Se usó la API de Cloud Translation para traducir esta página.

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.

Esta función es compatible con Cloud CDN con un balanceador de cargas de HTTP(S) externo global o un balanceador de cargas de HTTP(S) externo global.

Casos de uso 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 configurado un backend con Cloud CDN habilitado. Si no tienes Cloud CDN configurado, puedes seguir una de las 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).
Asegúrate de que los clientes no dependan de recuperar contenido parcial con solicitudes de rango o con ETags sólidas. Estas no son compatibles con la compresión dinámica.
Asegúrate de que los clientes puedan controlar las respuestas sin encabezados de longitud de contenido. La caché falla porque las compresas de Cloud CDN no tienen encabezados de longitud de contenido.
Tienes el rol Compute Load Balancer Admin (roles/compute.loadBalancerAdmin), que es necesario para realizar cambios en la configuración de 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 un origen nuevo, haz lo siguiente:

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

Ir a Orígenes de Cloud CDN
Haz clic en Agregar origen. Se mostrará la página Nuevo origen.
En la sección Aspectos básicos del origen, completa lo siguiente:
1. En el campo Nombre de origen, ingresa un nombre para tu origen.
  
  El nombre que elijas debe comenzar con una letra minúscula seguida por un máximo de 62 letras minúsculas, números o guiones. El nombre no puede terminar con un guion.
2. Selecciona una Configuración de origen:
  - Bucket de backend: Usa un bucket de Cloud Storage como origen. En Define tu bucket de backend, selecciona un bucket de Cloud Storage nuevo o existente.
  - Origen personalizado: Usa un origen personalizado. En Define tu origen personalizado, ingresa la dirección IP o el nombre de dominio y un puerto que Cloud CDN use para conectarse al origen.
  - Servicio de backend: Usa un balanceador de cargas que esté configurado como un backend. En Define tu servicio de backend, selecciona el servicio de backend que usarás. Si aún no tienes un servicio de backend configurado, puedes configurar uno ahora.
3. Para continuar, haz clic en Siguiente.
En la sección Reglas de host y ruta de acceso, selecciona una de las siguientes opciones:
- Selecciona un balanceador de cargas existente: puedes elegir un balanceador de cargas existente de la lista Seleccionar un balanceador de cargas.
- Crear un balanceador de cargas nuevo: Cloud CDN puede crear un balanceador de cargas nuevo por ti. Ingresa un nombre para tu nuevo balanceador de cargas en el campo Nombre del balanceador de cargas.
  
  El nombre debe comenzar con una letra minúscula, seguida de 62 letras minúsculas, números o guiones, como máximo. El nombre no puede terminar con un guion.
Para continuar, haz clic en Siguiente.
En la sección Opciones básicas, sigue estos pasos.
1. En Modo de almacenamiento en caché, selecciona una de las siguientes opciones:
  - Almacenar en caché el contenido estático: Recomendamos esta configuración para la mayoría de las situaciones.
  - Usar configuración de origen en función de los encabezados de control de caché: Cloud CDN almacena en caché las respuestas con directivas de control válidas en los encabezados de respuesta, como Cache-Control: public, max_age=3600.
  - Forzar el almacenamiento en caché de todo el contenido: Esto obliga a Cloud CDN a almacenar en caché todo el contenido, sin importar las directivas private, no-store o no-cache.
    
    Advertencia: Esta configuración puede provocar que Cloud CDN almacene en caché datos privados que identifiquen el usuario. Usa esto solo en backends que no entreguen contenido dinámico ni privado, como los buckets de Cloud Storage.
2. En Almacenar en caché el contenido estático y Forzar el almacenamiento en caché de todo el contenido, puedes configurar lo siguiente:
  - Tiempo de actividad del cliente: Te permite establecer un tiempo de actividad más breve en navegadores o clientes, y hacer que esos clientes se vuelvan a validar en Cloud CDN de forma más frecuente.
    
    El valor del tiempo de actividad del cliente no puede ser mayor que el tiempo máximo de actividad, pero puede ser igual.
  - Tiempo de actividad predeterminado: Especifica el tiempo de actividad predeterminado para el contenido almacenado en caché que entrega este origen, en el caso de respuestas que no tienen un tiempo de actividad válido.
    
    Este valor puede ser igual al del tiempo de actividad máximo, pero no debe ser superior.
3. En Almacenar en caché el contenido estático, selecciona el Tiempo de actividad máximo.
  
  El tiempo de actividad máximo te permite establecer el tiempo máximo para el contenido almacenado en caché que entrega este origen.
4. En Claves de caché, selecciona una de las siguientes opciones de la lista de Claves de caché:
  - Predeterminado: Incluye parámetros de consulta que se conocen en Cloud Storage.
  - Personalizado: Selecciona los componentes de la clave de caché, como la cadena de consulta o los encabezados HTTP, que Cloud CDN usa para distinguir entre las entradas de caché.
5. En Opciones avanzadas, completa lo siguiente:
  1. Selecciona un modo de compresión en la lista Modo de compresión.
    
    Para habilitar la compresión dinámica, selecciona Automática.
  2. En Entregar durante el estado de inactividad, selecciona el período durante el cual Cloud CDN continúa entregando contenido inactivo durante un error de caché o un error de origen.
6. En Contenido restringido, selecciona una de las siguientes opciones:
  - Permitir el acceso público al contenido que Cloud CDN almacena en caché: Recomendamos esta configuración para la mayoría de las situaciones.
  - Restringir el acceso con URLs firmadas y firmadas: Te permite restringir el acceso a los visualizadores autorizados. Proporciona una URL o cookie de tiempo limitado que otorga a los usuarios acceso por un tiempo limitado. Para obtener más información, consulta Usa URLs firmadas y Usa cookies firmadas.
7. Opcional: Agrega encabezados de respuesta personalizados. Para obtener más información, consulta Crea encabezados personalizados en servicios de backend.
8. Habilita el almacenamiento en caché negativo (opcional). Para obtener más información, consulta Usa el almacenamiento en caché negativo.
9. Opcional: Agrega encabezados específicos que, cuando estén presentes, omitan la caché. Para obtener más información, consulta Omite la caché.
Para crear el origen, haz clic en Listo.

Edita un origen existente

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

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

Ir a Orígenes de Cloud CDN
Haz clic en el nombre del origen que deseas editar y, luego, en Editar.
En la sección Aspectos básicos del origen, haz clic en Siguiente.
En la sección Reglas de host y ruta de acceso, haz clic en Siguiente.
En la sección Rendimiento de caché, navega a Opciones avanzadas.
En la lista Modo de compresión, selecciona Automática.
Para aplicar los cambios, haz clic en Listo.

gcloud

Para los servicios de backend, usa el comando gcloud compute backend-services create o 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 la llamada a la API Method: backendServices.insert o Method: backendServices.update.

En el caso de los buckets de backend, usa la llamada a la API Method: backendBuckets.insert o Method: backendBuckets.update.

Usa una de las siguientes llamadas a la API:

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. Solo los backends con un loadBalancingScheme de EXTERNAL pueden configurar un modo de compresión que no sea 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

En comparación con Gzip, Brotli puede producir una reducción adicional del 10% al 20% en el tamaño de la descarga para la mayoría de los tipos de contenido, con un rendimiento de descompresión similar, lo que lo hace más rápido en general cuando se considera el tiempo de descarga y descompresión en el cliente.

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.

¿Cuándo se comprime una respuesta?

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

Por ejemplo, con un encabezado Accept-Encoding en una solicitud de cliente, la respuesta se comprime (o no) de acuerdo con 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 application/csv application/json application/json+protobuf application/x-plist application/x-protobuffer application/x-protobuf application/x-protobuf application/x-protobuf
Coincidencia del patrón	application/+json application/+xml application/mpegURL text/

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.
Pesa menos de 1 KiB.

El tiempo dedicado a comprimir y descomprimir a menudo compensa cualquier beneficio. También hay menos contenido para comprimir, lo que puede reducir la efectividad de la compresión y producir 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.

Registros

Los registros de Cloud CDN y del balanceador de cargas HTTP(S) externo incluyen un campo compressionStatus en jsonPayload que indica si el balanceador de cargas comprimió la respuesta, junto con 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 se comprime una respuesta mediante Cloud CDN o Cloud Load Balancing, la salida de caché o la salida de Internet relevantes (respectivamente) se mide en función de los bytes comprimidos finales que se envían al cliente.

Si entregas una gran cantidad de respuestas que se pueden comprimir, esto puede generar una reducción en tus tarifas de salida mensual y un mayor rendimiento 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.

Deberías esperar una disminución en los bytes totales de respuesta (y la capacidad de procesamiento de salida).

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?

Para comprender cómo los modos de almacenamiento en caché facilitan el almacenamiento en caché del contenido, consulta Usa modos de almacenamiento en caché.
Si deseas habilitar Cloud CDN para las instancias de balanceo de cargas de HTTP(S) y buckets de almacenamiento, consulta Usa Cloud CDN.
Para obtener información sobre cómo invalidar memorias caché, consulta Descripción general de la invalidación de caché.
Para encontrar puntos de presencia de GFE, consulta Ubicaciones de caché.