Аналіз бандла, Tree Shaking та Code Splitting в Next.js

Навіщо це потрібно#

У веб-застосунках JavaScript є найдорожчим ресурсом з точки зору обчислювальної потужності пристрою користувача. На відміну від растрових зображень однакової ваги, кожен кілобайт клієнтського JS-коду потребує не лише передачі мережею, але й подальшого розпакування, синтаксичного парсингу та JIT-компіляції рушієм V8 перед безпосереднім виконанням.

Роздутий клієнтський бандл призводить до негайної деградації ключових метрик:

• TBT (Total Blocking Time) та INP (Interaction to Next Paint): Основний потік браузера блокується тривалою компіляцією та гідратацією React, ігноруючи або затримуючи кліки, введення тексту та тапи.
• Обмеження мобільних пристроїв: На смартфонах середнього класу з термальним тротлінгом парсинг бандла розміром понад 250 КБ може займати від 1.5 до 3 секунд повної нечуйності інтерфейсу.

Фреймворк Next.js реалізує нативне Code Splitting за сегментами маршрутів та алгоритм Tree Shaking. Проте неконтрольований імпорт сторонніх npm-бібліотек (наприклад, монолітних утиліт чи повних бібліотек іконок) та використання Barrel Files можуть випадково затягнути в клієнтський бандл сотні кілобайтів мертвого коду.

Ментальна модель#

Архітектура розділення коду в App Router#

1. Маршрутне розділення (Route-based Splitting): Код, скомпільований для маршруту /dashboard, розташовується в окремому чанку і ніколи не завантажується користувачем, який переглядає /blog.
2. Спільні чанки (Shared Chunks): Спільні бібліотеки (ядро React, клієнтський роутер Next.js) компілятор групує в чанки First Load JS shared by all, що агресивно кешуються браузером між переходами.
3. Статичний аналіз графів модулів (ESM Tree Shaking): Компілятор аналізує конструкції import та export. Якщо імпортовано лише одну функцію з ESM-модуля, збирач видаляє всі інші невикористані частини пакета.

Синтаксис та API#

Налаштування @next/bundle-analyzer#

Для генерації інтерактивної карти пам'яті (treemap) використовується офіційний плагін @next/bundle-analyzer:

pnpm add -D @next/bundle-analyzer cross-env

Підключення плагіна в next.config.ts:

import type { NextConfig } from 'next';
import withBundleAnalyzer from '@next/bundle-analyzer';

const nextConfig: NextConfig = {
  // Експериментальні оптимізації компілятора
  experimental: {
    // Автоматичний глибокий Tree Shaking для barrel-пакетів
    optimizePackageImports: ['lucide-react', 'date-fns', 'lodash-es'],
  },
};

const analyzer = withBundleAnalyzer({
  enabled: process.env.ANALYZE === 'true',
});

export default analyzer(nextConfig);

Для запуску профілювання та відкриття візуального звіту в браузері виконайте:

cross-env ANALYZE=true pnpm run build

Динамічні імпорти через next/dynamic#

Для вилучення важких клієнтських бібліотек (наприклад, пакетів візуалізації Recharts або редакторів TipTap) із початкового бандла застосовується функція dynamic():

'use client';

import React, { useState } from 'react';
import dynamic from 'next/dynamic';

// Увага: опція { ssr: false } дозволена ВИКЛЮЧНО в клієнтських компонентах ('use client')
const DynamicAnalyticsChart = dynamic(
  () => import('@/components/HeavyChart').then((mod) => mod.HeavyChart),
  {
    loading: () => (
      <div className="w-full h-64 bg-bg-surface animate-pulse rounded-xl border border-border flex items-center justify-center">
        <span className="text-xs text-text-muted font-mono">Завантаження модуля графіків...</span>
      </div>
    ),
    ssr: false, // Вимикає серверний рендеринг (бібліотека потребує window / canvas)
  }
);

export function DashboardMetrics() {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <div className="space-y-4">
      <button
        onClick={() => setIsOpen(!isOpen)}
        className="px-4 py-2 rounded-lg bg-accent-violet text-white text-sm font-medium hover:bg-accent-violet/90 transition-colors"
      >
        {isOpen ? 'Приховати аналітику' : 'Показати аналітику'}
      </button>

      {/* Код чанка завантажується браузером лише в момент першого рендерингу */}
      {isOpen && <DynamicAnalyticsChart />}
    </div>
  );
}

Практичні патерни#

1. Серверні компоненти як головний інструмент Code Splitting#

У React Server Components код бібліотек виконується виключно на сервері. Залежності, імпортовані в серверні компоненти, конструктивно виключаються з клієнтського JavaScript-бандла.

// Серверний компонент (без директиви 'use client')
import { getPostBySlug } from '@/lib/posts';
// Пакет 'marked' важить ~40 КБ, але він НІКОЛИ не буде переданий клієнту
import { marked } from 'marked';
import sanitizeHtml from 'sanitize-html';

export default async function BlogPostPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const post = await getPostBySlug(slug);

  // Обчислення виконуються на сервері; клієнт отримує чистий безпечний HTML
  const rawHtml = await marked.parse(post.content);
  const cleanHtml = sanitizeHtml(rawHtml);

  return (
    <article className="prose dark:prose-invert max-w-3xl mx-auto py-8">
      <div dangerouslySetInnerHTML={{ __html: cleanHtml }} />
    </article>
  );
}

2. Заміна застарілих бібліотек на сучасні ESM-альтернативи#

• Замінюйте moment (~290 КБ, CJS без підтримки Tree Shaking) на date-fns або нативний Intl.DateTimeFormat.
• Замінюйте монолітний lodash (70 КБ CommonJS) на модульний lodash-es або нативні методи масивів стандарту ES2024.

Типові помилки#

Питання для співбесіди#