Улучшение времени загрузки страницы за счет исключения клиентского JavaScript

WeWork.com служит отправной точкой для предложений WeWork по всему миру. Многие из наших пользователей просматривают сайт с мобильных устройств из регионов с не очень высокой скоростью Интернета, например, из Бруклина.

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

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

A / B-тестирование - наш путь к сокращению количества JavaScript

Мы провели управляемый эксперимент, в котором удалили весь клиентский код React на наших страницах сборки и заменили его библиотеками с нулевой зависимостью или пользовательскими реализациями. Мы хотели выяснить, во сколько нам обошлась эта проблема с JavaScript.

После нашего эксперимента мы обнаружили, что, устранив весь несущественный клиентский JavaScript, фактически уменьшив размер пакета с 506 КБ до 44 КБ (уменьшение ~ 91%), мы смогли значительно улучшить ключевые показатели.

  • Среднее время загрузки улучшено с 8,1 сек. до 4,6 сек. (Снижение ~ 43%)
  • Показатель дохода WeWork улучшен примерно на 43%
  • Показатель отказов снизился на 4,4%
  • Улучшенный поисковый рейтинг - Согласно Moz, Google использует скорость страницы как фактор при ранжировании страниц (хотя это трудно измерить).

Оптимизация времени загрузки

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

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

Клиенту необходимо отправить три вещи: документ, отображаемый на стороне сервера, код JavaScript, необходимый для визуализации приложения на стороне клиента (например, React, ReactDOM, код компонента), и любые данные, необходимые для гидратации дерева React. (В нашем случае это была каждая строка на странице - no bueno).

Для WeWork это накапливалось в необоснованный объем данных для отправки клиенту и являлся причиной наших низких оценок производительности.

JavaScript с нулевой зависимостью

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

Некоторые из отличных инструментов, которые мы используем:

  • Glide.js, карусели и слайдеры
  • Лозад. ленивая загрузка изображений и видео
  • Fetch API (с полифилом), для HTTP-запросов на стороне клиента.

Мы даже заменили нашу внутреннюю библиотеку компонентов React на внутреннюю библиотеку с нулевой зависимостью.

Наша собственная библиотека CSS / JS, Ray

Поскольку мы больше не могли использовать наши существующие инструменты (поскольку они были созданы на основе React), нам пришлось начать с библиотеки компонентов.

Вернуться к основам!

Почему вы вообще используете React для рендеринга целевой страницы?

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

  • A / B тестирование
  • логирование
  • Аналитика
  • Встроенная проверка формы
  • Модальные окна
  • Интерактивные карты
  • Переключатель языка
  • Ленивая загрузка изображений
  • Слайдеры изображений

Заключение

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

Я надеюсь, что это тематическое исследование может вдохновить других на пересмотр своей работы в Интернете, что и вдохновило нас на тематические исследования, подобные Netflix’s.

Спасибо за прочтение.

Огромное спасибо персоналу WeWork: Стелле Моретти (данные), Алану Фридману, Нилу Любину, Наджати Имаму и Алеку Петросу (инженеру) за их вклад в этот проект.