La livraison frontale à l’ère de la publication à haute fréquence nécessite de repenser la collaboration en matière de mise en cache et de compression.

Une fois que les ressources frontales entreront dans un rythme de publication à haute fréquence, les problèmes de performances ne seront bientôt plus aussi simples que « allumer Brotli ». Le premier écran ralentit, le trafic de retour à l’origine augmente et le processeur du nœud périphérique tremble. En apparence, il semble que la compression ne soit pas assez agressive. En regardant plus en profondeur, c’est souvent la mise en cache et la compression qui sont optimisées séparément, et finissent par s’affaiblir sur le lien de publication.

Ce genre de problème n’est généralement pas exposé dans la première version. Au début, l’équipe ne voyait que quelques signaux épars : un petit changement provoquait une panne du taux de réussite des ressources statiques, une augmentation anormale de la compression de bord du processeur à la veille d’une promotion majeure et le volume des paquets de retour dans l’étape en niveaux de gris ne correspondait pas au trafic officiel. Si vous continuez à vérifier, les indices convergent généralement vers la même chose : bien que le contenu de la ressource n’ait que peu changé, la clé de cache, le fractionnement des morceaux et l’entrée compressée sont devenus un ensemble de choses différent, et la couche de transport est obligée d’avaler à nouveau la totalité du coût.

Tant que le hachage des ressources n’est pas stable, les avantages de la compression sont tout simplement intenables.

Une fois les projets front-end publiés en parallèle avec plusieurs pages, plusieurs itinéraires et plusieurs équipes, l’aspect le plus souvent négligé est la stabilité des noms de fichiers. Tant que la segmentation des morceaux dérive légèrement, même si le code métier ne modifie que la copie d’un bouton, le produit final peut également réécrire le hachage d’une série de bundles publics. Ce que le système de mise en cache voit, c’est un lot de nouveaux objets, et ce que voit le système de compression, c’est un lot d’entrées qui apparaissent pour la première fois.

À l’heure actuelle, quel que soit le taux de compression, il ne peut pas empêcher le taux de réussite de s’effondrer. Les anciens fichiers se trouvent toujours dans les nœuds périphériques et les nouveaux fichiers ont été retouchés ; le cache local du navigateur est complètement invalide et le CDN doit extraire à nouveau la source, recompresser et redistribuer. Un changement dans une petite entreprise se transforme en un travail répété sur l’ensemble de la liaison de transmission.

L’action vraiment utile n’est généralement pas de continuer à ajuster le niveau de compression, mais de contrôler d’abord la stabilité du produit libéré :

• Les dépendances publiques sont découpées en couches distinctes pour réduire les changements commerciaux et regrouper les packages de base pour modifier le hachage.
• Évitez de mélanger des changements à haute fréquence tels que les horodatages et créez des numéros directement dans le contenu du produit.
• Laissez le code proche du même itinéraire tomber en morceaux stables autant que possible au lieu d’être remanié à chaque fois qu’il est compilé.

Ce n’est que lorsque l’identité de la ressource est stabilisée que le cache peut être réutilisé en continu et que les résultats de la compression ont une valeur cumulative.

Une conférence de presse à haute fréquence réécrit le problème de compression en un problème de version de dictionnaire

Alors que les ressources deviennent de plus en plus fragmentées, le Brotli ou gzip à fichier unique reste important, mais ce n’est plus tout. Le coût réel commence à se déplacer vers les éléments en double : le code d’exécution du framework, les modèles de style, les déclarations de type d’interface, les couches d’empaquetage générées par les empaqueteurs, sont souvent très similaires entre les lots de versions. Avec un tempo de release rapide, ces riffs seront transférés encore et encore.

Le problème est que le dictionnaire de compression peut facilement passer d’une optimisation à une perturbation s’il n’est pas géré en même temps que la cadence de publication. Si le dictionnaire est changé à l’avance, le nouveau dictionnaire référencé par l’ancienne page ne correspondra pas ; le dictionnaire est découpé en trop de morceaux et le nombre de versions à maintenir par les nœuds périphériques augmente fortement ; la mise à jour du dictionnaire n’est pas synchronisée avec la ressource en ligne et les objets qui auraient dû être touchés sont renvoyés en transmission complète.

Il s’agit également d’un changement très pratique dans la récente livraison front-end : les stratégies de mise en cache et les protocoles de compression ne peuvent plus être maintenus par différentes équipes. Les versions de ressources, les versions de dictionnaire et les espaces de clés de cache constituent essentiellement le même problème de publication.

Une approche hiérarchique comme celle-ci est généralement plus stable qu’une « compression forte unifiée pour l’ensemble du site » :

const policy = {
  immutableAssets: 'public, max-age=31536000, immutable',
  releaseManifest: 'public, max-age=60, stale-while-revalidate=30',
  sharedDictionary: 'versioned-by-release-train'
}

La clé n’est pas la configuration elle-même de ces trois lignes, mais les contraintes qu’elles expriment : les ressources à cycle de vie long, la liste à cycle de vie courte et la version compressée du dictionnaire doivent évoluer ensemble selon le même rythme de publication.

La pression du retour à la source n’est souvent pas due au fait que le fichier est trop volumineux, mais au fait que la méthode d’échec est trop brutale.

Une autre erreur d’appréciation très courante consiste à attribuer l’augmentation de la bande passante directement au poids de la page. Les pages deviennent certainement plus lourdes, mais les amplis en ligne les plus dangereux sont généralement la solution.

Si vous purgez par répertoire, préfixe ou même l’intégralité du site à chaque publication, la couche cache perdra instantanément sa mémoire. À ce stade, même si la taille du fichier ne continue pas à augmenter, la valeur maximale de retour à l’origine augmentera d’elle-même. Dès que la source est renvoyée, les bords sont recompressés, les objets sont réchauffés et le navigateur est retéléchargé. La fenêtre de publication passera d’un petit changement progressif à une relocalisation complète du site.

Dans ce type de scénario, la chose la plus précieuse est le rayon de défaillance contrôlable :

- Invalider uniquement les ressources manifestes, HTML et mutables qui ont réellement changé

• Essayez de ne pas purger les fichiers statiques avec du hachage et transférez-les à de nouvelles références pour une commutation naturelle.
• Diviser la version dans l’ordre suivant : “Télécharger d’abord les nouvelles ressources, puis supprimer les références, puis recycler les anciennes ressources” au lieu de les effacer toutes en même temps.

Ce qui est vraiment sensible concernant le coût de transfert n’est pas seulement la taille du fichier, mais aussi la façon dont le système décide quel contenu doit être récupéré.

La limite applicable est déterminée en même temps que l’échelle des ressources et la fréquence de libération.

Cet ensemble de co-conception n’est pas obligatoire pour tous les sites. Pour les projets avec un petit nombre de pages statiques, un petit package de ressources et une fréquence de publication hebdomadaire, voire mensuelle, l’utilisation de noms de fichiers de hachage traditionnels ainsi que la précompression Brotli est généralement suffisamment stable.

La mise en cache et la compression deviennent rapidement une infrastructure de livraison une fois que ces caractéristiques sont en place :

• Publié plusieurs fois par jour, avec des lancements en niveaux de gris, en restauration ou régionaux
• Le produit frontal est de grande taille, comporte de nombreuses dépendances publiques et des relations de fragments complexes.
• CDN, stockage objet, compression Edge et mise en cache du navigateur participent simultanément au lien de transmission
• Le trafic est si élevé que le taux de réussite du cache et la valeur maximale de retour à l’origine refléteront directement le coût et la stabilité.

Une fois que la livraison frontale entre dans cette étape, la compression ne consiste plus simplement à « réduire la taille des fichiers » et la mise en cache ne consiste plus simplement à « stocker davantage de copies de contenu ». Ce que les deux décident ensemble, c’est : en cas de changement dans une petite entreprise, s’il s’agit simplement d’envoyer un morceau supplémentaire ou si l’ensemble de la liaison de transmission doit être à nouveau exécuté. Plus vous publiez fréquemment, plus cette différence devient coûteuse.