Блог

Я смотрел на практику service worker и workbox.

Есть много статей, в которых говорится о предварительном кэшировании, workbox даже предоставляет специальный метод precachingAndRoute() именно для этого. Думаю, я понимаю концептуальную разницу между предварительным кэшем и кэшем времени выполнения, но что меня смущает, так это то, почему предварительное кэширование обрабатывается так специально?

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

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

Рассмотрим 2 абстрактных случая для сравнения. Допустим, у нас есть два разных service worker, один ( /precache/sw.js ) выполняет только предварительное кэширование, а другой ( /runtime/sw.js ) выполняет только кэш времени выполнения, где /precache и /runtime размещено одно и то же веб-приложение (что означает, что одни и те же ресурсы будут кэшироваться).

При каком сценарии веб-приложение /precache и /runtime может работать по-разному из-за разных настроек sw?

В моем понимании,

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

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

Как онлайн / оффлайн делает предварительное кэширование героем?

Что я здесь пропустил, что такого особенного в предварительном кэшировании?

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

На что похоже приложение:

У вас есть целевая страница для вашего приложения. У вас есть несколько маршрутов, по которым можно перемещаться

Cache Strat:

Если пользователь переходит на целевую страницу, кэшируются только ресурсы целевой страницы.

Стратегия предварительного кэширования:

Если пользователь переходит на целевую страницу, все настроенные предварительно кэшированные ресурсы будут кэшироваться.

Разница:

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

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

Вы хотите как можно больше предварительно кэшировать, не нарушая динамический характер вашего приложения. Итак, кэшируйте обычные JS, CSS, изображения, шрифты и страницы, которые используются снова и снова. Конечно, есть стратегия аннулирования, чтобы поддерживать их в актуальном состоянии. Затем обработайте некэшированные сетевые адресуемые ресурсы (URL) из обработчика событий выборки. Кэшируйте их так, как это имеет смысл. И аннулируйте кэшированные ресурсы, поскольку это имеет смысл.

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