Core Web Vitals pour les sites PHP : comment réparer LCP, INP et CLS

Core Web Vitals pour les sites PHP ne sont pas un sujet uniquement frontal. Une page PHP lente peut passer une seconde à produire du HTML, et aucune optimisation d'image ne récupère cela. Dans le même temps, un serveur très rapide n'aide pas si une image de héros de 1,5 Mo bloque la plus grande peinture. Voici comment nous abordons les deux côtés sur nos propres sites PHP (integrono.com exécute PHP-FPM derrière nginx et Cloudflare) et sur les projets clients.

Ce que mesurent Core Web Vitals

• LCP ( Largest Contentful Paint) : lorsque le plus grand élément visible (généralement une image de héros ou un bloc d'en-tête) est rendu. Le bien dure 2,5 secondes ou moins.
• INP ( Interaction to Next Paint) : la rapidité avec laquelle la page répond visuellement après des clics, des pressions et des pressions sur des touches, tout au long de la visite. Le bon est de 200 ms ou moins.
• CLS ( Cumulative Layout Shift) : quantité de contenu qui saute pendant le chargement. Bon est de 0,1 ou moins.

Google les évalue sur la base de données de terrain provenant d'utilisateurs réels de Chrome, au 75e centile, séparément pour les mobiles et les ordinateurs de bureau. Cela signifie qu’un modèle ou un pays lent peut faire échouer l’ensemble du groupe. Les outils de laboratoire tels que Lighthouse sont destinés au débogage, pas à la partition finale.

Étape 1. Mesurez correctement

1. Ouvrez le rapport Core Web Vitals dans Google Search Console pour voir quels groupes d'URL échouent et sur quelle métrique.
2. Vérifiez PageSpeed Insights pour une URL de chaque groupe défaillant. Le bloc supérieur « données de champ » est ce qui compte ; le bloc Lighthouse ci-dessous est un test en laboratoire qui explique pourquoi.
3. Utilisez le panneau Performances de Chrome DevTools avec un ralentissement du processeur 4x et "Slow 4G" pour reproduire une expérience mobile typique.
4. Pour une surveillance continue, collectez des données d'utilisateurs réels avec la bibliothèque JavaScript web-vitals et envoyez-les à vos analyses.

<script type="module">
  import {onLCP, onINP, onCLS} from 'https://unpkg.com/web-vitals@4?module';
  const send = (m) => navigator.sendBeacon('/vitals', JSON.stringify({
    name: m.name, value: m.value, id: m.id, url: location.pathname
  }));
  onLCP(send); onINP(send); onCLS(send);
</script>

Étape 2. Corrigez d'abord le temps de réponse du serveur ( TTFB)

LCP inclut le temps avant l'arrivée du premier octet. Si la génération de votre HTML prend 800 ms, vous avez déjà dépensé un tiers du budget. Sur les sites PHP les leviers habituels sont :

• Activez OPcache et assurez-vous qu'il est suffisamment grand pour contenir tous les scripts. Sans cela, PHP recompile les fichiers à chaque requête.
• Ajustez PHP-FPM. Trop peu de travailleurs font la queue pour les requêtes, trop de mémoire épuise. Regardez la page d'état PHP-FPM pour la "file d'attente d'écoute" et le "nombre maximum d'enfants atteints".
• Mettez en cache des pages entières pour les visiteurs anonymes (nginx fastcgi_cache, un cache de réponses Laravel ou des règles de cache Cloudflare) et mettez en cache des fragments ou des résultats de requêtes avec Redis.
• Corrigez les requêtes lentes. Activez le journal des requêtes lentes, recherchez les modèles N+1 et ajoutez des index. Une page qui exécute 120 requêtes est lente quelle que soit la version de PHP.
• Gardez PHP à jour. Les versions PHP les plus récentes sont plus rapides et utilisent moins de mémoire.

# php.ini (production)
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0   ; reload php-fpm on each deploy

# php-fpm pool
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

Définissez pm.max_children à partir de la mémoire réelle : divisez la mémoire que vous pouvez donner à PHP par la taille moyenne d'un processus de travail (vérifiez avec ps). Avec validate_timestamps=0 n'oubliez pas de recharger PHP-FPM après chaque déploiement, sinon l'ancien code reste en mémoire.

Au niveau du serveur Web, activez HTTP/2 ou HTTP/3, Brotli ou gzip et les en-têtes de mise en cache de longue durée pour les fichiers statiques :

location ~* \.(?:css|js|webp|avif|jpg|png|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;

Utilisez des noms de fichiers versionnés ou une requête ?v= basée sur l'heure de modification du fichier afin que « immuable » ne serve jamais d'actifs obsolètes.

Étape 3. Réparez l'élément LCP

Recherchez l'élément LCP dans PageSpeed Insights ou dans le panneau DevTools Performance. Sur la plupart des pages de contenu, il s'agit d'une image de héros. Alors:

• Ne le chargez pas paresseusement. loading="lazy" sur l'image LCP le retarde. Utilisez plutôt fetchpriority="high".
• Servir la bonne taille. Une image de 2400 px pour un emplacement de 900 px gaspille des octets. Utilisez srcset et sizes.
• Utilisez WebP ou AVIF. Les économies typiques sont de 30 à 60 pour cent par rapport au JPEG de qualité similaire.
• Évitez les chaînes. Une image définie via un arrière-plan CSS ou injectée par JavaScript est découverte tardivement. Mettez-le dans le HTML en tant que <img>.
• Préconnecter ou auto-héberger les origines tierces dont dépend le LCP (polices, image CDN).

<img src="/images/hero-1200.webp"
     srcset="/images/hero-640.webp 640w, /images/hero-1200.webp 1200w"
     sizes="(max-width: 1040px) 92vw, 960px"
     width="1200" height="630"
     alt="Descriptive alt text"
     decoding="async" fetchpriority="high">

C'est le modèle utilisé par l'article sur ce blog : deux tailles WebP, des dimensions explicites et une priorité de récupération élevée pour le héros.

Étape 4. Supprimer les changements de disposition ( CLS)

• Définissez toujours width et height (ou aspect-ratio en CSS) sur les images, les vidéos et les iframes afin que le navigateur réserve de l'espace.
• Réservez de l'espace pour les bannières, les avis de cookies et les publicités. Insérez-les dans un conteneur avec une hauteur minimale fixe au lieu de pousser le contenu vers le bas après le chargement.
• Polices : utilisez font-display: swap ou optional, préchargez le fichier de police principal et sous-définissez-le. Choisissez une police de secours avec des métriques similaires.
• N'injectez pas de contenu au-dessus du contenu existant à moins que l'utilisateur ne l'ait déclenché.
• Animez avec transform et opacity, pas avec des propriétés qui changent la disposition (top, height).

Étape 5. Améliorer INP : moins de JavaScript sur le thread principal

INP est la métrique la plus récente et celle que les développeurs PHP négligent, car le serveur ne l'influence pas directement. Les causes résident dans le navigateur : tâches longues provenant de gros bundles, scripts tiers lourds (analyses, widgets de chat, gestionnaires de balises) et gestionnaires qui font trop de travail de manière synchrone.

• Auditez les scripts tiers. Supprimez ce que personne n'utilise, chargez le reste avec defer ou après la première interaction.
• Divisez les tâches longues. Divisez le travail en morceaux avec requestIdleCallback, setTimeout ou l' Scheduler API; déplacer les calculs lourds vers un Web Worker.
• Gardez le DOM petit. Des milliers de nœuds ralentissent chaque mise à jour.
• Évitez les mises en page synchrones forcées dans les boucles (lecture et écriture des propriétés de mise en page en alternance).
• Afficher un retour immédiat (un état enfoncé ou une roulette) avant de commencer un travail lent.

Étape 6. Protégez-le dans votre processus de déploiement

Les performances régressent tranquillement : un nouveau tag, un héros plus lourd, une requête supplémentaire sur la page d'accueil. Ajoutez Lighthouse CI ou une vérification programmée de l'API PageSpeed pour vos cinq modèles les plus importants, définissez des budgets ( LCP, taille totale JS, poids de l'image) et alertez lorsqu'ils sont dépassés. Comparez TTFB avant et après chaque version ; s'il saute, la cause est presque toujours une requête ou un cache qui ne fonctionne plus.

Un ordre de travail réaliste

1. Mesurez les données de champ et identifiez les groupes d'URL défaillants.
2. Activez OPcache, vérifiez les paramètres PHP-FPM, ajoutez une mise en cache pleine page pour le trafic anonyme.
3. Correction des images de héros : format, taille, priorité, dimensions.
4. Réservez de l'espace pour tout ce qui se charge tardivement.
5. Réduisez et différez JavaScript ; supprimer les tiers inutilisés.
6. Mesurez à nouveau après 28 jours, car les données de terrain sont une fenêtre continue.

Attendez-vous à ce que des améliorations apparaissent progressivement dans Search Console : le rapport utilise environ les 28 derniers jours de données, donc un correctif expédié aujourd'hui n'est entièrement visible qu'après environ un mois.

Comment pouvons-nous vous aider

Nous effectuons un travail de performance sur des projets PHP et Laravel dans le cadre d'un engagement technique SEO et en réglage ponctuel : mise en cache, requêtes, images et correctifs front-end livrés dans le code. Si vous souhaitez savoir lesquels des changements ci-dessus seraient rentables sur votre site, réservez une consultation ou une analyse de serveur. Pour une liste de contrôle plus large concernant l'exploration et l'indexation, lisez notre liste de contrôle technique d'audit SEO.