Що таке серверний рендеринг (SSR) у Vue.js?

Vue.js – це платформа для створення клієнтських додатків. За замовчуванням компоненти Vue створюють і маніпулюють DOM у браузері як виведення. Однак, також можливо перетворити ті самі компоненти на рядки HTML на сервері, надіслати їх безпосередньо в браузер і, нарешті, “гідратувати” статичну розмітку в повністю інтерактивний застосунок на клієнті. Застосунок Vue.js, що відображається на сервері, також можна вважати “ізоморфним” або “універсальним” у тому сенсі, що більша частина коду вашого застосунку виконується як на сервері, так і на клієнті.

Чому SSR?

Порівняно з односторінковим додатком на стороні клієнта (SPA) перевага SSR насамперед полягає в:

• швидшому отриманні контенту: це більш помітно за повільного Інтернету або повільних пристроїв. Розмітці, що відображається на сервері, не потрібно чекати, поки весь JavaScript буде завантажений і виконаний для відображення, тому ваш користувач побачить повністю візуалізовану сторінку раніше. Крім того, вибірка даних виконується на стороні сервера під час першого відвідування, що, ймовірно, забезпечує більш швидке з’єднання з вашою базою даних, ніж клієнт. Зазвичай це призводить до поліпшення показників Core Web Vitals, поліпшення користувацького досвіду і може мати вирішальне значення для застосунків, де час створення контенту безпосередньо пов’язаний з коефіцієнтом конверсії.
• єдиною ментальною моделлю: ви можете використовувати одну й ту саму мову та одну й ту саму декларативну, компонентно-орієнтовану ментальну модель для розроблення всього вашого застосунку, замість того, щоб стрибати туди-сюди між внутрішньою системою шаблонів і зовнішнім середовищем.
• кращому SEO: сканери пошукових систем будуть безпосередньо бачити повністю відмальовану сторінку.

Порада. Наразі Google і Bing прекрасно індексують синхронні додатки JavaScript. Ключове слово тут – синхронність. Якщо ваш застосунок запускається з лічильником завантаження, а потім витягує контент через Ajax, сканер не чекатиме, поки ви закінчите. Це означає, що якщо у вас асинхронно завантажується контент на сторінках, для яких важлива SEO, може знадобитися SSR.

Під час використання SSR також слід враховувати деякі компроміси:

1. Обмеження розвитку. Код, специфічний для браузера, можна використовувати тільки всередині певних перехоплювачів життєвого циклу; деяким зовнішнім бібліотекам може знадобитися спеціальне опрацювання, щоб їх можна було запускати в застосунку, що відображається на сервері.
2. Складніші вимоги до налаштування і розгортання збірки. На відміну від повністю статичного SPA, який можна розгорнути на будь-якому статичному файловому сервері, для застосунку, що відображається на сервері, потрібне середовище, у якому може працювати сервер Node.js.
3. Більше навантаження на сервер. Рендеринг повного додатка в Node.js буде більш ресурсомістким, ніж просто обслуговування статичних файлів, тому, якщо ви очікуєте високий трафік, будьте готові до відповідного навантаження на сервер і розумно використовуйте стратегії кешування.

Перш ніж використовувати серверну візуалізацію vue js для свого додатка, перше питання, яке вам слід поставити: чи дійсно він вам потрібен. Здебільшого це залежить від того, наскільки важливим є час створення контенту для вашої програми. Наприклад, якщо ви створюєте внутрішню панель моніторингу, де додаткові кілька сотень мілісекунд під час початкового завантаження не мають великого значення, SSR буде зайвим. Однак, у тих випадках, коли час доставки контенту має вирішальне значення, SSR може допомогти вам досягти максимально можливої продуктивності під час початкового завантаження.

SSR проти SSG

Статична генерація сайту (SSG), також звана попередньою візуалізацією, – ще один популярний метод створення швидких веб-сайтів. Якщо дані, необхідні для візуалізації сторінки на сервері, однакові для кожного користувача, то замість візуалізації сторінки кожного разу, коли надходить запит, ми можемо візуалізувати її тільки один раз, заздалегідь, під час процесу складання. Попередньо оброблені сторінки генеруються та обслуговуються як статичні HTML-файли.

SSG зберігає ті самі характеристики продуктивності, що й додатки SSR: він забезпечує відмінний час обробки контенту. Водночас його дешевше і простіше розгортати, ніж додатки SSR, оскільки на виході виходить статичний HTML і ресурси. Ключове слово тут статичне: SSG можна застосовувати тільки до сторінок, які споживають статичні дані, тобто дані, які відомі під час складання і не змінюються між розгортаннями. Щоразу, коли дані змінюються, потрібне нове розгортання.

Якщо ви вивчаєте SSR тільки для поліпшення SEO декількох маркетингових сторінок (наприклад, /, /about, /contact тощо), то вам, імовірно, потрібен SSG замість SSR. SSG також чудово підходить для змістовних веб-сайтів, таких як сайти документації або блоги. Фактично, цей веб-сайт, який ви зараз читаєте, статично створений за допомогою VitePress, генератора статичних сайтів на базі Vue.

FoxmindEd – це навчальний центр, що має велику різноманітність напрямків курсів для новачків та програмістів з досвідом!

Тільки починаєте свій шлях в ІТ? Спробуйте курси Start

Вже маєте базові навички програмування? Тоді
курси Junior саме для вас.

Хочете поглибити свої знання в ІТ? Ми маємо курси Middle/Senior

Рендеринг додатка

Давайте подивимося на найпростіший приклад Vue SSR у дії.

1. Створіть новий каталог і перейдіть у нього.
2. Запустіть npm init -y.
3. Додайте “type”: “module” у package.json, щоб Node.js працював у режимі модулів ES.
4. Запустіть npm install vue.
5. Створіть файл example.js:

// this runs in Node.js on the server.

import { createSSRApp } from 'vue'

// Vue's server-rendering API is exposed under `vue/server-renderer`.

import { renderToString } from 'vue/server-renderer'

const app = createSSRApp({

  data: () => ({ count: 1 }),

  template: `<button @click="count++">{{ count }}</button>`

})

renderToString(app).then((html) => {

  console.log(html)

})

Потім запустіть:

node example.js

У командному рядку має бути надруковано таке:

<button>1</button>

Рішення вищого рівня

Перехід від прикладу до готового до використання SSR-додатку вимагає набагато більшого. Нам знадобиться: підтримка Vue SFC та інші вимоги до етапів складання. Фактично нам потрібно буде узгодити дві збірки однієї й тієї самої програми: одну для клієнта й одну для сервера.

Порада. Компоненти Vue компілюються по-іншому під час використання для SSR – шаблони компілюються в конкатенації рядків замість функцій візуалізації Virtual DOM для ефективнішої продуктивності візуалізації.

В обробнику запитів сервера візуалізуйте HTML з правильними посиланнями на ресурси на стороні клієнта та оптимальними підказками до ресурсів. Нам також може знадобитися переключитися між режимами SSR і SSG або навіть змішати обидва режими в одному додатку.

Керуйте маршрутизацією, отриманням даних і сховищами управління станом універсальним способом.

Повна реалізація буде досить складною і залежить від набору інструментів збірки, який ви обрали для роботи. Тому ми настійно рекомендуємо використовувати самовпевнене рішення вищого рівня, яке позбавить вас складнощів. Нижче ми представимо кілька рекомендованих рішень SSR в екосистемі Vue.

1. Nuxt​

Nuxt – це платформа вищого рівня, побудована на основі екосистеми Vue, яка забезпечує оптимізований процес розробки для написання універсальних додатків Vue. А ще краще, ви також можете використовувати його як генератор статичних сайтів. Ми настійно рекомендуємо це спробувати.

2. Quasar​

Quasar – це комплексне рішення на основі Vue, яке дає змогу використовувати SPA, SSR, PWA, мобільний застосунок, настільний застосунок і розширення браузера, використовуючи одну базу коду. Він не тільки виконує налаштування збірки, але також надає повну колекцію компонентів користувацького інтерфейсу, сумісних з Material Design.

3. Vite SSR

Vite надає вбудовану підтримку рендерингу на стороні сервера Vue, але вона навмисно низькорівнева. Якщо ви хочете використовувати Vite безпосередньо, скористайтеся vite-plugin-ssr, плагіном спільноти, який дозволяє абстрагуватися від багатьох складних деталей. Тут ви також можете знайти приклад проекту Vue + Vite SSR з використанням ручного налаштування, який може слугувати основою для подальшого розвитку. Зверніть увагу, що це рекомендується тільки в тому випадку, якщо у вас є досвід роботи з інструментами SSR/збірки і ви дійсно хочете мати повний контроль над архітектурою вищого рівня.

Написання коду, дружнього до SSR

Незалежно від ваших налаштувань збірки або вибору платформи вищого рівня, існують певні принципи, які застосовуються у всіх додатках Vue SSR.

Реактивність на сервері

Під час SSR кожну URL-адресу запиту зіставляють із бажаним станом нашого застосунку. Ніякої взаємодії з користувачем і оновлень DOM немає, тому реактивність на сервері не потрібна. За замовчуванням реактивність під час SSR вимкнено для підвищення продуктивності.

Перехоплювачі життєвого циклу компонентів

Оскільки динамічних оновлень немає, перехоплювачі життєвого циклу, як-от onMounted або onUpdated, НЕ викликатимуться під час SSR і виконуватимуться тільки на клієнті.

Вам слід уникати коду, який створює побічні ефекти, що вимагають очищення в setup() або кореневій області <script setup>. Прикладом таких побічних ефектів є налаштування таймерів за допомогою setInterval. У коді тільки на стороні клієнта ми можемо встановити таймер, а потім вимкнути його в onBeforeUnmount або onUnmounted. Але, оскільки перехоплювачі розмонтування ніколи не будуть викликатися під час SSR, таймери залишаться увімкненими назавжди;

Щоб уникнути цього, перемістіть код побічного ефекту в onMounted.

Доступ до API-інтерфейсів, специфічних для платформи

Універсальний код не може припускати доступ до API-інтерфейсів, специфічних для платформи, тому, якщо ваш код безпосередньо використовує глобальні змінні тільки для браузера, як-от вікно або документ, вони видаватимуть помилки під час виконання в Node.js, і навпаки.

Для завдань, які спільно використовуються сервером і клієнтом, але з різними API-інтерфейсами платформи, рекомендується обернути реалізації для конкретної платформи в універсальний API або використовувати бібліотеки, які зроблять це за вас. Наприклад, ви можете використовувати node-fetch, щоб використовувати один і той самий API вибірки як на сервері, так і на клієнті.

Для API тільки для браузера загальний підхід полягає в ледачому доступі до них усередині обробників життєвого циклу тільки для клієнта, таких як onMounted. Зверніть увагу: якщо стороння бібліотека не написана з урахуванням універсального використання, її може бути складно інтегрувати в додаток, що відображається на сервері. Можливо, вам вдасться змусити його працювати, імітуючи деякі глобальні змінні, але це буде по-хакерськи і може перешкодити коду визначення середовища інших бібліотек.

Висновок

Насамкінець можна підбити підсумки щодо значення та переваг використання серверного рендерингу (SSR) у розробці додатків на Vue.js. SSR дає змогу поліпшити продуктивність застосунку завдяки попередньому відтворенню сторінок на сервері перед надсиланням на клієнт, що збільшує швидкість завантаження і покращує SEO-оптимізацію. Це особливо важливо для проєктів, де важлива швидкість завантаження та індексація контенту пошуковими системами.

Переваги використання SSR у Vue.js охоплюють кращу оптимізацію продуктивності, підвищення SEO-показників, поліпшену користувацьку інтерактивність і кращу підтримку для соціальних мереж під час обміну посиланнями на вміст.

Для подальшого вивчення та застосування SSR у проєктах на Vue.js рекомендується:

• Вивчити документацію Vue.js і зрозуміти основні принципи роботи серверного рендерингу.
• Провести практичні експерименти з реалізацією SSR у своїх проєктах для кращого розуміння механізмів роботи.
• Вивчити можливості оптимізації SSR для поліпшення продуктивності та користувацького досвіду.
• Стежити за останніми тенденціями та найкращими практиками в галузі SSR, щоб ефективно застосовувати їх у своїх проєктах.

Таким чином, використання серверного рендерингу в Vue.js може значно поліпшити продуктивність і оптимізацію додатків, що робить його важливим інструментом для розробників, які прагнуть створення швидких, масштабованих і оптимізованих веб-додатків з високим рівнем користувацького досвіду!