Веб-разработка немного похожа на самурайство: цели нет, есть только путь. И на этом пути разработчики постоянно решают две задачи: реализуют бизнес-логику на сайтах и веб-приложениях и оптимизируют их производительность. И вторая задача будет решаться до тех пор, пока количество трафика между сервером и клиентом не сожмётся до точки, а скорость отрисовки страницы (FCP) и скорость старта работы интерактивных элементов (TTI) не станет быстрее взмаха крыла бабочки.
А впрочем, бесконечность — не предел. Потому что цели, как мы помним, нет.
Темы оптимизации мы касались в наших прошлых статьях, когда рассказывали о библиотеке React, фреймворке Next и Server-Side Rendering. Сегодня мы снова вернёмся к этим технологиям и расскажем, какое значение в оптимизации производительности играют серверные компоненты.
Проблема рендеринга на стороне сервера
Один из способов улучшить производительность сайтов — это снизить трафик с сервера на на устройство пользователя (клиент). Суть клиент-серверной архитектуры — в череде запросов и ответов между клиентом и сервером, который, в свою очередь, обращается к базе данных. Постепенно веб-разработка ставила себе другие задачи: например, где и как можно закешировать страницу или отдать её разметку для SEO, чтобы позже страница ожила и начала работать для пользователя; или какую часть отрисовки страницы можно вынести на клиент или сервер.
И вот появились разработчики, которые взяли библиотеку React, выстроили вокруг неё фреймворк Next, вместе в фреймворком предложили принцип рендеринга на стороне сервера (Server-Side Rendering, или SSR) и сказали: «Теперь динамическое React-приложения можно частично собирать на сервере, отдавать его браузеру в виде одной страницы, а контент, завязанный на действиях пользователя, досылать в виде маленьких AJAX-файлов по мере совершения этих самых действий».
Что ж, маленький AJAX-файл — большой шаг для веб-разработки в сторону снижения времени на First Contentful Paint. Плюс с таким подходом у сайтов на React отличные SEO-показатели.
Но, несмотря на свой прорывной характер, SSR всё ещё не был подарком с точки зрения производительности. Перед отправкой компонентов на клиентскую сторону на их рендеринг уходит много серверных мощностей, что может привести к увеличению нагрузки на сервер в сравнении с традиционным клиентским рендерингом. Поэтому во второй половине 2010-х было нормальным докупать серверные ресурсы, чтобы сокращать время на ожидание, пока загрузится сайт.
Что такое серверные компоненты React
Напрашивается вопрос: а почему бы не распределить рендеринг страницы поровну между клиентом и сервером? Пусть сервер рендерит только статичные элементы компонентного дерева и отправляет их клиенту в виде HTML, а клиент обрабатывает кнопки, формы и прочий интерактив, который приходит ему как JS-файлы. Отсюда и берётся идея делить компоненты React на клиентские и серверные.
Суть серверных компонентов в том, что код хоть и пишется на React, но исполняется на сервере. После исполнения он компилируется в JSON-формате и передаётся в браузер пользователя как часть virtual DOM, чтобы React-приложение встроило его в DOM-дерево и он заработал так, будто и был собран в браузере.
Какая разница между React Server Components и Server-Side Rendering
Вернёмся к рендерингу на стороне сервера. При SSR вся страница собирается на сервере — вся, кроме динамических компонентов. Сначала пользователь видит версию, собранную на сервере и без отзывчивых интерактивных элементов интерфейса. И только в ходе так называемой гидратации, когда React цепляет к разметке страницы слушателей событий и начинает обрабатывать приложение в браузере, прежде бездействующие динамические элементы становятся интерактивными.
Серверные компоненты React обрабатывает только сервер, чтобы выдать готовую разметку и метаданные и отправить их в браузер React-приложению, которое встроит их в DOM-дерево. Это похоже на то, как работают обычные монолитные приложения, когда сервер отдаёт тебе HTML-разметку — ты не знаешь, как она собралась внутри, а видишь только результат. Здесь примерно то же самое, только сервер отдаёт не HTML-разметку, а данные для React.
Метод RSC накладывает ограничения: у серверных компонентов нет жизненного цикла. И если нужно обрабатывать то, что вводит пользователь, эти компоненты не подойдут. Но для статичных элементов они подходят идеально, потому что код, который отвечает за рендеринг серверного компонента, вообще не идёт на клиент, что уменьшает и количество скачиваемого кода, и размер бандла, в котором хранятся файлы JS, CSS и другие ресурсы для работы приложения.
Таким образом, в серверные компоненты нужно выносить статичные элементы: хэдер, футер, контент. А реактивная часть, которая будет работать с гидратацией — это формы, кнопки и прочие элементы с меняющимся состоянием.
У подхода RSC есть ещё одна особенность: с ним получать доступ к ресурсам базы данных можно напрямую, минуя серверный API. Это, опять же, даёт меньший объём кода, меньший объём передаваемых данных и более эффективное приложение.
Также, начиная с актуальной на данный момент версии React (React 18), Server Components API позволяет декларативно описывать серверные компоненты и автоматически управлять их загрузкой. Это включает в себя автоматический Code Splitting: система автоматически определяет, какие части кода могут быть асинхронно загружены на сервере в зависимости от текущего контекста запроса.
Назначение серверных и клиентских компонентов представлено в таблице ниже.
Преимущества серверных компонентов
Что получает React-приложение, когда на нём используются серверные компоненты React:
- страницы отрисовываются без череды запросов и ответов между клиентом и сервером (так называемых client-server-водопадов);
- объём приложения уменьшается, так как часть кода исполняется на сервере;
- доступ к ресурсам на бэкенде можно получить, минуя серверный API;
- Code Splitting автоматизируется.
Мы уже опробовали серверные компоненты React. В онлайн-сервисе, который мы сейчас разрабатываем, есть несколько кабинетов, и большая часть кабинета динамическая. Помимо этих кабинетов, есть ещё и сайт, который по большей части статичен. И, чтобы он быстрее работал и загружался, используются серверные компоненты.
Работая с предыдущей версией Next, мы наблюдали технологию серверных компонентов в довольно сыром виде, что несло с собой проблемы. На том же проекте с сервера на клиент приходил сначала каркас сайта, а меню приходило отдельно — оно зависит от разрешения браузера и меняет состояния, поэтому серверным компонентом его сделать не получается. В последней версии работа серверных компонентов стала стабильнее, и мы с интересом отслеживаем её прогресс в боевых условиях.
