В начале этого года розничная компания, в которой я работаю (https://www.garbarino.com), решила создать PWA.

Для такого фаната веб-технологий, как я, это был великий момент - стать их частью. В Аргентине нет надежных мобильных подключений, наши клиенты могут не захотеть устанавливать собственное приложение, и, к счастью, 80% нашего мобильного трафика поступает из Chrome. Итак, давайте сделаем это! 💪

Ключевая цель

Чтобы улучшить работу на мобильных устройствах.

Настройка проекта

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

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

Мы задали себе несколько вопросов наподобие следующих (и я ожидаю ответить на все из них до конца статьи):

  • Какие показатели мы будем измерять, чтобы знать, насколько мы работаем лучше?
  • Наполнение дома каруселями товаров - лучший способ продавать больше? Думаю, нет, но в первой версии те же компоненты, что и в мобильном Интернете, и мы не могли сделать ничего другого. Деловое решение. 🤷
  • Следует ли нам использовать наши существующие веб-приложения и постепенно создавать их поверх? Или нам следует создать новое приложение? Поскольку нам нужен был новый дизайн и подход к SPA, мы выбрали второй вариант. Это подразумевает больше работы, но дает нам больше гибкости.
  • Какой модный фреймворк мы будем использовать? Vuejs? Реагировать? Preact? Мы выбрали реакцию, потому что у большего числа людей в компании есть предыдущий опыт в этом. Нам нравятся некоторые функции Vue, но мы довольны реакцией в любом случае. 👍

Технический подход

Я начал проект на основе серии замечательных сообщений, написанных Адди Османи: https://medium.com/@addyosmani/progressive-web-apps-with-react -js-part-i-Introduction-50679aef2b12

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

  • Базовая поддержка офлайн (пользовательский экран вместо даунзавра)
  • Поддержка Добавить на главный экран
  • Отрисовка на стороне сервера
  • SPA подход
  • Статические файлы кешируются
  • Разделение кода на основе маршрута
  • Те же URL-адреса, что и на обычном сайте
  • И впереди многое другое ...

Выбранный стек был:

  • Node.JS для сервера
  • React для интерфейса
  • И множество полезных библиотек, таких как material-ui

Проблемы проекта

Мы розничная компания. SEO - наш бог, поэтому подход SPA требует обязательного рендеринга на стороне сервера.

Выполнение SSR - это больше, чем просто сказать: мы используем response и node, оба являются JS. Что может потерпеть неудачу? Мы назвали это требование: темная сторона серверной части, и это должно стать заголовком доклада в будущем. Между тем, вы можете прочитать этот отличный пост, если хотите иметь представление: https://reactjsnews.com/isomorphic-react-in-real-life

Если вы пробовали SSR с реакцией, наверняка видели это сообщение не раз:

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

  • У нас есть ежедневные предложения с обратным отсчетом времени, которое осталось до каждого предложения. Если вы визуализируете обратный отсчет на сервере, когда он дойдет до клиента, оставшееся время будет другим (из-за сети), поэтому разметка будет другой. Решение - вычислить время после установки компонента только на стороне клиента.
  • Мы используем зависимость, которая выбирает инкрементные идентификаторы для компонента, счетчик будет абсолютно разным на сервере и на клиенте, а также идентификатор и разметка. Решение: к счастью, эта зависимость принимает свойство instanceId, и мы можем сгенерировать уникальный идентификатор с одинаковым алгоритмом для обеих сторон.
  • Мы используем redux, все вызовы API асинхронные. Но сервер этого не знает. Итак, как сказать серверу, что он должен дождаться ответа, чтобы отобразить разметку и только в этот момент отправить его клиенту? Дан Зайдбанд нашел ответ! Отправьте действие serverReady, обновите свое состояние, когда у вас есть данные, и дождитесь его перед рендерингом приложения на сервере. Что-то вроде этого:
const unsubscribe = store.subscribe(() => {
 if (store.getState().serverSide.serverReady) {
 unsubscribe();
 response.render('index', {data: yourData}
}

Другие проблемы

Одна прекрасная проблема, которую мы не решили (и никогда не решим), - это постоянная эволюция экосистемы JS. Например, мы начали проект, используя webpack 1, затем мы перешли на webpack 2, а теперь мы используем webpack 3 (только через 6 месяцев ). То же самое происходит со многими другими зависимостями. Вы никогда не прекратите перенос основных выпусков!

AB тестирование

Итак, однажды у нас был готов MVP, и нам потребовалось A / B-тестирование на мобильном Интернете.

Что ж, не все так просто ...

  • Мы хотим разделить измерения Google Analytics в новом представлении, но без потери всей картины на мобильных устройствах.
  • Мы хотим измерить коэффициент конверсии, но корзина и касса не входят в PWA.
  • У нас есть одинаковые URL для обеих сторон эксперимента.
  • Было бы хорошо, если бы мы не использовали в URL странные параметры запроса.
  • Люди, которые видят A, должны продолжать видеть A, а люди, которые видят B, должны продолжать видеть B.

Что мы сделали?

Для первых двух пунктов мы настроили новое представление в Google Analytics на основе специального измерения, которое заполняется непосредственно в коде для PWA и на основе файла cookie для корзины и проверить.

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

Мы сохраняем этот выбор в файле cookie «навсегда», если вы видите PWA, и в течение дня, если вы видите старый мобильный сайт. (Этот файл cookie помог нам узнать, какой пользователь перешел на страницу корзины с какой версии).

И постепенно мы увеличили процент A / B-тестирования, начиная с 10%, затем 20%, 50% и, наконец, 100% (удалили A / B-тестирование).

Почему мы так решили?

По сути, мы увидели улучшения почти по всем отслеживаемым показателям: коэффициент конверсии, средняя сумма тикетов, показатель отказов, просмотры страниц за сеанс, вернувшийся посетитель, сеанс. Продолжительность.

Статистика

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

Ниже приведены средние проценты за две недели A / B-теста.

Коэффициент конверсии

Мы увидели, что коэффициент конверсии на 27% выше.

Средняя сумма билета

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

Показатель отказов

Снижено на 9%.

Потому что загружается быстрее? Потому что это самое красивое? Потому что легче найти то, что вы ищете? Кто знает! Но номер отличный!

Вернувшийся посетитель

Увеличено на 13%, и те же вопросы, которые мы задали для показателя отказов, являются действительными.

Просмотры страниц за сеанс

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

Продолжительность сеанса

Почти так же, как раньше. Что в сочетании с + 35% просмотров страниц может означать: лучшую производительность, меньшее время загрузки и большее количество пользователей, просматривающих сайт.

Другими словами, в течение того же времени люди видят на 35% больше страниц. Таким образом, поскольку поток остался прежним, они теперь больше взаимодействуют с нашим сайтом.

Заключение

Это была непростая работа. Подход SPA был (на мой взгляд) одним из лучших улучшений.

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

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

По любым вопросам или сообщениям вы можете найти меня по адресу: https://twitter.com/leopittelli