SSG, SSR та ISR: Розуміння сучасних стратегій рендерингу веб-сторінок

У світі веб-розробки, що постійно розвивається, вибір правильної стратегії рендерингу став критично важливим для створення ефективних, масштабованих і зручних для користувача веб-додатків. Три підходи виділилися як лідери у сучасному веб-рендерингу: Статична генерація сайтів (SSG), Рендеринг на стороні сервера (SSR) та Інкрементальна статична регенерація (ISR). Кожна з цих стратегій пропонує унікальні переваги та компроміси, які підходять для різних типів веб-додатків та сценаріїв використання.

У міру того, як веб-програми стають все більш складними, а очікування користувачів щодо продуктивності та інтерактивності продовжують зростати, розробники та організації стикаються з проблемою вибору найбільш відповідного методу рендерингу. Вибір між SSG, SSR та ISR може суттєво вплинути на різні аспекти веб-програми, включаючи продуктивність, оптимізацію для пошукових систем (SEO), складність розробки та частоту оновлення контенту.

Ця стаття покликана надати всебічний порівняльний аналіз цих трьох стратегій рендерингу, заглиблюючись у їхню механіку, переваги, обмеження та ідеальні випадки використання. Розуміючи нюанси SSG, SSR та ISR, розробники та особи, які приймають рішення, будуть краще підготовлені до прийняття обґрунтованих рішень, що відповідають вимогам їхніх проектів та бізнес-цілей.

Статична генерація сайтів (SSG)

Що таке SSG?

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

Як працює SSG

1. Створення контенту: Розробники створюють контент, часто використовуючи файли markdown або безголову CMS.
2. Процес складання: Під час складання інструмент SSG (наприклад, Gatsby, Next.js або Hugo) витягує дані із джерел контенту.
3. Генерація сторінок: Потім інструмент генерує статичну HTML-сторінку для кожного маршруту в додатку.
4. Оптимізація ресурсів: CSS, JavaScript та інші ресурси оптимізуються в процесі збирання.
5. Розгортання: Отримані статичні файли розгортаються на CDN або веб-сервері.
6. Обслуговування: Коли користувач запитує сторінку, попередньо створений HTML надається безпосередньо, без обробки на стороні сервера.

Переваги SSG

1. Продуктивність: Статичні сторінки завантажуються дуже швидко, оскільки вони попередньо створені і можуть кешуватися на рівні CDN.
2. Безпека: Відсутність рендерингу на стороні сервера зменшує поверхню атаки для потенційних вразливостей
3. Масштабованість: Статичні файли легко розповсюджувати по кількох CDN, що робить їх високо масштабованими.
4. SEO-дружелюбність: Пошукові системи можуть легко сканувати та індексувати статичні HTML-сторінки.
5. Економічність: Хостинг статичних файлів зазвичай дешевше, ніж запуск серверних програм.

Обмеження SSG

1. Час складання: Для великих сайтів процес складання може бути тривалим.
2. Динамічний контент: Складно увімкнути контент у реальному часі або специфічний для користувача.
3. Часті поновлення: Якщо контент часто змінюється, необхідно перебудовувати та повторно розгортати весь сайт.
4. Інтерактивність: Хоча статичні сайти можуть включати JavaScript для інтерактивності, складну функціональність, подібну до додатків, може бути важче реалізувати.

Випадки використання SSG

SSG особливо добре підходить для:

1. Блогів та сайтів з великою кількістю контенту
2. Маркетингових сайтів
3. Сайтів документації
4. Портфоліо
5. Сторінок каталогу продуктів електронної комерції
6. Сайтів з контентом, який не змінюється часто

Рендеринг на стороні сервера (SSR)

Що таке SSR?

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

Як працює SSR

1. Запит користувача: Коли користувач переходить на сторінку, запит надсилається на сервер.
2. Отримання даних: Сервер отримує необхідні дані з баз даних або API.
3. Генерація HTML: Сервер використовує ці дані для створення повної HTML-сторінки.
4. Початкове завантаження: Сервер відправляє згенерований HTML клієнту, який може бути негайно відрендерений.
5. Гідратація: Потім завантажується JavaScript, що "гідратує" сторінку, роблячи її інтерактивною.
6. Наступні взаємодії: Після початкового завантаження додаток може поводитися як односторінковий додаток (SPA) для більш плавного користувальницького досвіду.

Переваги SSR

1. Оптимізація SEO: Пошукові системи можуть легко сканувати та індексувати контент, відрендерований на сервері.
2. Швидше початкове завантаження: Користувачі бачать контент швидше, особливо на повільніших пристроях або мережах.
3. Динамічний контент: Дозволяє генерувати персоналізований контент у реальному часі
4. Покращена продуктивність для сайтів із великою кількістю контенту: Початкова продуктивність завантаження найкраще для сайтів з великим обсягом контенту.
5. Обмін у соціальних мережах: Надає точні метадані для платформ соціальних мереж

Обмеження SSR

1. Навантаження на сервер: Вимагає більше серверних ресурсів, тому що кожен запит потребує обробки на сервері.
2. Повільніше TTFB (Time To First Byte): Час створення контенту на сервері може затримати початкову відповідь.
3. Складність: SSR може додати складності в архітектуру програми та процес розгортання.
4. Обслуговування: Вимагає підтримки серверного середовища Node.js
5. Проблеми з кешуванням: Динамічний контент може бути складніше ефективно кешувати.

Випадки використання SSR

SSR особливо добре підходить для:

1. Контент-орієнтованих веб-сайтів, які потребують частих оновлень
2. Платформ електронної комерції з динамічним ціноутворенням та інвентарем
3. Платформ соціальних мереж з контентом користувача
4. Новинних сайтів з контентом у реальному часі
5. Веб-додатків, які потребують аутентифікації користувачів та персоналізованого досвіду
6. Веб-сайтів, орієнтованих на ринки з повільнішим інтернет-з'єднанням

Інкрементальна статична регенерація (ISR)

Що таке ISR?

Інкрементальна статична регенерація (ISR) - це відносно нова стратегія рендерингу, яка поєднує переваги статичної генерації сайтів (SSG) і рендерингу на стороні сервера (SSR). ISR дозволяє створювати або оновлювати статичні сторінки після того, як ви збудували свій сайт.Цей підхід дозволяє насолоджуватися перевагами продуктивності статичних сайтів, при цьому все ще надаючи свіжий контент.

Як працює ISR

1. Початкове складання: Сайт спочатку будується як статичний сайт, зі сторінками, попередньо відрендерованими під час складання.
2. Обслуговування застарілого контенту: Коли надходить запит, негайно обслуговується заздалегідь побудована статична сторінка.
3. Фонова регенерація: Після обслуговування статичної сторінки у фоновому режимі запускається регенерація цієї сторінки.
4. Інвалідація кешу: Як тільки нова версія згенерована, стара версія замінюється в кеші.
5. Ревалідація: Наступні запити отримуватимуть оновлену версію сторінки.

Переваги ISR

1. Продуктивність: Обслуговує статичний контент для швидкого завантаження, дозволяючи при цьому оновлення.
2. Свіжість: Дозволяє частіші оновлення контенту в порівнянні з традиційним SSG.
3. Масштабованість: Може обробляти високе навантаження трафіку так само ефективно, як статичні сайти
4. SEO-дружелюбність: Надає статичний контент для пошукових систем, зберігаючи його відносно актуальним.
5. Скорочений час збирання: Перебудовує тільки необхідні сторінки, а не весь сайт
6. Економічність: Балансує економічні переваги статичного хостингу з можливістю оновлення контенту

Обмеження ISR

1. Кінцева узгодженість: Може бути затримка між оновленнями контенту та тим, коли всі користувачі побачать новий контент.
2. Складність: Вимагає розуміння механізмів кешування та потенціалу застарілого контенту
3. Залежність від фреймворку: В даний час ISR в основному доступний в Next.js, обмежуючи вибір фреймворків.
4. Вимоги до хостингу: Потребує платформи хостингу, яка підтримує ISR (наприклад, Vercel).
5. Не в реальному часі: Хоча і більш динамічний, ніж SSG, не підходить для контенту в реальному часі

Випадки використання ISR

ISR особливо добре підходить для:

1. Сайтів електронної комерції з великими каталогами продуктів, що часто оновлюються.
2. Новинних сайтів або блогів із регулярними, але не постійними оновленнями
3. Сайтів документації, які потребують періодичних оновлень
4. Маркетингових веб-сайтів зі змінним контентом кампаній
5. Великомасштабних веб-сайтів, де перебудова всіх сторінок непрактична
6. Сайтів із сумішшю статичного та динамічного контенту

Порівняння SSG, SSR та ISR

Щоб допомогти вам прийняти обґрунтоване рішення про те, яку стратегію рендерингу використовувати для вашого проекту, давайте порівняємо SSG, SSR та ISR за декількома ключовими факторами:

Продуктивність

• SSG: Пропонує найкращий час початкового завантаження, оскільки сторінки попередньо відрендерені та можуть обслуговуватися безпосередньо з CDN.
• SSR: Початкове завантаження може бути повільніше через обробку на стороні сервера, але забезпечує більш швидкий час до першого байта (TTFB) для динамічного контенту.
• ISR: Забезпечує продуктивність, аналогічну SSG для кешованих сторінок, з можливістю оновлення контенту без повних перебудов.

Вплив на SEO

• SSG: Відмінно підходить для SEO, так як весь контент доступний у початковому HTML
• SSR: Також відмінно підходить для SEO, дозволяючи динамічні мета-теги та свіжий контент.
• ISR: Добре для SEO, поєднуючи переваги SSG з більш частими оновленнями контенту

Складність розробки

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

Масштабованість

• SSG: Високо масштабований, так як статичні файли можна легко поширювати CDN.
• SSR: Масштабованість може бути складним завданням, тому що кожен запит вимагає серверних ресурсів.
• ISR: Пропонує хорошу масштабованість, аналогічну SSG, з додатковою перевагою оновлень контенту.

Частота оновлення контенту

• SSG: Найкраще підходить для контенту, який не змінюється часто Оновлення вимагають повної розбудови сайту.
• SSR: Ідеально підходить для контенту в реальному часі або контенту, що часто змінюється.
• ISR: Добре підходить для контенту, який періодично оновлюється, але не в реальному часі.

Відповідні випадки використання

| Випадок використання SSG | SSR | ISR | |----------------------|-----|-----|-----| | Блог/Документація Відмінно | Добре | Дуже добре | | Електронна комерція Добре для невеликих каталогів Відмінно для великих, динамічних каталогів Дуже добре для великих каталогів з періодичними оновленнями | Новинний сайт | Добре для архівів Відмінно для новин у реальному часі | Дуже добре для новин із періодичними оновленнями | | Веб-додаток | Обмежено | Відмінно | Добре | | Маркетинговий сайт Відмінно | Добре | Дуже добре |

Хостинг та інфраструктура

• SSG: Може розміщуватись на простому хостингу статичних файлів або CDN.
• SSR: Вимагає більш складної серверної інфраструктури та потенційно високих витрат на хостинг.
• ISR: Вимагає специфічних платформ хостингу, які підтримують цю технологію (наприклад, Vercel для Next.js).

Вибір правильної стратегії

Вибір найбільш підходящої стратегії рендерингу для вашого веб-проекту має вирішальне значення для його успіху. Ось структура, яка допоможе вам ухвалити обґрунтоване рішення:

Чинники для розгляду

1. Частота оновлення контенту:
   • Статичний контент: Розгляньте SSG
   • Часті оновлення: SSR може бути краще
   • Періодичні оновлення: ISR може бути ідеальним
2. Вимоги до продуктивності:
   • Найшвидший час початкового завантаження: SSG
   • Дані у реальному часі: SSR
   • Баланс між швидкістю та свіжістю: ISR
3. Важливість SEO:
   • Всі три стратегії можуть бути SEO-дружелюбними, але SSG та SSR можуть мати невелику перевагу для високодинамічного контенту
4. Ресурси розробки:
   • Обмежені ресурси: SSG може бути простіше
   • Досвідчена команда з керуванням сервером: SSR життєздатний
   • Команда, знайома з Next.js: ISR може бути гарним варіантом
5. Потреби в масштабованості:
   • Високий трафік, переважно статичний контент: SSG
   • Динамічний контент із помірним трафіком: SSR
   • Високий трафік із періодичними оновленнями контенту: ISR
6. Інтерактивність користувача:
   • Мінімальна інтерактивність: SSG
   • Висока інтерактивність: SSR або ISR з рендерингом на стороні клієнта
7. Час виходу ринку:
   • Найшвидше розгортання: Часто SSG
   • Необхідність негайних оновлень контенту після запуску: SSR або ISR

Структура ухвалення рішень

1. Почніть з SSG, якщо:
   • Ваш контент не змінюється часто
   • Ви віддаєте пріоритет максимальної продуктивності
   • У вас обмежені серверні ресурси
   • SEO має вирішальне значення, і контент в основному статичний
2. Розгляньте SSR, якщо:
   • Вам потрібен контент у реальному часі або специфічний для користувача
   • Ваш сайт має часті оновлення контенту
   • Вам потрібні динамічні SEO мета-теги
   • Ви створюєте високоінтерактивну веб-додаток
3. Виберіть ISR, якщо:
   • Ви хочете переваги статичних сайтів з більш частими оновленнями
   • У вас великий сайт, де перебудова всіх сторінок непрактична
   • Ви використовуєте Next.js і можете розгорнути на підтримуючих платформах
   • Вам потрібен баланс між продуктивністю та свіжістю контенту
4. Розгляньте гібридний підхід:
   • Багато сучасних фреймворків дозволяють змішувати ці стратегії.
   • Використовуйте SSG для в основному статичних сторінок
   • Реалізуйте SSR для високодинамічних маршрутів
   • Використовуйте ISR для сторінок, які періодично оновлюються

Майбутні тенденції у веб-рендерінгу

З розвитком веб-технологій з'являються нові стратегії рендерингу та оптимізації. Ось погляд на деякі тенденції, що формують майбутнє веб-рендерінгу:

Нові технології

1. Edge Computing:
   • Рендеринг контенту в крайових локаціях, ближче до користувачів
   • Поєднує переваги SSR (свіжий контент) з SSG (швидка доставка)
   • Приклади: Cloudflare Workers, Vercel Edge Functions
2. Потоковий SSR:
   • Прогресивний рендеринг та відправка частин сторінки в міру їхньої готовності
   • Покращує продуктивність, що сприймається, показуючи контент швидше
   • Реалізовано у фреймворках, таких як React 18 та Next.js
3. Часткова гідратація:
   • Вибіркова гідратація інтерактивних частин сторінки
   • Зменшує навантаження JavaScript та покращує час до інтерактивності (TTI)
   • Фреймворки, такі як Astro, є піонерами у цьому підході
4. Архітектура островів:
   • Незалежно відрендеровані, гідратовані компоненти на іншій статичній сторінці
   • Поєднує продуктивність статичного контенту з інтерактивністю там, де це необхідно
   • Реалізовано у фреймворках, таких як Astro та Eleventy
5. WebAssembly (Wasm):
   • Потенціал для складнішої логіки рендерингу на стороні клієнта
   • Може дозволити нові гібридні стратегії рендерингу

Гібридні підходи

1. Розподілений рендеринг:
   • Поєднання кількох стратегій рендерингу в рамках одного додатка
   • Використання SSG для статичних сторінок, SSR для динамічних маршрутів та ISR для періодично оновлюваного контенту
   • Фреймворки, такі як Next.js та Nuxt.js, підтримують цей підхід із коробки
2. Адаптивний рендеринг:
   • Динамічний вибір стратегії рендерингу на основі факторів, таких як пристрій користувача, мережеві умови або тип контенту
   • Може включати машинне навчання для оптимізації рішень щодо рендерингу
3. Мікрофронтенди:
   • Різні частини сторінки рендеруються з використанням різних стратегій
   • Дозволяє більш детальну оптимізацію та автономію команди
4. Безсерверний SSR:
   • Використання безсерверних функцій для SSR для покращення масштабованості
   • Зменшує накладні витрати на управління інфраструктурою
5. Прогресивне покращення з SSG:
   • Початок зі статичної бази та прогресивне покращення динамічним контентом
   • Покращує час початкового завантаження, дозволяючи при цьому багату інтерактивність

З розвитком цих тенденцій ми можемо очікувати появи більш нюансованих і складних стратегій рендерингу, які розмивають межі між традиційними підходами SSG, SSR та ISR. Майбутнє веб-рендерингу, ймовірно, буде включати адаптивніші, контекстно-залежні рішення, які можуть забезпечити оптимальний баланс продуктивності, свіжості та інтерактивності для кожного унікального випадку використання.

Розробники повинні бути в курсі цих нових тенденцій і бути готовими адаптувати свої стратегії рендерингу з розвитком нових технологій і кращих практик.

Часті питання (FAQ)

Питання: У чому основна різниця між SSG, SSR та ISR?

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

З: Яка стратегія рендерингу найкраще підходить для SEO?

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

З: Чи можу я використовувати різні стратегії рендерингу для різних сторінок у моїй програмі?

В: Так, багато сучасних фреймворків, таких як Next.js, дозволяють використовувати суміш SSG, SSR та ISR в рамках однієї програми, вибираючи кращу стратегію для кожного маршруту.

П: Чим ISR відрізняється від простого частого перебудови мого статичного сайту?

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

З: SSR завжди повільніше, ніж SSG?

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

П: Чи можу я реалізувати автентифікацію користувачів з SSG?

Відповідь: Хоча самі сторінки SSG статичні, ви можете поєднувати їх з аутентифікацією на стороні клієнта для захищеного контенту. Однак, для дійсно динамічного, специфічного для користувача контенту SSR або ISR можуть бути більш відповідними.

П: Як працює кешування із цими різними стратегіями?

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

П: Яка стратегія найкраще підходить для сайту з контентом, що часто оновлюється?

Відповідь: Для сайтів з контентом SSR або ISR, що часто оновлюються, зазвичай є найкращим вибором. SSR дозволяє оновлювати контент у реальному часі, тоді як ISR забезпечує баланс між продуктивністю та свіжістю контенту.

П: Як ISR впливає використання серверних ресурсів проти SSR?

Відповідь: ISR зазвичай потребує менше серверних ресурсів, ніж SSR, оскільки сторінки періодично генеруються, а не при кожному запиті. Це може призвести до значної економії, особливо для сайтів із високим трафіком.

П: Чи можуть пошукові системи ефективно індексувати контент, відрендерований на стороні клієнта?

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

Питання: Як вибрати між ISR і традиційним SSG з частими перебудовами?

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

П: Які інструменти чи фреймворки найкраще підтримують кожну із цих стратегій рендерингу?

• SSG: Gatsby, Hugo, Jekyll
• SSR: Next.js, Nuxt.js, Express із шаблонізаторами
• ISR: Next.js (найбільш відома реалізація) Багато сучасних фреймворків, таких як Next.js і Nuxt.js, підтримують усі три стратегії.

З: Як ці стратегії рендерингу впливають на досвід розробки?

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

П: Чи можуть ці стратегії рендерингу використовуватися з будь-яким стеком технологій?

В: Хоча концепції можна застосовувати широко, конкретні реалізації можуть залежати від вашого стека. Наприклад, ISR нині найбільш тісно пов'язані з Next.js і React, але концепція адаптується й інших фреймворків.

П: Як ці стратегії рендерингу впливають на якийсь час до першого байта (TTFB)?

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

Q: Чи є ситуації, коли змішування цих стратегій не рекомендується?

В: Хоча змішування стратегій часто корисне, воно може ускладнити кодову базу та процеси розгортання. Це може бути небажаним для невеликих проектів або команд з обмеженими ресурсами.

Висновок

Вибір правильної стратегії рендерингу – це баланс між продуктивністю, свіжістю контенту, SEO та складністю розробки. SSG, SSR та ISR пропонують унікальні переваги, що підходять для різних сценаріїв:

• SSG чудовий для статичних сайтів, що пріоритизують швидкість і простоту.
• SSR ідеальний для динамічних сайтів, що потребують контенту в реальному часі та персоналізації.
• ISR пропонує компроміс, поєднуючи продуктивність SSG з частішими оновленнями контенту.

У міру розвитку веб-технологій ми можемо очікувати на появу ще більш нюансованих і гнучких підходів до рендерингу. Розробники повинні залишатися в курсі цих тенденцій та бути готовими адаптувати свої стратегії.

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

SSR: ключовий елемент сайту, який потребує особливої ​​уваги

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

Що таке SSR?

SSR - це Server Side Rendering, тобто, генерація сторінки на стороні сервера, а не в браузері, коли сервер віддає вже згенерований HTML.

Будь-яка сторінка сайту або найпростіша веб-версія програми – це HTML-код, який відображається у браузері у вигляді набору візуальних елементів – текстових блоків, зображень, посилань та кнопок. Рендеринг - Складання html коду для браузера користувача, з блоків коду вихідного vue-файлу. Це відбувається тоді, коли ми заходимо на сайт - тобто, відправляємо запит на сервер, а з нього отримуємо js-код vue додатки, html з порожніми місцями, в які буде рендерувати контент вже на стороні користувача. І, звісно, ​​ми хотіли б, щоб це відбувалося миттєво.

Відобразити сайт у браузері з уже згенерованим 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-файл. Ми обов'язково звертаємо увагу на наявність такого навички при наймі нових співробітників, для нас це дуже важливо.