Optimiser la vitesse de WordPress : les techniques avancées

Introduction : cet article commence où les autres s'arrêtent

Les guides de performance disent tous la même chose : activez un cache, compressez vos images, utilisez un réseau de diffusion. C'est juste, c'est nécessaire, et une fois que c'est fait, la plupart des sites restent lents.

Cet article suppose ces trois choses acquises. Il traite ce qui reste — et ce qui reste n'est presque jamais dans le rendu de la page :

temps total = temps serveur + chemin critique + ce que les tiers ajoutent
                    ↑              ↑                    ↑
              requêtes, PHP    CSS/JS bloquants    scripts que vous
              autoload, cron                       n'avez pas écrits

Les guides traitent la colonne du milieu. Les deux autres sont là où se trouvent les secondes. Pour les bases et la mesure des Core Web Vitals, commencez par l'optimisation des Core Web Vitals.

1. Le temps serveur — ce que le cache masque au lieu de régler

Un cache de page rend le problème invisible aux visiteurs anonymes, et totalement intact pour tous les autres : utilisateur connecté, panier non vide, page de compte, recherche interne, formulaire. Sur une boutique, ce sont exactement les pages qui rapportent.

La table des options et l'autoload. WordPress charge à chaque requête toutes les options marquées comme chargées automatiquement. Des extensions désinstallées y laissent des entrées, parfois volumineuses, qui continuent d'être lues à vie. C'est le premier endroit à regarder et presque personne ne le fait : mesurez le poids total de l'autoload, puis ce qui le compose.

Les requêtes non indexées. Une requête qui parcourt une table entière est indolore à mille lignes et fatale à cent mille. Le symptôme est trompeur : le site ralentit progressivement, on l'attribue à l'hébergement, et la cause est une requête qui n'a jamais changé.

Les tâches planifiées. WordPress les déclenche au chargement d'une page — c'est un visiteur qui paie l'exécution. Une tâche lourde et un site à faible trafic produisent le pire cas : le seul visiteur de l'heure attend la sauvegarde. Basculer sur une planification serveur réelle est une des interventions les plus rentables de cette liste.

Le nombre d'extensions. Ce n'est pas un mythe : chacune ajoute des lectures d'options, des scripts et des points d'accroche. Passer de trente à quinze se voit sur le temps serveur sans aucune autre intervention — voir auditer vos extensions en 5 étapes.

2. Le chemin critique — la seule règle qui compte

Tout ce qui bloque l'affichage du premier écran est du temps que le visiteur regarde. Les techniques classiques (minifier, différer) plafonnent vite. Ce qui débloque vraiment :

• charger le nécessaire au premier écran, différer le reste. Un fichier CSS unique qui contient les styles de toutes les pages du site fait payer à la page d'accueil le style du tunnel de commande ;
• ne pas charger les scripts là où ils ne servent pas. Un formulaire de contact qui charge sa bibliothèque sur les 400 pages du site est un cas extrêmement fréquent, et le correctif est conditionnel : charger sur la page qui l'utilise ;
• réserver la place des éléments qui arrivent après. Un bandeau, une image, une police qui s'insère décale la page — le visiteur perd sa ligne, et l'indicateur de stabilité visuelle s'effondre. Réserver la hauteur coûte une ligne de style ;
• précharger la police et l'image du premier écran, mais elles seulement. Tout précharger revient à ne rien prioriser.

⚠ Le piège : optimiser ce que l'outil de mesure affiche plutôt que ce que le visiteur vit. Un score obtenu en différant un script qui devient nécessaire trois secondes plus tard n'a rien amélioré — il a déplacé l'attente hors de la mesure.

3. Les tiers — le poste le plus lourd et le moins regardé

Sur beaucoup de sites, la moitié du temps de chargement vient de code que personne dans l'entreprise n'a écrit : mesure d'audience, bandeau de consentement, chat, pixels publicitaires, polices distantes, cartes.

Trois règles, par rendement :

1. Compter avant de discuter. Listez chaque script tiers et ce qu'il ajoute au poids et au temps. Le résultat surprend, et il rend la conversation possible avec ceux qui les ont demandés.
2. Un tiers doit gagner sa place. Un pixel installé pour une campagne terminée il y a huit mois coûte tous les jours. C'est le nettoyage le plus rapide et le plus rentable de tout cet article.
3. Héberger ce qui peut l'être. Les polices en particulier : les servir depuis votre domaine retire une résolution de nom, une connexion, une négociation de sécurité — et règle au passage une question de données personnelles.

Le cas du bandeau de consentement est le plus délicat, parce qu'il est obligatoire et qu'il arrive tôt. La solution n'est pas de le retirer : c'est de l'insérer sans qu'il pousse la page. Traité dans notre approche du consentement et des cookies.

4. Les images — au-delà de la compression

La compression est acquise. Ce qui reste :

• les dimensions servies. Une image de 2400 px affichée dans un cadre de 600 px transfère quatre fois trop d'octets. C'est le gaspillage le plus courant après les tiers ;
• le format, qui se choisit selon le contenu et non par principe ;
• le chargement différé, sauf pour l'image du premier écran. Différer celle-là dégrade directement l'indicateur principal — c'est l'erreur classique de la case cochée partout ;
• les textes alternatifs, qui ne servent pas la vitesse mais dont c'est le moment de s'occuper puisque vous ouvrez le sujet. Voir notre comparatif face à Smush.

5. Mesurer — trois erreurs qui font travailler pour rien

Mesurer en laboratoire seulement. Un test synthétique depuis un centre de données proche avec une connexion parfaite ne décrit personne. Les données de terrain décrivent vos visiteurs.

Regarder la moyenne. La moyenne cache la queue de distribution, et c'est dans la queue que se trouvent les abandons. Regardez les percentiles hauts : ce sont vos clients sur mobile en déplacement.

Mesurer une page. La page d'accueil est rarement représentative. Mesurez une page de contenu, une page produit et le tunnel — trois profils différents, trois goulots différents.

Et la seule question qui tranche l'ensemble : est-ce que le taux de conversion a bougé ? Un gain de vitesse qui ne se voit sur aucun indicateur métier est un gain d'ingénieur. Sur une boutique, le raisonnement complet est dans l'optimisation du tunnel de conversion.

6. Le protocole avancé, en une page

• Mesurer avant — terrain et laboratoire, sur trois types de pages, et noter les chiffres
• Poids de l'autoload relevé, entrées orphelines d'extensions désinstallées supprimées
• Requêtes lentes identifiées sur la page la plus lente, pas sur l'accueil
• Tâches planifiées basculées sur une planification serveur réelle
• Inventaire des tiers, avec pour chacun : qui l'a demandé, pour quoi, encore utile ?
• Polices hébergées chez vous, préchargées, et elles seules
• Scripts conditionnels : chargés sur les pages qui les utilisent
• Place réservée pour tout élément qui s'insère après le rendu
• Re-mesurer, comparer aux chiffres notés, et garder une page témoin non touchée

Conclusion

Quand le cache et la compression sont en place, la vitesse ne se gagne plus par réglage : elle se gagne en retirant. Des options qui se chargent pour rien, des scripts qui servent une page sur quatre cents, des tiers installés pour une campagne finie, des extensions gardées au cas où.

C'est moins spectaculaire qu'un nouveau module de cache, et c'est ce qui produit les secondes. La performance avancée est un travail de soustraction, et c'est pour ça qu'elle est rarement faite : il n'y a rien à installer.

Le test qui dit où vous en êtes : ouvrez la page la plus lente de votre site, pas votre page d'accueil. C'est celle-là que vos clients mécontents ont vue.

Pour la suite : l'optimisation des Core Web Vitals, les Core Web Vitals de WooCommerce et notre comparatif face à WP Rocket. Côté outils : performance des pages et optimisation des images — versions premium avec remboursement intégral sous 14 jours.