Cómo medir y optimizar los intercambios firmados para aprovecharlos al máximo
Los intercambios firmados (SXG) son una forma de mejorar la velocidad de tu página, principalmente el Largest Contentful Paint (LCP). Cuando se refieren sitios (actualmente, la Búsqueda de Google) a una página, pueden precargarlo en la caché del navegador antes de que el usuario haga clic en el vínculo.
Es posible crear páginas web que, cuando se realiza la carga previa, no requieran red en la ruta de acceso crítica para renderizar la página. En una conexión 4G, esta carga de página va de 2.8 s a 0.9 s (los 0.9 s restantes son principalmente por el uso de la CPU):
En la actualidad, la mayoría de las personas que publican SXG usan la función de intercambios firmados automáticos (ASX) fácil de usar de Cloudflare (aunque también existen opciones de código abierto):
![Panel de configuración de Cloudflare con una casilla de verificación para habilitar los intercambios firmados automáticos](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/cloudflare-settings-panel-5a154cefaeee.png?authuser=0000&hl=es)
En muchos casos, marcar la casilla para habilitar esta función es suficiente para obtener el tipo de mejora sustancial que se muestra arriba. A veces, hay que seguir algunos pasos más para garantizar que estos SXG funcionen según lo previsto en cada etapa de la canalización y optimizar las páginas para aprovechar al máximo la carga previa.
Durante los últimos meses desde el lanzamiento de Cloudflare, estuve leyendo y respondiendo preguntas en varios foros. Además, aprendí a asesorar a los sitios sobre cómo asegurarse de aprovechar al máximo sus implementaciones de SXG. Esta publicación es una recopilación de mis consejos. Te explicaremos los pasos para hacer lo siguiente:
- Analiza el rendimiento de SXG con WebPageTest.
- Depura la canalización de SXG si el paso analizar muestra que no funciona.
- Optimiza las páginas para la carga previa de SXG, incluida la configuración de un
max-age
óptimo y la precarga de subrecursos que bloquean el procesamiento. - Mida la mejora de SXG con Google Analytics. Para ello, seleccione los grupos experimentales y de control adecuados.
Introducción
Un SXG es un archivo que contiene una URL, un conjunto de encabezados de respuesta HTTP y un cuerpo de respuesta, todo firmado de manera criptográfica por un certificado de PKI web. Cuando el navegador carga un SXG, verifica todo lo siguiente:
- El SXG no debe estar vencido.
- La firma coincide con la URL, los encabezados, el cuerpo y el certificado.
- El certificado es válido y coincide con la URL.
Si falla la verificación, el navegador abandona el SXG y, en su lugar, recupera la URL firmada. Si la verificación se realiza correctamente, el navegador carga la respuesta firmada y la considera como si proviniera directamente de la URL firmada. Esto permite volver a alojar los SXG en cualquier servidor, siempre y cuando no haya vencido ni se haya modificado desde que se firmó.
En el caso de la Búsqueda de Google, SXG habilita la carga previa de páginas en los resultados de la búsqueda. En el caso de las páginas que admiten SXG, la Búsqueda de Google puede cargar previamente la copia almacenada en caché de la página, alojada en webpkgcache.com. Estas URLs webpkgcache.com no afectan la visualización ni el comportamiento de la página, ya que el navegador respeta la URL original firmada. La carga previa puede permitir que tu página se cargue mucho más rápido.
Analizar
Para ver el beneficio de los SXG, comienza por usar una herramienta de lab para analizar el rendimiento de SXG en condiciones repetibles. Puedes usar WebPageTest para comparar cascadas (y LCP) con y sin carga previa de SXG.
Genera una prueba sin SXG de la siguiente manera:
- Ve a WebPageTest y accede a tu cuenta. Cuando accedes, se guarda tu historial de pruebas para facilitar la comparación más adelante.
- Ingresa la URL que quieres probar.
- Ve a Configuración avanzada. (Necesitarás la configuración avanzada para la prueba SXG, por lo que usarla aquí ayuda a garantizar que las opciones de prueba sean las mismas).
- En la pestaña Test Settings, puede ser útil establecer Connection en 4G y aumentar la "Number of Tests to Run" a 7.
- Haz clic en Comenzar prueba.
Genera una prueba con SXG siguiendo los mismos pasos que se indican más arriba, pero antes de hacer clic en Iniciar prueba, ve a la pestaña Secuencia de comandos, pega la siguiente secuencia de comandos de WebPageTest y modifica las dos URLs navigate
como se indica:
// 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
En el caso de la primera URL de navigate
, si tu página aún no aparece en ningún resultado de la Búsqueda de Google, puedes usar esta página de carga previa para generar una página de resultados de búsqueda simulada para ese fin.
Para determinar la segunda URL de navigate
, visita tu página con la extensión de Chrome del validador de SXG y haz clic en el ícono de la extensión para ver la URL almacenada en caché:
![El validador de SXG muestra la información de la caché, incluida la URL](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-cac-cd00f49c76676.png?authuser=0000&hl=es)
Una vez que se completen estas pruebas, ve al Historial de pruebas, selecciona las dos pruebas y haz clic en Comparar:
![Historial de pruebas con dos pruebas marcadas y el botón Comparar destacado](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/test-history-two-tests-c-c2bdb42542715.png?authuser=0000&hl=es)
Agrega &medianMetric=LCP
a la URL de comparación para que WebPageTest seleccione la ejecución con la mediana de LCP para cada lado de la comparación. (El valor predeterminado es la mediana por índice de velocidad).
Para comparar las cascadas, expande la sección Opacidad de cascada y arrastra el control deslizante. Para ver el video, haz clic en Ajustar la configuración de la tira de película, desplázate hacia abajo dentro de ese cuadro de diálogo y haz clic en Ver video.
Si la carga previa de SXG se realiza correctamente, verás que el mensaje "con SXG" La cascada no incluye una fila para el HTML, y las recuperaciones de subrecursos comienzan antes. Por ejemplo, compara "Antes" y "Después" aquí:
Depurar
Si WebPageTest muestra que se está realizando la carga previa del SXG, significa que se realizó correctamente en todos los pasos de la canalización. Puedes pasar a la sección Optimizar para descubrir cómo seguir mejorando el LCP. De lo contrario, deberás averiguar en qué parte de la canalización falló y por qué. Continúa leyendo para saber cómo hacerlo.
Publicación
Asegúrate de que tus páginas se generen como SXG. Para ello, debes simular ser un rastreador. La forma más sencilla es utilizar la extensión de Chrome del validador de SXG:
![El validador de SXG muestra una marca de verificación (✅) y un tipo de contenido de aplicación/intercambio firmado. v=b3](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-ch-663e5b3cc9f67.png?authuser=0000&hl=es)
La extensión recupera la URL actual con un encabezado de solicitud Accept
que dice que prefiere la versión de SXG. Si ves una marca de verificación (✅) junto a Origin, significa que se devolvió un SXG. Puedes pasar a la sección Indexación.
Si ves una marca de tachado (❌), significa que no se devolvió un SXG:
![El validador de SXG muestra una marca de tachado (❌) y un tipo de contenido de texto/html](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-cr-555ac59fdd27f.png?authuser=0000&hl=es)
Si Cloudflare ASX está habilitado, el motivo más probable de una marca de tachado (❌) es que un encabezado de respuesta de control de caché lo impide. ASX examina los encabezados con los siguientes nombres:
Cache-Control
CDN-Cache-Control
Surrogate-Control
Cloudflare-CDN-Cache-Control
Si alguno de estos encabezados contiene alguno de los siguientes valores de encabezado, impedirá que se genere un SXG:
private
no-store
no-cache
max-age
menor que 120, a menos que la anule uns-maxage
mayor o igual que 120
ASX no crea una SXG en estos casos, ya que las SXG se pueden almacenar en caché y reutilizar para varias visitas y varios visitantes.
Otro posible motivo de una marca de tachado (❌) es la presencia de uno de estos encabezados de respuesta con estado, excepto por Set-Cookie
. ASX quita el encabezado Set-Cookie
para cumplir con la especificación de SXG.
Otro posible motivo es la presencia de un encabezado de respuesta Vary: Cookie
. Googlebot recupera SXG sin credenciales del usuario y puede entregarlos a varios visitantes. Si publicas diferentes HTML a distintos usuarios en función de sus cookies, es posible que vean una experiencia incorrecta, como una vista sin acceder a la cuenta.
Como alternativa a la extensión de Chrome, puedes usar una herramienta como curl
:
curl -siH "Accept: application/signed-exchange;v=b3" $URL | less
dump-signedexchange -verify -uri $URL
Si el SXG está presente y es válido, verás una impresión legible por humanos del SXG. De lo contrario, verás un mensaje de error.
Indexación
Asegúrate de que tus SXG se hayan indexado correctamente en la Búsqueda de Google. Abre las Herramientas para desarrolladores de Chrome y, luego, realiza una Búsqueda de Google para tu página. Si se indexó como SXG, el vínculo de Google a tu página incluirá un data-sxg-url
que dirija a la copia de webpkgcache.com:
![Resultados de la Búsqueda de Google con Herramientas para desarrolladores que muestran una etiqueta fija que apunta a webpkgcache.com](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-search-results-de-57d0db7b9c20a.png?authuser=0000&hl=es)
Si la Búsqueda de Google considera que es probable que el usuario haga clic en el resultado, también lo hará previamente:
![Resultados de la Búsqueda de Google con Herramientas para desarrolladores que muestran un vínculo con rel=prefetch para webpkgcache.com](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-search-results-de-3127d5a0a1ef9.png?authuser=0000&hl=es)
El elemento <link>
le indica al navegador que descargue el SXG en su caché de carga previa. Cuando el usuario haga clic en el elemento <a>
, el navegador usará ese SXG almacenado en caché para renderizar la página.
También puedes ver evidencia de la carga previa yendo a la pestaña Red en Herramientas para desarrolladores y buscando URLs que contengan webpkgcache
.
Si <a>
apunta a webpkgcache.com, significa que funciona la indexación de la Búsqueda de Google del intercambio firmado. Puedes avanzar a la sección Transferencia.
De lo contrario, es posible que Google no haya vuelto a rastrear tu página desde que habilitaste SXG. Prueba la Herramienta de inspección de URLs de Google Search Console:
![Herramienta de inspección de URLs de Search Console, haciendo clic en Ver página rastreada y, luego, en Más información](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/search-console-url-inspec-3f054b4eeeef4.png?authuser=0000&hl=es)
La presencia de un encabezado digest: mi-sha256-03=...
indica que Google rastreó correctamente la versión de SXG.
Si no hay un encabezado digest
, esto podría indicar que no se publicó un SXG para Googlebot o que el índice no se actualizó desde que habilitaste SXG.
Si un SXG se rastrea correctamente, pero todavía no se vincula, es posible que no se cumplan los requisitos de caché de SXG. Los analizaremos en la siguiente sección.
Transferencia
Cuando la Búsqueda de Google indexa un SXG, envía su copia a la caché de SXG de Google, que la valida en función de los requisitos de la caché. La extensión de Chrome muestra el resultado:
![El validador de SXG muestra una marca de verificación (✅) y no muestra ningún mensaje de advertencia](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-ch-1282069b578ae.png?authuser=0000&hl=es)
Si ves una marca de verificación (✅), puedes avanzar a Optimizar.
Si no cumple con los requisitos, verás una marca de tachado (❌) y un mensaje de advertencia en el que se indicará el motivo:
![El validador de SXG muestra una marca de tachado (❌) y un mensaje de advertencia que dice](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-cr-69db2da79bd7b.png?authuser=0000&hl=es)
En este caso, la página funcionará como lo hacía antes de habilitar SXG. Google vinculará a la página en su host original sin una carga previa de SXG.
Si la copia almacenada en caché venció y se vuelve a recuperar en segundo plano, verás un reloj de arena (⌛):
![El validador de SXG muestra un reloj de arena (⌛) y ningún mensaje de advertencia](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-ho-dcbdc4694a3f.png?authuser=0000&hl=es)
En el documento para desarrolladores de Google sobre SXG, también se incluyen instrucciones para consultar la caché de forma manual.
Optimizar
Si la extensión de Chrome del validador de SXG muestra todas las marcas de verificación (✅), tienes una SXG que se puede publicar para los usuarios. Sigue leyendo para descubrir cómo optimizar tu página web a fin de obtener la mejora mayor de LCP de SXG.
edad máxima
Cuando venzan los SXG, la caché de SXG de Google recuperará una nueva copia en segundo plano. Mientras se espera la recuperación, se dirige a los usuarios a la página en su host original, que no se carga previamente. Mientras más tiempo establezcas Cache-Control: max-age
, con menos frecuencia se realizará esta recuperación en segundo plano y, por lo tanto, será más frecuente que se reduzca el LCP mediante la carga previa.
Esta es una compensación entre rendimiento y actualidad, y la caché permite a los propietarios de sitios proporcionar SXG con una antigüedad máxima de entre 2 minutos y 7 días, según las necesidades particulares de cada página. De manera anecdótica, descubrimos lo siguiente:
max-age=86400
(1 día) o más funciona bien para mejorar el rendimientomax-age=120
(2 minutos) no
A medida que estudiamos más los datos, esperamos aprender más sobre los valores intermedios.
user-agent
Una vez, vi un aumento en el LCP cuando se usaba un SXG cargado previamente. Ejecuté WebPageTest y comparé la mediana de resultados sin carga previa de SXG y con ella. Haz clic en Después a continuación:
Noté que la carga previa funcionaba. El HTML se quita de la ruta crítica y, por lo tanto, todos los subrecursos pueden cargarse antes. Pero el LCP (esa línea punteada verde) aumentó de 2 s a 2.1 s.
Para diagnosticarlo, vi las tiras de película. Descubrimos que la página se procesaba de manera diferente en SXG. En HTML sin formato, Chrome determinó que el "elemento más grande" de LCP fue el titular. Sin embargo, en la versión de SXG, la página agregó un banner de carga diferida que colocaba el título en la mitad inferior de la página y hacía que el nuevo elemento más grande fuera el diálogo de consentimiento de uso de cookies de carga diferida. Todo se procesó más rápido que antes, pero la métrica lo informó como más lento debido a un cambio en el diseño.
Investigué en más detalle y descubrí que el motivo de la diferencia en el diseño es que la página varía según User-Agent
, y hubo un error en la lógica. Publicaba una página para computadoras de escritorio, aunque el encabezado de rastreo de SXG indicaba dispositivos móviles. Una vez corregido, el navegador volvió a identificar correctamente el título de la página como su elemento más grande.
Ahora, cuando hago clic en “Después”, vi que el LCP cargado previamente cae a 1.3 s:
Los SXG están habilitados para todos los factores de forma. Para prepararte para ello, asegúrate de que se cumpla una de las siguientes condiciones:
- Tu página no
Vary
porUser-Agent
(p.ej., utiliza diseño responsivo o URLs independientes para computadoras de escritorio y dispositivos móviles). - Si tu página usa la publicación dinámica, se anota como solo para dispositivos móviles o computadoras de escritorio mediante
<meta name=supported-media content=...>
.
Subrecursos
Los SXG se pueden usar para realizar una carga previa de subrecursos (incluidas las imágenes) junto con el HTML. Cloudflare ASX analizará el código HTML en busca de elementos <link rel=preload>
del mismo origen (propios) y los convertirá en encabezados de vínculo compatibles con SXG. Obtén más detalles en el código fuente aquí y aquí.
Si funciona, verás solicitudes previas adicionales de la Búsqueda de Google:
![Resultados de la Búsqueda de Google con la pestaña Network de Herramientas para desarrolladores, que muestra una carga previa de /sub/.../image.jpg](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-search-results-de-50436b3876448.png?authuser=0000&hl=es)
Para optimizar el LCP, observa tu cascada y averigua qué recursos se encuentran en la ruta crítica para renderizar el elemento más grande. Si no se pueden cargar previamente, considera si se pueden quitar de la ruta de acceso crítica. Presta atención a las secuencias de comandos que ocultan la página hasta que se terminen de cargar.
La caché de SXG de Google permite hasta 20 precargas de subrecursos y ASX garantiza que no se supere este límite. Sin embargo, existe el riesgo de agregar demasiadas precargas de subrecursos. El navegador solo usará subrecursos precargados si todos ellos terminaron de recuperar, para evitar el seguimiento entre sitios. Cuantos más subrecursos haya, es menos probable que todos ellos hayan terminado de cargarse antes de que el usuario haga clic para ir a la página.
Actualmente, el validador de SXG no verifica los subrecursos. para depurar, usa curl
o dump-signedexchange
mientras tanto.
Medir
Después de optimizar la mejora del LCP en WebPageTest, es útil medir el impacto de la carga previa de SXG en el rendimiento general de tu sitio.
Métricas del servidor
Cuando midas métricas del servidor, como el tiempo hasta el primer byte (TTFB), es importante tener en cuenta que tu sitio solo publica SXG para rastreadores que aceptan el formato. Limita la medición del TTFB a las solicitudes que provienen de usuarios reales, no de bots. Tal vez notes que generar SXG aumenta el TTFB de las solicitudes del rastreador, pero esto no afecta la cantidad de clics una experiencia fluida a los desarrolladores.
Métricas del cliente
Los SXG producen el mayor beneficio de velocidad para las métricas del cliente, especialmente el LCP. Cuando midas su impacto, simplemente puedes habilitar Cloudflare ASX, esperar a que Googlebot vuelva a rastrearlo, esperar 28 días adicionales para la agregación de Métricas web esenciales (CWV) y, luego, consultar tus nuevas cifras de CWV. Sin embargo, es posible que el cambio sea difícil de detectar si se combina con todos los demás cambios durante este período.
En cambio, me resulta útil "acercar la imagen" en las cargas de páginas potencialmente afectadas y enmarcarlo como: "Los SXG afectan el X% de las vistas de página, lo que mejora su LCP en Y milisegundos en el percentil 75".
Actualmente, la carga previa de SXG solo se produce en determinadas condiciones:
- Navegador Chromium (p.ej., Chrome o Edge, excepto en iOS), versión M98 o posterior
Referer: google.com
o algún otro dominio de búsqueda de Google Ten en cuenta que, en Google Analytics, una etiqueta de referencia se aplica a todas las vistas de página de la sesión, mientras que la carga previa de SXG solo se aplica a la primera vista de página, directamente vinculada desde la Búsqueda de Google.
Consulta la sección Estudio contemporáneo para obtener información sobre cómo medir el "X% de las vistas de página". y “mejorar su LCP en Y milisegundos”.
Estudio contemporáneo
Cuando se observan datos de supervisión de usuarios reales (RUM), se deben dividir las cargas de página en SXG y no en SXG. Cuando lo hagas, es fundamental limitar el conjunto de cargas de páginas que miras, de modo que el lado que no sea de SXG coincida con las condiciones de elegibilidad de SXG y, así, evitar el sesgo de selección. De lo contrario, todos los siguientes elementos existirían solo en el conjunto de cargas de páginas que no son de SXG, que pueden tener un LCP completamente diferente:
- Dispositivos iOS: Debido a las diferencias en el hardware o la velocidad de la red entre los usuarios que tienen estos dispositivos.
- Navegadores Chromium más antiguos: Por los mismos motivos.
- Dispositivos de escritorio: por los mismos motivos o porque el diseño de la página genera un "elemento más grande" diferente elegir.
- Navegaciones del mismo sitio (los visitantes siguen los vínculos dentro del sitio): Porque pueden reutilizar los subrecursos almacenados en caché de la carga anterior de la página.
En Google Analytics (UA), crea dos dimensiones personalizadas con el alcance "Hit" y una llamada "isSXG". y otro llamado “referrer”. (La dimensión "Fuente" integrada tiene alcance de sesión, de manera que no excluye las navegaciones en el mismo sitio).
![Editor de dimensiones de Google Analytics con configuración recomendada](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-analytics-dimensio-f031123b0438f.png?authuser=0000&hl=es)
Crea un segmento personalizado llamado "Contrafáctico de SXG". con los siguientes filtros unidos por tipo AND:
- La "
referrer
" comienza con "https://www.google.
" Browser
coincide exactamente conChrome
Browser
La versión coincide con la regex^(9[8-9]|[0-9]{3})
isSXG
coincide exactamente confalse
![Editor de segmentos de Google Analytics con filtros recomendados](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-analytics-segment-14980677de979.png?authuser=0000&hl=es)
Crea una copia de este segmento, llamada "SXG", excepto que isSXG
coincida exactamente con true
.
En la plantilla de tu sitio, agrega el siguiente fragmento arriba del fragmento de Google Analytics. Esta es una sintaxis especial que ASX cambiará false
a true
cuando genere un SXG:
<script data-issxg-var>window.isSXG=false</script>
Personaliza la secuencia de comandos de informes de Google Analytics como se recomienda para grabar el LCP. Si utilizas gtag.js, modifica el comando 'config'
para establecer la dimensión personalizada (reemplaza 'dimension1'
y 'dimension2'
por los nombres que Google Analytics indica que deben usarse):
gtag('config', 'YOUR_TRACKING_ID', {
'dimension1': String(isSXG),
'dimension2': document.referrer,
});
Si usas analytics.js, modifica el comando 'create'
como se documenta aquí.
Después de esperar unos días para recopilar algunos datos, ve al informe Eventos de Google Analytics y agrega un desglose para el segmento de SXG. Esto debería completar la X de “Los SXG afectan el X% de las vistas de página”:
![El informe de eventos de Google Analytics con el segmento SXG, que muestra un 12.5% de eventos únicos](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-analytics-events-r-cbf7d46bbd64e.png?authuser=0000&hl=es)
Por último, ve al Informe de Métricas web, selecciona "Elegir segmentos" y, luego, "Contrafáctico de SXG". y "SXG".
![Informe de métricas web con selecciones de SXG contrafáctico y SXG](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/web-vitals-report-select-d978e48f3498e.png?authuser=0000&hl=es)
Haz clic en "Submit" (Enviar). Deberías ver las distribuciones de LCP para los dos segmentos. Esto debería completar el Y para “mejorar su LCP en Y milisegundos en el percentil 75”:
![Informe de Métricas web que muestra distribuciones de LCP para SXG contrafáctico y SXG](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/web-vitals-report-showing-07708e1eca8c5.png?authuser=0000&hl=es)
Advertencias
Una vez que hayas aplicado todos los filtros anteriores, las cargas de páginas contrafácticas de SXG deberían constar de lo siguiente:
- Errores de caché: Si la caché de SXG de Google no tiene una copia nueva del SXG para una URL determinada, se redireccionará a la URL original de tu sitio.
- Otros tipos de resultados: Actualmente, la Búsqueda de Google solo admite SXG para resultados web estándar y algunos otros tipos. Otros, como los Fragmentos destacados y el carrusel de Noticias destacadas, vincularán a la URL original de tu sitio.
- URL no aptas: Si algunas páginas de tu sitio no son aptas para SXG (p.ej., porque no se pueden almacenar en caché), podrían aparecer en este conjunto.
Es posible que haya un sesgo restante entre las cargas de páginas de SXG y el conjunto anterior de cargas de páginas que no son de SXG, pero debería ser de menor magnitud que los sesgos mencionados en la parte superior de la sección Estudio contemporáneo. Por ejemplo, es posible que tus páginas que no se pueden almacenar en caché sean más lentas o más rápidas que las páginas que sí pueden almacenarse en caché. Si crees que podría tratarse de un problema, considera revisar los datos limitados a una URL específica apta para SXG para ver si los resultados coinciden con el estudio general.
Si tu sitio tiene algunas páginas de AMP, es probable que no vean mejoras de rendimiento cuando habilites SXG, ya que se pueden obtener previamente desde la Búsqueda de Google. Considerar la posibilidad de agregar un filtro para excluir esas páginas y poder "acercar aún más" los cambios relevantes.
Por último, incluso cuando se abordan todos los sesgos de selección, existe el riesgo de que el sesgo de supervivencia haga que las mejoras de LCP parezcan degradaciones en las estadísticas de RUM. En este artículo, se explica muy bien este riesgo y se sugiere buscar algún tipo de métrica de abandono para detectar si esto está sucediendo.
Antes y después del estudio
Para corroborar los resultados del estudio contemporáneo, puede ser útil hacer una comparación del LCP antes y después de habilitar SXG. No limites las páginas vistas de SXG para eliminar los posibles sesgos mencionados anteriormente. En su lugar, observa los resultados aptos para SXG: las definiciones de segmentos anteriores, pero sin la restricción isSXG
.
Ten en cuenta que la Búsqueda de Google puede tardar varias semanas en volver a rastrear todas las páginas de tu sitio para identificar que se habilitó SXG. En esas semanas, pueden surgir otros sesgos posibles:
- Las nuevas versiones del navegador o nuevas mejoras en las contraseñas de los usuarios hardware puede acelerar la carga de páginas.
- Un evento significativo, como una festividad, puede alterar el tráfico de lo normal.
También es útil observar el LCP general del percentil 75 antes y después para confirmar los estudios anteriores. Aprender sobre un subconjunto de la población no necesariamente nos dice acerca de la población general. Por ejemplo, supongamos que SXG mejora el 10% de las cargas de página en 800 ms.
- Si estas ya eran las cargas de página un 10% más rápidas, esto no afectará en absoluto al percentil 75.
- Si fueran las cargas de páginas un 10% más lentas, pero, en primer lugar, estuvieron más de 800 ms más lentas que el LCP del percentil 75, esto no afectará en absoluto al percentil 75.
Estos son ejemplos extremos, probablemente no reflejan la realidad, pero esperamos que ilustren el problema. En la práctica, es probable que SXG afecte al percentil 75 de la mayoría de los sitios. Las navegaciones entre sitios suelen ser algunas de las más lentas, y las mejoras de la carga previa tienden a ser significativas.
Cómo inhabilitar algunas URLs
Por último, una forma de comparar el rendimiento de SXG podría ser inhabilitar SXG para un subconjunto de URLs de tu sitio. Por ejemplo, puedes configurar un encabezado CDN-Cache-Control: no-store
para evitar que Cloudflare ASX genere un SXG. Te recomiendo que no lo hagas.
Es probable que tenga un mayor riesgo de sesgo de selección que los otros métodos del estudio. Por ejemplo, puede marcar una gran diferencia si la página principal de tu sitio o una URL popular similar se selecciona en el grupo de control o en el grupo experimental.
Estudio de aislamiento
La forma ideal de medir el impacto sería llevar a cabo un estudio de aislamiento. Lamentablemente, no puedes hacer este tipo de prueba por el momento. Planeamos agregar compatibilidad para esta prueba en el futuro.
Un estudio de aislamiento tiene las siguientes propiedades:
- En el grupo experimental, una fracción aleatoria de las páginas vistas que serían SXG se "retienen" y se publican como sin SXG. Esto permite un diálogo de “manzana con manzana” comparación entre usuarios, dispositivos, situaciones y páginas equivalentes.
- Las vistas de página retenidas (también conocidas como contrafácticas) se etiquetan como tales en las estadísticas. Esto permite un acercamiento de los datos, en la que podemos comparar las cargas de páginas de SXG en el control con los contrafácticos de SXG en el experimento. Esto, a su vez, reduce el ruido de otras cargas de página que no se verían afectados por la carga previa de SXG.
Esto eliminaría las posibles fuentes ya mencionadas de sesgo de selección, aunque no eliminaría el riesgo de sesgo de supervivencia de LCP. Para ambas propiedades, se necesita el navegador o la URL de referencia.
Conclusión
¡Vaya! Eso fue mucho. Esperamos que proporcione un panorama más completo de cómo probar el rendimiento de SXG en una prueba de laboratorio, cómo optimizar su rendimiento en un ciclo de reacción cerrado con la prueba de laboratorio y, por último, cómo medir su rendimiento en el mundo real. Combinar todos estos aspectos debería ayudarlo a aprovechar al máximo las SXG y garantizar que beneficien a su sitio y a sus usuarios.
Si tienes más consejos sobre cómo capturar el rendimiento de SXG, comunícate con nosotros. Informa un error en developer.chrome.com con las mejoras sugeridas.
Para obtener más información sobre los intercambios firmados, consulta la documentación de web.dev y la documentación de la Búsqueda de Google.