Su guía para las tácticas de Core Web Vitals usando Cloudflare y WebpageTest
Publicado: 2022-01-12Una de las mejores maneras de poder realizar ediciones tácticas en el código de la página web y mejorar las puntuaciones de Core Web Vitals es establecer una comparación, como una prueba A/B. Como desarrollador, puede ejecutar Lighthouse en su entorno de desarrollo local y realizar pruebas a medida que realiza cambios. Todavía es útil para probar el código de producción, lo que debe hacer de todos modos cuando no es el desarrollador.
Usamos una ingeniosa pila de demostración en nuestra Clínica del sitio Core Web Vitals en diciembre pasado en SMX Build: SEO para desarrolladores. Continuaremos usándolo en la próxima capacitación SMX Master Class y, de ahora en adelante, con nuestra serie de publicaciones SEO para desarrolladores.
Aquí se explica cómo probar las puntuaciones de Core Web Vitals y los cambios de código utilizando Cloudflare Workers como proxy inverso y WebpageTest. Todos estos servicios son gratuitos y ciertamente no somos los primeros en usarlos. Patrick Meenan, desarrollador de WebpageTest, lo pensó todo. Describiremos cómo empezar sin todo el trabajo pesado.
Cloudflare y prueba de página web
La aplicación Cloudflare Workers nos brinda nuestro banco de pruebas de proxy inverso y código de transformación utilizando el entorno de proxy. Si bien existe un patio de recreo en cloudflareworkers.com, las URL fragmentadas en esa dirección nos impiden realizar pruebas sin una cuenta de Cloudflare (la gratuita funciona). No necesita una cuenta de WebpageTest.
Una vez que tenga una cuenta de Cloudflare, vaya a Trabajadores y haga clic para crear un nuevo trabajador con el botón Crear un servicio. Esto llenará un trabajador de JavaScript de muestra con un editor de interfaz de usuario al que puede acceder con el botón Edición rápida. Cada trabajador que crea obtiene una URL única. Puedes cambiarle el nombre en cualquier momento. Configuramos uno en: https://sel.deckart.workers.dev para este propósito.
Si navega, observe el requisito de "encabezado x-host". El requisito limita las solicitudes a las pruebas. Usamos una extensión del navegador para modificar las solicitudes, agregamos el encabezado x-host necesario para proporcionar el script con el host que queremos probar. Modifiquemos las solicitudes en su navegador para que podamos ver la página, ver el código fuente y ejecutar DevTools.
Navegar por las pruebas con ModHeader
Usaremos ModHeader que es compatible con los principales navegadores. En nuestro caso, instalamos la extensión de Chrome y agregamos dos encabezados personalizados como se muestra a continuación. El encabezado x-host proporciona el host que queremos convertir en proxy para nuestra prueba, y el encabezado x-bypass-transform activa y desactiva la transformación para que podamos probar la diferencia.

Con x-bypass-transform establecido en un valor "verdadero", la transformación está desactivada. Luego podemos ver la fuente para buscar tácticas para probar. Con el encabezado x-host en su lugar como se muestra arriba, puede navegar a la URL del trabajador y debería poder ver la página de inicio de Search Engine Land, ver su código fuente y abrir DevTools.
Configuración de su propio trabajador
El trabajo del trabajador es obtener los valores de encabezado y procesar las solicitudes en consecuencia. A continuación, resumiremos el guión, dejando de lado algunos detalles que no son importantes en este momento.
- URL de proxy que usan el valor del encabezado x-host.
- Transforme las solicitudes que tienen un valor de encabezado de aceptación con "text/html" en la cadena.
- Omitir la transformación cuando el valor del encabezado x-bypass-transform es verdadero.
- Transforme el HTML cuando falte el encabezado x-bypass-transform o el valor sea falso.
Si alguna vez ha escrito un bloque de código de flujo de control condicional, entonces estas tareas deberían ser bastante fáciles de imaginar escribiéndolas usted mismo en JavaScript. Entonces, la pregunta más interesante es: ¿Cómo vamos a transformar HTML? Ahí es donde está la magia de HTMLRewriter(). Copie el trabajador básico Gist y reemplace su trabajador predeterminado con la fuente sin procesar.
Configuración de WebpageTest para comparaciones
El script de trabajador básico realiza solo una transformación. Al precargar la imagen LCP, adelantamos su solicitud un par de lugares en la cola. Eso llevó el tiempo de carga del LCP móvil de más de 5 segundos a menos de 4, una mejora de aproximadamente 500 ms. Para reproducir esto, nuestra secuencia de comandos debe mantenerse al día con los cambios. El objetivo es prepararte para las pruebas con SEO para desarrolladores y tu propio trabajo.

Ahora que podemos hacer cambios A/B en el navegador, ¿cómo usamos WebpageTest para obtener la diferencia entre las puntuaciones? Obtenemos referencias de elementos LCP como parte del gráfico de cascada detallado, que es nuestro mapa más útil para ver los efectos de nuestros cambios tácticos. Observamos el orden de solicitud y planeamos cambiar el orden en el que se cargan los recursos para mejorar la velocidad.
Nuestro punto de partida será WebpageTest con la URL (y no el proxy inverso). Esto se debe a que las URL de los trabajadores de Cloudflare tienen condiciones diferentes a las del proveedor de host de origen. Por ejemplo, el host podría estar funcionando con el antiguo protocolo HTTP/1.1, mientras que Cloudflare se actualiza a HTTP/2 como parte de su servicio. Este primer informe de WebpageTest debe usarse para desarrollar tácticas.
A continuación, ejecutaremos una prueba con script en WebpageTest para proporcionar los encabezados personalizados necesarios para realizar pruebas A/B de nuestros cambios mediante la URL del proxy inverso. Para simular las condiciones de Core Web Vitals, WebpageTest tiene un botón fácil de encontrar. Está bien usar esto para la prueba inicial. Deberá editar la configuración en las pruebas posteriores y la página del botón Core Web Vitals no tiene la interfaz de usuario para eso.
En su lugar, utilice la prueba de página de inicio predeterminada y coloque la URL de origen en el campo de entrada de prueba. Cambie el menú desplegable del navegador para seleccionar "Motorola G (gen 4)". Abra el cuadro de diálogo Configuración avanzada y cambie el menú desplegable Conexión para seleccionar "4G (9 Mbps, 170 ms RTT)". Haga clic en la pestaña "Avanzado" y busque el campo Encabezados personalizados donde agregaremos los siguientes encabezados.

No vamos a pasar por alto las transformaciones en este momento, por lo que establecemos el valor falso. Continuando, tenemos que escribir la prueba para que WebpageTest ignore que colocamos https://searchengineland.com en el campo de prueba y, en su lugar, obtenga de nuestro proxy inverso lo que se requiere para que la prueba pueda intercambiar correctamente el host en el documento HTML base. Cambie a la pestaña Script y agregue lo siguiente.

Vas a querer reemplazar todas las cadenas de URL para que coincidan con tus propias pruebas una vez que te hayas configurado con Cloudflare. Al ejecutar la prueba con secuencia de comandos, podrá obtener la cola de solicitudes paso a paso con tiempos y detalles más que suficientes para desarrollar tácticas para mejorar Core Web Vitals con la mayoría de las páginas web. La mayoría de las páginas web son fácilmente proxy, pero su millaje puede variar.
por qué nos importa
Core Web Vitals es un factor de clasificación de la experiencia del usuario de Google. Puede que no sea el impulso más fuerte para su clasificación junto a, por ejemplo, optimizar los títulos de las páginas. Google tiene constancia de que mejorará su clasificación en función de sus puntuaciones. Han declarado que no necesita todos los signos vitales para obtener una puntuación buena para disfrutar del beneficio. Su puntaje óptimo es 90+ y una vez que haya alcanzado el umbral, un puntaje más alto de 90 no es mejor que 90 en sí mismo.
Puntaje LCP antes de una prueba con guión

Puntuación LCP con la prueba con guión...

