Performance web des grands sites : mesurer juste et agir à grande échelle

L’essentiel

• Les Core Web Vitals se jugent au 75e percentile, par appareil : au moins 75 % des observations doivent respecter chaque seuil. Une moyenne ou le meilleur test ne suffit pas, et les trois indicateurs doivent passer.
• Les seuils « bons » sont LCP ≤ 2,5 s, INP ≤ 200 ms et CLS ≤ 0,1. Au-delà de 4 s, 500 ms et 0,25 respectivement, l’indicateur est mauvais ; entre ces bornes, il reste à améliorer.
• Le terrain décrit les visites réelles ; le laboratoire sert à reproduire et expliquer un problème dans des conditions fixées. CrUX, RUM et tests répétés se complètent ; TBT ne remplace pas INP.
• CrUX couvre une fenêtre glissante de 28 jours et seulement une population éligible de Chrome. Les données d’une URL se distinguent de celles de son origine : ces dernières peuvent masquer des gabarits lents.
• Un waterfall montre quand chaque requête commence, ses phases réseau et ses dépendances. Les retards du contenu utile guident la lecture, au-delà du poids des fichiers, avec l’appui de la filmstrip et de la trace CPU.
• Le HAR ajoute un journal exploitable des URL, statuts, en-têtes, tailles et timings pour comparer les captures et regrouper les coûts par domaine. Il ne décrit pas le travail de rendu (rendering) et doit être nettoyé avant partage.
• Sur un grand catalogue, je commence par l’attente serveur (TTFB) : requêtes applicatives, cache HTML et cache en périphérie (edge caching) du CDN. La politique de cache dépend de la fraîcheur attendue et de la personnalisation, avec des règles d’invalidation (purge) explicites.
• Deuxième levier : la chaîne image, avec des dimensions adaptées et un format vérifié visuellement. L’image LCP doit être découverte tôt, sans lazy loading ; son diagnostic sépare l’attente avant requête du téléchargement et du retard d’affichage.
• Le travail JavaScript est le troisième levier, tiers compris, pendant le chargement et les interactions. Différer un script ne supprime pas son coût CPU ; les parcours se testent sur un téléphone modeste, selon le consentement.
• HTTP/2 et HTTP/3 permettent le multiplexage, mais ne raccourcissent ni une chaîne de découverte (request chain) ni un calcul serveur sérialisé. La comparaison entre première visite et visite répétée révèle les effets du cache navigateur.
• Des réponses serveur lentes et des erreurs peuvent réduire la capacité de crawl de Googlebot. Étudier ce lien demande de croiser logs et statistiques d’exploration, sans déduire du LCP un nombre d’URL explorées ni promettre l’indexation.
• La priorité dépend de la famille de pages, du trafic touché et de l’enjeu du parcours ; chaque correction répond à une hypothèse. On vérifie le gain par des tests avant/après, puis sa tenue en production avec le RUM et enfin CrUX.

Partir de l’expérience réelle, pas d’une note

Une fiche produit peut obtenir une bonne note Lighthouse et rester pénible à utiliser. L’image arrive vite, puis le sélecteur de taille ne répond plus pendant l’initialisation des scripts. Le diagnostic doit donc suivre tout le parcours, de l’arrivée via Google à l’ajout au panier, en passant par l’ouverture d’un filtre et la consultation du produit.

Quand la page répond vite, le visiteur garde son attention sur le parcours et ne prend pas l’attente pour une panne. Réduire cette attente peut limiter l’abandon et favoriser la conversion. Une seconde gagnée ne garantit toutefois pas le même effet commercial partout. Le chapitre Performance du Web Almanac 2025 décrit cette expérience au-delà du chargement initial. Pour mesurer l’effet sur l’activité, il faut comparer des populations en contrôlant l’acquisition, l’appareil utilisé et les promotions. Une corrélation entre lenteur et abandon ne prouve pas, seule, la causalité.

CrUX fournit des données terrain issues d’utilisateurs de Chrome ayant activé les conditions de collecte requises. Il ne couvre donc ni tous les navigateurs ni tous les visiteurs. Les pages doivent aussi être publiques et suffisamment fréquentées : une URL sans données n’est pas une URL rapide.

L’API CrUX distingue les données d’une URL de celles de son origine, définie par protocole, hôte et port. L’agrégat d’origine peut masquer des catégories lentes derrière des fiches populaires. La fenêtre glissante couvre 28 jours, avec une actualisation quotidienne ; une livraison ne remplace pas immédiatement les anciennes observations. Le jeu BigQuery mensuel suit un autre calendrier.

Les formats d’appareil sont phone, tablet et desktop. La documentation des dimensions CrUX indique le retrait d’Effective Connection Type en février 2025. Les notes de version précisent que la publication du 11 février remplace cette dimension dans BigQuery par RTT, une métrique de latence aller-retour. Ce n’est pas un filtre équivalent aux anciennes classes de connexion, ni une mesure de débit.

Dans Search Console, le rapport Signaux Web essentiels regroupe des URL aux comportements similaires à partir de CrUX. Ces groupes signalent les familles touchées ; leur résultat ne s’applique pas automatiquement à chaque fiche. Une collecte RUM sur le site complète cette vue. Avec web-vitals.js et sa version d’attribution, on relie les mesures aux éléments et interactions concernés. Le gabarit et la version déployée donnent le contexte technique ; l’état du consentement précise les conditions de la visite. Documenter l’échantillonnage et ne transmettre aucune donnée personnelle dans les sélecteurs.

Choisir les KPI qui expliquent le problème

Les Core Web Vitals se jugent au 75e percentile, séparément selon l’appareil : pour être bon sur un indicateur, au moins 75 % des observations doivent respecter son seuil. Ce n’est ni une moyenne, ni la meilleure exécution d’un test. Les trois indicateurs doivent passer pour une évaluation globale favorable.

Les seuils officiels distinguent trois classes. Le LCP est bon jusqu’à 2,5 s, à améliorer au-delà et jusqu’à 4 s, puis mauvais au-delà de 4 s. Pour l’INP, ces bornes sont de 200 ms et 500 ms ; pour le CLS, de 0,1 et 0,25. Dans les deux cas, l’indicateur est bon jusqu’à la première borne, à améliorer jusqu’à la seconde incluse, puis mauvais au-delà.

Le repère TTFB de 800 ms n’est pas un quatrième Core Web Vital. FCP décrit un premier signe de vie, parfois très éloigné du contenu utile. Le Web Almanac distingue ces mesures des indicateurs de réactivité dans son analyse des performances.

FID a disparu des Core Web Vitals au profit d’INP en mars 2024 : il ne mesurait que l’attente avant le traitement de la première interaction. INP observe les clics, pressions et saisies pendant la visite, jusqu’au prochain affichage, en écartant certains extrêmes. Il ne chronomètre pas toute la réponse métier asynchrone. Une visite sans interaction éligible ne produit pas d’INP.

TTI a été retiré de Lighthouse 10 : sa dépendance aux périodes de calme réseau et CPU le rendait trop variable. La définition MDN de TTI aide à lire les anciens audits. Aujourd’hui, TBT sert au diagnostic de laboratoire ; il ne remplace pas INP terrain.

Pour une image LCP, les quatre sous-parties orientent directement l’action. Un téléchargement raccourci ne change rien si un script retarde ensuite l’affichage. Pour un LCP textuel sans ressource propre, les phases de chargement de ressource ne s’interprètent pas comme celles d’une image. Additionner des p75 indépendants ne permet pas de reconstituer un p75 global.

Je recommande de réduire d’abord les délais avant chargement et avant affichage. Le téléchargement utile occupe alors la plus grande part possible du temps restant ; il n’y a ni raison de l’allonger ni quota universel à respecter. Un resource load delay long oriente d’abord vers une découverte tardive de l’image ; sa priorité et une éventuelle attente réseau viennent ensuite dans les vérifications.

Utiliser WebPageTest pour trouver la cause

Avec WebPageTest.org, on peut reproduire les conditions d’une page lente. Lighthouse fournit un audit reproductible et des pistes ; WebPageTest offre davantage de contrôle et une lecture temporelle détaillée. Tester d’abord sur un téléphone milieu de gamme de type Moto G, réel si disponible, puis sur un profil desktop. Une émulation de dimensions ne reproduit pas le CPU d’un téléphone.

Le navigateur doit rester le même et la localisation proche du public. Commencer en 4G, puis passer à un scénario dégradé en 3G ; sur desktop, le câble sert de référence. Consigner le débit, la latence et les paramètres CPU exacts, car les noms des profils ne suffisent pas. Le guide WebPageTest de DebugBear, actualisé en décembre 2025, présente les réglages et vues disponibles.

Le waterfall aligne les requêtes dans le temps, de la résolution du domaine (DNS) à l’établissement du transport (connect) et à la sécurisation de l’échange (TLS). Viennent l’envoi, l’attente du premier octet et le download. Le segment d’attente d’une requête n’est pas le TTFB de navigation complet. Blocking désigne une attente avant départ, notamment liée à l’ordonnancement ; ce n’est pas automatiquement du JavaScript bloquant. Les timings de navigation et de ressources précisent ces frontières.

Les lignes verticales repèrent les événements selon la légende du rapport : render start pour le début visuel, DOMContentLoaded après analyse du document et scripts concernés, on load pour l’événement de chargement. Fully loaded est une convention de fin de mesure après activité réseau, pas la preuve que toutes les interactions fonctionneront. Une connexion réutilisée peut ne montrer aucun nouveau DNS ou TLS.

La filmstrip montre ce que le visiteur voit pendant l’attente. Si, par exemple, l’écran reste blanc quatre secondes avant que la grille apparaisse d’un coup, il faut chercher les dépendances qui précèdent le premier rendu. Pour chaque changement visuel, regarder les requêtes et l’activité CPU au même instant.

Les tests répétés se comparent sur leur médiane et leur dispersion. La first view alimente le cache navigateur que réutilise la repeat view. Leur écart ne mesure pas directement le cache hit du CDN, qui peut être chaud dès la première visite.

Pour une comparaison A/B technique, ne faire varier qu’un facteur et alterner les exécutions entre les deux versions, à consentement et cache identiques. La comparaison technique n’est pas un test de conversion randomisé. Le blocage d’URL ou de domaines sert ensuite à isoler un fournisseur.

Lire un waterfall, requête par requête

Suivre une page liste de produits

Sur une page liste typique, les dépendances entre ressources déterminent l’arrivée du contenu. Le schéma ci-dessous en donne un exemple simplifié, sans mesure ni durées attribuées à un site réel. Le temps se lit de gauche à droite ; les départs des requêtes se suivent de haut en bas.

Le document HTML ouvre la séquence. Son attente domine : tant que les premiers octets ne sont pas arrivés, le navigateur ne découvre pas les ressources qu’ils annoncent. Le CSS part ensuite ; la police web attend la lecture des règles qui la déclarent et son utilisation. Cette chaîne HTML, CSS, police peut retarder le texte ou provoquer son remplacement après un premier affichage.

Le téléchargement de l’image hero, candidate LCP, démarre tard parce que, dans cet exemple, elle est déclarée en arrière-plan CSS. Un lazy loading mal placé pourrait produire un retard comparable. Il faut distinguer ce délai avant la requête de la lenteur du téléchargement lui-même. Plus bas, un bundle JavaScript déclenche un tag manager, qui ouvre plusieurs branches vers des scripts tiers. Ces branches montrent les requêtes qu’un seul script d’intégration peut déclencher.

Décomposer les barres et les repères

Consulter la légende : les couleurs varient selon l’outil. Si la portion DNS est longue, vérifier la résolution et les domaines sollicités. Pour une connexion longue, examiner la latence et l’établissement du transport ; pour un TLS long, la négociation sécurisée. Ces étapes peuvent disparaître sur une connexion réutilisée.

La couleur d’attente correspond au délai après envoi, avant réception du premier octet de la réponse. Elle mêle des effets réseau et serveur ; l’attribuer intégralement au calcul applicatif fausserait le diagnostic. Si le téléchargement dure, vérifier les octets transférés, le débit et la concurrence. Un espace avant la barre peut signaler une découverte tardive ou une file d’attente : l’initiateur et les timings permettent de les distinguer. Les timings documentés par MDN évitent de mélanger ces phases.

Les traits verticaux situent les événements du chargement : TTFB du document, premier affichage, LCP, DOMContentLoaded et load. Le premier affichage ne garantit pas un contenu utile ; DOMContentLoaded concerne l’analyse HTML et les scripts concernés, load les ressources qui conditionnent cet événement. Leur ordre par rapport au LCP dépend de la page. Aucun ne certifie que les filtres répondront vite.

Remonter les dépendances, comparer les visites

Pour reconstituer la chaîne critique, partir du contenu attendu et remonter vers ses initiateurs. Des requêtes parallèles ne s’additionnent pas ; une petite ressource découverte après plusieurs dépendances peut peser davantage qu’une grosse image secondaire. Le navigateur arbitre aussi selon ses priorités, les connexions et le débit disponibles.

En repeat view, certaines barres disparaissent ou raccourcissent grâce au cache navigateur ; une revalidation conserve toutefois un échange. Les lenteurs restantes concernent notamment le HTML et les tiers peu cacheables. Les domaines externes peuvent ajouter leurs propres connexions et concurrencer l’image principale. Leur position dans le waterfall indique leur départ, pas leur coût d’exécution, que révèle la trace CPU.

Les pistes d’amélioration

Lorsque l’attente du document domine, je commence par le TTFB. Vérifier le cache HTML et la proximité des réponses via le CDN, puis remonter à l’origine : base de données, recherche et appels internes. Séparer les réponses servies en cache des recalculs, sinon la moyenne risque de masquer les cas coûteux.

Intégrer le CSS critique raccourcit la chaîne de chargement, mais augmente le poids HTML à mesurer. Déclarer l’image LCP dans le document plutôt qu’en arrière-plan CSS avance sa découverte ; un preload ciblé et fetchpriority="high" complètent ce travail. La priorité de chargement complète la découverte précoce, elle ne la remplace pas. preconnect se réserve aux origines indispensables. Pour les polices, le réglage de font-display accompagne le préchargement du seul WOFF2 nécessaire, avec les attributs adaptés, dont crossorigin.

Le protocole HTTP/2 ou HTTP/3 et la priorisation effective des ressources se vérifient dans les captures. Leur multiplexage partage une connexion entre flux ; QUIC évite qu’une perte bloque tous les flux comme avec TCP. Si l’origine sérialise ses traitements, HTTP/2 laisse subsister cette attente. Les 103 Early Hints peuvent annoncer des ressources avant la réponse finale, pendant sa préparation ; leur usage demande de valider la prise en charge et de limiter les indications aux dépendances stables.

Passer les scripts compatibles en defer, ou en async lorsqu’ils sont indépendants. Les tiers secondaires peuvent attendre l’interaction utile, sans reporter leur initialisation sur le premier clic ; leur déclenchement respecte le consentement requis. En revoyant les formats et les dimensions des images, il faut veiller à conserver une qualité acceptable pour présenter les produits.

Réserver immutable aux ressources versionnées dont l’URL change avec le contenu. Pour compresser les textes côté serveur, précompresser les fichiers statiques et maîtriser le coût CPU des contenus dynamiques. Rejouer ensuite le scénario pour mesurer l’effet de la requête raccourcie sur l’affichage du contenu ou sur l’interaction.

Le fichier HAR : le journal complet d’un chargement

Ce qu’est un HAR

Le HAR conserve les échanges réseau pour l’analyse après le test. Ce journal JSON rassemble toutes les requêtes enregistrées pendant la session, dans log.entries : URL, méthode, en-têtes, statut, tailles et corps optionnel. Le format courant est HAR 1.2 ; la spécification hébergée par le W3C reste un brouillon historique abandonné, pas une recommandation W3C.

Les timings détaillent blocked, attente avant départ ; dns, résolution ; connect, connexion ; ssl, négociation TLS ; send, envoi ; wait, attente du premier octet après envoi ; receive, réception. Ils sont exprimés en millisecondes. ssl est inclus dans connect. Une valeur -1 indique une information indisponible ou non applicable, jamais une durée négative à additionner.

Générer une capture exploitable

La capture doit commencer avant la première navigation du parcours. Dans Chrome DevTools, on ouvre Network, on vide le journal, puis on active Preserve log et Disable cache avant de recharger. Preserve log conserve les navigations successives. Après retrait des filtres, les options d’export HAR, dont « sanitized », remplacent l’ancienne commande « Save all as HAR with content ». Les guides DebugBear et Google Cloud détaillent la capture.

Dans Firefox, on enregistre depuis Réseau avec « Save All As HAR ». Dans Safari, on active les outils de développement, puis on ouvre l’inspecteur Web ; après rechargement dans Network, la commande Export produit le fichier. Requestly illustre ces parcours. Pour étudier le cache, Disable cache doit être décoché avant la visite répétée.

L’export HAR de WebPageTest doit identifier la first view ou la repeat view et le numéro d’exécution. Pour automatiser, Playwright propose recordHar ; il faut fermer le contexte pour enregistrer le fichier. Lighthouse collecte aussi automatiquement réseau et trace, mais son rapport JSON n’est pas un HAR : ses journaux réseau nécessitent une conversion.

Les ajouts de Chrome et leurs pièges

Chrome ajoute notamment _initiator, origine du déclenchement, _priority, priorité, _resourceType, catégorie, et _fromCache, provenance du cache lorsqu’elle est renseignée. Ces extensions varient selon l’exporteur. Le guide Monito accompagne la lecture d’un HAR Chrome ; seuls les champs réellement présents peuvent être exploités.

Je déconseille d’interpréter les dernières décimales des timings arrondis. Une ressource servie depuis le cache peut figurer sans transfert réseau. Les corps volumineux gonflent l’archive, parfois sans être tous conservés. Comme le rappelle KeyCDN, le HAR archive les échanges ; son poids sur disque n’est pas celui de la page téléchargée.

Passer des requêtes aux corrections

startedDateTime et les timings permettent de reconstruire le waterfall. Les initiateurs relient ensuite les requêtes à l’image LCP identifiée dans la trace. L’examen porte sur les CSS et scripts potentiellement bloquants, puis sur les polices tardives et les scripts injectés par un tag manager. Leur position seule ne prouve pas qu’ils bloquent le rendu.

Pour chaque réponse, la politique de transfert et de cache se lit dans Content-Encoding, Cache-Control, Age et les en-têtes de hit CDN. Vérifier ensuite les redirections en chaîne et les codes 4xx ou 5xx. Comparer l’attente par domaine à partir du champ wait, sans la confondre avec le TTFB complet ni avec le seul calcul serveur.

Pour comparer ces coûts avec Python, on charge le JSON et on parcourt log.entries. Extraire l’hôte de request.url avec urllib.parse.urlsplit, puis regrouper les entrées par hôte et _resourceType, à défaut par response.content.mimeType. On compte les entrées et on additionne response.bodySize pour les corps transférés, en isolant les tailles inconnues. response.content.size mesure le contenu décompressé. Les totaux par domaine et par type incluent les tiers. Trier ensuite les timings.wait valides par ordre décroissant et afficher les dix premiers avec leur URL.

Comparer deux HAR

Documenter les conditions des captures, puis importer les fichiers dans Chrome DevTools ou le HAR Analyzer de DebugBear. Avant/après optimisation, first view/repeat view, avec/sans domaines tiers bloqués, ou deux appareils : le scénario et le consentement doivent rester identifiables. Sur plusieurs captures, comparer les requêtes et les octets, puis la chaîne critique et les attentes par domaine. Rapprocher les entrées par URL et méthode en conservant les paramètres qui modifient la réponse. Ne pas additionner les durées parallèles.

Nettoyer avant de partager

Un HAR brut peut exposer des cookies, des jetons, des informations d’autorisation et des données de formulaire : il doit être nettoyé avant partage. Chrome retire désormais par défaut cookies et en-têtes d’autorisation, mais des secrets restent possibles dans les URL et corps. Le HAR Sanitizer, open source et exécuté côté client, assure ce nettoyage ; je recommande encore une relecture du résultat. Le 25 mars 2026, Cloudflare a ajouté à sa DLP la détection des HAR et un parcours de nettoyage avec reconnaissance des fichiers assainis.

Ce que le HAR ne montre pas

Le HAR décrit le réseau, pas le rendu ni le thread principal. Le panneau Performance et la trace Lighthouse montrent le travail du navigateur. Confronter ce diagnostic à l’expérience des visiteurs avec les métriques terrain.

Réduire l’attente serveur et organiser les caches

Face à un TTFB élevé, distinguer le réseau de l’origine. Vérifier la localisation et l’état du cache CDN, puis utiliser les temps applicatifs pour isoler le coût de la base de données, du moteur de recherche et des appels internes. Ajouter des serveurs ne résout pas une requête catalogue mal conçue.

DNS, TLS, géographie et réutilisation des connexions pèsent avant même le HTML. HTTP/2 multiplexe les échanges ; HTTP/3 utilise QUIC et limite le blocage entre flux provoqué par une perte de paquets. L’évolution de HTTP chez MDN explique ces différences. Aucun protocole ne supprime le calcul métier. Une stratégie Edge SEO peut rapprocher certaines réponses du visiteur, avec des règles de cache maîtrisées.

Dans le navigateur, Cache-Control: public, max-age=31536000, immutable se réserve aux ressources publiques versionnées par hash. Une nouvelle version reçoit une nouvelle URL. Pour les documents qui doivent être revalidés, ETag autorise une réponse 304, qui économise le corps mais conserve un aller-retour. no-cache impose une validation ; no-store interdit le stockage. Ces distinctions figurent dans Cache-Control sur MDN.

Au CDN, TTL et s-maxage gouvernent la fraîcheur partagée. stale-while-revalidate peut servir temporairement une réponse périmée pendant son actualisation. La cache key doit intégrer les variantes réellement nécessaires, comme langue ou devise, sans multiplier les entrées avec des paramètres marketing inutiles. Une réponse personnalisée exige une politique spécifique pour éviter tout mélange entre visiteurs.

Le cache hit ratio se calcule sur un périmètre explicite : hits divisés par requêtes observées, avec traitement documenté des bypass. Les octets servis apportent une autre lecture du cache. Isoler les échecs sur HTML : un ratio global élevé grâce aux images peut cacher une origine saturée.

Le cache applicatif stocke données ou calculs ; le cache de pages conserve du HTML rendu. Sur un grand catalogue, les listes cumulent filtres, tris et pagination. Je recommande de mettre en cache d’abord les combinaisons fréquentées et d’en limiter le nombre. Séparer autant que possible les données stables de la disponibilité volatile réduit les contraintes de fraîcheur. Une modification de produit déclenche une invalidation ciblée des fiches et listes concernées. Il faut suivre ces dépendances, dédupliquer les événements et éviter qu’une purge massive provoque une avalanche de recalculs simultanés.

Alléger les transferts et la chaîne image

Avant de chercher à alléger une page, il faut regarder ce qui pèse. Le chapitre Page Weight 2025 distingue poids total et catégories de ressources. Répartir les octets entre HTML, CSS, JS, images et polices, puis examiner cette répartition par propriétaire. Les tiers traversent ces catégories ; leurs octets sont déjà comptés dans le total. Le poids dépend aussi du scénario et du moment où la mesure s’arrête.

Gzip et Brotli compressent les contenus textuels. Dans l’exemple publié par DebugBear, un fichier JavaScript de 173 Ko descend à 61 Ko avec Gzip et 52 Ko avec Brotli, soit environ 65 % et 70 % de réduction. Ce sont les résultats de cet exemple, pas des ratios garantis.

Gzip propose des niveaux de 1 à 9, Brotli de 0 à 11. Monter le niveau augmente généralement le coût CPU de compression. Les fichiers statiques peuvent être précompressés pendant le build, éventuellement au niveau maximal après mesure du temps nécessaire. Pour le HTML dynamique, je préfère un niveau modéré s’il préserve mieux le TTFB.

On négocie via Accept-Encoding et vérifie Content-Encoding. Zstandard, identifié par zstd, émerge dans la diffusion HTTP ; la référence MDN permet de vérifier son support. Inutile de recomprimer systématiquement des images déjà compressées.

Pour les images, AVIF peut offrir un meilleur compromis poids et qualité, avec un encodage plus coûteux ; WebP reste utile et JPEG conserve sa place selon le contenu et la chaîne existante. Je recommande une comparaison visuelle portant notamment sur les textures et les détails produit. Le choix du format ne corrige pas une image hero servie, par exemple, en 4000 pixels sur un téléphone.

srcset propose les variantes, sizes décrit la largeur d’affichage attendue. Des dimensions width et height réservent l’espace. Le lazy loading s’applique sous la zone visible, jamais à l’image LCP ; fetchpriority="high" signale sa priorité. Un preload aide si sa découverte est tardive, à condition de cibler la même variante responsive pour éviter un double téléchargement. Les attributs de l’image HTML décrivent ces mécanismes.

Le DAM conserve les originaux et métadonnées. Le CDN image produit des variantes à la volée, puis les cache. Une gamme finie de dimensions et des paramètres autorisés contiennent le coût des transformations. Si le format est négocié via Accept, le cache doit distinguer les représentations, avec Vary: Accept ou une normalisation équivalente adaptée au CDN. La version de l’original entre dans la clé.

Rendre du temps au navigateur et encadrer les tiers

Un fichier JavaScript léger sur le réseau peut coûter cher à analyser, compiler et exécuter. Le CPU, la mémoire disponible et le thread principal déterminent ce qui reste possible pendant une interaction. Un téléphone d’entrée de gamme rend cette concurrence visible ; ralentir seulement le réseau d’un ordinateur puissant ne suffit pas.

Pour un script classique externe, defer préserve l’ordre et attend la fin de l’analyse HTML ; async exécute dès disponibilité sans garantir l’ordre. Les modules sont différés par défaut. Ces règles de chargement déplacent l’exécution, elles ne la rendent pas gratuite.

Découper le code par usage pour retarder les fonctions secondaires, sans créer une cascade d’imports au premier clic. L’hydratation rattache les comportements au HTML rendu côté serveur : hydrater toute une longue liste peut annuler une partie du gain initial. Pour les éléments purement éditoriaux, vérifier si cette hydratation est nécessaire.

Une Long Task dépasse 50 ms sur le thread principal. La trace indique si elle vient du code métier, d’un tiers ou d’un recalcul de mise en page. Pour fractionner un traitement, await scheduler.yield() cède la main avant une continuation priorisée. Sa disponibilité doit être vérifiée et un repli prévu, conformément à la documentation MDN. Fractionner réduit le blocage continu, pas le volume total de travail.

Les tiers ajoutent transferts, connexions et exécution. Le chapitre Third Parties 2025 examine notamment leur coût sur le thread principal. Un tag manager organise leur déclenchement ; il n’efface pas leur impact sur INP.

Je déconseille de repousser tous les tags au premier tap : cela peut libérer le chargement puis bloquer précisément l’utilisateur. Le protocole distingue l’état avant consentement des visites après acceptation ou refus. Dans WebPageTest, bloquer les domaines d’un fournisseur permet de comparer plusieurs exécutions du même parcours. Si le blocage casse une dépendance, le gain apparent n’est pas exploitable tel quel. Chaque tiers doit avoir un responsable, une utilité vérifiable, un budget et une date de réexamen.

Relier performance serveur et exploration SEO

Googlebot adapte son rythme à la santé du serveur. Des réponses lentes, des erreurs 5xx ou des limitations 429 peuvent réduire sa capacité d’exploration, comme l’explique le guide Google sur le budget de crawl des grands sites. Une page lente occupe plus longtemps les ressources disponibles pour l’exploration. À l’échelle d’un catalogue, ces délais limitent potentiellement la couverture.

Je déconseille de convertir mécaniquement le LCP en nombre d’URL explorées : ce lien concerne la capacité serveur. La demande de crawl dépend aussi des contenus et de leurs changements. Une infrastructure rapide ne garantit ni exploration exhaustive ni indexation.

Dans le rapport Statistiques d’exploration de Search Console, on rapproche les temps de réponse et les volumes des incidents, puis on examine les codes HTTP pour préciser les échecs. L’analyse des logs serveur et du crawl révèle les familles coûteuses et les paramètres inutiles. Ces URL alimentent le travail sur l’inventaire dans la stratégie SEO.

Transformer le diagnostic en travail suivi

Pour chaque problème observé sur le terrain, retenir des pages représentatives : catégories fréquentées, fiches, recherche et panier. Inclure aussi des cas peu visités mais coûteux pour l’origine. La priorité combine trafic touché, gravité, enjeu du parcours, coût de correction et risque métier.

Chaque ticket doit formuler une hypothèse vérifiable. Par exemple, rendre l’image LCP découvrable dans le HTML doit réduire son resource load delay. Joindre la trace initiale et indiquer le gabarit concerné ainsi que le protocole de comparaison. Après correction, on répète les tests de laboratoire, puis on mesure les effets en production avec le RUM avant leur confirmation progressive dans CrUX.

Les budgets de performance deviennent des garde-fous dans la CI : poids JavaScript par route, ressources critiques, absence de régression sur les scénarios stabilisés. Les alertes terrain associent dépassement durable, volume minimal et segment concerné. Une exécution isolée ne suffit pas à justifier le blocage d’une livraison. Un échange sur le catalogue peut partir de ces éléments concrets : gabarits, mesures et contraintes de fraîcheur.

Questions fréquentes

Une bonne note Lighthouse suffit-elle ?

Une bonne note Lighthouse atteste la réussite d’un scénario de laboratoire, sans suffire à établir la qualité de l’expérience réelle. Il faut aussi examiner les visites terrain et les interactions pendant le chargement.

Pourquoi une URL n’apparaît-elle pas dans CrUX ?

Une URL peut manquer d’observations éligibles ou ne pas satisfaire les critères de publication. Son absence de CrUX ne renseigne donc pas sur sa rapidité. Le RUM et le laboratoire permettent de l’étudier sans lui attribuer automatiquement les valeurs de l’origine.

Faut-il mettre toutes les pages en cache ?

Les exigences de fraîcheur et de personnalisation imposent des règles de cache distinctes selon les pages. Les variantes de listes rarement utilisées peuvent aussi coûter davantage à stocker et invalider qu’elles ne rapportent.

Quand vérifier les résultats après une correction ?

La vérification au laboratoire commence dès le déploiement. Le RUM prend le relais avec assez d’observations comparables. CrUX reflète progressivement la nouvelle version sur sa fenêtre de 28 jours.

Que montre un waterfall de plus qu’une note ?

Le waterfall expose les départs, les attentes et les dépendances de chaque requête. Il explique ainsi pourquoi une image légère peut arriver tard. Le HAR précise les en-têtes et les tailles ; la trace CPU aide à expliquer les retards de rendu et d’interaction.

À retenir

• Piloter les Core Web Vitals au p75, par appareil et famille de pages.
• Je recommande de croiser CrUX, RUM et laboratoire avant de choisir une correction.
• Remonter la chaîne critique dans le waterfall, vérifier les échanges dans le HAR et croiser filmstrip et trace CPU.
• Organiser chaque cache autour de la fraîcheur et de l’invalidation.
• Livrer des images adaptées et rendre la ressource LCP découvrable tôt.
• Mesurer JavaScript et tiers sur un téléphone modeste, pendant les interactions.
• Relier les lenteurs serveur au crawl, puis surveiller les gains en production.