EMZETT.
Увійти

Emzett Wiki

Стратегії відображення: порівняння SSR, SSG, ISR і клієнтського відображення

Properties1
tagsglossar, nextjs, frontend

2 хв читання

Стратегії відображення: порівняння SSR, SSG, ISR і клієнтського відображення

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

Докладніше: Питання в тому, коли й де виникає HTML. Фреймворки на кшталт Next.js дають змогу обирати це для кожної сторінки.

Подробиці

Стратегії

  • SSG (статична генерація сайту): HTML генерується під час збірки й віддається через CDN. Дуже швидко, дешево, безпечно; але актуально лише настільки, наскільки остання збірка. Ідеально для блогу, документації, вікі, посадкових сторінок.
  • SSR (відображення на сервері): сервер генерує HTML за кожного запиту; завжди актуально й персоналізовано (cookie), але повільніше й дорожче (час обчислень, можливо, база даних).
  • ISR (інкрементальна статична регенерація): статична сторінка зі строком дії (revalidate: 3600); після спливу перебудовується у фоні. Хороший компроміс для списків, магазинів, новин.
  • CSR (відображення на клієнті): браузер завантажує JavaScript і будує сторінку; добре для панелей за входом, гірше для часу першого завантаження та SEO.
  • Streaming/Suspense: сторінка віддається частинами; важливе з’являється першим.

Допомога у виборі

ВимогаВибір
Рідко змінюваний вміст, багато трафікуSSG
Вміст змінюється щохвилини/щогодиниISR
Різне для кожного користувача (кошик, профіль)SSR або CSR
За входом, інтерактивноCSR (або SSR + клієнтські компоненти)
SEO важливеSSG/ISR/SSR

Гібриди нормальні: статична оболонка, динамічні частини через streaming або клієнтський запит.

Наслідки

  • Навантаження на базу даних: SSR/ISR запитують її; з кешуванням (див. unstable_cache, revalidate) і довгими строками дії навантаження різко падає, особливо в безсерверних баз даних, які призупиняються в простої й тарифікують час обчислень.
  • Вартість і швидкість: віддача статичних сторінок через CDN найдешевша.
  • Стійкість: статичні сторінки продовжують працювати, навіть якщо база даних недоступна; тому збірки не повинні залежати від бази даних або мають перехоплювати помилки.
  • Свіжість: з повторною перевіркою на вимогу (теги/шляхи) можна цілеспрямовано перебудовувати після змін.

Практика

Починайте зі статики, додавайте динаміку там, де потрібно. Вимірюйте з Lighthouse/Core Web Vitals (LCP, CLS, INP). Відповідним чином задавайте заголовки кешу. Перевіряйте поведінку за збою бази даних і холодних стартів. У Next.js: export const revalidate = 3600, dynamic = 'force-dynamic', generateStaticParams, серверні компоненти з fetch та опціями кешу (дивіться документацію вашої версії, API змінюється).

Див. також: Next.js App Router, Стратегії кешування, Теги кешу та revalidateTag, Lighthouse і Core Web Vitals, Безсерверні обчислення

Зворотні посилання