Статичні сайти тепер не зупиняються під час повторної публікації

Повторна публікація статичного сайту в Mythex раніше спершу видаляла живі файли, а потім завантажувала нову збірку. Протягом завантаження деякі відвідувачі отримували сторінку 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, назва яких змінюється щойно змінюється вміст, кешуються на рік і позначаються як незмінні. Під цією назвою вони ніколи не можуть застаріти.
• Усе інше, тобто сторінки та файли з постійною назвою, як-от логотип, позначаються no-cache, що означає «перевірити перед використанням». Якщо нічого не змінилося, відповідь це крихітна 304 Not Modified без тіла, тепер, коли ми дотримуємося перевірки браузера If-None-Match.

Розрізнити їх треба обережно: файл, скопійований з public/assets/, зберігає власну назву, а кешування assets/logo.png на рік закріпило б старий логотип на рік. Тому файл вважається хешованим, лише якщо він лежить у теці вихідних файлів збірки і його назва містить сегмент, схожий на хеш, а не звичайне слово.

Локально нова сторінка та логотип були видимі через 6 секунд після того, як публікація стала активною. Раніше це було 60 секунд для сторінки і доба для логотипу.

Два менші виправлення

• Порожні сторінки з запитів HEAD. Запит HEAD запитує заголовки сторінки без її тіла. Ми кешували ці порожні відповіді, тож наступний відвідувач цієї сторінки отримував порожню сторінку. Відповіді HEAD більше не кешуються.
• Справжня сторінка для «тут нічого немає». Адреса без застосунку раніше отримувала звичайний текст «Цей опублікований застосунок офлайн або посилання не знайдено» з кодом помилки 502. Тепер вона отримує нормальну сторінку «Тут немає застосунку» зі статусом 404 і посиланням назад на Mythex для власника. Невідомі власні домени отримують ту саму сторінку.

Що ми з цього взяли

• Порядок є частиною правильності. Ті самі файли, завантажені в іншому порядку, це різниця між зламаним і робочим сайтом.
• Видаляйте пізно і лише те, що знаєте. Прибирання зі списком, складеним до завантаження, безпечне; очищення теки та сподівання, що завантаження завершиться, ні.
• Кешуйте за версією, а не за часом. Час експірації це здогад про те, коли змінюється вміст. Ключ, що змінюється разом зі збіркою, це факт.

Пов'язане: ваш опублікований застосунок тепер залишається працездатним під час повторної публікації. Більше про публікацію в документації.