121 mesures Core Web Vitals : mes deux meilleures hypothèses rejetées
La concaténation CSS a dégradé le TBT de 76 à 372 ms. Le report AJAX de 64 à 265 ms. Le vrai coupable était la stack publicitaire. Rapport de 9 séries de tests.
👁 124 lectures
Nous avons optimisé ce site pendant plusieurs jours, en effectuant une série de mesures Lighthouse après chaque modification au lieu d’un seul test. Le résultat fut humiliant : deux de nos meilleures hypothèses se sont révélées nuisibles, et nous n’avons trouvé le vrai coupable qu’en cessant de croire à un résultat unique. 121 mesures en neuf séries. Voici ce qui en est ressorti.
Trois conclusions en un paragraphe
1. Une seule mesure Lighthouse ne signifie rien - la même URL nous donnait des résultats de 60 à 96 points sans aucune modification du code. 2. La concaténation des fichiers CSS en un seul, conseil de tous les tutoriels, a dégradé le TBT de 76 à 372 ms. 3. Le responsable de la dispersion n’était pas notre code, mais la stack publicitaire - après blocage des domaines publicitaires, le résultat s’est stabilisé à 77/77 avec une dispersion FCP de 0,7% au lieu de 22%.
Liste actuelle des formations IA
Compilation mise à jour automatiquement une fois par jour : prix, nombre de cours et notes directement depuis le catalogue du vendeur. Nouveautés et meilleures ventes en haut.
Ouvrir la compilation →
Règle zéro : mesurez une série, pas un seul test
Cela semble banal, mais presque personne ne le fait - et c’est pourquoi presque toutes les « optimisations » sur Internet relèvent du hasard.
Nous avons lancé Lighthouse dix fois de suite sur une URL inchangée. Les résultats ont varié de 60 à 96 points. Si nous avions modifié quoi que ce soit dans le code et obtenu un test à 96 après modification et 60 avant, nous aurions proclamé le succès. Si l’inverse s’était produit, nous aurions annulé une bonne correction.
Conseil pro : minimum cinq tests par variante, comparez les médianes et indiquez toujours la plage complète. Si les plages avant et après se chevauchent, vous n’avez pas de résultat - vous avez du bruit.
Hypothèse 1, rejetée : concaténation CSS en un seul fichier
Conseil classique : moins de requêtes HTTP, donc combinez les feuilles de style. Nous avons construit un bundle à partir de plusieurs fichiers CSS du thème, vérifié la validité des chemins relatifs et l’ordre des imports, puis déployé. Mesure :
| Indicateur sur la page d’article | Avant | Après concaténation |
|---|---|---|
| TBT (blocage du thread principal) | 76 ms | 372 ms |
| Temps styleLayout | 700 ms | 1018 ms |
Pourquoi cela n’a pas fonctionné : cinq feuilles de style séparées représentent cinq tâches courtes d’analyse que le navigateur peut entrelacer avec d’autres. Une seule feuille de 69 KB constitue une longue tâche qui ne peut être interrompue - et les longues tâches sont précisément ce que mesure le TBT. Nous avons réduit le nombre de requêtes et dégradé la perception de fluidité.
Conseil pro : avec HTTP/2, le nombre de requêtes a cessé d’être un problème. La concaténation de fichiers est un conseil de l’époque HTTP/1.1 et peut aujourd’hui nuire.
Hypothèse 2, rejetée : report des requêtes en arrière-plan
La page boutique envoyait plusieurs requêtes AJAX au démarrage. Nous les avons reportées via requestIdleCallback avec une limite de temps de 3000 ms - solution de manuel. Mesure :
- TBT de la boutique : 64 ms → 265 ms
- Le démarrage des requêtes est passé de l’intervalle 183-1329 ms à 383-2411 ms
Pourquoi cela n’a pas fonctionné : la limite de temps de 3000 ms a fait que le navigateur a déclenché toutes les requêtes reportées en une seule série - et précisément dans la fenêtre où le TBT est calculé. Au lieu de répartir le travail, nous l’avons concentré en un seul embouteillage.
Conseil pro : requestIdleCallback avec une courte limite de temps n’est pas « fais-le plus tard ». C’est « fais-le plus tard, mais certainement ». Sans limite ou avec une très longue, il se comporte différemment.
Ce qui a fonctionné et pourquoi
Une ligne qui a éliminé 70 ms de recalcul forcé de mise en page
Le script lisait la position d’un élément et la modifiait immédiatement. Cela provoque un recalcul forcé de mise en page - le navigateur doit tout interrompre et calculer la géométrie de la page. Lighthouse indiquait 70-75 ms sur une seule ligne.
La correction tient en une ligne :
if (window.requestAnimationFrame) requestAnimationFrame(place); else place();
La lecture est transférée au moment où le navigateur recalcule de toute façon la mise en page. Le coût tombe à zéro, et le code fait exactement la même chose.
Retrait du chemin critique de ce que la page n’utilise pas
La feuille de style des templates pesait 75 094 octets et se chargeait sur chaque sous-page, bien que la plupart des pages n’utilisent aucun de ces templates. La version de base fait 9 708 octets - soit 87% du poids pour rien. De même pour jQuery, chargé malgré l’absence de tout consommateur.
Conseil pro : avant de minifier, vérifiez si le fichier est même nécessaire sur cette page. La suppression bat la compression tous les jours.
Le vrai coupable : la stack publicitaire
Après avoir rejeté les deux hypothèses, nous avons posé une autre question : d’où vient la dispersion de 60-96 points. Nous avons bloqué les domaines publicitaires et de consentement et répété la série :
| Avec publicités | Sans publicités | |
|---|---|---|
| Score de performance | 60-96, bipolaire | stable 77/77 |
| Dispersion FCP | 22% | 0,7% |
| TBT | variable | 0 |
| Poids de la stack | 445-467 KB | |
La conclusion fut brutale : pendant plusieurs jours, nous avons optimisé du code qui ne représentait qu’une fraction du problème. La dispersion provenait de scripts externes sur lesquels nous n’avons aucun contrôle et que nous ne supprimerons pas, car ils financent le site.
Conseil pro, le plus important de tout l’article : avant d’optimiser quoi que ce soit, mesurez combien du résultat provient de vous et combien de scripts externes. Faites une série avec les domaines tiers bloqués. Si la différence est importante, votre plafond réel est bien plus bas que vous ne le pensez - et mieux vaut le savoir avant trois jours de travail qu’après.
Deux pièges d’outils rencontrés en cours de route
Pingdom peut mentir sur la compression
Le rapport affirmait que le serveur ne compressait pas les réponses. Nous avons vérifié directement : le serveur envoie br et zstd, et quand on demande explicitement gzip, il renvoie la page d’accueil en 71 306 octets au lieu de 289 394 non compressés. L’outil ne déclarait simplement pas la prise en charge des algorithmes plus récents. Les en-têtes d’expiration étaient également en place.
Vider tout le cache peut casser l’apparence
Le plugin vidait à chaque publication tout le cache y compris les fichiers CSS minifiés. Dans la fenêtre entre la suppression et la reconstruction, la page pointait vers une feuille de style qui n’existait pas - et s’affichait momentanément en HTML brut. Avec une dizaine d’articles par jour, cela arrivait régulièrement.
Conseil pro : après publication d’un article, videz ponctuellement - l’article lui-même, la page d’accueil, ses catégories et le flux RSS. Un nouvel article ne change pas le contenu du fichier CSS, donc aucune raison de le supprimer.
Liste de contrôle si vous voulez reproduire cela chez vous
- Faites dix mesures sur une page inchangée. Notez la médiane et la plage. C’est votre bruit.
- Répétez la série avec les domaines externes bloqués. La différence est le plafond de vos possibilités.
- Seulement maintenant, changez une chose à la fois et mesurez en série, pas avec un seul test.
- Si les plages avant et après se chevauchent - annulez la modification. L’absence de preuve n’est pas une preuve.
- Commencez par supprimer, pas par minifier. Un fichier qui n’existe pas est toujours le plus rapide.
- Cherchez les recalculs forcés de mise en page. Ils peuvent valoir 70 ms pour une ligne de correction.
D’où viennent ces chiffres
Toutes les valeurs proviennent de 121 mesures Lighthouse en neuf séries, effectuées sur ce site les 18-19 septembre 2026 sur quatre types de pages : accueil, article, revue et boutique. Les deux hypothèses rejetées ont été déployées en production, mesurées et annulées. Ce n’est pas une compilation de conseils d’autrui - c’est un rapport de ce qui a fonctionné et ce qui n’a pas fonctionné chez nous.
More on this from PROMPTIF
guides·Warp : guide complet du terminal avec agent IA intégréWarp est un terminal avec agent IA intégré : décrivez ce que vous voulez faire et l'agent propose la commande. Voici comment l'utiliser au quotidien.