Activer la compression dynamique

La compression dynamique compresse automatiquement les réponses diffusées par Cloud CDN. La taille des données envoyées sur le réseau est réduite de 60 à 85 % dans les cas typiques.

La réduction de la taille réduit le temps de téléchargement du contenu. Pour les éléments importants tels que les feuilles de style (CSS), les scripts (JavaScript) et les fichiers manifestes vidéo (HLS/DASH), cela peut réduire le temps de chargement des pages et le temps de démarrage des vidéos.

Pour en savoir plus sur les avantages de la compression des réponses, consultez le guide Web Fundamentals.

Vous pouvez activer la compression sur un service de backend ou un bucket backend.

Exemples de cas d'utilisation

La compression dynamique réduit directement la taille des données envoyées de la périphérie de Cloud CDN au client. Les opérations suivantes peuvent alors être directement effectuées :

• Réduire la taille des fichiers CSS et JavaScript, ce qui permet aux pages Web de s'afficher plus rapidement et réduit la durée d'exécution de First Contentful Paint, une métrique importante en termes de performances Web.

• Avoir un impact important et positif lors de la mise en cache de réponses d'API REST, telles que des charges utiles JSON. Ces charges utiles sont compressées facilement en raison des clés, des espaces et des accolades répétés. La mise en cache d'API publiques pendant 5 à 10 secondes est une approche populaire pour réduire la charge d'origine tout en conservant l'actualisation des données.

  Même sans mise en cache, la compression de ces réponses peut réduire le nombre total d'octets envoyés jusqu'à 90 %.

• Améliorer le temps de début lecture pour la diffusion de vidéos et la latence de jointure pour la diffusion en direct. Les grandes playlists en direct (fichiers manifestes) contiennent une quantité importante de données répétées, y compris le préfixe d'hôte et de chemin d'accès de chaque segment, ainsi que les métadonnées de la playlist HLS ou DASH. Plus le téléchargement de la playlist ou les mises à jour de la playlist est rapide, moins le client doit attendre pour analyser et commencer à télécharger les séquences vidéo référencées. La taille des playlists HLS et DASH présente souvent une réduction totale de plus de 90 %.

Avant de commencer

Assurez-vous de disposer des éléments suivants:

• Un backend compatible avec Cloud CDN configuré Si Cloud CDN n'est pas actuellement configuré, vous pouvez suivre l'un des guides de configuration.
• Votre backend dispose d'un contenu compressible prêt à être diffusé, tel que des éléments Web ou des fichiers manifestes vidéo compris entre 1 Kio et 10 Mio (inclus).
• Les clients ne s'appuient pas sur la récupération d'une partie du contenu avec des requêtes de plage ou des ETag forts. Ils sont incompatibles avec la compression dynamique.
• Les clients peuvent gérer les réponses sans en-tête Content-Length. Par exemple, les défauts de cache liés à la compression de Cloud CDN n'ont pas d'en-têtes Content-Length.
• Le rôle IAM d'administrateur de l'équilibreur de charge Compute (roles/compute.loadBalancerAdmin), requis pour modifier la configuration de votre backend.

Activer la compression sur un service de backend ou un bucket backend

Pour activer la compression, procédez comme suit :

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

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

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

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

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

"compressionMode": AUTOMATIC

En quelques minutes, votre configuration se propage à tous les emplacements périphériques. Le contenu compressible diffusé à partir du backend est compressé avant d'être distribué au client.

Modes de compression

Le mode de compression par défaut est DISABLED.

Le mode AUTOMATIC permet à Cloud CDN de choisir la meilleure méthode de compression en fonction des éléments suivants :

• L'encodage accepté par le client
• Le taux de compression attendu de la réponse
• La vitesse de compression de Cloud CDN (débit)

Brotli peut permettre une réduction supplémentaire de 10 à 20 % de la taille de téléchargement pour la plupart des types de contenu par rapport à gzip, avec des performances de décompression similaires, ce qui le rend globalement plus rapide lorsque vous tenez compte du temps de téléchargement et de la vitesse de décompression au niveau du client.

Cloud CDN indique que la méthode de compression choisie est gzip ou brotli dans l'en-tête Content-Encoding de la réponse.

Cloud CDN détermine le niveau de compression pour équilibrer la taille totale de téléchargement et le coût du processeur sur le client. Des niveaux de compression plus élevés n'entraînent pas toujours de meilleures performances, en particulier sur les appareils mobiles à faible puissance.

Lorsque Cloud CDN compresse le contenu pour la première fois, il supprime l'en-tête Content-Length de la réponse. Cela est nécessaire pour permettre la diffusion de la réponse le plus rapidement possible, car la longueur totale du contenu est inconnue jusqu'à ce que l'intégralité de la réponse soit compressée. Une fois qu'une réponse a été compressée et mise en cache, Cloud CDN peut inclure l'en-tête Content-Length dans les réponses suivantes. (Pour HTTP/1.1 et les versions antérieures, Cloud CDN utilise Transfer-Encoding: chunked dans la réponse lorsqu'il n'utilise pas Content-Length.)

Quand une réponse est-elle compressée ?

Si une requête comporte un en-tête Accept-Encoding qui indique explicitement la compatibilité avec les algorithmes gzip ou Brotli, les réponses non compressées diffusées par le backend (origine) avec un en-tête Content-Type correspondant aux types de contenu compressibles sont compressées avec gzip ou Brotli, en conséquence. Si une requête n'a pas d'en-tête Accept-Encoding ou si elle contient Accept-Encoding: *, la réponse n'est pas compressée.

Par exemple, pour un en-tête Accept-Encoding dans une requête client, la réponse est compressée (ou non) selon les informations du tableau suivant:

Types de contenus compressibles

La compression dynamique s'applique aux types MIME suivants, en fonction de l'en-tête de réponse HTTP Content-Type. Les réponses qui n'ont pas d'en-tête de réponse Content-Type ne sont pas compressées.

Les types de contenu courants et leurs types MIME sont les suivants :

• Contenu HTML : text/html
• Feuilles de style : text/css
• JavaScript : application/javascript
• JSON : application/json
• Playlists HLS : application/x-mpegURL ou application/vnd.apple.mpegURL
• Fichiers manifestes DASH : application/dash+xml

Le tableau suivant récapitule l'impact du type MIME sur la compression.

Les formats d'image et de vidéo (tels que image/jpeg, image/png et video/mpeg4) sont presque toujours déjà compressés. Par conséquent, Cloud CDN ne les compresse pas. La recompression d'une réponse déjà compressée réduit rarement la taille du fichier, et les clients peuvent présenter un comportement inattendu lorsqu'ils reçoivent une réponse de ce type.

Quand une réponse n'est-elle pas compressée ?

La compression dynamique ne compresse pas une réponse présentant une ou plusieurs des caractéristiques suivantes :

• La réponse ne comporte pas d'en-tête Content-Type correspondant à un type de contenu compressible.
• Elle n'a pas d'en-tête Content-Length.
• Elle comporte un en-tête Content-Encoding.

• La taille d'un fichier est inférieure à 1 Kio.

  Le temps passé à compresser et à décompresser est souvent compensé par les avantages offerts par ce service. Le nombre de contenus à compresser est également limité, ce qui peut réduire l'efficacité de la compression et entraîner un taux de compression inférieur.

• Elle est supérieure à 10 Mio.

• Elle comporte un en-tête Cache-Control: no-transform.

• Elle comporte un en-tête Vary: Accept-Encoding.

Requêtes de plage

Lorsque Cloud CDN compresse une réponse, il ajoute un en-tête Accept-Ranges: none et remplace tous les en-têtes Accept-Ranges existants. Les succès de cache (hit) de ces réponses ignorent les en-têtes Range.

Cela empêche la diffusion de contenu partiel incorrect aux clients, car il est impossible de savoir si un client attend une plage d'octets de la forme compressée ou non compressée d'une ressource.

ETags

Lorsque la compression dynamique compresse une réponse, tous les en-têtes ETag fortes sont affaiblies, conformément à la section 2.3 du document RFC 7232. Par exemple, ETag: "xyzzy" est remplacé par ETag: W/"xyzzy".

En-tête Vary

Lors de la diffusion d'une réponse pouvant être compressée (en fonction de la requête), Cloud CDN ajoute l'en-tête Vary: Accept-Encoding à la réponse.

Résumé des modifications des réponses

Le tableau suivant récapitule les modifications que Cloud CDN apporte aux en-têtes d'une réponse en cas de compression:

Journalisation

Les journaux Cloud CDN incluent un champ compressionStatus dans jsonPayload, qui indique si la réponse a été compressée par l'équilibreur de charge et le type de compression.

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

Facturation

Lorsqu'une réponse est compressée par Cloud CDN ou Cloud Load Balancing, le transfert de données du cache sortant ou le transfert de données Internet sortant approprié est mesuré par rapport aux derniers octets compressés envoyés au client.

Si vous diffusez une grande quantité de réponses compressibles, cela peut entraîner une réduction des frais mensuels de transfert de données sortant, ainsi qu'une amélioration des performances pour les utilisateurs finaux.

de régression

Lorsque la compression est activée, la métrique https/response_bytes_count existante sous loadbalancing.googleapis.com indique la taille de la réponse compressée.

Vous pouvez vous attendre à une baisse du nombre total d'octets de réponse (et du débit de transfert de données sortant).

Si vous diffusez une grande quantité de contenu textuel se compressant bien (par exemple, HTML, CSS, JavaScript ou JSON), vous risquez de constater une baisse importante du nombre d'octets de réponse.

Pour en savoir plus, consultez la section Surveillance.

Étapes suivantes

• Pour comprendre comment les modes de cache facilitent la mise en cache du contenu, consultez la page Modifier les modes de cache.
• Pour activer Cloud CDN pour vos instances à équilibrage de charge HTTP(S) et vos buckets de stockage, consultez la page Présentation de la configuration.
• Consultez la page Présentation de l'invalidation de cache pour en savoir plus sur l'invalidation de cache.
• Pour trouver des points de présence GFE, consultez la section Emplacements de cache.