Executando verificação de segurança...
2

Engenharia de Performance: Como atingi 100/100 no Lighthouse gerando 500+ páginas estáticas com Next.js 14

Fala pessoal,

Queria compartilhar um case técnico de uma ferramenta de nicho (Web App) que desenvolvi para resolver um problema de integridade de dados em conversões físicas (densidade de materiais), e usei como laboratório para testar a performance do Next.js 14 (App Router) no limite.

O projeto é o Culinary Converters.

A premissa parece simples, mas a execução técnica envolveu mapear a densidade específica (g/mL) de 500+ ingredientes para permitir a conversão bidirecional entre qualquer unidade de Volume (ml, xícaras, colheres) e Massa (gramas, onças, libras) instantaneamente:

Interface do Culinary Converters

⚙️ Os Desafios de Engenharia

Não queria apenas "mais uma calculadora". O objetivo era ter a melhor performance possível e uma arquitetura escalável para SEO Programático.

Aqui está o que aprendi no processo:

1. SSG em Escala (Static Site Generation)

Para garantir indexação e TTFB (Time to First Byte) próximo de zero, optei por gerar todas as rotas de conversão no build time.

  • Desafio: Gerar 500+ páginas estáticas sem explodir o tempo de build.
  • Solução: Uso agressivo de generateStaticParams do App Router. O site inteiro é pré-renderizado. Quando o usuário acessa uma conversão específica (ex: Almond Flour), ele está baixando HTML puro e cacheado na Edge, sem bater no servidor para calcular.

2. A Obsessão pelo 100/100 no Lighthouse

A maioria das aplicações modernas sofre com Cumulative Layout Shift (CLS) e Hydration.
Para bater 100 em tudo (Mobile), tive que:

  • Usar fontes otimizadas (next/font) para evitar FOUT/FOIT.
  • Controlar a hidratação de componentes client-side (como os inputs da calculadora) para não travar a thread principal durante o carregamento inicial.

O Resultado:
Lighthouse Score 100

3. Lógica de Negócio e Hooks

Além da performance visual, a lógica de conversão precisava ser robusta. Implementei Custom Hooks para gerenciar a compatibilidade entre diferentes sistemas de medidas (Métrico vs Imperial) baseada na densidade do ingrediente selecionado, garantindo type-safety com TypeScript:

Snippet de Código VS Code

Tive também que implementar uma estratégia de aria-labels dinâmicos injetados via props para garantir que leitores de tela entendessem o contexto de cada um dos 500 ingredientes sem poluir a UI visualmente.

🎨 Stack

  • Framework: Next.js 14 (App Router)
  • Estilização: Tailwind CSS + Shadcn/UI (leve e responsivo)
  • Dados: JSON estático (optei por não usar DB externo na leitura para eliminar latência).
  • Deploy: Vercel (Edge Network).

Open Source

A parte da "inteligência" (o banco de dados de densidade e a lógica matemática) eu decidi abrir no GitHub. Se alguém estiver construindo algo na área de FoodTech ou precisar de um dataset limpo:

Website Link: Culinary Converters.
🔗 Repo: github.com/culinaryconverters

Se puderem testar a velocidade de carregamento e me dizer se sentem algum gargalo no mobile, agradeço muito o feedback!

Abraços.

Carregando publicação patrocinada...