Les sites statiques restent en ligne pendant leur republication

Republier un site statique sur Mythex supprimait auparavant les fichiers en ligne avant de téléverser la nouvelle version ; pendant toute la durée du téléversement, certains visiteurs obtenaient donc une page 404 ou une page dont les scripts étaient manquants. Un téléversement raté 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'à une journée.

Comment un site statique est servi

Un site statique est constitué uniquement de fichiers : pages HTML, JavaScript, CSS, images. Lorsque vous le publiez sur Mythex, nous le compilons, nous téléversons le résultat dans un stockage d'objets, dans un dossier propre à votre site, et nous le servons par un réseau de périphérie — des serveurs proches de vos visiteurs qui récupèrent les fichiers dans le stockage et en conservent des copies pendant un certain temps. (Si ce concept vous est nouveau, notre guide sur ce qu'est un CDN l'explique.)

Deux éléments posaient problème : 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 téléversement — 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 une 404, ou une page HTML dont les scripts renvoyaient une 404.

Un téléversement échoué était pire. Le dossier était déjà vide, et sur l'un des deux chemins de téléversement, le nouveau index.html pouvait arriver 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, 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 les styles dont elle a besoin ; les pages sont donc envoyées en dernier. Tant que les nouvelles pages ne sont pas arrivées, les visiteurs reçoivent l'ancienne page, qui nomme les anciennes ressources, lesquelles sont toujours là. Une fois les nouvelles pages en place, les nouvelles ressources qu'elles nomment sont déjà présentes.
3. Supprimer les fichiers restants plus tard. Avant le téléversement, nous listons les éléments qui composent le site. 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 ; un visiteur qui détient encore l'ancienne page peut donc trouver les ressources qu'elle nomme.
4. En cas de doute, ne rien supprimer. Si le listage précédant le téléversement échoue, aucun élément n'est élagué. Les fichiers restants sont sans conséquence, 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 maintenant l'ancien site 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 vrai service de stockage, et avec des visiteurs arrivant sur 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 visite n'était cassée sur environ 3 500 visites couvrant les deux chemins de téléversement, un téléversement échoué et la publication qui suit — et seuls les fichiers restants attendus ont été supprimés.

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

Même lorsque le téléversement se passait bien, les modifications apparaissaient lentement. La périphérie conservait sa copie d'une page pendant 60 secondes et celle de tous les autres fichiers pendant une journée, et elle demandait aux navigateurs de faire de même. Les fichiers à nom fixe — logo.png, une police, tout ce qui vient d'un dossier public/ — pouvaient afficher l'ancienne version jusqu'à une journée après une republication.

La correction : des copies de fichiers sous une version de compilation

Lorsque la périphérie demande à notre API où vit un site, la réponse contient maintenant un marqueur de compilation 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 une journée sans jamais servir une copie au-delà de la publication qui l'a remplacée.

Les navigateurs suivent deux règles différentes :

• Les sorties de compilation avec empreinte — des fichiers comme assets/index-CzLcxDO8.js, dont le nom change quand 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 — pages et fichiers à nom fixe comme un logo — est marqué no-cache, ce qui signifie « vérifier avant d'utiliser ». Si rien n'a changé, la réponse est un minuscule 304 Not Modified sans contenu, car nous respectons maintenant la vérification If-None-Match du navigateur.

Distinguer les deux demande de la prudence : un fichier copié depuis public/assets/ conserve son propre nom, et mettre assets/logo.png en cache pendant un an figerait l'ancien logo pour un an. Un fichier n'est donc considéré comme haché que s'il se trouve dans un dossier de sortie de compilation et que son nom contient 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 une journée pour le logo.

Deux corrections plus petites 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 « il n'y a rien ici ». Une adresse sans application renvoyait auparavant un texte brut « Cette application publiée est hors ligne ou le lien est introuvable » avec un code d'erreur 502. Elle affiche maintenant une vraie page, « 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.
• Supprimez tard, et seulement ce que vous connaissez. Élaguer à partir d'un listage pris avant le téléversement est sûr ; vider un dossier en espérant que le téléversement se termine ne l'est pas.
• Mettez 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 la compilation est un fait.

Voir aussi : votre application publiée reste en ligne pendant que vous la republiez. Plus d'informations sur la publication dans la documentation.