Производительность компонентов React Server в SEO
Итак, это довольно новая тема, недавно были выпущены серверные компоненты React, по сравнению с SSR/Next.js, как это влияет на SEO?
Поскольку компонент отображается на сервере динамически, когда он запрашивается, он на самом деле не такой статичный, как SSR, такой как Next.js, не сможет ли поисковая система проиндексировать этот компонент, если я его использую?
Демо можно найти здесь
Мы можем видеть это в
api.server.js
,
async function renderReactTree(res, props) {
await waitForWebpack();
const manifest = readFileSync(
path.resolve(__dirname, '../build/react-client-manifest.json'),
'utf8'
);
const moduleMap = JSON.parse(manifest);
pipeToNodeWritable(React.createElement(ReactApp, props), res, moduleMap);
}
function sendResponse(req, res, redirectToId) {
const location = JSON.parse(req.query.location);
if (redirectToId) {
location.selectedId = redirectToId;
}
res.set('X-Location', JSON.stringify(location));
renderReactTree(res, {
selectedId: location.selectedId,
isEditing: location.isEditing,
searchText: location.searchText,
});
}
Я понимаю, что это может помочь снизить нагрузку на клиентское устройство, поскольку компонент отображается на сервере и отправляется клиенту, и что компонент может отображаться с секретом, хранящимся на сервере, поскольку мы можем просто передать его в качестве реквизита, а не мы отправляем секрет клиенту.
Но если SEO имеет значение, предпочтительнее ли SSR, чем React Server Component?
2 ответа
Серверные компоненты дополняют рендеринг в HTML, а не альтернативу. План состоит в том, чтобы иметь оба.
Серверные компоненты не были выпущены. То, что было выпущено, — это ранний технический предварительный просмотр в духе нашего исследования. Эта предварительная версия не включает средство визуализации HTML.
api.server.js
файл из упомянутой вами демонстрации содержит комментарий по этому поводу:
const html = readFileSync(
path.resolve(__dirname, '../build/index.html'),
'utf8'
);
// Note: this is sending an empty HTML shell, like a client-side-only app.
// However, the intended solution (which isn't built out yet) is to read
// from the Server endpoint and turn its response into an HTML stream.
res.send(html);
К тому времени, когда серверные компоненты будут официально выпущены, для первого рендеринга появится потоковый HTML-рендерер.
Он еще не построен.
С точки зрения SEO он должен быть таким же, как SPA.
Что происходит с классическим React SPA, так это то, что он загружает компоненты React (которые по сути являются функциями JS) как часть пакета JS, а затем начинает запрашивать данные из бэкэнда в формате JSON. После получения JSON он обрабатывается с помощью функций компонента React и вставляется в DOM. Современные сканеры используют движок V8 (или, может быть, что-то еще, если это Bing:D), они ждут, пока страница полностью загрузится, все данные JSON будут загружены, а все компоненты будут фактически отображены, а затем сканирует полученный DOM.
GoogleBot сканирует SPA таким образом уже как минимум 3 года, а возможно, и больше, поэтому, если вы думаете, что SSR необходим для SEO, нет, это не так. Было проведено множество расследований этого случайного примера: https://medium.com/@l.mugnaini/spa-and-seo-is-googlebot-able-to-render-a-single-page-application-1f74e706ab11 .
Так что, по сути, для сканера не имеет большого значения, как именно отображается компонент React. В случае компонентов React Server функция компонента находится на сервере и никогда не передается клиенту как часть пакета JS. Таким образом, вместо запроса данных JSON приложение запрашивает визуализированный компонент в каком-то промежуточном формате (не HTML, кстати). Результат этого передается клиенту и отображается в DOM. Так что конечный результат все тот же — это некоторые элементы DOM, которые бот может сканировать.