SEO : Performance mobile

‍

Faciliter l'accès au contenu mobile

‍

Aider les utilisateurs à trouver le contenu qu'ils souhaitent

‍

Alors que la majorité des pages comportent désormais du texte et du contenu lisibles sans avoir à recourir à Google, ce dernier a constaté que certaines de ces pages affichaient des interstitiels intrusifs.

‍

Si le contenu est présent sur la page et indexable par Google, il peut être masqué par un interstitiel. Cela peut frustrer les utilisateurs, qui se retrouvent dans l'incapacité d'accéder facilement au contenu qu'ils s'attendaient à voir en cliquant sur le résultat de la recherche.

‍

Les pages comportant des interstitiels intrusifs offrent une moins bonne expérience utilisateur que celles dont le contenu est immédiatement accessible. Ce problème peut se poser sur les appareils mobiles, dont les écrans sont souvent plus petits.

‍

Afin d'améliorer la recherche sur mobile, depuis le 10 janvier 2017, les pages dont le contenu est difficilement accessible depuis les résultats de recherche sur mobile peuvent être moins bien classées.

‍

Voici quelques exemples de techniques qui nuisent à l'accessibilité du contenu :

• Affichage d'une fenêtre contextuelle qui se superpose au contenu principal, dès que l'utilisateur accède à une page à partir des résultats de recherche ou lorsqu'il parcourt la page.
• Affichage d'un interstitiel autonome que l'utilisateur doit fermer avant d'accéder au contenu.
• Utiliser une mise en page dans laquelle la partie située au-dessus de la ligne de flottaison est affichée sous la forme d'un interstitiel autonome, mais où le contenu original est intégré sous la ligne de flottaison.

‍

Exemples d'interstitiels qui nuisent à l'accessibilité du contenu

‍

Voici un exemple de pop-up intrusif :

‍

‍

‍

‍

Voici un exemple d'interstitiel autonome intrusif :

‍

‍

‍

‍

En revanche, voici quelques techniques qui, utilisées de manière responsable, n'auront pas d'impact sur le classement Google :

• Les interstitiels qui semblent répondre à une exigence légale (par exemple, l'utilisation de cookies ou la vérification de l'âge).
• Les boîtes de dialogue de connexion sur les sites dont le contenu n'est pas publiquement indexable.
• Les bannières qui occupent un espace raisonnable sur l'écran et qui peuvent être facilement fermées.

‍

Exemples d'interstitiels qui n'auront pas d'impact sur le classement dans Google, s'ils sont utilisés de manière responsable

‍

Voici un exemple d'interstitiel pour l'utilisation de cookies :

‍

‍

‍

‍

Voici un exemple d'interstitiel pour la vérification de l'âge :

‍

‍

‍

‍

Voici un exemple de bannière qui utilise un espace raisonnable sur l'écran :

‍

‍

‍

‍

N'oubliez pas que ces signaux UX ne sont que quelques-uns des centaines de signaux utilisés pour déterminer le classement de Google. L'intention d'une requête de recherche reste un signal très important.

‍

Ainsi, une page peut être bien classée si elle a un contenu pertinent et de qualité. un contenu de qualité. Mais à pertinence égale des informations, une page présentant de mauvais signaux UX peut être moins bien positionnée par Google.

‍

Indicateur mobile de performance

‍

L'importance des indicateurs de base de Web Vitals

‍

‍

‍

‍

Comment la note de performance est-elle pondérée ?

‍

La note de performance est une moyenne pondérée des notes obtenues pour les indicateurs énumérés ci-dessous. Naturellement, les indicateurs les plus pondérés ont un effet plus important sur votre note de performance globale.

‍

‍

FCP

‍

Ce que mesure le FCP

‍

Le FCP mesure le temps, en secondes, qu'il faut au navigateur pour afficher le premier élément du contenu DOM après qu'un utilisateur a navigué sur votre page.

‍

Les images, les éléments <canvas> et les SVG de votre page sont considérés comme du contenu DOM ; tout ce qui se trouve dans une iframe n'est pas inclus.

‍

Ce tableau montre comment interpréter votre score FCP :

‍

‍

‍

‍

Comment améliorer votre score au FCP ?

‍

Le temps de chargement des polices est un point particulièrement important pour le FCP. Assurez-vous que le texte reste visible pendant le chargement de la police web, car les polices sont des fichiers volumineux qui prennent du temps à charger.

‍

Certains navigateurs masquent le texte jusqu'au chargement de la police, ce qui provoque un flash de texte invisible (FOIT). Pour éviter cela, affichez le contenu immédiatement aux utilisateurs en utilisant une police système.

‍

Affichez le texte immédiatement en utilisant font-display

Before After

@font-face { font-family : Helvetica ; } @font-face { font-family : Helvetica ; font-display : swap ; }

‍

font-display est une API permettant de spécifier la stratégie d'affichage des polices. swap indique au navigateur que le texte utilisant cette police doit être le navigateur que le texte utilisant cette police doit être affiché immédiatement à l'aide d'une police système. Lorsque la police personnalisée est prête, la police système est remplacée.

‍

Si un navigateur ne prend pas en charge l'affichage des polices, il continue à suivre son comportement par défaut pour le chargement des polices. Pour savoir quels navigateurs prennent en charge l'affichage des polices, cliquez ici.

‍

L’indice de vitesse

‍

Ce que mesure l'indice de vitesse

‍

L'indice de vitesse mesure la rapidité avec laquelle le contenu s'affiche visuellement pendant le chargement de la page.

Ce tableau montre comment interpréter votre score Speed Index :

‍

‍

‍

‍

Comment améliorer le score de votre Speed Index ?

‍

Si tout ce que vous faites pour améliorer la vitesse de chargement des pages améliorera votre score au Speed Index, la résolution de tout problème découvert par ces audits de diagnostic devrait avoir un impact particulier :

• Réduire l'impact du code tiers
• Réduire le JavaScript
• Réduire les feuilles de style CSS
• Veiller à ce que le texte reste visible pendant le chargement de la police web

‍

LCP

‍

Ce que mesure Largest Contentful Paint

‍

Le LCP indique le temps de rendu de la plus grande image ou du plus grand bloc de texte visible dans la fenêtre d'affichage, par rapport au début du chargement de la page. Ce tableau montre comment interpréter votre score LCP :

‍

‍

‍

‍

Quels éléments sont pris en compte ? Les types d’éléments pris en compte pour le PAFR sont :

• <img> éléments
• <image> éléments d’un élément <svg>
• <video> éléments
• Un élément avec une image d’arrière-plan chargée via la fonction url() (par opposition à un gradient CSS)
• Éléments de niveau bloc contenant du texte

‍

Quand le PAFR est-il signalé ? Les pages Web se chargent souvent par étapes, de sorte qu’il est possible que l’élément le plus important de la page change. Pour gérer ce changement potentiel, le navigateur envoie un LCP "PerformanceEntry" identifiant le plus grand élément de contenu dès que le navigateur a affiché la première image.

‍

Mais ensuite, après le rendu des images suivantes, il enverra une autre PerformanceEntry chaque fois que l’élément le plus grand change. Par exemple, sur une page contenant du texte et une image, le navigateur peut d’abord simplement rendre le texte, auquel cas il enverra une entrée LCP dont la propriété "element" fera probablement référence à un <p> ou à un <h1>.

‍

Plus tard, une fois le chargement de l’image terminé, une deuxième entrée LCP sera envoyée et sa propriété "element" référencera le <img>.

‍

Il est important de noter qu’un élément ne peut être considéré comme l’élément de contenu le plus important que lorsqu’il a été rendu et qu’il est visible par l’utilisateur. Les images qui n’ont pas encore été chargées ne sont pas considérées comme "rendues". Les nœuds de texte qui utilisent des polices web pendant la période de verrouillage des polices ne sont pas non plus rendus.

‍

Dans ce cas, un élément plus petit peut être considéré comme l’élément plus grand, mais dès que l’élément plus grand termine le rendu, il sera marqué avec un autre objet "PerformanceEntry".

‍

En plus du chargement tardif des images et des polices, une page peut ajouter de nouveaux éléments au DOM lorsque du nouveau contenu est disponible. Si l’un de ces nouveaux éléments est plus grand que l’élément de contenu précédent, un nouvel objet PerformanceEntry sera également marqué.

‍

Si un élément qui est actuellement le plus grand élément de contenu est supprimé de la fenêtre de visualisation (ou même du DOM), il restera le plus grand élément de contenu à moins qu’un élément plus grand soit rendu. Avant Chrome 88, les éléments supprimés n’étaient pas considérés comme le plus grand élément de contenu, et la suppression du candidat actuel a déclenché une nouvelle entrée LCP.

‍

Toutefois, en raison de modèles d’interface utilisateur populaires, comme les carrousels d’images qui suppriment souvent les éléments DOM, la mesure a été mise à jour pour mieux refléter l’expérience utilisateur.

‍

Le navigateur cessera de signaler les nouvelles entrées dès que l’utilisateur interagit avec la page (en tapant, en faisant défiler ou en appuyant sur la touche), car l’interaction de l’utilisateur change souvent ce qui est visible pour l’utilisateur (cela est particulièrement vrai avec le défilement). À des fins d’analyse, vous ne devez enregistrer que le dernier PerformanceEntry envoyé.

‍

Comment améliorer votre note du PAFR ?

‍

Le PAFR est principalement touché par les facteurs suivants :

• Lenteur des temps de réponse du serveur
• Rendu de blocage JavaScript et CSS
• Optimisation et compression des images
• Préchargement de ressources importantes
• Compression de fichiers texte
• Rendu côté client

‍

TIME TO INTERACTIVE

‍

Mesure du temps nécessaire à l’interactivité

‍

L’ITD mesure le temps nécessaire pour qu’une page devienne entièrement interactive. Une page est considérée comme entièrement interactive lorsque :

• La page affiche le contenu utile, qui est mesuré par le FCP
• Les gestionnaires d’événements sont enregistrés pour la plupart des éléments visibles sur la page, et
• La page répond aux interactions de l’utilisateur en 50 millisecondes.

‍

Ce tableau montre comment interpréter votre score TTI :

‍

‍

‍

‍

Comment améliorer votre score TTI ?

‍

L’TTI est principalement affecté par les facteurs suivants :

• Réduire l’impact du code tiers
• Minimiser le JavaScript
• Minimiser les SSC
• Lenteur des temps de réponse du serveur
• Rendu de blocage JavaScript et CSS
• Optimiser et compresser les images
• Précharge des ressources importantes
• Compresser des fichiers texte
• Rendu côté client

‍

Temps de blocage total

‍

Ce que mesure le temps de blocage total

‍

TBT mesure le temps total pendant lequel une page est bloquée pour répondre à la saisie de l’utilisateur, comme des clics de souris, des presses d’écran ou de clavier. La somme est calculée en ajoutant la partie bloquante de toutes les tâches longues entre FCP et TTI.

‍

Toute tâche qui dure plus de 50 ms est une tâche longue. Le temps écoulé après 50 ms est la partie bloquante. Par exemple, si Lighthouse détecte une tâche de 70 ms, la partie bloquante sera de 20 ms.

‍

Ce tableau montre comment interpréter votre score OTC :

‍

‍

‍

‍

Comment améliorer votre score TBT ?

‍

Consultez "Qu’est-ce qui cause mes longues tâches?" pour apprendre à diagnostiquer la cause de longues tâches avec le panneau Performance dans Chrome DevTools. En général, les causes les plus courantes des tâches longues sont :

• Chargement, analyse ou exécution inutiles de JavaScript. En analysant votre code dans le panneau Performance, vous découvrirez peut-être que le fil principal fait un travail qui n’est pas vraiment nécessaire pour charger la page. Réduire les charges utiles JavaScript en fractionnant le code, en supprimant le code inutilisé ou en chargeant efficacement des tiers JavaScript devrait améliorer votre score TBT.
  ‍
• Instructions JavaScript inefficaces. Par exemple, après avoir analysé votre code dans le panneau Performance, supposons que vous voyez un appel à document.querySelectorAll('a') qui renvoie 2000 nœuds. En refacturant votre code pour utiliser un sélecteur plus spécifique qui renvoie seulement 10 nœuds, vous devriez améliorer votre score TBT.

‍

CLS

‍

Le CCRS est une mesure importante et axée sur l’utilisateur de la stabilité visuelle, car il quantifie la fréquence à laquelle les utilisateurs subissent des changements de mise en page imprévus - un CCRS faible garantit que la page est agréable.

‍

Avez-vous déjà lu un article en ligne lorsque quelque chose change soudainement sur la page? Sans avertissement, le texte bouge, et vous avez perdu votre place. Ou pire encore : vous êtes sur le point d’appuyer sur un lien ou un bouton, mais au moment où votre doigt atterrit - BOOM - le lien se déplace et vous finissez par cliquer sur autre chose !

‍

La plupart du temps, ce genre d’expérience est juste ennuyeux, mais dans certains cas, il peut causer des dommages réels.

‍

Le déplacement inattendu du contenu d’une page est généralement dû au chargement asynchrone de ressources ou à l’ajout dynamique d’éléments DOM en plus du contenu existant. Il pourrait s’agir d’une image ou d’une vidéo de dimensions inconnues, d’une police qui rend plus grande ou plus petite que la police de sauvegarde, ou d’une annonce ou d’un widget tiers qui redimensionne dynamiquement.

‍

Ce qui rend ce problème encore plus problématique est que la façon dont un site fonctionne pendant le développement est souvent très différente de la façon dont les utilisateurs travaillent. Le contenu personnalisé ou tiers ne se comporte souvent pas de la même manière dans le développement qu’en production, les images de test sont souvent déjà dans le cache du navigateur du développeur, et les appels API qui s’exécutent localement sont souvent si rapides que le retard n’est pas perceptible.

‍

La mesure Cumulative Layout Shift (CLS) vous aide à résoudre ce problème en mesurant à quelle fréquence il se produit pour les utilisateurs réels.

‍

Ce que mesure le CLS

‍

Le CCRS est une mesure du plus grand décalage de mise en page, pour chaque décalage de mise en page inattendu, qui se produit pendant la durée de vie d’une page. Un décalage de disposition se produit chaque fois qu’un élément visible change de position.

‍

Une série de changements de mise en page, appelée fenêtre de session, se produit lorsqu’un ou plusieurs changements de mise en page individuels se produisent en succession rapide, avec moins d’une seconde entre chaque changement et un maximum de 5 secondes pour la durée totale de la fenêtre.

‍

L’éclatement le plus important est la fenêtre de session avec le score cumulatif maximum de toutes les modifications de mise en page dans cette fenêtre.

‍

Ce tableau montre comment interpréter votre score CLS :

‍

‍

‍

‍

Comment améliorer votre score CLS ?

‍

Les causes les plus fréquentes d’un CCRS médiocre sont les suivantes :

• Images sans dimensions
• Annonces, éléments embarqués et iframes sans dimensions
• Contenu injecté dynamiquement
• Polices Web entraînant FOIT/FOUT (Flash of invisible text (FOIT ) et Flash of Unstyled Text (FOUT)
• Actions en attente d’une réponse réseau avant de mettre à jour le DOM Pour la plupart des sites Web, vous pouvez éviter tous les changements de mise en page inattendus en suivant quelques directives :
• Ajoutez toujours des attributs de taille à vos images et éléments vidéo, ou réservez l’espace nécessaire en utilisant les "boîtes de rapport d’aspect CSS," par exemple. Cette approche garantit que le navigateur peut allouer la quantité correcte d’espace dans le document pendant le chargement de l’image. Notez que vous pouvez également utiliser la politique "unsized-media feature" pour appliquer ce comportement dans les navigateurs qui prennent en charge ces fonctionnalités.
• N’insérez jamais de contenu en plus du contenu existant, sauf en réponse à l’interaction de l’utilisateur, ce qui garantit que tout changement de présentation qui se produit est attendu.
• Préférez les animations de transformation aux animations de propriétés qui déclenchent des changements de mise en page. Animer les transitions pour fournir le contexte et la continuité d’un état à l’autre.