Optimiser le LCP à l'aide d'échanges signés

Mesurer et optimiser les échanges signés pour en tirer le meilleur parti

Devin Mullins

Les échanges signés (SXG) sont un moyen d'améliorer la vitesse de vos pages, en particulier le Largest Contentful Paint (LCP). Lorsque des sites référents (actuellement la recherche Google) redirigent vers une page, ils peuvent la précharger dans le cache du navigateur avant que l'utilisateur ne clique sur le lien.

Il est possible de créer des pages Web qui, une fois préchargées, ne nécessitent aucun réseau sur le chemin critique pour afficher la page. Sur une connexion 4G, ce chargement de page passe de 2,8 s à 0,9 s (les 0,9 s restants dépendent principalement de l'utilisation du processeur):

Remarque:Auparavant, ce post présentait une amélioration de 6 s à 0,9 s. C'est vrai, mais le site testé était anormalement lent à ce moment-là. Il peut néanmoins servir d'exemple pour les pages comportant plus de sous-ressources, des serveurs plus lents ou des utilisateurs dont la connexion est plus lente.

Aujourd'hui, la plupart des personnes qui publient des échanges signés utilisent la fonctionnalité Échanges signés automatiques (ASX) de Cloudflare facile à utiliser (bien que des options Open Source existent également):

Dans de nombreux cas, cocher la case permettant d'activer cette fonctionnalité suffit pour obtenir les améliorations substantielles indiquées ci-dessus. Parfois, quelques étapes supplémentaires permettent de s'assurer que ces échanges fonctionnent comme prévu à chaque étape du pipeline et d'optimiser les pages afin de tirer pleinement parti du préchargement.

Depuis deux mois, depuis le lancement de Cloudflare, j'ai lu plusieurs forums et j'y ai répondu. J'ai également appris à conseiller les sites pour s'assurer qu'ils exploitent au mieux leurs déploiements SXG. Ce post est un recueil de mes conseils. Voici la procédure à suivre pour:

• Analysez les performances des échanges signés à l'aide de WebPageTest.
• Déboguer le pipeline SXG si l'étape "Analyser" montre qu'il ne fonctionne pas.
• Optimisez les pages pour le préchargement d'échanges signés en définissant un max-age optimal et en préchargeant des sous-ressources qui bloquent l'affichage.
• Mesurez l'amélioration des échanges signés à l'aide de Google Analytics en sélectionnant les groupes de test et de contrôle appropriés.

Introduction

Un échange signé est un fichier contenant une URL, un ensemble d'en-têtes de réponse HTTP et un corps de réponse, tous signés de manière cryptographique par un certificat Web PKI. Lorsque le navigateur charge un échange signé, il vérifie toutes les conditions suivantes:

• L'échange signé n'a pas expiré.
• La signature correspond à l'URL, aux en-têtes, au corps et au certificat.
• Le certificat est valide et correspond à l'URL.

Si la validation échoue, le navigateur abandonne l'échange signé et récupère l'URL signée. Si la validation réussit, le navigateur charge la réponse signée, en la traitant comme si elle provenait directement de l'URL signée. Cela permet de réhéberger les échanges signés sur n'importe quel serveur, à condition qu'ils n'aient pas expiré ou qu'ils n'aient pas été modifiés depuis leur signature.

Dans le cas de la recherche Google, l'échange signé permet le préchargement des pages dans ses résultats de recherche. Pour les pages compatibles avec les échanges signés, la recherche Google peut précharger sa copie en cache, hébergée sur webpkgcache.com. Ces URL webpkgcache.com n'affectent pas l'affichage ni le comportement de la page, car le navigateur respecte l'URL d'origine signée. Le préchargement permet à votre page de se charger beaucoup plus rapidement.

Remarque:Les échanges signés sont potentiellement utiles pour d'autres cas d'utilisation qui ne sont pas traités dans cet article. Par exemple, ils peuvent activer la résilience de la connexion: une application de chat peut prétélécharger un lien envoyé à l'utilisateur si la page est compatible avec l'échange signé, afin qu'il puisse le consulter hors connexion. Consultez cette liste plus longue des cas d'utilisation potentiels.

Analyser

Pour voir les avantages des échanges signés, commencez par analyser les performances des échanges signés dans des conditions reproductibles à l'aide d'un outil d'atelier. Vous pouvez utiliser WebPageTest pour comparer les cascades d'annonces et le LCP avec et sans préchargement SXG.

Attention:Les résultats des ateliers peuvent différer des expériences utilisateur réelles, mais ils constituent un outil utile pour déterminer les points à optimiser et effectuer rapidement des itérations. Nous verrons comment mesurer les métriques utilisateur réelles qui en résultent dans la section Mesurer.

Générez un test sans échange signé comme suit:

• Accédez à WebPageTest et connectez-vous. Lorsque vous vous connectez, l'historique de vos tests est enregistré pour que vous puissiez le comparer plus facilement par la suite.
• Saisissez l'URL que vous souhaitez tester.
• Accédez à Configuration avancée. (Vous aurez besoin de la configuration avancée pour le test SXG. Son utilisation ici permet donc de s'assurer que les options de test sont les mêmes.)
• Dans l'onglet Test Settings (Paramètres de test), il peut être utile de définir la connexion sur 4G et de passer à 7 le nombre de tests à exécuter.
• Cliquez sur Démarrer le test.

Générez un test avec un échange signé en suivant la même procédure que ci-dessus, mais avant de cliquer sur Démarrer le test, accédez à l'onglet Script, collez le script WebPageTest suivant, puis modifiez les deux URL navigate comme indiqué ci-dessous:

// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0

// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image

// Wait for the prefetch to succeed.
sleep 10

// Re-enable log collection.
logData 1

// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html

Pour la première URL navigate, si votre page n'apparaît pas encore dans les résultats de recherche Google, vous pouvez utiliser cette page de préchargement pour générer une simulation de page de résultats de recherche à cette fin.

Pour déterminer la deuxième URL navigate, accédez à votre page à l'aide de l'extension Chrome SXG Validator, puis cliquez sur l'icône de l'extension pour afficher l'URL du cache:

Une fois ces tests terminés, accédez à l'historique des tests, sélectionnez les deux tests, puis cliquez sur Comparer:

Ajoutez &medianMetric=LCP à l'URL de comparaison afin que WebPageTest sélectionne l'exécution avec le LCP médian pour chaque côté de la comparaison. (La valeur par défaut correspond à la médiane basée sur l'indice de vitesse.)

Pour comparer des cascades, développez la section Opacité de la cascade et faites glisser le curseur. Pour regarder la vidéo, cliquez sur Ajuster les paramètres de la pellicule, faites défiler la boîte de dialogue vers le bas, puis cliquez sur Regarder la vidéo.

Si le préchargement d'échanges signés aboutit, la cascade "avec échange signé" n'inclut pas de ligne pour le code HTML et les récupérations pour les sous-ressources démarrent plus tôt. Par exemple, comparez "Avant" et "Après" ici:

Déboguer

Si WebPageTest indique que l'échange signé est en cours de préchargement, cela signifie qu'il a réussi toutes les étapes du pipeline. Vous pouvez passer à la section Optimiser pour découvrir comment améliorer davantage le LCP. Sinon, vous devez déterminer où et pourquoi cette défaillance a été détectée dans le pipeline. Poursuivez votre lecture pour découvrir comment.

Publication…

Assurez-vous que vos pages sont générées en tant qu'échanges signés. Pour ce faire, vous devez vous faire passer pour un robot d'exploration. Le moyen le plus simple consiste à utiliser l'extension Chrome SXG Validator:

Remarque:Les échanges signés sont destinés aux robots d'exploration compatibles avec ce type d'échange, afin d'activer le préchargement. Lorsque des utilisateurs visitent directement votre site, vous ne devez pas leur envoyer d'échanges signés, car ils ne seront pas préchargés. Cela ne ferait qu'ajouter des frais. Cloudflare ASX effectue cette négociation de contenu automatiquement.

L'extension récupère l'URL actuelle avec un en-tête de requête Accept indiquant qu'elle préfère la version SXG. Si une coche (✅) s'affiche à côté de l'origine, cela signifie qu'un échange signé a été renvoyé. Vous pouvez passer à la section Indexation.

Si vous voyez une croix (❌), cela signifie qu'aucun échange signé n'a été renvoyé:

Si Cloudflare ASX est activé, la cause la plus probable d'une marque croisée (❌) est qu'un en-tête de réponse de contrôle du cache l'empêche. ASX examine les en-têtes portant les noms suivants:

• Cache-Control
• CDN-Cache-Control
• Surrogate-Control
• Cloudflare-CDN-Cache-Control

Si l'un de ces en-têtes contient l'une des valeurs d'en-tête suivantes, il empêche la génération d'un échange signé:

• private
• no-store
• no-cache
• max-age inférieur(e) à 120, sauf si la valeur de s-maxage est supérieure ou égale à 120

Dans ce cas, ASX ne crée pas d'échange signé, car il peut être mis en cache et réutilisé pour plusieurs visites et visiteurs.

Une autre raison possible d'une marque croisée (❌) est la présence de l'un de ces en-têtes de réponse avec état, à l'exception de Set-Cookie. ASX supprime l'en-tête Set-Cookie pour se conformer à la spécification SXG.

Remarque:Ces restrictions sont détaillées dans le code ASX. Par exemple, les en-têtes de contrôle du cache sont inspectés par le code qui détermine quand signer et la durée de signature à respecter. Les autres en-têtes sont supprimés avant la signature avec cette configuration ou avec ce code. Les autres en-têtes empêchent la signature s'ils ne sont pas supprimés autrement.

Une autre raison possible est la présence d'un en-tête de réponse Vary: Cookie. Googlebot récupère les échanges signés sans identifiants utilisateur et peut les diffuser auprès de plusieurs visiteurs. Si vous utilisez un code HTML différent pour les différents utilisateurs en fonction de leur cookie, ils risquent de voir une expérience incorrecte, telle qu'une vue déconnectée.

Remarque:À l'avenir, les pages utilisant Vary: Cookie seront compatibles avec l'échange signé, car elles ne s'afficheront qu'auprès des visiteurs n'ayant pas recours aux cookies pour votre site. Cette fonctionnalité est implémentée dans Chromium et sera activée dans la recherche Google une fois qu'elle aura été entièrement déployée.

Vous pouvez également utiliser un outil tel que curl à la place de l'extension Chrome:

curl -siH "Accept: application/signed-exchange;v=b3" $URL | less

ou dump-signedexchange:

dump-signedexchange -verify -uri $URL

Si l'échange signé est présent et valide, une impression lisible par l'humain le concernant s'affiche. Sinon, un message d'erreur s'affiche.

Indexation

Assurez-vous que vos échanges signés sont bien indexés par la recherche Google. Ouvrez les outils pour les développeurs Chrome, puis recherchez votre page sur Google. S'il a été indexé en tant qu'échange signé, le lien Google vers votre page inclura un data-sxg-url pointant vers la copie de webpkgcache.com:

Si la recherche Google estime que l'utilisateur est susceptible de cliquer sur le résultat, il procède également au préchargement de celui-ci:

L'élément <link> demande au navigateur de télécharger l'échange signé dans son cache de préchargement. Lorsque l'utilisateur clique sur l'élément <a>, le navigateur utilise cet échange signé mis en cache pour afficher la page.

Vous pouvez également consulter la preuve du préchargement en accédant à l'onglet "Network" (Réseau) des outils de développement et en recherchant les URL contenant webpkgcache.

Si <a> renvoie vers webpkgcache.com, cela signifie que l'indexation de l'échange signé fonctionne dans la recherche Google. Vous pouvez passer à la section Ingestion.

Il est également possible que Google n'ait pas encore réexploré votre page depuis que vous avez activé l'échange signé. Essayez l'outil d'inspection d'URL Google Search Console:

La présence d'un en-tête digest: mi-sha256-03=... indique que Google a réussi à explorer la version de l'échange signé.

Si aucun en-tête digest n'est présent, cela peut signifier qu'aucun échange signé n'a été envoyé à Googlebot ou que l'index n'a pas été mis à jour depuis que vous avez activé les échanges signés.

Si un échange signé a bien été exploré, mais qu'il n'y est toujours pas associé, il se peut qu'il ne réponde pas aux exigences du cache d'échanges signés. Celles-ci sont traitées dans la section suivante.

Ingestion

Lorsque la recherche Google indexe un échange signé, elle envoie sa copie au cache d'échanges signés Google, qui la vérifie par rapport aux exigences de mise en cache. L'extension Chrome affiche le résultat suivant:

Si une coche (✅ s'affiche, vous pouvez passer directement à l'étape Optimiser).

Si elle ne respecte pas les exigences, une croix (❌) s'affiche, ainsi qu'un message d'avertissement indiquant la raison de ce problème:

Dans ce cas, la page fonctionnera comme avant l'activation de l'échange signé. Google créera un lien vers la page sur son hôte d'origine sans préchargement d'échanges signés.

Si la copie en cache a expiré et qu'elle est de nouveau récupérée en arrière-plan, un sablier (⌛) s'affiche :

Le document Google destiné aux développeurs sur les échanges signés contient également des instructions pour interroger le cache manuellement.

Optimisation

Si l'extension Chrome SXG Validator affiche toutes les coches (✅), cela signifie qu'un échange signé peut être diffusé auprès des utilisateurs. Poursuivez votre lecture pour découvrir comment optimiser votre page Web afin d'améliorer le plus le LCP des échanges signés.

max-age

Lorsque les échanges signés expirent, le cache d'échanges signés Google récupère une nouvelle copie en arrière-plan. En attendant la récupération, les utilisateurs sont redirigés vers la page de son hôte d'origine, qui n'est pas préchargée. Plus vous définissez Cache-Control: max-age, moins l'extraction en arrière-plan se produit, et plus le LCP peut être réduit par le préchargement.

Il s'agit d'un compromis entre performances et fraîcheur, et le cache permet aux propriétaires de sites de définir un âge maximal entre deux minutes et sept jours pour les échanges signés, afin de répondre aux besoins spécifiques de chaque page. Anecdotique, nous constatons que:

• max-age=86400 (1 jour) ou plus permet d'améliorer les performances
• max-age=120 (2 minutes) ne fait pas

Nous espérons en apprendre davantage sur les valeurs intermédiaires au fur et à mesure que nous étudierons les données.

Remarque:Nous prévoyons de faciliter la gestion de ce compromis à l'avenir en ajoutant une API de purge du cache. Elle sera annoncée à l'adresse webpackaging-announce.

user-agent

Une fois, j'ai constaté une augmentation du LCP lors de l'utilisation d'échanges signés préchargés. J'ai exécuté WebPageTest pour comparer les résultats médians sans préchargement d'échanges signés et avec un préchargement d'échanges signés. Cliquez sur Après ci-dessous:

J'ai vu que le préchargement fonctionnait. Le code HTML est supprimé du chemin critique et toutes les sous-ressources peuvent donc se charger plus tôt. En revanche, le LCP (la ligne en pointillés verts) est passé de 2 s à 2,1 s.

Pour diagnostiquer cela, j'ai regardé les bandes de film. J'ai constaté que la page s'affichait différemment dans un échange signé. En HTML brut, Chrome a déterminé que "l'élément le plus grand" du LCP était le titre. Cependant, dans la version SXG, la page a ajouté une bannière à chargement différé, qui a repoussé le titre en dessous de la ligne de flottaison et a fait que le nouvel élément le plus grand était la boîte de dialogue de consentement à chargement différé. Le rendu s'est affiché plus rapidement qu'auparavant, mais un changement de mise en page a ralenti la métrique.

J'ai approfondi mes recherches et j'ai découvert que la différence de mise en page s'explique par le fait que la page variait de User-Agent et qu'il y avait une erreur dans la logique. Il affichait une page pour ordinateur alors que l'en-tête d'exploration de l'échange signé indique "mobile". Une fois le problème résolu, le navigateur a à nouveau identifié correctement le titre de la page comme étant à nouveau son élément le plus grand.

En cliquant sur "After", je vois que le LCP préchargé passe à 1,3 s:

Les échanges signés sont activés pour tous les facteurs de forme. Pour vous préparer à ce changement, assurez-vous que l'une des conditions suivantes est remplie:

• Votre page ne Vary pas User-Agent (par exemple, elle utilise un design réactif ou des URL distinctes pour mobile et ordinateur).
• Si votre page utilise l'affichage dynamique, elle s'annotera pour l'affichage sur mobile ou ordinateur uniquement à l'aide de <meta name=supported-media content=...>.

Sous-ressources

Les échanges signés peuvent être utilisés pour précharger des sous-ressources (y compris des images) avec le code HTML. Cloudflare ASX analyse le code HTML à la recherche d'éléments <link rel=preload> de même origine (propriétaires) et les convertit en en-têtes de lien compatibles SXG. Plus de détails dans le code source ici et ici.

Si cela fonctionne, vous verrez d'autres préchargements à partir de la recherche Google:

Pour optimiser le LCP, examinez attentivement votre cascade et identifiez les ressources sur le chemin critique pour afficher l'élément le plus grand. Si elles ne peuvent pas être préchargées, demandez-vous si elles peuvent être retirées du chemin critique. Faites attention aux scripts qui masquent la page jusqu'à ce que leur chargement soit terminé.

Google SXG Cache autorise jusqu'à 20 sous-ressources préchargées, et ASX s'assure que cette limite n'est pas dépassée. Toutefois, l'ajout d'un trop grand nombre de préchargements de sous-ressources présente un risque. Afin d'éviter le suivi intersites, le navigateur n'utilise les sous-ressources préchargées que si la récupération de toutes les ressources est terminée. Plus il y a de sous-ressources, moins elles sont susceptibles d'avoir fini de précharger avant que l'utilisateur clique pour accéder à votre page.

Remarque:ASX n'est actuellement compatible qu'avec le préchargement des sous-ressources de même origine (propriétaires). Si vous connaissez des fournisseurs de sous-ressources tiers qui acceptent les échanges signés, signalez-nous ce bug afin que nous puissions donner la priorité à la compatibilité multi-origine.

Le programme de validation d'échanges signés ne vérifie pas les sous-ressources pour le moment. En attendant, utilisez curl ou dump-signedexchange pour effectuer le débogage.

Mesurer

Après avoir optimisé l'amélioration du LCP via WebPageTest, il est utile de mesurer l'impact du préchargement d'échanges signés sur les performances globales de votre site.

Métriques côté serveur

Lorsque vous mesurez des métriques côté serveur telles que le temps avant le premier octet (TTFB), il est important de noter que votre site ne diffuse des échanges signés que pour les robots d'exploration qui acceptent ce format. Limitez votre mesure du TTFB aux requêtes provenant d'utilisateurs réels et non de bots. Vous constaterez peut-être que la génération d'échanges signés augmente le TTFB pour les requêtes du robot d'exploration, mais cela n'a aucune incidence sur l'expérience de vos visiteurs.

Métriques côté client

Les échanges signés offrent les meilleurs avantages en termes de vitesse pour les métriques côté client, en particulier pour le LCP. Pour mesurer leur impact, vous pouvez simplement activer Cloudflare ASX, attendre que Googlebot le réexplore, attendre 28 jours supplémentaires pour l'agrégation Core Web Vitals (CWV), puis examiner les nouveaux chiffres de vos métriques Core Web Vitals. Cependant, le changement peut être difficile à repérer lorsqu'il est mélangé à tous les autres changements sur cette période.

Au lieu de cela, je trouve utile de "faire un zoom avant" sur les chargements de page potentiellement concernés et de les encadrer de la manière suivante : "Les échange signés affectent X% des pages vues, améliorant ainsi leur LCP de Y millisecondes au 75e centile".

Actuellement, le préchargement d'échanges signés ne s'effectue que dans certaines conditions:

• Navigateur Chromium (par exemple, Chrome ou Edge, sauf sur iOS), version M98 ou ultérieure
• Referer: google.com ou d'autres domaines de recherche Google. Notez que dans Google Analytics, une balise de parrainage s'applique à toutes les pages vues de la session, tandis que le préchargement d'échanges signés ne s'applique qu'à la première page vue, directement liée à partir de la recherche Google.

Remarque:La recherche Google prévoit d'étendre les contextes dans lesquels le préchargement d'échanges signés peut avoir lieu, y compris avec les OS d'ordinateur de bureau, etc. Cela peut augmenter de X% au fil du temps, ce qui signifie également que vous pouvez mettre à jour vos métriques afin de tenir compte de ce changement. Le cas échéant, vous devez l'annoncer sur webpackaging-announce.

Consultez la section Étude contemporaine pour savoir comment mesurer "X% des pages vues" et "améliorer le LCP de Y millisecondes".

Étude contemporaine

Lorsque vous examinez les données de surveillance des utilisateurs réels (RUM, Real User Monitoring), vous devez diviser les chargements de page en deux catégories : SXG et non SXG. Dans ce cas, il est essentiel de limiter l'ensemble de chargements de pages que vous consultez, afin que le côté autre que les échanges signés corresponde aux conditions d'éligibilité pour ce type d'échange, afin d'éviter tout biais de sélection. Sinon, tous les éléments suivants n'existeraient que dans l'ensemble des chargements de pages non SXG, dont le LCP peut être interne à différents:

• Appareils iOS:en raison des différences de débit du matériel ou du réseau parmi les utilisateurs disposant de ces appareils.
• Navigateurs Chromium plus anciens:pour les mêmes raisons.
• Ordinateurs:pour les mêmes raisons, ou parce que la mise en page entraîne le choix d'un autre "plus grand élément"
• Navigations sur le même site (les visiteurs suivent des liens sur le site) : ils peuvent réutiliser les sous-ressources mises en cache du chargement de page précédent.

Dans Google Analytics (UA), créez deux dimensions personnalisées de portée "Appel", l'une nommée "isSXG" et l'autre "URL de provenance". (La dimension intégrée "Source" a une portée de session, de sorte qu'elle n'exclut pas les navigations sur le même site.)

Créez un segment personnalisé nommé "SXG contrefactuel" associé aux filtres suivants avec l'opérateur AND:

• referrer commence par https://www.google.
• Browser correspond exactement à Chrome
• Browser La version correspond à l'expression régulière ^(9[8-9]|[0-9]{3})
• isSXG correspond exactement à false

Créez une copie de ce segment, nommée "SXG", sauf que isSXG correspond exactement à true.

Dans votre modèle de site, ajoutez l'extrait suivant au-dessus de l'extrait Google Analytics. Il s'agit d'une syntaxe spéciale dans laquelle ASX remplace false par true lors de la génération d'un échange signé:

<script data-issxg-var>window.isSXG=false</script>

Personnalisez votre script de création de rapports Google Analytics comme recommandé pour enregistrer le LCP. Si vous utilisez gtag.js, modifiez la commande 'config' pour définir la dimension personnalisée (remplacez 'dimension1' et 'dimension2' par les noms que Google Analytics indique d'utiliser):

gtag('config', 'YOUR_TRACKING_ID', {
  'dimension1': String(isSXG),
  'dimension2': document.referrer,
});

Si vous utilisez analytics.js, modifiez la commande 'create' comme indiqué ici.

Après avoir attendu quelques jours pour collecter des données, accédez au rapport "Événements" de Google Analytics et ajoutez une vue détaillée pour le segment échange signé. Le texte "X" doit être rempli pour "Les échange signés affectent X% des pages vues":

Enfin, accédez au rapport sur les métriques Web Vitals, sélectionnez "Choisir des segments", puis "SXG contrefactuel" et "SXG".

Cliquez sur "Envoyer". Vous devriez voir les distributions LCP pour les deux segments. Cela devrait remplir le Y pour « améliorer leur LCP de Y millisecondes au 75e centile » :

Mises en garde

Une fois que vous avez appliqué tous les filtres ci-dessus, les chargements de pages contrefactuels d'échanges signés doivent se présenter comme suit:

• Absence de cache (miss):si le cache d'échanges signés Google ne dispose pas d'une nouvelle copie de l'échange signé pour une URL donnée, il effectue une redirection vers l'URL d'origine sur votre site.
• Autres types de résultats:actuellement, la recherche Google n'est compatible qu'avec les échanges signés pour les résultats Web standards et quelques autres types. D'autres, comme les extraits optimisés et le carrousel "À la une", redirigent vers l'URL d'origine de votre site.
• URL non éligibles:si certaines pages de votre site ne sont pas éligibles à l'échange signé (parce qu'elles ne peuvent pas être mises en cache, par exemple), elles peuvent figurer dans cet ensemble.

Il peut y avoir un biais entre le chargement de la page d'échanges signés et celui de l'ensemble des chargements de pages autres que les échanges signés ci-dessus, mais son ampleur doit être inférieure à celle mentionnée en haut de la section Étude contemporaine. Par exemple, les pages ne pouvant pas être mises en cache sont peut-être plus lentes ou plus rapides que les pages pouvant être mises en cache. Si vous pensez que cela pourrait être un problème, envisagez d'examiner les données limitées à une URL spécifique éligible aux échanges signés pour voir si ses résultats correspondent à l'ensemble de l'étude.

Si votre site comporte des pages AMP, l'activation de l'échange signé ne permettra probablement pas d'améliorer les performances, car elles peuvent déjà être préchargées depuis la recherche Google. Pensez à ajouter un filtre pour exclure ces pages afin d'effectuer un zoom avant sur les modifications pertinentes.

Enfin, même en traitant tous les biais de sélection, le biais de survie risque que les améliorations du LCP ressemblent à des dégradations des statistiques RUM. Cet article explique parfaitement ce risque et suggère d'examiner une métrique d'abandon pour détecter si tel est le cas.

Étude avant/après

Pour corroborer les résultats de l'étude contemporaine, il peut être utile de comparer le LCP avant et après l'activation des échanges signés. Ne vous limitez pas au nombre de pages vues des échanges signés afin d'éliminer les biais potentiels mentionnés ci-dessus. Examinez plutôt les résultats éligibles aux échanges signés (les définitions de segment ci-dessus, mais sans la contrainte isSXG).

Notez que la réexploration de toutes les pages de votre site dans la recherche Google peut prendre plusieurs semaines afin de déterminer que les échanges signés ont été activés pour elles. Pendant ces semaines, d'autres biais potentiels peuvent survenir:

• Les nouvelles versions du navigateur ou les améliorations apportées au matériel des utilisateurs peuvent accélérer le chargement des pages.
• Un événement important, tel qu'un jour férié, peut fausser le trafic de la normale.

Il est également utile d'examiner le LCP global du 75e centile avant et après pour confirmer les études ci-dessus. Apprendre à connaître un sous-ensemble de la population ne nous renseigne pas nécessairement sur la population globale. Par exemple, imaginons qu'un échange signé améliore 10% du chargement des pages de 800 ms.

• S'il s'agissait déjà des 10% de chargements les plus rapides, cela n'affectera pas du tout le 75e centile.
• S'il s'agissait des 10% de chargements les plus lents, mais qu'ils étaient plus lents de plus de 800 ms par rapport au LCP du 75e centile, cela n'affectera pas du tout le 75e centile.

Il s'agit d'exemples extrêmes qui ne reflètent probablement pas la réalité, mais qui, nous l'espérons, illustrent le problème. En pratique, il est probable que l'échange signé affecte le 75e centile pour la plupart des sites. La navigation sur plusieurs sites est généralement l'une des plus lentes, et les améliorations liées au préchargement sont généralement significatives.

Désactiver certaines URL

Enfin, pour comparer les performances des échanges signés, vous pouvez désactiver ces échanges pour certains sous-ensembles d'URL de votre site. Par exemple, vous pouvez définir un en-tête CDN-Cache-Control: no-store pour empêcher Cloudflare ASX de générer un échange signé. Je vous déconseille.

Elle a probablement un risque de biais de sélection plus important que les autres méthodes d'étude. Par exemple, le fait de sélectionner la page d'accueil de votre site ou une URL similaire dans le groupe de test peut faire une grande différence.

Étude de retenue

La façon idéale de mesurer l'impact serait de mener une étude de retenue. Malheureusement, vous ne pouvez pas effectuer ce type de test pour le moment. Nous prévoyons de rendre ce type de test compatible à l'avenir.

Une étude de retenue a les propriétés suivantes:

• Dans le groupe de test, une fraction aléatoire des pages vues qui seraient à recevoir des échanges signés sont "retenues en arrière" et diffusées à la place. Cela permet d'effectuer une comparaison équitable entre les utilisateurs, appareils, scénarios et pages équivalents.
• Les pages vues restreintes (ou contrefactuelles) sont identifiées comme telles dans les données analytiques. Cela permet d'obtenir une vue "zoomée" des données, qui permet de comparer les chargements de pages d'échanges signés dans le contrôle aux contrefacteurs d'échanges signés dans le test. Cela permet de réduire le bruit provenant des autres chargements de page qui ne serait pas affecté par le préchargement d'échanges signés.

Cela éliminerait les sources possibles de biais de sélection mentionnées ci-dessus, bien que cela n'élimine pas le risque de biais de survie LCP. Ces deux propriétés nécessitent l'activation du navigateur ou de l'URL de provenance.

Conclusion

Ouf ! C'était beaucoup. Nous espérons qu'il décrit plus en détail comment tester les performances des échanges signés lors d'un test en laboratoire, comment optimiser leurs performances dans une boucle de rétroaction étroite avec le test en laboratoire et enfin comment mesurer leurs performances en conditions réelles. Tout cela devrait vous permettre de tirer le meilleur parti des échanges signés, et de vous assurer qu'ils profitent à votre site et à vos utilisateurs.

Si vous avez d'autres conseils sur la façon d'enregistrer les performances d'un échange signé, n'hésitez pas à nous contacter. Signalez un bug sur developer.chrome.com et suggérez des améliorations.

Pour en savoir plus sur les échanges signés, consultez la documentation web.dev et la documentation sur la recherche Google.