PWA для электронной коммерции - это революция, подарок, который все давно ждали. Технология, которая быстро генерирует контент и доставляет его пользователю, дает возможность дешевого масштабирования, безопасна, удобна и открывает новые горизонты для роста бизнеса обречена на успех в области, для которой это является ключевыми показателями эффективности. Неудивительно, что все больше и больше брендов используют эту технологию, чтобы увеличить свой доход и повысить качество обслуживания своих клиентов.
Использование PWA в ecommerce по своей сути провозглашает начало эры «безголового подхода электронной коммерции», когда используются две платформы - одна для обработки так называемого «презентационного слоя», а другая — для поддержки требуемой функциональности электронной коммерции. Слой презентации относится ко всем тем функциям, которые не связаны с онлайн-продажами, таким как создание контента и управление им. Звучит необычно и, казалось бы, подрывает всю идеологию развития ecomm платформ, сложившуюся за последние несколько лет, но этот подход дает неоспоримые преимущества: скорость, удобство, безопасность, масштабируемость и гибкость.
Компаниям, которым необходимо постоянно исправлять, дополнять, искать замену устаревшим системам – затрачивая миллионы и теряя ценное время выхода на рынок – должны рассматривать «безголовый подход» как реальную альтернативу традиционным платформам электронной торговли, которые предоставляют все функциональные возможности веб-сайта и инфраструктуру электронной торговли в одном решении.
Очевидно, что, когда речь идет об электронной коммерции, единого универсального решения не существует и многое зависит от особенностей проекта, номенклатуры, функциональности и целевых показателей которых можно достигать разными методами и платформами электронной торговли. Так, например, сегодня существуют PWA практически для всех известных платформ:
— Prestashop PWA;
— PWA WebKul для Joomla;
— PWA для Drupal;
— OpenCart PWA;
— WooCommerce PWA;
— CS-Cart PWA.
Но когда речь заходит об Enterprise уровне решений, на рынке которых одним из лидеров является Magento можно сделать предположение, что заложенный в платформе функционал и возможности с лихвой покрывают все потребности. Однако это совсем не так и Magento, в частности, является одной из лучших платформ для «безголового подхода»
Vue или React?
Фронтенд — одно из наиболее динамично развивающихся направлений современной разработки. Неудивительно, что он оброс множеством инструментов, библиотек и фреймворков, призванных помочь в работе. В мире JavaScript, к примеру, новые фреймворки и библиотеки появляются чуть ли не каждый день. На самом деле, это практически непрерывный процесс, в ходе которого фавориты меняются буквально каждые несколько месяцев. Однако в случае PWA для Magento речь может идти о безоговорочных лидерах - Vue.js и React.
Vue.js создан бывшим сотрудником Google, Эваном Ю. Его целью было разработать платформу, объединяющую лучшие функции уже существующих фреймворков.
React — это JavaScript-библиотека, которую создал технологический гигант - Facebook. Одной из основных причин создания React было желание компании улучшить механизмы формирования интерфейсов. Библиотека React известна как мощное средство для создания динамических и интерактивных пользовательских интерфейсов.
Согласно статистики Node Package Manager, React является лидером по популярности среди фреймворков JavaScript, в то время как Vue.js — немного легче и как следствие должен быть чуть-чуть быстрее. Однако эти различия весьма условны так как Обе платформы популярны, и позволяют быстро развиваться. Суть в том, что они ведут себя одинаково, решают одни и те же проблемы, предполагают одинаковый уровень производительности и так далее. Они оба:
— используют Virtual DOM;
— предоставляют реактивность и компонентную структуру;
— фокусируются на корневой библиотеке, вынося прочие вопросы, такие как роутинг или управление глобальным состоянием приложения, в дополнительные библиотеки.
Основные же различия между ними заключено в определении: Vue.js является более высокоуровневым фреймфорком, использует шаблоны с декларативным рендерингом и имеет более низкую точку входа с точки зрения наличия опыта и знаний, React же является JavaScript библиотекой, использующей JSX — расширение JS, позволяющее использовать в нем HTML. Это означает, что React требует более сложных реализаций даже для простых задач, а также больше времени для разработки сложного компонента.
Требовательность к квалификации разработчиков на React открывает еще одно из его самых значимых преимуществ - гибкость. Поскольку он не является полноценным фреймворком, то разработчики могут не работать в заданных шаблонах, а добавлять библиотеки и искать наилучшие решения для существующих задач формируя тем самым независимость от обновлений версий фреймворка, которые неминуемо потребуют обновление кода и как следствие дополнительных финансовых вложений.
Vue, в отличие от React, даёт разработчику более обширный набор стандартных инструментов, позволяющих решать те же задачи, которые в экосистеме React обычно решают с использованием сторонних библиотек.
Vue и React лежат в основе наиболее известных «каркасов прогрессивных веб-приложений» для Magento:
— Vue Storefront – бесплатный каркас с открытым исходным кодом, подходящий ко многим CMS;
— Magento PWA Studio – пожалуй первое нативное PWA решение поддерживаемое Magento;
— FrontCommerce;
— DEITY.
Magento PWA Studio
Предлагаемый технический стек: React, Node.js, Webpack, Redux, GraphQL Apollo, Jest, StoryBook.
Неоспоримым преимуществом является то, что Magento PWA Studio является нативным решением и поддерживается Adobe, но стоит помнить, что это относительно новый инструмент, который находится в разработке с 2017 года и с точки зрения функциональности многое еще не учтено. Процесс был разделен на несколько этапов и в текущий момент Magento PWA Studio все еще находится на ранней стадии развития.
Magento PWA Studio следует примерно той же схеме релизов, что и Magento 2 и это, с одной стороны, безусловно, плюс, потому что Studio всегда будет соответствовать новым разработкам Magento 2 и архитектурным изменениям. С другой стороны, релизы Magento 2 движутся в стабильном, но медленном темпе, и это нужно учитывать в разработке если принято решение использовать именно это решение.
Резюме: поскольку Studio отлично взаимодействует с Magento 2, это во многом оптимальный выбор для начала работы с PWA. Studio дает творческую свободу и полный контроль над кодом и модулями. Это отличный инструмент, когда Magento команда хочет придерживаться тех технологий, которые им удобны и которым они привыкли.
DEITY
Предлагаемый технический стек: Node.js, React.js, Webpack + Babel, Apollo GraphQL, Koa, Jest.
DEITY Falcon на базе React вышел с открытым исходным кодом осенью 2018 года. Обнародование произошло после года закрытого тестирования и внедрения нескольких рабочих проектов. Еще до релиза эта команда разработчиков выполнила ряд успешных реализаций: модульная касса без головы, полный интернет-магазин и блог. Помимо этих реализаций, инструмент получил большое обновление в 2018 году, когда DEITY добавил множество функций, запрошенных сообществом.
В этом решении реализован достаточно функциональный редактор тем, который позволяет адаптировать стандартную тему PWA к своему магазину, не требуя огромного количества технических знаний.
Это решение может приобрести много последователей поскольку предоставляет достаточный уровень свободы и скорость внедрения на стандартном функционале.
Резюме: DEITY Falcon — это интересный инструмент, второй по привлекательности после Magento Studio, который предлагает совершенно другой подход к разработке PWA. Основное внимание в нем уделяется интересам разработчиков и веб-мастеров, а не пользовательскому опыту и скорости, что резко контрастирует с другими инструментами на рынке.
Front-Commerce
Предлагаемый технический стек: React, Node.js, Algolia API, GraphQL, Jest, Pact, StoryBook, ShipperHQ
Команда разработчиков Front-Commerce начала свой проект в 2015 году. Проект появился как инструмент, облегчающий ежедневную внутреннюю работу команды разработчиков. Front-Commerce была запущена благодаря появлению компонентов на основе компонентов и таких инструментов, как React, GraphQL, Falcor, а также различных библиотек шаблонов.
Первый релиз Front-Commerce состоялся в октябре 2016 года. Тогда же были приняты GraphQL и Apollo. Февраль 2018 года ознаменовался первым крупным публичным выпуском, и с тех пор FC набрал обороты и стал заметем в сообществе разработчиков.
Как и другие решения PWA, Front-Commerce все еще находится в стадии разработки. Но уже прямо сейчас позволяет реализовать: каталог, checkout, доставку, прием платежей, deployments, кэширование, протоколирование.
Резюме: Front-Commerce претендует на звание самой зрелой «темы PWA для электронной коммерции» в отрасли. Его функциональность действительно достойна уважения. С помощью Front-Commerce можно построить живой магазин PWA, в котором можно многое реализовать из того, что ожидается от обычного шоппинга Magento 2.
Vue Storefront
Предлагаемый технический стек: Vue.js и Vue.js 2.0, Node.js, Webpack, Express, Docker, GraphQL, Pimcore, Babel.
Пройдя через маркетинговый ошибки, Vue Storefront заявляет, что является самым большим и самым функциональным инструментом PWA на рынке. Storefront является единственным решением PWA для Magento, которое использует Vue.js вместо React. Этот выбор фреймворка, в случае его использования для кастомизированных ecomm решений вынудит владельцев магазинов и разработчиков проводить доработки как после релизов Magento, так и после релизов Vue Storefront, которых немало, и приведет к дополнительным инвестициям.
После появления Magento PWA Studio и DEITY, Vue Storefront предлагает несколько вариантов интеграции API с различными платформами электронной коммерции и поддерживает функцию мультисклад с версии Magento 2.3, что упрощает управление запасами без необходимости разработки/установки стороннего расширения.
Резюме: Vue Storefront действительно обладает активным сообществом, большим функционалом, еще не реализованном в других решениях и более законченным, но функционирует больше как пакетная сборка, похожая на то, чем DEITY стремится стать для разработчиков PWA на React. Основное внимание уделяется предоставлению полного стандартизованного функционала, что дает разработчикам гораздо более согласованный набор продуктов, чем свободный набор инструментов, таких как в Magento PWA Studio. Кастомизация функционала приведет к дополнительным инвестициям на дистанции в 1-3 года.
Резюмируя вышесказанное, совершенно очевидно, что выбор труден. И сравнивать что лучше Vue или React будет не совсем правильным подходом к выбору PWA решения, поскольку приведет к личным предпочтениям и квалификации разработчиков. Следует помнить, что веб-интерфейс — это просто маленький кусочек в большой головоломке, а PWA, по сути, не просто язык, это стек, который определит будущее проекта электронной торговли, подходы к созданию кода и бюджетирования. Выбор PWA неразрывно связан с выбором видения «провайдера», обеспечивающего «безголовую» архитектуру для построения PWA, на будущее собственно архитектуры, на будущее Magento, на видение альтернативных платформ электронной коммерции и способы работы с расширениями (расширения Magento, компоненты Vue или React, их собственная архитектура расширений).
Magento PWA Studio vs Mygento PWA
На наш взгляд, Magento PWA Studio - оптимальное решение для большинства PWA магазинов на Magento. Это многообещающий набор инструментов, созданный сообществом Magento, и предназначенный для решения задач, характерных для разработки Magento PWA.
Studio является большой платформой для совместной работы других компаний, которые хотели бы активно участвовать в сообществе Magento, что, в свою очередь, будет способствовать появлению новых решений для создания Magento PWA и в конечном счете сделает Magento PWA Studio лидером среди подобных решений.
Тем не менее Magento PWA Studio не является законченным решением и много полезного и необходимого нам функционала, который мы используем каждый день в проектах наших клиентов или хотели бы в них использовать, в нем не реализовано. Так, например, в PWA Studio архитектурно заложено расширение функционала разработчиками, но пока что не предоставлена работающая модель такого расширения. Большое количество динамического функционала «зашито» прямо в код и не подгружается из платформы по требованию, а стандартная структура проекта не подразумевает возможности добиться эффективного кэширования.
Кроме того, мы хотели построить решение, которое бы поддерживало уровень сложности и отточенности UX на современных проектах электронной торговли требующих более мощных инструментов, чем прямое использование нативного DOM API и SSR (server side rendering).
Для того, чтобы понять, что мы хотели изменить, необходимо ознакомиться с рабочим процессом Magento, а также окунуться в базовые принципы работе браузеров:
Как работает фронтэнд Magento 2
При первом открытии страницы браузер кэширует все свои статические ресурсы: скрипты, стили и использует разметку, возвращаемую с сервера, для отображения содержимого страницы. В следующий раз, когда вы посещаете тот же веб-сайт, браузер загружает только HTML и повторно использует кэшированные ресурсы браузера для отображения контента. Это означает, что для отображения страницы требуется запрос HTML-кода с сервера. Содержимое HTML кэшируется на сервере. Это в свою очередь означает, что для одной и той же страницы сервер будет генерировать HTML только один раз. Генерация HTML на сервере называется SSR. Magento 2 позволяет автоматически по требованию очищать определенные кэши HTML-страниц в том случае, когда информация об объекте была изменена. Такой механизм называется «Full Page Cache». Этот подход в обычной Magento очень гибкий, но чересчур масштабный и сложный для изучения.
В чем проблема такого решения?
Несмотря на изменение только одного информационного объекта (например, имени продукта), сервер сбрасывает и после этого заново генерирует все HTML-страницы, на которых этот объект использовался. Это вынуждает сервер снова загружать объекты, даже если они не были изменены. Именно по причине того, что Magento 2 выполняет много ненужных запросов для неизмененных объектов, она является очень ресурсоемкой платформой. И это ее свойство крайне губительно для PWA.
Как заставить Magento 2 не загружать ненужные объекты заново?
Необходимо запрашивать информацию об объектах на странице отдельно. Это невозможно сделать с использованием исключительно HTML-кода, созданного на сервере, поскольку после его кэширования информация не может быть разделена. Это означает, что мы не можем добиться эффективного кэширования, только за счет SSR, даже используя механизм «Full Page Cache». Чтобы не загружать весь HTML заново, мы должны обращаться к серверу за отдельными объектами. Эти объекты могут быть представлены в разных форматах, например, XML, JSON. Чтобы обмениваться информацией, сервер должен иметь API (например, REST API (JSON), SOAP API (XML), GraphQL (JSON)). С помощью методологии AJAX информация извлекается с сервера, а затем передается алгоритму в браузере, который генерирует HTML. Можно использовать несколько отдельных запросов AJAX, и каждый отдельно кэшировать на сервере. Когда это делается для всех данных на странице, то такой подход называется рендерингом на стороне клиента (CSR).
Можно ли реализовать CSR в Magento 2?
Да. Magento версии 2.3.x поддерживает GraphQL, но тем не менее, по умолчанию тема Magento по-прежнему, в основном, использует SSR. При формировании заказа и в корзине используются запросы AJAX, которые оптимизируют и улучшают работу пользователей на этих страницах. Чтобы реализовать полную CSR, нам потребуется полностью переработать способ, который Magento 2 использует для рендеринга. Мы должны избавиться от системы макетов и реализовать решение, которое будет способно работать в браузере, делать запросы к API Magento 2 и отображать информацию в формате HTML. Проблема как такова не в регенерации html заново, а в большом объеме кода и количества блоков, каждый из которых загружает большой объем данных, иногда повторно, и приведения этого всего в вид, удобный для рендера, плюс сам рендер. В PWA рендер идет по готовым кэшированным данным, никаких повторных подтягиваний данных и много переиспользования.
Reason to Believe
Для того чтобы проверить на сколько мы были правы в своем стремлении идти самостоятельным путем в создании PWA решения для Magento (Mygento PWA), мы решили провести небольшое тестирование, в котором бы приняли участие проекты, созданные на Vue storefront и Magento PWA Studio с “безголовой” Magento, а также проект созданный в рамках нашего видения PWA инфраструктуры и сравнить performance этих интернет-магазинов при первом заходе.
Для эксперимента мы выбрали два проекта использующих Vue от различных команд разработчиков – интернет-магазин сети аптек Ригла на Vue.js (rigla.ru – проект X), служба онлайн-доставки мирового гиганта Danone на Vue Storefront (danonedirect.ru – проект Y), интернет-магазин на нативной Magento 1 - официальный интернет-магазин бренда Lancome в России (lancome.ru – проект R) и созданный в рамках нашего видения PWA проект – beauty retailer Salon Secret (shop.salonsecret.ru – проект Z).
1. Объем js (который закачается браузером). Именно эти данные браузер закачивает из сервера и чем меньше количество килобайт – тем лучше.
2. Объем распакованного js, который браузер будет обрабатывать. Чем больше килобайт JS – тем дольше браузер его будет обрабатывать, и соответственно, для этого потребуется больше вычислительных мощностей.
3. Объем стилей css, которые закачиваются браузером и чем меньше количество килобайт – тем лучше.
4. Объем распакованных стилей, которые браузер будет обрабатывать. Чем больше килобайт JS – тем дольше браузер его будет обрабатывать, и соответственно, для этого потребуется больше вычислительных мощностей.
5. Аудит Lighthouse performance показывает, насколько веб-сайт соответствует стандартам Google и оценивает производительность сайта. Чем больше баллов показывает аудит, тем больше соответствие.
6. Аудит Lighthouse accessibility. В широком смысле, когда говорится, что сайт доступен, имеется ввиду, что контент сайта доступен и его функционалом может воспользоваться пользователь. Чем больше баллов показывает аудит, тем выше доступность сайта.
7. Аудит Lighthouse best practice. Оценивается применение «правильных» подходов к разработке сайта и инфраструктуры. Чем больше баллов показывает аудит, тем выше его соответствие.
8. Аудит Lighthouse seo. Оценивается, насколько сайт оптимизирован для поисковых систем. Чем больше баллов показывает аудит, тем выше его соответствие.
Аудит Google Lighthouse не является панацеей определения скорости веб-страниц. Но данный аудит в целом может достоверно показать картину производительности сайта.
9. Аудит Webpagetest Document Complete показывает среднее количество секунд, которое понадобилось браузеру, чтобы полностью загрузить HTML, построить DOM-дерево и загрузить ресурсы для видимой части экрана (сайтом можно начать пользоваться).
10. Аудит Webpagetest Fully Loaded. Аудит показывает сколько секунд в среднем проходит, прежде чем все сторонние js/сервисы загрузятся и выполнятся.
11. Аудит Webpagetest Speed index показывает среднее время в секундах, прошедшее от момента захода на сайт до показа видимой части экрана сайта. Грубо говоря – через сколько времени у вместо фона/белого экрана браузера, визуально покажется сайт.
12. Среднее время обработки добавления товара в корзину показывает время в миллисекундах, необходимое для добавления товара в корзину. За добавление товара в корзину отвечает backend, время добавления напрямую зависит от количества активных маркетинговых правил для корзины.
13. Время ответа сервера на получение главной страницы сайта отражает время необходимое серверу для того, чтобы сгенерировать и отдать HTML код. Чем меньше миллисекунд на это потребуется, тем лучше.
14. Вес HTML главной страницы сайта отражает какой объем данных требуется скачать HTML браузеру и чем меньше количество килобайт – тем лучше.
К примеру, значение - 2 kb для магазина X объясняется тем, что в документе размещены только мета-тэги страницы, ссылки на основной скрипт страницы и сторонние скрипты
15. Замеры performance товарных страниц на тестовом окружении: Chrome 83, Windows 10, Core i5 7400, 32 GB RAM, 1 Gbit internet
В таблице представлено время, которое потребовалось процессору и браузеру, чтобы показать пользователю страницу карточки товара. Чем меньше времени нужно на каждый этап – тем лучше.
Loading – время для загрузки в браузер данных страницы;
Scripting – время исполнения всех JS скриптов, которые есть на странице;
Rendering – время генерации DOM дерева страницы для отображения;
Painting – время пересчета и применения CSS стилей для отображения клиенту;
System – время на сторонние процессы на странице (запросы в кэш, системные шрифты, service worker и прочее).
Суммарный график времени:
16. Объем оперативной памяти, требуемой для загрузки карточки товара (Мб). Чем меньше - тем лучше.
Сводная таблица, цветовое форматирование: красное (медленное) ➔ зеленое (быстрое):
Резюме:
По результатам тестов, решения, построенные с использованием Vue.js, показали наихудший результат. Скорее всего это связано с особенностями разработанной темы и её “удельным весом”. Однако, вполне возможно, что квалификация разработчиков сыграла не последнюю роль (как указывалось ранее порог входа во Vue.js с точки зрения опыта и квалификации гораздо ниже, чем в React). Решение, построенное на нативном Magento 1, в целом, показало ожидаемый результат, а наше решение Mygento PWA оказалось выше всяческих похвал.
В мире электронной коммерции необходимо быть в тренде, чтобы оперативно реагировать на появление новых технологий и вызовы рынка. Progressive Web Applications наилучшим образом подходит для обеспечения клиентам быстрого, безопасного и беспроблемного опыт совершения покупок, а для электронной коммерции, PWA - это идеальное решение, независимо от сферы, объемов и особенностей бизнеса. Главное, внимательно подойти к выбору решения и поставщика, и тогда успех будет не за горами.
