Une introduction aux technologies facilement accessibles.
Pourquoi la vitesse de chargement des pages est-elle importante ?
La plupart des utilisateurs considèrent régulièrement les lenteurs de chargement des pages comme étant une source majeure de frustration (54% d'entre eux selon une étude menée par Google). Il ne faut donc pas s'étonner qu'un chargement plus rapide des pages donne de meilleurs résultats pour une entreprise. En effet, si les visiteurs sont frustrés avant même d'interagir avec un site Web, il est très peu probable qu'ils restent assez longtemps pour apprécier sa valeur. Une autre étude Google menée auprès de 254 sites d'e-commerce, de finance et de voyages a montré que les sites qui se chargent en deux secondes ou moins avaient des taux de conversion 15% plus élevés.
Accélérer le LCP (Largest Contentful Paint)
Comme dit le dicton, il est impossible d'améliorer ce qu'on ne mesure pas. En ce qui concerne l'expérience utilisateur sur le Web, nous pensons que les Core Web Vitals constituent un ensemble solide de métriques centrées sur l'utilisateur et conçues pour capturer les aspects fondamentaux de l'expérience utilisateur. Plus spécifiquement, la métrique LCP (Largest Contentful Paint) mesure les performances de chargement de vos pages en indiquant le temps nécessaire pour afficher le bloc de texte ou d'image le plus volumineux que l'utilisateur voit. Pour offrir une bonne expérience utilisateur, le LCP doit se produire dans les 2,5 secondes suivant le début du chargement de la page (autrement dit, lorsque le LCP est bon).
Voyons ce qui contribue au LCP d'une page type.
Lorsqu'un internaute consulte une page, le navigateur demande le code HTML au serveur. Le serveur répond avec le code HTML, qui donne au navigateur plus d'indices sur ce qu'il doit récupérer ensuite, y compris les fichiers CSS, JavaScript, les polices et les images. Au fur et à mesure que ces réponses reviennent, le navigateur doit également les évaluer, puis disposer et peindre les composants de la page. Mais la majorité du temps est passée à attendre que ces paquets soient acheminés de l'appareil au serveur, puis à nouveau vers l'appareil. D'ailleurs, nos données (Chrome pour Android, médiane) montrent qu'environ 40% de la latence visible par l'utilisateur est généralement passée par le navigateur en attendant le retour du tout premier octet du serveur.
La puissance du préchargement
Si l'on pouvait précharger tous ces fichiers (c'est-à-dire les récupérer avant que l'utilisateur ne consulte la page), cela permettrait d'augmenter considérablement la vitesse, ne laissant que quelques tâches avant d'afficher la page: évaluer, calculer la mise en page et peindre.
Étant donné les données partagées précédemment, on peut également se contenter de précharger la ressource principale tout en maintenant un chargement de page beaucoup plus rapide. Dans le cas d'un site identique, ce type de technique est facilement accessible avec des primitives telles que rel=prefetch. Toutefois, avec les scénarios intersites, ce n'est pas aussi simple.
Navigations intersites
Bien que le préchargement existe depuis un certain temps, une attention supplémentaire est justifiée lorsque vous préchargez des pages depuis un site alors que l'utilisateur est sur un autre.
Supposons qu'un site référent demande au navigateur de précharger une page à partir d'un autre site. À l'évidence, lorsque l'internaute clique sur le lien vers cette page préchargée, il aimerait bénéficier d'une meilleure expérience avec un chargement de page beaucoup plus rapide. Cependant, que se passe-t-il si l'utilisateur ne clique jamais sur ce lien ? Il ne s'attend pas à ce qu'un site Web lié à un lien apprenne qu'il a peut-être été intéressé par un sujet alors qu'il le consultait sur le site de provenance. Il s'agit toutefois d'un risque important, car les requêtes de préchargement comportent alors l'adresse IP de l'utilisateur et, le cas échéant, les cookies, comme toute autre requête standard.
Solutions
Pour permettre le préchargement intersite respectant la confidentialité, nous avons développé deux solutions au cours des trois dernières années: le proxy de préchargement privé et les échanges signés (SXG). Nous avons également effectué un test à grande échelle pour confirmer que le préchargement multi-origine offre des avantages significatifs en termes de vitesse. Concrètement, lorsque nous avons examiné des cas où Google a pu précharger en toute sécurité le code HTML principal pour la prochaine navigation de l'utilisateur, nous avons constaté que la fraction des chargements de page avec un "bon" LCP a augmenté de 14 points de pourcentage.
Remarques importantes
Alors que le proxy de préchargement privé et l'échange signé résolvent le même cas d'utilisation, chaque technologie présente un ensemble différent de compromis. Le meilleur choix dépend donc des besoins spécifiques de votre site. Pour vous aider à comprendre les compromis à faire, les sections suivantes traitent de deux éléments clés à prendre en compte pour activer le préchargement intersite et choisir entre les deux technologies disponibles. Vous trouverez également plus de détails dans les articles détaillés sur chaque technologie.
Visiteurs récurrents
Le préchargement intersite est facile à activer pour les utilisateurs qui accèdent à votre site pour la première fois. Pour les visiteurs récurrents, cela dépend du degré de personnalisation effectué sur votre site. En effet, pour des raisons de confidentialité, les demandes de préchargement intersites ne peuvent pas inclure de cookies.
- Pour les nouveaux visiteurs, cette restriction ne pose aucun problème, car ces visiteurs n'ont pas de cookies pour commencer. Vous pouvez donc activer le préchargement intersite pour ces utilisateurs sans modifier votre site.
- Si vous souhaitez activer le préchargement intersite pour les visiteurs récurrents et que votre site est personnalisé en fonction de cookies, vous devrez charger ces éléments personnalisés de façon différée après la navigation de l'utilisateur. En effet, lors de la navigation, la restriction des cookies n'est plus nécessaire puisque l'utilisateur a explicitement choisi de visiter votre site Web. Ainsi, au moment de la navigation, votre site a accès à ses cookies comme d'habitude. Pour obtenir des conseils concrets, consultez ces bonnes pratiques concernant le chargement différé.
- Si vous encodez actuellement la personnalisation directement dans votre code HTML, vous pouvez continuer à le faire lorsque des cookies sont présents et utiliser le chargement différé comme stratégie de remplacement pour les pages préchargées.
- Si votre site n'est pas personnalisé selon les cookies ou si cette personnalisation n'est pas essentielle, vous pouvez choisir de proposer le même contenu aux visiteurs récurrents et aux nouveaux visiteurs.
Pour le moment, le proxy de préchargement privé n'est activé que pour les nouveaux visiteurs (liens sans cookies). Nous nous efforçons en permanence d'étendre la couverture aux visiteurs récurrents (liens avec cookies). En revanche, Signed Exchange est déjà compatible avec le préchargement intersites pour les nouveaux visiteurs et les visiteurs réguliers (selon les approches décrites ci-dessus).
Diffusion de données supplémentaires à partir du préchargement
L'activation du préchargement intersite peut entraîner une diffusion de données supplémentaire. En effet, si une URL de provenance précharge votre page, mais que l'utilisateur ne clique pas sur le lien, vous générez du trafic supplémentaire.
- Pour limiter ce problème, vous pouvez demander à l'URL de provenance d'être moins agressif vis-à-vis de ses requêtes de préchargement. De même, l'URL de provenance, ou le navigateur, peut limiter ce problème en se concentrant sur les ressources relativement légères, mais critiques (par exemple, la ressource principale, les sous-ressources CSS ou les sous-ressources JavaScript). Il s'agit essentiellement d'un compromis entre vitesse de traitement et trafic supplémentaire.
- Vous pouvez également compenser ce trafic en activant la mise en cache supplémentaire (consultez cette section sur les échanges signés pour en savoir plus). L'inconvénient est que la mise en cache de contenu pendant trop longtemps peut entraîner l'affichage d'informations plus anciennes. Il s'agit essentiellement d'un compromis entre diffusion de données supplémentaires et fraîcheur du contenu.
Pour prendre la meilleure décision, demandez-vous où se situe votre site entre une actualisation maximale et un minimum de demandes supplémentaires. La réponse à cette question dépend en fin de compte des besoins spécifiques de votre entreprise et de vos utilisateurs.
Premiers pas
Ces technologies ont été intégrées à la recherche Google afin que les sites puissent commencer à améliorer immédiatement leur LCP. Nous espérons que cela incitera également d'autres parrains populaires à suivre le même exemple et contribuera à rendre le Web beaucoup plus rapide à tous les niveaux !
Bien que ces technologies résolvent toutes les deux le même cas d'utilisation, elles offrent des compromis différents sur les considérations clés expliquées plus tôt. Vous pouvez même décider de commencer avec une technologie et de passer à l'autre à mesure que vos besoins ou l'appréciation de ses avantages évoluent. Consultez ces présentations détaillées pour déterminer quelle technologie est la plus adaptée à votre situation: