Os dados do meu produto estão seguros?

Sim. Analisamos apenas dados públicos acessíveis via URL. Seus dados não são armazenados permanentemente e nunca são usados para treinar modelos de IA.

Qual a diferença para o Google Lighthouse ou PageSpeed?

Lighthouse foca em performance técnica. EscaneAI analisa estratégia de negócio: copy, pricing, growth, UX de conversão, posicionamento competitivo — áreas que ferramentas técnicas não cobrem.

Como funciona o pagamento?

Você compra pacotes de créditos (cada crédito = 1 análise). Pagamento único via PIX — sem assinatura, sem cobrança recorrente. Seus créditos nunca expiram.

Meus dados são usados para treinar IA ou beneficiar concorrentes?

Nunca. Os dados da sua análise são usados exclusivamente para gerar o seu relatório. Não treinamos modelos com dados de clientes e nada é compartilhado com terceiros.

Qual a nota ideal no PageSpeed Insights?

O ideal é acima de 90 em desktop e acima de 75 em mobile. Porém, o mais importante são as métricas reais de campo (Core Web Vitals) dos seus usuários, não o score sintético do lab test.

Quanto tempo leva para melhorar o PageSpeed?

Ações básicas como otimizar imagens e eliminar CSS não utilizado podem ser feitas em horas. Otimizações avançadas como SSR e reestruturação de JavaScript podem levar semanas. Comece pelas ações de impacto imediato.

Sim. Core Web Vitals são fatores de ranking confirmados pelo Google. Sites com LCP, INP e CLS dentro das metas tendem a rankear melhor que concorrentes mais lentos, tudo mais sendo igual.

Qual a diferença entre PageSpeed lab e field data?

Lab data são testes simulados em condições controladas. Field data são métricas reais de usuários do seu site. O Google usa field data (CrUX) para ranking. Lab data é útil para diagnóstico e debugging.

Imagens WebP são melhores que JPEG?

Sim. WebP oferece 30-50% de redução de tamanho comparado a JPEG com qualidade equivalente. AVIF é ainda melhor (50-70%), mas tem suporte de navegador mais limitado. Use a tag picture com fallbacks.

Como Melhorar o PageSpeed: 15 Ações Práticas

Por que PageSpeed é dinheiro (literalmente)

Velocidade de carregamento não é métrica de vaidade. É métrica de receita. Os dados são claros:

Amazon: cada 100ms de latência adicional custa 1% em vendas
Google: 53% dos visitantes mobile abandonam páginas que levam mais de 3 segundos
Walmart: cada 1 segundo de melhoria em velocidade aumentou conversões em 2%
BBC: perdiam 10% dos usuários para cada segundo adicional de carregamento

Além do impacto direto em conversão, Core Web Vitals são fatores de ranking confirmados pelo Google. Um site lento perde posições para concorrentes mais rápidos, mesmo com conteúdo idêntico.

Entendendo as métricas que importam

Antes de otimizar, você precisa entender o que está medindo. Estas são as métricas críticas em 2026:

Largest Contentful Paint (LCP)

Mede quando o maior elemento visível da página termina de renderizar. É a métrica mais próxima da percepção de "a página carregou" pelo usuário.

Bom: até 2.5 segundos
Precisa melhorar: 2.5 a 4 segundos
Ruim: acima de 4 segundos

O LCP geralmente é uma imagem hero, um bloco de texto grande ou um vídeo. Identificar qual elemento é o LCP da sua página é o primeiro passo para otimizá-lo.

Interaction to Next Paint (INP)

Substituiu o FID em março de 2024. Mede a responsividade geral da página a todas as interações do usuário (cliques, taps, teclas), não apenas a primeira.

Bom: até 200ms
Precisa melhorar: 200 a 500ms
Ruim: acima de 500ms

Cumulative Layout Shift (CLS)

Mede instabilidade visual: quanto os elementos da página se movem durante o carregamento.

Bom: até 0.1
Precisa melhorar: 0.1 a 0.25
Ruim: acima de 0.25

As 15 ações práticas para melhorar seu PageSpeed

Ações de impacto imediato (faça hoje)

1. Otimize imagens para WebP/AVIF

Imagens são responsáveis por 50-80% do peso da maioria das páginas. A conversão para WebP reduz o tamanho em 30-50% sem perda perceptível de qualidade. AVIF é ainda mais eficiente (50-70% menor), mas tem suporte de navegador mais limitado.

Implementação prática:

Use a tag <picture> com fallback: AVIF > WebP > JPEG
Ferramentas: Squoosh (manual), Sharp (Node.js), ou plugins de build automáticos
Alvo: nenhuma imagem acima de 200KB na página inicial

2. Implemente lazy loading

Imagens e iframes abaixo da dobra não precisam carregar imediatamente. Use o atributo loading="lazy" nativo do HTML. Mas nunca aplique lazy loading na imagem LCP (acima da dobra), pois isso piora o LCP.

3. Defina dimensões explícitas em imagens

Toda tag <img> deve ter atributos width e height definidos. Isso permite que o navegador reserve espaço antes da imagem carregar, eliminando layout shifts (CLS).

4. Preconnect a origens externas

Se você carrega fonts do Google Fonts, analytics de terceiros ou CDNs, adicione <link rel="preconnect"> no <head> para estabelecer conexão antecipada:

<link rel="preconnect" href="https://fonts.googleapis.com" crossorigin>

5. Elimine CSS não utilizado

A maioria dos sites carrega 60-80% mais CSS do que realmente usa na página. Ferramentas como PurgeCSS ou a funcionalidade de coverage do Chrome DevTools identificam CSS não utilizado. Remover esse excesso melhora tanto o FCP quanto o LCP.

Ações de impacto médio (faça esta semana)

6. Minimize e comprima JavaScript

JavaScript é o recurso mais caro que seu site carrega, porque além de ser baixado, precisa ser parseado, compilado e executado. Estratégias:

Minificação: Remove espaços, comentários e renomeia variáveis. Terser é o padrão para projetos modernos.
Tree shaking: Bundlers como Webpack e Vite eliminam automaticamente código não utilizado.
Code splitting: Divida seu bundle em chunks menores carregados sob demanda.

7. Adie JavaScript não crítico

Scripts que não são necessários para o render inicial devem usar defer ou async. Scripts de analytics, chatbots e widgets sociais são candidatos clássicos. A diferença:

async: Baixa em paralelo, executa assim que baixar (pode bloquear o parser)
defer: Baixa em paralelo, executa apenas após o HTML ser completamente parseado (geralmente preferível)

8. Use CDN para assets estáticos

Um CDN (Content Delivery Network) serve seus arquivos a partir do servidor mais próximo do usuário. Para audiência brasileira, serviços como Cloudflare, Vercel Edge e AWS CloudFront tem pontos de presença em São Paulo e Rio de Janeiro.

9. Ative compressão Brotli

Brotli comprime 15-25% melhor que Gzip e é suportado por todos os navegadores modernos. A maioria dos CDNs e hosts modernos suportam Brotli nativamente. Verifique se está ativo nos headers de resposta do seu servidor.

10. Otimize o Critical Rendering Path

O CSS crítico (acima da dobra) deve ser inlined no HTML para evitar render-blocking. O CSS restante pode ser carregado de forma assíncrona:

Extraia o CSS crítico com ferramentas como Critical ou Critters
Inline no <head> dentro de uma tag <style>
Carregue o CSS restante com media="print" onload="this.media='all'"

Ações avançadas (faça este mês)

11. Implemente Server-Side Rendering ou Static Generation

SPAs (Single Page Applications) que fazem todo o rendering no cliente sofrem com LCP alto. Frameworks como Next.js, Nuxt e SvelteKit oferecem SSR e SSG que enviam HTML pré-renderizado, melhorando drasticamente o LCP.

12. Otimize fontes web

Fontes customizadas são uma das causas mais comuns de CLS e LCP alto. Otimizações:

Use font-display: swap para mostrar texto imediatamente com fallback
Faça subset das fontes (remova glifos não utilizados)
Self-host fontes em vez de usar Google Fonts (elimina uma requisição DNS)
Preload a fonte principal: <link rel="preload" href="font.woff2" as="font" crossorigin>

13. Implemente cache eficiente

Configure headers de cache adequados para cada tipo de recurso:

Assets estáticos (JS, CSS, imagens): Cache-Control: max-age=31536000, immutable (1 ano, com hash no filename)
HTML: Cache-Control: no-cache (revalida a cada request)
API responses: Cache-Control: max-age=60 (conforme a frequência de atualização)

14. Reduza requisições de terceiros

Cada script de terceiro (analytics, chat, pixel de ads, widgets) adiciona DNS lookups, conexões TCP e downloads que impactam performance. Audite cada terceiro:

Ele é realmente necessário?
Pode ser carregado de forma assíncrona?
Existe uma alternativa mais leve?

15. Monitore performance continuamente

Performance não é um projeto pontual. É um processo contínuo. Configure monitoramento com:

Google Search Console (dados reais de campo)
Chrome UX Report (dados agregados de usuários reais)
Ferramentas de análise como o EscaneAI, que monitora performance junto com SEO, UX e outros fatores

Como diagnosticar problemas de PageSpeed rapidamente

Antes de implementar qualquer otimização, você precisa saber exatamente quais problemas seu site tem. O EscaneAI inclui um agente de Performance Técnica que analisa velocidade, responsividade e estabilidade visual, gerando um diagnóstico com ações priorizadas por impacto.

A diferença de outras ferramentas é que o EscaneAI correlaciona problemas de performance com impacto em SEO e conversão, mostrando não apenas o que otimizar, mas por que cada otimização importa para seus resultados de negócio.

Conclusão: velocidade é vantagem competitiva

Em um mercado onde a maioria dos sites ainda tem LCP acima de 4 segundos em mobile, ter um site rápido é uma vantagem competitiva real. Comece pelas ações de impacto imediato, avance para as intermediárias e implemente as avançadas conforme maturidade técnica.

Analise a performance do seu site gratuitamente e descubra exatamente quais das 15 ações acima vão gerar o maior impacto para o seu caso específico.

Como Melhorar o PageSpeed do Seu Site: 15 Ações Práticas