Velocidade da página e Principais métricas da Web
A velocidade da página, nas práticas de pesquisa modernas, significa fazer com que as páginas pareçam rápidas: o conteúdo principal surge rapidamente, o esquema mantém-se estável e as interações respondem sem atrasos. O nome público que a Google dá às três métricas de campo que captam essa sensação é — Largest Contentful Paint (), Interaction to Next Paint () e Cumulative Layout Shift ().
Ao longo desta página, suponha que a Fernwood precisa que a sua página de preços, páginas de comparação e principais guias atinjam os limiares de «bom» em dispositivos móveis — onde chegam a maioria dos novos visitantes e muitos cliques encaminhados por assistentes.
Esta técnica deliberadamente não é um manual completo de engenharia. O web.dev já cobre detalhadamente o como fazer. O que se segue é o enquadramento para a tomada de decisões: o que significam as métricas, qual a sua importância, como definir prioridades com a Silktide e para onde encaminhar os engenheiros para implementarem correções.
Porque funciona (e em que medida)
Há dois públicos interessados:
- Visitantes. Um LCP lento e um CLS instável provocam abandono antes de a resposta ou a CTA ser vista. Isto é um problema de conversão, mesmo quando as classificações estão bem.
- Pesquisa. A Google afirma que as Principais métricas da Web são utilizadas pelos sistemas de classificação como parte da experiência da página e recomenda boas métricas para o sucesso na Pesquisa (Compreender as Principais métricas da Web e os resultados da Pesquisa Google; Compreender a experiência da página). A Google também afirma que a Pesquisa continua a procurar mostrar o conteúdo mais relevante mesmo quando a experiência da página é inferior — portanto, as métricas são um sinal real, não uma alavanca mágica de classificação. Considere-as requisitos básicos e um critério de desempate entre páginas semelhantes, e não um substituto para conteúdo que dá prioridade à resposta ou para a autoridade.
Especificamente para AEO: uma página rápida não faz com que um assistente o cite. Mas uma página lenta, cujo esquema muda, continua a perder os utilizadores humanos que essas citações enviam — e a renderização pesada no lado do cliente que prejudica a velocidade também costuma prejudicar o conteúdo legível sem JavaScript.
As três métricas importantes
Os limiares abaixo são as metas «boas» da Google, avaliadas para utilizadores reais aproximadamente no percentil 75 (dados de campo). As ferramentas de laboratório fazem diagnósticos; os dados de campo são o que a Pesquisa avalia.
| Métrica | O que mede | Bom |
|---|---|---|
| LCP | Quando o conteúdo principal aparece | ≤ 2,5 s |
| INP | A rapidez com que a página responde a cliques/toques | ≤ 200 ms |
| CLS | Quanto o esquema muda durante o carregamento | ≤ 0,1 |
Detalhes e guias de depuração: Métricas do web.dev, Otimizar o LCP, Otimizar o INP, Otimizar o CLS.
Como abordar o problema (ordem de operações da Fernwood)
1. Escolha as páginas importantes
Não tente resolver tudo de uma vez. Comece por:
- Páginas de destino com muito tráfego e a página inicial
- Páginas de conversão (preços, registo, comparações principais)
- Os guias estruturantes e as páginas de investigação que pretende que sejam citados
Um arquivo de blogue mediano pode esperar. Uma página de preços lenta não pode.
2. Separe o diagnóstico de laboratório da realidade de campo
- Laboratório (testes de velocidade da Silktide, Lighthouse, WebPageTest): repetível, adequado para encontrar causas num URL e perfil de dispositivo específicos.
- Campo (Chrome UX Report / relatório de Principais métricas da Web do Search Console, RUM como o Analytics da Silktide, quando disponível): o que os visitantes reais experienciaram.
Podem divergir sem que nenhum esteja errado — os dispositivos, países e estados de cache são diferentes. Corrija problemas de laboratório que correspondam claramente a falhas no campo; não procure a perfeição no laboratório num URL que já cumpre os limiares de campo.
O ecrã de Velocidade da Silktide combina diagnósticos de laboratório com medições de visitantes reais quando o Analytics está ligado. A verificação Web Vitals resume o desempenho de laboratório; Páginas de carregamento lento e Alterações de esquema isolam o LCP e o CLS.
3. Corrija as causas, não as pontuações
Quando a Silktide (ou o Lighthouse) aponta uma causa, corrija-a:
| Causa comum | Métrica típica | Silktide / passo seguinte |
|---|---|---|
| Imagem principal enorme, servidor lento, CSS/JS que bloqueia a renderização | LCP | Páginas de carregamento lento, Pré-carregar imagem LCP, verificações de otimização de imagens |
| Imagens/anúncios/conteúdo incorporado sem espaço reservado; tipos de letra tardios | CLS | Alterações de esquema, Tamanhos de imagem explícitos |
| Tarefas JavaScript longas ao clicar | INP / TBT | Reduzir o tempo de execução de JavaScript, Eliminar recursos que bloqueiam a renderização |
| Excesso geral de bytes | Todas | Rever o peso em bytes, formatos de imagem modernos, armazenamento em cache |
Os engenheiros devem usar os guias do web.dev indicados acima para obter detalhes de implementação — os padrões específicos de cada framework mudam mais rapidamente do que esta página deveria mudar.
4. Teste novamente os mesmos URLs
Após uma correção, volte a executar os testes de laboratório no mesmo perfil de dispositivo e, em seguida, aguarde que os dados de campo sejam atualizados (as janelas do CrUX abrangem várias semanas). Avalie o sucesso pelo estado de campo dos URLs importantes, não por uma captura de ecrã do Lighthouse apenas da página inicial numa apresentação.
Limites honestos
- O conteúdo continua a vencer. Uma página vazia e rápida perde para uma resposta completa mais lenta. Trabalhar a velocidade de páginas fracas é apenas polimento.
- Terceiros. Gestores de etiquetas, widgets de chat e ferramentas de testes A/B dominam frequentemente o INP e o LCP. Reserve capital político para os remover ou adiar; minificar o seu próprio CSS não salvará uma bomba síncrona de terceiros.
- SPA / renderização apenas no cliente. Se o site de marketing da Fernwood disponibiliza uma estrutura vazia, poderá estar a lutar tanto contra as métricas como contra a legibilidade para rastreadores de IA. Prefira SSR/SSG para conteúdo público (Conteúdo legível sem JavaScript).
- Teatro de sobre-otimização. Reduzir 20 ms do LCP de laboratório num URL cujos dados de campo já estão a verde raramente é a melhor utilização do tempo de um engenheiro, enquanto as páginas de comparação ainda não têm blocos de evidências.
Como a Silktide ajuda
- Ecrã de Velocidade — por onde começar no produto
- Web Vitals — pontuação de resumo de laboratório e tempos dos componentes
- Páginas de carregamento lento (LCP) e Alterações de esquema (CLS)
- Verificações de desempenho de apoio (imagens, JS, cache, redirecionamentos) associadas a partir desses artigos
- Visão geral da Experiência do utilizador: Experiência do utilizador
Relacionado
- Conteúdo legível sem JavaScript — frequentemente a mesma causa raiz que um LCP fraco em tecnologias modernas
- / / /
- Web Vitals (web.dev)
- Principais métricas da Web e a Pesquisa Google
- Compreender a experiência da página nos resultados da Pesquisa Google