En juin 2021, Google va intégrer les Core Web Vitals dans son algorithme pour classer les résultats dans son moteur de recherche. Il s’agit d’un ensemble de 3 indicateurs décrivant 3 aspects de l’expérience utilisateur réelle sur une page web : Vitesse, Interactivité et Stabilité visuelle Découvrez comment sont mesurés ces 3 indicateurs et les optimiser dans une présentation d’Alexis Rylko pour SEMRush.

1. Core Web Vitals :
Comprendre,
Mesurer,
Optimiser
Alexis Rylko
pour
SEMRUSH

2. Les Core Web Vitals sont un ensemble de 3 indicateurs
décrivant 3 aspects de l’expérience utilisateur réelle sur
une page web : Vitesse, Interactivité et Stabilité visuelle.
Ils sont censés être intégrés dans l’algorithme de
classement de Google en juin 2021(pour l’instant).
Mais revenons un peu en arrière.

3. Analyser les performances web aujourd’hui c’est :
FCP SI
FMP TTI CLS
FCI DOMCLT FP
LCP PageSpeed
Insights
FID GTMetrix
FPLT Dareboost /
Fasterize
Lighthouse
WebPageTest
Pingdom
TTFB
Multitude d’indicateurs Multitude d’outils

4. Effet : « Metric & Tool Fatigue »

5. Sans oublier qu’il existe 2 méthodes de mesure des indicateurs
Données de laboratoire
(alias synthétiques)
Données de terrain
(alias field, RUM, réelles etc.)

6. Sans oublier qu’il existe 2 méthodes de mesure des indicateurs
Données de laboratoire
(alias synthétiques)
Données de terrain
(alias field, RUM, réelles etc.)
Sont collectées par votre navigateur ou le serveur de l’outil de
mesure.
Ne reflètent pas l’expérience réelle que vit l’internaute sur vos
pages car l’environnement de mesure n’est pas réel.
On peut voir très vite les effets de ses optimisations.
Certains indicateurs ne peuvent pas être mesurés en
conditions de laboratoire.
Facile à manipuler.
Sont collectées par les navigateurs de vos visiteurs Chrome,
Chromium, Android.
Stockées dans la BDD CRUX.
Reflètent l’expérience réelle vécue par les internautes sur vos
pages car prennent en compte des conditions de navigation
réelles.
Pour voir les résultats de vos optimisations, il faudra patienter
~28 jours.
Presque impossible à manipuler

7. Pour faire face à ce problème, les équipes de Google ont
proposé de se focaliser uniquement sur 3 indicateurs qui
sont les plus pertinents, les plus parlants et qui reflètent le
mieux l’expérience de l’internaute sur la page.
Ils les ont appelés les “Core Web Vitals” ou les “Signaux
Web Essentiels”.

8. Core Web Vitals : 3 indicateurs et leurs méthodes de mesure
75ème percentile
de pages vues
Méthodes de
mesure
Indicateurs

9. Les Core Web Vitals comme part des Page Experience Search Signals
https://developers.google.com/search/blog/2020/11/timing-for-page-experience

10. Les méthodes de mesure et outils
Données de laboratoire Données de terrain

11. Les rapports Core Web Vitals dans PageSpeed Insights
https://developers.google.com/speed/pagespeed/insights/?hl=fr
1. Données de laboratoire + données de terrain.
2. Avantage: il est possible d’accéder aux données de terrain
par page.
3. Faute de données de terrain par page – rapport de
synthèse pour le site entier (origine).

12. Chrome User Expérience Report (CRUX)
Public Google BigQuery project
• Database BigQuery gratuite (limites).
• Inclut les données pour 369 953 domaines distincts dans la
database FR.
• Affiche les données par domaine.
• Pour accéder aux performances réelles par page par url – utiliser
PageSpeed Insights.
• Se met à jour chaque 2ème semaine du mois.

13. Chrome User Expérience Report (CRUX) : Dashboard Data Studio
Montez votre propre dashboard de Core Web Vitals en quelques clics - https://g.co/chromeuxdash

14. Croiser CRUX avec d’autres datasets publics
Mars 2021: CRUX + HTTPArchive (Tous les pays)
Largest Contentful Paint moyen par CMS les plus populaires au monde

15. LCP – Largest Contentful Paint
Temps nécessaire au navigateur pour
afficher le plus grand élément visible dans
la fenêtre d'affichage à compter du début
de chargement de la page.
Vitesse

16. Quel élément peut être LCP ?
1. Image dans <img>.
2. L’élément <image> à l’intérieur de la balise <svg>.
3. Miniature de video.
4. Image de fond chargée via la function url() dans le CSS.
Largest Contentful Paint
1. En-tête
2. Paragraphe
3. Légende de l’image
4. Elément <li> d’une liste.
Image Texte

17. Comment savoir quel élément est identifié comme LCP ?
PageSpeed Insights
Lighthouse (dans Google Chrome)
Chrome DevTools > Performance > Timings

18. Le chargement de l’élément le plus large. Vraiment ?
1 2

19. Le chargement de l’élément le plus large. Vraiment ?
3
4

20. Le LCP – c’est plutôt la superficie occupée par un bloc dans le
code HTML que la largeur
(contrairement à ce que dit son nom).

21. Le chargement de l’élément en 1er écran. Vraiment ?
https://web.dev/unused-javascript/
#how-the-unused-javascript-audit-fails
https://web.dev/unused-javascript/
L’élément identifié comme LCP n’est pas toujours
l’élément se trouvant au-dessus de la ligne de flottaison
(1er écran), mais l’élément le plus grand visible à
l’internaute au moment où celui-ci arrive sur la page.

22. Comment optimiser le LCP ?
Si le LCP est une image:
1. Servir l’image de la taille appropriée
(images responsives).
2. Compresser l’image.
3. Utiliser le format d’image de nouvelle
génération (JPEG 2000, JPEG XR ou
WebP)
Si le LCP est un texte:
1. Compresser le texte (Gzip, Brotli).
1. Géographiquement :
• Utiliser des CDNs pour les images.
2. Dans le fil de chargement:
1. Ajouter le CSS critique en “inline” dans
<head>.
2. Retirer/différer les ressources qui bloquent
le chargement du LCP (JS & CSS).
3. Ajouter l’élément LCP (ou ceux qui
l’influencent) dans <link rel="preload">
(image, polices, styles, JS).
4. Utiliser HTTP/2 Push.
Mettre en place la mise en cache.
Utiliser un service-worker.
Utiliser rel="prerender“
(avec beaucoup de precaution).
2. Optimiser l’élément LCP
lui-même
1. Rapprocher l’élément LCP du
début de chargement
3. Accélérer les chargements
ultérieurs de l’élément LCP
1. Changer le focus sur un élément plus rapide.
2. Renoncer aux images de fond.
3. Concevoir le viewport plus simple.

23. Exemple 1: JDDM.fr
Le LCP c’est une image.
L’image est chargée avec
du lazy loading c’est-à-dire
que le chargement est
différé (reporté à plus
tard).
Ne pas charger l’image en
1er écran avec du lazy
loading permettra de la
rapprocher du début du
chargement de la page.

24. Exemple 2: Parents.fr
Données de laboratoire > Lighthouse
De nouveau, l’image la plus importante se charge avec le lazy loading.

25. Exemple 3: Francetvinfo.fr
Parfois, quand il n’y a pas de possibilités techniques d’optimiser le chargement de l’image, il est possible de changer le focus sur un élément
plus rapide par exemple du texte. Voyons cela sur l’exemple d’une page d’actualité sur Francetvinfo: quand le titre est long, il est souvent
considéré comme le LCP de la page :

26. Exemple 2: FranceInfo
Mais si on raccourcit le titre de manière que sa superficie devient inférieure à celle de l’image alors celle-ci qui devient le LCP et le temps de
chargement de LCP devient bien plus lent :

27. Exemple 3 : Semrush : Google Fonts
Sur la page mobile de https://fr.semrush.com/ le LCP identifié est l’en-tête, donc du texte. Pour commencer à le charger, le navigateur
attend la police qui est chargée directement depuis Google Fonts. Rapatrier les polices sur le même serveur hébergeant le site permettra
d’économiser un temps important nécessaire pour installer la connexion.

28. Délai entre le moment où un internaute interagit
pour la première fois avec votre page et le moment
où le navigateur répond à cette interaction.
Interaction = clic sur un lien, bouton etc.
Le plus souvent, la valeur FID affichée est
meilleure qu’en réalité. Il est pertinent de travailler
et améliorer plutôt le TBT (Total Blocking Time).
Interactivité

29. Qu’est-ce que le main thread (fil principal) ?

30. Qu’est-ce que le main thread (fil principal) ?
Pendant les périodes en rouge, le navigateur est tellement occupé
qu’il n’est pas capable de répondre aux interactions de l’internaute.

31. Long tasks dans Chrome DevTools
Pour identifier les périodes de surcharge du fil principal du navigateur, on analyse les long tasks (>50 secondes) :

32. Qu’est-ce qui charge le main thread ?
https://www.paypal.com/fr/home/ https://www.cdiscount.com/ https://www.lemonde.fr/

33. Comment identifier le code et les styles non-utilisés ?
Lighthouse:
Rapport de Couverture de
Google Chrome
( Ctrl +P > « Coverage »):

34. Comment améliorer le FID ?
1. Se débarrasser de longs tasks.
2. Splitter de gros fichiers JS en plus petits (code-splitting).
3. Différer le code qui n’est pas nécessaire pour dessiner la page au moment quand le
thread principal sera plus libre.
4. Privilégier les CSS et les possibilités natives des navigateurs au JS.
5. Ajouter des fils de chargement supplémentaires à l’aide des web workers.
6. L’objectif principal: faire de sorte que la page soit intéractive au plus tôt possible.

35. CLS – Cumulative Layout Shift
Somme totale des scores pour chaque
décalage de mise en page inattendu
survenu pendant toute la durée de vie
de la page.
Interaction = clic sur un lien, bouton
etc.
L’algorithme change souvent.
Problèmes de calcul sur les SPA,
pages avec des sessions longues.
Stabilité visuelle

36. Comment mesurer le CLS ?
Extension Web Vitals pour Chrome
Page Speed Insights
(attention, non pertinent, car ne mesure pas dans la
durée)
Option Layout Shift Regions
dans l’outil « Rendering » de Google Chrome

37. Exemple: Paypal.com

38. Exemple: Actu.fr
Un bon exemple sur Actu.fr : prévoir des
emplacements dédiés pour tout élément
chargé après le contenu principal :
widgets tiers, publicités et images.

39. Comment améliorer le CLS ?
Toujours réserver l’espace pour les éléments qui apparaissent après l’affichage du contenu principal (Publicités,
widgets tiers, images différées (lazy loading), iframe etc.)
1. Réaliser les animations par les moyens CSS (transform: translate()).
2. S’il faut fixer un élément (menu, sidebar), privilégier CSS et fonctionnalités natives du navigateur (position sticky)
au JS.
3. Veiller à ce que les actions sur hover et scroll ne fassent pas bouger le template.
4. Toujours renseigner les attributs width et height des images.
5. Utiliser les ads et les widgets tiers de la taille connue.

40. Le CLS va évoluer
https://web.dev/evolving-cls/

41. Core Web Vitals dans la Search Console
Le statut d’une page est égal à la performance
la plus faible d’un des indicateurs de Core Web
Vitals.

42. Expérience sur la page : dans la Search Console
Combien de vos pages respectent-elles toutes les
exigences des facteurs liés à l’expérience sur la page ?

43. CWV et Rankings: Qu’est-ce qu’on en sait?
Les données sont réparties par mobile et desktop et sont appliquées de manière appropriée au classement de recherche.
En d'autres termes si vous êtes sur une page mobile, le classement n'est impacté que par les données mobiles et même chose sur
ordinateur. (John Mueller, 15 décembre 2020)
At this time, using page experience as a signal for ranking will apply only to mobile Search (CWV FAQ, 3 décembre 2020).
“And the other thing is that relevance is still by far much more important.” (Jonh Mueller, 27 février 2021)
Nous commencerons à tenir compte de l'expérience sur la page dans nos systèmes de classement à partir de la mi-juin 2021.
Cependant, l'impact de l'expérience sur la page sur ces systèmes restera limité jusqu'à la fin du mois d'août (Blog Google
Developpers, 19 avril 2021).

44. Apport (possible) des indicateurs dans les Core Web Vitals
https://googlechrome.github.io/lighthouse/scorecalc/

45. MERCI !
QUESTIONS ?
Alexis Rylko, iProspect
@alekseo
aliaksei.rylko@iprospect.com