Como Tornar o Seu Site Mais Rápido: Uma Lista de Verificação Prática

Para tornar um site mais rápido, meça-o primeiro com o PageSpeed Insights e depois corrija a maior causa que ele apontar — normalmente imagens demasiado grandes, JavaScript em excesso, tipos de letra pesados ou scripts de terceiros. Procure as metas "boas" das Core Web Vitals da Google: conteúdo principal visível em 2,5 segundos, respostas aos toques em 200 milissegundos e quase nenhum salto do layout. A maioria dos sites lá chega com um punhado de alterações, não com uma reescrita.

Meça antes de alterar seja o que for

Adivinhar desperdiça tempo. Duas ferramentas gratuitas cobrem quase tudo:

• PageSpeed Insights (pagespeed.web.dev) — cole um URL ao vivo. Mostra dados de campo de utilizadores reais do Chrome (se o 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 DevTools do Chrome — o mesmo teste de laboratório, executado em qualquer página que consiga abrir, incluindo uma pré-visualização. Teste em modo móvel; é nos telemóveis com redes mais lentas que os problemas se notam.

Os números que importam são as Core Web Vitals da Google. Em setembro de 2026, a documentação da Google no web.dev dá estes limiares "bons", medidos ao percentil 75 dos carregamentos de página:

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

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

Onde vai o tempo: opções e compromissos

Cada causa comum tem uma solução, e cada soluçã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 píxeis mostrada com 800 píxeis de largura obriga cada visitante a descarregar cinco vezes mais do que vê.

• Sirva as imagens com o tamanho em que são apresentadas, com tamanhos srcset responsivos para telemóveis e computadores.
• Use formatos modernos (WebP ou AVIF) e uma compressão sensata.
• Defina width e height em cada imagem para que o navegador reserve espaço. Só isto corrige a maior parte do salto do layout.
• Carregue tarde as imagens abaixo da dobra com loading="lazy".
• Nunca carregue tarde a imagem principal no topo da página. A orientação da Google sobre LCP é clara: carregar tarde a imagem LCP atrasa-a sempre. Use fetchpriority="high" em vez disso.

JavaScript

Muitos sites construídos com IA são aplicações de página única (SPA): o navegador descarrega um pacote de JavaScript e só depois desenha a página. Quanto maior o pacote, mais tempo o ecrã fica em branco. As correções, por ordem de esforço:

1. Remova o que não usa. Peça uma lista das dependências e corte as bibliotecas que foram adicionadas uma vez e esquecidas — uma biblioteca de datas para uma única data, um pacote completo de ícones para cinco ícones.
2. Divida por rota. Carregue o código do painel de administração só quando alguém o abrir, e não na página inicial.
3. Pré-renderize as páginas públicas. Uma página de marketing que chega como HTML real aparece antes de correr qualquer JavaScript. Isto também ajuda os motores de pesquisa; veja SEO para sites criados com IA.

Um INP lento costuma significar uma tarefa longa a bloquear a página — filtrar uma lista enorme a cada tecla, ou voltar a renderizar uma tabela inteira quando muda uma célula. O painel de Desempenho das DevTools do Chrome mostra qual.

Tipos de letra

Cada família e cada peso de letra é outro ficheiro. Duas famílias e três ou quatro pesos chegam normalmente. Pré-carregue o tipo de letra usado acima da dobra, use font-display: swap para que o texto apareça de imediato, e aloje os tipos de letra você mesmo se o serviço externo for lento para os seus visitantes.

Scripts de terceiros

Widgets de chat, analítica, mapas de calor, pixels de anúncios, vídeos incorporados e feeds sociais carregam código de outros servidores. Cada um parece pequeno; em conjunto, costumam ser a parte mais lenta da página. Mantenha os que realmente consulta. Carregue os restantes depois de a página ficar interativa, e substitua embeds pesados (um leitor do YouTube, um mapa) por uma pré-visualização leve que carrega o conteúdo real ao clique.

Resposta do servidor

O tempo até ao primeiro byte (TTFB) — quanto tempo o servidor demora a começar a responder — está por baixo de todas as outras métricas. As páginas estáticas servidas a partir de uma CDN (uma rede de servidores perto dos seus visitantes; veja o que é uma CDN) são rápidas quase em todo o lado. As páginas construídas por um servidor em cada pedido dependem desse servidor e da sua base de dados. A cache para trabalho repetido e índices de base de dados para consultas lentas são as correções habituais.

Prompts que funcionam

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

O PageSpeed Insights reporta um LCP de 4,8 s em telemóvel para a página inicial, e o elemento LCP é a imagem de topo. Redimensiona e converte a imagem de topo para WebP, serve tamanhos responsivos, define width e height, dá-lhe fetchpriority="high" e garante que não é carregada tarde. Carrega tarde todas as imagens abaixo da dobra. Não alteres o design.

Audita as dependências desta app. Lista cada pacote, o que o usa e, aproximadamente, quanto acrescenta ao pacote. Remove os não usados e divide as rotas /admin e /settings em blocos separados que só carregam quando visitados.

A caixa de pesquisa em /products parece lenta. Aplica debounce ao filtro, evita voltar a renderizar a lista inteira a cada tecla e pagina ou virtualiza a lista se tiver mais de 200 itens.

Passo a passo

1. Teste a página ao vivo no PageSpeed Insights em modo móvel. Anote o LCP, o INP e o CLS, e os três principais problemas listados.
2. Corrija primeiro as imagens: tamanhos, formatos, dimensões, carregamento tardio abaixo da dobra, prioridade para a imagem de topo.
3. Corte os scripts de terceiros que não usa e adie os restantes.
4. Reduza os tipos de letra ao que o design precisa.
5. Reduza o JavaScript: remova pacotes não usados, 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 base de dados, alojamento estático para conteúdo que muda pouco.
8. Publique de novo e volte a testar. Os dados de campo do PageSpeed Insights atualizam-se nas semanas seguintes à medida que chegam visitas reais, por isso avalie os primeiros resultados pelos dados de laboratório.

Erros comuns

• Testar apenas num portátil rápido. Os seus visitantes estão em telemóveis de gama média e em dados móveis irregulares. Teste em modo móvel.
• Perseguir um 100 perfeito. A pontuação de laboratório é um guia. Quando as Core Web Vitals estiverem na faixa boa, o conteúdo e a usabilidade importam mais do que os últimos pontos.
• Carregar tarde tudo, incluindo a imagem de topo. Isso piora o LCP.
• Acrescentar um plugin ou uma biblioteca de velocidade por cima. Remover peso quase sempre vence acrescentar código para o gerir.
• Otimizar a pré-visualização em vez do site ao vivo. As pré-visualizações de desenvolvimento usam builds não otimizadas. Meça o URL publicado.
• Corrigir a velocidade uma única vez. Cada novo widget, imagem e funcionalidade acrescenta peso. Volte a testar após alterações grandes.

Lista de verificação de velocidade

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 em telemóvel
• Imagens redimensionadas, comprimidas, em formato moderno, com width e height
• Imagem de topo não carregada tarde; imagens abaixo da dobra carregadas tarde
• Sem bibliotecas JavaScript não usadas; rotas pesadas separadas
• Duas famílias de tipos de letra ou menos, tipo de letra principal pré-carregado
• Apenas os scripts de terceiros que realmente usa, carregados mais tarde
• Páginas públicas pré-renderizadas ou estáticas sempre que possível
• Novo teste no URL ao vivo após publicar

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

Velocidade no Mythex

No Mythex faz estas alterações pedindo no chat, ou no editor de código no Pro. Verifique o URL publicado, não a Pré-visualização, já que a Pré-visualização usa um servidor de desenvolvimento. As front-ends estáticas são implementadas como sites estáticos quando publica (sites estáticos), o que se adequa a páginas de conteúdo. As apps com servidor escalam para zero: adormecem quando estão inativas e acordam no próximo acesso, por isso o primeiro pedido após um período calmo é mais lento, e uma base de dados associada adormece após 5 minutos inativos (limites de alojamento). Se uma página pública só estiver lenta na primeira visita, essa é a causa provável. Manter as páginas de marketing estáticas ajuda. Após as alterações, publique de novo e faça um refresh forçado.

Perguntas