Статичните сайтове вече остават онлайн, докато се публикуват наново

Преиздаването на статичен сайт в Mythex преди изтриваше live файловете и след това качваше новия билд, така че за времето на качването някои посетители получаваха страница 404 или страница, чиито скриптове липсваха. Неуспешното качване можеше да остави сайта празен или наполовина нов. Сега новият билд се записва върху стария, страниците последни, а остатъците се премахват след няколко минути. Втора поправка прави преиздаването видимо за секунди вместо за минута — или, за файлове като лого, до един ден.

Как се сервира статичен сайт

Статичният сайт е такъв, който е само файлове: HTML страници, JavaScript, CSS, изображения. Когато го публикувате в Mythex, ние го строим, качваме резултата в обектно хранилище под папка за вашия сайт и го сервираме през edge мрежа — сървъри близо до посетителите, които вземат файлове от хранилището и пазят копия за известно време. (Ако това ви е ново, нашето ръководство за какво е CDN обяснява идеята.)

Нещо не беше наред в две неща: редът, в който преиздаването променяше файловете, и колко дълго се пазеха старите копия.

Проблем 1: качването първо изпразваше сайта

Преиздаването изтриваше всичко в папката на сайта, след което качваше новия билд. Докато качването траеше — 12 секунди за сайт от 250 файла в нашия локален тест — посетител, чиято заявка още не беше в кеша на edge, получаваше 404, или HTML страница, чиито скриптове връщаха 404.

Неуспешното качване беше по-лошо. Папката вече беше празна, а на единия от двата пътя на качване новият index.html можеше да се качи преди файла, който се провали. Публикуване, докладвано като неуспешно, можеше да остави наполовина нов сайт онлайн.

Поправката: записване отгоре, страниците последни, почистване по-късно

1. Не трийте първо. Новият билд се качва върху стария.
2. Активите преди страниците. Страницата назовава скриптовете и стиловете, от които се нуждае, затова страниците се качват последни. Докато новите страници не пристигнат, посетителите получават старата страница, която назовава старите активи, а те още са там. Когато пристигнат, новите активи, които те назовават, вече са на място.
3. Остатъците — по-късно. Преди качването записваме какво се състои сайтът. Три минути след успешно качване всичко от този списък, което новият билд не е презаписал, се изтрива. Три минути е по-дълго от 60-те секунди, за които страница може да е кеширана на edge и в браузъра, така че посетител, който още държи старата страница, може да намери активите, които тя назовава.
4. При съмнение — не трий нищо. Ако изброяването преди качването се провали, нищо не се изчиства. Оставените файлове са безвредни, а следващото публикуване ги изчиства. Изтриването без да знаете какво е било там е начинът сайтът да остане празен.

Неуспешно качване сега оставя предишния сайт точно такъв, какъвто е бил.

Тествахме това от край до край локално, като използвахме реалния скрипт за качване, реалния маршрут за качване и сервирането от хранилището, с посетители, които пристигат със студен кеш на edge. При стария код 55 от 91 посещения бяха счупени по време на преиздаване, а 61 от 92 — при неуспешно. При новия код 0 бяха счупени в около 3500 посещения, обхващащи двата пътя на качване, неуспешно качване и публикуването след него — и точно остатъчните файлове бяха изчистени.

Проблем 2: преиздаването отнемаше твърде дълго, за да се види

Дори когато качването минаваше добре, промените се появяваха бавно. Edge пазеше копието си от страница 60 секунди, а от всеки друг файл — един ден, и казваше същото на браузърите. Файловете с фиксирано име — logo.png, шрифт, всичко от папка public/ — можеха да показват старата версия до един ден след преиздаване.

Поправката: копията на файловете са под билда

Когато edge попита нашия API къде живее даден сайт, отговорът вече включва маркер на билда, който се сменя при всяко публикуване. Edge подрежда копията си под този маркер. Публикуването следователно става напълно нов набор от кеш ключове, веднага щом 30-секундното търсене на edge изтече. Старите копия просто никога повече не се намират, така че edge може да пази копията до един ден, без никога да сервира такова след публикуването, което го е заменило.

Браузърите получават две различни правила:

• Хешираният изходен билд — файлове като assets/index-CzLcxDO8.js, чието име се сменя, когато съдържанието се промени — се кешира за година и се маркира като immutable. Под това име никога не може да е остарял.
• Всичко останало — страници и файлове с фиксирано име, като лого — се маркира с no-cache, което означава „провери преди ползване“. Ако нищо не се е променило, отговорът е малко 304 Not Modified без тяло, откакто вече спазваме проверката If-None-Match на браузъра.

Различаването на двете изисква внимание: файл, копиран от public/assets/, запазва собственото си име, а кеширането на assets/logo.png за година би закрепило старото лого за година. Затова файл се счита за хеширан само ако е в папка на изходния билд и името му има сегмент, който прилича на хеш, а не на обикновена дума.

Локално новата страница и логото бяха видими 6 секунди след като публикуването стана live. Преди това бяха 60 секунди за страницата и един ден за логото.

Две по-малки поправки по пътя

• Празни страници от HEAD заявки. Заявка HEAD пита за заглавките на страница без тялото ѝ. Кеширахме тези празни отговори, така че следващият посетител на страницата получаваше празна страница. Отговорите на HEAD вече не се кешират.
• Истинска страница за „тук няма нищо“. Адрес без приложение преди получаваше обикновен текст „Това публикувано приложение е офлайн или връзката не е намерена“ с код 502. Сега получава нормална страница — „Тук няма приложение“ — със статус 404 и връзка обратно към Mythex за собственика. Непознатите персонални домейни получават същата страница.

Какво взехме от това

• Редът е част от коректността. Същите файлове, качени в различен ред, са разликата между счупен и работещ сайт.
• Изтривайте късно и само това, което знаете. Изчистването с изброяване, направено преди качването, е безопасно; изпразването на папка с надежда качването да завърши — не е.
• Кеширайте по версия, не по време. Времената на изтичане са предположение за това кога се променя съдържанието. Ключ, който се сменя с билда, е факт.

Свързано: вашето публикувано приложение остава онлайн, докато го преиздавате. Повече за публикуването — в документацията.