Quand PageSpeed Insights affiche « Analysis failed » ou tourne dans le vide, le réflexe classique c’est de spammer le bouton « Analyser ». Mauvaise idée. Tu perds du temps, tu n’apprends rien, et tu finis par confondre la santé de ton site avec la disponibilité d’un service externe.
PSI est pratique, mais ce n’est pas un socle. Si ton diagnostic perf dépend d’un outil instable, ton suivi Core Web Vitals est fragile par construction. Le but de ce papier, c’est de te donner un plan B concret, qui tient même quand PSI part en vrille.
Pourquoi PageSpeed Insights “échoue” (et pourquoi ce n’est pas toujours ton site)
On mélange souvent deux problèmes. Il y a le cas où ta page est vraiment trop lourde ou trop lente, et PSI n’arrive pas au bout. Et il y a le cas où PSI, côté infra, te lâche, te rate-limit, ou te renvoie une erreur générique. Dans les deux scénarios, ton écran dit « échec », mais la réponse à apporter n’a rien à voir.
Le pattern que je vois le plus souvent quand « ça échoue partout », c’est un mélange de timeouts et d’instabilité côté pipeline de test. Et quand ça passe enfin, tu découvres des temps absurdes, du genre 20–30 secondes de chargement. Là, oui, ton site a probablement un sujet, mais ton premier problème reste le même : tu ne peux pas investiguer proprement avec un outil qui se comporte comme une boîte noire capricieuse.
Autre cause fréquente, plus “site” que “tool” : une erreur runtime qui casse une partie du rendu ou des scripts au mauvais moment. La page “marche” pour toi parce que tu as du cache, une session existante, un navigateur qui a déjà tout préchargé, ou parce que tu ne touches pas le chemin de code qui explose. Le runner, lui, arrive à froid, sans contexte, et se prend une exception qui finit en échec d’audit.
Enfin, il y a les pages qui ne devraient pas être testées telles quelles. Pages avec auth, redirections bizarres, interstitiels, consentements qui bloquent, A/B tests agressifs, anti-bot trop strict. PSI n’est pas là pour “négocier” avec tes règles produit. Si ton parcours nécessite une interaction ou une session, PSI n’est déjà plus le bon outil pour dire une vérité stable.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Ton socle : séparer “lab” et “field”, sinon tu pilotes à l’instinct
Un diagnostic perf qui tient a deux jambes. La première, c’est la mesure “lab” que tu contrôles, reproductible, qui sert à faire du avant/après et à comprendre pourquoi. La deuxième, c’est la mesure “field” (terrain) qui décrit ce que vivent tes utilisateurs, sur leurs devices, leurs réseaux, leurs vrais parcours. PSI mélange les deux dans une UX sympa, mais cette UX ne doit pas être ton unique source de vérité.
Si tu veux arrêter de subir, tu dois pouvoir répondre à ces deux questions sans ouvrir PSI. Un, « est-ce que mon build a régressé ? ». Deux, « est-ce que les utilisateurs le ressentent vraiment ? ». À partir de là, PSI redevient ce qu’il aurait toujours dû être : un point d’entrée pratique, pas un juge de paix.
Plan B “lab” : Lighthouse local et Lighthouse CI (LHCI), pas un screenshot
Le moyen le plus simple de reprendre la main, c’est Lighthouse en local. Pas pour obtenir un score magique, mais pour obtenir une trace stable, relançable, comparable. Tu peux figer une config, une URL témoin, une stratégie de throttling, une fenêtre de test. Et surtout tu peux rejouer après une modification précise, sans dépendre d’un service.
Le cran au-dessus, c’est Lighthouse CI. Là, tu ne “fais pas un audit”. Tu industrialises une mesure. Tu peux faire tourner l’audit sur chaque PR, conserver un historique, détecter une régression, et surtout bloquer un merge quand tu exploses un budget. C’est brutal, et c’est exactement ce qu’on veut. Les perfs ne s’améliorent pas avec des bonnes intentions, elles s’améliorent quand la régression devient pénible.
// lighthouserc.js (exemple minimaliste, à adapter)
module.exports = {
ci: {
collect: {
url: [
'https://exemple.com/',
'https://exemple.com/produit/slug-temoin'
],
numberOfRuns: 3,
settings: {
preset: 'desktop'
}
},
assert: {
assertions: {
'categories:performance': ['warn', { minScore: 0.7 }],
'first-contentful-paint': ['warn', { maxNumericValue: 2500 }],
'largest-contentful-paint': ['warn', { maxNumericValue: 2500 }],
'cumulative-layout-shift': ['warn', { maxNumericValue: 0.1 }]
}
},
upload: {
target: 'temporary-public-storage'
}
}
};
Deux points importants pour éviter de se mentir avec Lighthouse. D’abord, choisis une “page témoin” qui représente ton vrai problème, pas une home vide qui score à 98. Ensuite, accepte que le lab est bruité. Fais plusieurs runs, regarde les tendances, et compare des changements isolés. Si tu changes le bundling, le cache, le rendu, et trois scripts tiers en même temps, tu ne sais plus ce que tu as amélioré.
Plan B “lab” bis : WebPageTest quand tu veux de la réalité (et des preuves)
Quand tu veux sortir du débat « ça marche chez moi », WebPageTest est souvent plus utile que PSI. Tu choisis une localisation, un device, un profil réseau. Tu obtiens une waterfall lisible, des timings, des films de rendu, et des résultats que tu peux partager sans passer 20 minutes à expliquer ce que PSI a “peut-être” fait en arrière-plan.
Je l’utilise surtout dans deux cas. Quand une page est lente “pour de vrai” et qu’on doit pointer du doigt ce qui bloque le rendu. Et quand on suspecte un script tiers de plomber le démarrage ou de générer du long task en cascade. WebPageTest ne règle pas tout, mais il a un talent rare : il te force à regarder les bytes, l’ordre de chargement, et les dépendances réelles. Pas les intentions.
La vérité produit : CrUX et RUM, parce que la perf n’est pas une moyenne de devs en fibre
PSI est séduisant parce qu’il affiche aussi des données terrain (quand elles existent). Mais tu n’as pas besoin d’ouvrir PSI pour lire le terrain. CrUX (Chrome UX Report) donne une vision agrégée par origine (ou URL selon les cas), et surtout sur une fenêtre de temps. C’est lent à bouger, et c’est très bien. Ça évite de paniquer sur un mardi matin parce qu’un test a eu un mauvais run.
Le vrai niveau au-dessus, c’est le RUM (Real User Monitoring) chez toi, sur ton produit, avec tes segments. Parce que « LCP dégradé » en moyenne, ça ne te dit pas si ce sont les Android bas de gamme, les pages produit, ou une route interne de SPA qui explose l’INP. Un RUM propre te permet de découper, de corréler avec une release, et de trouver le parcours qui fait mal.
// RUM minimal avec web-vitals (exemple)
import {onCLS, onINP, onLCP} from 'web-vitals';
function send(metric) {
navigator.sendBeacon(
'/rum',
JSON.stringify({
name: metric.name,
value: metric.value,
id: metric.id,
path: location.pathname,
navType: performance.getEntriesByType('navigation')[0]?.type
})
);
}
onCLS(send);
onINP(send);
onLCP(send);
Ce snippet ne fait pas tout, mais il met le pied à l’étrier. Derrière, tu veux ajouter un identifiant de release, un device hint, une segmentation (connectivité, pays), et un endpoint qui ne tombe pas. Et tu veux surtout un dashboard qui répond à une question simple : « est-ce qu’on s’améliore, ou est-ce qu’on se raconte une histoire ? »
Le triage reproductible quand PSI ne sort rien : une page témoin, puis l’isolement
Quand PSI échoue, ton objectif n’est pas de “réussir PSI”. Ton objectif est de comprendre si tu as un problème de performance, un problème de stabilité JS, ou un problème d’accès au contenu (redirections, consentements, protections). Le triage doit être mécanique.
Je commence par figer une page témoin testable sans interaction, sans login, sans dépendre d’un état utilisateur. Si je n’ai pas ça, je la crée, quitte à ajouter une route dédiée en environnement de staging. Sans page témoin, tu ne peux pas prouver une amélioration. Tu peux seulement débattre.
Ensuite j’isole. Je veux savoir ce que fait le cœur du produit, sans le bruit. Les scripts tiers sont les suspects numéro un, pas parce qu’ils sont “mal” mais parce qu’ils échappent à ta maîtrise et qu’ils changent sans prévenir. Tu peux les désactiver via un flag (idéal), via un environnement “audit”, ou en les conditionnant sur un consentement explicite. L’idée est simple : si sans tiers tout va mieux, tu as une piste exploitable et un plan d’action réaliste.
Et pendant que tu isoles, tu vérifies les bêtises qui coûtent cher. Une boucle de redirection, une page qui fait 12 Mo parce qu’un carrousel embarque 15 images en full, un bundle qui a doublé suite à une dépendance importée “pour un helper”. Ce n’est pas glamour. C’est souvent ça.
Budgets perf : le seul truc qui évite les rechutes silencieuses
Un audit ponctuel, même bien fait, ne te protège de rien. Les régressions arrivent quand personne ne regarde. Quand le tracking ajoute un tag. Quand le design demande une police variable de plus. Quand un composant React se met à rerender en boucle après une refacto “sans impact”.
Les budgets sont la barrière. Pas forcément des budgets ultra stricts dès le départ, sinon tu vas te mettre tout le monde à dos. Mais des seuils cohérents, alignés avec ton produit, et surtout visibles. Un budget sur le LCP, un budget sur le CLS, un budget sur la taille des assets critiques. Et si tu peux, un budget sur le temps CPU après interaction, parce que l’INP se détruit souvent sur des pages “déjà chargées”.
Automatiser les garde-fous : CI, historique, et alerting (sinon tu vas oublier)
Le nerf de la guerre, c’est la répétition. Lighthouse CI dans la CI te donne un signal à chaque PR. Un RUM te donne le terrain en continu. WebPageTest te donne l’enquête quand tu dois convaincre ou débugger en profondeur. Avec ça, PSI devient optionnel. Utile, mais optionnel.
Le détail qui change tout, c’est l’historique. Sans historique, tu ne sais pas si tu as une tendance ou juste un mauvais run. Sans historique, tu ne sais pas quand ça a commencé. Et sans “alerting”, tu découvres les problèmes quand ton support te remonte « le site est lent » ou quand ton SEO te dit que les CWV sont passés en orange.
Si je dois résumer mon avis, assez sec : la perf n’est pas un score, c’est une discipline d’observabilité. Tant que ta mesure dépend d’un outil externe qui peut tomber, tu ne fais pas de la perf. Tu fais du screenshot.
