Statische Websites bleiben jetzt online, während sie neu veröffentlicht werden

Das Neu-Veröffentlichen einer statischen Website auf Mythex hat früher zuerst die Live-Dateien gelöscht und dann den neuen Build hochgeladen. Während des Uploads bekamen deshalb manche Besucher eine 404-Seite oder eine Seite, deren Skripte fehlten. Ein fehlgeschlagener Upload konnte die Website leer oder halb neu zurücklassen. Jetzt wird der neue Build über den alten geschrieben, Seiten kommen zuletzt, und Reste werden einige Minuten später entfernt. Eine zweite Korrektur sorgt dafür, dass eine Neuveröffentlichung in Sekunden statt in einer Minute sichtbar wird, oder bei Dateien wie einem Logo bis zu einem Tag braucht.

So wird eine statische Website ausgeliefert

Eine statische Website besteht nur aus Dateien: HTML-Seiten, JavaScript, CSS, Bilder. Wenn Sie eine auf Mythex veröffentlichen, bauen wir sie, laden das Ergebnis in einen Objektspeicher in einen Ordner für Ihre Website hoch und liefern sie über ein Edge-Netzwerk aus, also Server nah bei Ihren Besuchern, die Dateien aus dem Speicher holen und eine Zeit lang Kopien behalten. (Falls Sie neu dabei sind: Unser Leitfaden zu was ein CDN ist erklärt die Idee.)

Zwei Dinge waren falsch: die Reihenfolge, in der eine Neuveröffentlichung die Dateien änderte, und wie lange alte Kopien aufbewahrt wurden.

Problem 1: Der Upload leerte die Website zuerst

Eine Neuveröffentlichung löschte alles im Ordner der Website und lud dann den neuen Build hoch. Solange der Upload dauerte, also in unserem lokalen Test 12 Sekunden für eine Website mit 250 Dateien, bekam ein Besucher, dessen Anfrage nicht schon am Edge zwischengespeichert war, eine 404-Seite oder eine HTML-Seite, deren Skripte 404 lieferten.

Ein fehlgeschlagener Upload war schlimmer. Der Ordner war bereits leer, und auf einem der beiden Upload-Pfade konnte die neue index.html landen, bevor die fehlgeschlagene Datei kam. Eine als fehlgeschlagen gemeldete Veröffentlichung konnte eine halb neue Website live lassen.

Die Lösung: überschreiben, Seiten zuletzt, Reste später entfernen

1. Nicht zuerst löschen. Der neue Build wird über den alten hochgeladen.
2. Assets vor Seiten. Eine Seite nennt die Skripte und Stile, die sie braucht, deshalb kommen Seiten zuletzt hoch. Bis die neuen Seiten ankommen, bekommen Besucher die alte Seite, die auf die alten Assets verweist, und die sind noch da. Wenn die neuen Seiten ankommen, sind die neuen Assets, die sie nennen, bereits vorhanden.
3. Reste später entfernen. Vor dem Upload erfassen wir, woraus die Website besteht. Drei Minuten nach einem erfolgreichen Upload wird alles aus dieser Liste gelöscht, das der neue Build nicht überschrieben hat. Drei Minuten sind länger als die 60 Sekunden, für die eine Seite am Edge und im Browser zwischengespeichert werden könnte, daher finden Besucher, die noch die alte Seite haben, die Assets, auf die sie verweist.
4. Im Zweifel nichts löschen. Schlägt das Auflisten vor dem Upload fehl, wird nichts bereinigt. Übrig gebliebene Dateien sind harmlos, und die nächste Veröffentlichung räumt sie auf. Löschen, ohne zu wissen, was da war, ist der Weg, wie eine Website leer wird.

Ein fehlgeschlagener Upload lässt jetzt die vorherige Website genau so, wie sie war.

Wir haben das lokal Ende-zu-Ende getestet, mit dem echten Upload-Skript, der echten Upload-Route und der Auslieferung aus dem Speicher, und mit Besuchern, die auf einen kalten Edge-Cache treffen. Mit dem alten Code waren 55 von 91 Besuchen während einer Neuveröffentlichung gestört und 61 von 92 während einer fehlgeschlagenen. Mit dem neuen Code waren 0 gestört, bei rund 3.500 Besuchen, die beide Upload-Pfade, einen fehlgeschlagenen Upload und die Veröffentlichung danach abdeckten. Und genau die Reste wurden entfernt.

Problem 2: Eine Neuveröffentlichung brauchte zu lange, bis sie sichtbar war

Auch wenn der Upload gut lief, erschienen Änderungen nur langsam. Der Edge behielt seine Kopie einer Seite 60 Sekunden und die jeder anderen Datei einen Tag, und wies Browser an, es genauso zu machen. Dateien mit festem Namen, etwa logo.png, eine Schrift oder alles aus einem Ordner public/, konnten nach einer Neuveröffentlichung bis zu einem Tag lang die alte Version zeigen.

Die Lösung: Dateikopien unter dem Build-Stand

Wenn der Edge bei unserer API nachfragt, wo eine Website liegt, enthält die Antwort jetzt eine Build-Markierung, die sich bei jeder gelandeten Veröffentlichung ändert. Der Edge legt seine Kopien unter dieser Markierung ab. Eine Veröffentlichung wird deshalb zu einem brandneuen Satz von Cache-Schlüsseln, sobald die 30-Sekunden-Nachschlagung des Edge abläuft. Alte Kopien werden schlicht nicht mehr gefunden, daher kann der Edge Kopien einen Tag behalten, ohne je eine auszuliefern, die von der nächsten Veröffentlichung ersetzt wurde.

Browser bekommen zwei verschiedene Regeln:

• Gehashte Build-Ausgabe, Dateien wie assets/index-CzLcxDO8.js, deren Name sich ändert, sobald sich der Inhalt ändert, wird ein Jahr lang zwischengespeichert und als unveränderlich markiert. Unter diesem Namen kann sie nie veraltet sein.
• Alles andere, also Seiten und Dateien mit festem Namen wie ein Logo, wird mit no-cache markiert, was „vor der Verwendung prüfen“ bedeutet. Hat sich nichts geändert, lautet die Antwort ein winziges 304 Not Modified ohne Inhalt, denn wir beachten jetzt die Prüfung If-None-Match des Browsers.

Die beiden zu unterscheiden braucht Sorgfalt: Eine aus public/assets/ kopierte Datei behält ihren eigenen Namen, und würde man assets/logo.png ein Jahr lang zwischenspeichern, hinge das alte Logo ein Jahr fest. Eine Datei gilt deshalb nur dann als gehasht, wenn sie in einem Build-Ausgabeordner liegt und ihr Name einen Abschnitt hat, der wie ein Hash aussieht, nicht wie ein gewöhnliches Wort.

Lokal war die neue Seite und das neue Logo 6 Sekunden nach dem Live-Gehen der Veröffentlichung sichtbar. Vorher waren es 60 Sekunden für die Seite und ein Tag für das Logo.

Zwei kleinere Korrekturen nebenbei

• Leere Seiten bei HEAD-Anfragen. Eine HEAD-Anfrage fragt die Header einer Seite ohne deren Inhalt ab. Wir haben diese leeren Antworten zwischengespeichert, daher bekam der nächste Besucher dieser Seite eine leere Seite. HEAD-Antworten werden nicht mehr zwischengespeichert.
• Eine echte Seite für „hier ist nichts“. Eine Adresse ohne App bekam früher einen Klartext „Diese veröffentlichte App ist offline oder der Link wurde nicht gefunden“ mit dem Fehlercode 502. Jetzt gibt es eine richtige Seite, „Hier gibt es keine App“, mit dem Status 404 und einem Weg zurück zu Mythex für den Eigentümer. Unbekannte eigene Domains erhalten dieselbe Seite.

Was wir daraus mitnehmen

• Die Reihenfolge gehört zur Korrektheit. Dieselben Dateien, in einer anderen Reihenfolge hochgeladen, sind der Unterschied zwischen einer kaputten und einer funktionierenden Website.
• Spät löschen, und nur, was man kennt. Eine Bereinigung anhand einer Liste, die vor dem Upload erstellt wurde, ist sicher. Einen Ordner zu leeren und zu hoffen, dass der Upload fertig wird, ist es nicht.
• Nach Version zwischenspeichern, nicht nach Zeit. Ablaufzeiten sind eine Vermutung darüber, wann sich Inhalte ändern. Ein Schlüssel, der sich mit dem Build ändert, ist eine Tatsache.

Verwandt: Ihre veröffentlichte App bleibt jetzt online, während Sie sie neu veröffentlichen. Mehr zum Veröffentlichen finden Sie in der Dokumentation.