Performance WordPress : LCP, CLS, INP ce que ça change concrètement

La page optimisation WordPress couvre les aspects larges : cache, plugins, images. Cette page est centrée sur les Core Web Vitals spécifiquement, LCP, CLS, INP. Ce sont les métriques que Google mesure et qui influencent directement le classement.

Oui, directement. Un hébergement partagé lent dégrade le TTFB, ce qui impacte le LCP. Un VPS avec nginx correctement configuré et LiteSpeed Cache peut diviser le TTFB par 3 ou 4. Je conseille sur le choix et la configuration de l’hébergement dans le cadre des optimisations.

Oui, avec une configuration rigoureuse.  désactivation des polices inutilisées, lazy loading natif, désactivation du CSS global sur les pages qui n’en ont pas besoin , ces réglages combinés permettent d’atteindre des scores corrects. Le seuil de 90 sur mobile reste difficile avec un builder , 75-85 est un objectif réaliste et suffisant pour la plupart des sites. Ces réglages doivent être vérifiés à chaque mise à jour majeure du builder, ce que je couvre dans le cadre de la maintenance WordPress.

C’est le cas le plus fréquent. Plusieurs raisons expliquent cet écart. D’abord la puissance de traitement : un mobile bas de gamme a 5 à 10 fois moins de puissance CPU qu’un desktop, ce qui pénalise directement l’INP le JavaScript qui s’exécute en 50ms sur desktop peut prendre 200ms sur un smartphone de milieu de gamme. Ensuite la connexion : même en 4G, la latence mobile est plus élevée qu’une fibre fixe, ce qui impacte le TTFB et le LCP. Enfin les images : si les images ne sont pas servies en taille adaptée via srcset, le mobile charge la même image haute résolution que le desktop inutilement lourd. Google pondère les données mobiles plus fortement que les données desktop dans son algorithme depuis le passage au mobile-first indexing.

Le LCP en laboratoire, c’est ce que PageSpeed Insights mesure en simulant une connexion et un appareil standardisés dans un environnement contrôlé. C’est utile pour diagnostiquer des problèmes et comparer des versions d’une page. Le LCP terrain, c’est ce que Google mesure sur les vrais visiteurs de votre site via le Chrome User Experience Report, connexions variables, appareils anciens, géographies différentes. C’est cette donnée terrain que Google utilise pour le classement, pas le score PageSpeed. Un site peut avoir un excellent score PageSpeed en labo et des Core Web Vitals terrain mauvais si ses visiteurs sont majoritairement sur mobile avec une connexion lente. Je regarde toujours les deux, mais c’est le terrain qui compte pour le SEO.

Oui, c’est souvent le premier levier à corriger. Le TTFB (Time to First Byte) mesure le temps que met le serveur à envoyer le premier octet de réponse. Si le TTFB dépasse 600ms, le LCP ne peut pas être bon le navigateur attend que le serveur réponde avant de commencer à rendre quoi que ce soit. Sur un hébergement mutualisé surchargé sans cache, j’ai vu des TTFB de 1,5 à 2 secondes sur des sites WordPress. Passer sur un VPS avec LiteSpeed Cache bien configuré ramène souvent ce TTFB sous les 200ms. C’est un gain immédiat sur le LCP, sans toucher au contenu ni au code.

Ça dépend du type d’animation. Les animations CSS qui modifient transform ou opacity n’affectent pas le CLS elles sont composées sur le GPU et ne déclenchent pas de recalcul de layout. En revanche, les animations qui modifient top, left, width, height ou margin déplacent des éléments dans le flux du document et peuvent générer du CLS si elles se produisent pendant le chargement initial. Sur un builder et les builders visuels, beaucoup d’effets d’entrée (fade-in, slide-in) utilisent des propriétés qui affectent le layout, je les désactive systématiquement sur les éléments visibles au-dessus de la fold.