Розробка Next.js: де вузьке місце і що ламається
Вузьке місце рендерингу майже завжди виглядає однаково: сервер віддає порожній каркас, а вся логіка — фільтри каталогу, підстановка цін, підвантаження списків — виконується в браузері.
На середньому мобільному це секунди білого екрана, і зростання відмов починається раніше, ніж метрики встигають його показати.
Повільне завантаження сторінок рідко пояснюється одним важким файлом. Зазвичай це накопичений клієнтський код: кожен новий блок, віджет і зовнішній лічильник підключається одразу до всіх сторінок, бо розділення за маршрутами немає. Пакет зростає монотонно — разом із ним зростає час до першого рендерингу й вартість кожної зміни.
Окрема поломка — сторінки-пустушки у пошуковій видачі. Якщо вміст підставляється скриптом уже після завантаження, робот індексує заглушку: заголовок без тексту, каталог без позицій, статтю без абзаців.
Це пряма втрата позицій у пошуку за запитами, де напрямок раніше тримався в топі, і повернути їх дорожче, ніж не втрачати.
У всіх трьох симптомів одна причина — архітектурне розгалуження: який обсяг роботи віддається серверу, що кешується і на який строк, а що справді має жити в браузері. У Next.js це режими рендерингу та межі між серверними й клієнтськими компонентами, а не вибір бібліотеки. Розбираємо, як це закривається і що змінюється в цифрах.
Що дає серверний рендеринг: ефект у метриках і видачі
Швидкість першого рендерингу
Серверний рендеринг віддає розмітку вже готовою, тому браузер показує контент, не чекаючи завантаження й виконання скриптів. Час до першого рендерингу скорочується до одного мережевого запиту, і на медіанній мобільній мережі розрив із клієнтською збіркою помітний одразу.
Індексація сторінок
Пошуковий робот отримує той самий HTML, що й відвідувач, без черги на виконання скриптів. Частка сторінок в індексі зростає: зникають порожні відповіді та дублі, які з’являлися, коли контент збирався вже в браузері. Метадані й мікророзмітка формуються на сервері, тому сніпети стабільні для кожної картки й розділу.
Навантаження на пристрій клієнта
Сервер надсилає обчислену розмітку, а не дані для її збирання, тому слабкі телефони й бюджетні ноутбуки витрачають менше процесорного часу та заряду. На клієнті залишається лише інтерактивність — форми, фільтри, переходи без перезавантаження сторінки.
Стійкість до пікового трафіку
Готові та кешовані відповіді йдуть із пограничного шару, минаючи застосунок, — сплеск відвідуваності не перетворюється на чергу на бекенді.
Сторінки оновлюються за розкладом або за подією, тому під навантаженням зберігається актуальність даних, а за деградації джерела кеш продовжує віддавати контент.
Розробка Next.js: SSR, SSG, ISR і клієнтський рендеринг
В App Router режим віддачі задається не для всього застосунку, а на рівні сегмента маршруту: каталог може роздаватися статикою, особистий кабінет — рендеритися на сервері під кожен запит, а новинний розділ — оновлюватися за розкладом.
Тому «вибрати один режим для проєкту» — питання поставлено неправильно: рішення ухвалюється для кожного типу сторінок окремо.
Далі вибір зводиться до компромісу між часом до першого байта, свіжістю даних і навантаженням на сервер.
Статика та ISR віддають готовий HTML без звернення до сервера застосунку й тримають трафік, але показують дані на момент останнього оновлення; SSR завжди актуальний, але кожен запит коштує обчислень, а блоки під користувача без серверного рендерингу з’являються лише після гідратації.
Зведення за режимами
| Режим | Коли підходить | Обмеження |
|---|---|---|
| SSG | Лендінги, документація, довідкові сторінки: контент змінюється під час релізу | Зміна потребує перезбирання, персоналізація недоступна |
| ISR | Каталог, картки товарів, новини: контент змінюється, але не щосекунди | До оновлення може віддаватися попередня версія, зростає обсяг кешу |
| SSR | Особистий кабінет, кошик, пошукова видача, сторінки під авторизацією | Відгук залежить від сервера й зовнішніх джерел, вище навантаження |
| Клієнтський рендеринг | Віджети та інтерактивні панелі всередині вже відрендереної сторінки | У цьому блоці немає готового HTML для пошукових систем, дані надходять із затримкою |
На практиці режими комбінуються всередині одного дерева маршрутів: сторінка віддається статикою, а її персональні блоки підвантажуються окремо.
Етапи впровадження: від аудиту до передачі інженерам
Порядок етапів визначається ризиками, а не зручністю: спочатку знімаємо невизначеність щодо поточного коду, потім змінюємо маршрутизацію, і тільки згодом торкаємося навантаження й приймання.
На кожному кроці фіксуємо стан до і після — приймання робіт спирається на вимірювання, а не на враження.
- Аудит фронтенду. Розбираємо структуру сторінок і маршрутів, джерела даних і обсяг коду, що йде в браузер. На виході — карта вузьких місць з оцінкою впливу на швидкість віддачі.
- Схема маршрутів і даних. Розкладаємо сторінки за режимами: статика, збирання на сервері під запит, оновлення за розкладом або подією. Для кожного маршруту — джерело даних і поведінка за його недоступності.
- Налаштування рендерингу. Переносимо схему в App Router, розмічаємо серверні та клієнтські компоненти, задаємо правила оновлення й точкову інвалідацію за тегами, щоб правка однієї сутності не скидала весь кеш.
- Міграція без простою. Нові маршрути працюють паралельно зі старими, звіряння відповідей відбувається на живому трафіку, перемикання — у міру збігу.
- Перевірка під навантаженням. Вимірюємо час до першого байта, частку помилок, холодний старт і поведінку за відмови зовнішніх сервісів.
- Приймання робіт. Звіряємо метрики до і після, фіксуємо чек-ліст маршрутів, сценарій відкату на попередню версію та регламент оновлення контенту.
- Передача інженерам. Архітектурна документація, схема маршрутів, доступи й регламенти — команда веде проєкт далі сама.
Артефакти проєкту: репозиторій, схеми, регламенти
Проєкт передається не архівом файлів, а робочою системою: за нею новий інженер піднімає середовище й випускає реліз, не розшукуючи автора. Нижче — перелік артефактів, які залишаються в замовника разом із вихідним кодом.
- Репозиторій і структура маршрутів — дерево сегментів, вкладені макети, межі завантаження й обробки помилок. За ним одразу видно, яка адреса віддається статикою, яка рендериться на сервері, а яка живе на клієнті.
- Конфігурація маршрутів — переадресації, переписування адрес, заголовки відповіді та правила доступу зібрані в одному місці, а не розкидані по обробниках.
- Схема потоків даних — звідки надходять дані, де серверний шар, де клієнтський, які запити кешуються, а які йдуть напряму до джерела.
- Політики кешування — для кожного маршруту зафіксовано режим віддачі, строк життя запису та умову його скидання за подією, а не за таймером. Це те, що найчастіше ламається під час доопрацювань без документації.
- Регламент релізів і розгортання — порядок збирання, обов’язкові перевірки, схема гілок, порядок розгортання на тестове середовище й відкат на попередній випуск.
- Інструкції із супроводу фронтенду — оновлення залежностей, поведінка в разі розбіжності даних і кешу, точки контролю в разі падіння збірки.
- Документація проєкту — схема середовищ, змінні, порядок доступів, журнал відомих обмежень і передача з розбором для команди замовника.
Кейс: каталог на мільйон сторінок почав відповідати помітно швидше
Каталог на мільйоні товарних сторінок рендерився на сервері на кожен запит: час відповіді на піку сягав 1,9 с, пошукові роботи обходили розділи повільно, в індексі трималося менше половини карток.
У дні розпродажів, коли трафік зростав у шість разів, сервіс починав віддавати помилки, і частина аудиторії йшла до конкурентів.
Ми розвели контент за режимами: категорії та ходові картки віддаємо статикою, решту — за зверненням із фоновим оновленням за правилами перевірки, а персональні блоки (наявність у регіоні, ціну з карткою лояльності) винесли в клієнтські компоненти.
Вітрину перезібрали на серверних компонентах Next.js і потоковій віддачі, а серверну частину каталогу закрили кешем із точковим скиданням за повідомленням про зміну товару: замість повного перезбирання на 40 хвилин оновлюються лише зачеплені сторінки.
Що змінилося за метриками: час відповіді сервера на 95-му процентилі — з 1,9 до 0,3 с, частка сторінок у пошуковому індексі — з 43 до 91%, органічний трафік виріс приблизно у 2,3 раза за квартал.
Шестикратний пік розпродажу сервіс проходить без помилок і деградації, а масова правка цін перестала вимагати повного перезбирання каталогу.
Відгук технічного директора замовника: «Каталог перестав бути вузьким місцем — розпродажі та оновлення цін більше не потребують ручного втручання чергової команди».
Чим серверний рендеринг відрізняється від статичної генерації?
В основі — момент, коли формується HTML. Статична генерація готує сторінки один раз, під час збирання: кожен запит віддає вже зібраний файл із кешу на найближчому до користувача вузлі.
Серверний рендеринг збирає розмітку в момент запиту — під конкретного користувача і з актуальними даними.
Різницю зручно дивитися за трьома осями: актуальність даних на сторінці, поведінка під навантаженням і вимоги до інфраструктури.
У Next.js це не жорсткий вибір із двох варіантів: інкрементальне оновлення віддає сторінку з кешу, а перегенерацію запускає у фоні за інтервалом або на вимогу, коли контент змінився.
| Режим віддачі | Коли підходить | Обмеження |
|---|---|---|
| Статична генерація | Каталог, лендінги, документація — дані змінюються рідко | Правка контенту потребує перезбирання; персоналізація недоступна |
| Рендеринг за запитом | Особисті кабінети, залишки й ціни під конкретного користувача | Кожен запит займає ресурс застосунку; піки потребують запасу потужностей |
| Інкрементальне оновлення | Контентні сторінки з частими правками | Потрібно керувати кешем і часом життя: залишається вікно застарівання |
Під навантаженням поведінка відрізняється принципово. Статика тримає пік завдяки кешуванню відповідей на краю мережі — кількість запитів майже не доходить до застосунку, і вартість інфраструктури зростає повільно.
Рендеринг за запитом щоразу звертається до даних, тому ємність планується під трафік: допомагає кеш проміжного шару, але для персональних відповідей він не працює.
Тому на практиці режими розводять за маршрутами, а не вибирають один на весь проєкт: статика — для публічних розділів, рендеринг за запитом — для персоналізованих, інкрементальне оновлення — для каталогів із регулярними правками.
Сумніви щодо App Router, кешу й маршрутизації
Сумніви перед стартом зазвичай технічні, і знімаються вони на проєктуванні, а не в бою. Нижче — питання, які найчастіше звучать, коли команда вже вибрала Next.js і обговорює перехід на App Router.
Чи можна переходити частинами, не переписуючи сайт повністю?
Так. Нові розділи піднімаємо на App Router, старі маршрути продовжують працювати й переносяться зонами, по одній. Шар даних, стилів і розмітки залишається єдиним, тому відвідувач не бачить швів, а релізи не зупиняються на час переходу.
Чи не почне кеш віддавати старі ціни й залишки?
Кешуємо за типами даних: тексти й каталог — надовго, ціни, наявність і персональні блоки — із коротким строком або без збереження взагалі. Скидання прив’язане до події: змінився товар — перезбираються лише пов’язані сторінки, а не весь сайт.
У нас свій сервер і своє розгортання — доведеться все перебудовувати?
Як правило, ні. Застосунок вирушає в контейнері за ваш проксі, домен, сертифікати й балансування залишаються на місці, змінюються лише кроки збирання. Плани на статичну видачу обговорюємо до старту — від цього залежить набір доступних режимів рендерингу.
Зовнішні сервіси відповідають повільно — сайт буде чекати?
Ні. Відповіді зовнішніх систем забираємо на своїй стороні, з обмеженням часу очікування й запасним значенням: відвідувач отримує готову сторінку, а не очікування чужого сервера. Якщо сервіс недоступний, показуємо коректний варіант і фіксуємо збій для розбору.
Обговоримо задачу: повернемося з планом і оцінкою робіт
Почати можна з обговорення задачі — докладне технічне завдання на вході не потрібне.
Достатньо описати продукт і те, як він має працювати: які сторінки й розділи потрібні, звідки надходять дані, чи потрібна роздача через серверний рендеринг або достатньо статичної генерації з фоновим оновленням.
Корисно побачити поточний код або прототип, якщо він є, і отримати доступи до репозиторію, панелі керування контентом і тестового середовища. Якщо проєкту ще немає — вистачить карти розділів, вимог до авторизації та прикладів інтерфейсів, які вам близькі за логікою.
На виході ви отримуєте:
- карту маршрутів App Router: які сторінки рендеряться на сервері, які збираються статично;
- схему джерел даних і правила оновлення кешу;
- план робіт за етапами з порядком і залежностями;
- оцінку трудомісткості та строків за кожним етапом;
- склад команди й точки, де потрібне ваше рішення;
- перелік ризиків і порядок відкату до попереднього стану.
Це робочий документ, за яким видно, з чого почнеться старт проєкту і що ви отримаєте на кожному кроці. Опишіть задачу в зручному вигляді — повернемося з планом робіт і оцінкою проєкту, а деталі за потреби уточнимо на дзвінку з інженерами.
