Автор Кристофер Бакстер

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

Результатом этих усилий стало сокращение времени запуска на 70%, и они были сосредоточены в трех ключевых областях:

  1. Серверный и клиентский рендеринг
  2. Универсальный JavaScript
  3. Уменьшение полезной нагрузки JavaScript

Серверный и клиентский рендеринг

В стеке устаревших веб-сайтов netflix.com было жесткое разделение между серверной разметкой и улучшением клиента. В первую очередь это произошло из-за разных языков программирования, используемых в каждой части нашего приложения. На сервере была Java с Tomcat, Struts и Tiles. В клиенте браузера мы улучшили разметку, создаваемую сервером, с помощью JavaScript, в основном с помощью jQuery.

Это разделение привело к нежелательным результатам во время нашего стартапа. Каждый раз, когда посетитель переходил на любую страницу netflix.com, наш уровень Java генерировал большую часть ответа, необходимого на протяжении всего времени существования страницы, и доставлял его в виде разметки HTML. Часто пользователи будут ждать генерации разметки для больших частей страницы, которые они никогда не посетят.

Наша новая архитектура отображает только небольшую часть разметки страницы, загружая клиентское представление. Мы можем легко изменить объем общего представления, создаваемого сервером, что позволяет легко увидеть положительное или отрицательное влияние. Серверу требуется меньше данных для доставки ответа и меньше времени на преобразование данных в элементы DOM. После того, как клиентский JavaScript вступил во владение, он может получить все дополнительные данные для оставшейся части текущего и будущих просмотров сеанса по запросу. Основными преимуществами здесь стали сокращение времени обработки на сервере и объединение рендеринга на одном языке.

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

Универсальный JavaScript

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

Нашу новую архитектуру Node.js сформировали три большие болевые точки:

  1. Переключение контекста между языками было не идеальным.
  2. Для улучшения разметки потребовалось слишком много прямого взаимодействия между серверным кодом, генерирующим разметку, и клиентским кодом, улучшающим его.
  3. Мы бы предпочли создавать всю разметку с использованием одного и того же API.

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

Node.js и React.js естественно подходят для этого стиля приложения. С помощью Node.js и React.js мы можем рендерить с сервера и впоследствии полностью рендерить изменения на клиенте после того, как начальная разметка и компоненты React.js были переданы в браузер. Эта гибкость позволяет приложению отображать одни и те же выходные данные независимо от местоположения визуализации. Жесткого разделения больше нет, и гораздо менее вероятно, что сервер и клиент будут отличаться друг от друга.

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

Уменьшите влияние на полезную нагрузку JavaScript

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

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

Время для интерактивного

Чтобы проверить и понять влияние нашего выбора, мы отслеживаем метрику, которую мы называем временем интерактивности (tti).

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

Для приложений, работающих в веб-браузере, эти данные легко получить из Navigation Timing API (где поддерживается).

Работа продолжается

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

В ближайшие месяцы мы будем изучать Service Workers, ASM.js, Web Assembly и другие развивающиеся веб-стандарты, чтобы увидеть, можем ли мы использовать их для повышения производительности веб-сайта. Если вы заинтересованы в создании и формировании нового поколения эффективных веб-интерфейсов для пользователей, обращайтесь сюда.

Первоначально опубликовано на сайте techblog.netflix.com 5 августа 2015 г.