Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «SSR і Time to First Paint». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**Time to First Paint (TTFP)** - це час від початку завантаження сторінки до **першої візуальної зміни**, яку бачить користувач. **Ключове:** SSR може збільшити TTFP, бо сервер має виконати рендер і зачекати на дані перед відправленням HTML, тоді як CSR одразу віддає статичні файли.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення## Що таке TTFP **Time to First Paint (TTFP)** - це час від початку завантаження сторінки до **першої візуальної зміни** (першого пікселя, який бачить користувач). Чим менший TTFP - тим швидше користувач відчуває, що сторінка "завантажилася". --- ## Чому SSR може збільшити TTFP ### 1. Сервер має **виконати рендеринг перед відправленням** У CSR сервер просто віддає статичні файли (`index.html`, JS, CSS) - майже миттєво. У SSR же сервер: 1. Запускає Node.js-застосунок. 2. Завантажує потрібні дані (fetch, БД, API). 3. Виконує React/Vue/тощо для генерації HTML. 4. Лише потім відправляє HTML клієнту. Все це додає затримку до **TTFB (Time to First Byte)** - а отже, і до **TTFP**. Поки сервер не виконає рендер, браузеру нема чого малювати. > Іншими словами: при SSR браузер **чекає**, поки сервер "приготує страву", > а при CSR - отримує "сирі інгредієнти" одразу. --- ### 2. Мережа + відстань до сервера SSR збільшує розмір відповіді (готовий HTML більший, ніж голий шаблон), а також робить серверний рендеринг чутливим до **мережевих затримок**. - Якщо сервер далеко (або без CDN), час запиту + відповіді зростає. - Користувач в іншій країні отримує HTML пізніше. > У CSR і SSG це вирішується CDN-кешуванням, а у SSR - не завжди можливо через динаміку. --- ### 3. Виконання JS відкладається до отримання HTML Поки сервер не віддасть готовий HTML, клієнт **не може почати завантажувати JS-бандли**. У CSR браузер **паралельно** отримує JS і CSS, тому JS може почати виконуватися раніше. > SSR -> "чекаємо HTML" -> потім завантажуємо JS > CSR -> "одразу качаємо JS" -> швидше рендеримо порожню сторінку --- ### 4. Повільні серверні API-запити Якщо серверний рендеринг чекає на відповіді від API (наприклад, `getServerSideProps` у Next.js), то кожен з них напряму збільшує затримку до першого рендеру. > Один зайвий запит на 300 мс = +300 мс до TTFP. --- ### 5. Відсутність стрімінгу (або неправильне його використання) Якщо сервер не використовує **streaming SSR (React 18 renderToPipeableStream)**, він генерує **весь HTML цілком**, а не частинами. Браузер не може почати малювати, поки не отримає весь документ. > Сучасний стрімінг-SSR дозволяє почати First Paint раніше, > але класичний SSR - ні. --- ## Підсумок: SSR покращує *перцептивну* швидкість, але може сповільнити *технічний старт* | Етап завантаження | CSR | SSR | |---|---|---| | Відправлення першого байта (TTFB) | Швидка | Повільніша | | Початок першого Paint (TTFP) | Швидше (порожній екран + JS) | Повільніше (чекає HTML) | | Відображення реального контенту | Пізніше (після JS) | Раніше (готовий HTML) | Тобто **перший піксель може з'явитися пізніше**, але **перший корисний контент - раніше**. --- ## Висновок SSR може **збільшити TTFP**, тому що: 1. Серверу потрібен час на рендеринг перед відповіддю. 2. Відповідь більша і залежить від API-запитів. 3. Клієнт чекає на HTML, перш ніж почати завантаження інших ресурсів. 4. Без стрімінгу рендер блокується повністю. --- **Ключова думка:** > SSR робить контент "видимим" раніше, але "перший піксель" може прийти пізніше. > Тому грамотний SSR завжди поєднують зі **streaming**, **CDN-кешуванням** і **гібридними підходами (ISR, partial hydration)**.Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.