← Усі статті

Next.js майже миттєво: практичний чеклист для App Router

Server Components за замовчуванням, менше client JS, next/image, без CLS, кешування, next/script і заміри на throttled mobile.

Теги
НовиниfrontendПродуктивність
Next.js майже миттєво: практичний чеклист для App Router
Зміст

Коротко

На Dev.to опублікували практичний чеклист, як прискорити сайти на Next.js App Router: менше JavaScript на клієнті, стабільна верстка без CLS, оптимізація зображень, серверний рендер із кешем і заміри на throttled mobile, а не на dev-ноутбуці. Автор пов’язує швидкість із конверсією та Core Web Vitals як ranking-сигналом Google.

Що сталося

Стаття йде від найважчого важеля до інфраструктурних звичок.

1. Менше JS на клієнті. Більшість «повільних React-сайтів» — це гідратація сотень кілобайт JS, які користувачу не потрібні. Рецепт: Server Components за замовчуванням, 'use client' лише там, де потрібні state і browser API, і опускати client boundary вниз по дереву, а не піднімати на всю сторінку. Важкі блоки (charts, 3D, modals) — через next/dynamic з ssr: false.

2. Запобігання CLS. Явні width/height у next/image (або fill + контейнер із розміром), резерв місця під async-контент, шрифти через next/font з display: 'swap'.

3. Зображення як головна вага сторінки. next/image дає AVIF/WebP, sizing і lazy load; hero — з priority, решта — lazy; не віддавати 4000px фото в слот 400px.

4. SSR і кеш. Static/ISR для всього, що не персоналізовано per-request; fetch caching і revalidate; third-party через next/script з strategy="lazyOnload".

5. Заміри. Lighthouse у mobile mode з CPU throttling; field data в Search Console (CrUX). Опційно — performance budget у CI (наприклад, < 150 KB JS на first load).

Чому це важливо

Чеклист не про «екзотику», а про послідовне виконання нудних правил App Router. Server Components — не опція, а default: кожен зайвий 'use client' на layout тягне все піддерево в bundle.

Core Web Vitals безпосередньо впливають на SEO і bounce rate; локальні заміри на MacBook з fiber систематично завищують результат. Throttled mobile + CrUX ближче до того, що бачить Google і реальні користувачі.

Performance budget у CI ловить «повільне повзуче погіршення» на етапі PR — дешевше, ніж розслідувати просадку конверсії після релізу.

На практиці

Пройдіть чеклист перед продакшен-релізом Next.js:

  1. Аудит 'use client': чи можна компонент залишити server-only?
  2. Hero і above-the-fold — без lazy; below-the-fold charts — dynamic(..., { ssr: false }).
  3. Усі <Image> з розмірами; шрифти — лише через next/font.
  4. Сторінки каталогу/блогу — static або ISR; персоналізацію не змішувати з public cache без потреби.
  5. Analytics/chat widgets — lazyOnload, не блокувати main thread.
  6. Lighthouse mobile + перевірка CrUX; при зростанні JS — fail build за budget.

Якщо сайт «здається швидким» лише у вас — перепровірте на Slow 4G і mid-tier Android.

Підсумок

Миттєве завантаження Next.js — це App Router done right: server-first, мінімальний client JS, дисципліна з медіа та кешем, чесні метрики. Чеклист з Dev.to зручний як runbook перед кожним великим релізом фронтенду.