Cómo optimizar LCP mediante intercambios firmados

Cómo medir y optimizar los intercambios firmados para aprovecharlos al máximo

Devin Mullins

Los intercambios firmados (SXG) son un medio para mejorar la velocidad de tu página, principalmente el Largest Contentful Paint (LCP). Cuando los sitios de referencia (actualmente, la Búsqueda de Google) incluyen vínculos a una página, pueden cargarlos previamente en la caché del navegador antes de que el usuario haga clic en el vínculo.

Es posible hacer que las páginas web que, cuando se carguen previamente, no requieran una red en la ruta crítica para renderizar la página. En una conexión 4G, la carga de esta página va de 2.8 s a 0.9 s (los 0.9 s restantes son principalmente por el uso de CPU):

Nota: Anteriormente, en esta publicación, se mostraba una mejora de 6 s a 0.9 s. Eso era cierto, pero el sitio que se estaba probando era atípicamente lento en ese momento. No obstante, puede servir como ejemplo de páginas con más subrecursos, servidores más lentos o usuarios con tipos de conexión más lenta.

En la actualidad, la mayoría de las personas que publican SXG usan la función Intercambios firmados automáticos (ASX) fácil de usar de Cloudflare (aunque también existen opciones de código abierto):

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 algunos pasos más para garantizar que los 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.

En los últimos meses desde el lanzamiento de Cloudflare, estuve leyendo y respondiendo preguntas en varios foros y aprendí a asesorar a los sitios sobre cómo asegurarse de que aprovechen al máximo sus implementaciones de SXG. Esta publicación es una colección de mis consejos. Te explicaré los pasos para hacer lo siguiente:

• Analiza el rendimiento de SXG con WebPageTest.
• Depura la canalización de SXG si el paso Analyze muestra que no funciona.
• Optimiza las páginas para la carga previa de SXG, lo que incluye configurar un max-age óptimo y precargar subrecursos de bloqueo de procesamiento.
• Medir la mejora de SXG con Google Analytics seleccionando grupos de experimento y 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 forma criptográfica por un certificado Web PKI. Cuando el navegador carga un SXG, verifica todo lo siguiente:

• El SXG no venció.
• 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 trata como si proviniera directamente de la URL firmada. Esto permite que los SXG se vuelvan a alojar en cualquier servidor, siempre que no hayan vencido ni se hayan modificado desde la firma.

En el caso de la Búsqueda de Google, SXG permite la carga previa de páginas en los resultados de la búsqueda. En el caso de las páginas compatibles con SXG, la Búsqueda de Google puede precargar su copia almacenada en caché de la página, alojada en webpkgcache.com. Estas URLs de 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.

Nota: Los SXG pueden ser útiles para otros casos de uso que no se tratan en este artículo. Por ejemplo, podrían habilitar la resiliencia de la conexión: una app de chat podría descargar previamente un vínculo enviado al usuario si la página admite SXG para que más tarde pueda verlo sin conexión. Consulta esta lista más amplia de casos de uso posibles.

Analizar

Para conocer el beneficio de los SXG, comienza usando una herramienta de lab que te permita analizar el rendimiento de los SXG en condiciones repetibles. Puedes usar WebPageTest para comparar cascadas (y LCP) con y sin carga previa de SXG.

Precaución: Los resultados de los labs pueden diferir de las experiencias reales del usuario, pero son una herramienta útil para diagnosticar dónde optimizar y dónde iterar con rapidez. Explicaremos cómo medir las métricas resultantes reales del usuario en la sección Medición.

Genera una prueba sin SXG de la siguiente manera:

• Ve a WebPageTest y accede a tu cuenta. Si accedes a tu cuenta, se guardará tu historial de pruebas para facilitar la comparación en el futuro.
• 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 la prueba sean las mismas).
• En la pestaña Test Settings, puede resultar útil establecer la conexión a 4G y aumentar la "Cantidad de pruebas que se ejecutarán" a 7.
• Haz clic en Iniciar prueba.

Genera una prueba con SXG siguiendo los pasos anteriores, 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 este 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é:

Una vez que se completen estas pruebas, ve al Historial de pruebas, selecciona las dos pruebas y haz clic en Comparar:

Agrega &medianMetric=LCP a la URL de comparación para que WebPageTest seleccione la ejecución con el LCP medio para cada lado de la comparación. (El valor predeterminado es la mediana del Índice de velocidad).

Para comparar las cascadas, expande la sección Waterfall Opacity y arrastra el control deslizante. Para ver el video, haz clic en Adjust Filmstrip Settings, desplázate hacia abajo dentro de ese cuadro de diálogo y haz clic en View Video.

Si la carga previa de SXG se realiza correctamente, verás que la cascada "with SXG" no incluye una fila para el HTML, y las recuperaciones de los subrecursos comienzan antes. Por ejemplo, compara "Antes" y "Después" aquí:

Depuración

Si WebPageTest muestra que el SXG se está cargando previamente, significa que se realizó correctamente todos los pasos de la canalización. Puedes pasar a la sección Optimize para obtener información sobre cómo mejorar aún más el LCP. De lo contrario, deberás averiguar en qué parte de la canalización falló y por qué. Sigue leyendo para obtener más información.

En proceso de publicación

Asegúrate de que tus páginas se generen como SXG. Para hacerlo, debes simular ser un rastreador. La forma más sencilla es utilizar la extensión de Chrome del validador de SXG:

Nota: Los SXG están diseñados para rastreadores compatibles con SXG para habilitar la carga previa. Cuando los usuarios visitan tu sitio directamente, no debes publicar SXG en ellos, ya que no se cargarán previamente, ya que esto solo aumenta la sobrecarga. Cloudflare ASX realiza esta negociación de contenido automáticamente.

La extensión recupera la URL actual con un encabezado de solicitud Accept que indica que prefiere la versión de SXG. Si ves una marca de verificación (✅) junto a Origin, significa que se mostró un SXG. Puedes pasar a la sección Indexación.

Si ves una marca cruzada (❌), significa que no se devolvió un SXG:

Si Cloudflare ASX está habilitado, el motivo más probable de una marca cruzada (❌) es porque un encabezado de respuesta de control de caché lo evita. ASX examina los encabezados que tienen 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 s-maxage mayor o igual que 120

ASX no crea un SXG en estos casos, ya que los SXG se pueden almacenar en caché y volver a usar para varias visitas y varios visitantes.

Otro posible motivo para una marca cruzada (❌) 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.

Nota: Estas restricciones se pueden ver con más detalle en el código ASX. Por ejemplo, el código que determina cuándo firmar y cuál debe ser la duración de la firma inspecciona los encabezados de control de caché. Los demás encabezados se quitan antes de firmar con esta configuración o con este código. Otros encabezados evitan la firma si no se quitan de otro modo.

Otro motivo posible es la presencia de un encabezado de respuesta Vary: Cookie. Googlebot recupera los SXG sin credenciales del usuario y puede mostrárselos a varios visitantes. Si publica código HTML diferente para distintos usuarios según sus cookies, es posible que estos experimenten una experiencia incorrecta, como una vista que indica que no han accedido a su cuenta.

Nota: En el futuro, las páginas que usen Vary: Cookie serán compatibles con SXG y solo se mostrarán a los visitantes que no tengan cookies para tu sitio. Esta función se implementa en Chromium y se habilitará en la Búsqueda de Google cuando se haya lanzado con más frecuencia.

Como alternativa a la extensión de Chrome, puedes usar una herramienta como curl:

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

o dump-signedexchange:

dump-signedexchange -verify -uri $URL

Si el SXG está presente y es válido, verás una impresión legible del SXG. De lo contrario, aparecerá un mensaje de error.

Indexación

Asegúrate de que la Búsqueda de Google indexe correctamente tus SXG. Abra las Herramientas para desarrolladores de Chrome y, luego, realice una búsqueda de Google en su página. Si se indexó como SXG, el vínculo de Google a tu página incluirá un data-sxg-url que dirige a la copia de webpkgcache.com:

Si la Búsqueda de Google considera que es probable que el usuario haga clic en el resultado, también realizará una carga previa:

El elemento <link> le indica al navegador que descargue el SXG en su caché de carga previa. Cuando el usuario hace 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 si vas a la pestaña Red en Herramientas para desarrolladores y buscas URLs que contengan webpkgcache.

Si <a> dirige 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 todavía no haya vuelto a rastrear tu página desde que habilitaste SXG. Prueba la Herramienta de inspección de URLs de Google Search Console:

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 los SXG.

Si un SXG se rastrea correctamente, pero aún no se vincula, es posible que no cumpla con los requisitos de la caché de SXG. Abordaremos esto 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:

Si ves una marca de verificación (✅), puedes pasar a Optimize.

Si no cumple con los requisitos, verás una marca cruzada (❌) y un mensaje de advertencia que indica el motivo:

En este evento, la página funcionará tal como lo hacía antes de habilitar SXG. Google vinculará a la página en su host original sin una carga previa de SXG.

En caso de que la copia almacenada en caché haya vencido y se esté recuperando de nuevo en segundo plano, verás un reloj de arena (⌛):

En el documento para desarrolladores de Google sobre SXG, también se incluyen instrucciones para consultar la caché de forma manual.

Optimiza

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 para obtener la mayor mejora del LCP de SXG.

max-age

Cuando venzan los SXG, la caché de SXG de Google recuperará una copia nueva en segundo plano. Mientras esperan a que se realice la recuperación, se dirige a los usuarios a la página en su host original, que no recibe una carga previa. Cuanto más tiempo establezcas Cache-Control: max-age, menos frecuente será esta recuperación en segundo plano y, por lo tanto, con mayor frecuencia se podrá reducir el LCP mediante la carga previa.

Se trata de un equilibrio entre el rendimiento y la actualización, 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. Anecdóticamente, encontramos que:

• max-age=86400 (1 día) o más sirve para el rendimiento
• max-age=120 (2 minutos) no

Esperamos aprender más acerca de los valores intermedios a medida que estudiamos más los datos.

Nota: Para facilitar la administración de esta compensación en el futuro, agregaremos una API de purga de caché. Se anunciará en el anuncio webpackaging.

user-agent

Una vez, noté un aumento en el LCP cuando se usaba un SXG con carga previa. Ejecutamos WebPageTest y comparé la mediana de los resultados sin y con la carga previa de SXG. Haz clic en Después a continuación:

Noté que la carga previa estaba funcionando. El HTML se quita de la ruta de acceso crítica y, por lo tanto, todos los subrecursos pueden cargarse antes. Sin embargo, el LCP, esa línea punteada verde, aumentó de 2 s a 2.1 s.

Para diagnosticar esto, miré las tiras de película. Descubrí que la página se renderizaba de forma diferente en SXG. En HTML simple, Chrome determinó que el "elemento más grande" del LCP era el título. 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 provocaba que el nuevo elemento más grande fuera el cuadro de diálogo de consentimiento de cookies de carga diferida. Todo se renderiza más rápido que antes, pero un cambio en el diseño hizo que la métrica lo informara como más lento.

Investigué más y descubrí que el motivo de la diferencia en el diseño es que la página varía según User-Agent y había un error en la lógica. Publicaba una página para computadoras a pesar de que el encabezado de rastreo de SXG indicaba que era móvil. Una vez corregido esto, el navegador volvió a identificar correctamente el título de la página como el elemento más grande.

Ahora, haz clic en “After” y vi que el LCP con carga previa disminuye a 1.3 s:

Los SXG están habilitados para todos los factores de forma. Para prepararte, asegúrate de que se cumpla una de las siguientes condiciones:

• Tu página no debe Vary de User-Agent (p.ej., utiliza diseño responsivo o URLs independientes para dispositivos móviles o computadoras de escritorio).
• Si tu página usa la publicación dinámica, se anotará como exclusiva para dispositivos móviles o computadoras de escritorio con <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> de origen (propios) y los convertirá en encabezados de vínculo compatibles con SXG. Consulta los detalles en el código fuente aquí y aquí.

Si funciona, verás cargas previas adicionales de la Búsqueda de Google:

Para optimizar el LCP, observa detenidamente tu cascada y determina 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 crítica. Presta atención a las secuencias de comandos que ocultan la página hasta que terminan de cargarse.

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 recuperarse, para evitar el seguimiento entre sitios. Cuantos más subrecursos haya, es menos probable que todos hayan terminado de cargar previamente antes de que el usuario haga clic en tu página.

Nota: Actualmente, ASX solo admite la carga previa para subrecursos del mismo origen (propios). Si conoces proveedores de subrecursos externos que admitan SXG, avísanos sobre este error para que podamos priorizar la incorporación de compatibilidad con orígenes cruzados.

Por el momento, el validador de SXG no verifica los subrecursos. Mientras tanto, usa curl o dump-signedexchange para realizar la depuración.

Medir

Después de optimizar la mejora de 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 las métricas del servidor, como el tiempo hasta el primer byte (TTFB), es importante que tengas en cuenta que tu sitio solo publica SXG en los rastreadores que aceptan el formato. Limita tu medición del TTFB a las solicitudes que provienen de usuarios reales, no de bots. Es posible que la generación de SXG aumente el TTFB de las solicitudes del rastreador, pero esto no afecta la experiencia de tus visitantes.

Métricas del cliente

Los SXG ofrecen el mayor beneficio de velocidad para las métricas del cliente, especialmente LCP. Para medir su impacto, simplemente puedes habilitar Cloudflare ASX, esperar a que Googlebot vuelva a rastrearlo, esperar 28 días más para la agregación de las Métricas web esenciales (CWV) y, luego, consultar tus nuevas cifras de Métricas web esenciales. Sin embargo, puede ser difícil detectar el cambio si se mezcla con todos los demás cambios durante este período.

En cambio, me resulta útil “acercar” las cargas de páginas potencialmente afectadas y enmarcarlas 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 ocurre en determinadas condiciones:

• Navegador Chromium (p.ej., Chrome o Edge, excepto en iOS), versión M98 o posterior
• Referer: google.com o bien otros dominios 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, vinculada directamente desde la Búsqueda de Google.

Nota: La Búsqueda de Google planea expandir los contextos en los que puede ocurrir la carga previa de SXG, incluidos los SO de computadoras de escritorio, entre otros. Esto puede aumentar el X% con el tiempo y también significa que es posible que desees actualizar tus métricas para adaptarse al cambio. Cuando eso suceda, se debe anunciar en webpackaging-announce.

Consulta la sección de 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

Al observar los datos de supervisión de usuarios reales (RUM), debes dividir las cargas de página en SXG y en las que no sean SXG. Cuando lo hagas, es fundamental limitar el conjunto de cargas de página que ves, de modo que el lado que no es de SXG coincida con las condiciones de elegibilidad de SXG para evitar el sesgo de selección. De lo contrario, todo lo siguiente existiría solo en el conjunto de cargas de páginas que no sean de SXG, que pueden tener un LCP intrínsecamente diferente:

• Dispositivos iOS: Esto se debe a las diferencias en la velocidad de red o hardware 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 hace que se elija un "elemento más grande" diferente.
• Navegaciones por el mismo sitio (los visitantes que siguen los vínculos dentro del sitio): porque pueden volver a usar subrecursos almacenados en caché de la carga de página anterior.

En Google Analytics (UA), crea dos dimensiones personalizadas con el alcance "Hit", una llamada "isSXG" y otra "referrer". (La dimensión integrada "Fuente" tiene el alcance de la sesión, por lo que no excluye las navegaciones del mismo sitio).

Cree un segmento personalizado llamado "Contrafáctico SXG" con los siguientes filtros combinados mediante el operador Y:

• La "referrer" comienza con "https://www.google."
• Browser coincide exactamente con Chrome
• La versión de Browser coincide con la regex ^(9[8-9]|[0-9]{3})
• isSXG coincide exactamente con false

Crea una copia de este segmento, denominado "SXG", excepto que isSXG coincide exactamente con true.

En la plantilla de tu sitio, agrega el siguiente fragmento arriba del fragmento de Google Analytics. Esta es una sintaxis especial con la que ASX cambiará false a true cuando genere un SXG:

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

Personaliza la secuencia de comandos de los informes de Google Analytics como se recomienda para registrar 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 se deben usar):

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

Si utilizas analytics.js, modifica el comando 'create' como se documenta aquí.

Después de esperar algunos días para recopilar algunos datos, ve al informe de eventos de Google Analytics y agrega un desglose del segmento SXG. Esto debería llenar la X de "Los SXG afectan al X% de las vistas de página":

Por último, ve al Informe de Métricas web, selecciona "Elegir segmentos" y selecciona "Contrafáctico de SXG" y "SXG".

Haz clic en "Enviar" y deberías ver las distribuciones LCP de los dos segmentos. Esto debería completar la Y para “mejorar su LCP en Y milisegundos en el percentil 75”:

Advertencias

Una vez que hayas aplicado todos los filtros anteriores, las cargas de páginas contrafácticas de SXG deberían incluir los siguientes elementos:

• Errores de caché: Si la caché de SXG de Google no tiene una copia nueva de SXG para una URL determinada, redireccionará a la URL original de tu sitio.
• Otros tipos de resultados: Actualmente, la Búsqueda de Google solo admite SXG para los resultados web estándar y algunos otros tipos. Otras, como los fragmentos destacados y el carrusel de Historias destacadas, incluirán un vínculo a la URL original de tu sitio.
• URLs no aptas: Si algunas páginas de tu sitio no son aptas para SXG (p.ej., porque no se pueden almacenar en caché), es posible que aparezcan en este conjunto.

Es posible que haya sesgo restante entre las cargas de páginas de SXG y el conjunto anterior 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 de 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 se pueden almacenar en caché. Si sospechas que esto podría ser un problema, considera consultar los datos limitados a una URL específica para SXG apta para ver si sus resultados coinciden con los del estudio general.

Si tu sitio tiene algunas páginas de AMP, es probable que no vean mejoras de rendimiento al habilitar SXG, dado que ya se pueden cargar previamente desde la Búsqueda de Google. Considera agregar un filtro para excluir este tipo de páginas y "acercar" los cambios relevantes.

Por último, incluso cuando se aborda todos los sesgos de selección, existe el riesgo de que el sesgo de supervivencia haga que las mejoras del LCP parezcan degradaciones en las estadísticas de RUM. Este artículo explica muy bien ese riesgo y sugiere observar alguna forma de métrica de abandono para detectar si esto ocurre.

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. Para eliminar los posibles sesgos mencionados anteriormente, no debes limitarte a las páginas vistas de SXG. En su lugar, observa los resultados aptos de 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 para ellas. Durante esas semanas, pueden producirse otros sesgos como los siguientes:

• Las nuevas versiones del navegador o las mejoras en el hardware de los usuarios pueden acelerar la carga de las páginas.
• Un evento importante, como un día feriado, puede sesgar el tráfico de la normalidad.

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 total. Por ejemplo, supongamos que SXG mejora el 10% de las cargas de páginas en 800 ms.

• Si estas ya eran las cargas de páginas un 10% más rápidas, no afectará el percentil 75 en absoluto.
• Si fueron las cargas de páginas un 10% más lentas, pero fueron más de 800 ms más lentas que el LCP del percentil 75 en primer lugar, entonces no afectará al percentil 75 en absoluto.

Estos son ejemplos extremos, probablemente no reflejan la realidad, pero esperamos que ilustren el problema. En la práctica, es probable que SXG afecte el percentil 75 para 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.

Inhabilitar algunas URLs

Por último, una forma de comparar el rendimiento de SXG podría ser inhabilitar SXG para algún 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. No se recomienda hacer esto.

Es probable que tenga un riesgo mayor de sesgo de selección que los otros métodos de estudio. Por ejemplo, puede marcar una gran diferencia si se selecciona la página principal de tu sitio o una URL similar popular en el grupo de control o en el grupo experimental.

Estudio de aislamiento

La forma ideal de medir el impacto sería realizar un estudio de aislamiento. Lamentablemente, no puedes hacer este tipo de prueba en este momento. Planeamos agregar compatibilidad para esta prueba en el futuro.

Un estudio de aislamiento tiene las siguientes propiedades:

• En el grupo experimental, se "retiene" una fracción aleatoria de las vistas de páginas que serían de SXG y se publican como elementos que no son de SXG. Esto permite realizar una comparación de elementos similares entre usuarios, dispositivos, situaciones y páginas equivalentes.
• Esas vistas de página retenidas (también conocidas como contrafácticas) se etiquetan como tales en las estadísticas. Esto permite una vista "con zoom" 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 las otras cargas de página que no se verían afectadas por la carga previa de SXG.

Esto eliminaría las posibles fuentes de sesgo de selección antes mencionadas, aunque no eliminaría el riesgo del sesgo de supervivencia de LCP. Ambas propiedades requieren que se habilite el navegador o la URL de referencia.

Conclusión

¡Vaya! Eso fue mucho. Esperamos que ofrezca un panorama más completo de cómo probar el rendimiento de SXG en una prueba de lab, cómo optimizar su rendimiento en un ciclo de reacción estrecho con la prueba de laboratorio y, por último, cómo medir su rendimiento en el mundo real. Unificar todo esto debería ayudarte a aprovechar al máximo los SXG y asegurarte de que beneficien a tu sitio y a tus usuarios.

Comunícate con nosotros si tienes más sugerencias sobre cómo captar el rendimiento de SXG. 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.