Почему это важно? Что я пропустил?

Я смотрел на практику обслуживающего персонала и workbox.

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

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

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

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

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

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

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

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

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

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


person Mark Ye    schedule 02.10.2020    source источник


Ответы (2)


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

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

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

person Chris Love    schedule 03.10.2020
comment
Спасибо за ответ. Думаю, вопрос был неправильно понят. Речь шла о том, зачем заниматься предварительным кешированием, а не просто кешированием во время выполнения. Кажется, что предварительное кэширование приносит пользу только при первом посещении, когда срабатывает установка службы. Предварительное кэширование и кэширование во время выполнения не должны делать ничего по-другому при последующих посещениях. - person Mark Ye; 04.10.2020
comment
Кстати, если вы заинтересованы в снятии ограничения пути sw, ознакомьтесь с этим w3. org / TR / service-worker / # service-worker-allowed - person Mark Ye; 05.10.2020
comment
Я правильно понял вопрос. На самом деле это всегда зависит от того, как приложение должно работать. Некоторые активы должны быть предварительно кэшированы, другие - динамическими. Вы также должны использовать стратегии недействительности кеша и т.д. - person Chris Love; 09.10.2020
comment
Да, но вопрос в том, в чем разница, и зачем вам использовать одно вместо другого, вы на самом деле не ответили. Вы просто дали общий хороший совет и сказали, что все приложения имеют разные требования. - person joeycozza; 06.07.2021

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

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

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

Кэш-страт:

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

Предварительное кеширование Strat:

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

Разница:

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

person joeycozza    schedule 06.07.2021