Fecha de publicación: 14 de mayo de 2025
El transporte de diccionarios de compresión es un nuevo estándar que nos permite comprimir contenido repetido en las solicitudes y se lanzó en Chrome 130 a fines de 2024. La Búsqueda de Google adoptó esta nueva tecnología y observó grandes mejoras.
La oportunidad
Hay mucha duplicación en las páginas web que visitamos. Muchas páginas del mismo sitio web constan de grandes partes del mismo código, ya sea HTML, CSS o JavaScript, y solo cambia el contenido entre todo este código. Si bien cada resultado es una combinación única de cientos de funciones que generan contenido totalmente único, aún hay mucha similitud en el código que se envía al navegador para producirlos.
Visualmente, la mayoría de las páginas de resultados de la Búsqueda son algo similares, sin importar el término de búsqueda ingresado: en la parte superior, tenemos el logotipo de Google, la barra de búsqueda y algunos controles. En el medio, tenemos algunas pestañas para el tipo de búsqueda y, luego, una lista de resultados de la búsqueda a la izquierda intercalada con varios widgets para ayudar al usuario y contexto adicional a la derecha con paneles "Acerca de":
Por último, en la parte inferior, tenemos las opciones de paginación y el pie de página estándar. Esto es solo lo que está disponible visualmente. Tras bambalinas, hay mucho código (HTML, CSS y JavaScript) para producir esta página. Gran parte de este código se inserta directamente en el HTML de la página como una optimización del rendimiento. Si bien esto permite una carga de página más rápida, no se comparte ese código entre las diferentes páginas de resultados, como lo permitiría un recurso almacenado en caché de forma externa.
Compresión en la Web
La compresión es una tecnología muy utilizada en la Web. La compresión de recursos con gzip o algoritmos más nuevos, como Brotli o Zstandard, permite evitar la repetición dentro de un archivo con compresión sin pérdida para empaquetar toda la información de la manera más ajustada posible en el servidor antes de enviarla. Luego, el navegador puede descomprimir los bytes comprimidos para restablecer el contenido original. En el caso de las imágenes, la compresión con pérdida ofrece beneficios similares, ya que quita los bytes adicionales que pueden no ser perceptibles para los usuarios.
Hasta hace poco, la compresión en la Web se limitaba a la compresión dentro de los recursos. No era posible comprimir diferentes recursos y, ciertamente, no en diferentes páginas. Esto se reconoció durante mucho tiempo como una limitación que los ingenieros web intentaron solucionar.
¡El transporte de diccionarios de compresión al rescate!
El transporte de diccionarios de compresión es un nuevo estándar que permite la compresión en los recursos con el uso de "diccionarios" compartidos que permiten reemplazar series comunes de bytes con referencias de ese diccionario compartido.
Los algoritmos de compresión modernos, como Brotli y Zstandard, admiten el uso de diccionarios de términos comunes que permiten una mayor compresión reemplazando esos términos con una referencia más pequeña al diccionario. Brotli incluso se incluye con un diccionario integrado de términos web comunes. El transporte de diccionarios de compresión se basa en esto, ya que proporciona formas para que el servidor y el navegador compartan diccionarios personalizados.
Los diccionarios personalizados pueden ser un recurso que ya se usa en el sitio. Por ejemplo, puedes usar app.v1.js como diccionario cuando descargas app.v2.js para descargar básicamente solo la diferencia (a menudo conocida como "compresión delta"). Como alternativa, se puede especificar un recurso de diccionario independiente con una etiqueta <link rel="compression-dictionary"> (o un encabezado HTTP Link equivalente).
Esto puede reducir drásticamente el tamaño de descarga de los recursos con mucho contenido o código compartido, como las páginas de resultados de la Búsqueda mencionadas anteriormente.
Uso de diccionarios de compresión de la Búsqueda de Google
El equipo de la Búsqueda de Google busca continuamente mejorar el rendimiento de la Búsqueda. Fueron los primeros en adoptar los diccionarios de compresión, ya que vieron el potencial de esta tecnología.
La Búsqueda usa la compresión Brotli compartida para sus páginas de resultados con un archivo de diccionario independiente creado a partir de una muestra representativa de los resultados de la búsqueda. Una canalización automatizada sólida garantiza que el diccionario se mantenga actualizado y se adapte al contenido de la SRP que cambia con frecuencia y que se lanza varias veces al día. Puedes usar las Herramientas para desarrolladores para ver exactamente cómo funciona.
Cuando un cliente carga por primera vez una página de resultados de búsqueda, el servidor proporciona un vínculo al diccionario con el encabezado HTTP Link: con un tipo de rel=compression-dictionary:
Link en la pestaña RedSi el cliente admite la compresión de diccionarios Brotli, pero aún no almacenó en caché el diccionario compartido, el navegador descarga este diccionario durante el tiempo de inactividad. La respuesta del diccionario incluye el encabezado de respuesta Use-As-Dictionary que le indica al navegador para qué recursos puede usar este diccionario:
Use-As-Dictionary en la pestaña RedEl diccionario usará la semántica cache-control estándar y estará disponible para cualquier recurso que coincida con las reglas definidas en ese encabezado. En este ejemplo, las páginas comienzan con /search.
Para las cargas futuras de la página de resultados de búsqueda, el navegador puede indicarle al servidor que tiene un diccionario con el encabezado de la solicitud HTTP Available-Dictionary. Si vuelves a cargar la página, se muestra en acción:
Available-Dictionary en la pestaña RedCon la casilla de verificación Conservar registro habilitada y el filtrado, podemos comparar las dos respuestas:
En este ejemplo, la primera solicitud es la respuesta completa de 107 kB y usa la compresión Brotli (br), mientras que la segunda solicitud de recarga es casi la mitad del tamaño en 60 kB y usa la compresión Brotli comprimida por diccionario (dcb), lo que genera un tiempo de descarga más rápido.
En Chrome, puedes ver la página chrome://net-internals/#sharedDictionary para ver los diccionarios compartidos y borrarlos si deseas repetir este ejemplo desde el principio.
#sharedDictionaryNet-InternalsLos resultados
El cambio se lanzó para los usuarios de la Búsqueda en la primavera de 2025, inicialmente para los usuarios de Chrome. Esto redujo el tamaño promedio de la carga útil de HTML en todos los usuarios de Chrome en un 23% en comparación con la compresión Brotli estándar. Este promedio general incluye los resultados no comprimidos por diccionario (por ejemplo, los usuarios nuevos sin diccionario) y los resultados de la búsqueda comprimidos por diccionario. En el caso de los resultados comprimidos por diccionario, los ahorros son aún mayores, como vimos con la mejora de casi el 50% en el ejemplo anterior que analizamos.
Esto generó una mejora del Largest Contentful Paint (LCP) del 1.7% en general y de hasta el 9% en redes de alta latencia. Esto puede parecer pequeño, pero la Búsqueda de Google es un sitio hiperoptimizado, por lo que las ganancias de esta magnitud son enormes. Otros sitios pueden ver mejoras aún mayores con esta tecnología.
Pruébala en tu sitio
El transporte de diccionarios de compresión ya está listo para usarse en todos los navegadores basados en Chromium (Chrome, Edge, Opera, etcétera). Es una mejora progresiva que los navegadores no compatibles ignorarán, pero, a medida que más navegadores la admitan, también podrán beneficiarse.
Los desafíos que aborda esta tecnología no son específicos de la Búsqueda de Google. Muchos sitios pueden beneficiarse del transporte de diccionarios de compresión, ya sea con un diccionario independiente como el que usó la Búsqueda o usando un recurso existente como diccionario (como la versión anterior de una app cuando se lanza una versión nueva).
Consulta la guía en MDN para obtener más detalles sobre cómo funciona esta tecnología y cómo puedes implementarla en tu sitio.
Esto requiere cierta configuración en tu servidor o proceso de compilación para crear recursos comprimidos basados en diccionarios y publicarlos según corresponda, pero los resultados pueden ser muy impresionantes en términos de rendimiento.