Производительность Next.js: Core Web Vitals, изображения, streaming и размер бандла
← Назад к статьям

июль 2026 г.

Производительность Next.js: Core Web Vitals, изображения, streaming и размер бандла

Шестая статья цикла: как ускорять Next.js-приложение через Core Web Vitals, оптимизацию изображений, Server Components, streaming, lazy loading, анализ JavaScript-бандла и кеширование.

Производительность Next.js-приложения — это не один флаг в конфиге и не только Lighthouse score. Быстрый сайт получается из десятков решений: сколько HTML отдаётся сразу, какие данные блокируют рендер, сколько JavaScript приезжает в браузер, как грузятся изображения и где стоит кеш.

Короткий ответ

Начинайте с Core Web Vitals: LCP, INP и CLS. Уменьшайте клиентский JavaScript через Server Components, оптимизируйте изображения через next/image, используйте streaming для тяжёлых страниц, lazy loading для вторичных блоков и анализируйте bundle перед добавлением каждой крупной библиотеки.

LCP: главный контент должен появляться быстро

Largest Contentful Paint чаще всего зависит от hero-изображения, главного заголовка, серверного ответа и блокирующих запросов. Если первый экран зависит от медленного API, пользователь увидит пустоту. Для публичных страниц используйте SSG/ISR, CDN и заранее подготовленные данные.

INP: интерфейс должен отвечать

Interaction to Next Paint показывает, насколько быстро страница реагирует на действия пользователя. Основной враг INP — лишний JavaScript на клиенте. В App Router важно не превращать всё приложение в Client Component. Чем больше логики остаётся на сервере, тем легче браузеру.

tsx
// Хорошо: интерактивен только маленький виджет
export default async function ProductPage() {
  const product = await getProduct();

  return (
    <>
      <ProductDetails product={product} />
      <AddToCartButton productId={product.id} />
    </>
  );
}

CLS: стабильная верстка

Cumulative Layout Shift ухудшается, когда изображения, баннеры, шрифты или динамические блоки меняют размер после загрузки. Задавайте width/height для медиа, резервируйте место под виджеты, не вставляйте верхние баннеры без стабильного контейнера.

Изображения

Компонент next/image помогает с responsive sizes, lazy loading, modern formats и предотвращением layout shift. Но он не заменяет дизайн-решения: не нужно грузить 3000px изображение в карточку 320px, не стоит ставить priority всем картинкам и нельзя забывать про alt-текст.

tsx
<Image
  src={cover.url}
  alt={cover.alternativeText ?? article.title}
  width={1200}
  height={630}
  priority
  sizes="(max-width: 768px) 100vw, 1200px"
/>

Streaming и Suspense

Streaming позволяет отдавать часть страницы раньше, пока тяжёлые блоки догружаются. Это особенно полезно для dashboard, аналитики, рекомендаций, комментариев и других секций, где разные данные имеют разную стоимость.

tsx
export default function DashboardPage() {
  return (
    <>
      <Summary />
      <Suspense fallback={<ChartSkeleton />}>
        <SlowAnalyticsChart />
      </Suspense>
    </>
  );
}

Размер JavaScript-бандла

Каждая UI-библиотека, date library, markdown renderer и chart package увеличивает стоимость страницы. Проверяйте bundle analyzer, используйте dynamic import для тяжёлых клиентских компонентов и избегайте случайного переноса серверного кода в браузер через 'use client' на слишком высоком уровне дерева.

SEO и MUVERA-ready структура

Для SEO скорость напрямую влияет на пользовательский опыт, индексацию и конверсию. Для semantic retrieval полезны короткие определения рядом с примерами: LCP — скорость появления главного контента, INP — отзывчивость, CLS — стабильность верстки, streaming — поэтапная доставка UI. Такая структура помогает системам поиска сопоставлять статью с прикладными вопросами разработчиков.

FAQ

Почему Next.js-приложение может быть медленным?

Чаще всего из-за лишнего клиентского JavaScript, неоптимизированных изображений, медленных API-запросов, плохого кеширования и нестабильной верстки.

Нужно ли оптимизировать все страницы одинаково?

Нет. Главная, статьи, карточки товара, dashboard и checkout имеют разные bottleneck'и. Сначала измеряйте, потом меняйте архитектуру.

Итог

Быстрый Next.js — это приложение, где сервер делает свою работу, браузер получает минимум лишнего JavaScript, изображения имеют правильные размеры, а тяжёлые блоки не мешают первому экрану. Производительность нужно проектировать вместе с архитектурой, а не чинить после релиза.

Практический цикл статей о Next.js: от первого приложения и архитектуры проекта до рендеринга, кеширования, авторизации, наблюдаемости, деплоя и проектирования высоконагруженного веб-сервиса.

  1. 1.Next.js: Полный гайд по фреймворку для React
  2. 2.Next.js: настройка проекта, маршруты и первая архитектура
  3. 3.Next.js рендеринг и кеширование: SSR, SSG, ISR и Server Components
  4. 4.Next.js как BFF: Route Handlers, Server Actions и слой данных
  5. 5.Авторизация и безопасность в Next.js: cookies, Middleware, CSRF и rate limiting
  6. 6.Производительность Next.js: Core Web Vitals, изображения, streaming и размер бандла← вы здесь
  7. 7.Next.js в production: деплой, CDN, observability и высокая нагрузка

# Где это применено на практике

Проекты ниже связаны с этой статьёй по общим темам, технологиям или предметной области. Они показывают, где эти идеи использовались в реальной инженерной работе.

Контакт

Напишите мне

Открыт к интересным проектам и предложениям о сотрудничестве

Или напрямую:

i@paulislava.space