Como Tornar Seu Site Mais Rápido: Um Checklist Prático

Para tornar um site mais rápido, meça primeiro com o PageSpeed Insights e depois corrija a maior causa que ele indicar — normalmente imagens grandes demais, JavaScript em excesso, fontes pesadas ou scripts de terceiros. Busque as metas "boas" das Core Web Vitals do Google: conteúdo principal visível em até 2,5 segundos, resposta a toques em até 200 milissegundos e quase nenhum salto de layout. A maioria dos sites chega lá com um punhado de mudanças, não com uma reescrita.

Meça antes de mudar qualquer coisa

Chutar desperdiça tempo. Duas ferramentas gratuitas cobrem quase todo mundo:

• PageSpeed Insights (pagespeed.web.dev) — cole uma URL ativa. Ele mostra dados de campo de usuários reais do Chrome (se o seu site tiver tráfego suficiente) e dados de laboratório de um carregamento simulado, além de uma lista de problemas específicos.
• Lighthouse nas Ferramentas do Desenvolvedor do Chrome — o mesmo teste de laboratório, executado em qualquer página que você consiga abrir, incluindo uma prévia. Teste no modo móvel; é em celulares com redes mais lentas que os problemas aparecem.

Os números que importam são as Core Web Vitals do Google. Em setembro de 2026, a documentação do Google no web.dev define estas metas "boas", medidas no 75º percentil dos carregamentos de página:

O INP substituiu a antiga métrica First Input Delay em 2024. Se alguma ferramenta ainda mostrar FID, ela está desatualizada.

Anote os seus números iniciais. Depois de cada correção, teste de novo para saber o que ajudou.

Onde o tempo se perde: opções e compensações

Cada causa comum tem uma correção, e cada correção tem um custo. Comece pelas que estão no topo — são as mais baratas e as mais comuns.

Imagens

As imagens são o problema mais comum e o mais fácil de corrigir. Uma foto de 4.000 pixels exibida com 800 pixels de largura obriga cada visitante a baixar cinco vezes mais do que vê.

• Sirva as imagens no tamanho em que são exibidas, com tamanhos srcset responsivos para celulares e computadores.
• Use formatos modernos (WebP ou AVIF) e uma compressão sensata.
• Defina width e height em todas as imagens para que o navegador reserve o espaço. Só isso já corrige a maior parte do deslocamento de layout.
• Carregue de forma preguiçosa as imagens abaixo da dobra com loading="lazy".
• Nunca carregue de forma preguiçosa a imagem principal do topo da página. A orientação do Google sobre LCP é direta: carregar de forma preguiçosa a imagem LCP sempre atrasa essa imagem. Use fetchpriority="high" nela.

JavaScript

Muitos sites feitos com IA são aplicações de página única (SPAs): o navegador baixa um pacote de JavaScript e só então desenha a página. Quanto maior o pacote, maior a tela em branco. Correções, em ordem de esforço:

1. Remova o que você não usa. Peça uma lista de dependências e corte as bibliotecas que foram adicionadas uma vez e esquecidas — uma biblioteca de datas para uma única data, um pacote inteiro de ícones para cinco ícones.
2. Divida por rota. Carregue o código do painel administrativo somente quando alguém abri-lo, não na página inicial.
3. Pré-renderize as páginas públicas. Uma página de marketing entregue como HTML real aparece antes de qualquer JavaScript rodar. Isso também ajuda os mecanismos de busca; veja SEO para sites feitos com IA.

INP lento geralmente significa uma tarefa longa bloqueando a página — filtrar uma lista enorme a cada tecla digitada, ou renderizar uma tabela inteira quando uma célula muda. O painel Performance das Ferramentas do Desenvolvedor do Chrome mostra qual é.

Fontes

Cada família de fonte e cada peso é mais um arquivo. Duas famílias e três ou quatro pesos costumam bastar. Pré-carregue a fonte usada acima da dobra, use font-display: swap para que o texto apareça imediatamente e hospede as fontes você mesmo se o serviço externo de fontes for lento para os seus visitantes.

Scripts de terceiros

Widgets de chat, analytics, mapas de calor, pixels de anúncios, vídeos incorporados e feeds de redes sociais carregam código de outros servidores. Cada um parece pequeno; juntos, muitas vezes são a parte mais lenta da página. Mantenha os que você realmente acompanha. Carregue os demais depois que a página estiver interativa, e troque embeds pesados (um player do YouTube, um mapa) por uma prévia leve que carrega o conteúdo real ao clicar.

Resposta do servidor

O tempo até o primeiro byte (TTFB) — quanto o servidor demora para começar a responder — fica por baixo de todas as outras métricas. Páginas estáticas servidas por um CDN (uma rede de servidores próximos aos seus visitantes; veja o que é um CDN) são rápidas quase em qualquer lugar. Páginas construídas por um servidor a cada requisição dependem desse servidor e do seu banco de dados. Cache de trabalho repetido e índices de banco de dados para consultas lentas são as correções usuais.

Prompts que funcionam

Seja específico: diga a página, a métrica e a restrição. Cole as conclusões do PageSpeed Insights se você as tiver.

O PageSpeed Insights aponta LCP de 4,8 s no celular para a página inicial, e o elemento LCP é a imagem de destaque. Redimensione e converta a imagem de destaque para WebP, sirva tamanhos responsivos, defina width e height, use fetchpriority="high" e garanta que ela não seja carregada de forma preguiçosa. Carregue de forma preguiçosa todas as imagens abaixo da dobra. Não altere o design.

Audite as dependências deste app. Liste cada pacote, o que o utiliza e aproximadamente quanto ele adiciona ao pacote. Remova os não usados e separe as rotas /admin e /settings em blocos que só carregam quando visitados.

A caixa de busca em /products parece lenta. Aplique debounce no filtro, evite re-renderizar a lista inteira a cada tecla e pagine ou virtualize a lista se ela tiver mais de 200 itens.

Passo a passo

1. Teste a página ativa no PageSpeed Insights no celular. Anote LCP, INP e CLS e os três principais problemas listados.
2. Corrija as imagens primeiro: tamanhos, formatos, dimensões, carregamento preguiçoso abaixo da dobra, prioridade para a imagem de destaque.
3. Corte os scripts de terceiros que você não usa e adie os demais.
4. Reduza as fontes ao que o design precisa.
5. Diminua o JavaScript: remova os pacotes não usados e divida por rota.
6. Pré-renderize as páginas públicas se ainda forem renderizadas no cliente e o LCP continuar lento.
7. Verifique o servidor: cache, índices de banco de dados, hospedagem estática para conteúdo que muda pouco.
8. Publique de novo e teste outra vez. Os dados de campo no PageSpeed Insights são atualizados nas semanas seguintes, conforme as visitas reais chegam, então avalie os primeiros resultados pelos dados de laboratório.

Erros comuns

• Testar apenas em um notebook rápido. Seus visitantes estão em celulares intermediários e dados móveis instáveis. Teste no modo móvel.
• Caçar um 100 perfeito. A pontuação de laboratório é um guia. Quando as Core Web Vitals estiverem na faixa boa, conteúdo e usabilidade importam mais do que os últimos pontos.
• Carregar de forma preguiçosa tudo, inclusive a imagem de destaque. Isso piora o LCP.
• Adicionar um plugin ou biblioteca de velocidade por cima. Remover peso quase sempre vence acrescentar código para gerenciá-lo.
• Otimizar a prévia, não o site no ar. As prévias de desenvolvimento rodam builds não otimizados. Meça a URL publicada.
• Corrigir a velocidade uma única vez. Cada novo widget, imagem e recurso acrescenta peso. Teste de novo após mudanças grandes.

Checklist de velocidade

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 no celular
• Imagens redimensionadas, comprimidas, em formato moderno, com width e height
• Imagem de destaque sem carregamento preguiçoso; imagens abaixo da dobra com carregamento preguiçoso
• Nenhuma biblioteca de JavaScript não usada; rotas pesadas separadas
• Duas famílias de fonte ou menos, fonte principal pré-carregada
• Apenas os scripts de terceiros que você realmente usa, carregados depois
• Páginas públicas pré-renderizadas ou estáticas sempre que possível
• Testado de novo na URL ativa após a publicação

Velocidade e layout para celular andam juntos; veja como tornar um site responsivo para celular. Para uma revisão completa antes do lançamento, como levar um protótipo de IA para produção cobre o restante.

Velocidade no Mythex

No Mythex, você faz essas mudanças pedindo no chat ou, no plano Pro, no editor de código. Confira a URL publicada, não a Prévia, já que a Prévia roda um servidor de desenvolvimento. Front-ends estáticos são implantados como sites estáticos ao publicar (sites estáticos), o que combina com páginas de conteúdo. Apps com servidor escalam a zero: eles dormem quando ociosos e acordam na próxima visita, então a primeira requisição depois de um período parado é mais lenta, e um banco de dados conectado entra em repouso após 5 minutos ociosos (limites de hospedagem). Se uma página pública for lenta só na primeira visita, essa é a causa provável. Manter as páginas de marketing estáticas ajuda. Depois das mudanças, publique de novo e faça um recarregamento forçado.

Perguntas