Когда использовать рендеринг на стороне сервера (SSR) в проектах Vue.js
В сообществе все еще остается много вопросов о рендеринге на стороне сервера (SSR), и когда его использовать, есть несколько моментов, которые мы рассмотрим прямо сейчас в этой статье.
Я добавил в заголовке «в проектах Vue.js», но некоторые вещи, обсуждаемые здесь, также будут служить другим технологиям, рендеринг на стороне сервера - это тема, мало обсуждаемая в сообществе, но она набирает силу в тенденции создания SPA, в основном для модернизации фреймворков javascript.
У использования рендеринга на стороне сервера есть свои преимущества и недостатки, но главный вопрос, который у меня возник, когда я столкнулся с возможностью использования на стороне клиента или на стороне сервера, был:
- Когда использовать рендеринг на стороне сервера?
После нескольких вопросов от членов сообщества я решил попытаться разъяснить, что у нас есть в SSR сегодня, как преимущества и недостатки в его использовании, и я немного расскажу о том, через что я прошел, когда настраивал его вручную, помимо разговоров об основных инструментах для SSR, таких как Nuxt Framework.
Что мы обнаруживаем при использовании рендеринга на стороне сервера?
- SEO
Сканеры поисковых систем, такие как Google, Bing и другие, должны четко понимать, что они найдут в своем контенте, потому что сканеры не поддерживают JavaScript.
Обновление: Google и Ask уже поддерживают с хорошей надежностью, но Bing, объявивший, что рендеринг и индексирование Javascript по-прежнему несовместимы. Я оставлю в последовательности две статьи, в которых рассказывается о том, как обстоят дела у Google и Bing.
- Https://medium.com/@l.mugnaini/spa-and-seo-is-googlebot-able-to-render-a-single-page-application-1f74e706ab11
- Https://www.screamingfrog.co.uk/bing-javascript/
Когда мы используем клиентское приложение, как уже сказано в названии, контент загружается почти всегда после его доступности в браузере, что затрудняет идентификацию контента через ваш HTML-файл и индексацию вашей страницы.
Другая встречающаяся проблема заключается в том, что социальные сети также не могут идентифицировать контент, когда они пытаются получить доступ к вашей странице, чтобы собрать информацию и установить данные для общего доступа, и это также плохо для сайтов, которым требуется такое взаимодействие.
Решение состоит в том, что при использовании SSR перед обслуживанием браузера в вашем приложении происходит процесс монтирования HTML-документа, соответствующего запросу, если вам нужны данные из вашего API, сервер сам подаст заявку и будет обрабатывать ответ, пока не вставит его в HTML перед отправкой клиенту. Такой подход позволяет сканерам также получать полный контент, что упрощает его анализ и индексирование. Так и с социальными сетями.
Поэтому, если вашему приложению нужен такой подход, вам нужно будет использовать рендеринг на стороне сервера, что между нами является самой большой и самой важной причиной при принятии решения, использовать ли рендеринг на сервере.
Некоторое время назад я сделал статью для Vue.js Brazil, в которой рассказывалось о новинке Google, которая заключалась в возможности рендеринга JavaScript в определенных ситуациях с помощью опции fetch as Google в инструментах Google для веб-мастеров.
- Перформанс (да и нет)
Когда пользователь запрашивает страницу, ему не нужно ждать загрузки JavaScript, прежде чем отобразится контент, поскольку компоненты уже были обработаны на сервере и преобразованы в теги HTML, что неплохо для медленных интернет-пользователей и устройств. Это улучшает взаимодействие с пользователем, но интерактивность приложения будет происходить только при правильной загрузке JavaScript и Vue.
Это улучшает взаимодействие с пользователем, но интерактивность приложения будет происходить только при правильной загрузке JavaScript и Vue.
Нет в названии этого раздела заключается в том, что, даже если вы иногда проявляете осторожность с SSR, вы даете серверу больше работы, и в зависимости от того, что вам нужно при рендеринге HTTP-ответа клиенту, это займет немного больше времени.
Причина этой задержки иногда связана с интенсивной обработкой, которая происходит на сервере в каждом запросе, или если вашему приложению требуются данные от внешнего API, где серверу придется ждать ответа, чтобы иметь возможность отобразить приложение, вызывающее размер вашего HTML будет больше.
Это не критический фактор, но в зависимости от того, что будет загружено, он может стать громоздким
Я практически подробно описал здесь плюсы и минусы использования SSR, когда дело касается производительности. Чтобы улучшить это, по возможности используйте мощность кеша.
- Ограничения при использовании рендеринга на стороне сервера
Одна из самых больших проблем, с которыми я столкнулся при использовании SSR, была при использовании сторонних библиотек, которые отображали компоненты, необходимые для доступа к определенным переменным, доступным только в браузере, я говорю о window, document и так далее. Один из хаков, который мне понадобился, состоял в том, чтобы смоделировать среду DOM на узле с JS-DOM, при этом ошибки прекратились, но рендеринг все еще был ограничен.
Другое дело, что в Vue.js есть некоторые методы жизненного цикла, которые мы знаем как (хуки жизненного цикла), которые вызываются только в браузере (beforeMount e mounted) , если вы визуализируете что-то, что запускается этими хуками, этого не произойдет на сервере.
Некоторые внешние библиотеки также необходимо адаптировать для использования в приложениях, использующих SSR, постепенно экосистема вытягивает это и начинает обновлять и поддерживать.
Когда использовать рендеринг на стороне сервера?
- Если вам нужна SEO в Google, Yahoo, Bing и других;
- Если вам нужно, чтобы ваш контент публиковался в социальных сетях;
- Если вы ищете альтернативу для улучшения взаимодействия с пользователем и производительности;
- Если у вас есть ресурсы для найма и обслуживания серверов, особенно если вы ожидаете большого пользовательского трафика. У вас также должна быть хорошая стратегия кеширования.
Что нам нужно сделать, чтобы запустить приложение SSR com Vue.js?
- Nuxt Framework
Nuxt - это фреймворк для создания универсальных приложений с Vue.js, и он пришел к решению ужасающей задачи выполнения всей конфигурации, необходимой для использования серверного рендеринга с Vue.js, вдохновленный Next.js, который представляет собой универсальный фреймворк, созданный для ReactJS.
Его уже можно рассматривать как официальный фреймворк Vue.js для приложений SSR, но он выходит за рамки этого. Это сообщество, которое создает экосистему специальных модулей, ориентированных на этот тип подхода, предлагает вам простой опыт разработки для написания компонентов файла vue. Он также предлагает захватывающие функции, которые помогают в разработке, такие как асинхронные данные, промежуточное ПО, макет и так далее.
Кроме того, он имеет генератор статических сайтов с использованием prerender-spa-plugin и генерирует страницы вашего SPA-приложения без необходимости использования сервера. Важное замечание: он не отображает динамические страницы. Если у вас есть блог, лучше использовать SSR.
Вы можете воспользоваться курсом, подготовленным инструктором Максимилианом Шварцмюллером в Udemy под названием «Nuxt.js - Vue.js на стероидах».
- Другие интересные сооружения
- Ream: похож на Nuxt, с той разницей, что у вас больше свободы при разработке приложения;
- Vue-ssr-starter-kit: Vue 2.0, vue-router и стартовый набор vuex для рендеринга на стороне сервера с помощью webpack 2.0;
- Vue-ssr-markerplate: шаблон рендеринга на стороне сервера Vue.js без загрязнения Vuex;
- Vueniverse: полный стек, пользовательский, PWA, шаблон Vue;
Если у вас есть вопрос, если я забыл что-то адресовать, оставьте свой комментарий, поделитесь своим опытом работы с SSR. увидимся в следующем посте.
