POR QUE SEU SITE É LENTO

Se você abre DevTools, muda três plugins, e faz redeploy sem olhar para dados de campo, você está adivinhando com passos extras. Lentidão é uma experiência do visitante. Prove com números de usuários reais antes de tocar no código.

Comece com dados de campo do Chrome UX Report no PageSpeed Insights ou no Core Web Vitals do Search Console. Você quer o percentil 75 para Largest Contentful Paint, Interaction to Next Paint, e Cumulative Layout Shift em mobile. Scores de laboratório do Lighthouse são úteis para debugar um único carregamento de página. Não é a métrica que o Google usa para ranking nem a métrica que seus compradores sentem em uma conexão Wi-Fi de trem.

O que capturar nos primeiros dez minutos

URL da página lenta. Classe de dispositivo (celular em primeiro lugar). Se o problema é primeira visita ou visita repetida. Se páginas logadas diferem da homepage pública. TTFB se você conseguir vê-lo. O nome do elemento LCP do painel de diagnósticos. Essa lista curta geralmente aponta para a faixa certa antes de qualquer um debater frameworks.

Conclusão chave: dados de campo decidem se o site é lento. Dados de laboratório ajudam você a encontrar a alavanca. Nunca inverta essa ordem.

Se a página é lenta antes de qualquer conteúdo aparecer, é geralmente o servidor: tempo alto até o primeiro byte, uma consulta de banco de dados sem cache, PHP ou Node renderizando em cada requisição, ou um host que é simplesmente fraco. Se o conteúdo aparece e depois trava, congela ou muda, é o front-end: imagens, scripts, fontes, e layout.

Uma divisão útil: TTFB abaixo de cerca de 0,8 segundos significa que a origem está praticamente fora do caminho crítico. Acima de 1,2 segundos em uma página com marketing, corrija hosting, cache, ou custo de server render antes de se obsecionar com codecs de imagem. Para sites grandes o diagnóstico tem seu próprio playbook no checklist de Core Web Vitals e no guia de correção de LCP, INP, CLS neste site.

Conclusão chave: Nomeie a faixa primeiro. Trabalho de servidor e trabalho de front-end precisam de pessoas diferentes e ferramentas diferentes.

Em ordem de frequência com que são o real problema em sites comerciais que vejo:

1. Mídia hero oversized

Um PNG de 2MB ou um upload não recortado do CMS como elemento LCP. Solução: redimensionar corretamente, formato moderno (WebP ou AVIF), atributos width e height, fazer preload da URL LCP real, servir de um CDN. Um bom ajuste de hero geralmente supera dez micro-otimizações.

2. JavaScript desnecessário no primeiro carregamento

Gerenciadores de tags, widgets de chat, ferramentas A/B, hidratação de framework não utilizada e componentes client "só por precaução". Solução: defer ou remover terceiros, enviar menos JS em rotas de marketing, manter ilhas de interatividade pequenas.

3. Hosting e cache misses

Hosts compartilhados, WordPress frio sem page cache, Next.js SSR em toda URL pública, ou padrões ISR que reconstroem o mundo a cada deploy. Solução: hosting gerenciado ou edge cache para WordPress, estático ou ISR com uma política de revalidação sensata para app frameworks.

4. Fontes e CSS que bloqueiam renderização

Cinco pesos de uma fonte display, importados de um arquivo CSS de terceiros, bloqueando texto. Solução: subset, self-host, font-display swap ou optional, CSS crítico para acima da dobra.

5. Terceiros sem limites

Pixels que injetam mais pixels. Correção: carregue após interação ou em tempo ocioso, elimine qualquer coisa que não ganhe seu lugar em um teste de conversão.

6. Layout shift de conteúdo tardio

Anúncios, embeds e imagens sem espaço reservado. Correção: caixas com aspect-ratio, slots reservados, evite injetar UI acima do conteúdo existente.

Conclusão-chave: A maioria das reclamações "o framework é lento" é uma destas seis com uma fantasia de framework.

Não otimize tudo de uma vez. Abra a entrada de LCP em seus diagnósticos de campo ou lab, encontre o elemento que é o LCP (geralmente a imagem hero ou headline), e torne apenas essa uma coisa rápida: dimensionada corretamente, pré-carregada, servida de um CDN. Meça novamente. Depois corte JavaScript que roda no caminho crítico. Meça novamente.

Uma ordem prática para um site de marketing: elemento LCP, depois JS de terceiros, depois carregamento de fontes, depois cache e TTFB, depois limpeza de CLS, depois micro-otimizações. Parar após os dois primeiros frequentemente coloca um site comercial em uma faixa de CWV de aprovação.

Nota WordPress: uma dieta de plugins e um cache de página real em hosting gerenciado vencem uma reescrita de tema mais frequentemente do que agências admitem. Nota Next.js e Astro: não faça SSR do brochure. HTML estático ou em cache para páginas públicas; reserve o trabalho de servidor para superfícies de produto autenticadas. Os detalhes vivem no guia Next.js vs Astro vs WordPress.

Conclusão-chave: Uma vitória de LCP medida bate uma semana de refatorações especulativas.

WordPress

Construtores de página enviando CSS de cada widget em cada página. Templates de WooCommerce sem cache. Consultas pesadas de posts relacionados. Tabelas de opções com autoload que cresceram por anos. Caminho da solução: cachear HTML na borda, reduzir plugins, lazy-load de seções do construtor abaixo da dobra, corrigir o inchaço de autoload do banco de dados.

Next.js

Componentes de cliente envolvendo páginas inteiras. Cascatas de awaits sequenciais. Imagens pelo loader errado. ISR ou SSR em páginas que nunca personalizam. Caminho da solução: Server Components por padrão, estático onde possível, auditar o bundle JS por rota.

Astro e outras pilhas estáticas

Normalmente rápido, a menos que você reintroduza uma ilha SPA do tamanho de um app de produto, ou hotlink de mídia gigante do CMS. Caminho da solução: manter ilhas pequenas, processar imagens no pipeline, não colar hábitos do WordPress em um site estático.

Ponto-chave: Adapte a solução à pilha. Replatforming raramente é o primeiro movimento de performance.

Metas, medidas em visitantes reais no percentil 75 em mobile: Largest Contentful Paint abaixo de 2,5 segundos, Interaction to Next Paint abaixo de 200 milissegundos, Cumulative Layout Shift abaixo de 0,1. Mantenha o time to first byte abaixo de cerca de 0,8 segundos para que o servidor não entre no caminho crítico.

Atingindo essas metas, o site não é lento de forma alguma que um visitante ou Google vá punir, não importa o que uma métrica de vaidade sintética diga. Qualquer coisa mais rápida é polimento. Entregue o produto em vez de perseguir 100s.

Se quer este trabalho em forma de checklist, use o Core Web Vitals checklist. Se precisa de cirurgia por métrica, use o guia de correção de LCP, INP e CLS. Se o caso de negócio é uma reconstrução, comece pelo pilar de performance em vez de um deck de redesign.

Ponto-chave: Passar no field CWV é a linha de chegada para "é lento?", não uma captura de tela perfeita do Lighthouse.

DIY é suficiente quando o elemento LCP é óbvio, há poucos terceiros, e você controla a hospedagem. Traga alguém para ajudar quando os dados de campo continuam vermelhos após dois ciclos honestos de correção, quando a stack é um híbrido que ninguém do time domina, ou quando as páginas de receita não podem esperar mais uma semana de mudanças especulativas.

Um briefing útil para um outsider: as três URLs que importam, os screenshots de campo, os nomes dos elementos LCP, a hospedagem e CDN, e a lista de tags que você não pode remover. Esse pacote transforma um vago "site está lento" em um job de um sprint.

Se a conversa vira um redesign completo, pause. Trabalho de performance e trabalho de redesign se misturam mal, a menos que o redesign tenha um orçamento CWV explícito. Corrija os templates atuais primeiro quando o negócio ainda depende deles.

Takeaway principal: Dois ciclos de correção falhados ou nenhum owner claro é a linha entre DIY e um paid performance pass.