Джереми Кейт написал у себя в блоге статью "Timing out" про то, как он использует Service Workers, чтобы улучшить пользовательский опыт при "Lie-Fi" (при неустойчивом соединении с сетью).

Стратегия работы с кэшом Service Worker'а выглядит следующим образом. Когда пользователь пытается загрузить страницу, сначала происходит попытка загрузки этой страницы из сети. Если это не удаётся, запрошенная страница берётся из кэша. Если в кэше страницы нет, показывается специальная страница для offline-режима. При этом, если запрашиваемая страница загружается слишком долго (Lie-Fi), пользователю отдаётся закэшированная страница.

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

Если вам потребуется делать что-то подобное, советую заглянуть в статью, там очень подробно разбирается код, который реализует описанную стратегию.

#offlinefirst #serviceworker #cache

https://adactio.com/journal/15122

Уже несколько недель лежала в закладках статья про то, как инженеры Google внедрили на страницу поиска сервис воркеры — "Bringing service workers to Google Search".

Сервис воркеры используются для того, чтобы кешировать результаты ответа на запрос в течение небольшого количества времени. Ещё они используются для offline-режима, в котором пользователь может ввести запрос и получить ответ как только появится соединение. Но наиболее интересным мне показался кейс с анализом запросов за бандлами js-кода. Код, работающий в сервис воркере, определяет состав бандла, который должен быть загружен с сервера. После этапа анализа создаётся бандл из локально закешированных модулей. Это позволяет увеличить отзывчивость сайта и уменьшить объём потребляемого трафика у клиента.

В статье есть ещё много информации о том, с каким сложностями столкнулась команда при добавлении сервис воркеров, и как они с ними справились. Статью точно стоит прочитать, если вы думаете о том, как внедрить сервис воркеры в свой проект.

#serviceworker #performance #google

https://web.dev/google-search-sw/

Ребята из Slack продолжают радовать статьями про своё новое приложение. В этот раз они написали про использование сервис воркеров в web-версии — "Service Workers at Slack: Our Quest for Faster Boot Times and Offline Support".

При первой загрузке приложения в кеш сервис воркера помещаются html, звуковые файлы, шрифты, js и css-файлы. Для того чтобы хранящиеся файлы не устаревали, кастомный плагин webpack формирует манифест, который встраивается в установочный код сервис воркера. Изменение кода сервис воркера инициирует его установку, в результате которой происходит загрузка всех файлов из манифеста и их сохранение в кеш. При таком подходе всегда будет загружаться не самая последняя версия клиента. Но на этот шаг пошли осознанно, чтобы сократить время загрузки клиента. Теперь приложение с прогретым кешом стартует в два раза быстрее. Чтобы приложение не устаревало, в фоне регулярно происходит проверка наличия обновлений.

Добавление сервис воркеров позволило реализовать базовые оффлайн функции (чтение ранее загруженных сообщений, отметки о прочитанности сообщений). В будущем, планируют добавить более продвинутые оффлайн-сценарии, но не написали, какие именно.

Статья хорошая, но, скорее всего, будет интересна не всем.

#serviceworker #experience

https://slack.engineering/service-workers-at-slack-our-quest-for-faster-boot-times-and-offline-support-3492cf79c88

Филип Уолтон из Google поделился техникой сокращения объёма скачиваемых страниц — "Smaller HTML Payloads with Service Workers".

Филип предлагает разделять страницу на составные части (в его примере — шапка, контент, подвал) и склеивать их в исходную страницу на уровне сервис-воркера. Благодаря такому подходу клиент будет загружать шапку и подвал только один раз. При этом можно не дожидаться загрузки контента, а начинать стримить склеиваемую страницу прямо из сервис-воркера, что ещё сильнее сказывается на сокращении First Contentful Paint (в блоге Филипа FCP уменьшился на 52%). Чтобы не ломать SEO, нужно создать полноценную страницу, которая будет раздаваться обычным web-сервером.

Очень рекомендую почитать статью. Описанную технику можно использовать для ускорения не только статических сайтов, но и SPA.

#performance #serviceworker

https://philipwalton.com/articles/smaller-html-payloads-with-service-workers/

Демиан Рензулли и Джеф Посник рассказали про то, как использовать сервис воркеры и Streams API для быстрого перехода между страницами сайта — "App shell UX with service workers and streams".

Статья основывается на подходе, который используется сайтом dev.to. На всех страницах выделяются общие части: header, navbar, footer — они кешируются сервис воркером. При переходе на новую страницу с сервера приходит основное содержимое сайта, которое "склеивается" с закешированными частями и передаётся как результат с помощью Streams API. Благодаря использованию стримов браузер начинает рендерить шапку страницы до получения ответа сервера. Переходы между страницами страницами становятся очень быстрыми — во время навигации по сайту заголовок страницы остаётся на своём месте, создавая иллюзию SPA. В статье есть пример как реализовать такой подход с помощью библиотеки Workbox.

Рекомендую почитать статью всем, кто поддерживает многостраничные сайты и ищет способы ускорения их работы.

#serviceworker #performance

https://web.dev/app-shell-ux-with-service-workers/

Стэфан Гису и Мартин Ширли в блоге web.dev рассказали о том, как собирать аналитику, когда устройство находится в оффлайне — "Measuring offline usage".

Собирать аналитику в оффлайне можно с помощью сервис воркеров. В статье для этого используется библиотека workbox, которая использует сервис воркеры под капотом. В workbox в свою очередь есть расширение, с помощью которого можно собирать оффлайн-аналитику и отправлять её в Google Analytics после перехода устройства в онлайн. Это расширение использует Background Sync API (поддерживается только в Chrome).

Сбор оффлайн-аналитики полезен для принятия решения, нужно ли добавлять на сайт оффлайн-режим или нет. Для этого можно сравнить между собой метрики обычных пользователей и пользователей, для которых сайт был недоступен.

Рекомендую почитать статью всем, кто думал над тем, чтобы добавить оффлайн-режим в свой проект.

#serviceworker #mobile

https://web.dev/measuring-offline-usage/

Джереми Вагнер рассказал о своём опыте использования сервис воркеров — "Now THAT’S What I Call Service Worker!".

Джереми работал с сайтом клиента, который часто посещают пользователи с ненадёжным подключением к сети. Добавление сервис воркера со стандартной схемой кэширования всего ответа улучшило метрики производительности на 10-20%. Дальнейшее его улучшение с помощью сохранения заголовка и подвала сайта в оффлайнт-кеше и динамического формирования всей страницы в сервис воркере улучшило FCP на 40%, а LCP на 51%. В статье есть пример с подробной реализацией этой стратегии.

Выводы из статьи. Даже самая базовая интеграция сервис воркера даёт преимущества по сравнению с обычным HTTP-кешированием.

Полезная статья. Рекомендую почитать всем, кто занимается производительностью.

#performance #serviceworker

https://alistapart.com/article/now-thats-what-i-call-service-worker/

Пока одни проекты внедряют сервис воркеры, другие их удаляют. Молли Стрюв из dev.to рассказала, почему они решили удалить сервис воркер — "Goodbye Offline Page".

Сервис воркер в первую очередь использовался для ускорения загрузки сайта, но он оказался дорогим в поддержке по разным причинам (в том числе из-за особенностей реализации в разных браузерах). Так как сайт уже был прикрыт CDN (то есть не сильно терял в производительности), они решили оставить сервис воркер только для оффлайн-страницы, но решили удалить его полностью после нескольких критических багов в проде.

Статья интересная, но не очень подробно раскрывает суть проблем.

#performance #serviceworker

https://dev.to/devteam/goodbye-offline-page-5d98