Consultant web performance front-end

Le front-end, là où tout se joue côté utilisateur

Le navigateur est impitoyable. Il parse le HTML, découvre les CSS, exécute le JavaScript, et ne peut rien afficher tant que les ressources critiques ne sont pas arrivées. Un fichier CSS de 200 Ko non minifié, une font chargée en render-blocking, un script analytics injecté dans le head — chacun de ces éléments repousse le moment où l'utilisateur voit quelque chose à l'écran.

La majorité des problèmes de Core Web Vitals que je rencontre en audit sont des problèmes front-end. Un LCP dégradé par une image hero en PNG de 2 Mo sans preload. Un INP plombé par un event listener qui déclenche un re-render complet du DOM. Un CLS causé par des publicités ou des embeds qui s'insèrent dans la page après le chargement.

Les scripts tiers, l'éléphant dans la pièce

Sur la plupart des sites e-commerce que j'audite, les scripts tiers représentent entre 50% et 80% du JavaScript exécuté. Tag managers, pixels de tracking, A/B testing, chatbots, widgets de recommandation — chacun ajoute son poids et ses requêtes réseau.

Le problème, c'est que personne ne regarde l'impact cumulé. Un tag manager à 80 Ko, ça passe. Mais quand il charge 15 tags qui chacun exécutent leur propre logique, les Long Tasks s'enchaînent et l'INP explose. La solution n'est pas toujours de tout supprimer — c'est d'auditer l'impact réel de chaque script, de retirer ceux qui ne servent plus, et de charger les autres de manière non bloquante.

Le Critical Rendering Path en pratique

Le concept est simple : réduire au minimum ce que le navigateur doit télécharger et exécuter avant de pouvoir afficher le contenu visible. En pratique, ça touche à tout — l'ordre des balises dans le head, la stratégie de chargement des fonts, le code splitting du JavaScript, l'extraction du CSS critique.

Ce qui rend le sujet intéressant, c'est que chaque stack a ses pièges. Un site React avec SSR peut avoir un excellent TTFB mais un INP catastrophique à cause de l'hydratation. Un WordPress avec 12 plugins charge souvent 400 Ko de CSS dont 90% ne s'applique pas à la page courante. Un site SFCC peut servir du HTML irréprochable mais injecter 3 Mo de JavaScript pour le layer de personnalisation.

Mesurer ce qui compte

Les scores Lighthouse sont utiles comme point de départ, mais ils ne reflètent pas l'expérience réelle. Un site peut avoir un score de 95 en lab et un LCP de 4 secondes sur le terrain. La différence vient du réseau, du device, des third-parties qui ne se chargent pas en mode headless.

Les données CrUX — le Chrome User Experience Report — mesurent ce que vivent les vrais utilisateurs sur les 28 derniers jours. C'est la seule source que Google utilise pour évaluer les Core Web Vitals dans son ranking. C'est aussi la source que j'utilise pour mesurer l'impact de chaque optimisation.