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

Выгоды

Прежде чем я перейду к истории и объяснению SSR, стоит сначала понять преимущества. Почему вас это должно волновать?

🔎 Поисковая оптимизация: поисковые системы сканируют контент, поэтому ваш сайт и страницы будут появляться в результатах поиска Google.

📣 Оптимизация в социальных сетях: когда люди публикуют ваши ссылки в Twitter, Facebook и т. д., появляется красивый предварительный просмотр с заголовком страницы, описанием и изображением.

🏎 Производительность: страницы, отображаемые на стороне сервера, будут загружаться быстрее, потому что контент быстрее становится доступным для браузера.

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

Я также сделал эпизод подкаста, объясняющий эти преимущества SSR:

История происхождения

Рендеринг на стороне сервера фактически существует с момента существования серверных языков программирования, таких как Java, PHP, Python и Ruby. Если вы когда-либо писали динамический код в файле index.php или во всем приложении Ruby on Rails, значит, вы уже выполняли рендеринг на стороне сервера.

Это делает понимание этой концепции намного проще. Допустим, у меня есть веб-сайт PHP, на котором я извлекаю список игр из базы данных. Это может выглядеть так:

<?php
$game1 = getFirstGameFromDatabase();
$game2 = getSecondGameFromDatabase();
echo "<ul><li>$game1</li><li>$game2</li></ul>";

Данные извлекаются и форматируются в виде HTML-списка на сервере. Как только вы просматриваете эту страницу в браузере, вам не нужно ждать запуска какого-либо JavaScript. Данные уже доступны, и вы сразу увидите список игр.

Это отлично подходит для всех, включая поисковые системы и социальные сети. Данные уже доступны в источнике страницы, поэтому поисковые роботы, такие как Google или даже Facebook, могут анализировать этот контент и отображать результаты поиска или предварительный просмотр ссылок.

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

Революция JavaScript

Браузеры постоянно становятся все более мощными, а это означает, что теперь вы можете делать гораздо больше с помощью JavaScript, чем 10 лет назад. Что же начали делать разработчики? Написание всех веб-сайтов и веб-приложений с использованием клиентского JavaScript.

Да, я в основном имею в виду использование фреймворков одностраничных приложений (SPA). Хотя их было много, Angular стал основным популяризатором этого подхода. Представьте, что вы можете получить некоторые данные через Ajax, добавить некоторые специальные атрибуты в свою разметку и вуаля: у вас есть динамический веб-сайт без необходимости возиться с PHP и серверами.

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

Теперь все, что у вас есть, это:

Я уверен, что Google не очень этому рад, как и пользователи. При медленном соединении может потребоваться некоторое время, чтобы JavaScript сделал эту страницу полезной.

Примечание. Прежде чем сказать: "Но теперь Google может сканировать JavaScript!", имейте в виду, что существуют ограничения, и не все поисковые роботы делают то же самое.

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

Примечание. Вы не теряете преимущества SPA.

Одностраничное приложение (SPA) популярно не только из-за быстрой разработки, но и из-за маршрутизации на стороне клиента. Это обеспечивает быструю навигацию для конечного пользователя, и это определенно то, что мы не хотим потерять, когда начинаем рендеринг на стороне сервера. К счастью, вы по-прежнему можете использовать эти фреймворки на стороне клиента, чтобы обеспечить такой опыт. Это означает, что начальный рендеринг использует SSR, но затем последующие переходы похожи на SPA.

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

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

Да, это возможно! Это все благодаря Node.js, который позволяет использовать так называемый универсальный JavaScript: код, который можно запускать как в браузере, так и на сервере.

Допустим, у нас есть простой компонент React, подобный этому:

function GamesList({ game1, game2 }) {
  return <ul><li>{game1}</li><li>{game2}</li></ul>;
}

Когда компонент отображается на странице следующим образом:

const games = <GamesList game1="mario" game2="pacman" />; ReactDOM.render(games, document.getElementById('app'));

Все это делается на стороне клиента. Как мы можем сделать то же самое на стороне сервера? Собственно, React предоставляет для этого метод:

return ReactDOMServer.renderToString(games);

Теперь вместо того, чтобы возвращать пустой div, мы можем заставить сервер Node.js возвращать полный HTML-код нашего компонента React! Аналогично коду PHP, который у нас был ранее.

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

Использование в реальном мире

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

Хотя вы можете начать с нуля и попытаться запустить свои приложения на Node.js, это много работы. Вы должны выяснить, как правильно реализовать выборку данных, гидратацию состояния, извлечение CSS и многое другое.

К счастью, для этого есть фреймворки:

  • Для проектов React я настоятельно рекомендую Next.js.
  • Для проектов Vue.js взгляните на Nuxt.js.

Другой вариант получения преимуществ рендеринга на стороне сервера без проблем с сервером Node.js — использование генератора статического сайта. Конечно, есть ограничения, такие как невозможность динамических маршрутов по запросу (например, профилей пользователей), но в остальном я определенно рекомендую взглянуть на GatsbyJS. Мой личный сайт работает на Гэтсби, о котором я тоже писал.

Я также должен упомянуть предварительный рендеринг, который, по сути, заключается в наличии вашего собственного поискового робота, который может анализировать JavaScript. Результат этой разметки затем передается соответствующим пользовательским агентам, таким как поисковые системы, и преимущество здесь в том, что вам не нужно менять способ написания вашего приложения. Prerender.io — популярный сервис, предоставляющий этот функционал. Имейте в виду, однако, что вы по-прежнему либо поддерживаете сервер, либо платите за услугу, и вы не получаете от этого никаких преимуществ в производительности.

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

Первоначально опубликовано на sunnysingh.io.