Prácticas recomendadas para distribuir contenido

En esta página se describen las prácticas recomendadas para optimizar y acelerar la distribución de contenido con Cloud CDN. Las secciones se dividen en varias áreas clave.

Cloud CDN usa un balanceador de carga de aplicaciones externo como origen del contenido almacenable en caché. Un balanceador de carga de aplicaciones externo puede ofrecer a los usuarios una combinación de contenido estático y creado dinámicamente a través de una dirección IP global desde los siguientes tipos de back-ends:

Gracias a la integración perfecta con Google Cloud, tienes varias opciones para implementar Cloud CDN y gestionar el contenido. Sigue las prácticas recomendadas que se indican en este artículo para planificar y perfeccionar tu implementación. Para obtener más información, consulta el artículo Configurar Cloud CDN.

Optimizar la proporción de aciertos de caché

Las siguientes prácticas recomendadas ayudan a optimizar la proporción de aciertos de caché.

Contenido estático en caché

Para mejorar el rendimiento, cuando habilites Cloud CDN, debes elegir el modo de caché adecuado para tu aplicación.

El método más flexible y generalmente preferido para gestionar las reglas de caché es usar el encabezado de control de caché. Si no sabes cómo usar los encabezados Cache-Control de origen, te recomendamos que permitas que Cloud CDN almacene en caché automáticamente el contenido estático.

Para almacenar en caché automáticamente las respuestas estáticas de tu origen, puedes usar el ajuste --cache-mode=CACHE_ALL_STATIC (predeterminado). Este ajuste permite que Cloud CDN almacene en caché tipos de contenido estático comunes cuando el origen no especifica ninguna directiva de almacenamiento en caché en los encabezados de respuesta. Asegúrese de que su contenido coincida con las categorías indicadas. De lo contrario, no se almacenará en caché.

No almacenar en caché contenido específico de los usuarios

En algunos casos, los navegadores pueden almacenar en caché contenido específico de un usuario. No uses Cloud CDN para almacenar en caché contenido específico de los usuarios.

Usar claves de caché personalizadas para mejorar la proporción de aciertos de caché

Para mejorar el rendimiento y la escalabilidad, es importante optimizar la proporción de aciertos de caché. De forma predeterminada, Cloud CDN usa la URL de solicitud completa para crear la clave de caché. Para optimizar la proporción de aciertos de caché, puedes usar claves de caché personalizadas para que Cloud CDN no fragmente la caché innecesariamente.

Almacén de pares clave-valor de Cloud CDN (haz clic para ampliar).

Las claves de caché personalizadas le permiten incluir u omitir cualquier combinación de protocolo, host y cadena de consulta. A continuación, se indican algunos ejemplos de cuándo puedes usar claves de caché personalizadas:

  • Tienes dos hosts que se resuelven en la misma dirección IP y van al mismo servicio. En este ejemplo, todo el sitio web es igual en los dos hosts. De forma predeterminada, Cloud CDN almacena en caché dos copias debido al encabezado Host: diferente en las solicitudes HTTP. Con una clave de caché personalizada, puedes hacer que Cloud CDN ignore la parte del host de la solicitud y comparta las entradas de caché.

  • En un ejemplo más específico, puede que tengas dos sitios web en dominios diferentes que usen el mismo logotipo. El contenido del sitio web es diferente, pero usas el mismo logotipo de empresa en ambos dominios y tienes un servicio backend específico que contiene contenido compartido. Cuando habilites Cloud CDN y personalices las claves de caché del servicio de backend que contiene el logotipo, desmarca la casilla Host para que la caché ignore el dominio, pero almacene en caché el logotipo.

  • Un logotipo debe almacenarse en caché tanto si se muestra a través de HTTP como de HTTPS. Cuando personalices las claves de caché del servicio de backend que contiene el logotipo, desmarca la casilla Protocol (Protocolo) para que las solicitudes a través de HTTP y HTTPS se consideren coincidencias de la entrada de caché del logotipo.

Para obtener información sobre cómo personalizar las claves de caché, consulte Usar claves de caché.

Optimización del rendimiento

Las siguientes prácticas recomendadas ayudan a optimizar el rendimiento.

Asegúrate de que la compatibilidad con los protocolos HTTP/3 y QUIC esté habilitada

HTTP/3 es un protocolo de Internet de nueva generación. Se basa en QUIC, un protocolo desarrollado a partir del protocolo original Google QUIC (gQUIC). HTTP/3 se admite entre el balanceador de carga HTTP(S) externo, Cloud CDN y los clientes.

Para mejorar el rendimiento con Cloud CDN, asegúrate de que HTTP/3 esté habilitado.

Usar almacenamiento en caché negativo

El almacenamiento en caché negativo ofrece un control pormenorizado del almacenamiento en caché en caso de errores o redirecciones habituales. Cuando Cloud CDN detecta códigos de respuesta específicos, mantiene esa respuesta en la caché durante un TTL determinado. De esta forma, se puede reducir la carga de tus orígenes y mejorar la experiencia del usuario final, ya que disminuye la latencia de las respuestas.

Habilitar los datos iniciales de TLS

El uso de datos iniciales de TLS mejora la tasa de conexiones reanudadas entre un 30 y un 50 %. Para habilitar los datos iniciales de TLS, usa el comando gcloud compute target-https-proxies update con la opción tls-early-data. Para obtener más información, consulta Configurar datos iniciales de TLS.

Puedes habilitar los datos iniciales de TLS en los modos STRICT o PERMISSIVE.

  • STRICT: habilita los datos iniciales de los métodos idempotentes (GET, HEAD, OPTIONS y TRACE), que no tienen otros parámetros de consulta. Este es el método más seguro y se puede aplicar en la mayoría de los casos.
  • PERMISSIVE: habilita los datos iniciales de los métodos idempotentes que pueden incluir parámetros de consulta. Cuando uses este modo, debes monitorizar de cerca el comportamiento de tu aplicación y su nivel de seguridad.

Las solicitudes de datos iniciales que usan métodos HTTP no idempotentes o que tienen parámetros de consulta se rechazan con un código de estado HTTP 425.

Optimizar la seguridad

Las siguientes prácticas recomendadas ayudan a optimizar la seguridad.

Usar Google Cloud Armor

Cloud Armor se integra con Cloud CDN para el contenido almacenado en caché y el no almacenado en caché o que no está en caché. Te recomendamos que uses Cloud Armor junto con Cloud CDN siempre que sea posible para aumentar la seguridad de las aplicaciones web.

Usar URLs firmadas

Si usas URLs firmadas, ten en cuenta lo siguiente:

Autenticar orígenes privados

La autenticación de origen ofrece una garantía sólida de que la solicitud solo procede del servicio de backend configurado. También ofrece protección de datos en tránsito para la solicitud y protege frente a la reutilización de la parte firmada de la solicitud.

Te recomendamos que uses la autenticación de origen privado para los segmentos de Amazon S3 o los almacenes de objetos compatibles. La autenticación de origen privado ayuda a garantizar que solo las conexiones de confianza accedan al contenido de tus orígenes privados y que los usuarios no accedan directamente a ellos.

Además, si los cortafuegos de origen impiden el acceso al origen, usa la lista de permitidas de IPs para asegurarte de que una solicitud procede de Cloud CDN o del balanceador de carga de aplicaciones externo. Sin embargo, esto no impide que otros clientes de Media CDN intenten acceder a tu contenido especificando tu origen en su configuración.

Optimizar la caché

Las siguientes prácticas recomendadas ayudan a optimizar la caché.

Optimizar los TTLs de la caché

Puedes definir o anular los TTLs para ajustar el tiempo que Cloud CDN almacena en caché tus respuestas y cuándo las vuelve a validar.

También puedes definir un TTL visible para el cliente para aprovechar al máximo las cachés del navegador.

Para obtener más información, consulta Usar la configuración de TTL y las anulaciones.

Definir la caducidad del contenido urgente

Cada contenido de la caché de Cloud CDN tiene un tiempo de caducidad asociado. Es importante definir una caducidad adecuada para tu caso de uso. Como los servidores de origen deben volver a enviar el contenido que caduca en los servidores de caché, debes elegir la caducidad con cuidado.

Una forma de elegir la fecha de vencimiento es categorizar el contenido en función de la frecuencia con la que lo actualizas. Por ejemplo:

  • Actualizaciones casi en tiempo real, como feeds en directo de eventos deportivos o del tráfico
  • Actualizaciones frecuentes, como información meteorológica semanal, diaria o por horas, o imágenes de noticias de portada
  • Actualizaciones poco frecuentes, como el logotipo de un sitio web o archivos CSS o JavaScript

A continuación, elige la caducidad por categoría de contenido. Por ejemplo, una caducidad de cinco segundos podría ser adecuada para resultados deportivos casi en tiempo real, y una caducidad de una hora podría usarse para actualizaciones meteorológicas. En el caso del contenido almacenado en Cloud Storage, define los tiempos de vencimiento mediante los metadatos Cache-Control. Cuando Compute Engine sirve contenido, puedes controlar los tiempos de vencimiento configurando el software de tu servidor web.

Los tiempos de vencimiento se especifican mediante los valores max-age y s-maxage en el encabezado Cache-Control. Este encabezado se define en la especificación HTTP. Por ejemplo, el siguiente encabezado Cache-Control hace que el contenido asociado se pueda leer públicamente y se pueda almacenar en caché con una caducidad de 72 horas (259.200 segundos):

  Cache-Control: public, max-age=259200

Para maximizar el almacenamiento en caché, sigue las directrices de la descripción general del almacenamiento en caché. Recuerda que los valores de max-age y s-maxage del campo de metadatos Cache-Control funcionan conjuntamente de las siguientes maneras:

  • Los valores de max-age y s-maxage se miden en segundos.
  • El valor s-maxage solo se aplica a las cachés compartidas, no a las cachés del navegador.
  • El valor max-age se aplica a todas las cachés, a menos que s-maxage lo anule.

En el caso del contenido que cambia con poca frecuencia o que debe cambiar junto con contenido relacionado, suele ser adecuado usar un tiempo de vencimiento largo en combinación con URLs con versiones.

Usar URLs con versiones para actualizar el contenido

El control de versiones del contenido sirve una versión diferente del mismo contenido, lo que equivale a eliminarlo, ya que se muestra a los usuarios contenido nuevo antes de que caduque la entrada de la caché. Como el control de versiones es gratuito, te recomendamos que lo utilices como método predeterminado para actualizar el contenido que se puede almacenar en caché.

Para crear versiones de contenido, añade un parámetro a la URL, como un número de versión. Hay varias formas de incluir parámetros en las URLs, como las siguientes:

  • Añadir una cadena de consulta: file.ext?v=100.

    En el caso de los backend buckets, las cadenas de consulta que se utilicen para el control de versiones deben especificarse en la configuración del backend bucket. Para obtener más información, consulta la lista de inclusión de cadenas de consulta para claves de caché de Cloud Storage.

  • Cambia el nombre del archivo: file.1.0.0.ext o file_v100.ext.

  • Cambiar la ruta: /v100/file.ext.

Cuando añades el parámetro, cambias el nombre del archivo y la URL. Este cambio obliga a la caché a ignorar cualquier entrada de caché.

Usa la invalidación con moderación para retirar contenido

La invalidación elimina el contenido de los servidores de caché distribuidos de Cloud CDN antes de que caduque la entrada de caché. La invalidación acaba siendo coherente.

Te recomendamos que uses la invalidación con moderación y solo como último recurso. Por ejemplo, la invalidación es útil cuando debes retirar contenido por motivos legales o debido a una subida accidental. De lo contrario, te recomendamos que uses el control de versiones siempre que sea posible o que esperes a que el contenido caduque de forma normal. Los servidores de caché de Cloud CDN suelen eliminar el contenido al que se accede con poca frecuencia para dejar espacio para el nuevo contenido. El contenido al que no se acceda en un plazo de 30 días se retirará sin condiciones.

Las invalidaciones de caché están limitadas por la frecuencia.

Para obtener más información sobre la invalidación, consulta la descripción general de la invalidación de caché.

Optimizar la coherencia de los archivos subidos

Las siguientes prácticas recomendadas ayudan a optimizar la coherencia de las subidas de archivos.

Evitar actualizar archivos

En lugar de actualizar los archivos, sube versiones nuevas.

En el caso de los archivos nuevos, usa nombres únicos que incluyan números de versión o fechas. Si añades un número de versión (por ejemplo, file_v2.css) o una fecha (por ejemplo, file_20230806.js) al nombre del archivo, te asegurarás de que Cloud CDN obtenga la versión correcta y actualizada. No se recomienda añadir un parámetro a la URL del archivo (por ejemplo, file.css?v=2) para forzar que se obtenga una versión nueva, ya que este método no aborda el riesgo de almacenar en caché una actualización de un archivo de origen no atómico, en la que se pueden almacenar en caché archivos parciales o incompletos.

Es fundamental subir nuevas versiones de las dependencias antes de subir los archivos que las referencian. De esta forma, se asegura de que todas las referencias sean a archivos completos y actualizados, lo que reduce el riesgo de que se sirvan archivos parcialmente actualizados o truncados.

Hacer actualizaciones atómicas en archivos

Cuando sea necesario actualizar archivos, hazlo de forma atómica.

Si se accede a un archivo y se almacena en caché antes de que se complete la subida, es posible que se almacene en caché como un archivo incompleto o truncado. Por ejemplo, un archivo, como /index.html, no puede tener un nombre único, pero puede apuntar a otros archivos que sí lo tengan.

Si subes un archivo con el nombre de destino, es posible que se almacenen en caché archivos incompletos cuando se acceda a ellos durante la subida. En su lugar, sube el archivo con un nombre temporal y cámbiale el nombre al definitivo solo cuando se haya completado la subida. De esta forma, se asegura de que el archivo esté disponible de forma completa e inmediata cuando se haga referencia a él.

Cuando se actualizan archivos, la caché de intervalos de bytes puede provocar que Cloud CDN conserve intervalos del archivo anterior después de que se haya subido el nuevo archivo. Si Cloud CDN ha almacenado en caché intervalos del archivo anterior, las solicitudes de los fragmentos que faltan pueden dar lugar a respuestas parciales. Esto ocurre porque Cloud CDN detecta que el archivo de origen ha cambiado (porque han cambiado etag o last-modified), elimina el contenido obsoleto, desconecta las descargas en curso y genera un error, lo que provoca que el cliente vuelva a intentarlo. Para mitigar este problema, emite invalidaciones para los archivos almacenados en caché de intervalos de bytes que se estén actualizando.

Optimizar Monitoring y Logging

Las siguientes prácticas recomendadas ayudan a optimizar Monitoring y Logging.

Asegúrate de que el registro esté habilitado en Cloud CDN

Una práctica recomendada para gestionar Cloud CDN es asegurarse de que el registro esté habilitado en todos los back-ends de Cloud CDN.

Usar el panel de control de monitorización personalizado de Cloud CDN

Para garantizar una mayor fiabilidad y rendimiento, es recomendable revisar periódicamente las métricas de monitorización relacionadas con Cloud CDN. Un buen punto de partida es el panel de control de monitorización personalizado de Cloud CDN.

Revisar las pruebas de rendimiento de terceros

Revisa los informes de proveedores externos, como los informes de disponibilidad, latencia y rendimiento que proporciona Citrix Radar.