Como criei um site Next.js multilingue em 3 dias

Um aplicativo móvel sem um site é como um restaurante sem letreiro. Você pode ter a melhor cozinha do mundo, mas ninguém o encontrará. Quando percebi que o TAMSIV precisava de um site de apresentação — landing page, preços, FAQ, páginas legais — estabeleci uma meta ambiciosa: 3 dias, nem um a mais.

72 horas depois, tamsiv.com estava online. Multilíngue (6 idiomas), responsivo, com um herói animado, páginas otimizadas para SEO e uma pontuação Lighthouse de 94/100/100. Aqui está o relato completo deste sprint, as escolhas técnicas, as armadilhas e o que eu faria diferente.

Pontos-chave a reter:
- Next.js 16 com App Router é ideal para um site de apresentação multilíngue e de alto desempenho
- A internacionalização com next-intl deve ser configurada desde o início, não adicionada depois
- Sempre execute npm run build localmente antes de implantar no Vercel
- O responsivo exige mais iterações do que o esperado — reserve 30% do tempo total
- Uma pontuação Lighthouse 90+ é alcançável em 3 dias com as escolhas de arquitetura certas

Por que Next.js em vez de Gatsby, Astro ou um simples HTML?

A escolha do framework não é trivial. Considere várias opções:

• HTML/CSS estático: O mais simples, mas inviável para 6 idiomas e mais de 20 páginas. Cada modificação precisa ser replicada 6 vezes.
• Gatsby: Bom para sites estáticos, mas o tempo de build e o ecossistema de plugins envelhecido me desanimaram.
• Astro: Excelente para conteúdo estático, mas eu sabia que precisaria de componentes interativos (autenticação, painel) mais tarde.
• Next.js 16: App Router, React Server Components, renderização híbrida (estática + dinâmica), i18n nativo. E o mais importante, eu conheço React — é o mesmo ecossistema do frontend móvel TAMSIV.

A escolha do Next.js também se impôs por uma razão prática: eu sabia que o site evoluiria além de um simples site de apresentação. O sistema de autenticação por QR code, o painel do aplicativo, o painel de administração — tudo isso requer um framework capaz de gerenciar páginas dinâmicas protegidas.

Como organizar um sprint de 3 dias de forma eficiente?

Três dias é pouco tempo. Sem planejamento, você passa o primeiro dia configurando seu ambiente e chega ao terceiro sem conteúdo. Veja como dividi o sprint:

Dia 1: Fundamentos técnicos (10 horas)

O primeiro dia é inteiramente dedicado à infraestrutura técnica. Nada visível para o usuário, mas todo o resto depende disso:

• Configuração do Next.js 16 com TypeScript, App Router, Tailwind CSS 4
• Internacionalização com next-intl — 6 idiomas (FR, EN, DE, ES, IT, PT) configurados desde o início
• Roteamento localizado: /fr/fonctionnalites, /en/features, /de/funktionen... cada página tem uma URL traduzida
• Layout básico: Cabeçalho, rodapé, navegação responsiva, tema escuro (#101922)
• Configuração do Vercel: Repositório Git conectado, implantações de visualização automáticas

O roteamento localizado me custou 2 horas de configuração sozinho. Com next-intl, cada rota deve ser declarada com suas traduções de slugs. É verboso, mas resulta em URLs limpas e amigáveis para SEO em cada idioma.

Dia 2: Conteúdo e design (12 horas)

O dia mais intenso. É aqui que o site toma forma:

• Herói animado: Plano de fundo de partículas em um fundo escuro #101922, com um CTA principal. Usei uma cena 3D Spline para o visual principal.
• Páginas de conteúdo: Casos de uso (4 cenários), recursos (grade responsiva), preços (3 planos com comparação de recursos), FAQ (acordeão)
• Copywriting: Cada página primeiro em francês, depois traduzida. O tom: direto, informal, focado nos benefícios do usuário
• Responsivo: Onde passei a maior parte do tempo. As grades de recursos (3 colunas → 2 → 1) exigiram 3 iterações. O herói animado no celular exigiu um fallback estático para o desempenho.

Dia 3: SEO, desempenho e implantação (8 horas)

O último dia é dedicado a tudo o que torna o site "profissional":

• SEO técnico: generateMetadata() por página com Open Graph, idiomas alternativos, sitemap XML dinâmico
• Analytics: GA4 com Modo de Consentimento RGPD (sem rastreamento sem consentimento)
• Páginas legais: Termos legais, política de privacidade, CGU, cookies
• Desempenho: Otimização de imagens, lazy loading, preloading de fontes críticas
• Implantação Vercel: E então... a batalha.

Por que a primeira implantação do Vercel falhou?

O momento da verdade. git push, o build do Vercel começa... e falha. Erro de TypeScript. Depois outro. Depois um terceiro.

O que aconteceu: no desenvolvimento local, o Next.js é tolerante com certos erros de tipo. O build de produção (next build) é rigoroso. Tipos implícitos any, imports ausentes, props opcionais não tratadas — tudo isso passa no desenvolvimento e quebra na produção.

A lição, aprendida da maneira mais difícil: sempre execute npm run build localmente antes de fazer o push. Leva 30 segundos e evita 3 horas de depuração nos logs do Vercel (que são menos legíveis do que a saída local).

Os erros mais comuns que corrigi:

• Tipos implícitos: function Component({ data }) → function Component({ data }: { data: DataType })
• Imports não utilizados: O build os trata como erros, não como avisos
• Variáveis de ambiente: Prefixo NEXT_PUBLIC_ obrigatório para variáveis acessíveis no lado do cliente
• Metadados alternativos: As URLs de cada idioma devem ser absolutas, não relativas

Como configurar a internacionalização com next-intl desde o início?

A i18n foi o tópico que mais me consumiu tempo no Dia 1. Com next-intl, a configuração inicial exige rigor:

1. Arquivos de mensagens: Um arquivo JSON por idioma (messages/fr.json, messages/en.json...). Estrutura idêntica, chaves idênticas, valores traduzidos.
2. Middleware: Detecção automática do idioma do navegador, redirecionamento para o prefixo correto (/fr/, /en/).
3. Roteamento: Cada página está em uma pasta [locale]. Os slugs são traduzidos via um arquivo de mapeamento.
4. Componentes: useTranslations('section') para acessar as traduções em cada componente.

A armadilha clássica: começar sem i18n e adicioná-la depois. Já vi projetos onde isso custou semanas de refatoração. Ao colocá-lo no Dia 1, cada componente já está pronto para 6 idiomas. A tradução automática via LLM se encarrega do resto.

Um ponto importante: o conteúdo HTML do blog é armazenado em arquivos separados (content/blog/{locale}/{slug}.html), não nos arquivos JSON. Por quê? Porque next-intl interpreta as tags HTML como variáveis ICU e gera erros. Essa separação me poupou horas de depuração.

Como obter uma pontuação Lighthouse 90+ com Next.js?

A pontuação final do Lighthouse: 94 Desempenho, 100 Acessibilidade, 100 SEO. Aqui estão as otimizações chave:

• Imagens otimizadas: Componente <Image> do Next.js com sizes e priority para o LCP. Formato WebP automático.
• Fontes críticas: next/font para Google Fonts com display: swap. Zero layout shift.
• Lazy loading: Todos os componentes abaixo da dobra carregados sob demanda. O herói animado é o único a ser carregado imediatamente.
• CSS atômico: Tailwind CSS 4 gera um CSS mínimo — apenas as classes usadas são incluídas.
• Geração Estática: Todas as páginas de conteúdo são pré-renderizadas no build. Zero servidor em tempo de execução para conteúdo estático.

O ponto de desempenho mais crítico era o herói animado. A animação de partículas em um fundo escuro era bonita, mas pesada. Tive que implementar um limite: no celular, a animação é substituída por um gradiente estático. No desktop, ela só começa após o LCP (Largest Contentful Paint).

Quais páginas são indispensáveis para um site de apresentação de aplicativo móvel?

Para um lançamento, você não precisa de 50 páginas. Aqui está o mínimo viável que criei em 3 dias:

1. Landing page: Herói + casos de uso + recursos + preços + FAQ + CTA. Isso representa 80% do tráfego.
2. Sobre: Quem está por trás do projeto. Para um desenvolvedor solo, é um trunfo de credibilidade.
3. Política de Privacidade: Obrigatório para a Play Store e o RGPD.
4. Termos de Serviço: Obrigatório para assinaturas in-app.
5. Política de Cookies: Obrigatório com o consentimento de cookies RGPD.
6. Blog: Opcional no lançamento, mas eu montei a estrutura no Dia 3. O blog se tornou um importante canal de aquisição de SEO.

Cada página existe em 6 idiomas graças à i18n. Isso resulta em mais de 30 páginas geradas a partir de 6 modelos. A relação esforço/impacto da i18n é enorme — falo sobre isso em detalhes no meu artigo sobre a i18n como canal de aquisição.

Como o site evoluiu após o sprint inicial?

Os 3 dias lançaram as bases. Desde então, o site evoluiu consideravelmente:

• Aplicativo de painel (/app/tasks, /app/memos, /app/agenda): Interface web completa para gerenciar tarefas e memorandos de um navegador. Autenticação por QR code ou e-mail.
• Painel de administração (/admin/dashboard): Métricas de usuário, gráficos Recharts, alertas. Detalhado no artigo sobre o painel de administração.
• Blog SEO: Mais de 40 artigos técnicos otimizados para SEO, com imagens geradas por IA.
• Roadmap público: Página de roadmap com funcionalidades entregues e futuras.
• Guia do usuário: Documentação interativa para novos usuários.

Tudo isso não teria sido possível sem as bases sólidas dos 3 primeiros dias. O App Router do Next.js, a i18n nativa, a implantação automática do Vercel — cada peça colocada no início facilitou as adições subsequentes.

Quais dicas para um desenvolvedor solo que lança seu site em sprint?

Se tu és um desenvolvedor solo e queres lançar um site de apresentação rapidamente, aqui estão as minhas 5 recomendações:

1. Escolhe um framework que tu conheças: Não é hora de aprender. Usa o que tu dominas.
2. Configura a i18n no Dia 1: Mesmo que tu traduzas apenas para um idioma, a estrutura estará pronta. Adicionar as traduções mais tarde será trivial.
3. Build local antes de cada push: npm run build. Sistematicamente. Sem exceção.
4. Mobile first para o CSS: Começa pelo mobile, adiciona os breakpoints desktop. O inverso sempre custa mais tempo.
5. Lança cedo, itera depois: Um site imperfeito online é melhor do que um site perfeito que só existe no localhost. As correções virão.

FAQ

Quanto custa a hospedagem de um site Next.js no Vercel?

O plano gratuito do Vercel é suficiente para a maioria dos sites de apresentação. Inclui SSL, CDN global e implantações de visualização. Ainda uso o plano gratuito para tamsiv.com, mesmo com mais de 40 páginas e tráfego regular.

É necessário Tailwind CSS ou outro framework CSS?

Tailwind CSS é ideal para um sprint rápido. Você codifica o design diretamente no JSX, sem a necessidade de arquivos CSS separados. A desvantagem: o código HTML é verboso. Mas para um desenvolvedor solo que quer ser rápido, o excesso de legibilidade é amplamente compensado pela velocidade de desenvolvimento.

Como gerenciar traduções sem um tradutor profissional?

Eu uso um script de tradução automática via OpenRouter (LLM). O script detecta as chaves modificadas (apenas o delta), traduz apenas o que mudou e custa cerca de 0,05 EUR por passagem. A qualidade é muito boa para textos técnicos. Os detalhes estão no artigo sobre a i18n em 6 idiomas.

O SEO é suficiente com generateMetadata do Next.js?

generateMetadata() gerencia o título, a descrição, o Open Graph e os alternates (hreflang). Isso é suficiente para 90% das necessidades de SEO on-page. Adicionei um sitemap dinâmico e um robots.txt para o rastreamento. O restante (backlinks, conteúdo, autoridade) depende do blog e do marketing.

É possível fazer o mesmo sprint com Astro em vez de Next.js?

Sim, Astro seria ainda mais rápido para um site puramente estático. Mas se você planeja adicionar páginas dinâmicas (autenticação, painel) mais tarde, Next.js ainda é a melhor escolha. A transição de estático para dinâmico é transparente com o App Router.