Site médico lento: como medir a velocidade e o que corrigir primeiro

Um site é considerado rápido pelo Google quando passa em três medidas chamadas Core Web Vitals: o conteúdo principal aparece em até 2,5 segundos (LCP), a página responde a um toque em até 200 milissegundos (INP) e o layout quase não se mexe enquanto carrega, com índice de até 0,1 (CLS). Para saber como está o seu, cole o endereço em pagespeed.web.dev. Em site de consultório, causas frequentes são imagens pesadas no topo da página e excesso de scripts e plugins.

As três métricas que o Google usa

• LCP (Largest Contentful Paint): mede o carregamento. É o tempo até aparecer o maior elemento visível da tela, que costuma ser a foto do topo ou o bloco de texto principal.
• INP (Interaction to Next Paint): mede a resposta. É o tempo entre o paciente tocar em um botão, como o de agendar, e a tela reagir.
• CLS (Cumulative Layout Shift): mede a estabilidade visual. É um índice, sem unidade de tempo, que cresce quando os elementos pulam de lugar durante o carregamento. É o que faz a pessoa tocar no botão errado.

Os limites abaixo são os publicados pelo Google no web.dev e na documentação do PageSpeed Insights.

O Google avalia o 75º percentil das visitas, separando celular e computador. Em linguagem simples, três em cada quatro acessos precisam ficar dentro do limite. Um site que abre rápido no wi-fi do consultório e demora no 4G do paciente pode ser reprovado.

Como medir no PageSpeed Insights

1. 1Abra pagespeed.web.dev e cole o endereço da página inicial.
2. 2Clique em Analisar e espere o relatório.
3. 3Fique na aba de dispositivos móveis, que simula um celular em rede mais lenta.
4. 4No topo, leia o bloco de dados de usuários reais e veja se a avaliação das Core Web Vitals foi aprovada.
5. 5Desça até o diagnóstico e anote os itens listados. A ferramenta aponta qual elemento é o LCP da página.
6. 6Repita com a página de agendamento e com uma página de especialidade.

O relatório tem duas partes, e misturá-las gera confusão. Os dados de campo vêm de usuários reais do Chrome e cobrem os 28 dias anteriores. São eles que definem se o site foi aprovado. Os dados de laboratório são uma simulação feita na hora, em ambiente controlado, e servem para investigar a causa do problema.

A nota de 0 a 100 no círculo colorido pertence ao laboratório. O Google considera 90 ou mais como bom, de 50 a 89 como precisa melhorar e abaixo de 50 como ruim. Ela oscila de um teste para outro, então rode duas ou três vezes antes de concluir alguma coisa.

Sites com pouco tráfego, caso de muitos consultórios, podem não ter dados de campo suficientes. Nessa situação a ferramenta tenta usar os dados do site inteiro em vez da página, e se nem isso houver ela mostra só o laboratório. Isso não indica erro no site. Use o laboratório como guia e reteste depois.

Causas comuns em sites de consultório

• Foto do topo enviada no tamanho original da câmera, com vários megabytes.
• Carrossel de imagens ou vídeo de fundo na primeira tela.
• Muitos plugins e scripts de terceiros carregando juntos: chat, pixel de anúncio, mapa incorporado, widget de avaliações, agenda externa.
• Imagens e incorporações sem largura e altura definidas, que empurram o texto quando terminam de carregar.
• Banner de cookies ou aviso que aparece depois e desloca a página.
• Fontes personalizadas que trocam o texto de tamanho ao entrar.
• Hospedagem que demora a enviar o primeiro byte da página.

Correções por métrica

LCP alto

Comece pela imagem que o relatório aponta como elemento LCP. Redimensione para o tamanho em que ela aparece na tela e exporte em formato moderno, como WebP ou AVIF. O web.dev é taxativo em um ponto: nunca aplique carregamento lento (lazy-load) na imagem do LCP, porque isso atrasa o início do download. Muitos temas e plugins de otimização fazem isso por padrão em todas as imagens, e é preciso excluir a do topo.

Peça ao desenvolvedor para marcar essa imagem com prioridade alta de busca (fetchpriority) e para adiar scripts que não são necessários na abertura. Se o tempo até o primeiro byte estiver alto, as recomendações do web.dev são cache de página, menos redirecionamentos e uma rede de distribuição de conteúdo (CDN).

INP alto

INP ruim costuma vir de JavaScript demais ocupando o navegador. Segundo o web.dev, scripts grandes geram tarefas longas que impedem a página de reagir ao toque, e páginas com estrutura muito grande dão mais trabalho de renderização. A correção prática é uma faxina: liste cada script e plugin, pergunte para que serve e remova o que ninguém usa.

CLS alto

A regra do web.dev é sempre informar largura e altura em imagens e vídeos, ou reservar a proporção via CSS. Para mapas, vídeos incorporados e widgets, reserve o espaço com altura mínima antes de o conteúdo chegar. Avisos e banners inseridos depois do carregamento devem ter espaço reservado ou ficar mais abaixo na página. Para fontes, o desenvolvedor pode pré-carregar os arquivos e definir uma fonte substituta de medidas parecidas.

Quanto a velocidade pesa na busca

A documentação do Google afirma que as Core Web Vitals são usadas pelos sistemas de classificação. Afirma também que bons resultados nesses relatórios não garantem as primeiras posições, e que a busca procura mostrar o conteúdo mais relevante mesmo quando a experiência da página é inferior. O próprio Google desaconselha perseguir a nota perfeita só por causa de SEO.

A leitura prática para um consultório é corrigir o que está na faixa ruim, levar as três métricas para a faixa boa no celular e parar aí. Depois de publicar as correções, o laboratório mostra o efeito no mesmo dia, e os dados de campo levam até 28 dias para refletir a mudança por inteiro, porque a janela de coleta tem esse tamanho. O Search Console tem um relatório de Core Web Vitals que acompanha o site todo com esses mesmos dados de campo.