Habilita la compresión dinámica

La compresión dinámica comprime automáticamente las respuestas que entrega 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 comunes.

La reducción del tamaño disminuye el tiempo que lleva descargar el contenido. En el caso de elementos importantes, como hojas de estilo (CSS), secuencias de comandos (JavaScript) y manifiestos de video (HLS/DASH), esto puede reducir la carga de la página y los tiempos de inicio del video.

Puedes obtener más información sobre los beneficios de comprimir respuestas en la guía Fundamentos de la Web.

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

Casos prácticos de ejemplo

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 directamente lo siguiente:

  • Reducir el tamaño de CSS y JavaScript, lo que ayuda a las páginas web a procesarse más rápido y a reducir el tiempo de primer procesamiento de imagen con contenido, una métrica importante del rendimiento web.

  • Tener un gran impacto positivo cuando se almacenan en caché respuestas de la API de REST, como las cargas útiles de JSON. Estas cargas útiles se comprimen de forma correcta debido a las claves repetidas, el espacio en blanco y las llaves. El almacenamiento en caché de API públicas durante 5 a 10 segundos es un enfoque popular para reducir la carga de origen y, al mismo tiempo, mantener la actualidad de los datos.

    Incluso sin el almacenamiento en caché, comprimir estas respuestas puede reducir los bytes totales enviados hasta en un 90%.

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

Antes de comenzar

Asegúrate de tener lo siguiente:

  • Un backend habilitado para Cloud CDN configurado Si no hay Cloud CDN está configurado actualmente, puedes seguir uno de los guías de configuración.
  • Tu backend tiene contenido que se puede comprimir y listo para entregar, como elementos web o manifiestos de video entre 1 KiB y 10 MiB (inclusive).
  • Los clientes no necesitan recuperar contenido parcial con solicitudes de rango o con ETags fuertes. Estas no son compatibles con la compresión dinámica.
  • Los clientes pueden manejar respuestas sin Content-Length headers. Por ejemplo, errores de caché que Cloud CDN comprime. no tiene encabezados Content-Length.
  • La API de IAM Función de administrador de balanceador de cargas de Compute (roles/compute.loadBalancerAdmin), que se requiere para realizar cambios en la configuración de tu backend.

Habilita la compresión en un servicio de backend o un bucket de backend

Para habilitar la compresión, sigue estos pasos.

Consola

Agrega un origen nuevo

Para agregar y configurar un nuevo origen, sigue las instrucciones en Descripción general de la configuración del tipo adecuado de backend. Cuando crees el origen, usa la sección Opciones avanzadas para configurar compresión dinámica seleccionando Automático en el Modo de compresión lista.

Edita un origen existente

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

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

    Ir a Orígenes de Cloud CDN

  2. Haz clic en el nombre de origen que deseas editar y, luego, en Editar.

  3. En la sección Aspectos básicos del origen, haz clic en Siguiente.

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

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

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

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

gcloud

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

Para los buckets de backend, 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

Para un servicio de backend existente, usa el comando update:

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

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

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

Para un bucket de backend existente, usa el comando update:

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

El compression-mode puede ser uno de los siguientes:

  • AUTOMATIC: usa de forma automática la mejor compresión en función del encabezado Accept-Encoding que envía el cliente. En la mayoría de los casos, esto hace que se favorezca la compresión de Brotli.
  • DISABLED (predeterminado): inhabilita la compresión.

API

Para los servicios de backend, usa el backendServices.insert o Método backendServices.update.

Para los buckets de backend, usa el backendBuckets.insert o 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

Agrega el siguiente fragmento al cuerpo de solicitud JSON:

"compressionMode": AUTOMATIC

El compression-mode puede ser uno de los siguientes:

  • AUTOMATIC (recomendado): Usa de forma automática la mejor compresión en función del encabezado Accept-Encoding que envía el cliente. En la mayoría de los casos, esto hace que se favorezca la compresión de Brotli.
  • DISABLED (predeterminado): inhabilita la compresión.

En pocos minutos, tu configuración se propaga a todas las ubicaciones perimetrales. El contenido comprimible que se entrega desde el backend se comprime antes de entregarse 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 los siguientes factores:

  • La codificación aceptada del cliente
  • El índice de compresión previsto de la respuesta
  • La velocidad de compresión (capacidad de procesamiento) de Cloud CDN

Brotli puede generar entre un 10% y un 20% adicional de reducción en el tamaño de descarga para la mayoría de los tipos de contenido en comparación con gzip, lo que representa rendimiento de descompresión, lo que hace que sea más rápido en general cuando se considera la descarga tiempo 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 costo de CPU en el cliente. Los niveles de compresión más altos no siempre benefician el rendimiento, en especial en dispositivos móviles de menor potencia.

Cuando Cloud CDN comprime contenido inicialmente, quita encabezado Content-Length de la respuesta; esto es necesario para permitir la respuesta se muestre lo más rápido posible, ya que todo el contenido se desconoce la longitud hasta que se comprima toda la respuesta. Después de que una respuesta se comprime y almacena en caché, es posible que Cloud CDN incluir el encabezado Content-Length en las respuestas posteriores. (Para 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 la compatibilidad con algoritmos gzip o Brotli, y luego las respuestas descomprimidos que se entregan desde backend (origen) con un encabezado Content-Type que coincida con el los tipos de contenido que se pueden comprimir se comprimen con gzip o Brotli, en consecuencia. Si una solicitud no tiene un encabezado Accept-Encoding o si tiene Accept-Encoding: *, la respuesta no está comprimida.

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

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

Tipos de contenido que se pueden comprimir

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

Los tipos de contenido comunes y sus tipos de MIME incluyen lo siguiente:

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

La siguiente tabla resume cómo el tipo de MIME afecta la capacidad de compresión.

  Tipos de MIME que se pueden comprimir
Concordancia exacta application/x-javascript
application/x-sdch-dictionary
application/javascript
application/xml
aplicación/csv
application/json
application/json+protobuf
application/signed-exchange
application/vnd.apple.mpegurl
aplicación/wasm
application/x-plist
application/x-protobuffer
application/x-protobuf
application/x-nacl
application/x-pnacl
fuente/ttf
font/otf
font/eot
image/svg+xml
imagen/pwg-raster
imagen/ícono x
image/vnd.microsoft.icon
video/vnd.mpeg.dash.mpd
audio/URL MPEG
application/dash+xml
application/vnd.ms-sstr+xml
Coincidencia del patrón application/*+json
application/*+xml
application/*mpegURL
texto/*

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

¿Cuándo no se comprime una respuesta?

La compresión dinámica no comprime una respuesta que tiene una o más 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.

  • Pesa menos de 1 KiB.

    El tiempo dedicado a comprimir y descomprimir a menudo compensa cualquier beneficio. Además, hay menos contenido para comprimir, lo que puede reducir la eficacia de compresión y conducen a una proporción de compresión más baja.

  • Pesa más de 10 MiB.

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

  • Tiene un encabezado Vary: Accept-Encoding.

Solicitudes de rango

Cuando Cloud CDN comprime una respuesta, agrega un encabezado Accept-Ranges: none y reemplaza los encabezados Accept-Ranges existentes. Los aciertos de caché para esas respuestas ignoran los encabezados Range.

Esto evita que los clientes entreguen contenido parcial incorrecto porque no hay forma de garantizar si un cliente espera un rango de bytes de la forma comprimida o sin comprimir de un recurso.

ETag

Cuando la compresión dinámica comprime una respuesta, cualquier encabezado de ETag fuerte se debilita, como lo requiere la sección 2.3 de RFC 7232. Por ejemplo, ETag: "xyzzy" se reemplaza por ETag: W/"xyzzy".

Encabezado Vary

Cuando se entrega una respuesta que se puede comprimir (según la solicitud), Cloud CDN agrega el encabezado Vary: Accept-Encoding a la respuesta.

Resumen de los cambios en las respuestas

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

Encabezado de respuesta Valor del encabezado después de la compresión
Content-Encoding Se configura como gzip o brotli.
ETag Toda etiqueta de entidad sólida se reemplaza por una versión debilitada. se indica con el prefijo W/.
Rangos de aceptación Configúralo con el valor none.
Duración del contenido Se puede quitar por completo o, si se incluye, se puede establecer en la longitud del contenido del cuerpo comprimido.
Codificación por transferencia Para HTTP/1.1 y protocolos anteriores, si Cloud CDN quita Content-Length, agrega este encabezado, con su valor establecido en chunked y fragmenta el cuerpo de la respuesta.

Logging

Los registros de Cloud CDN incluyen un campo compressionStatus en el jsonPayload: Indica si la carga comprimió la respuesta. balanceador de cargas y 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é de salida relevante o la transferencia de datos de Internet saliente se mide con respecto a los últimos bytes comprimidos enviados al cliente (respectivamente).

Si estás entregando una gran cantidad de respuestas comprimibles, esto puede una reducción en las tarifas mensuales de transferencia de datos salientes, así como un aumento para los usuarios finales.

Métricas

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

Es probable que haya una disminución en el total de bytes de respuesta (y en la transferencia de datos de salida) capacidad de procesamiento).

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

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

¿Qué sigue?