Intercambios firmados (SXG)
Un SXG es un mecanismo de entrega que permite autenticar el origen de un recurso independientemente de cómo haya sido entregado.
Un signed exchange (intercambio firmado) SXG es un mecanismo de entrega que permite autenticar el origen de un recurso independientemente de cómo haya sido entregado. Este desacoplamiento avanza en una variedad de casos de uso, como la captura o búsqueda previa para preservar la privacidad, las experiencias de Internet sin conexión y el servicio desde caché de terceros. Además, la implementación de SXG puede mejorar el Largest Contentful Paint o despliegue del contenido más extenso (LCP) para algunos sitios.
Este artículo proporciona una descripción general de los SXG: cómo funcionan, casos de uso y herramientas.
Compatibilidad del navegador #
Los SXG son compatibles con los navegadores basados en Chromium (a partir de las versiones: Chrome 73, Edge 79 y Opera 64).
Descripción general #
Los intercambios firmados (SXG) permiten a un sitio firmar criptográficamente un par de solicitud/respuesta (un "intercambio HTTP") de tal manera que el navegador pueda verificar el origen y la integridad del contenido independientemente de cómo se distribuyó. Como resultado, el navegador puede mostrar la URL del sitio de origen en la barra de direcciones, en lugar de la URL del servidor que entregó el contenido.
La implicación más amplia de los SXG es que hacen que el contenido sea portátil: el contenido entregado a través de un SXG puede ser distribuido fácilmente por terceros, mientras se mantiene la plena seguridad y atribución de su origen. Históricamente, la única forma de que un sitio utilice a un tercero para distribuir su contenido mientras mantiene la atribución, ha sido que el sitio comparta sus certificados SSL con el distribuidor. Esto tiene inconvenientes de seguridad y además, está muy lejos de hacer que el contenido sea realmente portátil.
A largo plazo, el contenido verdaderamente portátil se puede utilizar para lograr casos de uso como experiencias completamente fuera de línea. En el plazo inmediato, el caso de uso principal de los SXG es la entrega de experiencias de usuario más rápidas al proporcionar contenido en un formato de fácil almacenamiento en caché. Específicamente, la Búsqueda de Google almacenará en caché y, a veces, buscará previamente los SXG. Para los sitios que reciben una gran parte de su tráfico de la Búsqueda de Google, los SXG pueden ser una herramienta importante para entregar cargas de página más rápidas a los usuarios.
El formato SXG #
Un SXG está encapsulado en un archivo con codificación binaria que tiene dos componentes principales: un intercambio HTTP y una firma. El intercambio HTTP consta de una URL de solicitud, información de negociación de contenido y una respuesta HTTP.
A continuación, se muestra un ejemplo de un archivo SXG decodificado:
format version: 1b3
request:
method: GET
uri: https://example.org/
headers:
response:
status: 200
headers:
Cache-Control: max-age=604800
Digest: mi-sha256-03=kcwVP6aOwYmA/j9JbUU0GbuiZdnjaBVB/1ag6miNUMY=
Expires: Mon, 24 Aug 2020 16:08:24 GMT
Content-Type: text/html; charset=UTF-8
Content-Encoding: mi-sha256-03
Date: Mon, 17 Aug 2020 16:08:24 GMT
Vary: Accept-Encoding
signature:
label;cert-sha256=*ViFgi0WfQ+NotPJf8PBo2T5dEuZ13NdZefPybXq/HhE=*;
cert-url="https://test.web.app/ViFgi0WfQ-NotPJf8PBo2T5dEuZ13NdZefPybXq_HhE";
date=1597680503;expires=1598285303;integrity="digest/mi-sha256-03";sig=*MEUCIQD5VqojZ1ujXXQaBt1CPKgJxuJTvFlIGLgkyNkC6d7LdAIgQUQ8lC4eaoxBjcVNKLrbS9kRMoCHKG67MweqNXy6wJg=*;
validity-url="https://example.org/webpkg/validity"
header integrity: sha256-Gl9bFHnNvHppKsv+bFEZwlYbbJ4vyf4MnaMMvTitTGQ=
The exchange has a valid signature.
payload [1256 bytes]:
<!doctype html>
<html>
<head>
<title>SXG example</title>
<meta charset="utf-8" />
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<style type="text/css">
body {
background-color: #f0f0f2;
margin: 0;
padding: 0;
}
</style>
</head>
<body>
<div>
<h1>Hello</h1>
</div>
</body>
</html>El parámetro expires en la firma indica la fecha de expiración de un SXG. Un SXG puede tener una validez máxima de 7 días. Si la fecha de vencimiento de un SXG es de más de 7 días en el futuro, el navegador lo rechazará. Encuentre más información sobre el encabezado de la firma en la especificación de intercambios HTTP firmados.
Empaquetado web #
Los SXG son parte de la familia más amplia de propuestas de especificaciones de empaquetado web. Además de los SXG, el otro componente principal de la especificación de empaquetado web son los paquetes web ("intercambios HTTP empaquetados"). Los paquetes web son una colección de recursos HTTP y metadatos necesarios para interpretar el paquete.
La relación entre SXG y los paquetes web es un punto común de confusión. Se trata de dos tecnologías distintas que no dependen entre sí: los paquetes web se pueden utilizar con intercambios firmados y sin firmar. El objetivo común propuesto tanto por SXG como por los paquetes es la creación de un formato de "empaquetado web" que permita que los sitios se compartan en su totalidad para el consumo fuera de línea.
Los SXG son la primera parte de la especificación de empaquetado web que implementarán los navegadores basados en Chromium.
Cargar SXG #
En un inicio, el caso de uso principal de SXG probablemente sea como mecanismo de entrega para el documento principal de una página. Para este caso de uso, se puede hacer referencia a un SXG mediante las etiquetas <link> o <a>, así como la cabecera Link. Al igual que otros recursos, un SXG se puede cargar ingresando su URL en la barra de direcciones del navegador.
<a href="https://example.com/article.html.sxg"><link rel="prefetch" as="document" href="https://example.com/article.html.sxg">Los SXG también se pueden utilizar para entregar subrecursos. Para obtener más información, consulte Sustitución de subrecursos de intercambio firmado.
Servir SXG #
Negociación de contenido #
La negociación de contenido es un mecanismo para servir diferentes representaciones del mismo recurso en la misma URL dependiendo de las capacidades y preferencias de un cliente, por ejemplo, entregar la versión gzip de un recurso a algunos clientes, pero la versión Brotli a otros. La negociación de contenido permite ofrecer representaciones SXG y no SXG del mismo contenido, según las capacidades de un navegador.
Los navegadores web utilizan el encabezado de solicitud Acceptpara comunicar los tipos MIME que admiten. Si un navegador admite SXG, el tipo MIME application/signed-exchange se incluirá automáticamente en esta lista de valores.
Por ejemplo, este es el encabezado Accept enviado por Chrome 84:
accept:
text/html,
application/xhtml+xml,
application/xml;q=0.9,
image/webp,image/apng,
\*/\*;q=0.8,
application/signed-exchange;v=b3;q=0.9La parte application/signed-exchange;v=b3;q=0.9 de esta cadena informa al servidor web que Chrome admite SXG, específicamente, la versión b3. La última parte q=0.9 indica el q-value.
El q-value expresa la preferencia relativa de un navegador por un formato particular usando una escala decimal de 0 a 1, donde 1 representa la prioridad más alta. Cuando no se proporciona un q-value para un formato, 1 es el valor implícito.
Mejores prácticas #
Los servidores deben servir SXG cuando el encabezado Accept indica que el q-value para application/signed-exchange es mayor o igual que el q-value para text/html. En la práctica, esto significa que un servidor de origen entregará SXG a los rastreadores, pero no a los navegadores.
Los SXG pueden ofrecer un rendimiento superior cuando se utilizan con el almacenamiento en caché o la captura previa. Sin embargo, para el contenido que se carga directamente desde el servidor de origen sin el beneficio de estas optimizaciones, el formato text/html ofrece un mejor rendimiento que los SXG. Ofrecer contenido como SXG permite a los rastreadores y otros intermediarios almacenar en caché los SXG para una entrega más rápida a los usuarios.
La siguiente expresión regular se puede utilizar para hacer coincidir el encabezado Accept de las solicitudes que deben servirse como SXG:
Accept: /(^|,)\s\*application\/signed-exchange\s\*;\s\*v=[[:alnum:]\_-]+\s\*(,|$)/Tenga en cuenta que la subexpresión (,|$) coincide con los encabezados donde el q-value se ha omitido para SXG; esta omisión implica un q-value de 1 para SXG. Aunque teóricamente un encabezadoAccept podría contener la subcadena q=1, en la práctica los navegadores no enumeran explícitamente el q-value de un formato cuando tiene el valor predeterminado de 1.
Depuración de SXG con Chrome DevTools #
Los intercambios firmados se pueden identificar buscando signed-exchange en la columna Tipo del panel Red en Chrome DevTools.
La pestaña Vista previa proporciona más información sobre el contenido de un SXG.
Para ver un SXG de primera mano, visite esta demostración en uno de los navegadores compatibles con SXG
Casos de uso #
Los SXG se pueden usar para entregar contenido directamente desde un servidor de origen a un usuario, pero esto frustraría en gran medida el propósito de los SXG. Más bien, el uso previsto y los beneficios de los SXG se logran principalmente cuando los SXG generados por un servidor de origen se almacenan en caché y un intermediario los envía a los usuarios.
Aunque esta sección analiza principalmente el almacenamiento en caché y el servicio de SXG por parte de la Búsqueda de Google, es una técnica que se aplica a cualquier sitio que desee proporcionar a sus enlaces externos una experiencia de usuario más rápida o una mayor resistencia al acceso limitado a la red. Esto no solo incluye motores de búsqueda y plataformas de redes sociales, sino también portales de información que ofrecen contenido para consumo fuera de línea.
Búsqueda de Google #
La Búsqueda de Google utiliza SXG para proporcionar a los usuarios una experiencia de carga de página más rápida para las páginas cargadas desde los resultados de búsqueda. Los sitios que reciben un tráfico importantes de la Búsqueda de Google pueden ver mejoras de rendimiento significativas al ofrecer contenido como SXG.
La Búsqueda de Google ahora rastreará, almacenará en caché y buscará previamente los SXG cuando corresponda. Google y otros motores de búsqueda a veces buscan previamente el contenido que es probable que el usuario visite, por ejemplo, la página correspondiente al primer resultado de búsqueda. Los SXG son especialmente adecuados para la búsqueda previa, debido a sus beneficios de privacidad sobre los formatos que no son SXG.
Rastreadores #
El encabezado Accept enviado por el rastreador de búsqueda de Google expresa una preferencia igual por text/html y application/signed-exchange. Como se describe en la sección anterior, los sitios que deseen utilizar SXG deben servirlos cuando el encabezado Accept de una solicitud exprese una preferencia igual o mayor por SXG sobre text/html. En la práctica, solo los rastreadores expresarán una preferencia por los SXG sobre el text/html.
Indexación #
Las representaciones SXG y no SXG de una página no están clasificadas ni indexadas por separado por la Búsqueda de Google. SXG es, en última instancia, un mecanismo de entrega, no cambia el contenido subyacente. Dado esto, no tendría sentido que la Búsqueda de Google indexara por separado o clasificara de diferentes maneras el mismo contenido entregado.
Web Vitals #
Para los sitios que reciben una parte significativa de su tráfico de la Búsqueda de Google, los SXG se pueden utilizar para mejorar Web Vitals, a saber, LCP. Los SXG almacenados en caché y capturados previamente se pueden entregar a los usuarios de manera increíblemente rápida y esto produce un LCP más rápido. Aunque los SXG pueden ser una herramienta poderosa, funcionan mejor cuando se combinan con otras optimizaciones de rendimiento, como el uso de CDN y la reducción de subrecursos que bloquean el renderizado.
AMP #
El contenido AMP se puede entregar mediante SXG. SXG permite que el contenido AMP sea capturado previamente y mostrado usando su URL canónica, en lugar de su URL de AMP.
Todos los conceptos descritos en este documento aún se aplican al caso de uso de AMP; sin embargo, AMP tiene sus propias herramientas independientes para generar SXG.
Herramientas #
La implementación de SXG consiste en generar el SXG correspondiente a una URL determinada y luego entregar ese SXG a los solicitantes (generalmente rastreadores). Para generar un SXG, necesitará un certificado que pueda firmar SXG.
Certificados #
El uso de producción de SXG requiere un certificado que admita la extensión CanSignHttpExchanges. Según las especificaciones, los certificados con esta extensión deben tener un período de validez no mayor a 90 días y requieren que el dominio solicitante tenga configurado un registro CAA de DNS.
Esta página enumera las autoridades de certificación que pueden emitir este tipo de certificado. Los certificados para SXG solo están disponibles a través de una autoridad certificadora comercial.
Herramientas SXG específicas de la plataforma #
Estas herramientas admiten pilas de tecnología específicas. Si ya está utilizando una plataforma compatible con una de estas herramientas, le resultará más fácil de configurar que una herramienta de uso general.
sxg-rs/cloudflare_workerse ejecuta en Cloudflare Workers.sxg-rs/fastly_computese ejecuta en Fastly Compute@Edge.Los intercambios firmados automáticos son una función de Cloudflare que adquiere certificados y genera intercambios firmados automáticamente.
El módulo NGINX SXG genera y sirve SXG para sitios que usan nginx. Las instrucciones de configuración se pueden encontrar aquí.
Envoy SXG Filter genera y sirve SXG para sitios que usan Envoy.
Herramientas SXG de uso general #
CLI de Web Packager #
La CLI de Web Packager genera un SXG correspondiente a una URL determinada.
webpackager \
--private\_key=private.key \
--cert\_url=https://example.com/certificate.cbor \
--url=https://example.comUna vez que se haya generado el archivo SXG, cárguelo en su servidor y sírvalo con el tipo MIME application/signed-exchange;v=b3. Además, deberá entregar el certificado SXG como application/cert-chain+cbor.
Servidor de Web Packager #
El servidor de Web Packager, webpkgserver, actúa como un proxy inverso para servir SXG. Dada una URL, webpkgserver buscará el contenido de la URL, lo empaquetará como un SXG y entregará el SXG en respuesta. Para obtener instrucciones sobre cómo configurar el servidor del empaquetador web, consulte Cómo configurar intercambios firmados con Web Packager.
Bibliotecas SXG #
Estas bibliotecas podrían usarse para construir su propio generador SXG:
sxg_rses una biblioteca de Rust para generar SXG. Es la biblioteca SXG con más funciones y se utiliza como base para las herramientascloudflare_workeryfastly_compute.libsxges una biblioteca C mínima para generar SXG. Se utiliza como base para el módulo NGINX SXG y el filtro Envoy SXG.go/signed-exchangees una biblioteca Go mínima proporcionada por la especificación del paquete web como implementación de referencia para generar SXG. Se utiliza como base para su herramienta CLI de referencia,gen-signedexchangey las herramientas de Web Packager que cuentan con más funciones.
Conclusión #
Los intercambios firmados son un mecanismo de entrega que permite verificar el origen y la validez de un recurso independientemente de cómo haya sido entregado el recurso. Como resultado, los SXG pueden ser distribuidos por terceros mientras se mantiene la atribución total del editor.
Lecturas relacionadas #
- Borrador de especificaciones para intercambios HTTP firmados
- Explicaciones de empaquetado web
- Empiece a utilizar intercambios firmados en la Búsqueda de Google
- Cómo configurar intercambios firmados usando Web Packager
- Demostración de intercambios firmados