Habilitar la compresión dinámica

La compresión dinámica comprime automáticamente las respuestas que sirve Cloud CDN. El tamaño de los datos enviados a través de la red se reduce entre un 60% y un 85% en los casos habituales.

La reducción del tamaño disminuye el tiempo que se tarda en descargar el contenido. En el caso de los recursos importantes, como las hojas de estilo (CSS), las secuencias de comandos (JavaScript) y los manifiestos de vídeo (HLS o DASH), esto puede reducir los tiempos de carga de las páginas y de inicio de los vídeos.

Puedes consultar más información sobre las ventajas de comprimir respuestas en la guía de conceptos básicos de la Web.

Puedes habilitar la compresión en un servicio de backend o en un segmento de backend.

Ejemplos de casos prácticos

La compresión dinámica reduce directamente el tamaño de los datos enviados desde el perímetro de Cloud CDN al cliente. Esto puede hacer lo siguiente directamente:

  • Reduce el tamaño de CSS y JavaScript para que las páginas web se rendericen más rápido y se reduzca el tiempo hasta la primera pintura de contenido, una métrica importante del rendimiento web.

  • Tienen un gran impacto positivo al almacenar en caché las respuestas de las APIs REST, como las cargas útiles JSON. Estas cargas útiles se comprimen bien debido a las claves, los espacios en blanco y las llaves repetidos. Almacenar en caché las APIs públicas durante 5-10 segundos es una práctica habitual para reducir la carga del origen y, al mismo tiempo, mantener la actualización de los datos.

    Incluso sin almacenamiento en caché, la compresión de estas respuestas puede reducir el total de bytes enviados hasta en un 90%.

  • Mejorar el tiempo de inicio de la reproducción de la entrega de vídeo y la latencia de unión de la emisión en directo. Las listas de reproducción de contenido en directo grandes (manifiestos) tienen una cantidad significativa de datos repetidos, incluido el prefijo de host y de ruta de cada segmento, así como los metadatos de la lista de reproducción de HLS o DASH. Cuanto más rápido se cargue la lista de reproducción o se puedan descargar las actualizaciones de la lista de reproducción, menos tiempo tendrá que esperar un cliente para analizar y empezar a descargar los segmentos de vídeo a los que se hace referencia. Las listas de reproducción HLS y DASH suelen reducir su tamaño total en más de un 90%.

Antes de empezar

Asegúrate de que tienes lo siguiente:

  • Un backend configurado con Cloud CDN habilitado. Si no tienes configurado Cloud CDN, puedes seguir una de las guías de configuración.
  • Tu backend tiene contenido comprimible listo para servir, como recursos web o manifiestos de vídeo de entre 1 KiB y 10 MiB (ambos incluidos).
  • Los clientes no dependen de la obtención de contenido parcial con solicitudes de intervalo o con ETags fuertes. No son compatibles con la compresión dinámica.
  • Los clientes pueden gestionar las respuestas sin encabezados Content-Length. Por ejemplo, las fallos de caché que comprime Cloud CDN no tienen encabezados Content-Length.
  • El rol de gestión de identidades y accesos Administrador de balanceadores de carga de Compute (roles/compute.loadBalancerAdmin), que es necesario para hacer cambios en la configuración de backend.

Habilitar la compresión en un servicio de backend o un segmento de backend

Para habilitar la compresión, sigue estos pasos.

Consola

Añadir un origen

Para añadir y configurar un nuevo origen, sigue las instrucciones de la sección Configuración general del tipo de backend correspondiente. Cuando crees tu origen, usa la sección Opciones avanzadas para configurar la compresión dinámica. Para ello, selecciona Automático en la lista Modo de compresión.

Editar un origen

Para editar un origen de Cloud CDN, sigue estos pasos:

  1. En la Google Cloud consola, ve a la página Orígenes de Cloud CDN.

    Ir a Orígenes

  2. Haga clic en el nombre del origen que quiera editar y, a continuación, en Editar.

  3. En la sección Información básica del origen, haga clic en Siguiente.

  4. En la sección Reglas de host y ruta, haga clic en Siguiente.

  5. En la sección Rendimiento de la caché, vaya a Opciones avanzadas.

  6. En la lista Modo de compresión, selecciona Automático.

  7. Para aplicar los cambios, haz clic en Hecho.

gcloud

En el caso de los servicios de backend, usa el comando gcloud compute backend-services create o el comando gcloud compute backend-services update con la marca --compression-mode.

En el caso de los backend buckets, usa el comando gcloud compute backend-buckets create o el comando gcloud compute backend-buckets update con la marca --compression-mode.

Para un servicio de backend nuevo, usa el comando create:

gcloud compute backend-services create BACKEND_SERVICE_NAME \
    --compression-mode=AUTOMATIC

En el caso de un servicio de backend que ya tengas, usa el comando update:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --compression-mode=AUTOMATIC

Para crear un nuevo backend, usa el comando create:

gcloud compute backend-buckets create BACKEND_BUCKET_NAME
    --compression-mode=AUTOMATIC

Para usar un segmento de backend que ya tengas, usa el comando update:

gcloud compute backend-buckets update BACKEND_BUCKET_NAME
    --compression-mode=AUTOMATIC

El elemento compression-mode puede ser uno de los siguientes:

  • AUTOMATIC: usa automáticamente la mejor compresión en función del encabezado Accept-Encoding enviado por el cliente. En la mayoría de los casos, se favorece la compresión Brotli.
  • DISABLED (valor predeterminado): inhabilita la compresión.

API

En el caso de los servicios de backend, usa el método backendServices.insert o el método backendServices.update.

En el caso de los contenedores de backend, utiliza el método backendBuckets.insert o el método backendBuckets.update.

Usa uno de los siguientes comandos:

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices

PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET

Añade el siguiente fragmento al cuerpo de la solicitud JSON:

"compressionMode": AUTOMATIC

El elemento compression-mode puede ser uno de los siguientes:

  • AUTOMATIC (recomendado): usa automáticamente la mejor compresión en función del encabezado Accept-Encoding enviado por el cliente. En la mayoría de los casos, se favorece la compresión Brotli.
  • DISABLED (valor predeterminado): inhabilita la compresión.

En unos minutos, la configuración se propagará a todas las ubicaciones perimetrales. El contenido comprimible que se sirve desde el backend se comprime antes de enviarse al cliente.

Modos de compresión

El modo de compresión predeterminado es DISABLED.

El modo AUTOMATIC permite que Cloud CDN elija el mejor método de compresión en función de lo siguiente:

  • La codificación aceptada del cliente
  • Relación de compresión prevista de la respuesta
  • Velocidad de compresión (rendimiento) de Cloud CDN

Brotli puede reducir el tamaño de descarga entre un 10 y un 20 % en la mayoría de los tipos de contenido en comparación con gzip, con un rendimiento de descompresión similar, lo que hace que sea más rápido en general si se tiene en cuenta el tiempo de descarga y la velocidad de descompresión en el cliente.

Cloud CDN indica el método de compresión elegido como gzip o brotli en el encabezado Content-Encoding de la respuesta.

Cloud CDN determina el nivel de compresión para equilibrar el tamaño total de la descarga y el coste de CPU en el cliente. Los niveles de compresión más altos no siempre mejoran el rendimiento, sobre todo en dispositivos móviles con menos potencia.

Cuando Cloud CDN comprime el contenido inicialmente, elimina el encabezado Content-Length de la respuesta. Esto es necesario para que la respuesta se pueda enviar lo más rápido posible, ya que la longitud completa del contenido se desconoce hasta que se haya comprimido toda la respuesta. Una vez que se ha comprimido y almacenado en caché una respuesta, Cloud CDN puede incluir el encabezado Content-Length en las respuestas posteriores. En HTTP/1.1 y versiones anteriores, Cloud CDN usa Transfer-Encoding: chunked en la respuesta cuando no usa Content-Length.

¿Cuándo se comprime una respuesta?

Si una solicitud tiene un encabezado Accept-Encoding que indica explícitamente que admite los algoritmos gzip o Brotli, las respuestas sin comprimir que se sirven desde el backend (origen) con un encabezado Content-Type que coincida con los tipos de contenido comprimible se comprimen con gzip o Brotli, según corresponda. Si una solicitud no tiene un encabezado Accept-Encoding o tiene Accept-Encoding: *, la respuesta no se comprime.

Por ejemplo, si se incluye un encabezado Accept-Encoding en una solicitud de cliente, la respuesta se comprime (o no) según la información de la siguiente tabla:

Encabezado de solicitud Accept-Encoding Codificación de la respuesta
gzip, compress, br Brotli (br)
deflate Sin comprimir
deflate, gzip gzip
identity Sin comprimir
* Sin comprimir

Tipos de contenido comprimible

La compresión dinámica se aplica a los siguientes tipos MIME, en función del encabezado de respuesta HTTP Content-Type. Las respuestas que no tienen un encabezado de respuesta Content-Type no se comprimen.

Entre los tipos de contenido habituales y sus tipos MIME se incluyen los siguientes:

  • Contenido HTML: text/html
  • Hojas de estilo: text/css
  • JavaScript: application/javascript
  • JSON: application/json
  • Listas de reproducción HLS: application/x-mpegURL o application/vnd.apple.mpegURL
  • Archivos de manifiesto de DASH: application/dash+xml

En la siguiente tabla se resume cómo afecta el tipo MIME a la compresibilidad.

  Tipos de MIME comprimibles
Concordancia exacta application/x-javascript
application/x-sdch-dictionary
application/javascript
application/xml
application/csv
application/json
application/json+protobuf
application/signed-exchange
application/vnd.apple.mpegurl
application/wasm
application/x-plist
application/x-protobuffer
application/x-protobuf
application/x-nacl
application/x-pnacl
font/ttf
font/otf
font/eot
image/svg+xml
image/pwg-raster
image/x-icon
image/vnd.microsoft.icon
video/vnd.mpeg.dash.mpd
audio/mpegURL
application/dash+xml
application/vnd.ms-sstr+xml
Concordancia de patrones application/*+json
application/*+xml
application/*mpegURL
text/*

Los formatos de imagen y vídeo (como image/jpeg, image/png y video/mpeg4) casi siempre ya están comprimidos, por lo que Cloud CDN no los comprime. Volver a comprimir una respuesta que ya está comprimida rara vez reduce el tamaño del archivo, y es posible que los clientes muestren un comportamiento inesperado al recibir una respuesta de este tipo.

¿Cuándo no se comprime una respuesta?

La compresión dinámica no comprime una respuesta que tenga una o varias de las siguientes características:

  • La respuesta no tiene un encabezado Content-Type que coincida con un tipo de contenido comprimible.
  • No tiene un encabezado Content-Length.
  • Tiene un encabezado Content-Encoding.

  • Tiene un tamaño inferior a 1 KiB.

    El tiempo dedicado a comprimir y descomprimir suele compensar cualquier ventaja. También hay menos contenido que comprimir, lo que puede reducir la eficacia de la compresión y dar lugar a una relación de compresión más baja.

  • Tiene un tamaño superior a 10 MiB.

  • Tiene un encabezado Cache-Control: no-transform.

  • Tiene un encabezado Vary: Accept-Encoding.

Solicitudes de intervalo

Cuando Cloud CDN comprime una respuesta, añade un encabezado Accept-Ranges: none y sustituye cualquier encabezado Accept-Ranges que ya exista. Los aciertos de caché de estas respuestas ignoran los encabezados Range.

De esta forma, se evita que se sirva contenido parcial incorrecto a los clientes, ya que no hay forma de saber si un cliente espera un intervalo de bytes de la forma comprimida o sin comprimir de un recurso.

ETags

Cuando la compresión dinámica comprime una respuesta, los encabezados ETag sólidos se debilitan, tal como se indica en la sección 2.3 del RFC 7232. Por ejemplo, ETag: "xyzzy" se sustituye por ETag: W/"xyzzy".

Cabecera Vary

Cuando sirve una respuesta que se puede comprimir (en función de la solicitud), Cloud CDN añade el encabezado Vary: Accept-Encoding a la respuesta.

Resumen de los cambios en las respuestas

En la siguiente tabla se resumen los cambios que Cloud CDN realiza en los encabezados de una respuesta cuando se ha producido la compresión:

Encabezado de respuesta Valor del encabezado después de la compresión
Content-Encoding Su valor debe ser gzip o brotli.
ETag Cualquier etiqueta de entidad fuerte se sustituye por una versión debilitada, indicada por el prefijo W/.
Accept-Ranges Asigna el valor none.
Content-Length Puede eliminarse por completo o, si está presente, se asigna a la longitud del contenido del cuerpo comprimido.
Transfer-Encoding En el caso de HTTP/1.1 y protocolos anteriores, si Cloud CDN elimina Content-Length, añade este encabezado, con el valor chunked, y divide el cuerpo de la respuesta en fragmentos.

Almacenamiento de registros

Los registros de Cloud CDN incluyen un campo compressionStatus en el jsonPayload que indica si el balanceador de carga ha comprimido la respuesta, así como el tipo de compresión.

{
  insertId: "1c02hw9g3gjay67"
  jsonPayload: {
    @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
    statusDetails: "response_sent_by_backend"
    cacheId: "IAD-862d661f"
    compressionStatus: "br"
  }
}

Facturación

Cuando Cloud CDN o Cloud Load Balancing comprimen una respuesta, la transferencia de datos de caché saliente o la transferencia de datos de Internet saliente (respectivamente) se mide en función de los bytes comprimidos finales enviados al cliente.

Si sirves una gran cantidad de respuestas comprimibles, esto puede reducir las tarifas mensuales de transferencia de datos salientes, así como aumentar el rendimiento para los usuarios finales.

Métricas

Cuando la compresión está habilitada, la métrica https/response_bytes_count de loadbalancing.googleapis.com informa del tamaño de la respuesta comprimida.

Es de esperar que se produzca una disminución en el total de bytes de respuesta (y en el rendimiento de la transferencia de datos salientes).

Si sirve una gran cantidad de contenido basado en texto que se comprime bien, como HTML, CSS, JavaScript o JSON, es posible que observe una gran reducción en los bytes de respuesta.

Para obtener más información, consulta Monitorización.

Siguientes pasos