O site institucional da própria Via Hospedagem rodava em WordPress e tirava nota 60 de desempenho no PageSpeed Insights no celular. No desktop, 83. Nada catastrófico, mas longe do que o Google considera bom — e longe do que qualquer dono de site gostaria de ver depois de clicar em “Analisar”. Este é o checklist de PageSpeed Insights no WordPress que usamos no site da Via.
Depois de um processo de diagnóstico e correção, com ajuda de IA (Claude Code, usado de forma interativa, com cada mudança aprovada por um humano antes de ir ao ar), o resultado final foi:
– Mobile: 60 → 99 de desempenho
– Desktop: 83 → 98 de desempenho
Este artigo não é só a história desse case. É o checklist real que usamos, em ordem, com o problema específico encontrado em cada item — pra você usar como roteiro no seu próprio site, ou encaminhar para quem cuida dele.
Um aviso antes de começar: esses números são de um caso específico, com um site, um tema e um conjunto de plugins específicos. Eles mostram que a otimização é possível e qual caminho seguir — não que qualquer site chega a 99 seguindo a mesma lista. O ponto de partida do seu site define quanto (e quão rápido) dá para melhorar.
O que é o PageSpeed Insights no WordPress e por que essa nota importa
O PageSpeed Insights é uma ferramenta gratuita do Google que analisa uma página e devolve quatro notas de 0 a 100, além de uma lista de problemas técnicos encontrados. Ele roda em cima do Lighthouse, o mesmo motor de auditoria usado internamente pelo Chrome.
Importa por dois motivos práticos. Primeiro, velocidade de carregamento afeta diretamente quantas pessoas ficam no site em vez de sair antes da página carregar — vale tanto para quem chega organicamente quanto por anúncio pago. Segundo, o Google usa sinais de performance (os Core Web Vitals) como parte dos fatores de ranqueamento em buscas — não é o único fator, nem o mais decisivo, mas é um dos que dá para controlar tecnicamente.
Mobile x desktop: por que as notas costumam ser diferentes
O teste mobile simula uma conexão mais lenta e um processador mais fraco, imitando um celular intermediário — por isso a nota mobile costuma ser mais baixa que a desktop, mesmo sendo a mesma página. No nosso case, a diferença ficou clara no início: 60 no mobile contra 83 no desktop. Depois da otimização, os dois ficaram próximos (99 e 98) — sinal de que os gargalos removidos afetavam ambos os cenários, não só o mais exigente. Como a maior parte do tráfego de um site institucional hoje vem de celular, faz sentido priorizar a nota mobile ao decidir onde investir esforço primeiro.
As 4 métricas do relatório (Desempenho, Acessibilidade, Práticas recomendadas, SEO)
O relatório traz quatro notas separadas, e é comum confundir “desempenho” com “PageSpeed” como se fossem sinônimos — não são:
– Desempenho: velocidade real de carregamento e renderização. A métrica que mais varia de site para site e a que este artigo foca.
– Acessibilidade: contraste de cores, texto alternativo em imagem, uso correto de elementos HTML — o quanto o site é usável por pessoas com alguma limitação.
– Práticas recomendadas: itens técnicos gerais, como uso de HTTPS, bibliotecas sem vulnerabilidades conhecidas, ausência de erros no console do navegador.
– SEO: fatores técnicos básicos de indexação — meta tags, texto legível, links rastreáveis pelo Google.
No nosso case, desempenho foi de fato a métrica que mais precisou de trabalho (60 → 99 no mobile). As outras três já estavam em patamar bom ou muito bom antes mesmo de começar (Acessibilidade 95, Práticas recomendadas 96, SEO 100 no mobile; 95, 100 e 100 no desktop) e continuaram estáveis depois — o esforço concentrado em desempenho não derrubou as demais.
O case: como diagnosticamos os problemas (com ajuda de IA)
Antes do checklist, vale explicar o processo, porque ele muda o que você deve esperar de “otimizar com IA”.
Não existiu um plugin que escaneou o site e resolveu tudo sozinho. Foi uma investigação de causa raiz, conduzida com o Claude Code (ferramenta de linha de comando com IA da Anthropic) de forma interativa: a cada etapa, a IA analisava um sintoma (métrica ruim, requisição de rede, entrada estranha no `dataLayer`), propunha uma hipótese e uma correção, e um humano aprovava, testava antes e depois, e só então seguia adiante.
Na prática, o fluxo repetido foi: rodar o PageSpeed Insights ou inspecionar a aba de rede → identificar o que estava pesando → investigar a causa (um plugin específico? um script duplicado? uma regra de CSS faltando?) → propor a correção → testar → aprovar → medir de novo. Cada um dos 9 itens abaixo passou por esse ciclo. O valor não estava em “a IA otimizou o site” como frase genérica, mas em cada causa raiz identificada e cada correção testada antes de ser considerada resolvida.
O checklist: 9 pontos para melhorar o PageSpeed Insights do seu WordPress
A ordem abaixo segue a lógica de maior impacto e menor risco primeiro, indo para itens mais técnicos depois.
1. Comece pelas imagens: é o maior ganho, o menor risco
Imagem pesada é, na prática, a causa mais comum de site lento — e a mais fácil de corrigir sem risco de quebrar outra coisa no site. No nosso case, duas ilustrações usadas no site passaram por compressão:
– Uma ilustração (representando “solução completa”) foi de 250 KB para 14 KB na primeira rodada. Mais adiante, foi trocada por uma ilustração nova — um PNG de 1,7 MB, comprimido para 100 KB em formato WebP antes de entrar no ar.
– Uma segunda ilustração (relacionada a domínios) foi de 34 KB para 6 KB na primeira rodada. Depois, trocada por uma versão com fundo transparente — um PNG de 1,6 MB, comprimido para 59 KB em WebP.
O padrão se repete: qualquer imagem nova costuma sair de um editor de design ou banco de imagens muito maior do que o necessário para a web. Formatos modernos como WebP entregam qualidade visual equivalente a um PNG ou JPEG com uma fração do tamanho do arquivo.
Na prática: antes de subir qualquer imagem nova no WordPress, comprima e, se possível, converta para WebP — manualmente ou com um plugin de otimização de imagem.
2. Audite plugins que carregam script/CSS em todas as páginas sem necessidade
Um dos achados mais reveladores do case. O plugin Contact Form 7 estava instalado e ativo, e carregava seus arquivos de CSS e JavaScript (`swv/js/index.js`, `includes/js/index.js`, `includes/css/styles.css`) em toda página do site — incluindo dependências do próprio núcleo do WordPress, como `wp-polyfill`, `hooks.min.js` e `i18n.min.js`.
O problema: inspecionando a aba de rede em tempo real na home, em um post de blog e em uma landing page, não havia nenhum formulário do plugin visível em lugar nenhum do site. O plugin estava ativo, carregando arquivos, sem cumprir função alguma. Depois de confirmado que nenhuma página dependia dele, foi removido por completo do WordPress.
Esse tipo de problema é comum: plugins instalados em algum momento (para testar, para uma campanha antiga, por sugestão de terceiros) continuam ativos e carregando recursos mesmo sem uso real.
Na prática: liste os plugins ativos do seu WordPress e confirme, para cada um, se ele está de fato em uso em alguma página. Ferramentas de análise de performance costumam apontar quais arquivos JS/CSS pesam mais — cruze essa lista com os plugins instalados antes de decidir manter ou remover.
3. Confira se o Google Analytics não está disparando em dobro
Um problema silencioso: não deixa o site visivelmente lento, mas desperdiça uma requisição extra e — mais grave — pode inflar dados de analytics sem ninguém perceber.
No nosso caso, o Google Analytics (via `gtag.js`, ID `G-25C5LVNL38`) estava carregando e se configurando **duas vezes** na mesma página. A confirmação veio inspecionando o `window.dataLayer` no console: apareciam duas chamadas `config` para o mesmo ID. A causa raiz era um snippet manual do `gtag.js` colocado direto no `footer.php` do tema — redundante com a tag do GA4 já configurada dentro do próprio Google Tag Manager (GTM-5RLDPXGV), que já carregava em todas as páginas do site. A correção foi remover o snippet manual duplicado e manter só a configuração via GTM.
Na prática: abra o console do navegador (F12), digite `window.dataLayer` e veja se há mais de uma chamada `config` para o mesmo ID de Analytics. Se você usa Google Tag Manager e também tem um snippet de `gtag.js` colado manualmente no tema, um dos dois provavelmente está sobrando.
4. Carregue CSS e fontes sem travar a primeira renderização
Por padrão, uma tag `<link rel=”stylesheet”>` bloqueia a renderização da página até o arquivo terminar de baixar — o navegador não desenha nada na tela enquanto espera. Isso vale tanto para o CSS principal do tema quanto para fontes do Google Fonts.
A correção aplicada foi trocar para o padrão de “preload + troca para stylesheet depois” (técnica conhecida como `loadCSS`): o navegador baixa o arquivo em paralelo, sem bloquear a renderização, e só o aplica como folha de estilo assim que termina. Exemplo genérico da estrutura no HTML:
“`html
<link rel=”preload” href=”/estilo.css” as=”style” onload=”this.onload=null;this.rel=’stylesheet'”>
<noscript><link rel=”stylesheet” href=”/estilo.css”></noscript>
“`
O `<noscript>` garante que o CSS carrega normalmente para quem tem JavaScript desativado.
Na prática: se o seu tema carrega CSS e fontes com `<link rel=”stylesheet”>` simples no `<head>`, essa é uma otimização de impacto real e risco baixo — mas exige teste visual cuidadoso depois, porque muda a ordem em que os estilos chegam.
5. Coloque o CSS crítico da primeira dobra direto no HTML
Mesmo com a técnica acima, ainda existe uma pequena janela até o CSS completo chegar. Para a página não aparecer “em branco” nesse intervalo, um bloco pequeno de CSS — no nosso caso, cerca de **4,5 KB**, contendo só o necessário para desenhar a barra de navegação e a primeira seção (hero) da home — foi colocado direto inline no `<head>` do HTML, em vez de depender do arquivo CSS completo (26 KB).
Assim o navegador já recebe, junto com o próprio HTML, o estilo mínimo para desenhar o que a pessoa vê primeiro, enquanto o resto do CSS continua chegando pela técnica de preload do item anterior.
Na prática: o item mais técnico do checklist — normalmente exige identificar manualmente (ou com ferramenta específica) quais regras de CSS afetam só o que aparece “acima da dobra”. Vale encaminhar este item para um desenvolvedor.
6. Remova JavaScript que seu site não usa
WordPress carrega, por padrão, uma série de scripts em toda página — mesmo quando o recurso correspondente não é usado. Exemplo direto do case: o `wp-emoji-release.min.js`, cerca de **23 KB** de JavaScript que o WordPress core carrega automaticamente para dar suporte a emojis em navegadores antigos. Foi desativado usando os hooks padrão do próprio WordPress (sem plugin adicional), já que navegadores atuais renderizam emoji nativamente.
Na prática: revise, com a aba de rede aberta, quais arquivos JS carregam em toda página do seu site e pergunte, para cada um: esse recurso é usado aqui? Scripts de suporte a navegador antigo, de recursos desativados, ou de plugins como o do item 2, são os primeiros candidatos.
7. Configure cache do navegador para arquivos estáticos
Sem cabeçalhos de cache configurados, o navegador do visitante baixa de novo os mesmos arquivos de CSS, JavaScript e imagem toda vez que ele volta ao site — mesmo sem nada ter mudado. No nosso caso, nenhum arquivo estático tinha `Cache-Control` ou `Expires` configurado. A correção foi adicionar regras de `mod_expires` e `mod_headers` no `.htaccess`, definindo por quanto tempo cada tipo de arquivo pode ficar guardado no navegador.
Na prática: é um ajuste de servidor, normalmente feito uma vez só. Se você não tem acesso técnico para editar o `.htaccess` do seu site, encaminhe a um desenvolvedor ou converse com o suporte da sua hospedagem.
8. Corrija robots.txt e sitemap.xml desatualizados
Não muda a nota de Desempenho diretamente, mas afeta como o Google rastreia e indexa o site — e apareceu como problema real no case. O `robots.txt` não bloqueava o acesso a `/wp-admin/` e apontava o `Sitemap` para um arquivo estático de dezembro de 2023, sobra de uma versão anterior do site, listando só duas URLs — a home e uma página que nem existia mais (`/contato.html`).
Pior: o sitemap de verdade, gerado pelo plugin de SEO em uso atualmente, nem incluía as páginas de produto/landing pages — só a home aparecia nele. A correção foi apontar o `robots.txt` para o sitemap correto e adicionar o bloqueio de `/wp-admin/`.
Na prática: acesse `seusite.com/robots.txt` e confira duas coisas: se `/wp-admin/` está bloqueado, e se a linha `Sitemap:` aponta para um arquivo que realmente existe e lista as páginas atuais do site.
9. Depois de qualquer mudança visual, teste em várias telas
A nota de cautela que vale mais que qualquer dica isolada: depois de trocar duas imagens do site por versões novas — com proporção diferente das originais, que não eram mais quadradas — elas apareceram esticadas verticalmente na versão publicada.
A causa raiz: a regra de CSS definia `width` mas nunca `height`. Sem essa segunda propriedade, o atributo `height` declarado no HTML da imagem passa a valer como um número fixo de pixels, em vez de escalar proporcionalmente junto com a largura. A correção foi simples (adicionar `height: auto` nas duas regras de CSS afetadas), mas o bug só apareceu depois de publicado — nada nos números do PageSpeed Insights indica esse tipo de problema visual.
Na prática: toda vez que uma otimização envolver trocar ou redimensionar imagens, confira o site em telas diferentes (celular e desktop) depois do deploy — não só a nota do relatório. Regra prática: sempre que definir `width` para uma imagem via CSS, defina também `height: auto` junto.
O papel da IA nesse processo (e o que isso significa pra quem não é dev)
O que a IA fez bem: o trabalho repetitivo — ler saídas de rede, cruzar sintomas com causas prováveis, propor o trecho de código de cada correção —, principalmente nos problemas menos óbvios à primeira vista, como o Analytics duplicado e o plugin sem função do item 2.
O que continuou sendo trabalho humano: decidir, aprovar e confirmar visualmente cada item. A prova mais concreta é o bug do item 9 (imagem esticada), que só apareceu olhando a página de verdade, depois do deploy, em telas diferentes — nenhum relatório automatizado teria pego isso sozinho.
Isso é o oposto de “IA resolve sozinha”: investigação mais rápida, com decisão, teste e aprovação sempre nas mãos de uma pessoa.
O resultado final
O salto principal foi em Desempenho — a métrica mais sensível a peso de imagem, JavaScript não utilizado e bloqueios de renderização, exatamente os pontos trabalhados no checklist acima. As outras três métricas já estavam em patamar bom desde o início e se mantiveram estáveis, o que reforça que otimização de performance, quando bem feita, não compromete acessibilidade nem SEO técnico.
Vale repetir: este é o resultado de um site específico, com um ponto de partida específico. Se o seu site hoje está em uma faixa de nota diferente, com um conjunto diferente de plugins e imagens, o resultado do seu processo também será diferente — mas o caminho de diagnóstico (imagem por imagem, plugin por plugin, script por script) é o mesmo.
Você precisa fazer tudo isso sozinho?
Não necessariamente. Os itens 1, 6 e 9 deste checklist (imagens, remover script não usado, testar visualmente depois de mudanças) dá para fazer sem conhecimento técnico avançado, com cuidado e um pouco de tempo. Já os itens mais técnicos — CSS crítico inline, preload de CSS/fontes, cabeçalhos de cache no `.htaccess`, auditoria de plugins com inspeção de rede — costumam exigir alguém com experiência em desenvolvimento, ou pelo menos disposição para testar cada mudança com calma antes de publicar.
Vale separar dois problemas diferentes, porque a solução não é a mesma. Se o que você quer é alguém cuidando da manutenção, atualização e segurança do seu WordPress no dia a dia, é esse o papel do WP Care, dentro da [hospedagem WordPress](/hospedagem-wordpress/) da Via — mas isso não é otimização de performance nem aplicação do checklist de PageSpeed deste artigo.
Se o problema de fundo é que seu site já chega lento independente de otimização de código — plano de hospedagem no limite, recursos disputados com outros sites —, vale considerar uma [migração de site](/migracao-de-site/), gratuita em todos os planos de hospedagem da Via.
E se o que você quer é justamente ajuda com os itens deste checklist — você rodou o PageSpeed Insights, ficou com uma nota baixa e não sabe por onde começar a aplicar essas correções —, [fale com o nosso suporte](/#contato) — a gente conversa com pessoas, não com robôs, e pode ajudar a entender o que está pesando no seu caso.
Perguntas frequentes
Preciso chegar a 99 no PageSpeed Insights para meu site ser considerado rápido?
Não existe uma nota mínima obrigatória. O importante é a tendência: sair de uma nota muito baixa para uma faixa boa já traz ganho real de experiência e de sinais de SEO técnico. O valor exato depende do ponto de partida do seu site.
Otimizar imagens sozinho já resolve a maior parte do problema?
Na maioria dos sites, imagem pesada é o maior peso individual — por isso é o primeiro item do checklist. Mas, como mostra este case, plugins não utilizados, scripts duplicados e falta de cache também pesam, e um site pode ter nota baixa mesmo com imagens já otimizadas.
Preciso saber programar para melhorar meu PageSpeed Insights?
Alguns itens (comprimir imagem, revisar plugins ativos) não exigem programação. Outros (CSS crítico inline, ajustes de cache no `.htaccess`, preload de recursos) envolvem mexer em código do tema ou do servidor — para esses, vale ter apoio técnico.
A nota do PageSpeed Insights garante que meu site vai subir no Google?
Não isoladamente. Performance é um dos sinais técnicos usados no ranqueamento, não o único e nem o mais decisivo. Conteúdo relevante e outros fatores de SEO continuam pesando junto.
Minha hospedagem afeta minha nota no PageSpeed Insights?
Pode afetar, principalmente em métricas de tempo de resposta do servidor. Mas, como mostra este case, boa parte dos ganhos de nota vem de ajustes no próprio site (imagens, plugins, scripts, CSS) — que valem a pena revisar antes ou em conjunto com qualquer mudança de hospedagem.
CTA final
Rodou o PageSpeed Insights e não sabe por onde começar a corrigir? [Fale com o suporte da Via Hospedagem](/#contato) — a gente conversa com pessoas, não com robôs.