Серверный рендеринг (SSR)
Серверный рендеринг (SSR) приложения Inertia может улучшить поисковую оптимизацию (SEO), а также может сократить время до первой отрисовки содержимого (FCP). До сих пор Inertia не предлагала рендеринг на стороне сервера. Однако официальная поддержка приближается! Эта функция будет доступна в первую очередь нашим спонсорам. Пожалуйста, подумайте о поддержке этого проекта! ��
Как это работает
Проблема с серверными фреймворками JavaScript для рендеринга, такими как Vue, React и Svelte, заключается в том, что они были разработаны для рендеринга в браузере, а не на сервере. К счастью, благодаря Node.js, теперь можно также отображать эти фреймворки на стороне сервера!
Vue, React и Svelte предлагают инструменты SSR, которыми Inertia может воспользоваться. Вот как это работает:
Запрос поступает в ваш серверный фреймворк
Ваши запросы и ответы по-прежнему полностью управляются выбранной вами серверной структурой. Ваши маршруты, мидлвары и контроллеры подготавливают ответ Inertia, как и обычное приложение Inertia.
Inertia делает запрос к локальному SSR-серверу Node
Непосредственно перед тем, как Ваше приложение отправит браузеру полный ответ страницы, Inertia берет объект страницы для этого ответа и отправляет его через HTTP на локальный SSR-сервер Node
Сервер Node SSR отображает компонент страницы как HTML
Используя предоставленный объект страницы, сервер Node знает, какой компонент страницы Vue/React/Svelte визуализировать и какие реквизиты ему передать. Затем он возвращает обработанный HTML-код обратно в Ваше приложение.
Ваше приложение вставляет предварительно обработанный HTML-код в ответ
Теперь, когда Ваше приложение имеет предварительно обработанный HTML-код для страницы, оно может включать его в HTML-ответ, отправляемый браузеру. Когда клиентская платформа загружается, она может «гидратировать» HTML-код, отображаемый на стороне сервера, вместо повторного рендеринга всей страницы.
Что замечательно здесь, так это то, что из-за архитектуры Inertia объект page , отправляемый на сервер Node SSR, всегда включает в себя все необходимые данные (реквизиты), необходимые для рендеринга компонента страницы.
Это означает, что Вы не столкнетесь с какими-либо проблемами с асинхронной загрузкой данных при выполнении рендеринга на стороне сервера с помощью Inertia. Это очень быстро. Наши тесты показывают, что отрисовка страницы занимает 2ms-50ms , в зависимости от ее сложности.
Также имейте в виду, что Inertia нужно выполнять рендеринг на стороне сервера только для первая загрузка страницы. С этого момента Вы находитесь в «режиме SPA» и получаете обратно нормальные ответы Inertia XHR.
Требования
Хорошо, какие проблемы? Следует знать несколько технических требований.
Во-первых, поскольку мы используем Node для рендеринга на стороне сервера, Вам понадобится Node, установленный на Вашем сервере. К счастью, поскольку Node часто используется на этапах сборки, он очень часто устанавливается.
Во-вторых, Вам нужно запустить небольшой фоновый процесс Node. Если Вы используете современную хостинговую платформу, такую как Heroku или Laravel Forge, ее довольно просто настроить. (Технически Вы могли бы избежать запуска фонового процесса Node и просто выполнить оболочку для Node напрямую. Однако, поскольку Node загружается около 250ms , этот подход приводит к довольно значительному снижению производительности.)
В-третьих, Вы сейчас создаете приложение, которое должно работать как в браузере, так и в Node. Иногда их называют «универсальными» или «изоморфными» приложениями. В общем, это вполне управляемо. Вам просто нужно знать об этом, когда Вы добираетесь до window или document , поскольку они не существуют в Node.
Демо-приложение
Хотите знать, как выглядит приложение Inertia, созданное на стороне сервера? Мы настроили демонстрационное приложение Ping CRM в «режиме SSR», чтобы Вы могли узнать об этом.
Обязательно просмотрите источник, чтобы увидеть HTML, возвращаемый с сервера. Или, что еще лучше, войдите в систему, отключите JavaScript и щелкните приложение. Страницы загружаются, даже если JavaScript отключен! ��
Это демонстрационное приложение работает на небольшой капле Digital Ocean, управляемой Laravel Forge.
Server side rendering что это
19 декабря 2023
Скопировано
Серверный рендеринг (SSR, от английского server side rendering) — это генерация HTML-кода всей страницы на сервере в ответ на запрос.
Он позволяет избежать дополнительных запросов данных от клиента и обеспечивает быструю первую отрисовку и первую содержательную отрисовку. Благодаря выполнению логики страницы и рендерингу на сервере можно избежать отправки большого объема JavaScript клиенту, что сокращает время до достижения интерактивности. Этот подход применим в различных устройствах и сетевых условиях, предоставляя возможности для интересных оптимизаций браузера, таких как потоковый парсинг документа.
Освойте профессию «Frontend-разработчик»
Frontend-разработчик
Научитесь создавать удобные и эффектные сайты, сервисы и приложения, которые нужны всем. Сегодня профессия на пике актуальности: в России 9000+ вакансий, где требуется знание JavaScript.
Профессия / 9 месяцев
Frontend-разработчик
Создавайте интерфейсы сервисов, которыми пользуются все
Что такое SSR
Любая веб-страница или одностраничное приложение представляет собой код, который отображается в браузере пользователя в виде совокупности визуальных элементов, текста, интерактивных кнопок, ссылок и т. д. Сам процесс отрисовки ее содержимого называется рендерингом, а его результат — рендером. В идеале это должен быть почти мгновенный процесс: пользователь отправляет запрос на сервер, и тут же в ответ на него браузер показывает оформленную веб-страницу с работающими интерактивными элементами.
То есть в процессе отображения страницы участвуют две стороны:
- сервер, на котором хранятся ее код и все данные, включая контент, подгружаемые файлы, скрипты и т. д.;
- клиент (браузер пользователя), который отображает страницу в удобном для восприятия человеком виде.
Проблема заключается в том, что код практически любой современной веб-страницы или приложения (за исключением простейших сайтов-визиток) включает множество модулей, интерактивных элементов, файлов, стилей и т. д. Если заставить клиентскую программу (браузер) выполнять все это самостоятельно, беря данные с сервера, то возникает вероятность перегрузки аппаратных возможностей пользовательского ПК. Кроме того, такой подход не будет эффективно работать и при слабом интернет-подключении, потому что браузеру придется постоянно отправлять серверу запросы и получать файлы, что перегрузит канал.
Как раз для устранения этих проблем и увеличения скорости отрисовки страницы и предназначен метод «рендеринг на стороне сервера». Он заключается в том, что весь HTML-код страницы генерируется на сервере и оттуда отправляется клиенту в уже готовом виде. Это позволяет избежать лишних запросов данных от клиента, так как сервер сам выполняет всю необходимую работу по созданию HTML-кода перед отправкой ответа.
Как осуществляется серверный рендеринг
Генерация кода страницы на стороне сервера и его последующее отображение в браузере пользователя включает несколько ключевых этапов:
- Прием запроса. Сервер получает запрос от клиента, например на отображение определенной страницы веб-сайта.
- Загрузка данных. Сервер начинает загружать данные, которые будут использоваться для генерации HTML-кода страницы. Они могут быть получены из базы данных, файловой системы самого сервера или внешнего API.
- Выполнение логики страницы. Используя загруженные данные, сервер выполняет необходимые операции и логику для формирования содержимого страницы. Это может включать обработку данных, взаимодействие с другими сервисами и осуществление сложных вычислений.
- Рендеринг. На этом этапе сервер превращает данные в HTML-код, который будет представлять контент страницы. Обычно используются шаблонные движки, такие как Pug, Handlebars или EJS, для встраивания динамических данных в предварительно созданные шаблоны HTML. В результате этого процесса сервер формирует готовый HTML-код для отображения страницы.
- Отправка ответа. Получив готовый HTML-код, сервер отправляет его обратно клиенту вместе с заголовками HTTP и другими необходимыми данными. Этот ответ будет содержать полностью сгенерированную страницу с заполненным содержимым.
- Отображение на клиентском устройстве. Клиент получает ответ от сервера, который содержит полностью сгенерированный HTML-код страницы. Браузер со своей стороны начинает обрабатывать этот HTML и отображать его на экране устройства пользователя.
Станьте Frontend-разработчиком
и создавайте интерфейсы сервисов, которыми пользуются все
Преимущества серверного рендеринга
Повышенная производительность. В серверном рендеринге весь процесс генерации HTML-кода происходит на сервере, в отличие от клиентского рендеринга, где он происходит на стороне браузера. Это позволяет улучшить производительность, так как сервер обладает более мощными вычислительными ресурсами, чем клиентская сторона. Благодаря этому пользователи получают быструю загрузку и отзывчивость сайта.
Улучшенная SEO-оптимизация. Сервер генерирует полностью отрендеренную страницу, которая уже содержит контент, метаданные и ссылки. Это позволяет поисковым роботам легко индексировать сайт и повышает шансы на лучшую ранжировку в поисковых результатах. Клиентский рендеринг, напротив, может привести к проблемам с индексацией, так как поисковые роботы могут не обрабатывать динамически создаваемый контент.
Безопасность. При использовании серверного рендеринга весь код выполняется на сервере и только отрендеренный HTML-код отправляется на клиентскую сторону. Это уменьшает вероятность возникновения уязвимостей на стороне клиента, таких как межсайтовый скриптинг (XSS) или внедрение вредоносного кода.
Поддержка устаревших браузеров. Серверный рендеринг позволяет лучше обрабатывать ситуации, когда на клиентской стороне отсутствует поддержка современных технологий, например если браузер не поддерживает JavaScript или CSS-свойства. В таких случаях сервер может предоставлять альтернативный HTML-код, который все равно обеспечивает работоспособность и доступность сайта для всех пользователей.
Улучшенная масштабируемость. SSR позволяет легко масштабировать сайт для обработки большого количества запросов. Так как серверы могут быть гораздо более мощными, чем клиентские устройства, возможности масштабирования и обработки нагрузки значительно выше. Это особенно важно для сайтов с высоким трафиком и большим количеством одновременных пользователей.
Недостатки серверного рендеринга
Увеличение нагрузки на сервер. При серверном рендеринге серверу необходимо больше ресурсов для обработки запросов и отрисовки страниц. В случае высоких нагрузок (например, при обращении большого количества пользователей) это может привести к ухудшению производительности и временным задержкам в отображении страниц.
Ограниченная интерактивность. SSR подходит лучше для статических или ограниченно интерактивных страниц. При использовании этого метода обновление содержимого происходит только при перезагрузке или новом запросе от клиента. Сложные динамические взаимодействия, такие как формы с валидацией в реальном времени или интерактивные элементы, могут требовать дополнительной логики на сервере и усложнять процесс разработки.
Ограниченная переносимость. В отличие от клиентского рендеринга, который может осуществляться на любом устройстве с браузером, серверный требует наличия сервера для выполнения обработки запросов и рендеринга страниц. Это уменьшает переносимость приложений, так как для их работы необходима серверная инфраструктура.
Сложность в разработке и отладке. Реализация SSR в приложении может быть более сложной в сравнении с клиентским рендерингом. Разработчикам необходимо иметь хорошее понимание серверной инфраструктуры и среды выполнения, а также учитывать множество факторов, таких как безопасность, производительность и масштабируемость. Это может потребовать дополнительного времени и ресурсов.
Ограничения для SPA-приложений. Серверный рендеринг может стать проблемой для одностраничных приложений (SPA), которые часто используют динамическую загрузку и обработку данных на стороне клиента. В таких случаях серверный рендеринг способен осложнить процесс работы с клиентским состоянием и взаимодействие с сервером.
В каких приложениях целесообразно реализовать SSR
Использование серверного рендеринга имеет свои преимущества по сравнению с клиентским, особенно в следующих типах приложений:
Статичные сайты. При создании таких веб-ресурсов со статическим содержимым серверный рендеринг позволяет предоставить полностью готовый HTML, что положительно сказывается на скорости загрузки страниц и увеличивает производительность сайта. SSR дает возможность использовать для построения сайта такие технологии, как React, Vue.js или Angular, вместо более традиционных CMS (систем управления контентом), что упрощает разработку и поддержку.
Приложения с часто изменяющимся контентом. Веб-приложения, где обновление контента происходит часто или динамически, могут также использовать серверный рендеринг, чтобы не делать дополнительные запросы к серверу для получения актуальных данных. Примеры таких приложений могут включать ленты новостей, социальные сети, интернет-магазины и блоги, где частые обновления требуют быстрой и мгновенной передачи контента.
Приложения с требованиями SEO. Если ваш сайт или приложение нужно оптимизировать для поисковых систем, SSR является отличным способом улучшить SEO-индексацию. Полнотекстовый HTML-код, сгенерированный на сервере, может быть легко проиндексирован поисковыми системами, что повышает видимость веб-ресурса в результатах поиска. Сайты, где SEO критичен для привлечения трафика и посетителей, такие как онлайн-магазины или сервисы резервирования, оценят преимущества серверного рендеринга.
Многостраничные приложения. Для приложений с несколькими страницами и богатым контентом серверный рендеринг может улучшить пользовательский опыт за счет мгновенной загрузки страниц, а также повысить SEO-производительность каждой из них. Также это помогает с возможностью предоставить нужный HTML-код каждой страницы с учетом специфических требований и параметров.
Как серверный рендеринг влияет на SEO
Серверный рендеринг может существенно повысить видимость и индексацию сайта поисковыми системами. Рассмотрим основные моменты этой взаимосвязи:
Индексация полноценного HTML-кода. Поисковые системы сканируют и индексируют контент, который виден в HTML-коде страницы. Когда используется только клиентский рендеринг, поисковые системы могут иметь ограниченный доступ к контенту, поскольку они видят только исходный JavaScript-код. Серверный рендеринг решает эту проблему, поскольку генерирует HTML-код на сервере и отправляет его клиенту. В результате поисковые системы могут легко прочитать и проиндексировать весь контент, улучшая видимость сайта.
Улучшенная скорость загрузки страниц. Быстрая загрузка страниц является важным фактором для SEO, поскольку поисковые системы предпочитают сайты с хорошей производительностью. Клиентский рендеринг может временами вызывать задержки, поскольку требуется время для загрузки и выполнения JavaScript-кода для формирования контента. В то же время серверный рендеринг позволяет предварительно сформировать HTML-код на сервере и отправить его клиенту, что существенно сокращает время ожидания и ускоряет загрузку страницы. Это положительно сказывается на пользовательском опыте и SEO-рейтинге сайта.
Лучшая видимость контента при использовании AJAX и SPA. В современных веб-приложениях, использующих AJAX (Asynchronous JavaScript and XML) и SPA (Single-Page Application), клиент связывается с сервером, чтобы запросить и загрузить отдельные фрагменты контента. Это может создать проблемы с SEO, поскольку поисковые системы могут иметь ограниченный доступ к таким фрагментам контента, которые генерируются динамически на клиенте. Использование серверного рендеринга позволяет получить контент прямо на этапе отрисовки на сервере и предоставить его поисковым системам в виде полноценного HTML-кода. Это гарантирует, что весь контент будет доступен для индексации, повышая видимость и рейтинг сайта.
Улучшенный контроль над метаданными. Управление заголовками страницы, метатегами и описаниями является важным аспектом SEO. SSR предоставляет возможность динамически менять метаданные и управлять ими на сервере перед отправкой пользователю. Это позволяет оптимизировать их для поисковиков, включая ключевые слова, заголовки и описания, с целью улучшения видимости и позиционирования сайта в поисковой выдаче.
Рендеринг на стороне сервера — эффективная технология создания веб-страниц и приложений. Благодаря ей пользователь получает быстрый и отзывчивый интерфейс, минимизируется время ожидания открытия страницы и улучшается ее SEO-оптимизация. SSR также обеспечивает возможность регулярного обновления контента без необходимости полной перезагрузки страницы, что особенно полезно для динамических сайтов. В конечном итоге использование SSR позволяет создавать более эффективные и удобные веб-приложения.
Что такое рендеринг на стороне сервера и нужен ли он мне?
В новом году начнем общение с вами с затравочной статьи о серверном рендеринге (server-side rendering). В случае вашей заинтересованности возможна более свежая публикация о Nuxt.js и дальнейшая издательская работа в этом направлении
С появлением современных фреймворков и библиотек для JavaScript, которые предназначены, прежде всего, для создания интерактивных веб-страниц и одностраничных приложений, сильно изменился весь процесс показа страниц пользователю.
До пришествия приложений, полностью генерируемых на JS в браузере, HTML-разметка выдавалась клиенту в ответ на HTTP-вызов. Это могло происходить путем возврата статического HTML-файла с контентом, либо путем обработки отклика при помощи какого-либо серверного языка (PHP, Python или Java), причем, более динамическим образом.
Подобное решение позволяет создавать отзывчивые сайты, работающие гораздо быстрее стандартных сайтов, действующих по модели «запрос-отклик», поскольку при работе устраняется время, проводимое запросом «в пути».
Типичный отклик, отправляемый сервером на запрос к сайту, написанному на React, будет выглядеть примерно так:
React App Выбрав этот отклик, наш браузер также выберет «пакет» app.js , содержащий наше приложение, и через одну-две секунды полностью отобразит страницу.
В этот момент уже можно воспользоваться встроенным в браузер инспектором HTML, чтобы просмотреть весь отображенный HTML. Однако, заглянув в исходный код, мы не увидим ничего кроме HTML, приведенного выше.
Почему это проблема?
Хотя такое поведение и не доставит проблем большинству наших пользователей либо при разработке приложения, оно может стать нежелательным, если:
- Конечный пользователь работает с медленным интернет-соединением, что особенно актуально для мобильных устройств,
- Конечный пользователь работает с маломощным устройством, например, со смартфоном старого поколения
“Ладно, но в демографическом отношении моя целевая аудитория точно не относится ни к одной из этих групп, так стоит ли мне волноваться?”
Есть еще две вещи, которые следует учитывать при работе с приложением, рендеринг в котором выполняется на стороне клиента: поисковики и присутствие в социальных сетях.
Сегодня из всех поисковиков лишь Google обладает некоторыми возможностями отобразить и сайт и учесть его JS прежде, чем отобразить страницу. Кроме того, хотя Google и сможет отобразить индексную страницу вашего сайта, известно, что могут возникать проблемы с навигацией по сайтам, на которых реализован роутер.
Это означает, что вашему сайту будет очень непросто забраться в топ выдачи любого поисковика кроме Google.
Та же проблема просматривается и в социальных сетях, например, в Facebook — если ссылкой на ваш сайт поделятся, то ни его название, ни картинка-превью не отобразятся как следует.
Как решить эту проблему
Есть несколько способов ее решения.
A — Попробуйте оставить все ключевые страницы вашего сайта статическими
Когда создается сайт-платформа, куда пользователю придется входить под своим логином, а без входа в систему контент посетителю не предоставляется, можно попробовать оставить статическими (написанными на HTML) общедоступные страницы вашего сайта, в частности, индекс, «о нас», «контакты» и не использовать JS при их отображении.
Поскольку ваш контент ограничен требованиями по входу в систему, он не будет индексироваться поисковиками, и им нельзя будет поделиться в социальных сетях.
B — Генерируйте части вашего приложения в виде HTML-страниц в процессе сборки
В проект можно добавить такие библиотеки как react-snapshot; они используются для генерации HTML-копий страниц вашего приложения и для сохранения их в специально предназначенном каталоге. Затем этот каталог развертывается наряду с пакетом JS. Таким образом, HTML будет подаваться с сервера вместе с откликом, и ваш сайт увидят в том числе те пользователи, у которых отключен JavaScript, а также заметят поисковики и т.д.
Как правило, сконфигурировать react-snapshot не составляет труда: достаточно добавить библиотеку в ваш проект и изменить сборочный скрипт следующим образом:
«build»: «webpack && react-snapshot —build-dir static»
Недостаток такого решения заключается в следующем: весь контент, который мы хотим сгенерировать, должен быть доступен во время сборки – мы не можем обратиться к каким-либо API, чтобы получить его, мы также не можем заранее сгенерировать контент, зависящий от данных, предоставляемых пользователем (например, от URL).
C — Создать на JS приложение, использующее серверный рендеринг
Один из важнейших выигрышных моментов у современного поколения приложений на JS заключается в том, что их можно запускать как на клиенте (в браузере), так и на сервере. Так удается генерировать HTML для страниц, являющихся более динамичными, таких, чей контент в период сборки еще не известен. Подобные приложения часто называют «изоморфными» или «универсальными».
Два наиболее популярных решения, обеспечивающих серверный рендеринг для React:
- next.js — github.com/zeit/next.js
- Gatsby — github.com/gatsbyjs/gatsby
Создайте собственную реализацию SSR
Важно: если вы собираетесь попробовать самостоятельно создать собственную реализацию SSR для приложений на React, то должны будете обеспечить работу node-бэкенда для вашего сервера. Вы не сможете развернуть это решение на статическом хосте, как в случае со страницами github.
Первым делом нам понадобится создать приложение, точно как в случае с любым другим приложением React.
Давайте создадим входную точку:
// index.js import React from 'react'; import < render >from 'react-dom'; import App from './App.js';render(, document.getElementById('root'));И компонент-приложение (App):
// App.js import React from 'react';const App = () => < return ( Welcome to SSR powered React application! ); >А также “оболочку”, чтобы загрузить наше приложение:
// index.html Как видите, приложение получилось довольно простым. В рамках этой статьи мы не будем пошагово разбирать все шаги, необходимые для генерации правильной сборки webpack+babel.
Если запустить приложение в его текущем состоянии, то на экране появится сообщение-приветствие. Просмотрев исходный код, вы увидите содержимое файла index.html , но приветственного сообщения там не будет. Для решения этой проблемы добавим серверный рендеринг. Для начала добавим 3 пакета:
yarn add express pug babel-node --save-devExpress – это мощный веб-сервер для node, pug – движок-шаблонизатор, который можно использовать с express, а babel-node – это обертка для node, обеспечивает транспиляцию на лету.
Сначала скопируем наш файл index.html и сохраним его как index.pug :
// index.pug ! Как видите, файл практически не изменился, не считая того, что теперь в HTML вставлено ! . Это переменная pug , которая впоследствии будет заменена реальным HTML.
Создадим наш сервер:
// server.jsimport React from 'react'; import < renderToString >from 'react-dom/server'; import express from 'express'; import path from 'path';import App from './src/App';const app = express(); app.set('view engine', 'pug'); app.use('/', express.static(path.join(__dirname, 'dist')));app.get('*', (req, res) => < const html = renderToString( ); res.render(path.join(__dirname, 'src/index.pug'), < app: html >); >);app.listen(3000, () => console.log('listening on port 3000'));Разберем этот файл по порядку.
import < renderToString >from 'react-dom/server';Библиотека react-dom содержит отдельный именованный экспорт renderToString , работающий подобно известному нам render , но отображает не DOM, а HTML в виде строки.
const app = express(); app.set('view engine', 'pug'); app.use('/', express.static(path.join(__dirname, 'dist')));Мы создаем новый инстанс сервера express и сообщаем ему, что собираемся использовать движок-шаблонизатор pug . В данном случае мы могли бы обойтись обычным считыванием файла и выполнением операции «поиск с заменой», но такой подход в самом деле неэффективен и может спровоцировать проблемы из-за множественного доступа к файловой системе, либо проблемы с кэшированием.
В последней строке мы приказываем express искать файл в каталоге dist , и, если запрос (напр. /bundle.js ) совпадает с файлом, присутствующем в этом каталоге, то выдать его в ответ.
app.get('*', (req, res) => < >);Теперь мы приказываем express добавить обработчик на каждый несовпавший URL — в том числе, на наш несуществующий файл index.html (как вы помните, мы переименовали его в index.pug , и его нет в каталоге dist ).
const html = renderToString( );При помощи renderToString мы отображаем наше приложение. Код выглядит точно как у входной точки, но такое совпадение не является обязательным.
res.render(path.join(__dirname, 'src/index.pug'), < app: html >);Теперь, когда у нас есть отображенный HTML, мы приказываем express отобразить в ответ файл index.pug и заменить переменную app тем HTML, что мы получили.
app.listen(3000, () => console.log('listening on port 3000'));Наконец, мы обеспечиваем запуск сервера и настраиваем его так, чтобы он слушал порт 3000.
Теперь нам осталось всего лишь добавить нужный скрипт в package.json :
"scripts":
Теперь, вызвав yarn run server , мы должны получить подтверждение, что сервер действительно работает. Переходим в браузере по адресу localhost:3000, где мы, опять же, должны увидеть наше приложение. Если мы просмотрим исходный код на данном этапе, то увидим:
div data-reactroot="">Welcome to SSR powered React application!
