Site-urile statice rămân online în timpul republicării

Republicarea unui site static pe Mythex ștergea înainte fișierele live, apoi încărca noul build, așa că pe durata încărcării unii vizitatori primeau o pagină 404 sau o pagină ale cărei scripturi lipseau. O încărcare eșuată putea lăsa site-ul gol sau pe jumătate nou. Acum noul build este scris peste cel vechi, paginile ultimele, iar resturile sunt șterse câteva minute mai târziu. O a doua corecție face ca o republicare să apară în câteva secunde în loc de un minut — sau, pentru fișiere precum un logo, în cel mult o zi.

Cum este servit un site static

Un site static este format doar din fișiere: pagini HTML, JavaScript, CSS, imagini. Când îl publici pe Mythex, îl construim, încărcăm rezultatul într-un stocaj de obiecte, într-un dosar pentru site-ul tău, și îl servim printr-o rețea edge — servere apropiate de vizitatori, care preiau fișierele din stocaj și le păstrează o vreme. (Dacă ești nou în domeniu, ghidul nostru despre ce este un CDN explică ideea.)

Două lucruri nu mergeau: ordinea în care o republicare schimba fișierele și cât timp erau păstrate copiile vechi.

Problema 1: încărcarea golea mai întâi site-ul

O republicare ștergea tot ce era în dosarul site-ului, apoi încărca noul build. Cât timp dura încărcarea — 12 secunde pentru un site de 250 de fișiere, în testul nostru local — un vizitator a cărui cerere nu era deja în cache la edge primea o eroare 404 sau o pagină HTML ale cărei scripturi returnau 404.

O încărcare eșuată era și mai rea. Dosarul era deja gol, iar pe una dintre cele două căi de încărcare, noul index.html putea ajunge înaintea fișierului care a eșuat. O publicare raportată ca eșuată putea lăsa live un site pe jumătate nou.

Soluția: scriere peste, pagini la final, curățare ulterioară

Nu ștergem mai întâi. Noul build se încarcă peste cel vechi.
Resursele înaintea paginilor. O pagină numește scripturile și stilurile de care are nevoie, așa că paginile se încarcă ultimele. Până ajung paginile noi, vizitatorii primesc pagina veche, care numește resursele vechi, iar acestea încă există. Când ajung paginile noi, resursele noi pe care le numesc sunt deja la locul lor.
Resturile se șterg mai târziu. Înainte de încărcare, listăm din ce este format site-ul. La trei minute după o încărcare reușită, orice se află pe listă și nu a fost rescris de noul build este șters. Trei minute sunt mai mult decât cele 60 de secunde în care o pagină poate fi păstrată în cache la edge și în browser, așa că un vizitator care mai ține pagina veche poate găsi resursele pe care aceasta le numește.
Dacă ai îndoieli, nu șterge nimic. Dacă listarea de dinaintea încărcării eșuează, nu se șterge nimic. Fișierele rămase nu fac rău, iar următoarea publicare le curăță. A șterge fără să știi ce era acolo este modul în care un site ajunge gol.

O încărcare eșuată lasă acum site-ul anterior exact cum era.

Am testat acest lucru cap-coadă local, folosind scriptul real de încărcare, ruta reală de încărcare și servirea reală din stocaj, cu vizitatori care sosesc cu un cache edge rece. Cu vechiul cod, 55 din 91 de vizite au fost afectate în timpul unei republicări, iar 61 din 92 în timpul uneia eșuate. Cu noul cod, 0 au fost afectate din aproximativ 3.500 de vizite, care acoperă ambele căi de încărcare, o încărcare eșuată și publicarea de după ea — și s-au șters exact fișierele rămase.

Problema 2: o republicare dura prea mult să se vadă

Chiar și când încărcarea mergea bine, schimbările apăreau încet. Edge-ul păstra copia unei pagini 60 de secunde și a oricărui alt fișier o zi, și le spunea același lucru browserelor. Fișierele cu nume fix — logo.png, un font, orice dintr-un dosar public/ — puteau arăta versiunea veche până la o zi după o republicare.

Soluția: copii ale fișierelor sub build

Când edge-ul întreabă API-ul nostru unde se află un site, răspunsul include acum un marcaj de build care se schimbă de fiecare dată când ajunge o publicare. Edge-ul salvează copiile sub acest marcaj. O publicare devine astfel un set complet nou de chei de cache imediat ce expiră căutarea de 30 de secunde a edge-ului. Copiile vechi nu mai sunt găsite niciodată, așa că edge-ul poate păstra copii o zi fără să servească vreodată una după publicarea care a înlocuit-o.

Browserele primesc două reguli diferite:

Rezultatul build-ului cu hash — fișiere precum assets/index-CzLcxDO8.js, al căror nume se schimbă când se schimbă conținutul — este salvat în cache un an și marcat ca immutable. Sub acest nume nu poate deveni niciodată vechi.
Tot restul — pagini și fișiere cu nume fix, precum un logo — este marcat no-cache, adică „verifică înainte de folosire”. Dacă nu s-a schimbat nimic, răspunsul este un mic 304 Not Modified fără corp, acum că respectăm verificarea If-None-Match a browserului.

Deosebirea dintre cele două cazuri cere atenție: un fișier copiat din public/assets/ își păstrează propriul nume, iar salvarea în cache a assets/logo.png un an ar fixa logoul vechi pentru un an. Așadar un fișier este considerat cu hash doar dacă se află într-un dosar de rezultat al build-ului și numele lui are un segment care arată ca un hash, nu ca un cuvânt obișnuit.

Local, pagina și logoul noi au fost vizibile la 6 secunde după ce publicarea a devenit live. Înainte, erau necesare 60 de secunde pentru pagină și o zi pentru logo.

Două corecții mai mici pe parcurs

Pagini goale din cererile HEAD. O cerere HEAD cere anteturile unei pagini, fără corpul ei. Salvam în cache aceste răspunsuri goale, așa că următorul vizitator al paginii primea o pagină goală. Răspunsurile HEAD nu mai sunt salvate în cache.
O pagină reală pentru „nu există nimic aici”. O adresă fără aplicație primea un text simplu, „Această aplicație publicată este offline sau linkul nu a fost găsit”, cu codul de eroare 502. Acum primește o pagină adecvată, „Aici nu există nicio aplicație”, cu statusul 404 și un drum înapoi spre Mythex pentru proprietar. Domeniile personalizate necunoscute primesc aceeași pagină.

Ce am învățat din asta

Ordinea face parte din corectitudine. Aceleași fișiere, încărcate într-o altă ordine, fac diferența între un site stricat și unul care funcționează.
Șterge târziu, și doar ce știi. Curățarea cu o listare luată înainte de încărcare este sigură; golirea unui dosar și speranța că încărcarea se termină nu este.
Memorează în cache după versiune, nu după timp. Duratele de expirare sunt o presupunere despre când se schimbă conținutul. O cheie care se schimbă odată cu build-ul este un fapt.

Înrudit: aplicația ta publicată rămâne online cât timp o republici. Mai multe despre publicare găsești în documentație.