Здесь много нюансов, и правильный ответ сводится к сочетанию понимания ваших пользователей и понимания ваших ресурсов.
Рекомендации пользователя
Одно из основных соображений заключается в том, уважает ли принудительная загрузка ~ 20 МБ данных вашу целевую пользовательскую базу.
Если вы разрабатываете собственное PWA для корпоративного клиента, вы можете быть уверены, что большинство пользователей будут использовать быстрое соединение и не будут платить по мегабайтам за свой тарифный план.
Если вы разрабатываете для рынка, на котором есть люди, использующие более медленные лимитированные соединения, хорошей идеей будет избегать автоматического предварительного кэширования больших полезных данных. Вы можете либо уменьшить размер полезной нагрузки предварительного кэша, либо, в качестве альтернативы, отложить регистрацию сервисных работников до тех пор, пока они немного не взаимодействуют с вашим PWA — в этот момент, если они используют ваш сайт, они с большей вероятностью извлекут пользу из вещей. кэшируется, и это не будет похоже на «дамп данных».
Понимание ваших ресурсов
В исходном вопросе ~ 20 МБ были названы ресурсами JavaScript, и я предполагаю, что все они являются активами, которые загружаются отложенно для различных представлений в вашем веб-приложении.
Предпочитайте множество небольших отдельных активов меньшему количеству объединенных более крупных активов
Помимо размышлений о первоначальных затратах на предварительное кэширование, вас должны беспокоить текущие затраты на истечение срока действия и повторную выборку записей, которые ранее были предварительно кэшированы, поскольку вы со временем вносите изменения в свой сайт.
Если у вас предварительно кэшировано 20 отдельных пакетов, каждый из которых имеет размер ~1 МБ, то внесение изменений в один файл в одном из пакетов приведет к передаче ~1 МБ данных в рамках последующего обновления. Если у вас есть 2 отдельных пакета, каждый из которых имеет размер ~ 10 МБ, то изменение того же файла приведет к передаче ~ 10 МБ данных. Стоимость поддержания ваших предварительно кэшированных ресурсов в актуальном состоянии может со временем легко перевесить первоначальные затраты на предварительное кэширование, поэтому постарайтесь помнить об этом при объединении.
Предварительно кэшируйте ресурсы только для представлений, которые с большой вероятностью будут использоваться.
Это следует из предыдущего пункта — старайтесь избегать предварительного кэширования лениво загружаемых ресурсов, которые будут запрашиваться только небольшим процентом ваших пользователей. Даже если сами активы невелики, их поддержание в актуальном состоянии требует затрат, которые эти пользователи платят каждый раз, когда вы вносите изменения в любой из файлов, составляющих эти пакеты. Вы можете легко представить ситуацию, когда со временем пользователь загружает и повторно загружает JS, который никогда не будет выполнен.
Не предварительно кэшировать изображения (обычно)
(Это предполагает, что вы рассматриваете возможность предварительного кэширования изображений.)
Изображения, если только они не используются как часть пользовательского интерфейса на многих страницах, не являются лучшими кандидатами для предварительного кэширования. Очевидно, что они имеют тенденцию быть большими, и если они не загружаются из-за того, что вы не в сети и их нет в кеше, то, надеюсь, у вас есть альтернативный текст в HTML-разметке для отображения вместо них.
Использование стратегии кэширования во время выполнения вместе с политикой истечения срока действия кэша обычно является лучшим советом для изображений.
person
Jeff Posnick
schedule
30.07.2018
