Offline-first в веб-приложениях: service worker, кэш и fallback

Ты открыл «Змейку» в браузере телефона, поехал в метро, интернет пропал — и игра зависла на половине экрана. Или ещё хуже: страница вовсе не загрузилась, потому что в тоннеле нет связи. Это типичная ситуация для обычного сайта, который при каждом открытии тянет файлы с сервера. Offline-first — это подход, при котором приложение сначала пытается работать с тем, что уже лежит на устройстве, а к интернету обращается только когда нужно. Ниже — как это работает в вебе, кто такой service worker, какие у него есть стратегии кеширования и какие ошибки чаще всего мешают обновлениям.

Что такое offline-first в вебе

Обычный сайт работает по простой схеме: браузер просит файл у сервера, сервер отдаёт файл, страница рисуется. Если связи нет — запрос падает, и пользователь видит ошибку. Offline-first переворачивает логику: приложение заранее сохраняет нужные файлы на устройстве и при открытии берёт их оттуда. Интернет используется не для базовой работы, а для обновления данных или синхронизации.

Проще говоря, offline-first — это когда сайт ведёт себя почти как приложение из магазина. Он запускается без сети, помнит состояние и продолжает работать даже в самолёте или подвале. Для игры вроде «Змейки» это означает, что рекорд остаётся на устройстве, а сама игра стартует мгновенно, потому что все файлы уже загружены.

Service worker: посредник между браузером и сетью

Service worker — это специальный JavaScript-файл, который браузер запускает в фоне, отдельно от самой страницы. Он не рисует интерфейс и не имеет прямого доступа к DOM, но умеет перехватывать сетевые запросы вашего приложения и решать, что с ними делать.

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

Service worker проходит через три основных состояния:

1. Регистрация. Страница сообщает браузеру: «У меня есть такой фоновый скрипт, запусти его».
2. Установка. Service worker загружает и сохраняет в кэш нужные файлы.
3. Активация. Он начинает перехватывать запросы и управлять страницами.

После активации каждый запрос к серверу проходит мимо service worker. Именно там происходит вся магия офлайна.

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

Не все файлы приложения одинаковы. HTML-страницу, иконки, стили и код игры можно кэшировать надолго, потому что они меняются редко. А вот таблицу рекордов или состояние магазина в «Змейке» лучше сначала запрашивать из сети. Поэтому в service worker используют разные стратегии.

Сначала кэш, потом сеть

Браузер сначала ищет файл в кэше. Если нашёл — отдаёт сразу. Если нет — идёт в сеть, скачивает и кладёт в кэш на будущее. Это идеально для статики: скрипты, стили, изображения, звуки. В «Змейке» так стоит кэшировать сам файл игры, спрайты и аудио.

Сначала сеть, потом кэш

Браузер пытается загрузить данные из интернета. Если сеть есть — показывает свежее и обновляет кэш. Если сети нет — отдаёт сохранённое. Эта стратегия подходит для динамических данных: рейтинг рекордов, новости, цены.

Устаревшее, пока обновляется

Сначала отдаётся версия из кэша, чтобы пользователь не ждал. Параллельно в фоне идёт запрос в сеть, и если пришла более новая версия, кэш обновляется для следующего раза. Это компромисс между скоростью и актуальностью. Хорошо работает для интерфейса, который можно немного отставать от сервера.

Только кэш или только сеть

«Только кэш» используют для файлов, которые вообще не должны ходить в интернет: например, для заранее встроенных уровней. «Только сеть» — для чувствительных операций, где кэш недопустим, например отправки результата игры на сервер.

Как это работает на практике

Когда пользователь первый раз открывает игру, service worker устанавливается и копирует в кэш список важных файлов. В следующий раз страница открывается практически мгновенно, потому что всё берётся с устройства. Если интернет пропал прямо во время игры, ничего страшного: сама игра продолжает работать, а сохранение рекорда можно отложить до восстановления связи.

Для данных, которые должны жить между сессиями, вроде локального рекорда, часто используют localStorage или IndexedDB. localStorage — это простое хранилище в браузере, с которым ты уже работал в «Змейке», когда сохранял лучший счёт. IndexedDB — более мощная база данных в браузере, подходящая для сложных структур: истории партий, настроек, временных очередей действий.

Важный момент: service worker кэширует файлы, а localStorage и IndexedDB хранят данные. Это два разных слоя. Файлы — это то, без чего приложение не запустится. Данные — это то, что приложение создаёт в процессе работы.

Fallback: что показать, если ничего нет

Даже при хорошем кэше бывают ситуации, когда нужного файла нет. Тогда service worker может отдать fallback — запасной вариант. Это может быть статичная страница «Нет соединения», упрощённая версия интерфейса или сообщение с предложением попробовать позже.

Для «Змейки» fallback может выглядеть так: если не загрузился один из скинов, показываем стандартную зелёную змейку. Если не удалось получить таблицу рекордов из сети, показываем локальный топ. Если совсем ничего не загружается — страница с текстом «Играть можно и без интернета. Ваш рекорд сохранён».

Хороший fallback не ругает пользователя, а объясняет, что происходит, и сохраняет возможность работы.

Подводные камни обновлений

Service worker мощный, но с ним легко допустить ошибки, из-за которых пользователи видят старую версию приложения неделями.

Старый service worker не уходит, пока вкладка открыта

Браузер не выкидывает старого service worker, пока открыты страницы, которые им управляются. Это значит, что после публикации новой версии пользователь может продолжать видеть старую, пока не закроет все вкладки сайта. Для игры это не страшно, но для приложения с важными исправлениями — проблема.

Решение — использовать skipWaiting, который форсирует активацию нового service worker. Но тогда нужно быть уверенным, что новая версия совместима с тем, что уже загружено.

Кэш не обновляется

Если service worker кэширует файлы по именам без версий, например game.js, то при обновлении кода браузер может продолжать отдавать старый файл. Стандартное решение — добавлять хеш к именам файлов или версионировать имя кэша: snake-cache-v1, snake-cache-v2. При активации нового service worker старые кэши удаляются.

Слишком агрессивное кеширование

Если закэшировать всё подряд, включая запросы к API, пользователь будет видеть устаревшие данные даже при наличии интернета. Для каждого типа запроса нужна своя стратегия.

Неправильная обработка ошибок

Если service worker падает, он может сломать загрузку всего сайта. Важно предусматривать fallback и не пытаться кэшировать слишком много на этапе установки.

Как проверить offline-режим

Проверить, работает ли приложение без интернета, проще всего в инструментах разработчика Chrome:

1. Открой свою игру в браузере.
2. Нажми F12, перейди во вкладку Network.
3. В выпадающем списке сети выбери Offline.
4. Обнови страницу и убедись, что игра загружается и работает.

Также полезна вкладка Application → Service Workers. Там видно, зарегистрирован ли service worker, в каком он состоянии и какие файлы попали в кэш. Если что-то пошло не так, можно нажать Unregister и обновить страницу — браузер установит service worker заново.

Для более глубокой проверки можно использовать Lighthouse: он покажет, насколько приложение соответствует критериям PWA, в том числе работу офлайн.

Заключение + чек-лист

Offline-first делает веб-приложение устойчивым к плохому интернету и похожим на нативные программы. Service worker берёт на себя роль диспетчера запросов, кэш хранит файлы, а fallback защищает пользователя от ошибок. В «Змейке» это позволит играть в метро, самолёте или деревне без лишних нервов.

Главное — не кэшировать всё подряд и следить за версионированием. Иначе вместо быстрого офлайна получишь вечно устаревшее приложение, которое невозможно обновить.

Чек-лист «Приложение готово к офлайну»

• Service worker зарегистрирован и активен.
• Статические файлы кэшируются при первой загрузке.
• Для разных типов запросов выбраны правильные стратегии.
• Данные пользователя сохраняются в localStorage или IndexedDB.
• Есть fallback на случай отсутствия нужного файла или сети.
• Имя кэша версионировано, старые кэши удаляются при обновлении.
• Приложение проверено в режиме Offline в Chrome DevTools.
• Обновления корректно доходят до пользователя после закрытия вкладок.

Источники

1. MDN Web Docs — «Service Worker API»: developer.mozilla.org
2. Chrome for Developers — «Strategies for service worker caching»: developer.chrome.com
3. web.dev — «Service workers and the Cache Storage API": web.dev/articles/service-workers-cache-storage