En bref
Le site sur lequel vous lisez ces lignes est passé de 73 à 99 sur PageSpeed mobile en une nuit. Six correctifs ont été posés, mesurés un par un. Deux n’ont rien changé et ont été retirés. C’est cette partie-là, celle que personne ne raconte, qui vaut le détour : sans mesure avant et après, ces deux modifications seraient encore en place aujourd’hui, à coûter quelque chose pour rien.
Et une fois le travail terminé, deux passages du même outil, sur le même site, à une minute d’écart, sans une ligne modifiée entre les deux, ont donné 96 puis 100.
Le point de départ, et ce qu’il disait déjà
Score de départ : 73. Le réflexe habituel consiste à lire ce chiffre et à demander « qu’est-ce qu’on optimise ». Le bon réflexe consiste à ouvrir la décomposition, parce qu’elle désigne le coupable avant qu’on ait touché à quoi que ce soit.
| Mesure | Valeur | Ce que ça dit |
|---|---|---|
| Blocage du fil principal | 0 ms | Le JavaScript n’est pas en cause |
| Stabilité de la mise en page | 0,004 | Rien ne saute à l’écran |
| Plus grand élément affiché | 3,7 s | Tout le problème est là |
| Vitesse d’affichage perçue | 10,1 s | Et il est sévère |
Deux mesures parfaites, deux mesures désastreuses. La lecture est immédiate : le site ne calculait pas trop, il attendait. Toute optimisation du JavaScript aurait été du temps perdu, sur un site déjà irréprochable de ce côté. C’est la première leçon, et elle est gratuite : la note ne se corrige pas, ses composantes si.
Les quatre correctifs qui ont payé
1. Les polices bloquaient l’affichage
Le thème chargeait ses deux familles de caractères depuis le service de polices de Google. Une pratique répandue, et longtemps recommandée. Le coût mesuré ici : 2 070 ms de blocage estimé, parce que le navigateur doit ouvrir deux connexions supplémentaires vers deux domaines extérieurs avant de savoir avec quelle police écrire.
Les fichiers ont été rapatriés sur le domaine du site, préchargés dans l’entête. À eux seuls, ils représentaient le poste le plus cher de tout l’audit.
2. Aucun en-tête d’expiration
Les sept fichiers statiques de la page d’accueil, feuilles de style, scripts, images, repartaient du serveur à chaque visite. Aucun ne portait d’instruction de mise en cache. Un visiteur qui revenait le lendemain retéléchargeait l’intégralité du site.
Trois lignes de configuration serveur ont réglé le sujet. C’est le correctif le moins spectaculaire de la liste, et probablement celui qui sert le plus aux visiteurs réels, qui eux ne découvrent pas le site à chaque page.
3. Du poids pour rien
| Élément | Avant | Après |
|---|---|---|
| Logo | 23,7 Ko, image de 1819 px affichée en 173 px | 4,8 Ko |
| Icône du site | 21,9 Ko pour afficher 32 pixels | 2,5 Ko |
| Détection d’émoji | 6,7 Ko sur chaque page | retirée |
Le logo est le cas d’école : un fichier de 1819 pixels de large servi pour un affichage de 173 pixels. Personne ne l’avait vu parce que rien ne casse. La page s’affiche, le logo est net, et le navigateur télécharge dix fois ce qu’il faut. L’icône du site raconte la même histoire : le fichier d’origine était déclaré tel quel pour les trois tailles demandées par les navigateurs, faute d’avoir généré ses déclinaisons.
4. Le contraste, qui n’est pas un sujet de performance
Tant qu’à mesurer, l’onglet accessibilité était à 96. Cinq éléments passaient sous le rapport de contraste minimum : un bouton d’appel à l’action en blanc sur la couleur de marque, à 3,96 pour 1 quand la règle demande 4,5, et quatre mentions de pied de page. Ratios calculés, pas jugés à l’oeil.
Un fond de bouton légèrement assombri et deux opacités remontées : accessibilité à 100, sans que la couleur de marque bouge nulle part ailleurs sur le site.
Le piège que seule la mesure pouvait trouver
Celui-là mérite son paragraphe, parce qu’aucun audit à l’oeil nu ne l’aurait attrapé.
Après avoir rapatrié les polices, le rapport signalait toujours un fichier de 14,5 Ko téléchargé sur le chemin critique. Un jeu de caractères étendu, celui qui sert aux langues d’Europe centrale, sur un site français et anglais. Cause réelle, trouvée en comparant les déclarations une par une : dans la feuille de style d’origine, la déclaration du jeu latin de base vient après celle du jeu étendu. En les réécrivant, cet ordre avait été inversé.
Or les deux plages de caractères se recouvrent, et quand deux déclarations couvrent le même caractère, c’est la dernière qui gagne. Résultat : le navigateur téléchargeait 14,5 Ko de police supplémentaire pour afficher un seul caractère, le « oe » de « mise en oeuvre », alors que le fichier déjà préchargé le contenait.
Une optimisation peut en créer une autre. Le seul moyen de le savoir est de remesurer après chaque modification, pas à la fin.
Les deux correctifs qui n’ont rien donné
Voici la partie que les études de cas passent sous silence.
Première fausse bonne idée : l’animation de la bannière de consentement. Elle couvre 40 % de l’écran sur mobile et apparaît avec une animation de 350 ms. L’hypothèse tenait debout : tant qu’elle n’est pas posée, l’écran n’est pas stable, donc la mesure d’affichage perçu en souffre. L’animation a été désactivée, deux mesures ont suivi. Résultat : aucun changement, à un dixième de seconde près. Retirée.
Deuxième fausse bonne idée : intégrer les feuilles de style dans la page. C’est la recommandation classique quand un outil signale des « requêtes bloquant le rendu ». Elle a été implémentée proprement, mesurée quatre fois. Les feuilles quittaient bien la liste des ressources bloquantes, l’alerte disparaissait du rapport, et aucune mesure ne bougeait : affichage du premier contenu, plus grand élément, vitesse perçue, tous identiques.
En échange, chaque page pesait 17,5 Ko de plus, puisque la feuille n’était plus mise en cache d’une page à l’autre. Sur un site où l’on lit plusieurs articles à la suite, c’est le mauvais côté du marché. Retirée aussi.
Ces deux modifications avaient trois points communs : elles étaient recommandées par un outil, elles semblaient logiques, et elles ne servaient à rien sur ce site précis. Sans mesure encadrant chaque geste, elles seraient encore en place, à coûter de la bande passante et de la dette de maintenance pour un bénéfice nul.
Ce que le score ne dit pas
Une fois le travail terminé, quatre passages de suite sur le même site, sans rien modifier entre eux :
| Passage | Score | Vitesse d’affichage perçue |
|---|---|---|
| 1 | 100 | 1,5 s |
| 2 | 97 | 4,2 s |
| 3 | 99 | 1,8 s |
| 4 | 97 | 4,2 s |
Même page, même minute, même code. L’écart vient d’un blocage d’affichage de deux secondes qui survient sur certaines mesures et pas sur d’autres, avec un profil réseau strictement identique. Ce n’est pas le serveur, ce ne sont pas les fichiers : c’est la mesure elle-même qui hésite. Le même piège existe ailleurs dans vos tableaux de bord : un chiffre qui s’affiche sans erreur n’est pas pour autant un chiffre juste.
Conclusion pratique, et elle vaut pour votre site autant que pour le nôtre : un passage isolé ne prouve rien. Relancer l’outil jusqu’à obtenir le bon chiffre est un exercice d’autosuggestion. Ce qui compte, c’est la médiane de plusieurs passages, et surtout ce que vivent vos visiteurs réels.
La méthode, applicable cette semaine
- Mesurez avant de toucher quoi que ce soit, et gardez la trace. Sans point de départ écrit, vous ne saurez jamais si vous avez amélioré ou dégradé.
- Lisez la décomposition, pas la note. Cinq mesures composent le score. Deux peuvent être parfaites pendant que les trois autres coulent. Elles ne se corrigent pas de la même façon.
- Une modification à la fois, une mesure après chaque. Trois correctifs posés ensemble donnent un résultat ininterprétable : impossible de savoir lequel a payé, ni lequel a nui.
- Retirez ce qui ne se voit pas dans les chiffres. Une optimisation sans effet mesurable n’est pas neutre : c’est du code en plus, à comprendre et à maintenir, pour toujours.
- Visez le visiteur, pas la note. Certains correctifs ne rapportent aucun point et changent la vie des gens sur un téléphone d’entrée de gamme. Dans notre cas, une animation qui tournait en boucle sans fin en arrière-plan a divisé par trois le travail du processeur, pour un seul point de score. La vitesse n’est d’ailleurs qu’une des frictions qui coûtent des conversions : le diagnostic page par page en recense d’autres, souvent plus rentables à corriger.
L’auto-diagnostic de cette semaine, sans outil ni développeur : ouvrez PageSpeed Insights sur votre page d’accueil, lancez la mesure trois fois de suite, et notez les trois scores. Si l’écart dépasse deux points, vous savez déjà que le chiffre que vous surveilliez ne méritait pas cette attention. Ouvrez ensuite la section des mesures détaillées et repérez laquelle est au rouge : c’est la seule information exploitable de la page.
Les approches du marché, et ce qu’elles valent
| Approche | Ce qu’elle donne | Pour qui |
|---|---|---|
| Extension de cache | Le meilleur rapport effort sur résultat sur la plupart des sites. Ne corrige rien de ce qui est mal construit | Tout le monde, en premier |
| Optimisation ciblée après mesure | Traite les causes réelles, une par une. Demande de savoir lire un rapport | Sites avec du trafic et un enjeu de conversion |
| Refonte technique | Règle tout, y compris ce qui n’était pas cassé. Coût sans commune mesure | Sites dont la structure est le problème |
| Ne rien faire | Défendable si vos mesures de terrain sont au vert | Sites sobres, déjà rapides |
Ces approches se combinent. Le cache d’abord parce qu’il coûte peu, la mesure ensuite pour savoir s’il reste quelque chose à faire, la refonte seulement quand les deux premières ont montré leurs limites.
L’outillage, et sa limite
Deux familles d’outils, souvent confondues. Les mesures de laboratoire, PageSpeed Insights et Lighthouse, simulent un téléphone milieu de gamme sur un réseau bridé. Elles sont reproductibles à peu près, disponibles tout de suite, et c’est là que se lisent les causes. Les mesures de terrain, celles que Google collecte auprès des vrais visiteurs de Chrome, ne mentent pas sur l’expérience vécue mais demandent du trafic pour exister, et regardent 28 jours en arrière.
La règle : le laboratoire pour diagnostiquer et corriger, le terrain pour décider si le sujet mérite qu’on s’en occupe. Un site dont les mesures de terrain sont au vert n’a pas de problème de vitesse, quel que soit le chiffre affiché par le laboratoire.
Aucun outil ne vous dira lequel de vos correctifs n’a servi à rien. Cette réponse-là ne s’obtient qu’en mesurant avant et après, à chaque geste. C’est le fond de notre métier sur la donnée et la performance : décider avec des chiffres, y compris quand ils disent que la modification ne sert à rien.
Ce que ça dit de plus grand
La performance web est devenue un domaine où l’on applique des recettes. Les listes de bonnes pratiques circulent, les extensions promettent de les appliquer d’un clic, et l’on finit par empiler des optimisations que personne n’a jamais vérifiées sur le site concerné. Deux sur six, dans notre cas, ne servaient à rien.
Le même travers touche l’analytics, le référencement et la publicité : on adopte ce qui se recommande, on ne mesure pas ce que ça donne, et la dette s’accumule en silence parce qu’aucune de ces décisions ne provoque de panne. Un site n’a jamais l’air cassé parce qu’il porte trois optimisations inutiles. Il est seulement un peu plus lourd, un peu plus difficile à faire évoluer, et un peu plus cher à maintenir, chaque mois.
Sources
- Calcul du score de performance Lighthouse, documentation Chrome for Developers
- Core Web Vitals, web.dev
- unicode-range, documentation MDN sur la sélection des jeux de caractères
- Mesures de cet article : Lighthouse 12, profil mobile, page d’accueil de dotsland.com, 11 et 12 août 2026
FAQ
Mon score PageSpeed change à chaque mesure, est-ce normal ?
Oui, et l’écart peut atteindre plusieurs points sans qu’une ligne de code ait bougé. Sur le site de cet article, quatre passages consécutifs ont donné 100, 97, 99 et 97. Lancez la mesure trois fois et retenez la médiane. Si vous voyez un écart de plus de deux points, ne tirez aucune conclusion d’un passage isolé.
Faut-il viser 100 sur 100 ?
Non. Le score est un indicateur de laboratoire, pas une mesure de ce que vivent vos visiteurs. Au-delà de 90, les points restants coûtent souvent plus cher en complexité qu’ils ne rapportent en vitesse réelle. Le seul objectif qui compte est que vos mesures de terrain, collectées auprès de vos vrais visiteurs, soient au vert.
Comment savoir si une optimisation a vraiment servi ?
En mesurant juste avant et juste après, sur la même page, sans rien changer d’autre entre les deux, et en répétant la mesure deux ou trois fois pour lisser la dispersion. Si les chiffres ne bougent pas, retirez la modification : du code qui ne sert à rien reste à maintenir indéfiniment.
Dotsland peut-il m’accompagner sur ce sujet ?
Oui. Nous mesurons l’existant, identifions les causes réelles plutôt que les recommandations génériques, et nous vous disons aussi ce qui ne vaut pas la peine d’être corrigé. Commencez par l’auto-diagnostic décrit plus haut, il prend dix minutes et vous saurez déjà si le sujet mérite un accompagnement. Parlons de votre projet.
Sur ces sujets de mesure et de visibilité, la fiabilité de la donnée est décisive. On s'appuie sur le tracking Server-Side DataFirefly pour une mesure durable, résiliente aux bloqueurs et aux restrictions cookies.