Votre guide des tactiques Core Web Vitals utilisant Cloudflare et WebpageTest

Publié: 2022-01-12

L'un des meilleurs moyens d'effectuer des modifications tactiques sur le code de la page Web et d'améliorer les scores Core Web Vitals consiste à établir une comparaison, comme un test A/B. En tant que développeur, vous pouvez exécuter Lighthouse dans votre environnement de développement local et tester au fur et à mesure que vous apportez des modifications. Il est toujours utile de tester le code de production, ce que vous devez faire de toute façon lorsque vous n'êtes pas le développeur.

Nous avons utilisé une pile de démonstration astucieuse dans notre clinique de site Core Web Vitals en décembre dernier dans la version SMX : SEO pour les développeurs. Nous continuerons à l'utiliser dans la prochaine formation SMX Master Class, et à partir de maintenant avec notre série de publications sur le référencement pour les développeurs.

Voici comment tester les scores Core Web Vitals et les changements de code en utilisant Cloudflare Workers comme proxy inverse et WebpageTest. Tous ces services sont gratuits et nous ne sommes certainement pas les premiers à les utiliser. Patrick Meenan, développeur WebpageTest, a pensé à tout. Nous vous expliquerons comment démarrer sans tout le travail lourd.

Cloudflare et WebpageTest

L'application Cloudflare Workers nous offre notre banc d'essai de proxy inverse et notre code de transformation à l'aide de l'environnement proxy. Bien qu'il existe un terrain de jeu sur cloudflareworkers.com, les URL fragmentées à cette adresse nous empêchent de tester sans compte Cloudflare (le gratuit fonctionne). Vous n'avez pas besoin d'un compte WebpageTest.

Une fois que vous avez un compte Cloudflare, accédez à Travailleurs et cliquez pour créer un nouveau travailleur avec le bouton Créer un service. Cela remplira un exemple de travailleur JavaScript avec un éditeur d'interface utilisateur auquel vous pouvez accéder avec le bouton Édition rapide. Chaque travailleur que vous créez obtient une URL unique. Vous pouvez le renommer à tout moment. Nous en avons créé un sur : https://sel.deckart.workers.dev à cet effet.

Si vous naviguez, notez l'exigence "x-host header". L'exigence limite les demandes aux tests. Nous utilisons une extension de navigateur pour modifier les requêtes, ajouter l'en-tête x-host nécessaire pour fournir au script l'hôte que nous voulons tester. Modifions les demandes dans votre navigateur afin que nous puissions afficher la page, afficher la source et exécuter DevTools.

Naviguer dans les tests avec ModHeader

Nous utiliserons ModHeader qui prend en charge les principaux navigateurs. Dans notre cas, nous avons installé l'extension Chrome et ajouté deux en-têtes personnalisés, comme indiqué ci-dessous. L'en-tête x-host fournit l'hôte que nous voulons proxy pour notre test, et l'en-tête x-bypass-transform active et désactive la transformation afin que nous puissions tester la différence.

Avec x-bypass-transform défini sur une valeur "true", la transformation est désactivée. On peut alors consulter le code source pour chercher des tactiques à tester. Avec l'en-tête x-host en place comme illustré ci-dessus, vous pouvez accéder à l'URL du travailleur et vous devriez pouvoir voir la page d'accueil de Search Engine Land, afficher son code source et ouvrir DevTools.

Configurer votre propre Worker

Le travail du travailleur consiste à obtenir les valeurs d'en-tête et à traiter les demandes en conséquence. Nous allons résumer le script ci-dessous, en laissant de côté quelques détails sans importance pour le moment.

URL proxy utilisant la valeur d'en-tête x-host.
Transformez les requêtes qui ont une valeur d'en-tête accept avec "text/html" dans la chaîne.
Ignorer la transformation lorsque la valeur de l'en-tête x-bypass-transform est vraie.
Transformez le code HTML lorsque l'en-tête x-bypass-transform est manquant ou que la valeur est fausse.

Si vous avez déjà écrit un bloc de code de flux de contrôle conditionnel, ces tâches devraient être assez faciles à imaginer écrire vous-même en JavaScript. La question la plus intéressante devient alors : comment allons-nous transformer le HTML ? C'est là que réside la magie de HTMLRewriter(). Copiez le travailleur de base Gist et remplacez votre travailleur par défaut par la source brute.

Configuration de WebpageTest pour les comparaisons

Le script de travail de base n'effectue qu'une seule transformation. En préchargeant l'image LCP, nous avons repoussé sa demande de quelques places dans la file d'attente. Cela a fait passer le temps de chargement du LCP mobile de plus de 5 secondes à moins de 4, soit une amélioration d'environ 500 ms. Pour reproduire cela, notre script doit suivre les changements. Le but est de vous préparer pour les tests avec SEO pour les développeurs et votre propre travail.

Maintenant que nous pouvons modifier A/B dans le navigateur, comment avons-nous utilisé WebpageTest pour obtenir la différence entre les scores ? Nous obtenons des références d'éléments LCP dans le cadre du graphique en cascade détaillé, qui est notre carte la plus utile pour visualiser les effets de nos changements tactiques. Nous examinons l'ordre des demandes et prévoyons de modifier l'ordre dans lequel les ressources se chargent pour améliorer la vitesse.

Notre point de départ sera WebpageTest avec l'URL (et non le proxy inverse). En effet, les URL Cloudflare Worker ont des conditions différentes de celles du fournisseur d'hôte d'origine. Par exemple, l'hôte peut utiliser l'ancien protocole HTTP/1.1, tandis que Cloudflare passe à HTTP/2 dans le cadre de son service. Ce premier rapport WebpageTest doit être utilisé pour développer des tactiques.

Ensuite, nous exécuterons un test scripté sur WebpageTest pour fournir les en-têtes personnalisés nécessaires au test A/B de nos modifications à l'aide de l'URL du proxy inverse. Pour simuler les conditions Core Web Vitals, WebpageTest dispose d'un bouton facile à trouver. C'est bien de l'utiliser pour le test initial. Vous devrez modifier les paramètres lors des tests ultérieurs et la page du bouton Core Web Vitals n'a pas l'interface utilisateur pour cela.

Au lieu de cela, utilisez le test de page d'accueil par défaut et placez l'URL d'origine dans le champ de saisie du test. Modifiez le menu déroulant du navigateur pour sélectionner "Motorola G (gen 4)". Ouvrez la boîte de dialogue Paramètres avancés et modifiez le menu déroulant Connexion pour sélectionner "4G (9 Mbps, 170ms RTT)". Cliquez sur l'onglet "Avancé" et recherchez le champ En-têtes personnalisés où nous ajouterons les en-têtes suivants.

Nous n'allons pas ignorer les transformations pour le moment, nous définissons donc la valeur false. En continuant, nous devons scénariser le test afin que WebpageTest ne tienne pas compte du fait que nous avons mis https://searchengineland.com dans le champ de test, et récupère à la place de notre proxy inverse qui est nécessaire pour que le test puisse correctement échanger l'hôte dans le document HTML de base. Passez à l'onglet Script et ajoutez ce qui suit.

Vous allez vouloir remplacer toutes les chaînes d'URL pour correspondre à vos propres tests une fois que vous vous serez configuré avec Cloudflare. En exécutant le test scripté, vous serez en mesure d'obtenir la file d'attente de demandes coup par coup avec des délais et plus que suffisamment de détails pour développer des tactiques d'amélioration de Core Web Vitals avec la plupart des pages Web. La majorité des pages Web sont facilement proxy, mais votre kilométrage peut varier.

Pourquoi nous nous soucions

Core Web Vitals est un facteur de classement de l'expérience utilisateur de Google. Ce n'est peut-être pas la plus forte amélioration de votre classement à côté, par exemple, de l'optimisation des titres de page. Google a déclaré publiquement qu'il améliorera votre classement en fonction de vos scores. Ils ont déclaré que vous n'avez pas besoin de tous les éléments vitaux pour obtenir un bon score afin de profiter de l'avantage. Votre score optimal est de 90+ et une fois que vous avez atteint le seuil, un score supérieur à 90 n'est pas meilleur que 90 lui-même.