Score Google PageSpeed - Webperf

Google propose des outils gratuits pour tester la vitesse de votre site web. Parmi eux, PageSpeed Insights. Si vous êtes ici, c’est que vous l’avez déjà sûrement essayé, et que vous êtes déçus de votre note. Le moteur de recherche se montre assez sévère lorsqu’il s’agit d’évaluer la performance des pages web, et nous allons voir pourquoi il considère que vos temps de chargement ne sont pas assez bons, et aussi, comment lire et relativiser ce score.

Comprendre le calcul du score PageSpeed

En rentrant tout simplement une URL dans PageSpeed Insights, Google calcule un score de performance compris entre 0 et 100 :

Page de résultat Google PageSpeed Inisghts

Page de résultats de Google PageSpeed Insights

Pour rappel, le moteur de recherche considère que :

  • de 0 à 49 : une page web est lente,
  • de 50 à 89 : une page web est moyennement rapide, 
  • de 90 à 100 : une page web est rapide.

Page Speed Insight score range

Mais comment ce score est-il établi ? Est-ce possible d’atteindre le graal : une note de 100 ?

Pour proposer ce score, Google se base sur l’un de ses autres outils : Lighthouse. Il faut savoir que les données sont collectées en simulant une navigation dans des conditions qui sont loin d’être optimales, et qui ne représentent pas forcément celles de vos utilisateurs réels. Plus précisément, dans PageSpeed Insights, le score Lighthouse est calculé par défaut comme si vos pages s’affichaient sur un mobile moyen de gamme en “Slow 4G”.

Ces conditions sont représentatives d’une moyenne pour l’ensemble de la population mondiale, toutes zones géographiques confondues, incluant les moins bien dotées en termes de qualité de réseau.
Pourtant, votre audience est certainement beaucoup plus locale, ou en tout cas concentrée sur quelques pays où l’essentiel de vos utilisateurs profite d’une qualité de réseau supérieure à de la Slow 4G. 

Idéalement, pour un score plus proche de votre réalité, PageSpeed Insights devrait détecter la localisation selon le nom de domaine (par exemple .fr) et proposer un calcul du score en fonction des conditions de navigation moyennes dans cette zone géographique au lieu du monde entier (en effet, rares sont les sites qui ont une audience sur 100 % du globe).

Pour vous aider à mieux comprendre l’impact de ces conditions de navigation sur le score Lighthouse, nous avons testé la même page web :

  • avec Lighthouse en simulant une connexion 4G en France sur un modèle Motorola G4 (le score est de 87) :
    Score Google PageSpeed Insights  : 87
  • et avec PageSpeed Insights (dans les conditions expliquées précédemment, et le score n’est alors que de 19) :

Score Google PageSpeed Insights : 19

La différence entre les résultats de ces deux tests est importante, et cet exemple illustre l’impact du choix (ou de l’absence de choix) des conditions de navigation sur ces scores de performance.

Ainsi, ce qu’il faut retenir en premier lieu, c’est que le score indiqué par Google est une photographie à un instant T dans des conditions de navigation définies par ses soins, qui ne sont pas les plus avantageuses pour traduire la vitesse réelle de vos pages web, et qui ne sont pas forcément représentatives des conditions de navigation de vos utilisateurs.

Mais alors, comment faire pour Google daigne considérer vos pages web comme rapides ?
Entrons dans les coulisses du calcul du score PageSpeed pour comprendre ce dont vous pouvez tenir compte pour optimiser la vitesse de vos pages, et aussi comment prendre du recul.

Dans les coulisses de PageSpeed Insights

En haut de la page de résultats, PageSpeed Insights affiche le score Lighthouse, établi dans les conditions que nous venons de détailler. Pour aller plus loin, sachez qu’il est calculé sur la base de 6 indicateurs dont il pondère l’impact comme suit : 

  • First Contentful Paint (15 %), qui évalue le moment où le navigateur rend le tout premier élément dans le navigateur ;
  • Speed Index (15 %), qui évalue la vitesse de chargement des éléments au-dessus de la ligne de flottaison ;
  • Largest Contentful Paint (25 %), qui évalue le temps qu’il faut pour que le plus grand élément visuel apparaisse dans le navigateur ;
  • Time To Interactive (15 %), qui évalue le temps nécessaire pour qu’une page web devienne interactive de façon durable et sans latence ; 
  • Total Blocking Time (25 %), qui additionne les temps de blocage d’une interface avant qu’elle ne devienne interactive de façon durable ;
  • Cumulative Layout Shift (5%), qui évalue la stabilité visuelle de la page.

Plus bas sur cette même page de résultats, l’outil détaille une sélection de métriques webperf qui mesurent différents aspects de la vitesse, réparties selon la façon dont elles sont récupérées :

  • des données sur la vitesse de chargement recueillies d’après l’expérience d’utilisateurs réels, que Google appelle “Field data” (données réelles) ;
  • des donnés sur la vitesse de chargement recueillies sur la base de navigations simulées (que avons vues ci-dessus, qui entrent dans le calcul du score Lighthouse), que Google appelle “Lab data” (données de laboratoire).

Google PageSpeed Inights : Field et Lab data

Les données Field et les données Lab ne sont pas récupérées de la même façon,
c’est pourquoi les mêmes indicateurs ne correspondent pas selon le mode de collecte

Dans le test ci-dessus, les données Field indiquent que, d’après les données du panel CrUX de Google, 75 % des utilisateurs ont un LCP inférieur à 3 secondes ; mais le LCP mesuré dans le cadre des données Lab (Lighthouse) est de 4,3 secondes. C’est une nouvelle illustration du fait que les données Lighthouse (et donc PageSpeed Insights) ne correspondent pas toujours à votre réalité.

Pour creuser davantage ce point, observons le First Input Delay (donnée réelle, ou Field) et le Total Blocking Time (équivalent du FID en donnée de laboratoire, nous y reviendrons un peu plus tard). 

Comme le mode de collecte est différent, bien qu’elles soient équivalentes, ces 2 métriques peuvent être très éloignées pour une même page, comme on le voit dans dans cet exemple :

Google PageSpeed Insights : Total Blocking Time et First Input Delay

Différence entre le FID et le TBT pour une même page testée avec PageSpeed Insights


Nous avons vu que le score Lighthouse est basé sur le TBT, et non sur le FID, et aussi que le TBT compte pour 25 % dans le calcul du score PageSpeed. De ce fait, si votre TBT est mauvais, l’impact sur votre score PageSpeed sera important.
Pourtant, sachez que le FID représente mieux l’interactivité et l’expérience réelle de vos utilisateurs. Pourquoi ?
Parce que le FID indique le moment où le navigateur est en mesure de répondre à une interaction de l’utilisateur ; alors que le TBT est une accumulation de périodes pendant lesquelles votre interface ne répond pas aux interactions. Mais ces périodes peuvent s’accumuler au début ou à la fin du chargement de vos pages web sans pour autant gêner l’utilisation ! 

Voyons en pratique l’impact de la prise en compte du TBT plutôt que du FID sur votre score PageSpeed.

Nous avons testé une page avec PageSpeed Insights, et elle obtient un score de 17. Le FID est de 87 ms, et le TBT est quant à lui de 4210 ms :

Google PageSpeed Insights : test du score Lighthouse

Puis nous avons repris les donnéeds de terrain (Lab) que nous avons intégrées dans l’outil Lighthouse Scoring Calculator (qui indique un score sans Slow 4G, donc) pour observer la note obtenue.
Pour ce test sur Lighthouse Scoring Calculator, nous avons utilisé les données du FID (87 ms) à la place du TBT (4210 ms). Et nous voyons que si PageSpeed Insights prenait en compte le FID au lieu du TBT, le score de cette page serait de 59 au lieu de 17 !

Total-Blocking-Time-Lighthouse-Scoring-Calculator

Voici un nouveau cas qui montre que Google note votre site dans des conditions particulièrement sévères, et que - encore une fois - le score obtenu ne traduit pas forcément la réalité de la majorité de vos utilisateurs, dont la qualité de réseau est probablement bien meilleure que celle simulée par Lighthouse pour PageSpeed Insights.

Toutefois, au-delà de la course au score PageSpeed, tout ce que vous pourrez faire pour optimiser chaque indicateur sur votre site restera bénéfique pour l’expérience utilisateur.

Par ailleurs, l’amélioration de vos Core Web Vitals est aussi un atout pour votre SEO, et il se trouve que 2 des métriques qui entrent dans le calcul du score Lighthouse sont des Core Web Vitals :

  • le Largest Contentful Paint, 
  • et l’équivalent du First Input Delay, le Total Blocking Time (si vous améliorez votre TBT qui est une donnée Lab, vous améliorez aussi votre FID qui est une donnée Field).

Le score PageSpeed est ainsi composé de différents indicateurs de vitesse qui traduisent chacun un aspect de l’expérience utilisateur.
Certains sont “faciles” à optimiser, et d’autres nécessitent une forte expertise. Si vous travaillez déjà sur vos temps de chargement, vous aurez peut-être même constaté qu’une optimisation peut améliorer un indicateur et en dégrader un autre simultanément. Pour éviter ce problème, sachez que notre moteur permet d’appliquer automatiquement les techniques d'optimisation de la vitesse tout en leur permettant de s’articuler intelligemment les unes par rapport aux autres.

Alors, maintenant que vous connaissez la recette du score PageSpeed Insights, voyons si tout est bon à prendre dans les recommandations que propose Google sur sa page de résultats. 

L’avis d’expert avec Anthony Barré, Software Engineer @ Fasterize

Notez que le score Lighthouse prend davantage en compte l’impact du JavaScript avec l'augmentation du poids du TBT et du TTI depuis la v6. Ainsi, des sites complexes tels que des sites e-commerce ont pu voir leur note baisser sans qu’il n’y ait eu de changement sur le site.

En effet, la note de Google pouvait être bonne au moment où l'interactivité était peu prise en compte dans le calcul de Lighthouse. Mais maintenant que le poids du TBT et du TTI ont augmenté, même si la vitesse d’affichage est bonne, si l’interactivité des pages n’est pas au rendez-vous, le score PageSpeed sera mauvais. En réalité, ce score est bien plus intéressant depuis la mise à jour de Lighthouse, c’est même l’un des plus avancés parmi les scores webperf.

Cela dit, il faut savoir que le score Lighthouse est étalonné par rapport aux millions de sites plus ou moins complexes qui font partie du panel CrUX de Google. On peut donc avoir l’impression d’un mauvais score, mais il faut tenir compte du fait qu’un site web est pris dans une comparaison avec d’autres sites sans aucune complexité (blogs, pages sans contenu riche…).
Or, une plateforme e-commerce fait appel à des services tiers pour enrichir l’expérience utilisateur (A/B test, chat, avis client, géolocalisation…). Ce type de site part donc avec une pénalité structurelle que Google ne prend pas en considération dans son analyse et ses recommandations (un site “riche” peut malgré tout obtenir un bon score PageSpeed dans l’absolu, mais cela nécessite une expertise poussée et des efforts conséquents et continus qu’il est préférable d’automatiser).

C’est pour cette raison qu’il est plus pertinent de comparer son score avec celui de ses concurrents, ou avec celui de sites web présentant le même niveau de complexité que le sien, et surtout, d’observer évolution du score PageSpeed dans la durée.

Par exemple, en observant le top 10 du classement webperf mobile du JDN à l’été 2020 pour la catégorie e-commerce, il est intéressant de constater que plus de la moitié de ces sites web a un score inférieur à 49 - donc considérés comme lent par Google. Aucun ne dépasse le score de 90 ! Cela permet de relativiser et de se situer par rapport à son écosystème.

Enfin, Il faut garder présent à l’esprit qu’on ne peut pas résumer la vitesse de pages web à une note, il faut observer différentes métriques pour comprendre vraiment les points d’achoppement et les leviers d’amélioration des performances.

Les recommandation de l’audit Google : ce qu’il faut faire pour améliorer son score PageSpeed (ou pas)

Vous l’avez compris, vous ne devez pas tout miser sur un simple score pour évaluer la vitesse de votre site.
Et qu’en est-il des conseils de Google pour accélérer vos pages web ? Ils sont aussi à prendre avec un peu de recul.
Certaines recommandations sont des basiques pour améliorer les temps de chargement, et des solutions SaaS, CDN, ou des plugins permettent de le faire automatiquement - et même mieux que si vous lanciez vous-mêmes des développements. D’autres, en revanche, nécessitent une intervention de votre part parce qu’elles sont difficilement automatisables.

Voici quelques exemples de ces recommandations Google qui doivent être appliquées avec précaution :

Servir des images dans des formats nouvelle génération 

C’est une recommandation intéressante, mais selon le nombre d’images à traiter sur votre site et la façon dont il est développé (version desktop / mobile, responsive, adaptatif), la mise en place peut être fastidieuse. Aussi, une même image compressée n’a pas besoin du même temps de décompression selon le contexte de navigation, notamment selon la puissance de l’appareil. Un plugin ou un outil de compression d’image peuvent vous aider ; et mieux encore : une solution d’optimisation du Frontend telle que Fasterize, pour compresser intelligemment de grands volumes d’images à moindre coût et servir la bonne taille d’image selon l’écran et le contexte de navigation. 

Sachez aussi que les gains estimés par Google dans son audit sont souvent bien au-dessus de la réalité. Il s’agit en fait d’une recommandation visant à pousser le format WebP que le moteur de recherche promeut depuis une dizaine d’année, mais sans grand succès puisque la compatibilité avec tous les navigateurs est récente. Le format Avif offrira des performances plus intéressantes.

Réduire l’impact du code tiers

C’est aussi une très bonne suggestion. Concrètement, votre site a certainement besoin de faire appel à des scripts tiers pour certaines fonctionnalités (chat, recherche, personnalisation du contenu, A/B Test, analytics…), et peut-être même que votre modèle économique en dépend (publicité). Mais comme leur nom l’indique, ces tiers viennent de l’extérieur et vous n’avez donc pas la main dessus. Le mieux est de prioriser vos scripts et de différer le chargement et l’exécution de ceux qui ne sont pas critiques pour le fonctionnement de la page. Des pages légères et des scripts optimisés vous permettent ainsi d’absorber au mieux le poids supplémentaire de ces Third Parties qui apportent de la valeur à votre site. Une gestion rigoureuse des tiers et un audit de l’utilité des scripts insérés à vos pages web devraient faire l’objet d’un travail par des équipes techniques en interne, dans la mesure où ce sont des tâches beaucoup plus difficilement automatisables. 

Précharger les demandes clés

On ne peut évidemment pas pré-charger toutes les ressources avec <link rel=preload>, car on créerait l’embouteillage qu’on souhaite justement éviter. Un navigateur définit déjà la priorité de chaque ressource, et modifier ces priorités peut créer l’effet inverse de ce qu’on souhaite. On peut en revanche appliquer ce préchargement aux fonts et à toute ressource critique pour la page. Il faut prévoir un travail de hiérarchisation au préalable (un conseil qui vaut pour l'application de toute bonne pratique webperf).

Pour conclure, vous pouvez considérer votre score PageSpeed comme un signal parmi d’autres, mais pas comme une note définitive de la vitesse de vos pages web à proprement parler. Google est d’ailleurs en recherche constante autour de ce score, au fur et à mesure de la découverte de nouvelles métriques.

Cela reste un outil intéressant et facile d’accès pour évaluer les performances de votre site, afin d’identifier dans les grandes lignes ce que vous devez optimiser à un instant T. En revanche, pour monitorer vos performances dans la durée, mieux vaut vous équiper d’outils dédiés au suivi de la webperf.

En somme, vous l’aurez compris, si vous avez un “mauvais score PageSpeed”, ça ne signifie pas forcément que votre site est lent pour absolument tous les utilisateurs dans tous les contextes. C’est le signe que vous devez travailler sur votre vitesse de chargement, et pour cela, il faut choisir intelligemment les métriques et les techniques sur lesquelles vous concentrer.

Pour comprendre en détail les principales métriques webperf,
comment les mesurer et les améliorer :

Téléchargez le livre blanc

 


Hello SMX Paris !