Empezar a usar intercambios firmados en la Búsqueda de Google

Signed exchanges (SXG) permite que la Búsqueda de Google precargue tu contenido y, al mismo tiempo, se respete la privacidad del usuario. En la práctica, significa que tanto los resultados AMP como los que no son AMP que se muestran en la Búsqueda de Google pueden precargar algunos recursos clave (como HTML, JavaScript, CSS, imágenes o fuentes) respetando la privacidad, si el sitio web asociado admite SXG.

Cuando el usuario hace clic en el resultado, la página web empieza a renderizarse mucho antes porque los recursos clave ya están disponibles, lo que mejora la experiencia de usuario. Por lo tanto, puede hacer que tu contenido obtenga una mejor puntuación de renderizado del mayor elemento con contenido (LCP). Si bien la Búsqueda de Google no cuenta el uso de SXG como factor directo de posicionamiento, sí puede que tenga en cuenta un LCP más bajo, porque la experiencia en la página es un factor de posicionamiento.

Implementar SXG

Para implementar SXG, sigue la guía detallada de web.dev. Después de implementarlo, sigue esta guía para medir y optimizar la mejora del rendimiento con SXG.

En el caso de las páginas AMP, sigue la guía detallada de amp.dev.

Google utiliza una caché de SXG para precargar tu contenido y puede servir estos SXG almacenados en caché varias veces.

Para asegurarte de que el contenido que se muestra en la Búsqueda de Google esté actualizado, configura los valores de caducidad de SXG de forma adecuada. Como regla general, comprueba que la fecha de vencimiento:

  • Sea anterior a la fecha de caducidad de la caché determinada por los encabezados HTTP
  • No sea ni un solo día posterior si el contenido es JavaScript o tiene JavaScript insertado; en caso contrario, que no sea 7 o más días posterior

Para asegurarte de que el contenido se muestre correctamente al servirse en distintos dispositivos, sigue estas recomendaciones:

  1. Traslada el contenido personalizado, como carritos de compra, a elementos de carga en diferido que estén fuera de SXG. También puedes añadir el encabezado firmado Vary: Cookie. Los SXGs que tengan este encabezado solo se mostrarán a los visitantes que no tengan una cookie para tu sitio.
  2. Crea las páginas con un diseño web adaptable. También puedes servir páginas para ordenadores y para móviles en URLs independientes o añadir una anotación en las páginas para indicar que no son adaptables mediante la etiqueta meta supported-media. Por ejemplo, en el elemento <head> de la página, añade la siguiente etiqueta: 
    <meta name=supported-media content="only screen and (max-width: 640px)">

Monitorizar y depurar SXG

Si quieres ver un listado de herramientas que puedes usar para depurar SXG, consulta la guía de web.dev sobre herramientas de SXG.

Si el robot de Google no puede analizar un SXG, puedes volver a rastrear la URL sin application/signed-exchange;v=b3 en el encabezado Accept para obtener la variante text/html. En el caso de que se produzca algún error de indexación de SXG, la Búsqueda de Google enlazará a la URL original, sin SXG.

En páginas AMP, supervisa los errores de SXG mediante el informe de estado de AMP de Search Console.

Depurar la caché de SXG de Google

Para determinar si SXG cumple los requisitos de caché, usa la extensión de Chrome SXG Validator.

También puedes hacer la consulta directamente en la caché de SXG de Google. Por ejemplo, si la URL de SXG es https://signed-exchange-testing.dev/sxgs/valid.html, escribe la URL de caché correspondiente:

https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid.html

El algoritmo para calcular el subdominio y el sufijo de la ruta de la URL es el mismo que el de la caché de AMP, pero la cadena de infijo /doc/-/ es diferente.

Si la respuesta es SXG, significa que la respuesta del servidor de origen cumple los requisitos de Google SXG Cache. Si no, incluirá un encabezado HTTP que indique el motivo.

  • Si hay un encabezado Warning, indica un error que ha impedido que SXG cumpla los requisitos de caché.
  • Si hay un encabezado Location, significa que la caché aún no lo ha obtenido. No es un error de tu SXG.

Independientemente de la respuesta, la caché pone en cola una solicitud de copia actualizada a la URL original. Hay varios factores que determinan cuándo y si se envía esta solicitud, incluida la frecuencia de rastreo de tu sitio por parte del robot de Google.

Google no almacena en caché los SXGs más tiempo del indicado en el campo expires de la firma de SXG o del tiempo de vida de actualización de los encabezados sin firmar de la respuesta de SXG.

En páginas AMP, puedes depurar errores de almacenamiento en caché con la herramienta de inspección de URLs.

No te pierdas nada

Suscríbete a la lista de distribución webpackaging-announce para estar al día de cambios como estos:

  • Cambios en Google SXG Cache para habilitar nuevas funciones o para que otras dejen de estar disponibles.
  • Cambios importantes en el empaquetador web de herramientas de SXG, el módulo NGINX SXG y libsxg.

Si tienes alguna duda sobre SXG en la Búsqueda de Google, visita la comunidad de ayuda del Centro de la Búsqueda.