ОБНОВЛЕНИЕ: 14 апреля Google объявил, что приостанавливает выполнение плана по развертыванию этой функции. Ознакомьтесь с моей последующей статьей здесь.

Если у вас есть PWA и вы недавно просматривали манифест консоли или приложения, возможно, вы заметили это сообщение:

Страница не работает офлайн. Начиная с Chrome 93, критерии возможности установки меняются, и этот сайт нельзя будет установить. Https://developer.chrome.com/blog/improved-pwa-offline-detection для получения дополнительной информации.

Или, если вы используете Edge:

Не удается установить сайт: страница не работает в автономном режиме. Эта страница не будет считаться устанавливаемой после Edge 93, стабильного выпуска от августа 2021 года.

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

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

В предстоящем выпуске Chrome вам придется использовать кеш, иначе PWA больше не будет устанавливаться.

Почему это происходит?

Догма Google состоит в том, что PWA никогда не должен отображать офлайн-экран Chrome по умолчанию. Вместо этого все PWA должны быть доступны в автономном режиме или отображать какую-то автономную страницу в качестве запасного варианта. Благодаря описанному выше хакеру вам не пришлось заставлять PWA работать в автономном режиме. Теперь вы будете (или вам нужно будет найти еще более уродливый хак, чтобы этого не делать).

Теперь немного неясно, почему пользовательская страница, которая практически не делает ничего полезного, кроме сообщения «вы не в сети», является лучшим запасным вариантом, чем страница с динозаврами по умолчанию. Люди действительно знают, что означает эта страница. Он предлагает четкие инструкции о том, что делать, чтобы вернуться в Интернет. И он создан самим Google (поэтому он не перенаправляет трафик на какой-то сторонний сайт, не связанный с этим).

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

Примечание: я создаю Progressier специально для того, чтобы вам не приходилось иметь дело с последними причудами Google / Apple / Microsoft / Samsung / Firefox (мы позаботимся об этом за вас - и это бесплатно), но если вы абсолютно настаиваете на том, чтобы нанести это себе, ниже описано, что вам нужно сделать, чтобы ваше приложение стало совместимым.

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

Во-первых, вам нужно заполнить обработчик «выборки», чтобы он действительно делал что-то полезное, то есть кешировал ресурсы. Есть два основных способа сделать это.

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

Есть еще пара мало полезных стратегий. С помощью Cache-First вы вообще не перепроверяете ресурсы. Ресурсы никогда не могут быть обновлены, если они находятся в кеше, но такая стратегия также может снизить ваши счета за использование AWS. При использовании Network-Only вы вообще не используете кеш, поэтому ресурсы всегда свежие. Также существует стратегия Cache-Only, которая практически бесполезна.

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

Проблема с кешированием ресурсов

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

В Progressier наше решение (по состоянию на март 2021 г.) в настоящее время частично совместимо с Chrome 93. Большинство PWA, в которых есть Progressier, уже работают в автономном режиме, хотя это немного зависит от точной структуры вашего приложения. К моменту выпуска Chrome 93 мы будем полностью соответствовать требованиям, так что каждое приложение, в котором работает Progressier, будет доступно в автономном режиме независимо от их структуры.

Как мы решим указанную выше проблему: наш бот будет регулярно посещать ваше приложение и проверять сетевые запросы. Когда мы видим новые ресурсы, мы автоматически добавляем их в список ресурсов для кеширования. С Workbox вам придется вручную создавать стратегии кеширования. С Progressier стратегии строятся для вас автоматически.

У вас есть вопросы? Или вам нужна помощь в обеспечении соответствия PWA Chrome 93? Прокомментируйте или напишите мне на [email protected]