Дев’ять способів прискорити процес розробки у Next.js та створення продакшн-бандлів

Next.js надає можливості маршрутизації, серверної обробки, API-маршрутів та оптимізації зображень понад базою React майже без налаштувань, тому він є таким популярним вибором, включаючи проекти, створені за допомогою ШІ. Однак у міру зростання проекту з’являються ті самі проблеми: процес компіляції сповільнюється, заміна модулів в реальному часі працює повільно, навіть незначна зміна інтерфейсу здається повільною. Десятисекундна процедура компіляції замість однієї секунди призводить до додаткових годин щомісяця, а очікування від допоміжного ШІ на застосування змін під час повторної компіляції сторінки ще більше дратує.

Дозволити допоміжному ШІ перевірити проект

За допомогою редактора коду на основі ШІ вам не потрібно вручну застосовувати кожну пораду. Попросіть асистента порівняти кодову базу з наведеними нижче практиками. Корисний запит — це коли ви просите його перевірити кожну практику, пояснити, чому вона важлива, оцінити вплив на швидкість розробки, час збірки або час виконання, показати точні зміни в коді та підтвердити все відповідністю поточній офіційній документації Next.js та React. Він має позначати поради, які вже застаріли або відкинуті, та пропонувати сучасніші підходи, а також не робити спекулятивних оптимізацій, які не підтримуються документацією або не підходять для проекту.

Перегляньте все, що він створив, перед об’єднанням. Фреймворки розвиваються швидко, тож те, що допомагало рік тому, може бути непридатним зараз. Ставіться до асистента як до досвідченого рецензента, а не до оракула. Остаточне рішення мають приймати офіційна документація та потреби конкретного додатку.

Дев’ять звичок, які приносять користь

1. Запустіть розробку в Turbopack

У останніх версіях Next.js Turbopack є стабільним для локальної розробки. Його увімкнення здійснюється за допомогою флага:

next dev --turbopack

У той час як старіший сервер розробки на базі Webpack обробляє більшу частину проекту, Turbopack перескладає лише ті модулі, які змінилися. У проектах середнього та великого розміру швидкість запуску та функція HMR покращуються миттєво. Для створення версій у продакшні все ще використовується стандартний процес, тому його використання під час розробки не несе значних ризиків.

2. Попередня компіляція важких залежностей

Повторна обробка пакетів сторонніх розробників, які рідко змінюються, під час кожного запуску є основною причиною повільного старту. Material UI, Monaco Editor, Three.js, Chart.js та великі набори іконок потребують значних ресурсів під час кожного запуску сервера розробки. Next.js може оптимізувати імпорти для пакетів з іменами:

experimental: {
    optimizePackageImports: [
        "@mui/material",
        "@mui/icons-material",
        "lodash"
    ]
}

Також уникайте завантаження цілого пакету, якщо достатньо одного інструменту. Менша діаграма залежностей компілюється швидше.

3. Пропустіть файли barrel

Один файл index.ts, який знову експортує кожен компонент, робить імпорти більш охайними, але змушує компілятор обробляти набагато більше файлів, ніж це необхідно. Цей імпорт проходить через файл barrel:

import { Button } from "@/components";

Краще імпортувати з власного шляху компонента:

import Button from "@/components/Button";

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

4. Не включайте перевірку типів у сервер розробки

Багато розробників блокують свій сервер розробки від перевірок TypeScript, які вже виконує редактор. Запускайте сервер та модуль спостереження за TypeScript як два окремі процеси:

next dev --turbopack
tsc --watch

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

5. Зберігайте клієнтські компоненти маленькими

У App Router будь-який файл, позначений як "use client", потрапляє до пакету браузера. Запитайте себе, чи справді компонент потребує клієнтського відображення. Статичні макети, навігація, сторінки з контентом та завантаження даних часто можуть залишатися серверними компонентами, а клієнтські компоненти використовуватися лише для тих частин, які дійсно потребують інтерактивності. Це зменшує кількість JavaScript-коду, який надсилається до браузера, а також кількість клієнтських модулів, які потрібно перебудовувати під час розробки.

6. Завантажуйте важкі бібліотеки за потреби

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

const Editor = dynamic(() => import("./Editor"), {
    ssr: false
});

Як початковий пакет, так і результати рекомпіляції у режимі розробки залишаються значно меншими.

7. Розділяйте великі компоненти

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

8. Вимикайте непотрібні сервіси під час розробки

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

if (process.env.NODE_ENV === "production") {
    initializeAnalytics();
    initializePWA();
}

Менше ініціалізації означає чистіший процес запуску в локальному середовищі та відсутність зовнішніх мережевих викликів під час розробки.

9. Налаштуйте також версію для продакшену

Швидкість розробки — це лише половина картини. Використовуйте компонент Image від Next.js замість простих тегів зображень, кешуйте дані там, де це можливо, стискайте ресурси та покладайтеся на серверні компоненти для скорочення обсягу відправляються JavaScript-кодів. Час від часу перевіряйте збірку за допомогою аналізатора, щоб якомога раніше виявити надмірно великі залежності. Багато невеликих покращень протягом процесу зазвичай ефективніші, ніж одна велика оптимізація наприкінці.

З чого почати

Мета — з’ясувати, де насправді йде час: під час розробки, під час створення збірки чи під час роботи програми. Почніть з основ: охайна структура залежностей, ретельне розділення коду, мінімальний обсяг JavaScript на стороні клієнта та інструменти, які вже надає Next.js. Вимірюйте зміни, вносіть корективи та переглядайте архітектуру у міру зростання додатку.

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