Premier délai d’entrée – Une explication simple

Le premier délai d’entrée (FID) est une mesure de l’expérience utilisateur que Google a introduite et qu’elle utilisera bientôt comme petit facteur de classement. Cet article offre un aperçu facile à comprendre du FID afin d’aider à donner un sens au sujet.

Le premier délai d’entrée est plus que d’essayer de plaire à Google. Les améliorations des performances du site entraînent généralement une augmentation des ventes, des revenus publicitaires et des prospects.

Définition du premier délai d’entrée

Le FID est la mesure du temps nécessaire à un navigateur pour répondre à la première interaction d’un visiteur du site avec le site pendant le chargement du site. Ceci est parfois appelé latence d’entrée.

Une interaction peut être en appuyant sur un bouton, un lien ou une touche et la réponse donnée en réponse. Les zones de saisie de texte, les listes déroulantes et les cases à cocher sont d’autres types de points d’interaction que FID mesurera.

Le défilement ou le zoom ne comptent pas comme des interactions car aucune réponse n’est attendue du site lui-même.

L’objectif de FID est de mesurer la réactivité d’un site pendant son chargement.

La cause du premier retard d’entrée

Le premier délai d’entrée est généralement causé par des images et des scripts qui se téléchargent de manière désordonnée. Ce codage désordonné provoque une pause excessive du téléchargement de la page Web, puis un démarrage puis une pause. Cela provoque un comportement insensible pour les visiteurs du site qui tentent d’interagir avec la page Web.

C’est comme un embouteillage provoqué par un free for all où il n’y a pas de feux de signalisation, ce qui provoque des accidents et des ralentissements. Le réparer, c’est mettre de l’ordre dans le trafic.

Google décrit la cause de la latence d’entrée comme suit:

«En général, le retard d’entrée (ou latence d’entrée) se produit parce que le thread principal du navigateur est occupé à faire autre chose, il ne peut donc pas (encore) répondre à l’utilisateur. Cela peut souvent se produire parce que le navigateur est occupé à analyser et à exécuter un gros fichier JavaScript chargé par votre application. Pendant ce temps, il ne peut pas exécuter d’écouteurs d’événements car le JavaScript qu’il charge peut lui dire de faire autre chose. »

Comment corriger la latence d’entrée

Étant donné que la cause première du premier délai d’entrée est le téléchargement désorganisé des scripts et des images, le moyen de résoudre le problème est de mettre de l’ordre dans la façon dont ces scripts et images sont présentés au navigateur pour téléchargement.

La résolution du problème du FID consiste généralement à utiliser des attributs HTML pour contrôler le téléchargement des scripts, à optimiser les images (le HTML et les images) et à omettre judicieusement les scripts inutiles. L’objectif est d’optimiser ce qui est téléchargé pour éliminer la pause typique et démarrer le téléchargement de pages Web non organisées.

Pourquoi les navigateurs ne répondent plus

Les navigateurs sont des logiciels qui effectuent des tâches pour afficher une page Web. Les tâches consistent à télécharger du code, des images, des polices, des informations de style et des scripts, puis à exécuter (exécuter) les scripts et à créer la page Web selon les instructions HTML.

Ce processus s’appelle le rendu. Le mot rendre signifie faire et c’est ce que fait un navigateur en assemblant le code et les images pour rendre une page Web.

Les tâches de rendu individuelles sont appelées threads. Le mot thread est l’abréviation de «thread d’exécution», ce qui signifie une séquence d’action individuelle (dans ce cas, les nombreuses tâches individuelles effectuées pour rendre une page Web).

Dans un navigateur, il existe un thread qui s’appelle un thread principal. Le fil principal est responsable de la création (du rendu) de la page Web que voit un visiteur du site.

Le fil principal peut être visualisé comme une autoroute dans laquelle les voitures symbolisent les images et les scripts qui sont téléchargés et exécutés lorsqu’une personne visite un site Web.

Certains codes sont volumineux et lents. Cela provoque l’arrêt des autres tâches et attend que le code volumineux et lent quitte l’autoroute (fin du téléchargement et de l’exécution).

Le but est de coder la page Web d’une manière qui optimise le code qui est téléchargé en premier, lorsque le code est exécuté, de manière ordonnée afin que la page Web se télécharge de la manière la plus rapide possible.

Ne perdez pas de sommeil avec un code tiers

En ce qui concerne les Web Vitals de base et en particulier avec le premier délai d’entrée, il existe du code sur lequel il n’y a pas grand-chose à faire. Cependant, c’est probablement le cas de vos concurrents.

Par exemple, si votre entreprise dépend de Google AdSense (un gros script de blocage de rendu), le problème sera le même pour votre concurrent.

Dans de nombreux cas, il peut suffire de faire de votre mieux car vos concurrents peuvent ne pas être en mesure de faire mieux non plus.

Donc, dans ces cas, il est préférable de prendre vos gains là où vous pouvez les trouver et de ne pas transpirer les pertes où vous ne pouvez pas faire de changement.

Impact de JavaScript sur le premier délai d’entrée

JavaScript est comme un petit moteur qui fait bouger les choses. Lorsqu’un nom est entré dans un formulaire, un code JavaScript peut être présent pour s’assurer que le prénom et le nom sont entrés. Lorsqu’un bouton est enfoncé, un JavaScript peut être là pour indiquer au navigateur de générer un message de remerciement dans une fenêtre contextuelle.

Le problème avec JavaScript est qu’il doit non seulement télécharger mais aussi s’exécuter (exécuter). Ce sont donc deux choses qui contribuent à la latence d’entrée.

Si un gros fichier JavaScript est situé près du haut de la page, alors ce fichier va empêcher le reste de la page en dessous de s’afficher (devenir visible et interactif) jusqu’à ce que le téléchargement et l’exécution du script soient terminés.

C’est ce qu’on appelle le blocage de la page.

La solution évidente est de déplacer ces types de scripts du haut de la page et de les placer en bas de la page afin qu’ils n’interfèrent pas avec tous les autres éléments de la page en attente de rendu.

Mais cela peut être un problème si, par exemple, il est placé à la fin d’une très longue page Web. La raison en est qu’une fois que la grande page est chargée et que l’utilisateur est prêt à interagir avec elle, le navigateur signalera toujours qu’elle est en cours de téléchargement (car le gros fichier JavaScript est en retard à la fin). La page peut se télécharger plus rapidement mais se bloquer en attendant que le JavaScript s’exécute.

Il y a une solution pour ça!

Attributs Defer et Async

Les attributs HTML Defer et Async sont comme des signaux de trafic qui contrôlent le début et l’arrêt du téléchargement et de l’exécution de JavaScript.

Un attribut HTML est quelque chose qui transforme un élément HTML, un peu comme l’extension de l’objectif ou du comportement de l’élément.

C’est comme si vous appreniez une compétence, cette compétence devenait un attribut de qui vous êtes.

Dans ce cas, les attributs Defer et Async modifient le comportement d’un fichier JavaScript.

L’un des changements importants est qu’ils indiquent au navigateur de ne pas interrompre le JavaScript. Ces attributs indiquent au navigateur de maintenir le thread principal en cours.

Les fichiers JavaScript seront téléchargés et traités indépendamment du fil de discussion principal, permettant au navigateur de rendre la page Web plus rapide.

Attribut asynchrone

Les fichiers JavaScript avec l’attribut Async seront téléchargés puis exécutés dès qu’ils seront téléchargés. Quand il commence à s’exécuter, c’est le point auquel le fichier JavaScript bloque le thread principal.

Normalement, le fichier bloque le thread principal lorsqu’il commence à se télécharger. Mais pas avec l’attribut async.

C’est ce qu’on appelle un téléchargement asynchrone, où il se télécharge indépendamment du thread principal et en parallèle avec lui.

L’attribut async est utile pour les fichiers JavaScript tiers tels que la publicité et le partage social, des fichiers dans lesquels l’ordre dans lequel ils sont exécutés n’a pas d’importance.

Attribut différé

Fichiers JavaScript avec le « reporterL’attribut ”sera également téléchargé de manière asynchrone.

Mais le fichier JavaScript différé ne s’exécutera pas tant que la page entière n’aura pas été téléchargée et rendue. Les scripts différés s’exécutent également dans l’ordre dans lequel ils se trouvent sur une page Web.

Les scripts avec l’attribut defer sont utiles pour les fichiers JavaScript qui dépendent des éléments de page en cours de chargement et du moment où l’ordre dans lequel ils sont exécutés est important.

En général, utilisez l’attribut defer pour les scripts qui ne sont pas essentiels au rendu de la page elle-même.

La latence d’entrée est différente pour tous les utilisateurs

Il est important de savoir que les scores du premier délai d’entrée sont variables et incohérents. Les scores varient d’un visiteur à l’autre.

La variance des scores est inévitable car le score dépend des interactions propres à l’individu visitant un site.

Certains visiteurs peuvent être distraits et ne pas interagir jusqu’à un moment où tous les actifs sont chargés et prêts à être interagis.

Voici comment Google le décrit:

«Tous les utilisateurs n’interagiront pas avec votre site à chaque visite. Et toutes les interactions ne sont pas pertinentes pour le FID…

De plus, les premières interactions de certains utilisateurs se produiront à des moments difficiles (lorsque le thread principal est occupé pendant une période prolongée), et les premières interactions de certains utilisateurs auront lieu à de bons moments (lorsque le thread principal est complètement inactif).

Cela signifie que certains utilisateurs n’auront aucune valeur FID, certains utilisateurs auront des valeurs FID faibles et certains utilisateurs auront probablement des valeurs FID élevées. »

Pourquoi la plupart des sites échouent au FID

Malheureusement, de nombreux systèmes de gestion de contenu, thèmes et plugins n’ont pas été conçus pour se conformer à cette métrique relativement nouvelle.
C’est la raison pour laquelle tant d’éditeurs sont consternés de découvrir que leurs sites ne passent pas le test du premier délai d’entrée.

Mais c’est quelque chose qui est en train de changer à mesure que la communauté de développement de logiciels Web répond aux demandes de normes de codage différentes de la communauté de l’édition.

Et ce n’est pas que les développeurs de logiciels qui créent des systèmes de gestion de contenu sont responsables de la production de produits qui ne sont pas à la hauteur de ces mesures.

Par exemple, WordPress a corrigé une lacune de l’éditeur de site Web Gutenberg qui lui faisait moins bien marquer qu’il ne le pouvait.

Gutenberg est un moyen visuel de créer des sites en utilisant l’interface ou la métaphore des blocs. Il y a un bloc de widgets, un bloc de formulaire de contact et un bloc de pied de page, etc.

Ainsi, le processus de création d’une page Web est plus visuel et se fait à travers la métaphore des blocs de construction, construisant littéralement une page avec différents blocs.

Il existe différents types de blocs qui se présentent et se comportent de différentes manières. Chaque bloc individuel a un code de style (CSS) correspondant, dont une grande partie est spécifique et unique à ce bloc individuel.

La méthode standard de codage de ces styles consiste à créer une feuille de style contenant les styles propres à chaque bloc. Il est logique de le faire de cette façon car vous avez un emplacement central où tout le code spécifique aux blocs existe.

Le résultat est que sur une page qui pourrait comprendre (disons) vingt blocs, WordPress chargerait les styles de ces blocs ainsi que tous les autres blocs qui ne sont pas utilisés.

Avant Core Web Vitals (CWV), qui était considéré comme le moyen standard de créer un package CSS.

Après l’introduction de Core Web Vitals, cette pratique est considérée comme un gonflement du code.

Ce n’est pas un reproche contre les développeurs WordPress. Ils ont fait un travail fantastique.

Ceci n’est que le reflet de la rapidité avec laquelle les normes en évolution peuvent se heurter à un goulot d’étranglement au stade du développement logiciel avant d’être intégrées dans l’écosystème de codage.

Nous avons vécu la même chose avec la transition vers la conception Web mobile first.

Gutenberg 10.1 Amélioration des performances

WordPress Gutenberg 10.1 a introduit un moyen amélioré de charger les styles en ne chargeant que les styles nécessaires et en ne chargeant pas les styles de bloc qui n’allaient pas être utilisés.

C’est une énorme victoire pour WordPress, les éditeurs qui s’appuient sur WordPress et bien sûr les utilisateurs qui visitent les sites créés avec WordPress.

Il est maintenant temps de corriger le premier délai d’entrée

Je pense que de plus en plus de développeurs de logiciels responsables du CMS, des thèmes et des plugins passeront à des pratiques de codage conviviales pour le premier délai d’entrée.

Mais jusqu’à ce que cela se produise, il incombe à l’éditeur de prendre des mesures pour améliorer le délai de première entrée. Le comprendre est la première étape.

Citations

Rapport d’expérience utilisateur Chrome

PageSpeed ​​Insights

Phare des outils de développement Chrome

Google Search Console (rapport Core Web Vitals)

Optimiser le premier délai d’entrée

Premier délai d’entrée

Mesures de performances centrées sur l’utilisateur

Script GitHub pour mesurer les valeurs vitales du Web principal