Les sites statiques restent en ligne pendant leur republication

Republier un site statique sur Mythex supprimait autrefois les fichiers en ligne avant de téléverser la nouvelle version : pendant toute la durée du transfert, certains visiteurs obtenaient une page 404 ou une page dont les scripts manquaient. Un téléversement échoué pouvait laisser le site vide ou à moitié nouveau. Désormais, la nouvelle version est écrite par-dessus l'ancienne, les pages en dernier, et les fichiers restants sont supprimés quelques minutes plus tard. Une seconde correction fait apparaître une republication en quelques secondes au lieu d'une minute — ou, pour des fichiers comme un logo, jusqu'à un jour.

Comment un site statique est servi

Un site statique est constitué uniquement de fichiers : pages HTML, JavaScript, CSS, images. Quand vous le publiez sur Mythex, nous le construisons, nous envoyons le résultat dans un stockage objet sous un dossier propre à votre site, et nous le servons via un réseau de périphérie — des serveurs proches de vos visiteurs qui récupèrent les fichiers depuis le stockage et en gardent des copies un certain temps. (Si c'est nouveau pour vous, notre guide sur ce qu'est un CDN explique l'idée.)

Deux éléments étaient défaillants : l'ordre dans lequel une republication modifiait les fichiers, et la durée de conservation des anciennes copies.

Problème 1 : le téléversement vidait d'abord le site

Une republication supprimait tout le contenu du dossier du site, puis téléversait la nouvelle version. Pendant toute la durée du transfert — 12 secondes pour un site de 250 fichiers dans notre test local — un visiteur dont la requête n'était pas déjà en cache sur la périphérie obtenait un 404, ou une page HTML dont les scripts renvoyaient un 404.

Un téléversement échoué était pire. Le dossier était déjà vide, et sur l'une des deux méthodes de téléversement, le nouveau index.html pouvait être écrit avant le fichier qui avait échoué. Une publication signalée comme échouée pouvait laisser un site à moitié nouveau en ligne.

La correction : écrire par-dessus, les pages en dernier, nettoyer plus tard

1. Ne pas supprimer d'abord. La nouvelle version est téléversée par-dessus l'ancienne.
2. Les ressources avant les pages. Une page nomme les scripts et styles dont elle a besoin, donc les pages sont envoyées en dernier. Jusqu'à l'arrivée des nouvelles pages, les visiteurs reçoivent l'ancienne page, qui nomme les anciennes ressources, toujours présentes. Une fois les nouvelles pages arrivées, les nouvelles ressources qu'elles nomment sont déjà en place.
3. Supprimer les restes plus tard. Avant le téléversement, nous listons ce dont le site est constitué. Trois minutes après un téléversement réussi, tout élément de cette liste que la nouvelle version n'a pas réécrit est supprimé. Trois minutes dépassent les 60 secondes pendant lesquelles une page peut être mise en cache sur la périphérie et dans le navigateur, si bien qu'un visiteur qui détient encore l'ancienne page peut trouver les ressources qu'elle nomme.
4. En cas de doute, ne rien supprimer. Si la liste établie avant le téléversement échoue, rien n'est purgé. Les fichiers restants sont inoffensifs, et la publication suivante les nettoie. Supprimer sans savoir ce qui se trouvait là est la façon dont un site finit vide.

Un téléversement échoué laisse désormais le site précédent exactement tel qu'il était.

Nous avons testé cela de bout en bout en local, avec le vrai script de téléversement, la vraie route de téléversement et le service de stockage réel, et des visiteurs arrivant avec un cache de périphérie froid. Avec l'ancien code, 55 visites sur 91 étaient cassées pendant une republication, et 61 sur 92 pendant une republication échouée. Avec le nouveau code, 0 n'étaient cassées sur environ 3 500 visites couvrant les deux méthodes de téléversement, un téléversement échoué et la publication qui a suivi — et exactement les fichiers restants ont été purgés.

Problème 2 : une republication mettait trop de temps à apparaître

Même quand le téléversement se passait bien, les changements apparaissaient lentement. La périphérie gardait sa copie d'une page pendant 60 secondes et de chaque autre fichier pendant un jour, et indiquait la même durée aux navigateurs. Les fichiers au nom fixe — logo.png, une police, tout élément d'un dossier public/ — pouvaient afficher l'ancienne version jusqu'à un jour après une republication.

La correction : des copies de fichiers sous la version de build

Quand la périphérie demande à notre API où se trouve un site, la réponse comporte désormais un marqueur de build qui change à chaque publication. La périphérie range ses copies sous ce marqueur. Une publication devient donc un tout nouvel ensemble de clés de cache dès que la recherche de 30 secondes de la périphérie expire. Les anciennes copies ne sont plus jamais retrouvées, si bien que la périphérie peut les conserver un jour sans jamais servir une copie postérieure à la publication qui l'a remplacée.

Les navigateurs suivent deux règles différentes :

• Les sorties de build avec un hachage — des fichiers comme assets/index-CzLcxDO8.js, dont le nom change dès que le contenu change — sont mis en cache pendant un an et marqués comme immuables. Sous ce nom, ils ne peuvent jamais être périmés.
• Tout le reste — les pages et les fichiers au nom fixe comme un logo — est marqué no-cache, ce qui signifie « vérifier avant utilisation ». Si rien n'a changé, la réponse est un minuscule 304 Not Modified sans contenu, désormais que nous respectons la vérification If-None-Match du navigateur.

Distinguer les deux demande de la rigueur : un fichier copié depuis public/assets/ conserve son propre nom, et mettre en cache assets/logo.png pendant un an figerait l'ancien logo pendant un an. Un fichier n'est donc considéré comme haché que s'il se trouve dans un dossier de sortie de build et si son nom comporte un segment qui ressemble à un hachage, et non à un mot ordinaire.

En local, la nouvelle page et le nouveau logo étaient visibles 6 secondes après la mise en ligne de la publication. Auparavant, c'était 60 secondes pour la page et un jour pour le logo.

Deux corrections plus modestes en chemin

• Pages vides avec les requêtes HEAD. Une requête HEAD demande les en-têtes d'une page sans son contenu. Nous mettions en cache ces réponses vides, si bien que le visiteur suivant de cette page recevait une page blanche. Les réponses HEAD ne sont plus mises en cache.
• Une vraie page pour « rien ici ». Une adresse sans application renvoyait autrefois un texte brut « Cette application publiée est hors ligne ou le lien est introuvable » avec un code d'erreur 502. Elle affiche désormais une page adaptée, « Il n'y a pas d'application ici », avec un statut 404 et un moyen de revenir vers Mythex pour le propriétaire. Les domaines personnalisés inconnus reçoivent la même page.

Ce que nous en avons retenu

• L'ordre fait partie de la justesse. Les mêmes fichiers téléversés dans un ordre différent font la différence entre un site cassé et un site qui fonctionne.
• Supprimer tard, et seulement ce que l'on connaît. Purger avec une liste établie avant le téléversement est sûr ; vider un dossier en espérant que le téléversement aboutisse ne l'est pas.
• Mettre en cache par version, pas par durée. Les durées d'expiration sont une supposition sur le moment où le contenu change. Une clé qui change avec le build, elle, est un fait.

À lire aussi : votre application publiée reste en ligne pendant que vous la republiez. Pour en savoir plus sur la publication, consultez la documentation.