diagnostic-cwv

Diagnostic Core Web Vitals : playbook par métrique

Chaque correctif se rattache à un niveau de cause : image, JS, fonts, layout, serveur. Le ticket cite toujours l’élément ou le script fautif identifié dans les audits PSI, pas une généralité.

LCP : décomposer en 4 phases (leur somme = le LCP)

L’audit largest-contentful-paint-element de PSI donne l’élément LCP et la répartition par phase. Traite la phase dominante.

1. TTFB (cause : serveur). Au-delà de 800 ms, le serveur plombe tout le reste. Causes : pas de cache page, hébergement sous-dimensionné, pas de CDN, redirections avant la page finale. Correctifs : cache page côté serveur (WordPress : cache serveur ou plugin de cache pleine page), CDN, réduire les sauts de redirection, HTTP/2 ou HTTP/3.

2. Load delay (cause : image ou JS). L’élément LCP est découvert tard. Causes : image en background CSS, lazy-load appliqué à l’image LCP, image injectée par JS, carrousel. Correctifs : l’image LCP en <img> dans le HTML initial, retirer loading="lazy" au-dessus de la ligne de flottaison, <link rel="preload" as="image"> avec fetchpriority="high".

3. Load time (cause : image). L’image est trop lourde. Correctifs : AVIF ou WebP, srcset à la taille réellement affichée, compression, CDN images.

4. Render delay (cause : JS ou fonts). Tout est chargé mais rien ne s’affiche. Causes : CSS bloquant volumineux, JS bloquant dans le head, rendu côté client (SPA), font bloquante sur le texte LCP. Correctifs : critical CSS inline, defer sur le JS, SSR ou prérendu pour les SPA, font-display: swap.

INP : où part le temps d’une interaction

INP mesure la pire interaction (clic, tap, clavier) de la visite, en trois segments :

• Input delay : le main thread est occupé au moment du clic. Causes : long tasks au chargement, hydratation des frameworks, scripts tiers (tag managers, chat, analytics, pubs). Audits PSI : long-tasks, third-party-summary, mainthread-work-breakdown.
• Processing : les handlers sont lents. Causes : JS lourd déclenché au clic, re-render complet d’un framework.
• Presentation delay : le rendu suivant est lent. Causes : DOM énorme (PSI signale au-delà de ~1 500 noeuds), layout thrashing.

Correctifs par cause :

• JS : code splitting, defer, supprimer les scripts tiers non indispensables (chaque tag se paye en INP), découper les long tasks (scheduler.yield() ou setTimeout 0), debounce sur les handlers fréquents.
• DOM : virtualiser les longues listes, content-visibility: auto sur les sections hors écran.
• Hydratation : îlots ou hydratation partielle si le framework le permet ; sinon réduire le bundle initial.

Labo : INP n’existe pas dans Lighthouse. Proxys : TBT, long tasks, third-party-summary. Le rapport le précise à chaque fois.

CLS : identifier ce qui bouge

L’audit layout-shift-elements liste les éléments qui bougent : cite-les dans le ticket. Causes classiques, par fréquence :

1. Images et iframes sans dimensions (cause : layout) : ajouter width/height ou aspect-ratio pour réserver l’espace.
2. Fonts (cause : fonts) : le swap tardif fait sauter le texte. font-display: swap plus preload de la font des titres, size-adjust sur la fallback pour limiter le saut.
3. Contenu injecté au-dessus du contenu existant (cause : layout) : bannières cookies, barres promo, blocs pubs, widgets avis. Réserver l’emplacement en CSS (min-height) ou injecter sous la ligne de flottaison.
4. Animations en top/left (cause : layout) : passer à transform.

Priorisation impact / effort

• Ordre : la métrique la plus dégradée sur le template au plus fort trafic, puis les quick wins tous templates.
• Quick wins typiques (heures) : preload de l’image LCP, dimensions d’images, font-display, retrait d’un script tiers, min-height sur un bloc injecté.
• Chantiers (jours) : refonte du bundle JS, SSR, changement d’hébergement, migration du thème.
• Un ticket doit être exécutable par un dev qui n’a pas lu le rapport PSI : contexte en une phrase, cause, correctif précis, fichier ou template probable, gain attendu chiffré en ordre de grandeur, mesure de contrôle.

Pièges

• Ne compare jamais un score labo desktop à un seuil terrain mobile.
• Le « score performance » sur 100 de Lighthouse n’est pas un facteur de ranking ; les trois métriques terrain le sont. Optimise les métriques, pas le score.
• CrUX à l’origine et CrUX à l’URL sont deux choses : précise toujours lequel tu cites. Une URL peu visitée n’a pas de CrUX propre et hérite du verdict origine.
• Après correctif : labo immédiat pour valider la direction, terrain sous 28 jours pour le verdict réel.
• FID est mort depuis mars 2024 : toute source qui en parle encore est à actualiser.