Cómo optimizar LCP mediante intercambios firmados

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):

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é:

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 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:

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:

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 un s-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

o dump-signedexchange:

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:

Si la Búsqueda de Google considera que es probable que el usuario haga clic en el resultado, también lo hará previamente:

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:

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:

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:

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 (⌛):

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 rendimiento
• max-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 por User-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:

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).

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 con Chrome
• Browser La versión coincide con la regex ^(9[8-9]|[0-9]{3})
• isSXG coincide exactamente con false

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”:

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

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”:

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.