Voltar
Como otimizar ao máximo um site feito com TanStack Start

Site com TanStack Start sai de 73 para 100 no Lighthouse mobile ao cortar JavaScript, imagens e fontes desnecessários

Aprofundamento CEVIU

Aprofundamento

O ponto de partida do autor foi uma nota 73 no PageSpeed Insights mobile para a home de um site migrado para TanStack Start. O elemento de LCP era um parágrafo, que levou 5,2 segundos para aparecer, mesmo com a página pré-renderizada e o texto já no HTML. O documento chegava em cerca de 110 ms. O atraso vinha de tudo o que carregava em volta, em boa parte JavaScript que ele nunca quis enviar.

Os ganhos mensuráveis vieram de não carregar coisas. Um import em um componente de card fazia todas as páginas baixarem o manifesto completo de 117 imagens, cerca de 35 KiB comprimidos. Depois da correção, o JavaScript com module preload da home caiu de aproximadamente 234 para 196 KiB. Diálogos fechados (busca, menu mobile, ampliação de imagem) foram carregados sob demanda com lazy e só montam na primeira interação. Só o motor de diálogo do Base UI pesava cerca de 14 KiB gzip em toda página.

Em fontes, o arquivo normal do Inter de cerca de 342 KiB virou subsets do Fontsource, e remover o eixo de optical size levou o Latin normal de 71,2 para 47,1 KiB. Os preloads caíram de três para um. A troca mais rápida gerou CLS perto de 0,21, resolvido com um fallback de métricas ajustadas para a Instrument Serif. Imagens escondidas por CSS continuavam sendo baixadas: eram nove requisições de navegação invisível no mobile.

As mudanças mais complexas deixaram dúvida. Extração de critical CSS com Beasties reduziu o CSS bloqueante de 20,6 a 29,7 KiB para 7,0 a 14,9 KiB por página, mas o autor não consegue creditar a nota final a isso e passou a manter uma allowlist de seletores. O React Compiler manteve os tempos e aumentou o JavaScript comprimido em 9,5 a 14,1 KiB por rota. Ele recomenda budgets de tamanho e testes de navegador para o ganho não evaporar. Os números são rodadas isoladas de laboratório, com várias mudanças entre elas.

Por que isso importa

Para quem opera uma app em TanStack Start, a leitura é que o relatório do Lighthouse aponta o sintoma, mas o trabalho está em abrir a aba Network e ver o que a página baixa sem precisar. Cortar manifestos, diálogos, fontes e imagens ocultas parece render mais do que técnicas sofisticadas, que cobram manutenção. Variação entre rodadas (91, 95 e 92 no mesmo build) também pede medianas, não uma medição só.

Perguntas frequentes

O que levou o site de 73 para 100 no Lighthouse mobile?

Segundo o autor, os ganhos atribuíveis vieram de remover o que não era necessário: o manifesto de imagens carregado em todas as páginas, diálogos fechados, imagens de navegação escondidas e arquivos de fonte desnecessários. O LCP caiu de 5,2 para 1,7 segundo. Técnicas mais complexas não tiveram o crédito comprovado.

Por que um parágrafo pré-renderizado demorou 5,2 segundos para aparecer?

O HTML chegou em cerca de 110 ms e já continha o texto. O atraso veio do JavaScript e de outros recursos carregados ao redor. Por isso comprimir a imagem do hero não ajudaria, já que o LCP era um parágrafo.

Critical CSS compensa em uma app TanStack Start?

No caso do autor, a extração com Beasties reduziu o CSS bloqueante, mas ele não consegue mostrar o efeito na nota. Ela também exigiu manter uma allowlist de seletores e rechecar modo escuro, fontes por variáveis CSS e controles de formulário. Ele só tentaria de novo com um gargalo claro de stylesheet no trace.

Como evitar que as otimizações se percam com o tempo?

O autor recomenda budgets de tamanho e testes de navegador, porque a próxima funcionalidade pode devolver os bytes. Budgets com folga não barram o crescimento lento, então vale também ler um relatório de bundle.

Fontes

Avalie este artigo:
Categoria
CEVIU Web Dev
Publicado
30 de outubro de 2026
Editoria
CEVIU Web Dev

Quer receber mais sobre CEVIU Web Dev?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser