Performance não é detalhe de implementação

Quase todo projeto trata performance web como a última etapa: o site fica pronto, alguém roda o Lighthouse, a nota vem vermelha e começa a caça aos quilobytes. Só que, a essa altura, as decisões que mais pesam já foram tomadas, e desfazê-las custa uma reescrita. O framework, a forma de gerar as páginas, quanto JavaScript vai para o navegador e como imagens e vídeos entram no layout se decidem nas primeiras semanas; é isso que define o seu LCP quando o produto estiver no ar há meses.

Este artigo junta o que a XPR Studio olha antes de escrever a primeira linha de um site ou sistema, e fecha com uma auditoria real, feita no nosso próprio site, com os números de antes e depois.

Performance em números: os Core Web Vitals

"O site está lento" não é uma medida. O Google resume a experiência de carregamento em três métricas, os Core Web Vitals, e avalia cada página com os dados reais de quem a visita (o relatório CrUX, que aparece no PageSpeed Insights e no Search Console):

• LCP (Largest Contentful Paint): quanto o maior elemento visível da primeira tela demora para aparecer. Bom: até 2,5 segundos.
• INP (Interaction to Next Paint): quanto a página demora para responder a um toque ou clique. Substituiu o FID em março de 2024. Bom: até 200 milissegundos.
• CLS (Cumulative Layout Shift): quanto o layout pula enquanto carrega, o botão que foge do dedo. Bom: até 0,1.

A conta é feita no percentil 75: a página passa quando três em cada quatro visitas ficam dentro do limite. Isso muda a conversa, porque quem decide é o celular intermediário no 4G, e não o notebook do time de desenvolvimento ligado na fibra do escritório.

Laboratório e campo

O Lighthouse roda numa máquina controlada e serve para diagnosticar. Os dados de campo dizem o que aconteceu com quem visitou de verdade. Os dois discordam com frequência e, quando discordam, vale o de campo: é ele que entra no ranqueamento, e é ele que a pessoa sentiu.

As decisões da semana 1

Nenhuma das escolhas abaixo parece ser sobre performance na hora em que é feita. Todas são.

Como as páginas são geradas

Site institucional, portfólio e blog quase nunca precisam montar a página no navegador. Gerar o HTML no build (SSG, geração estática) entrega a página pronta a partir de uma CDN, sem esperar servidor nem JavaScript para mostrar o conteúdo. Começar um site de conteúdo como SPA, a página em branco que o JavaScript preenche, empurra o LCP para depois do download, da análise e da execução do bundle inteiro, e nenhuma otimização posterior devolve esse tempo.

Isso não é campanha contra framework de aplicação; um painel com login, que a pessoa usa por uma hora seguida, tem outras prioridades. O ponto é escolher o modelo pelo tipo de página, não pelo hábito do time.

Quanto JavaScript vai para o navegador

JavaScript é o recurso mais caro que um site manda. Além de baixar, o navegador precisa analisar, compilar e executar o código, e é essa execução que trava a página quando alguém tenta tocar num botão. Por isso o INP costuma piorar devagar, uma dependência por vez, sem que ninguém note o dia em que passou do limite.

No site da XPR a regra é dura: nenhuma biblioteca de componentes e nenhum framework de UI rodando no navegador. Cada componente é escrito à mão, em Astro com Tailwind (o mesmo princípio do nosso guia de design system), e o JavaScript de cada seção só baixa quando a seção está para aparecer. O Three.js, que desenha a luneta em raio-X da página inicial, chega quando a pessoa rola até perto dela; o painel de contato baixa no primeiro clique. O HTML sai completo do build e já mostra o estado final, então o JavaScript que chega depois nunca empurra o layout.

Mídia é parte do design, não do deploy

Imagem e vídeo são, de longe, o que mais pesa numa página. O formato e o tamanho de cada arquivo precisam ser decididos junto com o layout, porque quem desenha a seção sabe em que tamanho aquilo vai aparecer. As regras que seguimos:

• Fotos e capturas de tela em WebP (ou AVIF), no tamanho em que aparecem, com versões por largura de tela.
• Logos e ícones em SVG, desde que sejam vetor de verdade.
• Vídeo curto em WebM (VP9), com MP4 de reserva para quem não toca WebM.
• Tudo abaixo da primeira tela carrega sob demanda, com largura e altura reservadas para não gerar CLS.

Fontes

Fonte servida de outro domínio custa uma conexão a mais antes de o texto aparecer. Servimos as fontes do próprio domínio, pré-carregamos só os pesos da primeira tela e usamos um fallback com métricas ajustadas, para o texto não mudar de tamanho quando a fonte da marca chega.

Scripts de terceiros

Analytics, pixel de anúncio, gravação de sessão e chat somam centenas de quilobytes com facilidade, e nenhum deles é necessário para a página aparecer. Aqui a LGPD ajudou: nada disso carrega antes do aceite de cookies, e quem não aceita recebe um site mais leve.

Um caso real: auditamos o nosso próprio site

Seria fácil escrever este artigo só com regras. Em outubro de 2026 rodamos no site da XPR a mesma auditoria de mídia que fazemos em projeto de cliente, e o resultado mostra como o peso se acumula mesmo num projeto cuidado.

O maior desperdício estava num lugar improvável: o logo de um cliente, na faixa de logos da primeira tela, pesava 373 KB. O arquivo era SVG, mas dentro dele havia uma imagem PNG de 2560 × 2560 pixels embutida, para um logo exibido com menos de 200 pixels de largura. Convertido para WebP no tamanho certo, caiu para 33 KB sem diferença visível. Ninguém tinha percebido, porque na tela ele parecia igual aos outros SVGs.

Nos vídeos dos cases, servir WebM (VP9) antes do MP4 (H.264) reduziu o download de cada página de case entre 50% e 63%: o case da Projax passou de 5,5 MB para 2,8 MB, e o da Safety Center, de 4,4 MB para 1,6 MB. A qualidade foi medida quadro a quadro, com SSIM acima de 0,99 em todos os clipes (1 é idêntico). E houve tropeço: a primeira leva saiu com as cores lavadas, porque as gravações estavam em faixa de cor cheia e o WebM saiu marcado de um jeito e codificado de outro. Só apareceu porque comparamos os quadros lado a lado antes de publicar.

O modelo 3D da seção de processo foi de 189 KB para 50 KB com compressão meshopt, mas esse exigiu mudança de código. O arquivo comprimido guarda a geometria em outra escala, e a conta que dimensionava a cena, que lia a altura da geometria, desenharia a luneta sete vezes menor; testamos o cálculo com os dois arquivos antes da troca.

Também saíram 750 KB de bandeiras em SVG, exibidas com 20 × 15 pixels no campo de telefone, e as imagens de compartilhamento passaram de PNG para JPEG, de cerca de 270 KB para algo entre 40 KB e 100 KB cada, porque imagem pesada demais pode não aparecer na prévia de link do WhatsApp.

A lição não é "otimize no fim". É quase o contrário: esses achados saíram baratos porque a arquitetura já era leve. Num site montado sobre um framework pesado, a mesma auditoria economizaria megabytes de mídia e deixaria intocado o que realmente segura a página.

Como manter a performance depois do lançamento

Site rápido no lançamento e lento um ano depois é o caminho normal, não a exceção. Cada dependência nova, cada script de marketing e cada vídeo enviado sem conversão somam um pouco. O que funciona para nós:

• Um orçamento de performance definido no começo, com teto de JavaScript por página e LCP alvo, conferido a cada entrega.
• Regras escritas no próprio repositório. No nosso, a documentação proíbe biblioteca de componentes e exige o WebM ao lado de cada vídeo novo.
• Atualização de dependências a cada três meses, com comparação visual automática de todas as páginas antes do merge.
• Monitoramento com dados de campo, no Search Console ou no Speed Insights da Vercel, para ver a regressão quando ela começa, e não quando o tráfego cai.

Perguntas frequentes sobre performance web

Performance influencia o SEO?

Sim. Os Core Web Vitals fazem parte dos sinais de experiência de página que o Google considera. Eles não substituem conteúdo relevante, mas desempatam páginas parecidas, e uma página lenta perde visitas antes de o ranqueamento importar: muita gente desiste antes de ela carregar.

Nota 100 no Lighthouse quer dizer site rápido?

Não necessariamente. O Lighthouse simula um aparelho e uma conexão numa máquina de laboratório; é ótimo para achar problemas, mas o que conta é o dado de campo, o comportamento do site no celular de quem visita.

Dá para resolver performance depois que o site está no ar?

Dá para melhorar bastante: converter mídia, adiar scripts, cortar dependências. O que não se corrige sem reescrever é a base. Se o site inteiro depende de JavaScript para aparecer, a otimização tem teto.

WebP ou AVIF?

Os dois são bem menores que JPEG e PNG. O AVIF costuma comprimir mais, mas é mais lento de gerar, e o WebP tem suporte praticamente universal. Para imagem de compartilhamento em rede social, use JPEG: nem todas as plataformas leem WebP na prévia de link.

Performance é decisão de produto

Quem escolhe o framework, o modelo de renderização e o tratamento da mídia está escolhendo, sem perceber, a velocidade que o site vai ter. Tratar performance como detalhe de implementação é deixar para o fim justamente a parte que não dá para consertar no fim.

Na XPR Studio, sites, e-commerces e sistemas nascem com essas decisões tomadas na primeira semana. Veja como isso aparece nos nossos cases ou fale com a gente sobre o seu projeto.