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.

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

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

Vous pouvez activer la compression sur un service de backend ou sur 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. Cela permet d'obtenir directement les résultats suivants :

  • Réduction de la taille des fichiers CSS et JavaScript, ce qui permet aux pages Web de s'afficher plus rapidement et réduit le délai avant le First Contentful Paint, une métrique de performances Web importante.

  • Impact important et positif lors de la mise en cache des réponses d'API REST, telles que des charges utiles JSON. La compression de ces charges utiles est très efficace du fait de la répétition des caractères, des espaces et des accolades. La mise en cache d'API publiques pendant 5 à 10 secondes est une approche populaire pour réduire la charge d'origine tout en préservant 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élioration du délai de démarrage de la lecture pour la diffusion de vidéos et de la latence pour rejoindre une 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 séquence, ainsi que les métadonnées de playlist HLS ou DASH. Plus le téléchargement de la playlist ou de ses mises à jour 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 configuré, sur lequel CDN est activé. Si vous n'avez pas configuré Cloud CDN, vous pouvez suivre l'un des guides de configuration.
  • Votre backend héberge un contenu compressible prêt à être diffusé, tel que des éléments Web ou des fichiers manifestes vidéo dont la taille est comprise entre 1 Kio et 10 Mio (inclus).
  • Les clients ne s'appuient pas sur la récupération de contenu partiel avec des requêtes de plage ou des ETags renforcés. Ces éléments sont incompatibles avec la compression dynamique.
  • Les clients peuvent gérer les réponses sans en-têtes Content-Length. Par exemple, les défauts de cache (miss) compressés par Cloud CDN ne comportent pas d'en-têtes Content-Length.
  • Vous disposez du rôle d'administrateur de l'équilibreur de charge Compute (roles/compute.loadBalancerAdmin), qui est nécessaire pour modifier votre configuration de backend.

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

Pour activer la compression, procédez comme suit :

Console

Ajouter une origine

Pour ajouter et configurer une origine, suivez les instructions de la section Présentation de la configuration correspondant au type de backend adéquat. Lorsque vous créez votre origine, utilisez la section Options avancées pour configurer la compression dynamique en sélectionnant Automatique dans la liste Mode de compression.

Modifier une origine existante

Pour modifier une origine Cloud CDN existante, procédez comme suit :

  1. Dans la console Google Cloud , accédez à la page Origines de Cloud CDN.

    Accéder à la page Origines

  2. Cliquez sur le nom de l'origine que vous souhaitez modifier, puis sur Modifier.

  3. Dans la section Blocs de base de l'origine, cliquez sur Suivant.

  4. Dans la section Règles d'hôte et de chemin d'accès, cliquez sur Suivant.

  5. Dans la section Performances des caches, accédez à Options avancées.

  6. Dans la liste Mode de compression, sélectionnez Automatique.

  7. Pour appliquer vos modifications, cliquez sur OK.

gcloud

Pour les services de backend, exécutez la commande gcloud compute backend-services create ou la commande gcloud compute backend-services update avec l'option --compression-mode.

Pour les buckets backend, exécutez la commande gcloud compute backend-buckets create ou la commande gcloud compute backend-buckets update avec l'option --compression-mode.

Pour un nouveau service de backend, utilisez la commande create.

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

Pour un service de backend existant, utilisez la commande update.

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

Pour un nouveau bucket backend, utilisez la commande create.

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

Pour un bucket backend existant, utilisez la commande update.

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

L'élément compression-mode peut prendre l'une des valeurs suivantes :

  • AUTOMATIC : utilise automatiquement la meilleure compression en fonction de l'en-tête Accept-Encoding envoyé par le client. Dans la plupart des cas, cela conduit à privilégier la compression Brotli.
  • DISABLED (par défaut) : désactive la compression.

API

Pour les services de backend, utilisez la méthode backendServices.insert ou la méthode backendServices.update.

Pour les buckets backend, utilisez la méthode backendBuckets.insert ou la méthode backendBuckets.update.

Utilisez l'une des commandes suivantes :

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

Ajoutez l'extrait suivant au corps de la requête JSON :

"compressionMode": AUTOMATIC

L'élément compression-mode peut prendre l'une des valeurs suivantes :

  • AUTOMATIC (recommandé) : utilise automatiquement la meilleure compression en fonction de l'en-tête Accept-Encoding envoyé par le client. Dans la plupart des cas, cela conduit à privilégier la compression Brotli.
  • DISABLED (par défaut) : désactive la compression.

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 :

  • Encodage accepté par le client
  • Taux de compression attendu de la réponse
  • Vitesse de compression de Cloud CDN (débit)

Brotli permet d'atteindre 10 à 20 % de réduction en plus par rapport à gzip sur la taille de téléchargement de la plupart des types de contenu, tout en offrant des performances de décompression similaires. Cela le rend donc globalement plus rapide lorsque l'on tient compte du temps de téléchargement et de la vitesse de décompression du client.

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

Cloud CDN détermine le niveau de compression afin d'é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.

Lors de la compression initiale du contenu par Cloud CDN, celui-ci supprime l'en-tête Content-Length de la réponse. Cela est nécessaire pour permettre à la réponse d'être diffusée le plus rapidement possible, car la longueur totale du contenu n'est pas connue tant que la réponse n'a pas été entièrement 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 prise en charge des algorithmes gzip ou Brotli, les réponses non compressées diffusées à partir du backend (origine) avec un en-tête Content-Type correspondant aux types de contenu compressibles sont en conséquence compressées avec gzip ou Brotli. Si une requête ne comporte pas d'en-tête Accept-Encoding ou si elle comporte un en-tête Accept-Encoding: *, la réponse n'est pas compressée.

Par exemple, pour une requête client présentant un en-tête Accept-Encoding, la réponse est compressée (ou non) en fonction des informations fournies dans le tableau suivant :

En-tête de requête Accept-Encoding Encodage de la réponse
gzip, compress, br Brotli (br)
deflate Non compressée
deflate, gzip gzip
identity Non compressée
* Non compressée

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 ne présentent pas d'en-tête de réponse Content-Type ne sont pas compressées.

Les types de contenu courants et les types MIME correspondants 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 compressibilité.

  Types MIME compressibles
Correspondance exacte 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
Correspondance de schéma application/*+json
application/*+xml
application/*mpegURL
text/*

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 présente pas d'en-tête Content-Type correspondant à un type de contenu compressible.
  • Elle ne présente pas d'en-tête Content-Length.
  • Elle comporte un en-tête Content-Encoding.

  • Sa taille est inférieure à 1 Kio.

    Le temps passé à compresser et à décompresser annule souvent les éventuels avantages. Il y a également moins de contenu à compresser, ce qui peut réduire l'efficacité de la compression et entraîner un taux de compression inférieur.

  • Sa taille dépasse 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 pour ce type de réponse ignorent les en-têtes Range.

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

ETags

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

En-tête Vary

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

Récapitulatif des modifications apportées aux réponses

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

En-tête de réponse Valeur de l'en-tête après la compression
Content-Encoding Défini sur gzip ou brotli.
ETag Tout tag d'entité fort est remplacé par une version affaiblie, indiquée par le préfixe W/.
Accept-Ranges Défini sur la valeur none.
Content-Length Peut être entièrement supprimé ou, s'il est présent, défini sur la longueur du contenu du corps compressé.
Transfer-Encoding Pour les protocoles HTTP/1.1 et antérieurs, si Cloud CDN supprime Content-Length, il ajoute cet en-tête, dont la valeur est définie sur chunked, et fragmente le corps de la réponse.

Journalisation

Les journaux Cloud CDN incluent un champ compressionStatus dans l'élément jsonPayload, qui indique si la réponse a été compressée par l'équilibreur de charge, ainsi que 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 sortantes du cache ou le transfert de données sortantes Internet respectif est mesuré par rapport aux octets compressés finaux envoyés au client.

Si vous diffusez une grande quantité de réponses compressibles, cela peut entraîner une réduction de vos frais mensuels sur le transfert de données sortantes tout en améliorant les performances pour les utilisateurs finaux.

Métriques

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

Vous devriez constater une diminution du nombre total d'octets de réponse (et du débit de transfert de données sortantes).

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

Pour en savoir plus, consultez la section Surveillance.

Étapes suivantes