SEO : Impact de la vitesse des pages sur le positionnement

Nous l’avons déjà vu le temps de chargement peut contribuer à un bon référencement naturel. Nous allons ici, nous attarder sur l’impact de la vitesse des pages sur le positionnement via les indicateurs FCP et FID, Dont certains webmasters ont découvert l’existence avec la fonctionnalité “Vitesse” de la Google Search Console.

Les pages considérées comme lentes peuvent être rétrogradées dans la recherche Google

C’est ainsi que Google introduit sa page d’aide sur le “Rapport sur la vitesse de vos pages”. On comprendra assez facilement que les pages étant identifiées comme “Lente” dans Google Search Console, doivent théoriquement être corrigées en priorités.

Google a initié une nouvelle fonctionnalité expérimentale : “Vitesse” qui synthétise l’expérience des utilisateurs de Chrome sur votre site. Toutes les pages récoltant suffisamment de données sont présentées dans le rapport. Les pages sont regroupées par “Type d’URL” (également appelés “groupes d’URL“), chaque type correspondant à des “scores” similaires au niveau du chargement. Une classification est effectuée autour de 3 états de vitesse : Lente, Moyenne, Rapide pour chacun des types d’appareils (à ce jour : mobile et ordinateur).

  •  
  • FCP
  • FID
  • Rapide
  • Inférieur à 1 sec.
  • Inférieur à 100 ms
  • Moyenne
  • Inférieur à 3 sec.
  • Inférieur à 300 ms
  • Lente
  • >= 3 sec.
  • >= 300 ms

On retrouve dans cette fonctionnalité deux indicateurs qui vont être détaillés ici. Nous analyserons également l’utilité de cet outil et quels recommandations SEO il peut induire.

FCP (First Contentful Paint)

Le “First Contentful Paint” c’est le “délai entre le moment où l’internaute essaie d’accéder à l’URL et le moment où le navigateur affiche le premier élément visible sur la page correspondante.

Cet indicateur est à ne pas confondre avec le “First Meaningful Paint” qui mesure le moment où le contenu principal d’une page est visible.

Pour imager le propos, sur l’image ci-dessous, il faudrait idéalement qu’il n’y ait pas de case blanche :


Capture d’écran du test Google PageSpeed Insights qui simule l’affichage de différent timing au chargement d’une page Web

FID (First Input Delay)

Le “First Input Delay” c’est le “délai entre le moment où un internaute interagit pour la première fois avec votre page (moment où il clique sur un lien, appuie sur un bouton ou autre) et le moment où le navigateur répond à cette interaction, quel que soit l’élément interactif sur lequel il a cliqué en premier.” et précision dans un article dédia au FID (extrait traduit de l’anglais) “Généralement, l’input delay est dû au fait que le thread principal est occupé à faire quelque chose d’autre, donc il ne peut pas (pour l’instant) répondre à l’utilisateur. Une raison commune, est potentiellement que le navigateur est occupé à parcourir et à exécuter un fichier Javascript volumineux chargé par l’application.” Dans ces cas là, il peut y avoir un délai entre l’action (exemple : clic) et l’effet (exemple : “ouverture” de la page).

Schéma explicatif du FID

Comment optimiser ces deux critères ?

Pour optimiser le FCP et le FID on peut :

  • FCP : diminuer le délai entre la réponse du serveur et l’affichage du premier contenu (idéalement du contenu utile). Bien souvent cela reviendra à différer le chargement des fichiers Javascript, retirer les traitements inutiles (JS ou CSS) et à diminuer au minimum utile les ressources bloquantes.
  • FID : diminuer l’activité du thread principal pour le rendre disponible aux actions utilisateurs le plus tôt possible, diminuer le temps d’exécution nécessaire au bon chargement des éléments interactifs de la page.

“Délai avant interactivité” (TTI) et “First CPU Idle”

Ces deux indicateurs ne sont pas intégrés à la fonctionnalité “Vitesse” de la Google Search Console, mais ils sont dans le cadre d’une analyse assez complémentaires. Ils sont tous les deux accessibles via l’outil Google PageSpeed Insights.

Le “Délai avant interactivité” (TTI) est le délai durant lequel la page n’est pas complètement interactive. Il est notamment utile pour compléter le FID, en cela qu’il permet de détecter un temps durant lequel l’utilisateur peut faire face à des indisponibilité de certaines fonctionnalités. Contrairement au FID il n’est pas dépendant d’une action de l’internaute sur le navigateur.

Le “First CPU Idle” “marque la première fois que le thread principal de la page est suffisamment silencieux pour gérer l’entrée“. Autrement dit il est le délai théorique minimal pour la gestion d’une action utilisateur.

Que se passe-t-il lorsqu’une page est supprimée du site ?

S’il y a une suppression de page : “Les URL qui ont été supprimées du Web et qui n’ont pas collecté de données au cours des 28 derniers jours n’apparaissent plus dans l’historique de validation ni dans le rapport.” Un fonctionnement assez logique lorsqu’on sait que pour obtenir ces indicateurs Google a besoin des internautes utilisant Chrome, si la page n’existe plus, elle n’est plus chargée, si elle n’est plus chargée, il n’y a plus de remontée de données.

A quoi sert l’outil Vitesse de la Search Console ?

Avec cette nouvelle fonctionnalité, il est possible de suivre plus facilement l’évolution de ces indicateurs et de suivre l’état des URL après correction. Une fois les modifications effectuées, il est possible de soumettre la correction à l’outil.

“Une fois que vous avez résolu un problème de vitesse spécifique au niveau de toutes vos URL, cliquez sur Démarrer le suivi pour initier une session de surveillance de 28 jours et vérifier ainsi s’il reste des occurrences de ce problème sur votre site. Si le problème n’est détecté dans aucune URL de votre site au cours de cette période de 28 jours, celui-ci sera considéré comme résolu.”
Dans le cas contraire, les pages “corrigées” seront retirées du groupe d’URL et celles restantes permettront la mise à jour.

Il s’agit d’un complément à l’outil Google PageSpeed Insights et à Chrome Lighthouse.

Ce rapport est similaire aux autres rapports d’erreur de la Google Search Console. La navigation se fait par : Device (Mobile et ordinateur), puis par Type de problème et enfin par Groupe d’URL.

Une fois sur le dernier niveau on obtient la liste des groupes d’URL avec pour chacun 1 URL en exemple (apparemment celle qui présente le plus de données) et au clic sur celle-ci on peut obtenir 20 URL “exemples” supplémentaires. Pour chaque groupe on a également le nombre d’URL similaires et le FID agrégé (ou FCP agrégé). Le tout exportable en CSV (sauf la liste de 20 URL “exemples”. Ajoutons à cela des raccourcis bien pratiques, vers le test Google PageSpeed.

On notera qu’il est dommage de ne pas pouvoir (au moment où sont rédigées ces lignes), rechercher une URL précise au sein d’un groupe d’URL, ou que ce rapport (comme d’autres rapports d’erreurs) ne soit pas intégré lors de l’analyse d’une URL.

A noter également :

  • Cet outil permet de mettre en lumière d’éventuelles faiblesses au niveau du chargement mobile, vu l’importance de ce support de nos jours, il est important de travailler sur l’optimisation de l’expérience utilisateur,
  • Le délai de 30 jours donne des potentiellement des indices sur la nécessité algorithmique de Google d’agréger suffisamment de données significatives sur une page pour la réévaluer. La durée de réévaluation d’une page pouvant bien sûr être inférieure,
  • Des différences importantes peuvent permettre de relever la défaillance de certains templates, et dans le cas contraire, on pourra effectuer des modifications plus globales sur le site dans l’objectif d’impacter un grand nombre de pages.


Ce site web utilise des cookies afin d'optimiser l'expérience utilisateur. En naviguant sur le site, vous acceptez l'usage de ces cookies.

Accepter
En savoir plus
X