Optimisation de la Vitesse WordPress

Ce que mesurent vraiment les Core Web Vitals

Trois indicateurs, chacun décrivant une manière différente dont une page peut être désagréable. Savoir lequel vous échouez indique où se trouve le travail — ils n'ont presque rien en commun techniquement.

Où passe réellement le temps

1. Le serveur n'a même pas encore répondu. Si le TTFB atteint 800 ms, aucun travail côté client ne vous sauvera : un tiers du budget LCP est consommé avant le premier octet. Causes : pas de cache objet, hébergement lent, version de PHP dépassée, ou une extension qui appelle une API externe pendant la génération de la page.
2. La base de données travaille beaucoup trop. Table wp_options gonflée de données en chargement automatique, requêtes de métadonnées sans index, transients expirés jamais nettoyés. Invisible pour tous les outils front-end, et c'est régulièrement le plus grand gain.
3. Chaque extension charge ses ressources partout. Une extension de formulaire qui charge son CSS sur la page d'accueil, une bibliothèque de carrousel sur des pages sans carrousel. Le déchargement conditionnel retire souvent un tiers du poids sans rien changer visuellement.
4. Les images sont l'élément le plus lourd et personne ne les a redimensionnées. Un JPEG de 3000 px affiché en 800 px, sans WebP ni AVIF, sans attributs width/height (ce qui dégrade aussi le CLS), et un chargement différé appliqué à l'image d'en-tête — ce qui aggrave le LCP.
5. Les polices bloquent l'affichage puis décalent la mise en page. Quatre graisses de deux familles, sans font-display: swap, ou chargées depuis un domaine tiers nécessitant sa propre résolution DNS et négociation TLS.
6. Les scripts tiers oubliés. Gestionnaire de balises, chat, deux outils d'analyse, une carte de chaleur, un bandeau cookies. Ils représentent souvent l'essentiel de votre INP, et aucune optimisation de votre code ne compense cela.

La méthode

1. Mesurer d'abord, sur vos vraies pages. Accueil, une page de catégorie, un article ou produit, et le tunnel de commande le cas échéant. Laboratoire, terrain, et temps serveur.
2. Identifier les causes et les classer par secondes gagnées par heure de travail. Vous recevez cette liste avant tout travail : vous voyez ce que vous payez et pouvez arrêter dès que le rendement décroît.
3. Corriger en préproduction, dans l'ordre. Serveur et base d'abord, puis ressources, puis front-end. Rien n'arrive en production sans test.
4. Vérifier le fonctionnement, pas seulement la vitesse. Paiement, formulaires, vues connectées, mobile. Un site rapide et cassé est pire qu'un site lent qui fonctionne.
5. Déployer, puis re-mesurer les mêmes tests. Mêmes pages, mêmes outils, pour une comparaison honnête.
6. Remettre un rapport écrit. Ce qui était lent, ce qui a changé, les chiffres avant/après, et ce qui dégradera lentement le site si rien n'est surveillé.

Pourquoi je ne cherche pas le score de 100

Un score Lighthouse parfait est atteignable sur presque n'importe quel site si l'on accepte de casser des choses : différer tout le JavaScript, supprimer le suivi dont votre marketing a besoin, tout mettre en ligne. J'ai vu des sites à 100 dont le tunnel de commande ne fonctionnait plus sur Safari.

Ce qui compte, c'est le moment où un vrai visiteur peut voir et utiliser votre page, sur l'appareil et la connexion qu'il a réellement. Parfois cela signifie un chiffre Lighthouse plus bas et un bien meilleur site. J'optimise pour les données terrain et pour le chiffre d'affaires, et je vous le dis clairement quand un réglage échangerait une fonctionnalité réelle contre un joli score.

WooCommerce, un autre problème

Les pages boutique ne se mettent pas en cache comme un article : paniers, sessions et clients connectés sont dynamiques par nature. Le travail se déplace donc : cache objet avec Redis pour que les requêtes répétées cessent d'atteindre MySQL, règles d'exclusion de cache rigoureuses (pour ne jamais servir à un client le panier d'un autre), gestion des fragments de panier, indexation des tables que Woo sollicite lourdement, et maîtrise des requêtes d'administration qui rendent la gestion des commandes pénible au-delà de quelques milliers de commandes.

Questions fréquentes

De combien mon site va-t-il accélérer ?

La plupart des sites que je reprends portent deux à cinq secondes de délai évitable, avec un objectif réaliste de LCP sous la seconde. J'annonce une cible précise après l'audit plutôt qu'une promesse à l'aveugle.

Vous installez juste une extension de cache ?

Non. Le cache masque la lenteur, il ne la supprime pas. Le travail consiste à trouver ce qui est réellement lent et à le corriger ; le cache vient ensuite.

L'optimisation risque-t-elle de casser mon site ?

Pas en travaillant d'abord en préproduction, ce qui est ma méthode. Chaque changement est vérifié — paiement et formulaires inclus — avant la mise en production.

La vitesse influence-t-elle vraiment le SEO et les ventes ?

Les Core Web Vitals sont un critère confirmé, mais modeste. L'effet commercial est plus fort : les pages lentes perdent les visiteurs avant qu'ils voient l'offre.

Comment saurai-je que ça a fonctionné ?

Des chiffres avant/après issus des mêmes tests sur les mêmes pages, laboratoire et terrain. Les données terrain sont celles que Google utilise.

Mon hébergeur dit que tout va bien. Qui a raison ?

Souvent les deux. L'hébergeur mesure la réponse serveur dans des conditions idéales ; vos visiteurs vivent la page entière sur un téléphone milieu de gamme.