Sur les audits de performance que nous menons, la répartition des causes est remarquablement stable. Environ la moitié des problèmes viennent du serveur et des images, un tiers du JavaScript tiers, et le reste de détails d’intégration.
Ce qui suit est la séquence que nous appliquons, dans l’ordre, parce que l’ordre compte.
Mesurer d’abord, sur les bonnes données
Un score Lighthouse à 100 avec un LCP terrain à 4 secondes n’est pas un paradoxe : c’est le signe que la mesure de laboratoire ne reflète pas vos visiteurs. La Search Console et le rapport Chrome UX donnent la vérité.
Nous commençons donc par relever, sur 28 jours, le 75e centile de chacune des trois métriques, séparément sur mobile et sur ordinateur. Tout le reste découle de ces six chiffres.
LCP : d’abord le serveur
Le LCP est la somme de quatre segments : le temps de réponse du serveur, le délai avant découverte de la ressource, son téléchargement et son rendu. Optimiser l’image quand le serveur répond en 900 ms ne sert à rien.
Réduire le temps de réponse. Cache de configuration et de routes, requêtes N+1 supprimées, cache applicatif sur les données coûteuses. Sur une application Laravel correctement réglée, le temps de réponse serveur d’une page publique doit se situer sous 200 ms.
Rendre l’image principale découvrable tôt. Une image de hero chargée par JavaScript ou avec loading="lazy" retarde systématiquement le LCP. Elle doit être dans le HTML initial, avec fetchpriority="high" et sans chargement différé.
Servir des formats modernes. AVIF puis WebP en repli, dimensions exactes, et width/height toujours renseignés.
INP : le poids du JavaScript exécuté
L’INP mesure le délai entre une interaction et la réponse visible. Il est dégradé par les tâches longues sur le fil principal.
Sur les sites que nous auditons, la première cause est presque toujours un script tiers : outil de mesure, chat, bandeau de consentement mal implémenté. Le second poste est un framework front chargé pour animer trois éléments.
Deux règles simples suffisent souvent. Aucun script tiers n’est chargé avant le consentement et avant la peinture du contenu principal. Et le JavaScript applicatif reste sous 100 Ko compressés — ce qu’Alpine.js permet largement.
CLS : réserver la place
Le décalage de mise en page vient de trois sources : les images sans dimensions, les polices qui remplacent une police de repli aux métriques différentes, et les contenus injectés au-dessus du contenu existant.
Les corrections sont mécaniques. Toujours renseigner width et height. Charger les polices en swap et les héberger localement. Réserver la hauteur des bandeaux et publicités avant leur apparition.
Empêcher la régression
Un site optimisé se dégrade en trois déploiements si rien ne l’en empêche. Nous ajoutons dans l’intégration continue un budget de performance : poids total, poids du JavaScript, et scores Lighthouse minimaux. Un dépassement bloque la fusion.
C’est la seule mesure qui produit un effet durable. Tout le reste est un nettoyage ponctuel.