В моем прогрессивном веб-приложении я должен использовать API-интерфейс кэша для рабочего агента для своих статических активов или просто полагаться на собственный контроль кеша браузера для них? Какая разница?
Какая разница между использованием API-интерфейсов Service Worker Cache и обычного кеша браузера?
Ответ 1
Основным преимуществом API кэширования сервис-работника является то, что он дает вам более подробный контроль, чем встроенный кеш браузера. Например, ваш работник службы может кэшировать несколько запросов, когда пользователь сначала запускает ваше веб-приложение, включая активы, которые они еще не посетили. Это ускорит последующие запросы. Вы также можете реализовать свою собственную логику управления кешем, гарантируя, что активы, которые считаются важными, хранятся в кеше при удалении менее используемых данных.
Ответ 2
Основное отличие - контроль. Кэш браузера отключен от заголовков Cache-Control, что хорошо, пока его нет. Существуют всевозможные стратегии для управления кэшированием сетевых адресуемых ресурсов; частные, общественные; время жить и т.д.
С кэшированием сервисных работников вы можете программным образом контролировать, как эти активы сохраняются. Но это означает, что на вас лежит бремя.
Кэш браузера - это то, что я считаю ненадежным. Браузер автоматически очистит активы на основе доступности хранилища устройств. Например, iPhones использовали игнорировать кеширование для любого ресурса более 25 КБ. Сегодня я думаю, что они просто очень агрессивны.
Я знаю, что команда Facebook провела несколько лет назад и обнаружила, что только 25% файлов, которые, как они ожидали, кэшируют на кешках, основаны на заголовках. Это означало дополнительный сетевой трафик и активность сервера.
Вот почему кэширование сервисных работников - лучший выбор. Не удаляйте заголовки кеша, просто не опирайтесь на них.