Três anos atrás eu estava em uma ligação com um cliente em Toronto, assistindo a um build Next.js se arrastar por 94 segundos enquanto fingíamos que estava tudo bem. Webpack. Oito mil módulos. Um monorepo com componentes de UI compartilhados que ninguém tinha auditado desde 2021. O cliente perguntou se poderíamos "tornar mais rápido". Coloquei dois dias de trabalho no orçamento. Levou quatro. E mesmo assim conseguimos reduzir para 61 segundos, o que pareceu vencer uma corrida que ninguém queria estar.
Turbopack mudou essa história. Bem, quase. Mas aqui em 2026, continuo vendo desenvolvedores assumir que mudar para Turbopack é uma linha de chegada e não um ponto de partida. Eles ativam o flag, cortam 40% do tempo de startup do servidor dev, e chamam de done. Os verdadeiros gargalos apenas se mudaram para um lugar mais silencioso.
Então deixe-me caminhar você através de para onde o tempo de build realmente vai quando você está rodando Turbopack em uma base de código real de produção. Não um app todo. Não o template de exemplo do Next.js. Um site real com 200+ rotas, integração com CMS, e um cliente que nota cada segundo.
A Lacuna Entre Modo Dev e Builds de Produção
Aqui está a coisa que a maioria das pessoas perde: as maiores vitórias do Turbopack são no servidor dev. Compilação incremental, cache em nível de módulo, todo o gráfico com poder de Rust. Em modo dev, é genuinamente transformador. Cronometrei um cold start em um projeto cliente Seahawk indo de 28 segundos sob webpack para menos de 4 com Turbopack. Isso não é um erro de arredondamento.
Mas next build é um animal diferente. A partir do início de 2026, o suporte de build de produção do Turbopack é estável mas não reescreve todo o pipeline. Análise estática, otimização de página, e o compilador SWC continuam fazendo trabalho pesado junto com o bundler do Turbopack. Você não está ganhando um 10x uniforme no output de produção.
Isso importa porque desenvolvedores benchmarkam a coisa errada. Eles observam next dev ligar e concluem que o build é rápido. Depois CI leva 3 minutos e eles encolhem os ombros.
O Que a Arquitetura do Turbopack Realmente Faz
Turbopack opera em um modelo de computação orientado por demanda. Constrói apenas o que é solicitado, faz cache em nível de módulo, e invalida precisamente em vez de amplamente. É por isso que a escrita de arquitetura do time Vercel fala sobre "memoização em nível de função." Não é marketing. É o mecanismo real por trás do motivo de tocar um componente não forçar um re-bundle completo.
A implicação: seus ganhos mais rápidos acontecem onde a invalidação era anteriormente muito ampla. Arquivos utilitários compartilhados, grandes exportações de barrel, re-exportações profundamente aninhadas. Esses são os lugares onde Webpack estava te punindo silenciosamente.
Para Onde o Tempo Realmente Desaparece em 2026
Auditei quatro bases de código no trimestre passado usando NEXT_TURBOPACK_TRACING=1. Sim, aquela variável de ambiente existe e sim, ela cospe um arquivo de trace que você pode carregar no painel de performance do Chrome. Altamente recomendado antes de assumir que qualquer coisa particular é o culpado.
Aqui está o que encontrei, ranqueado grosseiramente por quantas vezes aparecem:
- Explosões de arquivos barrel. Um único
index.tsre-exportando 60 componentes de um design system puxa cada um desses módulos no gráfico mesmo se você usar dois. Turbopack lida com isso melhor que Webpack mas não faz o problema desaparecer. A correção é importações granulares. Sempre. - Type-checking não separado do bundling. Rodar
tsc --noEmitdentro do mesmo pipeline de build que Turbopack está processando está dobrando seu tempo de wall. Separe. Type checking de TypeScript e bundling do Turbopack devem ser jobs paralelos em CI, não passos sequenciais. - IDs de módulos instáveis em pacotes de terceiros. Alguns pacotes npm ainda entregam CommonJS com requires dinâmicos. Turbopack tem que recorrer a caminhos de análise mais lentos para esses. Enfrentei isso no mês passado com uma versão antiga de uma biblioteca de geração de PDFs. Atualizei, economizei 8 segundos.
- Otimização de imagens em tempo de build. Se você está pré-gerando milhares de variantes de imagem com
next/imagee uma exportação estática, isso é síncrono e vinculado à CPU. Não é Turbopack. Mas aparece no trace do build e as pessoas culpam o bundler. - Grandes payloads de dados em `getStaticProps`. Buscar 4MB de dados CMS por página durante o build, em 300 páginas, é um problema de rede e parsing. De novo, não é Turbopack. Mas fica dentro do mesmo build de 180 segundos e é culpado coletivamente.
A verdade desconfortável é que Turbopack acelerou a fase de bundling tão drasticamente que tudo ao seu redor agora parece lento por comparação. É como atualizar sua lixeira de cozinha para abrir automaticamente e depois perceber que a caminhada até o contêiner de lixo lá fora é o inconveniente real.
O Problema dos Barrel Files Merece Sua Própria Seção
Não consigo enfatizar isso o bastante. Barrel files são a ferida de build mais comum auto-infligida que vejo entre agências.
Um cliente veio até nós no final de 2025 com uma biblioteca de componentes que tinha essa estrutura:
`` components/ index.ts (exports 140 named components) ``
Cada página importando até mesmo um botão puxava o gráfico inteiro de 140 componentes. Com Webpack, tree-shaking ajudava parcialmente em tempo de output. Com Turbopack, o gráfico de módulos ainda tinha que ser percorrido e compreendido antes que qualquer coisa pudesse ser removida. O dev server não era lento por si, mas cold starts eram dolorosos.
Reestruturamos para imports específicos de caminho:
`` import { Button } from '@company/ui/button' import { Modal } from '@company/ui/modal' ``
O cold dev start caiu de 11 segundos para menos de 3. O build de produção caiu 22 segundos. Ninguém tocou na config do Turbopack. A solução foi apenas... não ser preguiçoso sobre imports.
Na verdade existe uma boa regra eslint-plugin-import para pegar essas: import/no-barrel-files. Adicione ao seu config de lint e trate violações como débito de build.
Cache em CI: Você Provavelmente Está Deixando 40 Segundos na Mesa
O cache local do Turbopack é excelente. Cache em CI é um problema separado e a maioria das equipes configura uma vez e nunca revisita.
O cache do Turbopack vive em .next/cache/turbopack por padrão. Se seu pipeline de CI (GitHub Actions, CircleCI, o que for) não está persistindo esse diretório entre execuções, você está fazendo um build cold completo toda vez. Em uma base de código de qualquer tamanho razoável, isso são 30 a 60 segundos de puro desperdício por execução.
Aqui está como uma cache key apropriada se parece para uma setup de Next.js + Turbopack em GitHub Actions:
- Cache key: hash de
package-lock.json+ hash denext.config.js+ hash detsconfig.json - Cache path:
.next/cache - Restore keys: voltar para cache anterior no mesmo branch, depois main
É isso. A maioria das equipes só faz hash de package-lock.json. Mas se seu next.config.js muda a config do Turbopack (features experimentais, aliases de módulos, custom loaders), você quer que isso seja invalidado. Já vi bugs onde um cache stale estava servindo resoluções de módulo incorretas depois de uma mudança de config. Chato de debugar às 23h.
Seahawk teve um projeto fintech onde apenas corrigir a estrutura da cache key reduziu o build médio de CI de 4 minutos 20 segundos para 2 minutos 50 segundos. Mesmo código. Mesmo hardware. Apenas invalidação de cache mais inteligente.
Custom Loaders e Por Que Estão Matando Seus Ganhos
Turbopack suporta custom loaders, mas há um custo. Todo custom loader o tira do fast path nativo do Turbopack e coloca em uma camada de compatibilidade. O time do Vercel é bem honesto sobre isso na documentação de configuração Turbopack do Next.js.
Vejo isso mais frequentemente com:
- Loaders SVG (pessoas convertendo SVGs para componentes React no tempo de build)
- MDX com cadeias pesadas de plugins remark/rehype
- CSS Modules com configurações customizadas de PostCSS que incluem plugins raramente usados
Para SVGs especificamente, o movimento em 2026 é pré-compilar sua biblioteca de ícones para componentes React como um passo de build separado, não no tempo de build do Next.js. SVGR é excelente para isso como um script standalone. Execute quando seus design tokens mudarem, faça commit do output, e deixe o Turbopack tratá-los como arquivos .tsx normais.
MDX é mais complicado. Se você está executando 40 plugins remark, vai sentir. Audite quais você realmente precisa. Já vi bases de código executando remark-gfm, remark-smartypants, um plugin de notas de rodapé customizado, e dois outros, onde apenas dois deles estavam produzindo diferenças de output visíveis. Corte os não utilizados.
O Imposto de Resolução de Módulos Que Ninguém Fala
Path aliases. Todo mundo usa. @/components, @/lib, ~/utils. São convenientes. São também um pequeno imposto que se compõe.
Turbopack resolve aliases em cada encontro de import. Em uma base de código grande com 4.000 imports e 12 aliases configurados, são 48.000 operações de resolução por build. Não é catastrófico. Mas também não é grátis.
A solução não é remover aliases. É ser preciso com eles. Evite padrões de alias wildcard onde um caminho específico fará. E mantenha seus paths do tsconfig.json sincronizados com sua configuração turbopack resolveAlias do next.config.js. Desvio entre esses dois faz Turbopack fazer trabalho de resolução redundante. Já vi economias de 4-5 segundos apenas limpando isso.
O Que Turbopack em 2026 Ainda Não Faz
Olha, eu gosto do Turbopack. Usamos em a maioria dos novos projetos da Seahawk. Mas honestidade importa.
- Análise de bundle não é tão madura quanto o ecossistema do Webpack.
@next/bundle-analyzerfunciona mas a visualização é menos granular que a que você consegue dowebpack-bundle-analyzer. Isso está melhorando mas não está lá ainda. - Ecossistema de plugins é menor. Se seu stack depende de plugins Webpack altamente customizados (alguns setups legados enterprise fazem), migração ainda é um projeto real, não uma tarde.
- Desempenho do Windows historicamente ficou atrás de macOS e Linux. Isso está melhorando com cada release do Next.js, mas se seu time é pesado em Windows, faça benchmark antes de se comprometer.
Nenhum desses são dealbreakers. Mas são considerações reais se você está avaliando se migrar um projeto existente versus começar do zero.
Como Realmente Traçar Seu Build
Pare de adivinhar. Execute isso:
- Configure
NEXT_TURBOPACK_TRACING=1em seu ambiente - Execute
next build(ounext devse está fazendo profile da startup dev) - Abra
.next/traceno Perfetto UI ou nochrome://tracingdo Chrome - Filtre por duração. Qualquer coisa acima de 2 segundos em um módulo único vale investigar.
Essa é a mesma abordagem que uso antes de qualquer engajamento de otimização de build. O trace te diz onde o tempo vai. Tudo mais é adivinhação disfarçada de expertise.
---
FAQ
Turbopack é estável o suficiente para builds de produção em 2026?
Sim, suporte de build de produção chegou como stable no final de 2024 e amadureceu significativamente através de 2025. Para a maioria dos projetos Next.js começando do zero, eu teria o padrão Turbopack sem hesitação. Para projetos legados com customização pesada de Webpack, faça um spike primeiro e meça.
Turbopack substitui SWC?
Não. SWC é o transpilador de TypeScript e JSX. Turbopack é o bundler. Eles trabalham juntos. Turbopack usa SWC internamente para transformação. Você não escolhe entre eles.
Por que meu servidor de dev Turbopack é rápido mas a build de CI ainda é lenta?
Quase com certeza um destes: type-checking rodando em série com bundling, nenhum cache de CI configurado para .next/cache, ou otimização de imagens dominando a fase de geração estática. Execute o trace. Ele mostrará qual é.
Devo migrar um projeto Webpack existente para Turbopack agora?
Se for um greenfield ou projeto de baixa customização, sim. Se você tem 15 plugins Webpack customizados e uma cadeia de loaders complexa, reserve um sprint de migração adequado. Não faça isso como um afterthought numa sexta à tarde. (Falo por experiência pessoal. Não pergunte sobre a sexta.)
Turbopack funciona com monorepos Nx ou Turborepo?
Sim, e na verdade bem. O cache do Turborepo se empilha muito bem no topo do cache interno do Turbopack, e as duas ferramentas compartilham linhagem do mesmo time. A combinação é genuinamente boa para monorepos grandes onde apenas um subconjunto de pacotes muda por PR.
---
Build tooling é chato até sua conta de CI ser $800 por mês e seu time de dev reclamar sobre cold starts no standup. Turbopack moveu o gargalo, o que é progresso. Mas não eliminou a necessidade de pensar claramente sobre para onde o tempo vai. Trace primeiro. Otimize segundo. E pelo amor de tudo, corrija seus barrel files.