Что влияет на скорость, стоимость и сроки внедрения PWA на Magento

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Рад знакомству с аудиторией DOU! Я — Артур Потульный, CEO Perspective Studio. Пишу о разработке на Magento и проблемах e-commerce. Хочу, чтобы мой блог помог разработчикам максимально эффективно решать задачи бизнеса. В статье делюсь опытом разработки Progressive Web App на Magento. Ни один опыт не проходит без ошибок, поэтому расскажу про:

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

Для справки: что такое PWA и чем она хороша

На сегодня более 70% e-commerce веб-трафика приходится на мобильные устройства. Прогрессивное веб-приложение создано специально для «мобильных» клиентов, сочетает в себе функции сайта и нативного приложения. Что PWA значит для пользователя: он может открыть сайт в мобильном браузере и сохранить его как приложение на телефоне, минуя Google App или App Store. Пользователь может и не устанавливать. В любом случае, сайт будет визуально выглядеть как приложение, открываясь на весь экран. Также сайт получает дополнительные плюшки: возможность рассылать push-уведомления и работать без доступа к интернету.

А теперь о проблемах, которые возникли в ходе разработки PWA, и которые очень важно проговорить с клиентом.

Проблема #1

Скорее всего, сайт как приложение пользователь не установит. Да, если речь идет о повторных заказах суши, почтовых услугах или о покупках на маркет-плейсе, то есть высокая вероятность, что приложение таки установят. Но в остальных случаях — нет. Согласно последнему исследованию в США 88% опрошенных готовы скачать до 38 приложений, и лишь 10% согласны видеть больше иконок на своем телефоне.

Проблема #2

Сайты на PWA не загружаются за 1-1,5 секунды. Но скорость — это основной профит, который ожидает получить клиент. Практика показывает, что на PWA нет ожидаемых полторы секунды на загрузку. Почему так происходит? На чистых демо проектах, как правило, используется простой функционал. Сайты для среднего и крупного бизнеса всегда требуют дополнительный. Это и затормаживает работу сайта.

Но заказчик хочет, чтобы трекер загрузки страницы показывал не больше 1,5 секунды. Как следствие разработчики вынуждены идти на хитрости — многие данные воспроизводить используя ajax. Это значит, что важные блоки (меню, картинка товара, название, цена) — сразу появляются на странице загрузки, а остальные позже. Так можно выиграть доли секунды. Но так или иначе сложная функциональность сайта коррелирует со скоростью его загрузки всегда.

Проблема #3

Сделать сайт на PWA дольше и дороже чем многие думают. По нашему опыту, разработка на PWA в три раза дольше, чем на традиционной Magento. Причина — новизна самой технологии.

Есть базовый коробочный функционал PWA. Он подходит для малого бизнеса. Но, скорее всего, малый бизнес и не требует перехода на PWA, ведь это дорогостоящая технология. В свою очередь, у крупного бизнеса есть потребность широкого функционала, который пока что не разработан для PWA. Дополнительные фичи — это кастомная разработка. А кастомная разработка на PWA требует не мало времени и денег.

К примеру, в «коробке» PWA нет возможности использовать special price для продукта. Казалось бы, это базовая вещь для екоммерс, а ее нет. Также в коробке не предусмотрено bundle products — комплекты товаров. Например, кровать и две тумбочки — дешевле купить вместе, но можно купить и по отдельности. В итоге, эти функции мы разрабатывали специально для заказчика.

Хорошая новость в том, что PWA регулярно обновляется. Мы уже полгода разрабатываем сайт для Tefal, и уже трижды обновляли продукт. К примеру, в начале разработки PWA на Magento не поддерживала страницу сравнения, но сейчас она есть.

Иногда на сроки влияет и специфика обновлений PWA приложения. Сайты на PWA понятным для всех нажатием F5 не обновляются. Разработчику нужно написать специальный функционал, который проверяет нет ли на сервере обновлений, если они есть, то запускает обновление приложения. Для разработчиков это дополнительный пласт работы. Например, если приложение работает офлайн, то нужно время от времени проверять, не поменялись ли цены и наличие товаров. Или не держать эти данные в офлайне и подгружать в реальном времени с сервера. Нужно понимать, какие данные нужно обновлять чаще, а какие — реже.

Кастомной работы на PWA достаточно много. Я это вижу в своих проектах, и слышу от разных заказчиков, кто уже работал с PWA. Допустим, в интернет-магазина есть акция к выходу нового айфона и нужно срочно сделать особую акционную страницу. Если создавать на обычной Magento, то внедрение займет день-два. На PWA оперативно сделать не получится. Больше технологий задействовано в разработке.

Выводы

Резюмируя, можно задать себе вопрос: а зачем тогда переходить на PWA, если это требует таких затрат, много кастомной разработки и все равно не дает 1,5 сек? Может проще обычную Magento хорошенько оптимизировать?

Во-первых, PWA таки ускорит работу сайта — это гарантированно. Выиграть одну секунду, или даже доли секунды — это то, за что борется современный екоммерс каждый день. Скорость очень важна для customer experience и как следствие конверсии. PWA близок к нативным технологиям, подтягивает с телефона пользователя информацию — локацию, имя, фамилию. Приложение может взять эти данные, чтобы пользователь только частично заполнял checkout. Как результат — возможность делать заказ в один клик или даже без интернет связи.

Во вторых, PWA — это headless архитектура. Независимая работа фронтенда и бэкенда позволяет осуществить технические работы на сайте более безболезненно. Вы можете даже заменить бэкенд движок, а пользователи не ощутят подмены.

В-третьих, специфика обновлений на PWA в том, что в отличие от нативных приложений, согласование с Google Play или Apple Store не нужно. С типичным мобильным приложением для запуска обновления нужно пройти техническую проверку Google Play или Apple Store. На этот апрув уходят дни, а то и недели. Плюс часто возвращают обновление обратно на доработку.

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

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
К примеру, в «коробке» PWA нет возможности использовать special price для продукта. Казалось бы, это базовая вещь для екоммерс, а ее нет. Также в коробке не предусмотрено bundle products — комплекты товаров.

А какое PWA приложение вы использовали? Hyva?

Вы не рассматривали PWA Studio, ScandiPWA, Vue storefront?

ScandiPWA, Vue storefront — из коробки есть спешал прайс и бандл.
PWA Studio — всегда отстаёт, в Роад мап на 21 год есть Спешал прайс и бандлы.

1) Пробовали и ScandiPWA и Vue storefront, остановились PWA Studio т.к. больше верим в ее долгосрочность + на нее больше ориентируются другие вендоры.
+ по нашим ощущениям реакт более распространенный/комплексный и онбординг на него проще чем на vue
2) да PWA Studio существенно остает, но двигается уверенно с регулярными обновлениями, и например спешал прайс уже готов из коробки в последних версиях (с бандлами пока туго). Важно просто правильно донести клиенету что «всё будет», например мы начинали проект Мае 2020 и сразу договорились с клиентом что ЛК пилить не будем т.к. в августе 2020 будет обнова с ним, клиент окнул, лишний кастом не писали)

Рассматривали ли статический сайт на gatsby.js (например) вместо PWA? Как верно заметили, редко кто приложение магазина поставит на телефон

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

Во вторых, PWA — это headless архитектура

Толку с этого мало, так как для ускорения загрузки, надо по максимуму уменьшить js бандл. А для этого нужна не headless архитектура, а полностью избавиться от SPA фреймворков и перейти на старый добрый vanilla JS или же использовать библиотеки по типу alphine.js или StimulusJS. Ну и так же, необходимо прийти к определенному консенсусу с маркетологами, чтобы определить какие скрипты им точно нужны, а какие не очень, так как это тоже солидная статья расходов в плане первой загрузки.

локацию

Для этого есть Geolocation API — PWA тут никак не связан.

и перейти на старый добрый vanilla JS или же использовать библиотеки по типу alphine.js или StimulusJS.

А есть примеры таких переходов/использований? По моему опыту сложность разработки в таком случае растет по экспоненте и очень сложно держать большие проекты под контролем.

Мы в Javarush переводили контентную часть нашего сайта на svelte/sapper . Результат можно посмотреть вот тут к примеру developers.google.com/...​-i-peregruzka&tab=desktop . На ангуляре такая же страничка имела оба показателя (мобайл, десктоп) в районе красного уровня. Потом мы конечно добавили кеширование при ССР, но в целом всеравно немного не то.

svelte/sapper не рекомендую, так как мне они сыроватыми кажутся для прода.

сложность разработки

Скажем так, если делать изначально весь сайт так как предлагает например hotwire.dev , то сложно будет даже ниже, я думаю. А вот если у вас SPA, но вы решили что нужны хорошие метрики загрузки, вот тут начинаются танцы с бубном.

мы пробовали фронт на Hyvä (alpine js) вот демка demo.hyva.io/men.html
тоже пейдж спид 90+

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

А які недоліки виявили в роботі з Hyva?

Приветствую)
1) это новый фронт, как следствие большинство привычных фронтовых модулей не станет.. нужно или писать самим конектор или выбирать из уже совместимых (но радует что список пополняется) gitlab.hyva.io/...​acker?page=2&state=opened
2) это новая js бибилиотека для наших фронтов, как следствие кост для заказчика

Отказываться от SPA-фреймворков это скорее ошибка. Если речь о 40кб реакта в бандле, то можно взять преакт (хотя в целом это большого смысла не имеет).

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

Проблема в том, что на практике одним реактом сыт не будешь и в конце концов будет что-то такое react-redux.realworld.io/#/?_k=sihzmb Почти 200 килобайт, чтобы просто отрендерить список карточек. Даже бротли сжатие не спасает, как видно на примере.

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

У dev.to был интересный опыт построения их сайта — web.dev/...​-ux-with-service-workers

для сайтов можно вполне обойтись без редакса

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

redux — часто оверхед для подобных задач. Нужно просто выбирать инструменты правильно

Можно где-то посмотреть на результат?

на результат чего?

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

Мы же вроде бы об этом говорили.

к сожалению, клиентские проекты не могу разглашать

Підписатись на коментарі