Побудувала фронтенд Next.js 16: SSR, SSG і CSR

Ситуація. Дашборд для автентифікованих користувачів мав бути відчутно швидким і водночас по‑справжньому інтерактивним, а якщо підійти до справи наївно, ці дві мети тягнуть у різні боки. Якщо отримувати всі дані на клієнті, перше завантаження затягується, а що гірше — виникає патерн N+1: кожен компонент прокидається й надсилає власний запит, і одна сторінка перетворюється на каскад мережевих звернень.

Завдання. Кожну частину застосунку треба було рендерити саме так, як їй справді пасує, не жертвуючи клієнтською інтерактивністю там, де вона важлива.

Дія. Фронтенд на Next.js 16 обирає для кожної частини інтерфейсу той режим, який їй підходить, а не одне рішення на всі випадки. Маркетингові й публічні сторінки генеруються статично — вони не залежать від користувача, тож рендерити їх на кожен запит немає сенсу. Справді інтерактивні частини й далі рендеряться на клієнті. А там, де каскад N+1 справді дошкуляє, — у дашборді для автентифікованих користувачів і великих сторінках‑каталогах — рішення винесли у фабрику, а не писали щоразу вручну: createPrefetchedServerPage отримує дані сторінки на сервері й передає їх клієнту вже заповненими, тож компоненти одразу з’являються зі своїми даними, а не йдуть по них кожен окремо. Стратегія інвалідації кешу задокументована для кожного запиту, тож дані лишаються актуальними без повторного завантаження того, що застосунок уже має.

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