PWA и service worker

01Идея: сайт, который ведёт себя как приложение

PWA — это не новая технология, а набор возможностей браузера, используемых вместе. По HTTPS сайт с валидным manifest можно установить на домашний экран или рабочий стол, запускать в отдельном окне без интерфейса браузера, и он появляется в переключателе приложений. Service worker добавляет поддержку офлайна, более быструю загрузку за счёт кэширования и, при желании, push-уведомления и фоновые задачи. Представьте service worker как умного швейцара: каждый запрос страницы проходит через него, и он решает, взять ли ответ из сети, из своего кэша или и то и другое. «Progressive» означает, что он деградирует аккуратно: браузеры без поддержки какой-то возможности всё равно получают обычный сайт.

• Требуется HTTPS (для разработки разрешён localhost).
• Manifest: идентичность и внешний вид после установки.
• Service worker: сетевой прокси, кэш и фоновая работа.

02Web app manifest

Manifest — это JSON-файл, на который ссылается страница. Ключевые поля: name и short_name (показывается под иконкой), start_url (где открывается приложение), scope (какие URL относятся к приложению), display (standalone для окна приложения), theme_color и background_color (строка заголовка и splash screen) и icons. Предоставьте как минимум PNG-иконки 192x192 и 512x512. У maskable-иконок, помеченных purpose «maskable», важное содержимое находится внутри центральной безопасной зоны (круг диаметром 80% ширины), так что Android может обрезать их до круга, squircle или другой формы, не отрезая логотип. Добавьте id, чтобы браузер мог идентифицировать приложение, даже если start_url изменится, а также screenshots и description для более богатого диалога установки.

1{
2  "id": "/",
3  "name": "Example Portfolio",
4  "short_name": "Portfolio",
5  "start_url": "/?source=pwa",
6  "scope": "/",
7  "display": "standalone",
8  "theme_color": "#0f172a",
9  "background_color": "#0f172a",
10  "icons": [
11    { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png" },
12    { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png" },
13    { "src": "/icons/maskable-512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
14  ]
15}

03Жизненный цикл service worker

Service worker — это JavaScript-файл, который работает в собственном потоке, без доступа к DOM, и может жить дольше страницы. Страница регистрирует его; браузер скачивает его и вызывает install, где обычно предкэшируют офлайн-страницу и основные ресурсы. Затем он ждёт, пока ни одна открытая вкладка не будет использовать старый worker, и вызывает activate, где удаляют старые кэши. С этого момента он получает события fetch для каждого запроса в своём scope. Когда вы деплоите изменённый файл worker-а, браузер замечает разницу в байтах, устанавливает новую версию и держит её в ожидании, пока не закроются старые вкладки. skipWaiting() и clients.claim() заставляют новую версию взять управление сразу — это удобно, но может смешать старые страницы с новыми закэшированными ресурсами, поэтому используйте их осознанно.

1// In the page (only in production builds)
2if ("serviceWorker" in navigator) {
3  window.addEventListener("load", () => {
4    navigator.serviceWorker.register("/sw.js", { scope: "/" })
5      .catch((err) => console.error("SW registration failed", err));
6  });
7}

04Стратегии кэширования

Внутри обработчика fetch вы выбираете стратегию для каждого вида запросов. Cache-first отдаёт из кэша и идёт в сеть только при промахе; идеально для статических ресурсов с отпечатком в имени (app.3f9a.js) и шрифтов, которые никогда не меняются. Network-first пробует сеть и при офлайне откатывается к кэшу; идеально для HTML-страниц и данных API, которые должны быть свежими. Stale-while-revalidate мгновенно отвечает из кэша и обновляет кэш в фоне; хорошо для аватаров и некритичных данных. Network-only — для того, что никогда нельзя кэшировать, например аутентифицированных мутаций и платежей. Распространённый безопасный вариант по умолчанию для контентных сайтов — network-first для навигаций с офлайн-страницей в качестве fallback и cache-first для хэшированных статических файлов.

• Cache-first: хэшированные JS/CSS, шрифты, иконки.
• Network-first: HTML-навигации, свежие чтения из API.
• Stale-while-revalidate: изображения, некритичный JSON.
• Network-only: POST-запросы, auth, оформление заказа.

05Network-first service worker с офлайн-страницей

Этот написанный вручную worker при install предкэширует офлайн-страницу, при activate удаляет старые кэши и обрабатывает навигации по стратегии network-first: пробует сеть, сохраняет копию успешных страниц и при сбое сети откатывается к закэшированной странице или офлайн-странице. Не-GET запросы и другие origin он не трогает. Повышайте версию кэша, когда меняются офлайн-страница или основные файлы.

1const CACHE = "site-v3";
2const OFFLINE_URL = "/offline";
3 
4self.addEventListener("install", (e) => {
5  e.waitUntil(caches.open(CACHE).then((c) => c.addAll([OFFLINE_URL, "/icons/icon-192.png"])));
6});
7self.addEventListener("activate", (e) => {
8  e.waitUntil(caches.keys().then((keys) =>
9    Promise.all(keys.filter((k) => k !== CACHE).map((k) => caches.delete(k)))));
10});
11self.addEventListener("fetch", (e) => {
12  const req = e.request;
13  if (req.method !== "GET" || new URL(req.url).origin !== location.origin) return;
14  if (req.mode !== "navigate") return;
15  e.respondWith(fetch(req).then((res) => {
16    const copy = res.clone();
17    if (res.ok) caches.open(CACHE).then((c) => c.put(req, copy));
18    return res;
19  }).catch(async () => (await caches.match(req)) || caches.match(OFFLINE_URL)));
20});

06PWA в Next.js

Next.js App Router поддерживает manifest «из коробки»: файл app/manifest.ts, возвращающий объект MetadataRoute.Manifest, отдаётся как /manifest.webmanifest и подключается автоматически. Цвет темы задаётся в экспорте viewport. Service worker — статический файл public/sw.js, который отдаётся из корня сайта, чтобы его scope покрывал всё приложение, и регистрируется из небольшого клиентского компонента. Добавьте офлайн-роут (app/offline/page.tsx), который не зависит от данных, чтобы его можно было предкэшировать. Отдавайте sw.js с Cache-Control: no-cache, чтобы браузеры быстро проверяли обновления; документация Next.js показывает это через headers() в next.config. Для больших приложений Serwist (поддерживаемый преемник next-pwa, построенный на идеях Workbox) генерирует precache-манифесты из сборки.

1// app/manifest.ts
2import type { MetadataRoute } from "next";
3 
4export default function manifest(): MetadataRoute.Manifest {
5  return {
6    name: "Example Portfolio",
7    short_name: "Portfolio",
8    start_url: "/",
9    display: "standalone",
10    background_color: "#0f172a",
11    theme_color: "#0f172a",
12    icons: [
13      { src: "/icons/icon-192.png", sizes: "192x192", type: "image/png" },
14      { src: "/icons/icon-512.png", sizes: "512x512", type: "image/png" },
15      { src: "/icons/maskable-512.png", sizes: "512x512", type: "image/png", purpose: "maskable" },
16    ],
17  };
18}

07Установка, push и различия платформ

Браузеры на Chromium (Chrome, Edge, Samsung Internet) показывают предложение установки или пункт меню, когда сайт работает по HTTPS и у него есть manifest с name, icons, start_url и подходящим режимом display; можно перехватить событие beforeinstallprompt, чтобы показать собственную кнопку установки. Safari на iOS и iPadOS устанавливает через «Поделиться», затем «На экран „Домой“», и начиная с iOS 16.4 установленные веб-приложения могут получать Web Push. Safari на macOS поддерживает Add to Dock. Для push нужны service worker, разрешение пользователя, запрошенное после его действия, VAPID-ключи и сервер, отправляющий сообщения. Background Sync и Periodic Background Sync есть только в Chromium, так что считайте их улучшениями. Firefox на десктопе не устанавливает PWA нативно. Тестируйте на каждой целевой платформе.

08Scope, navigation preload и производительность

Service worker управляет страницами в пределах своего scope, который по умолчанию — директория, откуда он отдаётся; поэтому sw.js живёт в корне. Страница попадает под управление только после активации worker-а, так что самый первый визит никогда не перехватывается, если не вызвать clients.claim(). Одна скрытая цена network-first — запуск: когда worker простаивает, браузер должен загрузить его, прежде чем запрос уйдёт в сеть, что добавляет десятки миллисекунд. Navigation preload это решает: браузер начинает навигационный запрос параллельно с запуском worker-а, а обработчик fetch использует event.preloadResponse. Держите обработчик fetch быстрым и избегайте пустого слушателя fetch, который добавляет накладные расходы без пользы.

1self.addEventListener("activate", (e) => {
2  e.waitUntil(self.registration.navigationPreload?.enable());
3});
4 
5self.addEventListener("fetch", (e) => {
6  if (e.request.mode !== "navigate") return;
7  e.respondWith((async () => {
8    try {
9      return (await e.preloadResponse) || (await fetch(e.request));
10    } catch {
11      return (await caches.match(e.request)) || caches.match("/offline");
12    }
13  })());
14});

09Безопасные сценарии обновления

Самый безопасный паттерн обновления такой: новый worker устанавливается и ждёт; страница слушает ожидающий worker и показывает баннер «доступна новая версия»; когда пользователь соглашается, страница отправляет сообщение, worker вызывает skipWaiting(), а страница перезагружается по controllerchange. Так работающую страницу не начнёт внезапно обслуживать worker, в кэше которого лежат другие версии ресурсов. Для контентного сайта с network-first HTML и хэшированными ресурсами автоматический skipWaiting обычно нормален, потому что старые ресурсы не удаляются посреди сессии, если какое-то время хранить предыдущий кэш. Всегда предусматривайте kill switch: деплой worker-а, который снимает свою регистрацию и очищает кэши, — это аварийное восстановление, если выкатился плохой worker.

1// Emergency "kill switch" sw.js
2self.addEventListener("install", () => self.skipWaiting());
3self.addEventListener("activate", (e) => {
4  e.waitUntil((async () => {
5    for (const key of await caches.keys()) await caches.delete(key);
6    await self.registration.unregister();
7    for (const c of await self.clients.matchAll()) c.navigate(c.url);
8  })());
9});

10Лимиты хранилища, вытеснение и офлайн-данные

Cache API, IndexedDB и другие хранилища origin делят квоту, которой управляет браузер; Chromium позволяет origin занять значительную долю свободного диска, Safari строже и может вытеснять хранилище сайтов, которыми какое-то время не пользовались. По умолчанию хранилище работает в режиме «best effort» и может быть очищено при нехватке места; navigator.storage.persist() запрашивает постоянное хранилище, которое браузеры предоставляют с учётом вовлечённости или установки. Проверяйте использование через navigator.storage.estimate(). Для офлайн-данных помимо закэшированных ответов, например черновиков или отложенных отправок форм, используйте IndexedDB (через небольшую обёртку вроде idb) и повторяйте отложенные запросы при восстановлении сети — через Background Sync в Chromium и с fallback на событие online в остальных браузерах. Проектируйте с учётом конфликтов: к моменту попадания на сервер отложенные записи могут устареть.

11Подводные камни безопасности и приватности

Service worker — мощный инструмент, поэтому браузеры требуют HTTPS и скрипты того же origin. Основные риски — те, что мы создаём себе сами. Кэширование ответов с ключом только по URL может сохранить персонализированную страницу одного пользователя и показать её следующему на общем устройстве; никогда не кэшируйте аутентифицированный HTML или ответы API в общем кэше и очищайте кэши при выходе. Кросс-доменные opaque-ответы (no-cors) сильно расходуют квоту и не позволяют проверить их на ошибки, поэтому избегайте их кэширования. XSS-баг, через который можно зарегистрировать worker, закрепит код атакующего, поэтому помогают строгая Content Security Policy и директива worker-src. Наконец, сломанный worker может отрезать пользователей от обновлений — вот почему важны короткое HTTP-кэширование для sw.js и kill switch.