BackНазад к блогу

Turbopack Dev теперь стабилен

Это был долгий путь, но мы рады объявить, что `next dev --turbo` теперь стабилен и готов ускорить ваш процесс разработки.

Это был долгий путь, но мы рады объявить, что next dev --turbo теперь стабилен и готов ускорить ваш процесс разработки. Мы использовали его для работы над vercel.com, nextjs.org, v0 и всеми нашими другими приложениями с отличными результатами.

С момента выпуска 8 лет назад Next.js использовался для создания всего — от хобби-проектов на выходных до сложных корпоративных приложений. Когда Next.js впервые появился, webpack был очевидным выбором для основы бандлинга фреймворка, но со временем он перестал соответствовать потребностям современных веб-разработчиков. Наше сообщество начало замечать, что итерации стали болезненно медленными: приходилось долго ждать загрузки маршрутов, отражения изменений кода и деплоя production-сборок.

Мы вложили много времени и усилий в оптимизацию webpack, но в какой-то момент поняли, что усилия не окупаются. Нам нужен был новый фундамент, который мог бы поддерживать множество Next.js-приложений, уже работающих в production, а также будущие инновации, такие как React Server Components.

Вот наши требования к новому бандлеру:

  • Минимальные breaking changes
  • Поддержка как App Router, так и Pages Router
  • Более быстрая компиляция для проектов любого размера
  • Development-сборки, максимально приближенные к production
  • Продвинутые оптимизации для production (например, tree shaking внутри модулей)
  • Граф модулей, поддерживающий несколько окружений, таких как Node.js и браузер
  • Полная наблюдаемость для сопровождающих и продвинутых пользователей

Мы изучили все существующие решения и обнаружили, что у каждого есть компромиссы, не соответствующие нашим требованиям и целям. Поэтому мы решили создать что-то с нуля, что точно соответствовало бы потребностям Next.js сегодня, и контролировать roadmap, чтобы экспериментировать с тем, что понадобится завтра. Это и стало мотивацией для создания Turbopack.

Мы начали с оптимизации процесса разработки, и именно это мы выпускаем как стабильную версию сегодня. Мы активно тестировали Turbopack на приложениях Vercel и заметно улучшили скорость итераций наших разработчиков. Например, с vercel.com, крупным Next.js-приложением, мы наблюдали:

  • До 76.7% быстрее запуск локального сервера.
  • До 96.3% быстрее обновления кода с Fast Refresh.
  • До 45.8% быстрее компиляция начального маршрута без кеширования (у Turbopack пока нет кеширования на диске).

В этом посте мы обсудим, как мы достигли этих результатов, а также другие ключевые моменты. Мы также уточним, чего ожидать от этого релиза, и предоставим roadmap на будущее.

Основные преимущества

Более быстрая начальная компиляция маршрута

Одна из главных проблем, о которых сообщало наше сообщество, — слишком долгая загрузка маршрутов в development, что сводилось к скорости компиляции webpack. Next.js компилирует маршруты по требованию, чтобы избежать компиляции всех возможных маршрутов до их использования, что ускоряет первоначальный запуск и снижает использование памяти. Но даже в этом случае приходилось ждать загрузки отдельных страниц.

Справедливости ради, бандлеры вроде webpack выполняют много работы под капотом. При первой компиляции маршрута бандлер начинает с "точки входа". В случае Next.js это комбинация page.tsx и всех связанных файлов для этого маршрута, таких как layout.tsx и loading.tsx, и т.д. Эти точки входа анализируются для поиска import-операторов, которые разрешаются в файлы, обрабатываемые так же, как точки входа, и этот цикл продолжается, пока не будут найдены все импорты. Так строится граф модулей, который может включать не только TypeScript/JavaScript-модули (включая node_modules), но и CSS-файлы (как глобальные, так и CSS-модули), а также статические файлы, например, изображения для next/image.

После сбора всех модулей граф используется для создания бандлов JavaScript, часто называемых "чанками". Эти чанки — выходные данные компилятора, которые выполняются на сервере (во время сборки или выполнения) или в браузере.

webpack не поддерживает создание графов, которые генерируют выходные данные для нескольких окружений, поэтому сегодня в Next.js с webpack приходится запускать как минимум два отдельных компилятора — один для сервера, другой для браузера. Сначала мы компилируем серверный граф модулей, чтобы найти все ссылки на "use client". После сборки сервера мы обходим его граф, чтобы создать соответствующие точки входа для компилятора браузера. Поскольку это отдельный компилятор webpack, в процессе есть накладные расходы, например, двойной парсинг одного и того же кода на клиенте и сервере.

С Turbopack мы решили устранить накладные расходы от запуска нескольких компиляторов и координации между ними. Решение заключалось в том, чтобы сделать компилятор осведомленным о нескольких целях вывода. Внутри они называются "переходами" (transitions) между целями. Мы можем пометить импорт как переход с сервера на браузер или с браузера на сервер. Это позволяет Turbopack эффективно бандлить Server Components и Client Components, а также Server Functions, импортированные из Client Components.

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

Еще одно важное отличие webpack от Turbopack — Turbopack может распараллеливать работу на нескольких CPU, тогда как в webpack параллелизуется только этап преобразования TypeScript/JavaScript с помощью SWC.

webpack не поддерживает параллелизацию между CPU, потому что для эффективного распараллеливания данные должны быть легко доступны между потоками. webpack был построен с активным использованием больших JavaScript-объектов, которые нельзя легко разделить между потоками без дорогостоящей сериализации и десериализации. Эти накладные расходы часто сводят на нет преимущества использования нескольких CPU. Turbopack написан на Rust, у которого нет таких ограничений, и он изначально разрабатывался с учетом параллелизации.

Мы также добились повышения производительности за счет более быстрого чтения и записи файловой системы, ускоренного разрешения модулей и пропуска лишней работы для модулей без побочных эффектов.

При использовании Turbopack на vercel.com, крупном Next.js-приложении, мы наблюдали до 45.8% ускорения начальной компиляции по сравнению с Next.js на webpack.

Более быстрый Fast Refresh

Fast Refresh — это система, которую бандлеры используют для передачи изменений в маршрут, который вы сейчас просматриваете в браузере, иногда называемая Hot Module Replacement (HMR).

Next.js имеет более глубокую интеграцию, которая связывает Fast Refresh с React, гарантируя, что React не теряет состояние при изменении компонента.

С webpack мы обнаружили, что производительность Fast Refresh ограничена при достижении определенного количества JavaScript-модулей. Webpack должен выполнять обход графа и генерировать выходные данные даже для неизмененных модулей, что масштабируется линейно с количеством JavaScript-модулей.

Мы выяснили, что при примерно 30 000 модулях обработка изменений кода всегда занимает не менее 1 секунды, независимо от размера изменения. Например, изменение цвета в CSS-файле может занять 1 секунду для отображения на экране.

Такая производительность нас не устраивала. Мы считаем, что инкрементальные сборки должны масштабироваться только с размером локальных изменений, а не с размером маршрута или приложения. При изменении button.tsx компилятор должен выполнять только работу, связанную с этим изменением, вместо пересчета других модулей и выходных файлов, на которые изменение не влияет. Чтобы решить эту проблему, мы сосредоточились на создании основы в Turbopack, которая позволяет очень точно пересчитывать работу.

Эти усилия воплотились в базовую библиотеку Turbo Engine, использующую архитектуру автоматических инкрементальных вычислений по требованию для обеспечения интерактивного hot-reloading крупных Next.js и React-приложений за десятки миллисекунд. Эта архитектура основана на более чем десятилетних исследованиях и предыдущих наработках, включая webpack, Salsa, Parcel, Adapton и систему запросов компилятора Rust.

Теперь с Turbopack скорость Fast Refresh масштабируется с размером ваших изменений, что позволило нам достичь 96.3% ускорения обновлений кода с Fast Refresh в крупных Next.js-приложениях, таких как vercel.com.

Продвинутый трейсинг

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

Чтобы начать решать эту проблему, мы добавили трейсинг во внутренние компоненты Next.js. Эти трейсы записываются в файл в папке .next и не включают код приложения — только путь к файлу, время, затраченное компилятором, и другие временные метки, такие как отдельные преобразования. Однако с webpack у нас никогда не было хорошего способа четко разделить использование памяти компилятором и фреймворком или кодом приложения, так как все они выполняются в одном экземпляре Node.js.

С Turbopack мы смогли разработать систему с инструментированием с самого начала. Мы реализовали слой инструментирования в Turbo Engine, который позволяет собирать временные метки для каждой отдельной функции. Мы расширили эти трейсы, чтобы также отслеживать выделение, освобождение и сохранение памяти для каждой функции.

Этот новый, продвинутый трейсинг дает нам всю необходимую информацию для глубокого исследования замедлений и использования памяти; для этого требуется только трейс, а не полная кодовая база.

Для обработки этих новых трейсов мы реализовали специальный просмотрщик трейсов, который остается производительным независимо от размера приложения и трейса. Это просмотрщик, специально созданный для исследования замедлений и использования памяти в Turbopack, и он позволил нам оптимизировать производительность во многих приложениях ранних пользователей, сократив цикл обратной связи.

Хотя просмотрщик трейсов изначально создавался для внутреннего использования (и предназначен для ситуаций, когда требуется глубокий технический анализ), мы добавили необходимые компоненты для его самостоятельного запуска в Next.js. Вы можете сгенерировать трейс Turbopack, используя эти инструкции. Затем, когда трейс сгенерирован, вы можете использовать next internal turbo-trace-server .next/trace-turbopack для запуска сервера, позволяющего анализировать трейс. Краткий обзор просмотрщика трейсов доступен здесь.

Меньше нестабильности во времени компиляции

При использовании Next.js с webpack время компиляции часто недостаточно предсказуемо. В одном случае страница может открываться за 10 секунд, в другом — за 20. Хотя кеш может присутствовать, иногда его влияние недостаточно для стабильных результатов. Даже при компиляции без кеша мы наблюдали некоторую вариативность.

Базовая архитектура Turbopack обеспечивает гораздо более стабильное время компиляции. Время компиляции маршрутов варьируется всего на несколько процентов, что позволяет нам последовательно оптимизировать производительность компилятора.

Development-сборки, максимально приближенные к production

Чтобы оптимизировать скорость компиляции с webpack, нам пришлось пойти на некоторые компромиссы, которые привели к различиям между development и production окружениями. Например, мы используем style-loader, который вставляет стили на страницу и позволяет их обновлять с помощью Fast Refresh без перезагрузки страницы. Однако это означает, что в development стили добавляются через JavaScript, что вызывает мигание нестилизованного контента. Мы обходим эту проблему, чтобы вы его не видели. Другой пример — Next.js с webpack использует eval-source-map, что означает, что весь код обернут в eval, а sourcemaps включены в него, что гарантирует их доступность в development ценой усложнения отладки и анализа бандлов. Хотя webpack поддерживает вывод полных sourcemaps с помощью опции source-map, это оказывает чрезмерное влияние на время компиляции и использование памяти.

Для Turbopack мы изначально решили эти проблемы, выводя CSS-файлы и sourcemaps без использования eval. Turbopack использует sections sourcemaps, относительно новую часть спецификации source-map, которая позволяет более эффективно объединять sourcemaps. Там, где раньше нам приходилось генерировать все маппинги в одном месте, теперь мы можем делать это гораздо более детально и кешировать.

Обработка CSS в Turbopack всегда выводит CSS-файлы, и, аналогично обработке JavaScript, он может обновлять CSS-файл без перезагрузки браузера благодаря механизму, встроенному в среду выполнения Turbopack для development.

Теперь мы можем уверенно сказать: если что-то работает в development с Turbopack, это будет работать и вести себя так же в production.

Наш первый стабильный релиз

Два года назад мы представили Turbopack как альфа-версию в Next.js 13, показав его потенциал в плане производительности. Хотя первоначальные результаты были многообещающими, он поддерживал только базовое использование — многие функции Next.js, такие как basePath, еще не были реализованы.

В течение следующего года мы сосредоточились на добавлении отсутствующих функций Next.js и бандлинга. Основываясь на отзывах сообщества, мы решили полностью сосредоточиться на опыте next dev, чтобы решить наиболее распространенные проблемы со скоростью итераций. К прошлогоднему Next.js Conf 90% тестов для development проходили успешно, а разработчики Vercel уже использовали Turbopack в повседневной работе.

В апреле мы анонсировали Next.js 14.2 с 99.8% успешных тестов, вскоре достигнув 100%. С тех пор мы устранили проблемы, о которых сообщалось на GitHub, особенно связанные с npm-пакетами, Fast Refresh и точностью локализации ошибок.

Признаем, путь к стабильности занял много времени, но это в основном связано с обширным набором тестов Next.js, который задает высокую планку стабильности. У нас было 8 лет, чтобы выявить крайние случаи и добавить 6 599 тестов для development, которые также должны были проходить с Turbopack. Дополнительным фактором стало то, что мы разработали Turbopack с совершенно другой архитектурой, чем webpack. Простой порт webpack на Rust был бы проще, но не позволил бы достичь желаемого прироста производительности.

Теперь, когда Turbopack проходит все тесты, проверен с топовыми npm-пакетами и учтены отзывы ранних пользователей, мы готовы объявить его стабильным.

Что именно стабилизировано?

Этот вопрос вызывал путаницу в прошлом, поэтому в данном разделе мы проясним, что именно означает этот релиз для сообщества Next.js.

Данный релиз конкретно отмечает команду next dev --turbo как стабильную. Продукционные сборки (next build --turbo) пока не поддерживаются, но следите за обновлениями — работа над ними ведётся. В конечном итоге мы планируем выпустить автономную версию Turbopack вне Next.js, но сначала хотим доказать её ценность, улучшив опыт сообщества Next.js.

За исключением неподдерживаемых функций, которые мы рассмотрим в следующем разделе, Turbopack должен работать со всеми стабильными возможностями Next.js. Для ясности: Turbopack поддерживает как App Router, так и Pages Router. Экспериментальные функции могут работать или не работать с Turbopack, но они точно будут поддерживаться к моменту их стабилизации.

Если ваше приложение имеет кастомизацию webpack, но только добавляет загрузчики (loaders) webpack, вы уже можете использовать Turbopack, настроив загрузчики для него. Подробнее о поддержке загрузчиков webpack в Turbopack можно прочитать в документации.

Вот список загрузчиков webpack, которые проверены на совместимость с Turbopack:

  • @svgr/webpack
  • babel-loader
  • url-loader
  • file-loader
  • raw-loader
  • tsconfig-paths-webpack-plugin — поддерживается из коробки, без необходимости в плагине.
  • Большинство других загрузчиков также работают, так как мы поддерживаем подмножество API загрузчиков webpack.

Поддерживается большинство библиотек CSS и CSS-in-JS:

  • Поддерживаются:
    • Tailwind CSS
    • @emotion/react
    • Sass
    • styled-components
    • Bootstrap
    • Antd
    • node-sass
    • JSS
    • Emotion
    • theme-ui (использует Emotion)
    • @chakra-ui/core (с Emotion)
    • aphrodite
  • Пока не поддерживаются:
    • Less — можно добавить less-loader. Next.js с webpack также не поддерживает Less из коробки.
    • @vanilla-extract/css — использует кастомный плагин webpack. Мы планируем изучить, что потребуется для поддержки необходимых хуков в будущем.
    • StyleX — требует Babel-трансформации и поддержки атрибутов data:. Мы рассмотрим поддержку StyleX после стабилизации next build --turbo.

Производительность

Хотим отметить, что производительность текущей версии значительно выше, чем у webpack, но это не окончательный показатель. Мы следуем известной формуле Кента Бека: «Сначала заставь работать. Затем сделай хорошо. Затем сделай быстро». До сих пор большая часть наших усилий была направлена на этап «заставь работать», так как нам нужно догнать Next.js и webpack, которые развиваются почти десятилетие.

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

За последние 3 месяца мы уже добились значительных улучшений. Сравнение Turbopack в Next.js 15 RC 2 с Turbopack в 15 RC 1 показывает результаты этих оптимизаций:

  • Среднее снижение использования памяти на 25-35%.
  • Ускорение первоначальной компиляции на 30-50% для больших страниц с тысячами модулей.

Стабильная версия Turbopack содержит кэш в памяти, который необходимо перестраивать при каждом перезапуске сервера разработки — для больших приложений это может занимать 10 и более секунд. Нас очень вдохновляют успехи тестирования постоянного кэширования на диске, о котором мы расскажем далее.

Критические изменения

Одной из главных причин создания собственного сборщика была необходимость максимально соответствовать существующему поведению webpack, чего мы не могли гарантировать с другими решениями. Это включает способ разрешения файлов и мелкие особенности webpack, такие как комментарий webpackIgnore, который используют некоторые npm-пакеты.

К сожалению, нам пришлось отказаться от некоторых функций, чтобы обеспечить будущую устойчивость Turbopack и его интеграции с Next.js. Эти функции по-прежнему будут поддерживаться при использовании webpack.

Вот ключевые изменения и их причины:

Конфигурация webpack() не поддерживается. Turbopack — это не webpack, у него другая структура конфигурации, хотя он поддерживает многие аналогичные функции. В частности, мы реализовали поддержку загрузчиков webpack и алиасов разрешения. Большинство загрузчиков webpack, преобразующих код, работают из коробки. Некоторые экзотические загрузчики, например, использующие дочерний компилятор webpack или генерирующие файлы, не поддерживаются.

.babelrc не будет автоматически трансформировать код. Turbopack по умолчанию использует SWC. Вы по-прежнему можете добавить babel-loader, но мы обеспечиваем быстрые настройки по умолчанию, которые также логичны с архитектурной точки зрения. SWC всегда должен выполняться, даже если вы настроили .babelrc, для обработки других оптимизаций. Это аналогично тому, как webpack всегда запускает парсер acorn для дополнительных оптимизаций. Если вы используете SWC вместо Babel с Turbopack, мы можем парсить код один раз и использовать одно абстрактное синтаксическое дерево (AST) на всём протяжении работы Turbopack.

Некоторые редко используемые функции CSS Modules. Мы перешли с PostCSS на Lightning CSS для обработки CSS. Lightning CSS — это значительно более быстрый компилятор CSS, который поддерживает трансформации, минификацию и CSS Modules из коробки. Компромисс в том, что некоторые редко используемые функции не поддерживаются. А именно: псевдоселекторы :global и :local (их функциональные варианты :global() и :local() работают), @value, а также правила ICSS :import / :export. Также он строже других парсеров CSS и указывает на ошибки в коде вместо их игнорирования.

В процессе интеграции Lightning CSS мы внесли вклад в этот проект. Например, реализовали детальные настройки для CSS Modules, отключающие префиксинг CSS grid и режим pure для CSS Modules. Это упрощает переход на Lightning CSS для CSS Modules при использовании css-loader в webpack. Мы также улучшили сообщения об ошибках для неподдерживаемых функций CSS Modules.

Благодарим Devon Govett, автора и сопровождающего Lightning CSS, за постоянное сотрудничество.

Экспериментальные функции. Поскольку мы сосредоточены на стабильности Turbopack в Next.js, мы решили сначала обеспечить поддержку стабильных функций Next.js.

Полный список см. на странице документации.

Дорожная карта

Turbopack прошёл долгий путь, но впереди ещё много работы. Две ключевые функции, над которыми мы работаем, — это постоянное кэширование и продуктовые сборки. Ожидается следующий порядок внедрения:

  • Постоянное кэширование — в одном из следующих минорных релизов.
  • Бета-версия сборок — в одном из следующих минорных релизов.
  • Релиз-кандидат сборок — в одном из следующих минорных релизов.
  • Стабильные сборки — в одном из следующих минорных релизов.
  • Рекомендация в create-next-app для новых приложений — в одном из следующих минорных релизов.
  • Использование по умолчанию в Next.js при отсутствии кастомной конфигурации webpack — в следующем мажорном релизе.

Хотя webpack останется в Next.js, мы ожидаем, что благодаря преимуществам Turbopack большинство приложений Next.js захотят его использовать. После завершения работы над продуктовыми сборками в Turbopack мы начнём поддерживать популярные плагины webpack.

У нас есть примерные планы по развитию Turbopack, но в этом посте мы ограничимся тем, что можем уверенно выпустить в обозримом будущем. Хотя мы говорим только о двух функциях, они требуют значительных усилий, поэтому стоит рассмотреть их подробнее.

Постоянное кэширование (Fast Refresh между перезапусками)

Постоянное кэширование означает сохранение результатов работы компилятора для повторного использования между перезапусками сервера разработки или между несколькими продуктовыми сборками.

Проще говоря, Turbopack избегает повторного выполнения одной и той же работы, даже если вы перезапустили сервер.

Как упоминалось в разделе о Faster Fast Refresh, мы создали Turbo Engine, чтобы обеспечить параллелизацию и кэширование работы. Теперь мы работаем над тем, чтобы этот опыт сохранялся между перезапусками и при открытии маршрута. Нам не придётся перекомпилировать то, что уже было сделано в предыдущей сессии разработки. А что, если бы мы могли получить преимущества Fast Refresh при открытии маршрутов, скомпилированных ранее, или между сборками с next build?

Именно над этим мы работаем: новый уровень хранения для Turbo Engine, который сохраняет результаты компиляции на диск и восстанавливает их при запуске сервера разработки или повторной сборке.

Хотя webpack по умолчанию использует кэширование на диске в Next.js, у него есть несколько ограничений. Значительная часть кэша должна быть восстановлена с диска и загружена в память для работы. Кэш не всегда достаточно детализирован. Например, в крупных приложениях Vercel мы обнаружили, что кэш webpack на диске может работать медленнее, чем полная перекомпиляция, если кэш становится слишком большим.

В отличие от кэширования webpack, постоянный кэш Turbopack действительно ощущается как Fast Refresh между перезапусками. Маршруты, которые впервые компилируются более 10 секунд, восстанавливаются из кэша менее чем за 500 мс.

Мы наблюдаем аналогичные результаты для next build с Turbopack: перекомпилируются только изменённые файлы, остальное остаётся как есть. Это сокращает время сборки, перенося основное время выполнения с компиляции и сборки на проверку типов TypeScript.

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

После стабилизации постоянный кэш будет включён по умолчанию. Для его использования не потребуется изменять код.

Если вы хотите протестировать постоянное кэширование, свяжитесь с нами!

Продуктовые сборки

Мы рады сообщить, что добились значительного прогресса в создании стабильных продуктовых сборок с Turbopack. Сейчас проходят 96% наших тестов для продакшена, что является большим шагом вперёд. Однако остаются области, требующие доработки, прежде чем мы сможем рекомендовать Turbopack для масштабного использования в продакшене.

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

Оптимизации для продакшена

Корректность

Обеспечение корректности критически важно для надёжных продуктовых сборок. Текущий статус:

  • Чанкинг CSS: в процессе. Эта функция важна для разделения CSS на меньшие части, чтобы загружался только необходимый CSS для каждой части приложения, что уменьшает время загрузки и обеспечивает правильный порядок CSS-правил.
  • JS-рантайм для продакшена: завершён. Это гарантирует, что JavaScript-рантайм ведёт себя ожидаемо в продакшен-среде, обеспечивая надёжность и стабильность.
  • Хеширование имён файлов на основе содержимого: пока не реализовано. Хеширование на основе содержимого позволит генерировать имена файлов в зависимости от их содержимого, что улучшит долгосрочное кэширование в браузерах.

Оптимизация производительности UX

Производительность UX критически важна для быстрой загрузки и эффективного использования ресурсов. Вот над чем мы работаем:

  • Минификация JS: Завершено. Мы внедрили SWC Minify, который Next.js уже использует с webpack начиная с Next.js 13.
  • Минификация CSS: Завершено. Минификация CSS с помощью Lightning CSS, что важно для уменьшения размера таблиц стилей.
  • Глобальная информация (оптимизации всего приложения): Завершено. Turbopack может применять оптимизации, требующие данных обо всех маршрутах в приложении, например хеширование идентификаторов модулей.
  • Tree Shaking (удаление неиспользуемого кода): Частично завершено. В процессе. У нас есть частичная поддержка tree-shaking, которая помогает устранять неиспользуемый код и уменьшать размер бандлов. Однако есть сценарии, где tree-shaking пока не работает в полной мере:
    • Динамические импорты: Tree shaking ограничен для динамических импортов, таких как next/dynamic.
    • Сложные экспорты: Определённые типы экспортов, например export { foo as "string name" }.
    • Не-ES модули: Модули CommonJS не поддерживают tree-shaking.
    • Barrel-файлы: Реэкспорты из barrel-файлов неэффективны, с ограничениями в пропуске модулей без побочных эффектов.
    • Фрагментация: В некоторых случаях tree-shaking может создавать слишком много фрагментов, что приводит к неэффективным бандлам.
  • Хеширование идентификаторов модулей (частично): В процессе. Хеширование ID модулей частично реализовано, но мы работаем над улучшением производительности. После полной реализации это поможет уменьшить итоговый размер бандла.
  • Манглинг имён экспортов: В процессе. Это включает сокращение имён экспортов для уменьшения итогового размера бандла.
  • Поднятие областей видимости (Scope Hoisting): Пока не реализовано. Поднятие областей видимости поможет уменьшить размер бандла за счёт объединения небольших JavaScript-модулей в единую область видимости, что снизит накладные расходы и улучшит производительность.
  • Оптимизированная чанковка JS для production: Пока не реализовано. Разделение JavaScript-кода для минимизации дублирования критически важно для улучшения скорости загрузки, особенно для крупных приложений.

Следите за обновлениями

Мы рады с уверенностью рекомендовать next dev --turbo и с нетерпением ждём отзывов о том, как это улучшит ваш опыт разработки. Попробуйте уже сегодня и убедитесь в приросте производительности сами.

Это только начало — впереди реализация постоянного кеширования и production-сборок, которые сделают ваш рабочий процесс ещё быстрее и надёжнее.

Мы будем делиться новыми обновлениями по мере прогресса в обеспечении корректности и оптимизации производительности для бесшовной работы даже с самыми крупными приложениями. Следите за будущими релизами и улучшениями, пока мы работаем над тем, чтобы сделать Turbopack лучшим решением как для разработки, так и для production-сборок.

Участники

Мы благодарим тысячи разработчиков, которые участвовали в тестировании, сообщали о проблемах и проверяли исправления на протяжении бета-версии и фазы релиз-кандидата Turbopack.

Этот релиз стал возможен благодаря: