Por Que Meu Site Está Tão Lento? As Causas Reais e Como Resolvê-las

Resumo: os suspeitos de sempre, em ordem

A maioria dos sites lentos é lenta pelos mesmos poucos motivos, e você provavelmente encontra o seu na lista abaixo. Os maiores ganhos quase sempre vêm de imagens grandes demais e scripts de terceiros que você esqueceu que tinha adicionado. Comece por aí e depois vá descendo. Um teste de velocidade único feito na sua própria máquina vai te enganar, então o último e mais importante passo é medir a velocidade que os seus visitantes de verdade experimentam nos próprios celulares e redes.

• Imagens e mídias pesadas. Fotos sem compressão e arquivos grandes demais são a causa número um de carregamentos lentos. Comprima, redimensione e use formatos modernos.
• Scripts de terceiros em excesso. Widgets de chat, pixels de anúncio, ferramentas de testes A/B e analytics pesados cobram um pedágio cada um. A soma cresce rápido.
• CSS e JavaScript que bloqueiam a renderização. O navegador trava em recursos que precisa carregar antes de conseguir desenhar qualquer coisa. Adie o que não é essencial logo de cara.
• Hospedagem lenta, sem cache ou CDN. Hospedagem compartilhada barata e falta de cache fazem cada visitante esperar por um servidor de origem lento.
• Core Web Vitals reprovados. Até um site 'rápido' pode parecer travado se o conteúdo pula de lugar ou os botões não respondem. São as métricas que o Google e os seus usuários percebem.
• Medir a coisa errada. Uma nota de laboratório numa máquina rápida não é a velocidade que os seus visitantes reais recebem. Acompanhe usuários reais para encontrar o caminho lento que está realmente te custando.

Imagens e mídias pesadas

Se o seu site está lento, as imagens são o primeiro lugar para olhar. Uma única foto de destaque exportada direto do celular ou de uma ferramenta de design pode ter três ou quatro megabytes. Empilhe algumas dessas numa página e você construiu um site que se arrasta no celular, por mais limpo que seja o seu código.

A solução tem três partes. Primeiro, redimensione as imagens para o tamanho em que elas realmente aparecem. Uma foto exibida com 600 pixels de largura não precisa ter 4000 pixels. Segundo, comprima. Ferramentas e pipelines de build conseguem reduzir a maioria das imagens pela metade ou mais, sem perda visível de qualidade. Terceiro, use formatos modernos como WebP ou AVIF, que são muito menores que os antigos JPEGs e PNGs para a mesma qualidade.

Mais dois ganhos baratos: faça lazy load das imagens que ficam abaixo da dobra, para que o navegador só as busque quando o visitante rolar para perto delas, e sempre defina largura e altura explícitas nas imagens, para que a página não pule de lugar enquanto elas carregam. Esse último ponto importa mais do que parece, e vamos voltar a ele quando falarmos sobre Core Web Vitals.

Com vídeo é a mesma história, só que pior. Se você precisar usar, hospede em uma plataforma feita para streaming e carregue o player só quando alguém interagir com ele.

Scripts de terceiros em excesso (o pedágio invisível)

Essa é a causa que se esconde à vista de todos. Ao longo de um ano, um site acumula silenciosamente um widget de chat, uma ferramenta de mapa de calor, um trecho de teste A/B, dois pixels de anúncio, um banner de cookies, um carregador de fontes e uma ou três tags de analytics. Cada uma parecia inofensiva na hora em que você adicionou. Juntas, costumam ser a coisa mais pesada da página, e a mais lenta, porque buscam servidores que você não controla.

Scripts de terceiros são um pedágio por dois motivos. Eles adicionam bytes para baixar e processar, e adicionam idas e voltas de rede para outros domínios que podem ser lentos por conta própria. Uma única tag de marketing arrastada pode impedir que o resto da sua página fique interativo, e você normalmente não consegue deixar esses servidores externos mais rápidos, então a sua única alavanca é remover ou adiar o script.

Faça uma auditoria do que você tem. Abra o painel de rede do seu navegador, carregue a página e ordene por domínio. Você quase certamente vai encontrar requisições para serviços que esqueceu ou parou de usar meses atrás. Apague tudo de que não precisa ativamente. Para o resto, carregue de forma assíncrona ou depois que a página estiver interativa, e considere uma alternativa mais leve. Os maiores vilões raramente são os que você imaginaria.

Um bom hábito: trate cada novo script como um custo, não como um complemento gratuito. Antes de colar um trecho de código no seu site, pergunte se ele compensa o próprio peso. Se você está montando um projeto novo, uma passada rápida por um checklist de lançamento de site ajuda a evitar instalar cinco ferramentas que mais tarde você vai ter que arrancar.

CSS e JavaScript que bloqueiam a renderização

Mesmo com imagens enxutas e poucos scripts, uma página pode parecer lenta por causa da ordem em que o navegador faz as coisas. Quando o navegador encontra uma folha de estilo ou um script no head da sua página, muitas vezes ele precisa parar, baixar aquele arquivo e processá-lo antes de conseguir desenhar qualquer coisa na tela. Essa parada é o que os visitantes percebem como uma página branca em branco.

O objetivo é deixar o navegador mostrar algo útil o quanto antes. Embuta o pequeno trecho de CSS necessário para renderizar o que aparece primeiro (o conteúdo 'acima da dobra') e carregue o resto depois. Para o JavaScript, use os atributos defer ou async para que os scripts não bloqueiem a renderização inicial, e divida os bundles grandes para que o navegador só baixe o código que aquela página realmente precisa.

Frameworks e construtores de site modernos cuidam de boa parte disso para você, mas não de tudo. As fontes são um vilão comum: uma fonte web personalizada que bloqueia a exibição do texto deixa os visitantes olhando para o nada, ou causa um piscar quando o texto troca. Diga ao navegador para mostrar um texto alternativo imediatamente enquanto a fonte carrega. Mudança pequena, diferença real.

Hospedagem, cache e uma CDN

Às vezes a página em si está bem e o servidor por trás dela é o problema. Em hospedagem compartilhada de baixo custo, o seu site fica numa máquina com centenas de outros, e quando um deles fica sobrecarregado, todo mundo fica mais lento. O primeiro byte da sua página pode levar um segundo ou mais para chegar antes de qualquer outra coisa sequer começar. Se o seu tempo até o primeiro byte é consistentemente lento, nenhuma compressão de imagem vai te salvar.

O cache é a solução de maior alavancagem aqui. Um cache guarda uma cópia pronta das suas páginas para que o servidor não precise reconstruí-las do zero a cada requisição. Para um site de conteúdo ou blog, o cache de página inteira pode transformar uma origem arrastada em algo que responde quase instantaneamente. A maioria das plataformas e dos sistemas de gerenciamento de conteúdo já tem cache embutido ou a um plugin de distância.

Uma rede de distribuição de conteúdo (CDN) é a outra grande alavanca. Uma CDN mantém cópias dos seus arquivos estáticos (imagens, CSS, JavaScript) em servidores ao redor do mundo, então um visitante em Sydney carrega a partir de uma cidade próxima em vez de esperar os bytes cruzarem um oceano vindos da sua origem em Frankfurt. Para um público global, só isso já pode reduzir o tempo de carregamento de forma perceptível, e se a sua hospedagem não inclui uma, há muitas CDNs gratuitas para começar.

E antes que qualquer uma dessas coisas importe, o servidor precisa estar no ar. Um site fora do ar é infinitamente lento, e quedas têm o costume de acontecer nos piores momentos, sem ninguém perceber por horas. Se você nunca parou para pensar no que a sua hospedagem realmente garante, as nossas anotações sobre tempo de atividade de sites explicam por que uma sequência de pequenas quedas soma, em silêncio, muito mais tempo perdido do que a maioria dos donos imagina. Saber o exato momento em que a sua origem fica no escuro, ou começa a responder devagar, é o alicerce de tudo o mais aqui.

Core Web Vitals em português claro

O Google mede a velocidade do site por meio de um conjunto de métricas chamado Core Web Vitals, e elas aparecem na busca e no relatório de experiência do Chrome. Vale a pena entendê-las porque elas refletem de perto o que um visitante real de fato sente, e não apenas o tempo bruto de download. São três, e os limites são públicos no web.dev.

O Largest Contentful Paint (LCP) mede quanto tempo leva até o maior elemento visível (geralmente a sua imagem de destaque ou o título) terminar de carregar. Mire em menos de 2,5 segundos. O Interaction to Next Paint (INP) mede com que rapidez a página responde quando alguém toca ou clica, com a meta de menos de 200 milissegundos. O Cumulative Layout Shift (CLS) mede o quanto a página pula de lugar enquanto carrega, e você quer manter abaixo de 0,1. Você pode ler as definições completas na página oficial dos Core Web Vitals.

Em termos simples: o LCP é 'em quanto tempo a página apareceu', o INP é 'com que rapidez ela reage quando eu toco' e o CLS é 'o layout ficou parado ou o botão se mexeu bem na hora em que eu fui tocar'. Esse do CLS se liga diretamente a imagens sem dimensões e anúncios que carregam tarde, e é por isso que definir largura e altura nas imagens importa tanto. Se algum termo aqui for novo para você, o glossário define os mais comuns em um só lugar.

Dois dos três têm a ver com responsividade e estabilidade, não só com velocidade de download. Essa é a parte que uma única execução do Lighthouse no seu notebook tende a esconder, o que nos leva à seção mais importante.

Dados de laboratório mentem: monitore seus usuários reais

Aqui está a pegadinha que enfraquece a maior parte do trabalho de velocidade. Quando você roda uma ferramenta como o Lighthouse e recebe uma nota reluzente, isso é um teste de laboratório: uma página, uma máquina rápida, uma conexão estável, executado uma vez. Os seus visitantes reais não têm nada a ver com isso. Eles estão em celulares intermediários, no wifi de um hotel, num trem, com uma dúzia de abas abertas em segundo plano. A velocidade que recebem pode ser totalmente diferente da que o seu notebook informa, e um script que carrega bem para você pode ser justamente o que está arrastando todo mundo para baixo.

É por isso que uma única nota, por mais verde que seja, não basta. A única forma de saber a velocidade que as pessoas de fato experimentam é medir do lado delas, nos dispositivos e redes delas, de forma contínua. Quando você consegue acompanhar a velocidade que os visitantes reais recebem, você para de otimizar para um número que mais ninguém vê e começa a corrigir o caminho lento que está te custando visitantes: a página que é rápida na sua máquina mas trava num celular, o script que vai bem na fibra mas bloqueia tudo nos dados móveis.

O ponto mais simples para começar é a pergunta mais básica de todas: o site está sequer respondendo agora, e com que rapidez? Você não consegue resolver uma lentidão da qual nunca fica sabendo, e quedas e respostas lentas têm o costume de passar despercebidas por horas. Um pouco de monitoramento de tempo de atividade que verifica a sua origem em uma agenda regular vai te avisar quando os tempos de primeiro byte sobem ou o servidor fica quieto, que é o alicerce de cada outra correção deste post.

Quando você passa a acompanhar usuários reais, o trabalho muda. Em vez de caçar uma nota de laboratório perfeita, você fica de olho nas páginas e dispositivos em que a velocidade despenca, corrige esses casos e confirma que a correção funcionou para pessoas reais. Para um quadro mais amplo do que acompanhar e por quê, o nosso guia de boas práticas de web analytics mostra como ligar dados de velocidade e comportamento a resultados que importam.