"Совершенство достигается не тогда, когда больше нечего добавить, а скорее тогда, когда больше нечего отнять". - Антуан де Сент-Экзюпери
Мы все ❤️ SPA. В любой форме. Даже неважно, на какой платформе был сделан React, Vue, Angular или даже Vanilla кодинг.
Добиться более высокого рейтинга, скармливая краулеру статический HTML вашего Javascript-сайта, без ущерба для опыта ваших клиентов? Именно эта идея и собрала нас здесь.
Вчера и сегодня
Server-Side Rendering (SSR) хорошо работал в течение десятилетий. На сторону клиента передавались уже разобранные HTML-данные. Затем браузер легко вытеснял все на пользовательский интерфейс без дополнительной работы. Если что-то было изменено, страницу нужно полностью перезагрузить и заново инициализировать из бэкенда.
😳 Подождите секунду, но я же влюблен в одностраничную разработку! Это не должно вас волновать, так как SSR отлично работает со SPA. Вы можете найти множество фреймворков вроде next.js или даже создать все с нуля. Таким образом, вы всегда получите статичный сайт с поддержкой SEO. Мир спасен 🌈.
Единственный вопрос, который должен крутиться в вашей голове с тех пор, как вы услышали о SSR, должен быть связан с Client-Side Rendering (CSR). Да, мы все его любим. Я не буду делать огромную остановку на описании всех различий между SSR и CSR (иначе, я уверен, вы бы даже не начали читать эту статью).
Общая идея использования CSR (от которой я в восторге) заключается в том, что вы можете потратить гораздо меньше когнитивных ресурсов, сохраняя при этом баланс сложной архитектуры системы пользовательского интерфейса. Результат можно увидеть в UI мгновенно. Тратить меньше времени на отладку проблем, связанных с бэкендами. Давайте обсудим, что я имею в виду.
Что для этого нужно
Надеюсь, вы любите библиотеку/фреймворк React так же сильно, как и я. Так вот, известный метод React.renderDOM() здесь уже не сработает, потому что DOM API недоступен на сервере. Приходите и перепишите кучу кодовых баз, скажут они 💣 (те, кто любит SSR)!
По крайней мере, измените его в пользу React.hydrate(), избавившись от падения приложения, и начните изучать все больше и больше вещей вокруг SSR (они вам точно понадобятся). Затем, вы можете беспокоиться об управлении состояниями...
💡 Управление состоянием - довольно сложная задача, когда вам нужно написать SSR-ready SPA-приложение.
Добавим сюда инструменты для управления состояниями, такие как redux, и вы получите такую боль в шее при синхронизации не только разметки UI, но и его инициализационных данных, вводимых из бэкенда и заполняемых при первом рендере UI после этого.
Так зачем же заниматься этим и многими другими изнурительными примерами, если технологии могут с легкостью сделать все это за нас?
Что если вы можете писать CSR-код левой рукой, а пить любимые напитки правой (или наоборот 🍹😎 )? Что если вы все еще можете получить доступ к DOM API без паники, что что-то в вашем приложении начнет падать из-за SSR. Что если... Да, этот список может быть длиннее спагетти, и если вы уже так же, как и я, хотите избавиться от всего этого, давайте перейдем к сути.
Должен быть выход. Это всегда так.
Это стало реальностью, как только Google понял, насколько популярны статические приложения в течение последних 10 лет. Легче, быстрее и востребованы по причине. Это огромный скачок в веб-кодировании, и SEO тоже должно развиваться. После короткого анонса в 2015 году было объявлено, что их краулинговые роботы стали способны анализировать динамические веб-страницы на стороне клиента (например, статические SPA).
Несмотря на это, иногда могут возникать подводные камни. Нет никакой гарантии, что необходимые ресурсы страницы (изображения/css/data) будут получены до того, как робот решит взять тайм-аут :(.
Вскоре после того, как Google объявил, что разработчики могут создать скриншот веб-страницы (не файл .png/.jpg/.webp/.svg ;)) под названием Dynamic Rendering. Полностью пререндеренный HTML хранится на нашей стороне.
💡 Dynamic Rendering - это предложенное Microsoft решение для рендеринга JavaScript, вы можете найти больше информации в их документации для разработчиков.
Как только роботы попадают на веб-страницу, промежуточное программное обеспечение бэкенда перехватывает запрос, чтобы отправить настоящий SEO-оптимизированный снимок экрана обратно движку краулера. В то время как конечный пользователь получит свой обычный пакет HTML + CSS + JS для разворачивания. В общем, сервер становится способным различать человека и робота, предоставляя человеку полный опыт, а роботу - облегченную HTML-версию.
Как настроить динамический рендеринг
Базовая конфигурация может быть довольно простой.
Затем определите, требуется ли пользовательским агентам контент для настольных или мобильных компьютеров. Используйте динамическое обслуживание для предоставления соответствующей настольной или мобильной версии.
Это общая абстракция о том, как это работает. Если вы хотите прочитать больше, посетите официальную страницу Google.
Настройка Prerender.io
Ну, довольно просто, не так ли?
Увеличение масштаба
Если вам интересно узнать больше и дальше, то стоит начать копаться в официальном репозитории Prerender.io на Github. Там вы можете найти продвинутые ресурсы о тестировании снапшотов, настройке или даже написании собственного сервера для хранения снапшотов 🌀.
Подведение итогов
Я буду светиться от счастья 😇, если вы найдете эту статью полезной. Также, поднимите обсуждение, если вы чувствуете, что я что-то упустил или SSR все еще может сделать отличную работу.
Когда-нибудь весь этот беспорядок вокруг SEO исчезнет и ИИ будет контролировать планету. А пока это в процессе :) давайте будем благодарны таким командам как Prerender.io, которые делают рутину наших разработчиков намного проще!
Итак, если вам не очень нравится писать все самостоятельно, я бы посоветовал вам начать изучать направление Prerender.io. Это довольно интуитивно понятный сервис, с которым легко работать.
