SSR: ключевой элемент сайта, который требует особого внимания

Сегодня поговорим про 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

Leave a Comment

Your email address will not be published. Required fields are marked *