Сегодня поговорим про SSR — что это, зачем использовать, как с этим работать, чтобы все получалось.
Что такое SSR?
SSR — это Server Side Rendering, то есть, генерация страницы на стороне сервера, а не в браузере, когда сервер отдает уже сгенерированный HTML.
Любая страница сайта или простейшая веб-версия приложения — это HTML-код, который отображается в браузере в виде набора визуальных элементов — текстовых блоков, изображений, ссылок и кнопок. Рендеринг — сборка html кода для браузера пользователя, из блоков кода исходного vue-файла. Это происходит тогда, когда мы заходим на сайт — то есть, отправляем запрос на сервер, а с него получаем js-код vue приложения, html c пустыми местами, в которые будет рендериться контент уже на стороне пользователя. И, конечно, мы хотели бы, чтобы это происходило моментально.
Отобразить сайт в браузере с уже сгенерированным HTML занимает меньше времени, чем когда код генерируется в браузере, затрачивая при этом дополнительные ресурсы пользователя. Особенно это заметно на медленном интернете или на устройствах, в которых забита память.
Для этого и существует SSR. При этом методе весь HTML-код страницы генерируется на сервере и передается пользователю в браузер.
Какие боли решает метод SSR?
Во-первых, производительность этого метода сильно выше — мощности сервера сильно превосходят мощности принимающей стороны, а, значит не нужно будет рендерить страницу на стороне клиента перед отображением.
Во-вторых, у такого контента более качественная SEO-оптимизация. Страница, сгенерированная на сервере, уже содержит весь текст, и поисковые машины сразу могут корректно индексировать его и поднять в топ релевантной выдачи. Если сайт генерируется на стороне пользователя, то поисковый робот не увидит этот контент.
Какие потенциальные проблемы могут возникнуть при работе с SSR?
Фронтедер пишет код, используя Vue фреймворк, в его файлах содержится HTML разметка, JS – функции и стили сайта. Из этих блоков собирается внешний вид элементов сайта или целых страниц. При деплое кода сайта на проде или на стейдже он билдится автоматически, и если допустить ошибку во Vue-файле, то генерация кода будет нарушена — при деплое могут “отвалиться” элементы сайта, поехать вся вёрстка, нарушиться структура работы кнопок и ссылок. Это не только помешает пользователю видеть нужный контент, но и сделает сайт недоступным для поисковых роботов.
Также важно учитывать, какой скрипт во Vue.js функционирует на стороне пользователя (то есть, браузера), а какой — на стороне сервера. Существуют определённые методы, которые могут быть вызваны только на стороне пользователя. Если мы будем пытаться вызывать их на стороне сервера, это тоже может привести к ошибке — и на деплое также всё пойдёт наперекосяк, и билд не соберётся.
Разницу в работе скриптов на стороне сервера и на стороне браузера важно учитывать при проектировании архитектурных решений. На каждом этапе жизненного цикла кода нужно следить за правильным исполнением, особенно пристально стоит обращать на это внимание на этапах:
-
beforeCreate
-
created
-
beforeMount
-
mounted
-
beforeUpdate
-
updated
-
activated
-
deactivated
-
beforeDestroy
-
destroyed
Необходимо заранее продумать структуру кода так, чтобы скрипты, которые вызываются только на фронте (в браузере), не вызывались на бэкенде. Это нужно учитывать не только на этапе разработки, но и на этапе ревью и внедрения доработок — даже если визуально код выглядит рабочим, если логика разделения скриптов не соблюдена, могут проявиться ошибки. Например, если по ошибке обратиться к обьекту window в хуке, в котором он не доступен, например mounted, то это приведет к развалу vue-файла приложения, что в итоге развалит и весь SSR.
Есть и другая потенциальная проблема — она может возникать, когда мы получаем какие-либо данные с бэка для фронта. Если на бэке закралась какая-то ошибка, что и SSR будет работать некорректно. Страница при этом может отображаться нормально и казаться такой же, но рендера на сервере происходить не будет — всё на себя примет браузер.
Основные принципы работы с SSR, чтобы всё было хорошо
Учитывая фатальность возможной допущенной ошибки в логике Vue-файла или в данных с бэка, работа с SSR требует дотошности проверки на всех этапах — review кода, чекапы после любых доработок, тестирование на стейдже и даже регресс-тестирование.
Очень важно после каждого деплоя проверять, насколько корректно работает SSR. Это можно делать с помощью автотеста, а можно отключить на странице выполнение js-кода и попробовать открыть ее. При таком решении как результат мы должны увидеть только те части фронта, которые были запланированы, а не весь сайт. Если это происходит не так, значит, SSR не работает. Это очень важно отлавливать после релиза — если допустить ошибку, при кажущейся корректной работе страницы поисковики не будут находить ее, так как страница будет рендериться на стороне пользователя.
Ещё один важный пункт — опытные разработчики. Не у всех фронтендеров есть опыт работы с SSR, и это тоже надо учитывать — чем больше опыта работы с рендером на сервере есть у разработчика, тем корректнее он создаст Vue-файл. Мы обязательно обращаем внимание на наличие такого навыка при найме новых сотрудников, для нас это супер-важно.
Monstro – сервис для продвижения сайтов и услуг
https://t.me/monstrotraf