Строительные блоки прогрессивных веб-приложений

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

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

Что делает веб-приложение прогрессивным?

Прогрессивное веб-приложение — это общий термин для определенных технологий, которые вместе создают интерфейс, похожий на приложение в Интернете. Для простоты я буду называть их просто веб-приложениями.

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

В то же время он не должен жертвовать вещами, которые делают Интернет великолепным, например, возможностью делать глубокие ссылки в приложении и использовать URL-адреса для обеспечения совместного использования контента. Как и Интернет, он должен хорошо работать на разных платформах, а не ориентироваться исключительно на мобильные устройства. Он должен вести себя так же хорошо на настольном компьютере, как и в других форм-факторах, иначе мы рискуем столкнуться с новой эрой неотвечающих веб-сайтов m.example.com.

Прогрессивные веб-приложения не новы. Мобильные браузеры имеют возможность добавлять веб-сайты в закладки на главный экран вашего телефона с 2011 года (2013 год в Chrome Android), а метатеги в head определяют внешний вид установленной веб-страницы. The Financial Times использует веб-приложение для доставки цифрового контента на мобильные устройства с 2012 года.

Переход на веб-приложение позволил Financial Times использовать одно и то же приложение для доставки на разные платформы по одному каналу распространения. Когда я работал в Financial Times, с помощью одной сборки мы могли поддерживать следующее:

• iOS,
• Android (4.4+) Chrome,
• старый Android (через обертку),
• Windows 8,
• Ежевика,
• ОС Фаерфокс.

Это действительно означает «создать один раз, развернуть где угодно».

«Но его нет в App Store»

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

Я бы сказал, что пребывание в магазине приложений не имеет большого преимущества, потому что было показано, что если вы не входите в 0,1% лучших приложений в магазине приложений, вы не получаете значительной выгоды от пребывания там.

Пользователи, как правило, находят ваши приложения, сначала находя ваш веб-сайт. Если ваш веб-сайт представляет собой веб-приложение, то они уже находятся в пункте назначения.

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

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

Фон и текущий климат

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

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

В Chrome 38 появился манифест веб-приложения, который представляет собой файл JSON, описывающий конфигурацию вашего веб-приложения. Это позволило нам убрать конфигурацию из head .

В Chrome 40 (декабрь 2014 г.) сервис-воркеры начали внедряться в Firefox и Chrome. Apple до сих пор решила не реализовывать эту функцию в Safari на момент написания, но держит ее «на рассмотрении». Функция сервисного работника состоит в том, чтобы упростить процесс перевода приложения в автономный режим; он также закладывает основу для будущих функций приложений, таких как push-уведомления и фоновая синхронизация.

Приложения, созданные на основе новых сервис-воркеров и манифеста веб-приложений, стали называться прогрессивными веб-приложениями.

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

• имеет сервис-воркер (требуется HTTPS);
• имеет файл манифеста веб-приложения (по крайней мере, с минимальной конфигурацией и с display: "standalone" );
• было два разных визита.

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

Запрос на установку веб-приложения в настоящее время отображается в различных условиях в браузерах Opera, Chrome и Samsung.

Apple проявляет интерес к прогрессивным веб-приложениям для iOS, но на момент написания статьи она по-прежнему полагается на метатеги для конфигурации веб-приложений и кэш приложения (AppCache) для автономного использования.

В какой момент веб-сайт становится веб-приложением?

Мы знаем, как выглядит веб-сайт и как выглядит приложение, но в какой момент веб-сайт становится веб-приложением? Не существует окончательной метрики того, что делает что-то веб-приложением, а не веб-сайтом.

Здесь мы более подробно рассмотрим характеристики веб-приложения.

Прогрессивное веб-приложение должно обладать определенными свойствами…

• Отзывчивый
  Идеально заполняя экран, эти веб-сайты в первую очередь предназначены для телефонов и планшетов и должны соответствовать множеству размеров экрана. Они также должны работать как настольные веб-сайты. Адаптивный дизайн уже много лет является важной частью создания веб-сайтов. В Smashing Magazine есть отличные статьи об этом.
• Офлайн-первый
  Приложение должно иметь возможность запускаться в автономном режиме и по-прежнему отображать полезную информацию.
• сенсорный
  Интерфейс должен быть разработан для сенсорного управления с жестовым взаимодействием. Взаимодействие с пользователем должно быть отзывчивым и мгновенным, без задержки между прикосновением и ответом.
• Метаданные приложения
  Приложение должно предоставлять метаданные, чтобы сообщать браузеру, как оно должно выглядеть после установки, чтобы вы получали красивый значок с высоким разрешением на главном экране и заставку на некоторых платформах.
• Всплывающие уведомления
  Приложение может получать уведомления, когда оно не запущено (если применимо).

… но должны поддерживать определенные веб-свойства

• прогрессивный
  Возможность установки приложения является прогрессивным улучшением. Крайне важно, чтобы приложение по-прежнему работало как обычный веб-сайт, особенно на платформах, которые еще не поддерживают установку или обслуживание.
• HTTPS в открытом Интернете
  Приложение не должно быть привязано к какому-либо браузеру или магазину приложений. Он должен иметь возможность иметь глубокие ссылки и должен предоставлять методы для обмена текущим URL-адресом.

Перевод вашего сайта в автономный режим

Перевод вашего веб-сайта в автономный режим дает некоторые важные преимущества.

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

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

Есть два способа заставить веб-сайт работать в автономном режиме:

• Старый и нерабочий метод
  Поддержка запуска вашего веб-сайта в автономном режиме существует уже много лет в виде AppCache. Однако у AppCache есть несколько серьезных недостатков, и он даже исключен из спецификации. С ним сложно работать, и при неправильной настройке он может навсегда сломать ваш сайт. Тем не менее, это единственный способ работать в автономном режиме на iOS, по крайней мере, до тех пор, пока Apple не примет меры для поддержки сотрудников службы поддержки.
• Новая горячность
  Также эффективны сервис-воркеры, которые в настоящее время поддерживаются в Chrome, Firefox и Opera и очень скоро появятся в Edge. Команда Apple WebKit пометила его как «на рассмотрении».

Сервис-воркеры похожи на другие веб-воркеры тем, что они работают в отдельном потоке, но не привязаны к какой-то конкретной вкладке. При создании им назначается область URL, и они могут перехватывать и переписывать любые запросы в этой области. Если ваш сервис-воркер находится по адресу https://example.com/my-site/sw.js , он сможет перехватывать любые запросы к /my-site/ или ниже, но не может перехватывать запросы к корневому https://example.com/ . https://example.com/ .

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

Хорошим советом является то, что если вы создаете новый веб-сайт с нуля, начните с сервисного работника. Однако, если ваш веб-сайт уже работает в автономном режиме с AppCache, вы можете использовать инструмент sw-appcache-behavior, чтобы сгенерировать из него сервис-воркера, потому что скоро мы можем достичь точки, когда некоторые браузеры будут принимать только сервис-воркеров, а некоторые — только Кэш приложений.

Поскольку AppCache устарел, я не буду обсуждать его в этой статье.

Настройка сервис-воркера

(Также см. «Настройка Service Worker» для получения более подробных инструкций.)

Поскольку сервис-воркер — это особый тип общего веб-воркера, он запускается в отдельном потоке на вашей главной странице. Это означает, что он используется всеми веб-страницами на том же пути, что и сервис-воркер. Например, сервис-воркер, расположенный по адресу /my-page/sw.js , сможет воздействовать на /my-page/index.html и my-page/images/header.jpg , но не /index.html .

Сервисные работники могут перехватывать и переписывать или подделывать все сетевые запросы, сделанные на странице, в том числе сделанные к URL-адресам data:// !

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

Это разрешено только в защищенных контекстах (например, HTTPS), потому что это очень мощно. Это не позволяет третьим лицам навсегда переопределить ваш веб-сайт с помощью внедренного сервисного работника из зараженной или вредоносной точки доступа Wi-Fi.

Настройка HTTPS в настоящее время может показаться сложной и дорогой, но на самом деле это никогда не было проще и дешевле. Let's Encrypt предоставляет бесплатные SSL-сертификаты и сценарии для автоматической настройки сервера. Если вы размещаете на GitHub, страницы GitHub автоматически обслуживаются через HTTPS. Страницы Tumblr также можно настроить для работы по протоколу HTTPS. CloudFlare может проксировать запросы на обновление до HTTPS.

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

Я использую Service Worker Toolbox, чтобы абстрагироваться от сложной логики кэширования. Эту библиотеку можно настроить для обработки маршрутизации, предоставив четыре предварительно настроенных маршрута, которые можно легко настроить. Его можно импортировать в ваш сервис-воркер.

Вариант использования 1: предварительное кэширование

Предварительное кэширование отбирает запросы до того, как ваш сайт поймет, что они необходимы. Это может значительно сократить время первой прорисовки, потому что вашему веб-сайту не нужно анализировать /site.css прежде чем он начнет загрузку логотипа вашего веб-сайта, /images/logo.png .

 toolbox.precache(['/index.html', '/site.css', '/images/logo.png']);

Вариант использования 2: офлайн

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

 toolbox.router.default = toolbox.networkFirst; toolbox.options.networkTimeoutSeconds = 5;

На самом деле мы можем быть немного умнее, потому что большинство ваших активов не изменится со временем. Вероятно, мы просто хотим получить контент как можно быстрее, будь то из кеша или из сети. Следующая строка сообщает Service Worker Toolbox, что все запросы к путям к изображениям должны исходить из кеша, если они там доступны.

 toolbox.router.all('/images/*', toolbox.fastest);

В этом случае, когда пользователь проходит аутентификацию, важно, чтобы мы не просто возвращали кешированный ответ; мы должны указать, что запросы к /auth/ должны быть только сетевыми.

 toolbox.router.post('/auth/*', toolbox.networkOnly);

Вот несколько хороших практик для оффлайна:

• Исходные статические ресурсы должны быть предварительно кэшированы. Это загружает их и кэширует при установке сервисного работника. Это означает, что их не нужно загружать с сервера, когда они в конечном итоге потребуются.
• По умолчанию запросы в идеале должны поступать из сети, но возвращаться в кеш, чтобы они были доступны в автономном режиме.
• Относительно короткое время ожидания сети означает, что запросы смогут возвращать кэшированные данные по сетевому соединению, которое говорит, что у него есть соединение для передачи данных, но ответы не возвращаются.
• Редко обновляемые активы, такие как изображения, должны сначала отправляться из кеша, тогда браузер также попытается их обновить. Если используется toolbox.cacheOnly , он также может сохранять данные пользователя.

Примечание. Кэш браузера и Cache API — разные животные. Cache API был обойден в случае использования сети или только сети. Запрос может по-прежнему попасть в кеш браузера, потому что заголовки кэширования в запросе говорят, что он все еще действителен. Это может привести к тому, что пользователь получит смесь кэшированных и свежих данных. У Джейка Арчибальда есть несколько хороших советов, как избежать этой проблемы.

Отладка вашего сервис-воркера

Если вы используете Chrome или Opera, перейдите по chrome://serviceworker-internals . Это позволит вам проверять, приостанавливать и удалять скрипт сервисного работника.

В последних версиях Chrome и Opera вы можете получить подробные представления и инструменты отладки через вкладку «Приложение» в инспекторе.

Взаимодействие и анимация

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

• Когда пользователь что-то делает, приложение также должно что-то сделать в течение 100 миллисекунд; в противном случае пользователь заметит отставание. Это учитывает нажатия, щелчки, перетаскивания и прокрутки.
• Каждый кадр должен отображаться с постоянной скоростью 60 кадров в секунду (16 миллисекунд на кадр). Даже несколько медленных кадров будут очевидны.
• Это должно быть быстро на трехлетнем бюджетном телефоне, работающем в плохой сети, а не только на вашей блестящей машине для разработки.
• Он должен начаться быстро. Долгое время мы были сосредоточены на поддержании вовлеченности пользователей, делая наши веб-сайты видимыми и удобными для использования менее чем за 1–2 секунды. Когда дело доходит до веб-приложений, время запуска как никогда важно. Если все содержимое приложения кэшировано, а браузер все еще находится в памяти устройства, веб-приложение может запускаться быстрее, чем собственное приложение. Одна ошибка, допущенная разработчиками нативных приложений и веб-сайтов, заключается в том, что для работы продукта требуется сетевой контент.
• Веб-приложение должно быть небольшим для загрузки и обновления: 10 МБ из магазина приложений не кажутся большими, но 10 некэшированных МБ, загружаемых каждый раз, практически невозможно управлять для многих мобильных пользователей.

Внезапно, самый важный пункт в head документа:

 <meta name="viewport" content="width=device-width">

Эта строка гарантирует отсутствие 300-миллисекундной задержки касания в телефонных браузерах на основе Chromium или Firefox, но по-прежнему позволяет пользователю увеличивать масштаб, сводя пальцы (удобно для специальных возможностей).

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

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

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

Поищите или расспросите своих друзей или родственников о старом смартфоне. Обычно я одалживаю Nexus 4 своего партнера.

Подключите телефон к компьютеру и перейдите на страницу chrome://inspect/#devices . Это откроет окно проверки, которое вы можете использовать для проверки веб-страниц, запущенных на телефоне. Вы можете использовать профилирование и просматривать временную шкалу, чтобы найти источники низкой производительности, а затем оптимизировать их на основе реального базового устройства.

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

Если написание производительных анимаций является для вас сложной задачей, многие библиотеки справятся с этой задачей. Мой фаворит — GreenSock, который очень хорошо справляется с сенсорными взаимодействиями, такими как перетаскивание элементов, и может делать очень причудливую анимацию и анимацию.

Всплывающие уведомления

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

Убедитесь, что ваши push-уведомления релевантны пользователю для событий, происходящих в данный момент. Не тратьте их время на то, что можно сделать позже. То, о чем вы их уведомляете, должно требовать от них действий (ответ кому-то или посещение мероприятия). Кроме того, не отправляйте уведомление, если ваше веб-приложение видно или находится в фокусе.

При взаимодействии с уведомлением пользователь должен перейти на страницу, которая работает в автономном режиме. Уведомления могут оставаться непрочитанными; с ними можно взаимодействовать, когда у пользователя нет сетевого подключения. Пользователь будет разочарован, если ваше push-уведомление откажется работать после того, как они попытаются взаимодействовать с ним.

Самый лучший опыт для push-уведомлений освобождает пользователя от необходимости открывать ваше веб-приложение вообще ! «У вас есть новое сообщение» бесполезно и так же раздражает, как кликбейтный заголовок. Отображение сообщения и отправителя.

Кнопки действий в уведомлении могут предоставлять интерактивные подсказки, которые не обязательно открывают браузер («Мне нравится этот пост», «Ответить да», «Ответить нет», «Напомнить мне позже»). Они обслуживают пользователя на своих условиях, удерживают его внимание и минимизируют затраты времени.

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

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

API push-уведомлений требует сервисного работника. Поскольку можно получать push-уведомления, когда ни одна вкладка браузера не открыта, сервисный работник будет обрабатывать запрос уведомления в фоновом потоке. Он может выполнять асинхронные операции, такие как выполнение запроса на выборку к вашему API перед отображением уведомления пользователю.

Чтобы создать push-уведомление, сделайте запрос к конечной точке, предоставленной производителем браузера. Для браузеров на базе Chromium (Opera, Samsung и Chrome) это Firebase Cloud Messaging. Эти браузеры также ведут себя немного нестандартно.

Подробности можно узнать, запросив разрешение на push-уведомление:

 serviceWorkerRegistration .pushManager .subscribe({ // Required parameter as receiving updates // but not displaying a message is not supported everywhere. userVisibleOnly: true }) .then(function(subscription) { return sendSubscriptionToServer(subscription); })

Подписка представляет собой объект, который выглядит следующим образом:

 { "endpoint": "https://example.com/some/uuid" }

В приведенном выше примере uuid однозначно идентифицирует используемый в данный момент браузер.

Примечание. Браузеры на основе Chromium ведут себя немного по-другому. Вам понадобится идентификатор приложения Firebase, который необходимо ввести в файл манифеста вашего веб-приложения (например, "gcm_sender_id": "90157766285" ).

Кроме того, конечная точка не будет работать в заданном формате. Ваш сервер должен немного изменить его, чтобы заставить его работать. Это должен быть запрос POST с вашим ключом API в head и uuid в body .

При отправке push-уведомления возможна отправка данных в теле самого push-уведомления. Это сложно и включает в себя шифрование содержимого в запросе API. Пакет web-push для Node.js может справиться с этим, но я не предпочитаю его.

Можно выполнять асинхронные запросы после получения уведомления, поэтому я предпочитаю отправлять минимальное уведомление, известное как «щекотка», клиенту, а затем сервисный работник делает запрос на выборку к моему API, чтобы получить любой Недавние обновления.

Примечание . Service Worker может быть закрыт браузером в любой момент. Функция event.waitUntil в push-событии говорит сервис-воркеру не закрываться, пока событие не завершится.

 self.addEventListener('push', function(event) { event.waitUntil( // Makes API request, returns Promise getMessageDetails() .then(function (details) { self.registration.showNotification( details.title, { body: details.message, icon: '/my-app-logo-192x192.png' }) }) ); });

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

Не игнорируйте сильные стороны Интернета

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

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

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

Все сводится к следующему: предоставьте способы поделиться своим приложением с помощью кнопок общего доступа или кнопки для отображения URL-адреса.

Как насчет браузеров, которые не поддерживают прогрессивные веб-приложения?

Проверьте Готов ли ServiceWorker? для текущего состояния поддержки сервис-воркеров в разных браузерах.

Возможно, вы заметили, что во всем этом я упоминал Chrome, Firefox и Edge, но не упоминал Safari. Apple представила миру веб-приложения и проявила интерес к прогрессивным веб-приложениям, но по-прежнему не поддерживает сервис-воркеров или манифест веб-приложений. Что ты можешь сделать?

Можно создать автономный веб-сайт для Safari с AppCache, но это сложно и чревато странными пограничными случаями, которые могут сломать страницу или сделать ее постоянно устаревшей после первой загрузки.

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

Наконец, мы можем ожидать множество захватывающих разработок в мире веб-приложений с усилением поддержки лежащих в их основе технологий и появлением новых функций на веб-платформе, таких как Web Bluetooth API для взаимодействия с оборудованием, WebVR для виртуальной реальности. реальность и WebGL 2 для высокоскоростных игр. Сейчас самое время изучить возможности веб-приложений и принять участие в формировании будущего Интернета.

Ссылки

Другие статьи о прогрессивных веб-приложениях

• «Еще один блог о состоянии и будущем прогрессивных веб-приложений», Ада Роуз Эдвардс.

Ссылки, указанные в статье

• «Форма магазина приложений», Чарльз Перри
• Помощники сервисного работника, Google, GitHub
• Набор инструментов сервисного работника, Google, GitHub
• «Задержка клика 300 миллисекунд и iOS 8», TJ VanToll
• «Лучшие практики кэширования и ошибки максимального возраста», Джейк Арчибальд.