Server side rendering что это

# Руководство по серверному рендерингу Vue.js

Для этого руководства требуются следующие версии Vue и библиотек:

• vue & vue-server-renderer 2.3.0+
• vue-router 2.5.0+
• vue-loader 12.0.0+ & vue-style-loader 3.0.0+

Если вы ранее использовали Vue 2.2 с серверным рендерингом, вы заметите, что рекомендуемая структура кода теперь немного отличается (с новой опцией runInNewContext, установленной в false ). Ваше существующее приложение по-прежнему будет работать, но лучше внесите изменения с учётом новых рекомендаций.

# Что такое серверный рендеринг (SSR)?

Vue.js — это фреймворк для создания приложений, выполняемых на клиенте (client-side). По умолчанию компоненты Vue создают и манипулируют DOM в браузере. Однако, также возможно рендерить те же компоненты в HTML-строки на сервере, отправлять их в браузер, и наконец «гидрировать» статическую разметку в полностью интерактивное приложение на клиенте.

Приложение Vue.js отрендеренное на сервере также можно считать «изоморфным» или «универсальным», в том смысле, что большая часть кода приложения является общей для сервера и клиента.

# Нужен ли вам SSR?

По сравнению с традиционным SPA (Single-Page Application), преимуществами серверного рендеринга будут:

• Лучшее SEO, поскольку поисковые роботы будут видеть полностью отрендеренную страницу. Обратите внимание, что на данный момент Google и Bing могут без проблем индексировать синхронные приложения JavaScript. Ключевое слово здесь — синхронные. Если ваше приложение запускается с индикатором загрузки, а потом догружает контент через Ajax, то поисковый робот просто не будет дожидаться окончания загрузки. Это значит, что если у вас есть асинхронный контент на страницах где SEO важен, то может потребоваться серверный рендеринг.
• Лучшие показатели времени до отображения контента (time-to-content), особенно при плохом интернете или на медленных устройствах. Для разметки, отрендеренной на сервере, не требуется дожидаться пока весь JavaScript будет загружен и выполнен, поэтому ваш пользователь увидит полностью отрендеренную страницу раньше. Как правило, это приводит к лучшему пользовательскому опыту и может быть критичным для приложений, где время до отображения контента напрямую связано с коэффициентом конверсии.

Следует учитывать и некоторые компромиссы при использовании серверного рендеринга:

• Ограничения при разработке. Код только для браузера может быть использован лишь в определённых хуках жизненного цикла; некоторые внешние библиотеки могут нуждаться в особой обработке, чтобы иметь возможность запускаться в приложении с серверным рендерингом.
• Более сложные требования по настройке и развёртыванию сборки. В отличие от полностью статичного SPA, который может быть развёрнут на любом статичном файловом сервере, приложение с серверным рендерингом требует окружения, где есть возможность запустить сервер Node.js.
• Повышенная нагрузка на стороне сервера. Рендеринг полноценного приложения в Node.js очевидно более требователен к ресурсам процессора, чем простая раздача статичных файлов, поэтому если вы ожидаете большой трафик, будьте готовы к соответствующей нагрузке на сервер и используйте стратегии кэширования.

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

# SSR vs Пререндеринг

Если вы интересуетесь серверным рендерингом только для того, чтобы улучшить SEO на нескольких маркетинговых страницах (например, / , /about , /contact , и т.д.), вам скорее всего будет достаточно пререндеринга. Вместо того, чтобы заставлять веб-сервер компилировать HTML на лету, пререндеринг просто сгенерирует статичные HTML-файлы для указанных маршрутов на этапе сборки. Преимуществом пререндеринга будет простота реализации, кроме того этот подход позволит вам оставить фронтенд полностью статичным.

Если вы используете Webpack, то для добавления пререндеринга достаточно установить плагин prerender-spa-plugin

(opens new window) . Он был тщательно протестирован с приложениями Vue.

# Об этом руководстве

Это руководство ориентировано на SPA приложения с рендерингом на сервере, используя Node.js в качестве сервера. Использование серверного рендеринга Vue совместно с другими технологиями и настройками бэкэнда являются отдельной темой и кратко обсуждается в отдельном разделе.

Это руководство будет очень детальным и предполагает, что вы уже знакомы с самим Vue.js, имеете знания и опыт работы с Node.js и Webpack. Если вы предпочитаете более высокоуровневые решения, обеспечивающие работу из коробки — вам следует попробовать Nuxt.js

(opens new window) . Он построен на том же стеке Vue, но позволяет абстрагироваться от написания шаблонного кода, а также предоставляет некоторые дополнительные возможности, такие как генерация статичного сайта. Однако он может не подойти, если вам необходим полный контроль над структурой приложения. В любом случае, вам будет полезно прочитать это руководство, чтобы лучше понимать, как все составляющие работают вместе.

По мере прочтения руководства, будет полезным обращаться к официальному демо HackerNews

(opens new window) , в котором используется большинство техник, изложенных в этом руководстве.

Наконец, обратите внимание, что решения в этом руководстве не являются окончательными — мы решили, что они хорошо работают для нас, но это не означает, что они не могут быть улучшены. Они могут быть пересмотрены в будущем — поэтому не стесняйтесь вносить свой вклад, отправляя пулл-реквесты!

Понимание рендеринга на стороне сервера (SSR)

Рендеринг на стороне сервера (SSR) — это техника, используемая для улучшения производительности веб-сайта и удобства работы пользователей путем рендеринга веб-страниц на сервере перед отправкой их в браузер.

При традиционном рендеринге на стороне клиента веб-страницы создаются с помощью JavaScript на компьютере клиента, что может привести к замедлению времени загрузки и снижению поисковой оптимизации (SEO).

При использовании SSR сервер генерирует HTML-файлы, которые отправляются в браузер клиента, сокращая время, необходимое JavaScript для рендеринга страницы. Это приводит к ускорению загрузки, улучшению SEO и доступности для пользователей с медленным или ненадежным соединением интернет.

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

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

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

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

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

Серверный рендеринг (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 с нуля до профи

Главной проблемой Single Page приложений является то, что сервер отдает клиенту пустую HTML страницу. Её формирование происходит только после того как весь JS будет скачан (это весь ваш код, библиотеки, фреймверк). Это в большинстве случаев более 2-х мегабайт размера + задержки на обработку кода.

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

Google начинает выдавать красные карты если ваш сайт рендерится более 3-х секунд. First Contentful Paint, Time to Interactive — это метрики которые будут занижены при Single Page Application. Подробнее читайте здесь.

Также есть менее продвинутые поисковые системы, которые попросту не умеют работать с JS. В них Single Page Application не будут индексироваться.

На ранжирование сайта еще влияет множество факторов, часть из них мы разберем далее в этой статье.

Рендеринг

Существует несколько путей как решить проблему пустой странички при загрузке, рассмотрим несколько из них:

Static Site Generation (SSG). Сделать пререндер сайта перед тем как его загрузить на сервер. Очень простое и эффективное решение. Отлично подходит для простых веб страничек, без взаимодействия с backend API.

Server-Side Rendering (SSR). Рендерить контент в рантайме на сервере. При таком подходе мы сможем делать запросы backend API и отдавать HTML вместе с необходимым содержимым.

Server-Side Rendering (SSR)

Рассмотрим подробнее, как работает SSR:

• У нас должен быть сервер, который выполняет наше приложение точно так же, как делал бы это пользователь в браузере. Делая запросы на необходимые ресурсы, отображая весь необходимый HTML, наполняя состояние.
• Сервер отдает клиенту наполненный HTML, наполненное состояние, а также отдает все необходимые JS, CSS и прочие ресурсы.
• Клиент, получая HTML и ресурсы, синхронизирует состояние и работает с приложением как с обычным Single Page Application. При этом важным моментом является то, что состояние должно синхронизироваться.

Из вышеописанной работы SSR приложения мы можем выделить проблемы:

• Приложение делится на сервер и клиент. То есть у нас по сути получается 2 приложения. Данное разделение должно быть минимально иначе поддержка такого приложения будет сложной.
• Сервер должен уметь обрабатывать запросы к API с данными. Данные операции асинхронные, являются Side Effects. По умолчанию renderToString метод React работающий с сервером — синхронный и не может работать с асинхронными операциями.
• На клиенте приложение должно синхронизировать состояние и продолжать работать как обычное SPA приложение.

iSSR

Это маленькая библиотека которая способна решить проблемы асинхронной обработки запросов к данным а также синхронизации состояния с сервера на клиент. Это не “очередной убийца Next.JS”, нет! Next.JS прекрасный фреймверк имеющий множество возможностей, но чтобы его использовать вам придется почти полностью переписать ваше приложение и следовать правилам Next.JS.

Посмотрим на примере, как просто перенести обычное SPA приложение на SSR.

К примеру, у нас есть простейшее приложение с асинхронной логикой.

Код приложения

Данный код рендерит список выполненных задач, используя сервис jsonplaceholder для эмуляции взаимодействия с API.

Сделаем данное приложение SSR!

Шаг 1. Установка зависимостей

Для установки iSSR нужно выполнить:

npm install @issr/core --save npm install @issr/babel-plugin --save-dev 

Для настройки базовой билд системы установим:

npm install @babel/core @babel/preset-react babel-loader webpack webpack-cli nodemon-webpack-plugin --save-dev 

Один из неочевидных моментов разработки SSR приложений является то, что некоторые API и библиотеки могут работать на клиенте но не работать на сервере. Одним из таких API является fetch. Данный метод отсутствует в nodejs где будет выполняться серверная логика нашего приложения. Для того, чтобы у нас приложение работало одинаково установим пакет:

npm install node-fetch --save 

Для сервера будем использовать express, но это не важно, можно использовать любой другой фреймверк:

npm install express --save 

Добавим модуль для сериализации состояния приложения на сервере:

npm install serialize-javascript --save 

Шаг 2. Настройка webpack.config.js

webpack.config.js

const path = require('path'); const NodemonPlugin = require('nodemon-webpack-plugin'); const commonConfig = < module: < rules: [ < test: /\.jsx$/, exclude: /node_modules/, use: [ < loader: 'babel-loader', options: < presets: [ '@babel/preset-react' ], plugins: [ '@issr/babel-plugin' ] >> ] > ] >, resolve: < extensions: [ '.js', '.jsx' ] >> module.exports = [ < . commonConfig, target: 'node', entry: './src/server.jsx', output: < path: path.resolve(__dirname, './dist'), filename: 'index.js', >, plugins: [ new NodemonPlugin(< watch: path.resolve(__dirname, './dist'), >) ] >, < . commonConfig, entry: './src/client.jsx', output: < path: path.resolve(__dirname, './public'), filename: 'index.js', >> ]; 

• Для компиляции SSR приложения конфигурационный файл webpack должен состоять из двух конфигураций (MultiCompilation). Одна для сборки сервера, вторая для сборки клиента. Мы передаем в module.exports массив.
• Для конфигурации сервера нам нужно задать target: ‘node’. Для клиента задавать target не обязательно. По умолчанию конфигурация webpack имеет target: ‘web’. target: ‘node’ позволяет webpack обрабатывать сервер код, модули по умолчанию, такие как path, child_process и прочее.
• const commonConfig — общая часть настроек. Так как код сервера и клиента имеет общую структуру приложения, они должны обрабатывать JS одинаково.

Шаг 3. Модификация кода

Вынесем общую логику нашего приложения в отдельный файл App.jsx. Это нужно для того, чтобы в файлах client.jsx и server.jsx осталась только логика рендеринга, ничего больше. Таким образом весь код приложения у нас будет общий.

App.jsx
client.jsx

import React from 'react'; import < hydrate >from 'react-dom'; import < App >from './App'; hydrate( , document.getElementById('root') ); 

Мы поменяли стандартный render метод React на hydrate, который работает для SSR приложений.

server.jsx

import React from 'react'; import express from 'express'; import < renderToString >from 'react-dom/server'; import < App >from './App'; const app = express(); app.use(express.static('public')); app.get('/*', async (req, res) => < const html = renderToString(); res.send(`      $  `); >); app.listen(4000, () => < console.log('Example app listening on port 4000!'); >); 

В коде сервера обратите внимание, что мы должны расшаривать папку с собранным SPA приложением webpack:
app.use(express.static(‘public’));
Таким образом, полученный с сервера HTML будет работать далее как обычный SPA

Шаг 4. Обработка асинхронности

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

Для обработки асинхронных операций их нужно обернуть в хук useSsrEffect из пакета @issr/core:

App.jsx

В server.jsx заменим стандартный renderToString на serverRender из пакета @issr/core:

server.jsx

import React from 'react'; import express from 'express'; import < serverRender >from '@issr/core'; import serialize from 'serialize-javascript'; import < App >from './App'; const app = express(); app.use(express.static('public')); app.get('/*', async (req, res) => < const < html >= await serverRender(() => ); res.send(`      $    `); >); app.listen(4000, () => < console.log('Example app listening on port 4000!'); >); 

Если запустить приложение сейчас, то ничего не произойдет! Мы не увидим результата выполнения асинхронной функции getTodos. Почему так происходит? Мы забыли синхронизировать состояние. Давайте исправим это.

В App.jsx заменим стандартный setState на useSsrState из пакета @issr/core:

App.jsx

Внесем изменения в client.jsx для синхронизации состояния переданного с сервера на клиент:

client.jsx

import React from 'react'; import < hydrate >from 'react-dom'; import createSsr from '@issr/core'; import < App >from './App'; const SSR = createSsr(window.SSR_DATA); hydrate(  , document.getElementById('root') ); 

window.SSR_DATA — это объект, переданный с сервера с кешированнным состоянием, для синхронизации на клиенте.

Сделаем передачу состояние на сервере:

server.jsx

import React from 'react'; import express from 'express'; import < serverRender >from '@issr/core'; import serialize from 'serialize-javascript'; import < App >from './App'; const app = express(); app.use(express.static('public')); app.get('/*', async (req, res) => < const < html, state >= await serverRender(() => ); res.send(`       $    `); >); app.listen(4000, () => < console.log('Example app listening on port 4000!'); >); 

Обратите внимание, что функция serverRender передает не только HTML, но и состояние, которое прошло через useSsrState, мы его передаем на клиент, в качестве глобальной переменной SSR_DATA. На клиенте, данное состояние будет автоматически синхронизировано.

Шаг 5. Билд скрипты

Осталось добавить скрипты запуска в package.json:

"scripts": < "start": "webpack -w --mode development", "build": "webpack" >, 

Redux и прочие State Management библиотеки

iSSR отлично поддерживает разные state management библиотеки. В ходе работы над iSSR я заметил, что React State Management библиотеки делятся на 2 типа:

1. Реализует работу с Side Effects на слое React. Например Redux Thunk превращает вызов Redux dispatch в асинхронный метод, а значит мы можем имплементить SSR как в примере выше для setState. Пример с redux-thunk доступен по ссылке
2. Реализуют работу с Side Effects на отдельном от React слое. Например Redux Saga выносит работу с асинхронными операциями в Саги.

Мы не будем рассматривать этот пример так детально как предыдущий. Ознакомится с полным кодом можно по ссылке.

Redux Saga

*Для лучшего понимания происходящего, читайте предыдущую главу

Сервер запускает наше приложение через serverRender, код выполняется последовательно, выполняя все операции useSsrEffect.

Концептуально Redux работая с сагами не выполняет никаких асинхронных операций. Наша задача отправить action для старта асинхронной операции в слое Саг, отдельных от нашего react-flow. В примере по ссылке выше, в контейнере Redux мы выполняем

useSsrEffect(() => < dispatch(fetchImage()); >); 

Это не асинхронная операция! Но iSSR понимает, что что то произошло в системе. iSSR будет идти по остальным React компонентам выполняя все useSsrEffect если таковые будут и по завершению iSSR вызовет каллбек:

const < html >= await serverRender(() => ( >  ), async () => < store.dispatch(END); await rootSaga.toPromise(); >); 

Таким образом мы можем обрабатывать асинхронные операции не только на уровне с React но и на других уровнях, в данном случае мы в начале поставили на выполнение нужные нам саги, после чего в callback serverRender запустили и дождались их окончания.

Я подготовил много примеров использования iSSR, вы можете их найти по ссылке.

SSR трюки

На пути в разработке SSR приложений существуют множество проблем. Проблема асинхронных операций это только одна из них. Давайте посмотрим на другие распространенные проблемы.

HTML Meta Tags для SSR

Немаловажным аспектом в разработке SSR является использование правильных HTML meta tags. Они сообщают поисковому боту ключевую информацию на странице.
Для реализации данной задачи рекомендую использовать один из модулей:
React-Helmet-Async
React-Meta-Tags
Я подготовил несколько примеров:
React-Helmet-Async
React-Meta-Tags

Dynamic Imports

Чтобы снизить размер финального бандла приложения, принято приложение делить на части. Например dynamic imports webpack позволяет автоматически разбить приложение. Мы можем вынести отдельные страницы в чанки или блоки. При SSR мы должны уметь обрабатывать данные фрагменты приложения как одно целое. Для этого рекомендую использовать замечательный модуль @loadable

Dummies

Некоторые компоненты или фрагменты страницы можно не рендерить на сервере. Например, если у вас есть пост и комментарии, не целесообразно обрабатывать обе асинхронные операции. Данные поста более приоритетны чем комментарии к нему, именно эти данные формируют SEO нагрузку вашего приложения. По этому мы можем исключать не важные части при помощи проверок типа:

if (typeof windows === 'undefined')

localStorage, хранение данных

NodeJS не поддерживает localStorage. Для хранения сессионных данных мы используем cookie вместо localStorage. Файлы cookie отправляются автоматически по каждому запросу. Файлы cookie имеют ограничения, например:

• Файлы cookie — это старый способ хранения данных, они дают ограничение в 4096 байт (фактически 4095) на один файл cookie.
• localStorage — это реализация интерфейса хранилища. Он хранит данные без даты истечения срока действия и очищается только с помощью JavaScript или очистки кеша браузера / локально сохраненных данных — в отличие от истечения срока действия файлов cookie.

React Server Components

React Server Components возможно будет хорошим дополнением для SSR. Его идеей является снижение нагрузки на Bundle за счет выполнения компонент на сервере и выдачи готового JSON React дерева. Нечто подобное мы видели в Next.JS. Читайте подробнее по ссылке

Роутинг

React Router из коробки поддерживает SSR. Отличие в том, что на server используется StaticRouter с переданным текущим URL, а на клиенте Router определяет URL автоматически при помощи location API. Пример

Debugging

Дебаг на сервере может выполняться также как и любой дебаг node.js приложений через inpsect.
Для этого нужно добавить в webpack.config для nodejs приложения:

devtool: ‘source-map’
А в настройки NodemonPlugin:

new NodemonPlugin(< watch: path.resolve(__dirname, './dist'), nodeArgs: [ '--inspect' ] >) 

Также, для улучшения работы с source map можно добавить модуль

npm install source-map-support --save-dev 

В nodeArgs опций NodemonPlugin добавить:
‘—require=«source-map-support/register»’
Пример

Next.JS

Если вы создаете приложение с нуля, рекомендую обратить внимание на данный фреймверк. Это самое популярное решение на данный момент для создания с нуля приложений с поддержкой SSR. Из плюсов можно выделить то, что все идет из коробки (билд система, роутер). Из минусов — необходимо переписывать существующее приложение, использовать подходы Next.JS.

SEO это не только SSR!

Критерии Google бота для SEO оптимизации включают множество метрик. Рендер данных, получение первого байта и т.д. это лишь часть метрик! При SEO оптимизации приложения необходимо минимизировать вес картинок, бандла, грамотно использовать HTML теги и HTML мета теги и прочее.

Для проверки вашего сайта при SEO оптимизации можно воспользоваться:

Выводы

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

• Веб-разработка
• JavaScript
• Node.JS
• ReactJS
• Поисковая оптимизация