Девять способов ускорения сборки приложений Next.js в режиме разработки и генерации бандлов в продакшене

Next.js предоставляет функции маршрутизации, серверной отрисовки, API-маршрутов и оптимизации изображений для React практически без дополнительной настройки, поэтому он так популярен, включая при проектах, созданных с помощью ИИ. Однако по мере роста проекта возникают те же проблемы: медленная сборка, задержки при замене модулей в реальном времени, а даже небольшие изменения интерфейса кажутся медленными. Десятисекундная сборка вместо однесекундной приводит к тому, что каждый месяц теряется множество часов, а ожидание от ИИ-ассистента применения изменений во время повторной сборки страницы ещё больше раздражает.

Предоставление ИИ-ассистенту возможности проверить проект

С помощью редактора кода на основе ИИ вам не нужно вручную применять каждый совет. Попросите ассистента сравнить кодовую базу с приведёнными ниже рекомендациями. Полезный запрос предполагает, что он проверит каждую рекомендацию, объяснит её важность, оценит влияние на скорость разработки, время сборки или работу приложения, покажет точные изменения в коде и подтвердит всё согласно актуальной официальной документации Next.js и React. Он должен выделить устаревшие или заменённые советы и предложить более современные альтернативы, а также избегать спекулятивных оптимизаций, которые не поддерживаются документацией или не соответствуют проекту.

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

Девять привычек, которые приносят пользу

1. Запуск разработки с использованием Turbopack

В новых версиях Next.js Turbopack стабилен для локальной разработки. Его включение осуществляется с помощью флага:

next dev --turbopack

В то время как старый сервер разработки на основе Webpack обрабатывает всю структуру проекта, Turbopack пересоздаёт только те модули, которые изменились. В проектах среднего и крупного размера время запуска и функция реального времени обновления улучшаются сразу. Для производственных сборок по-прежнему используется стандартная цепочка обработки, поэтому применение Turbopack в процессе разработки несёт минимальные риски.

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. Лучшая оптимизация — это та, которая подходит для версии, на которой вы сейчас работаете, а не та, что была популярна в прошлом году.