Service worker очистить кэш

Обновлено: 03.07.2024

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

Введение в сервис-воркеров

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

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

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

Находясь в отдельном потоке, он не имеетДОМдоступ, и нет доступа кЛокальное хранилищеAPI иXHRAPI тоже, и он может связываться только с основным потоком, используяChannel Messaging API.

Сервис-воркеры взаимодействуют с другими недавними веб-API:

Фоновая обработка

Например они могут работать:

когда ваше мобильное приложениена заднем фоне, не активный
когда ваше мобильное приложениезакрыто, поэтому даже не в фоновом режиме
когдабраузер закрыт, если приложение запущено в браузере

Основные сценарии, в которых Service Workers очень полезны:

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

Service Worker запускается только при необходимости и останавливается, когда не используется.

Офлайн-поддержка

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

В недавнем прошлом HTML5 AppCache уже обещал разрешить веб-приложениям кэшировать ресурсы и работать в автономном режиме, но его отсутствие гибкости и запутанное поведение ясно дали понять, что он недостаточно хорош для работы, не выполняя своих обещаний (иэто было прекращено).

Сервис-воркеры - это новый стандарт автономного кэширования.

Какое кеширование возможно?

Предварительное кэширование ресурсов во время установки

Активы, которые повторно используются во всем приложении, такие как изображения, файлы CSS, JavaScript, могут быть установлены при первом открытии приложения.

Кеширование сетевых запросов

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

Жизненный цикл обслуживающего работника

Сервисный воркер проходит 3 шага, чтобы полностью заработать:

Постановка на учет
Установка
Активация

Постановка на учет

Пример кода для регистрации Service Worker, размещенного в worker.js :

Объем

В register() call также принимает параметр области, который представляет собой путь, определяющий, какая часть вашего приложения может контролироваться сервис-воркером.

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

В приведенном ниже примере регистрируется рабочий, указав /notifications/ объем папки.

В / важно: в этом случае страница /notifications не будет запускать Service Worker, в то время как если бы область

это сработало бы.

ПРИМЕЧАНИЕ. Сервисный работник не может «подняться» из папки: если его файл помещен в /notifications , он не может контролировать / путь или любой другой путь, который не находится под /notifications .

Установка

Если браузер определяет, что сервис-воркер устарел или никогда ранее не регистрировался, он продолжит его установку.

Это хорошее мероприятие для подготовки Service Worker к использованиюинициализация кеша, икешировать оболочку приложенияи статические активы, использующиеCache API.

Активация

Этап активации - это третий шаг после успешной регистрации и установки сервис-воркера.

На этом этапе сервис-воркер сможет работать с новыми загрузками страниц.

Он не может взаимодействовать с уже загруженными страницами, что означает, что сервис-воркер полезен только во второй раз, когда пользователь взаимодействует с приложением или перезагружает одну из уже открытых страниц.

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

Обновление Service Worker

Чтобы обновить Service Worker, вам просто нужно изменить в нем один байт, и при запуске кода реестра он будет обновлен.

После обновления Service Worker он не станет доступным до тех пор, пока все страницы, которые были загружены с подключенным старым Service Worker, не будут закрыты.

Это гарантирует, что в уже работающих приложениях / страницах ничего не сломается.

Обновления страницы недостаточно, так как старый воркер все еще работает и не был удален.

Получить события

Аполучить событиезапускается, когда ресурс запрашивается в сети.

Это дает нам возможностьсмотреть в кешперед выполнением сетевых запросов.

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

Фоновая синхронизация

Фоновая синхронизация позволяет откладывать исходящие соединения до тех пор, пока у пользователя не появится рабочее сетевое соединение.

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

Этот код прослушивает событие в Service Worker:

doSomething() возвращает обещание. В случае сбоя будет запланировано автоматическое повторение другого события синхронизации до тех пор, пока оно не завершится успешно.

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

Push-события

Сервис-воркеры позволяют веб-приложениям предоставлять пользователям собственные push-уведомления с помощью:

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

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

События push инициируются серверной частью через службу push-уведомлений браузера, например, предоставляемуюFirebase.

Вот пример того, как сервис-воркер может прослушивать входящие push-события:

Замечание о журналах консоли

Если у вас есть какой-либо оператор журнала консоли ( console.log и друзья) в Service Worker, убедитесь, что вы включили Preserve log особенность, предоставленнаяChrome DevTools, или эквивалент.

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

Cache API был создан для того, чтобы Service Workers могли кэшировать сетевые запросы, чтобы они могли предоставлять соответствующие ответы даже в автономном режиме. Тем не менее, это API также может быть использовано в качестве общего механизма хранения.

Где это доступно?

API в настоящее время доступно в Chrome, Opera и Firefox. И Edge, и Safari помечено «В разработке».

API предоставляется через свойство global caches, так что вы можете проверить наличие API с помощью простого обнаружения функции:

К API можно получить доступ из window, iframe, worker или service worker.

Что можно хранить в кеше

Можно создать объект Request, используя URL для сохранения в кеше:

Конструктор объекта Response принимает разные типы данных, включая Blobs, ArrayBuffers, объекты FormData и строки.

Можно установить MIME тип Response, установив соответствующий заголовок.

Работа с объектами Response

Если вы получили Response и хотите получить доступ к его body, вы можете использовать несколько вспомогательных методов. Каждый возвращает Promise, которое разрешается со значением другого типа.

Method	Description
arrayBuffer	Возвращает ArrayBuffer, содержащий body, сериализованное в байты.
blob	Возвращает Blob Если Response был создан с помощью Blob, то этот новый Blob имеет тот же тип. В противном случае используется Content-Type Response.
text	Интерпретирует байты body как строку в кодировке UTF-8.
json	Интерпретирует байты body как строку в кодировке UTF-8, а затем пытается проанализировать ее как JSON. Возвращает результирующий объект или выдает ошибку TypeError, если строка не может быть преобразована в JSON.
formData	Интерпретирует байты тела как форму HTML, закодированную как «multipart/form-data» или «application/x-www-form-urlencoded». Возвращает объект FormData или выдает ошибку TypeError, если данные не могут быть проанализированы.
body	Возвращает ReadableStream для данных body.

Создание и открытие кеша

Чтобы открыть кеш, используйте метод caches.open(name), передавая имя кеша в качестве единственного параметра. Если именованный кеш не существует, он создается. Этот метод возвращает Promise, который разрешается с помощью объекта Cache.

Извлечение из кэша

Чтобы найти элемент в кеше, используется метод match.

Если запрос является строкой, он сначала преобразуется в запрос путем вызова new Request(request). Функция возвращает Promise, который разрешается в Response, если найдена соответствующая запись, или undefined в противном случае.

Чтобы определить, совпадают ли два запроса, используется не только URL-адрес. Два запроса считаются разными, если они имеют разные строки запроса, заголовки Vary и/или методы (GET, POST, PUT и т. д.).

Вы можете игнорировать некоторые или все эти вещи, передавая объект параметров в качестве второго параметра.

Если более одного кэшированного запроса совпадает, возвращается тот, который был создан первым.

Если вы хотите получить все соответствующие ответы, можно использовать cache.matchAll.

Можно выполнить поиск по всем кешам одновременно, используя caches.match() вместо вызова cache.match() для каждого кеша.

Поиск

Фильтрация

Таким образом, можно использовать любое свойство объектов Request и Response для фильтрации записей. Обратите внимание, что это медленно, если вы ищите большие наборы данных.

Создания index

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

Если вы храните URL-адрес Request вместе со свойствами поиска, можно легко получить правильную запись в кэше после выполнения поиска.

Добавление в кеш

cache.put

cache.add

Синтаксис cache.add (request). request обрабатывается так же, как и для put, но Response, который хранится в кэше, является результатом выборки запроса из сети. Если выборка не удалась или если код состояния ответа не находится в диапазоне 200, то ничего не сохраняется и promises отклоняется. Обратите внимание, что запросы между источниками, не находящиеся в режиме CORS, имеют статус 0, и поэтому такие запросы могут храниться только с put.

cache.addAll

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

Удаление

Удаление элемента из кэша:

Где запрос может быть Request или строкой URL. Этот метод также принимает тот же объект параметров, что и cache.match, который позволяет удалить несколько пар «Request/Response» для одного и того же URL-адреса.

Удаление кеша

Чтобы удалить кеш, вызовите caches.delete(name). Эта функция возвращает Promise, который принимает значение true, если кэш существовал и был удален, или false в противном случае.

Пример использования кеша для service worker

Простой пример, демонстрирующий использование service worker для предварительного кэширования приложения JavaScript.

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

Проблема

Чтобы проиллюстрировать проблему, мы используем простой пример, состоящий из страницы (index.html) и с кнопкой на ней.

Нажатие на кнопку создает iFrame, который загружает вторую страницу (iframe.html), которая, в свою очередь, загружает приложение JavaScript (script.js); представьте, что этот файл большой (скажем, какое нибудь тяжелое приложение).

Хорошей новостью является то, что мы откладываем загрузку большого файла JavaScript, пока не нажмем кнопку. Плохая новость заключается в том, что после нажатия кнопки браузер должен (медленно) загрузить файл перед запуском приложения JavaScript в iFrame.

Код

Код проблемы особенно прост.

Решение

Общая идея состоит в том, что мы хотим, чтобы «большой» файл script.js кэшировался асинхронно при загрузке первой страницы index.html. При этом, когда мы нажимаем кнопку, script.js брался бы из кэша (быстро).

Ключом к этому решению является использование service worker

Код решения

Сначала мы добавляем код загрузчика service worker в…

и создадим код service worker …

Решение в действии

Используя вкладку «Network» в Chrome Developer Tools, мы видим, что при первоначальной загрузке index.html, worker.js загружается асинхронно…

… И запускает service worker (как видно на вкладке «Application»)

Что такое service workers и применение стратегий кэширования

Mar 29, 2019 · 4 min read

Service Workers — наверняка, вы что-то об этом слышали. Что это такое? Говоря простыми словами, это сценарий, который запускается браузером в фоновом режиме. Он никак не связан с веб-страницей или DOM и предоставляет функции “из коробки”, такие как обработка сетевых запросов, push-уведомления и фоновая синхронизация. Service workers обеспечивают возможность работы offline.

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

Service workers подобны J a vascript workers. Они не связаны с DOM или веб-страницами. Они работают на другом потоке и получают доступ к DOM с помощью API postMessage. При разработке прогрессивных веб-приложений (PWA) стоит обратить внимание на service workers и стратегии кэширования.

Примечание - Service workers не относятся к web workers. Web workers -это сценарии, выполняющие нагрузочные вычисления на другом потоке без блокировки основного цикла событий и замедлений в работе UI.

Для начала нужно зарегистрировать service worker в файле javascript.

Рассмотрим приведенный пример. Сначала проверяем наличие API service worker. При наличии поддержки, регистрируем его с помощью метода register, указав путь к файлу service worker. Service worker регистрируется при загрузке страницы.

Install

После регистрации service worker запускается событие install. Его можно прослушать в файле sw.js. Прежде чем перейти к коду, рассмотрим действия в событии install:

Устанавливаем кэш в это событие.
Добавляем все статические активы в кэш.

Метод event.waitUntil() использует промис для определения длительности и результата установки. Если какой-либо файл отсутствует в кэше, то service worker не устанавливается. Поэтому убедитесь, что в кэше отсутствует длинный список URL-адресов, поскольку если даже один url не кэшируется, то установка service worker будет приостановлена.

Activate

После установки нового Service Worker появится событие activate. В этом событии можно удалить старый кэш. Нижеприведенный фрагмент кода взят из руководства по service worker.

После активации, service worker переходит на стадию idle, не выполняя никаких действий, до запуска следующего события.

Fetch

Мы рассмотрели одну из стратегий кэширования в событии fetch под названием “cache falling back to network”. Запомните: все стратегии кэширования реализуются в событии fetch. Рассмотрим некоторые из них:

Cache only

Одна из самых простых стратегий. Как можно догадаться из названия, все запросы отправляются в кэш.

Случаи использования - для получения доступа к статическим активам

Network only

Клиент делает запрос, service worker перехватывает его и направляет в сеть. Легче легкого!!

Случаи использования - при отсутствии аналогов offline, например с analytics pings и запросами non-GET.

Примечание - Также работает в случае отсутствия метода respondWith.

Cache falling back to network

Эту стратегию мы рассматривали выше, в событии fetch. Service worker делает запрос в кэш, и при отсутствии ответа запрос отправляется в сеть.

Случаи использования - при разработке offline first приложения

Network falling back to cache

Сначала service worker делает запрос к сети, и в случае успешного ответа он отправляется в кэш.

Случаи использования - При разработке часто меняющихся страниц, например: страницы для записей или таблицы участников игры. Идеально подойдет для случая, когда в приоритете последние добавленные данные.

Generic fallback (Резерв)

Когда оба запроса дают сбой как к кэшу, так и к сети, отображается общий резерв вместо черного экрана или ошибки.

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

Fast start with PWA. Service Workers. Кеширование

Что такое Progressive Web Apps

Веб-проекты, которые выглядят и ведут себя, как мобильные приложения:

Работают в режиме offline
Имеют иконку на рабочем столе
Синхронизируют данные в фоновом режиме

Плюсы и возможности

Плюсы

Надежные - моментальная загрузка, вы никогда не увидите динозаврика
Быстрые - быстрый отклик на действия пользователя с плавной анимацией и скроллом
Чарующие - предоставляется максимально возможный нативный пользовательский опыт

Возможности

Push уведомления
Фоновая синхронизация
Доступность offline
Возможность установки на рабочий экран телефона
Доступ к камере устройства
Доступ к геопозиции .

SPA можно преобразовать в PWA, так же как и любую другую веб-страницу

Основные "слоны" PWA

Расширение диагностики сайта под Chrome. Проверяет:

Как быстро грузится сайт
Форматы картинок и их сжатие
Неиспользуемый css
SEO
Best practice
Соответствие требованиям PWA
- Скорость загрузки в 3G
- Доступность offline
- Возможность установить
Обычный json файл, содержащий информацию для браузера, как ваше веб-приложение должно себя вести, когда "установлено" на мобильное устройство.

Наличие этого файла обязательно в Chrome для показа предложения Add to Home Screen

Web App Manifest Generator

Сервис генерации манифеста для проекта (open source)

Добавьте в тэг head

Тестирование на реальном устройстве

Browser support

Service Worker lifecycle
1. register
2. installation
3. activation
4. idle
5. termination
serviceWorker.js

app.js

Когда обновляется Service Worker?
- При закрытии вкладки со старым процессом и открытии новой
- Добавить строчку self.skipWaiting(); в listener для install
Кеширование с Service Workers

Зачем?
- Плохое соединение
- Нет соединения (лифт/метро)
- Lie-Fie
Как?

Cache API - механизм для хранения пары запрос/ответ (без поддержки в Safari)

Что?

Объект, отвечающий за взаимодействие с кешем
- match(Request) - Проверяет, является ли данный Request ключом в любом из объектов Cache, отслеживаемых объектом CacheStorage, и возвращает Promise, который успешно завершится, когда найдет совпадение.
- open(cacheName) - Возвращает Promise, который успешно завершится, когда объект Cache найдет необходимый объект с cacheName (если такого нет, то создаст новый).
- has(cacheName) - Возвращает Promise, который успешно завершится и вернет true, если объект Cache содержит кеш с установленным cacheName.
Метод put позволяет добавлять данные налету.

Читайте также: