Автор Микель | Фронтенд-джедаи

Если вы читаете это, я позволю себе взять на себя смелость и предположить, что вы уже знакомы с Service Workers (SW) и их ценностью как для пользователей, так и для разработчиков.

Если нет, вот несколько ссылок, которые помогут вам быстрее:

В Marfeel мы были одними из первых, кто начал использовать Service Workers; мы начали использовать их, как только они стали поддерживаться, чтобы воспользоваться преимуществами контроля над сетевыми сообщениями, push-уведомлений через Интернет и, что наиболее важно, кэширования.

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

API кеширования сервис-воркеров

Кэш SW предоставляет API для использования кеша приложения. Это похоже на хранилище ключей и значений, в котором объекты запроса используются как ключи, а ответы как значения. Самое лучшее в этом то, что разработчики могут выбирать что кэшировать и когда использовать это или нет.

В нашем случае мы хотели иметь контроль над ресурсами, которые мы обслуживаем из нашего источника, и кэшировать их в соответствии с типом.

Проверка каждого запроса

Для этого мы должны перехватывать все запросы. Поэтому для каждого запроса, отправляемого из приложения, мы проверяем, попадает ли он в домен Marfeel.

Вот упрощенный код, который у нас есть:

Если запрашивается не ресурс Marfeel, браузер продолжает работу в обычном режиме.

Но если запрашивается ресурс Marfeel, у нас есть разные стратегии или политики в зависимости от типа ресурса. Например:

  • Запросы навигации. Поскольку страницы, на которых используется наше решение, являются издателями, запросы навигации направляются к статьям и разделам статей. В этом случае мы хотим быть максимально свежими. Здесь мы используем стратегию: всегда получать ресурс из сети и кэшировать его, чтобы он был доступен, даже если сеть недоступна (например, когда пользователь не в сети).
  • Для некоторых пакетов JS, которые не обновляются постоянно: сначала кешируйте. Это как раз наоборот. Мы хотим получить контент из кеша, чтобы ответ был мгновенным, но затем «в фоновом режиме» отправим запрос и обновим кеш, чтобы он был свежим для следующего доступа.
  • Гонка: в большинстве случаев мы хотим попытаться получить ресурс из сети, одновременно кэшировать и вернуть первый ответивший. Это всегда должен быть ответ кеша, но если он еще не был кэширован или работает медленнее, у вас есть ответ сети.
  • Кроме того, есть некоторые ресурсы, которые не изменяются со временем (например, некоторые изображения, такие как логотипы), которые вы можете кэшировать, как только кеш будет инициализирован, с помощью метода addAll ().

Таким образом, с очень небольшим количеством кода и большим количеством отладки и тестирования вы можете настроить несколько политик кеширования.

Теперь давайте посмотрим, что изменилось и действительно ли оно того стоит.

Результаты, достижения

С помощью предыдущего кода мы достигли пары вещей:

Результат # 1

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

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

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

Результат # 2

Второй результат - доступность контента в автономном режиме.

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

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

Но мы не можем забыть это ...

  • Несмотря на то, что Service Workers и правильные политики кэширования в конечном итоге повышают производительность, мы добавляем накладные расходы. Даже если это очень мало, перехват всех запросов и введение некоторой логики перед подключением к сети требует определенных затрат.
  • Все это будет полноценно работать при 2-й и последующих загрузках страницы. При первой загрузке большая часть ресурсов уже загружена к моменту запуска Service Workers.
  • Файлы будут кэшироваться, поэтому, если вы хотите установить исправление ошибки или что-то в этом роде, это займет некоторое время, если не будет реализована какая-либо политика очистки кеша.