- A partir do Next.js 15.1.8, a forma de processar metadados mudou, causando problemas graves em ambientes de deploy fora da Vercel
- Os metadados não são mais renderizados diretamente no
head do HTML, e sim enviados separadamente por meio de um método chamado "metadata streaming"
- Se o mecanismo de busca não executar JavaScript, os metadados simplesmente não aparecem, destruindo o SEO de forma crítica
- Há um tratamento de exceção com detecção de crawler (
htmlLimitedBots), mas ele não é perfeito
- Ambientes que não são a Vercel, como Netlify, Cloudflare e AWS, tentam compatibilidade com o OpenNext, mas na prática o Next.js está fortemente acoplado demais à infraestrutura da Vercel, o que torna a própria portabilidade difícil e cheia de bugs
- Mesmo builds estáticos não incluem metadados no
head do HTML, e a estrutura passou a forçar todos os ambientes de deploy a lidar com detecção complexa de crawler/execução de JS
- Questão de segurança (vulnerabilidade crítica divulgada em março de 2025)
- Insistir em versões antigas para evitar o metadata streaming expõe a falhas graves de segurança (o patch foi fornecido apenas no 15.2.3)
- O metadata streaming, na prática, esconde problemas de desempenho da página e ainda impacta negativamente o SEO
- Conclusão:
O Next.js parece open source, mas na prática se tornou um framework com dependência séria da Vercel; por isso, é mais sensato considerar outras opções em novos projetos
Visão geral
- A partir da versão 15.1.8 do Next.js, surgiram problemas graves no tratamento de metadata em ambientes que não sejam a Vercel
- Isso aprofunda a dependência estrutural da infraestrutura da Vercel no Next.js e ainda provoca piora em SEO e até riscos de segurança
O início do problema: a introdução do metadata streaming
- Em 2024, a Vercel introduziu um recurso experimental chamado metadata streaming
- Diferentemente da abordagem anterior, metadata (tags como title, description, Open Graph etc.) não é renderizado diretamente no `` do HTML, mas enviado separadamente após o carregamento inicial da página
- Esse recurso passa a exigir execução de JavaScript
A explicação técnica da Vercel e os problemas reais
- Motivo da adoção: resolver um gargalo computacional na geração de metadata
- Mas, na prática, metadata costuma ser um volume estático e pequeno de dados (menos de 1 KB)
- O custo de um round-trip ao servidor é maior do que o processamento inline
- Metadata dinâmica é um caso extremamente excepcional
- A implementação do metadata streaming aumenta a complexidade e a confusão
O contexto do problema de desempenho
- Alguns desenvolvedores relataram problemas de desempenho por atraso na geração de metadata, como em integrações com APIs externas
- Para resolver isso, a Vercel desenvolveu a abordagem de streaming
Crawlers de busca e impacto em SEO
- Motores de busca que não executam JavaScript não conseguem ler os metadados
- Como consequência, isso tem grande impacto negativo em SEO
- Como solução, a Vercel oferece o recurso htmlLimitedBots, em que o servidor detecta crawlers e, nesses casos, ignora o streaming e insere metadata no HEAD
Limitações de outros provedores de nuvem
- Netlify, Cloudflare, AWS e outros também criaram o projeto adaptador OpenNext para compatibilidade com o Next.js
- Mas, como o Next.js é dependente demais da Vercel, o porte exige reverse engineering
- Por causa de problemas de qualidade no OpenNext, na prática ele não funciona direito
Nem mesmo o build estático é completo
- Até mesmo o build de site estático (Static Build) deixou de incluir metadata no
head do HTML
- Como ele é empacotado junto com React Server Components, passa a exigir execução de JavaScript
- Surge assim o absurdo de ter que implementar por conta própria até lógica de detecção de crawler só para metadados HTML básicos
Vulnerabilidade grave de segurança e problema de atualização
- Em 21 de março de 2025, foi divulgada uma vulnerabilidade crítica (nível de segurança 9.1, GHSA-f82v-jwr5-mffw/CVE-2025-29927)
- Essa falha permite contornar a segurança de autenticação do middleware por meio da manipulação de certos headers
- O patch foi aplicado no Next.js 15.2.3, mas permanecer no 15.1.8 para evitar o metadata streaming deixa o sistema muito vulnerável
Resultados negativos trazidos pela adoção do streaming
- O metadata streaming esconde ainda mais problemas de desempenho
- Se houver atraso no processamento dos metadados da página, o usuário real não percebe
- Já os crawlers de mecanismos de busca podem aplicar penalidade na pontuação de SEO por causa da lentidão da resposta
Conclusão
- O Next.js se transformou em um vendor lock-in da Vercel disfarçado de framework open source
- Ao escolher a stack tecnológica de um próximo projeto, é mais prudente considerar outros frameworks em vez de Next.js
5 comentários
Então o Remix acaba sendo a alternativa, né?
Como mencionado no texto, há lock-in de fornecedor excessivo, comportamentos de caixa-preta demais e APIs pouco intuitivas. Além disso, do lado do React também estão promovendo abertamente esse estilo de desenvolvimento com renderização no servidor como se fosse o padrão do React. Acho que, para a maioria dos apps, uma SPA baseada em Vite já é suficiente.
Eu até reconheço que existe um certo vendor lock-in, mas as opiniões sobre a tecnologia do Next.js em si, quando você simplesmente lê, parecem não passar do nível de "não quero ler o texto".
Há tempos vinha fingindo ser aberta, mas mantendo uma postura fechada, e agora acabou praticamente trancando as portas.
Opiniões no Hacker News
Não recomendo usar Next de jeito nenhum. A experiência de desenvolvimento é terrível, o vendor lock-in é forte, e por causa de convenções estranhas não documentadas parece que há minas terrestres por toda parte se não for um SaaS B2B simples focado em CRUD. Em especial, já vivi um caso em que a tag Next
<Image />derrubou o FPS de uma cena WebGL na mesma página para 2Fico me perguntando como a Vercel conseguiu cozinhar lentamente usuários comuns de React no vendor lock-in. React era um projeto da Meta que enfatizava open source, e eu esperava que o open source ajudasse a evitar vendor lock-in, então é decepcionante ver que na prática não foi assim
Concordo totalmente. Usei Next de novo recentemente depois de muito tempo e a experiência de desenvolvimento foi extremamente decepcionante. A documentação era vaga e difícil de encontrar, e o app em si parecia lento por padrão. Ao tentar fazer deploy na AWS com Docker, passei por inúmeras dificuldades por causa do Dockerfile de exemplo fornecido pela Vercel
Fico curioso se você analisou diretamente esse problema do
<Image />ou se está supondo que é um problema do NextJs. Eu trabalho com a combinação NextJs,<Image>e RTF, mas nunca passei por algo assimUsei Next.js no trabalho nos últimos 3 anos e a sensação é de puro sofrimento. Hospedamos na Vercel, e a empresa adotou quase todos os serviços da Vercel, então vivemos um vendor lock-in de verdade. Antes compartilhei uma experiência ruim num post do Dan no HN sobre RSC, e senti que os apontamentos dele estavam certos. Como naquela fala de que "o próprio RSC já está bem sólido agora, mas frameworks como o Next.js ainda são meio ásperos", no geral até o React agora parece abaixo da média, e o Next.js parece até acelerar essa má reputação. O melhor é manter distância
A Vercel vai corrigir esse bug, mas agora estou cansado do Next.js porque esses probleminhas ficam se acumulando. Por exemplo, o jeito de identificar prefetch no middleware está quebrado há semanas, talvez meses. Como esses detalhes pequenos continuam se acumulando, estou bem desgastado com o Next.js. Mas ainda gosto muito do ecossistema JS em si
Saí do Next.js e fui para Astro. Eu queria voltar ao básico, mas configurar manualmente rotas/templates/assets estáticos/build era trabalhoso. O Astro cuida de tudo isso e ainda é SSR por padrão. Dá para usar React/Vue como uma camada de interatividade em cima, do jeito que originalmente deveriam ser usados, e isso me fez perceber o quanto frameworks JS de fato são desnecessários. O Next foi ficando cada vez mais mágico, as server actions são estranhas, e havia coisas demais no estilo "jeito NextJS" de implementar
Hoje uso Next.js no trabalho e em projetos paralelos, mas é uma pena a direção tomada depois da transição de pages para app router, porque antes era uma ferramenta divertida e produtiva
A partir da versão 15.1.8, algumas bibliotecas 1 quebraram, então surgiu a situação de precisar fazer downgrade para a versão vulnerável mencionada pelo autor
Concordo. Daqui para frente, pretendo usar Next.js só para sites estáticos ou SPAs pré-buildadas
O Next está virando piada. Depois que o Remix virou react-router de um jeito quase incompreensível, parece que sobraram pouquíssimos frameworks React decentes. No fim, voltei para a combinação plain vite + tanstack router
Surpreende que um post tão crítico tenha permanecido no Hacker News. Uma vez publiquei um post dizendo que dava para implementar aquilo de forma mais simples com Remix, e vários funcionários da Vercel me mandaram mensagem pedindo para apagar ou sugerindo marcar reunião. Entraram em contato ao mesmo tempo por várias contas em redes sociais
Fico curioso se você quer dizer que não usa mais Remix depois da mudança de marca, ou se quer dizer que ele não é mais um framework. O RR7 (React Router 7) também funciona normalmente como framework 1. Fui backend por 15 anos e recentemente migrei para full stack; um bom amigo recomendou RR7 e eu fico impressionado todo dia
Testei TanStack Router em um projeto novo e gostei tanto que também adicionei TanStack Query e TanStack Form
Fico curioso sobre qual seria a melhor alternativa e por que usar Vite. Eu uso Next em projetos pequenos e ouvi dizer que a maior vantagem é SEO. Não basta só gerar arquivos estáticos e subir no S3?
Queria entender especificamente qual é o problema de o Remix ter virado react-router. Para mim, parece só um rebranding
Há anos venho enfatizando que é preciso ter muito mais cuidado com React, Next, Svelte etc. quando são conduzidos por empresas como a Vercel. O objetivo deles é fazer algo como Heroku, mas de forma muito mais agressiva, induzindo lock-in completo em toda a stack (linguagem-runtime-máquina). Outras empresas também têm problemas. Por exemplo, a ferramenta CLI de deploy da Cloudflare só suporta macOS 13.5+ (pouco mais de 2 anos), e não está claro o motivo. É triste ver um SO lançado há 2 anos já ser tratado como antigo. Até dá para usar uma versão antiga do wrangler, mas a documentação e os recursos não batem, e parece que isso só vai piorar. Em algum momento a compatibilidade também pode ser cortada. Em contrapartida, outras ferramentas (vim, neovim, emacs etc.) ainda funcionam em versões antigas do OS X. Acho que isso acontece porque essas ferramentas abertas não têm incentivo para lock-in
Next e RSC são, de tudo que já lidei no front-end, o mais frustrante. Front-end por si só já é problemático o bastante, aí ainda se adiciona a "mágica" do Next e o vendor lock-in da Vercel. No time, nesta semana vamos migrar para tanstack router e vite e tentar construir um CSA comum, e estou animado
Todo mundo deveria falar mais do fato de que, no modo de desenvolvimento do Next.js, compilar rotas leva 10 segundos. O compilador Rust parece estar ali no canto fumando um cigarro
É de um nível inutilizável. A pior devx que já experimentei. A última vez que odiei uma stack nesse nível foi quando tive que ajudar com um site em Sharepoint
Agora até JS, que é só uma linguagem de script, passa por múltiplas etapas de build/compilação e já leva mais tempo que compiladores de C++. Já está num ponto em que talvez colocar até o Clang no navegador daria uma experiência melhor. Para referência, na empresa também usamos PHP e o mesmo problema acontece. Por ser linguagem de script, achei que seria simples, mas por limitações de performance do próprio PHP precisamos ter geração prévia de código e uma etapa separada de build do composer. Só que esse build feito por desenvolvedores PHP também é lento. Talvez porque não foi feito pelos criadores do GCC
Estranhamente, a opção
next dev —-turbotambém não é mais rápida na base de código da nossa empresaO compilador Rust realmente está compilando alguma coisa; fico em dúvida se o compilador do Next.js está de fato fazendo um trabalho tão complexo assim
É triste ver o estado atual do Next.js. Ainda uso, mas a ponto de precisar manter um fork e aplicar patches por conta própria.
next.config.jsé uma rota de fuga acidentada para mudar o comportamento padrão, e acho que essas opções deveriam ter sido oferecidas como pontos de extensão desde o início, em vez de ficarem escondidas atrás de "feature flags". Hoje está mais para um framework nota D quase espagueteSe não for NextJS, qual seria a combinação recomendada pensando em stack completa? Sou desenvolvedor backend há 15 anos, mas não mexia com front desde AngularJS. Recentemente tentei pesquisar para criar um app full stack por causa de um side project, e tanto o Gemini quanto a documentação oficial recomendavam NextJS. Ainda estou no começo, então quero aprender alternativas. Pretendo operar tudo diretamente em um VPS com Docker, então evito Vercel/Netlify
Se você não precisa de server rendering, recomendo React sem framework com Vite 1. Durante o desenvolvimento você roda com Vite, e no build de produção saem só arquivos HTML + JS, então basta subir num hosting estático como S3. Uso assim há mais de 10 anos e nunca tive problema. No backend, use o que for mais confortável para você; hoje em dia eu uso bastante PostgREST 2. Para chamadas de API no cliente, recomendo react-query 3
Fico curioso sobre que tipo de projeto você está desenvolvendo. Estou criando um webapp SaaS típico, e a combinação React/Refine.dev/Vite funcionou muito bem. Com o Refine.dev, dá para focar só no desenvolvimento das funcionalidades sem se preocupar com páginas CRUD
Acho que essa questão está sendo exagerada. Para quem entende como streaming funciona no React, é conhecimento básico que não dá para fazer stream de HTML linha por linha. Não se deve bloquear até o first paint por causa de metadata (HTML, não JS). Faz sentido tratar alguns user agents como exceção nesse comportamento. Na maior parte do tráfego, o importante é mostrar algo o mais rápido possível. Se houver usuários para quem o carregamento de metadata demora muito, fico curioso sobre como isso deveria ser resolvido