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) permettent 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 précharger la page dans le cache du navigateur avant que l'utilisateur ne clique sur le lien.

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

<ph type="x-smartling-placeholder">

</ph>

.

Remarque:Auparavant, cet article présentait une amélioration (de 6 s à 0,9 s). C'était vrai, mais le site testé était anormalement lent à l'époque. Toutefois, il peut servir d'exemple pour les pages comportant plus de sous-ressources, des serveurs plus lents ou des utilisateurs dont les types de connexion sont plus lents.

Aujourd'hui, la plupart des personnes qui publient des échanges signés utilisent la fonctionnalité Échanges signés automatiques (ASX) de Cloudflare (bien qu'il existe aussi des options Open Source):

Dans de nombreux cas, le fait de cocher la case permettant d'activer cette fonctionnalité suffit pour obtenir le type d'amélioration substantielle présenté ci-dessus. Il est parfois nécessaire d'effectuer quelques étapes supplémentaires pour s'assurer que ces échanges signés fonctionnent comme prévu à chaque étape du pipeline et pour optimiser les pages afin de tirer pleinement parti du préchargement.

Depuis le lancement de Cloudflare, j'ai lu les questions posées sur différents forums et j'y réponds depuis quelques mois. J'apprends à conseiller les sites sur la façon de s'assurer qu'ils tirent le meilleur parti de leurs déploiements SXG. Ce post regroupe mes conseils. Voici les étapes à suivre:

• Analysez les performances des échanges signés à l'aide de WebPageTest.
• Déboguer le pipeline SXG si l'étape d'analyse montre qu'il ne fonctionne pas.
• Optimisez les pages pour le préchargement des échanges signés, en définissant une max-age optimale et en préchargeant les 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 ces éléments sont signés de manière cryptographique par un certificat PKI Web. Lorsque le navigateur charge un échange signé, il vérifie tous les éléments suivants:

• 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 aboutit, 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 tant qu'ils n'ont pas expiré ni modifiés depuis leur signature.

Dans le cas de la recherche Google, l'échange signé permet le préchargement des pages des résultats de recherche. Pour les pages compatibles avec les échanges signés, la recherche Google peut précharger sa copie en cache de la page hébergée sur webpkgcache.com. Ces URL webpkgcache.com n'ont aucune incidence sur l'affichage ou le comportement de la page, car le navigateur respecte l'URL d'origine signée. La préchargement peut permettre à 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 abordés dans cet article. Par exemple, ils peuvent activer la résilience des connexions: une application de chat peut prétélécharger un lien envoyé à l'utilisateur si la page est compatible avec les échanges signés, afin qu'il puisse le consulter plus tard hors connexion. Consultez cette liste plus longue des cas d'utilisation potentiels.

Analyser

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

Attention:Les résultats de l'atelier peuvent différer de l'expérience utilisateur réelle, mais ils constituent un outil utile pour identifier les points à optimiser et pour effectuer rapidement des itérations. Nous verrons comment mesurer les métriques d'utilisateurs réels qui en résultent dans la section Mesurer.

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

• Accédez à WebPageTest et connectez-vous. En vous connectant, vous enregistrez l'historique de vos tests pour pouvoir les comparer plus facilement par la suite.
• Saisissez l'URL que vous souhaitez tester.
• Accédez à Configuration avancée. (Vous aurez besoin d'une configuration avancée pour le test d'échange signé. Son utilisation ici permet donc de s'assurer que les options de test sont identiques.)
• Dans l'onglet Paramètres des tests, il peut être utile de définir la connexion sur 4G et d'augmenter le nombre de tests à exécuter. et 7.
• 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é:

// 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 page de résultats de recherche fictive à cet effet.

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 est la médiane de l'indice de vitesse.)

Pour comparer des cascades d'annonces, développez la section Opacité du cascade d'annonces et faites glisser le curseur. Pour afficher 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 SXG réussit, vous verrez que l'option "with SXG" (avec échange signé) n'inclut pas de ligne pour le code HTML, et les extractions des 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écouvrir où le problème a échoué et pourquoi : poursuivez votre lecture pour en savoir plus.

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:

<ph type="x-smartling-placeholder">

</ph>

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

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 "Origine", cela signifie qu'un échange signé a été renvoyé. vous pouvez passer à la section Indexation.

Si vous voyez une coche (❌), cela signifie qu'aucun SXG n'a été renvoyé:

Si Cloudflare ASX est activé, il y a de fortes chances qu'un marquage croisé soit dû au fait 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, cela empêchera 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 plusieurs visiteurs.

Il est également possible qu'une marque croisée (❌) s'explique par 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 respecter la spécification SXG.

Remarque:Ces restrictions peuvent être vues plus en détail 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 quelle doit être la durée de signature. Les autres en-têtes sont supprimés avant la signature par cette configuration ou par ce code. Les autres en-têtes empêchent la signature s'ils ne sont pas supprimés.

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 affichez un code HTML différent à 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 qui utilisent Vary: Cookie seront compatibles avec SXG, car elles ne seront affichées que pour les visiteurs de votre site sans cookies. Cette fonctionnalité est implémentée dans Chromium et sera activée dans la recherche Google lorsque le déploiement sera plus complet.

En remplacement de l'extension Chrome, vous pouvez utiliser un outil comme curl:

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 version lisible par l'humain s'affiche. Sinon, un message d'erreur s'affichera.

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 inclut un data-sxg-url pointant vers la copie de webpkgcache.com:

Si la recherche Google pense que l'utilisateur est susceptible de cliquer sur le résultat, il précharge également ce résultat:

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 l'échange signé (SXG) mis en cache pour afficher la page.

Vous pouvez également voir les preuves 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> pointe vers webpkgcache.com, cela signifie que l'indexation de l'échange signé dans la recherche Google fonctionne. Vous pouvez passer directement à la section Ingestion.

Sinon, il est 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 SXG.

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

Si un échange signé est exploré avec succès, mais qu'il n'est toujours pas associé, cela peut signifier que les exigences concernant le cache d'échanges signés ne sont pas respectées. Ceux-ci sont abordés dans la section suivante.

Ingestion

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

Si une coche (✅) s'affiche, vous pouvez passer directement à la section Optimiser.

S'il ne répond pas aux exigences, une coche (❌) et un message d'avertissement vous en indiqueront la raison:

Dans ce cas, la page fonctionnera de la même manière qu'avant l'activation de l'échange signé. Google créera un lien vers la page sur son hôte d'origine sans préchargement SXG.

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

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

Optimiser

Si l'extension Chrome SXG Validator affiche toutes les coches (✅), vous disposez d'un SXG qui peut être diffusé auprès des utilisateurs. Lisez la suite pour découvrir comment optimiser votre page Web afin d'obtenir la meilleure amélioration de LCP de l'échange SXG.

âge-max

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 cette extraction, les utilisateurs sont redirigés vers la page sur son hôte d'origine, qui n'est pas préchargée. Plus la valeur définie pour Cache-Control: max-age est longue, moins cette récupération en arrière-plan se produit souvent, et plus le LCP peut être réduit par le préchargement.

Il s'agit d'un compromis entre les performances et l'actualisation. Le cache permet aux propriétaires de sites de fournir aux échange signés avec un âge maximal compris entre 2 minutes et 7 jours, afin de répondre aux besoins particuliers de chaque page. D'ailleurs, nous constatons que:

• max-age=86400 (1 jour) ou plus est un bon outil pour les performances
• max-age=120 (2 minutes) ne répond pas

Nous espérons en apprendre davantage sur les valeurs comprises entre ces deux valeurs à mesure que nous étudierons les données de plus près.

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 sur webpackaging-announce.

user-agent

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

J'ai vu que le préchargement fonctionnait. Le code HTML est supprimé du chemin critique. Ainsi, toutes les sous-ressources peuvent être chargées plus tôt. Mais le LCP (cette ligne en pointillés verts) est passé de 2 s à 2,1 s.

Pour diagnostiquer le problème, j'ai regardé les bandes de film. J'ai constaté que la page s'affichait différemment dans SXG. En HTML brut, Chrome a déterminé que le "plus grand élément" pour le LCP était le titre. Toutefois, dans la version SXG, la page ajoutait une bannière à chargement différé, qui poussait le titre en dessous de la ligne de flottaison. Le nouvel élément le plus grand était alors la boîte de dialogue de recueil du consentement pour le chargement différé des cookies. Tout s'affichait plus rapidement qu'avant, mais en raison d'un changement de mise en page, la métrique a indiqué que la métrique était plus lente.

J'ai creusé plus profondément et j'ai découvert que la différence de mise en page était due au fait que la page varie en fonction de User-Agent et qu'il y avait une erreur dans la logique. Il diffusait une page pour ordinateur même si l'en-tête d'exploration SXG indiquait "mobile". Une fois ce problème résolu, le navigateur a de nouveau identifié correctement le titre de la page comme étant son plus grand élément.

En cliquant sur "Après", j'ai constaté que le LCP préchargé passe à 1,3 s:

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

• Votre page n'affiche pas de Vary par User-Agent (par exemple, si elle utilise un responsive design ou des URL distinctes pour mobile et pour ordinateur).
• Si votre page utilise l'affichage dynamique, elle est annotée comme étant réservée aux mobiles ou aux ordinateurs à l'aide de <meta name=supported-media content=...>.

Sous-ressources

Les échanges signés peuvent être utilisés pour précharger les sous-ressources (y compris les images) avec le code HTML. Cloudflare ASX recherche dans le code HTML les éléments <link rel=preload> de même origine (propriétaires) et les convertit en en-têtes Link compatibles SXG. Pour en savoir plus, consultez le code source sur cette page et sur cette page.

S'il fonctionne, vous verrez d'autres préchargements provenant de la recherche Google:

Pour optimiser le LCP, examinez attentivement votre cascade d'annonces et identifiez les ressources qui se trouvent sur le chemin critique du rendu du plus grand élément. Si elles ne peuvent pas être préchargées, déterminez si elles peuvent être retirées du chemin critique. Surveillez les scripts qui masquent la page jusqu'à la fin du chargement.

Google SXG Cache autorise jusqu'à 20 préchargements de sous-ressources. ASX 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. Le navigateur n'utilise les sous-ressources préchargées que si l'extraction est terminée pour toutes les ressources, afin d'empêcher le suivi intersites. Plus il y a de sous-ressources, moins il y a de chances qu'elles aient terminé le préchargement avant que l'utilisateur ne clique pour accéder à votre page.

Remarque:Actuellement, ASX n'accepte le préchargement que pour les sous-ressources (propriétaires) de même origine. Si vous connaissez des fournisseurs de sous-ressources tiers qui acceptent les échanges signés, n'hésitez pas à nous signaler ce bug afin que nous puissions prioriser l'ajout de la compatibilité multi-origine.

Le programme de validation SXG ne vérifie pas les sous-ressources pour le moment. Pour le débogage, utilisez curl ou dump-signedexchange en attendant.

Mesurer

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

Métriques côté serveur

Lorsque vous mesurez des métriques côté serveur telles que Time to First Byte (TTFB), il est important de noter que votre site ne diffuse des échanges signés qu'aux robots d'exploration qui acceptent le format. Limitez vos mesures du TTFB aux demandes 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 demandes du robot d'exploration, mais cela n'a aucune incidence sur les performances expérience.

Métriques côté client

Les échanges signés offrent le meilleur bénéfice en termes de vitesse pour les métriques côté client, en particulier le LCP. Pour mesurer leur impact, il vous suffit d'activer Cloudflare ASX, d'attendre que Googlebot les explore à nouveau, d'attendre 28 jours supplémentaires pour l'agrégation des métriques Core Web Vitals (CWV), puis d'examiner vos nouvelles métriques Core Web Vitals. Toutefois, la modification peut être difficile à détecter lorsqu'elle est mélangée à toutes les autres modifications effectuées sur cette période.

Je trouve utile de faire un "zoom avant" sur les chargements de page potentiellement concernés, et encadrez-le de la manière suivante : "Les échanges affectent X% des pages vues, améliorant ainsi leur LCP de Y millisecondes au 75e centile".

Actuellement, le préchargement SXG ne se produit 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 site référent s'applique à toutes les pages vues de la session, tandis que le préchargement SXG ne s'applique qu'à la première page vue, directement associée à la recherche Google.

Remarque:La recherche Google prévoit d'étendre les contextes dans lesquels le préchargement SXG peut s'appliquer, y compris pour les OS de bureau et plus encore. Cela peut augmenter la valeur de X% au fil du temps et signifier que vous devrez peut-être mettre à jour vos statistiques pour vous adapter à ce changement. Lorsque cela se produit, l'annonce doit être annoncée sur webpackaging-announce.

Pour savoir comment mesurer "X% des pages vues", consultez la section Étude contemporaine. et "améliore leur LCP de Y millisecondes".

Étude contemporaine

Lorsque vous examinez les données de surveillance des utilisateurs réels (RUM), vous devez diviser les chargements de page en SXG et non-SXG. Dans ce cas, il est essentiel de limiter l'ensemble des chargements de pages que vous examinez, afin que le côté non-SXG corresponde aux conditions d'éligibilité pour les échanges signés, afin d'éviter tout biais de sélection. Sinon, tous les éléments suivants n'existeraient que dans l'ensemble de chargements de pages non-SXG, qui pourraient avoir un LCP intrinsèquement différent:

• Appareils iOS:en raison des différences de vitesse du matériel ou du réseau entre 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 provoque un "élément le plus grand" différent à choisir.
• Navigation sur le même site (visiteurs suivant un lien dans le site) : elles peuvent réutiliser les sous-ressources mises en cache lors du chargement de la page précédente.

Dans Google Analytics (UA), créez deux dimensions personnalisées avec le champ d'application "Hit", l'une nommée "isSXG". et l'autre nommée "referrer". Étant donné que la dimension intégrée "Source" est associée à une portée : session, elle n'exclut pas les navigations sur un même site.

Créez un segment personnalisé nommé "SXG contrefactual" avec les filtres suivants associés 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é "SXG", mais avec isSXG, qui correspond exactement à true.

Dans votre modèle de site, ajoutez l'extrait suivant au-dessus de l'extrait Google Analytics. Voici une syntaxe spéciale qu'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 à utiliser):

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

Si vous utilisez analytics.js, modifiez la commande 'create' comme décrit 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 SXG. Le "X" s'affiche alors pour "Les échanges affectent X% des pages vues" :

Enfin, accédez au rapport "Signaux Web", sélectionnez "Choisir des segments", puis "Contre-factuels SXG". et "SXG".

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

Mises en garde

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

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

Il peut y avoir un biais entre le chargement de la page SXG et l'ensemble ci-dessus de chargements de pages non SXG, mais son ampleur devrait être inférieure à celle des biais mentionnés en haut de la section Étude contemporaine. Par exemple, il est possible que les pages ne pouvant pas être mises en cache soient plus lentes ou plus rapides que les pages pouvant être mises en cache. Si vous pensez que cela peut poser problème, examinez les données limitées à une URL spécifique éligible pour un échange signé afin de voir si ses résultats correspondent à l'étude globale.

Si votre site comporte des pages AMP, l'activation des échanges signés n'améliorera probablement pas les performances, car elles peuvent déjà être préchargées à partir de la recherche Google. Pensez à ajouter un filtre pour exclure ces pages afin d'effectuer un "zoom avant" plus important. sur les modifications pertinentes.

Enfin, même la prise en compte de tous les biais de sélection, il existe un risque que le biais de survie donne l'impression que les améliorations du LCP ressemblent à des dégradations des statistiques du RUM. Cet article explique très bien ce risque et suggère d'examiner une certaine forme de métrique d'abandon pour détecter si tel est le cas.

Avant/Après l'étude

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

Notez que la recherche Google peut mettre jusqu'à plusieurs semaines pour réexplorer toutes les pages de votre site, afin d'identifier que l'échange signé a été activé. Pendant ces quelques semaines, d'autres biais potentiels peuvent survenir:

• Nouvelles versions du navigateur ou améliorations de la peut accélérer le chargement des pages.
• Un événement important comme des jours fériés peut fausser le trafic par rapport à 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 permet pas nécessairement d’en savoir plus sur l’ensemble de la population. Par exemple, supposons que SXG améliore 10% des chargements de page de 800 ms.

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

Il s'agit d'exemples extrêmes. Ils ne reflètent probablement pas la réalité, mais ils illustrent bien le problème. En pratique, il est probable que les échanges signés affectent le 75e centile pour la plupart des sites. Les navigations intersites sont généralement parmi les plus lentes, et les améliorations apportées par le préchargement sont généralement significatives.

Désactiver certaines URL

Enfin, pour comparer les performances des échanges signés, vous pouvez désactiver les échanges signés pour un sous-ensemble 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 le déconseille.

Elle présente probablement un risque de biais de sélection plus important que les autres méthodes de l'étude. Par exemple, le choix de la page d'accueil ou d'une URL similaire dans le groupe de contrôle ou le groupe test peut faire une grande différence.

Étude de type "holdback"

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

Une étude de type "holdback" a les propriétés suivantes:

• Dans le groupe de test, certaines fractions aléatoires de pages vues qui seraient considérées comme des échanges signés sont "retenues" et diffusées à la place. Cela permet d'appliquer une relation "pommes à pommes" d'utilisateurs, d'appareils, de scénarios et de pages équivalents.
• Ces pages vues retenues (également appelées "pages vues contrefactuelles") sont libellées comme telles dans les données analytiques. Cela permet un "zoom avant" des données, où nous pouvons comparer les chargements de pages d'échanges signés dans la version de contrôle aux contrefactuels d'échanges signés lors du test. Cela permet de réduire le bruit des autres chargements de page qui ne serait pas affecté par le préchargement SXG.

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 au 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 donnera un aperçu plus complet des performances d'un échange signé lors d'un test en laboratoire, de l'optimisation de ses performances dans une boucle de rétroaction serrée avec le test en laboratoire, et enfin de la façon de mesurer ses performances en conditions réelles. La combinaison de tous ces éléments devrait vous aider à tirer le meilleur parti des échanges signés, et à vous assurer qu'ils profitent à votre site et à vos utilisateurs.

Si vous avez d'autres conseils sur la façon de capturer les performances des échanges signés, n'hésitez pas à nous contacter. Signalez un bug sur developer.chrome.com en incluant vos suggestions d'amélioration.

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