Возможно ли объединить PWA с AMP?

Если вы следили за веб-сообществом последние несколько месяцев, то наверняка слыхали о прогрессивных веб-приложениях (Progressive Web Apps или просто PWA).

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

Но несмотря на то, что новый сервис API позволяет вам кэшировать практически все признаки сайта при мгновенной ПОВТОРНОЙ загрузке, именно первое впечатление играет роль, когда вы с кем-то знакомитесь. Если первая загрузка занимает больше, чем 3 секунды, то, как показывают исследования, по крайней мере 53% посетителей отпадут.

А 3 секунды, давайте быть реалистами, это уже ничего такая заявочка. С нашим то мобильным интернетом, вы можете остаться с лимитом загрузки в 1 секунду!

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

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

AMP спешат на помощь

Одно из самых значимых преимуществ веб-сайта - это практически беспрепятственный вход - никакого шага установки, быстрая загрузка…

Чтобы действительно выиграть от такой возможности все, что нужно - это реально быстро загружающийся сайт. А что нужно, чтобы сайт грузился безууууумно быстро? Определенная диета: никаких огромных картинок, никаких изощрений с рекламными блоками, и желательно без 100 000 строк Java скрипта - только чистый контент, пожалуйста-спасибо.

AMP, или Accelerated Mobile Pages в этом очень хороши. По сути, это их смысл жизни. Это как будто автопилот, который помогает вам не сойти с высокоскоростной трассы, придавая приоритет главному контенту на вашей странице. Создавая это строгое, четко структурированное пространство, AMP дают возможность платформам по типу Гугл приблизиться на шаг к той самой “мгновенной загрузке”, подгружая только самое главное.

Так что в итоге, AMP или PWA?

Чтобы сделать пользовательский экспириенс действительно ускоренным, то стоит обратить внимание на парочку ограничений, присущих AMP. Они не способны вам помочь, если вы нуждаетесь в высоко динамичном функционале, включающем в себя предоставление пуш-уведомлений, веб-платежей или чего либо, требующего дополнительного Java скрипта. Более того, поскольку страницы AMP обычно подаются из AMP кэша, вы не получаете те самые огромные преимущества прогрессивных мобильных приложений, которые работали бы с первого клика. С другой стороны, конечно, PWA никогда не будут такими молниеносно быстрыми, как AMP, так как для последних платформы могут легко и дешево “бронировать” место для такой страницы.

 

Ну так что же, AMP или прогрессивное веб приложение? Мгновенная оптимизированная загрузка или же характеристика самой продвинутой платформы?

А что, если существует способ это всё объединить…?

Идеальное путешествие пользователя

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

1. Пользователь находит ссылку вашего ресурса и кликает по ней.
2. Контент загружается практически моментально и посетитель от него в восторге.
3. Пользователя приглашают апгрейднуться до еще более шикарного уровня экспириенса.
4. Посетитель такой “Пффф… А почему, черт возьми, нет?!” и его сразу перенаправляет на страницы, похожие на приложение, где он имеет возможность прямо “не отходя от кассы” установить ярлык на домашнюю страничку.

 

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

Звучит слишком хорошо, чтобы быть правдой? Ну… а что, если мы попробуем соединить обе технологии, несмотря на то, что сперва они выглядят совершенно не связанными и решают разные проблемы?

Такой себе PWAMP и его разновидности

Чтобы получить моментально-загружаемое и автоматически-обновляемое счастье, необходимо все лишь смешать филигранную точность и скорость AMP с возможностями PWA одним (или несколькими) из представленных ниже способов:

• AMP как PWA

Когда вы можете пережить ограничения, представленные AMP

• AMP к PWA

Если вы хотите создать мягкий переход от одного к другому

• AMP в PWA

Когда вы хотите переиспользовать AMP, как источник данных для вашего PWA.

 

Давайте пройдемся по каждому из них отдельно.

AMP как PWA

Многим сайтам кроме AMP по сути, ничего больше и не надо. Сам сайт AMP (https://ampbyexample.com/), к примеру, является одновременно и AMP, и PWA. Когда посетитель заходит на сайт из Гугл, а потом кликает по другой ссылке на нем же, то его перекидывает из кэша AMP на оригинальный сайт. Ресурс все еще использует библиотеку AMP, но уже может взывать к расширенному функционалу.

Вы можете использовать эту технологию, чтобы получить оффлайн доступ к вашему AMP сайту так же, как и растягивать страницы, как только они подаются из оригинала, используя fetch event Service Worker-а и получая такой результат, какой захотите:

Этот метод позволит вам вводить скрипты и более сложный функционал вне рамок AMP.

AMP к PWA

Если того, что указано сверху, вам недостаточно и вы хотите кардинального PWA-эффекта от вашего контента, то можно использовать алгоритм посложнее:

• Весь контент страниц “листами” (то есть страницы с особым контентом, а не обзорные) публикуется в AMP, чтобы моментально подгружаться.
• Эти страницы используют особенный элемент AMP <amp-install-serviceworker> , чтобы “подогреть” кэш и обложку PWA, пока пользователь наслаждается вашим контентом.
• Когда посетитель кликает по другой ссылке на вашем сайте (к примеру, на призыве к действию), Service Worker перехватывает запрос и загружает PWA.

Подобного рода маршрут можно проложить в три простых шага, если вы уже знакомы с принципами работы Service Worker-a. Прежде всего, установите Service Worker на всех ваших AMP-страницах.

Затем, во время установки Service Worker-а кэшируейте все ресурсы, которые вам понадобятся для PWA:

Наконец, снова таки в Service Worker, поставьте PWA, вместо AMP в запросе навигации. (Пример внизу очень упрощенный)

Теперь, каждый раз, когда пользователь кликает по ссылке на странице из AMP кэша, Service Worker замечает запрос navigate, берет его на себя и предоставляет полностью функциональный и уже кэшированный PWA.

AMP в PWA

Ну что ж, теперь наш пользователь находится внутри PWA и каковы шансы того, что вы используете какую-то AJAX-овую навигацию и при этом подаете контент через JSON..? Конечно, может быть и такое. И подумайте, какая неразбериха происходит - теперь вам нужно два совершенно разных бэк энда - один для AMP-страниц, а второй - для API вашего прогрессивного веб-приложения.

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

А что, если мы могли бы существенно упростить бэк-энд, отбросив дополнительные JSON API и вместо этого еще раз использовав AMP, как формат данных для нашего PWA.

AMP-страницы можно с легкостью вписывать в другой сайт - библиотека AMP собирается и грузится только один раз для всего PWA.

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

1. PWA ворует любые навигационные клики.
2. Затем, оно посылает XMLHttpRequest, чтобы запросить соответствующие PWA.
3. Это отправляет контент в новые теневые каналы.
4. Тем временем, в библиотеку AMP отправляется сообщение “Эй, у меня тут для тебя новый документ - зацени!” (называется attachShadowDoc)

Благодаря этой технике, библиотека AMP собирается и грузится только один раз по всему PWA. Теперь, оно стало гораздо проще.

Последние мысли по теме

Не стоит и говорить о том, что это по правде прекрасная комбинация, которая выносит на первый план все самое лучшее:

• всегда быстрая работа, не смотря ни на что;
• один бэк и ничего лишнего;
• меньше итоговых затрат;
• меньше сложностей для клиента;

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