Сегодня поговорим про 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‑файл. Мы обязательно обращаем внимание на наличие такого навыка при найме новых сотрудников, для нас это супер‑важно.
