IHOR.DEVБАЗА_ЗНАНЬ
МЕНЮ

~/blog / Якість / how-to-reduce-javascript-bundle-size.md

// посібник · 3 хв читання

Як зменшити розмір JavaScript-пакета

Простежте клієнтські імпорти маршрутів, приберіть зайві залежності браузера, відкладіть додаткові інструменти й перевірте початкову та інтерактивну вартість.

Коротка відповідь

Зменшуйте JavaScript до першої корисної дії. Перевірте production-граф клієнтських імпортів, знайдіть шлях дорогої залежності, приберіть, перенесіть чи відкладіть її. Менший source-файл не гарантує менший download. Серверний результат, початковий код і пізні chunks — різні виміри.

Виберіть маршрут і дію до змін. Список портфоліо й admin-редактор потребують різних можливостей; імпорт парсера редактора до спільного client-layout змусить усіх платити за приватну задачу. Це приклад дизайну, не виміряний висновок цього репозиторію.

Практичні кроки реалізації

Перевірте production-граф

Використовуйте analyzer своєї версії й bundler. Поточний Next.js описує Turbopack analyzer і окремий Webpack-plugin. Фільтруйте маршрут і client, простежуйте імпорт та записуйте базу. Не порівнюйте dev із production і не змінюйте bundler посеред порівняння.

Зменшіть браузерну межу

Лишайте неінтерактивне форматування серверу без браузерних API. Розміщуйте use client біля інтерактивного, не навколо всієї сторінки за звичкою. Імпорти client-межі можуть тягнути залежності в браузер. Малий серіалізований результат замість бібліотеки трансформації зменшує код.

Приберіть чи звузьте залежності

Перевірте дублікати, локалі, icon-barrels, side effects і plugins. Обирайте документовані входи, не приватні deep imports. Tree shaking залежить від модулів і side effects; іменований імпорт не доводить малої функції в пакеті. Повторіть граф для підтвердження.

Відкладіть необов’язкове

Завантажуйте важкий редактор, графік чи експорт при відкритті. Дайте loading і помилку. Не відкладайте основний вміст і не створюйте довгий послідовний ланцюг chunks. Перевіряйте економію та затримку першої дії: перенесення не усуває вартість.

Приклад реалізації

Client-компонент відкладає умовний редактор до відкриття. Тримайте його окремо й не імпортуйте eager деінде. ssr false належить Client Component і потрібен лише для browser-only роботи.

"use client";
import dynamic from "next/dynamic";
import { useState } from "react";

const Editor = dynamic(() => import("./editor"), {
  ssr: false,
  loading: () => <p role="status">Loading editor…</p>,
});

export function OptionalEditor() {
  const [open, setOpen] = useState(false);
  return open ? <Editor /> : (
    <button onClick={() => setOpen(true)}>Open editor</button>
  );
}

Реальному редактору потрібна error boundary для chunk і доступне закриття. Перевірте відсутність модуля до відкриття й завантаження після. Код показує розміщення, не виміряну економію байтів.

Компроміси та альтернативи

Сервер зменшує браузерний код, але додає роботу й payload. Dynamic import додає першу затримку та chunk-відмови. Видалення залежності може збільшити підтримку поганої власної реалізації. Порівнюйте повну задачу, не один прямокутник treemap.

Поширені помилки

  • Вимір лише репозиторію чи node_modules.
  • Client-layout без потреби.
  • Dynamic import зі збереженим eager.
  • Послідовний waterfall основної роботи.
  • Відкладені байти як видалені.

Контрольний список перед випуском

  • База має той самий bundler і маршрут.
  • Великі імпорти простежено.
  • Обробка має свідому межу.
  • Відкладене має loading і помилку.
  • Перевірено load і першу дію.
  • Видалене відсутнє в output.

Поширені запитання

Чи tree shaking прибирає все зайве?

Ні. Важливі формат, side effects і шляхи. Перевіряйте граф і результат, не робіть висновок із синтаксису.

Чи завжди потрібен нуль client JavaScript?

Ні. Інтерактивне потребує коду. Робіть його пропорційним функції без сторонніх трансформацій чи інструментів.

Висновок

Простежте залежність до власної client-межі, зробіть зміну й перевірте маршрут. Окремо записуйте початкові байти та відкладену дію, щоб користь мала сенс.

Первинні джерела

Пов’язані посібники та приклади

Ігор Харчишин

Незалежний full-stack інженер продуктів, який пише посібники з реалізації розширень браузера та сучасних вебпродуктів на основі першоджерел.

Потрібно реалізувати це у вашому продукті?

Перегляньте відповідні приклади продуктів або поділіться контекстом розробки вебзастосунку, розширення Chrome, API чи SaaS.