Biblioteca·SOP·SEO
Teste páginas representativas, separe dados reais de simulações e priorize melhorias de velocidade com evidências e um plano de reteste comparável.
Última revisão: · Revisão editorial
Clareza, estrutura e referências revisadas nesta versão. Não equivale a um teste em uma conta real.
Teste páginas importantes e representativas no celular e no computador, separe dados de campo de usuários reais de resultados simulados em laboratório, identifique um gargalo sustentado pelas evidências e atribua a próxima melhoria com um plano de reteste nas mesmas condições.
Este SOP abrange:
Não abrange:
Comece pelas tarefas importantes dos visitantes e pelos tipos de página para que os testes representem trabalho útil, não um conjunto aleatório de URLs.
Crie uma cópia de trabalho do Plano de ação de SEO técnico. Use a aba Speed tests para medições e Action plan para decisões e acompanhamento.
Escolha uma URL pública funcional para cada tipo importante de página ou tarefa do visitante. Use uma página de produto ou serviço, formulário de leads ou artigo importante, conforme apropriado. Teste uma URL por layout distinto; adicione outra apenas quando o layout ou a tarefa do visitante for significativamente diferente.
Planeje relatórios separados de Mobile e Desktop para cada URL selecionada no PageSpeed Insights. Registre o dispositivo com cada medição, pois celular e computador podem mostrar resultados diferentes.
Dados de campo descrevem visitantes reais ao longo de um período móvel. Dados de laboratório são uma simulação que ajuda a diagnosticar o carregamento de uma página. Mantenha os dois tipos de evidência separados.
Para cada URL e dispositivo selecionados, registre se o PSI possui dados de campo daquela URL exata, da origem inteira do site ou nenhum dado. Os dados de campo resumem visitantes reais do Chrome em um período móvel de 28 dias.
Para cada URL, insira o endereço público exato no PSI e execute o relatório. Quando os resultados carregarem, use o controle de dispositivo para escolher Mobile e observe se os dados de campo dizem “This URL”, “Origin” ou “No data”. Depois, escolha Desktop no relatório carregado e anote a identificação dos dados de campo.
Adicione uma linha Field por URL, dispositivo e data de verificação na aba Speed tests. Preencha URL, Device, Checked on, Data shown, LCP (s), INP (ms), CLS, Assessment, Report URL e Notes. Copie os valores e a avaliação exibidos pelo PSI; deixe as células de métricas vazias quando não houver dados.
O PSI mostra valores de campo do percentil 75: 75% das visitas registradas ficaram iguais ou abaixo de cada valor e 25% foram mais lentas. Registre a data, pois essa janela de 28 dias muda ao longo do tempo.
Use os significados abaixo ao registrar a avaliação dos dados de campo. Os limites “Good” do PSI se aplicam aos valores de campo do percentil 75; não os use para classificar uma execução de laboratório.
Largest Contentful Paint (LCP) indica quando o principal conteúdo visível aparece. Bom: até 2,5 segundos.
Interaction to Next Paint (INP) mede a rapidez de resposta da página após interações reais dos visitantes. Bom: até 200 milissegundos.
Cumulative Layout Shift (CLS) mede movimentos inesperados durante o carregamento. Bom: até 0,1.
Execute a mesma URL e o mesmo dispositivo no PSI três vezes para observar quais achados de carregamento simulado se repetem. Testes de laboratório são simulações controladas; ajudam a diagnosticar, mas não representam o dispositivo, a rede ou o comportamento de cada visitante.
Para cada URL e dispositivo, execute o PSI três vezes sem alterar a página. Se precisar mudar de dispositivo, carregue primeiro o relatório da URL e depois escolha Mobile ou Desktop nele. Em Speed tests, adicione três linhas Lab com a mesma URL e dispositivo, Before/After como “Before” e Run como 1, 2 e 3.
Em cada linha Lab, preencha Checked on, LCP (s), CLS, TBT (ms), Performance score, Report URL e Main finding. Em Main finding, escreva a pista recorrente identificada pelo PSI, como atraso na imagem principal ou resposta lenta do servidor, em vez de “pontuação baixa”.
Total Blocking Time (TBT) estima por quanto tempo scripts ou outro trabalho da página mantêm o navegador ocupado nesse carregamento simulado. Pode apontar trabalho de scripts que merece verificação, mas não é INP. O relatório padrão de laboratório do PSI não fornece INP de laboratório.
Priorize pelo impacto nos visitantes, importância para o negócio e uma causa que você consiga indicar. Use a pontuação de laboratório como contexto, não como decisão.
Compare evidências de campo e laboratório separadamente. Não calcule uma média entre elas: medem experiências diferentes.
Primeiro, considere um tipo importante de página com uma métrica de campo marcada Poor ou Needs Improvement. O valor da página vem da tarefa do visitante ou de contagens disponíveis de visitantes, não da Performance score. Se os dados de campo forem Origin ou No data, não afirme que provam o desempenho da URL testada.
Em seguida, procure o mesmo gargalo provável na maioria das três linhas Lab. Se as leituras ou os achados variarem, registre a incerteza e peça outro conjunto antes de recomendar uma correção específica.
Quando dois problemas tiverem evidências semelhantes, coloque uma correção que afeta vários tipos importantes de página à frente de um problema isolado em uma página menos importante. Se não conseguir identificar uma causa provável, defina a próxima ação como “Confirmar a causa” e atribua uma investigação.
Exemplo: uma página de produto não tem dados de campo, mas as três execuções Lab para celular mostram LCP próximo de 4 segundos e identificam a imagem grande do produto visível. A pista repetida da imagem sustenta verificá-la primeiro, enquanto “No data” significa que você não pode afirmar que visitantes reais têm o mesmo LCP. Registre a ação sobre a imagem e planeje uma verificação posterior de campo.
Na aba Action plan, adicione uma linha para cada problema distinto que deseja acompanhar. Preencha Page or issue, What you found, Next action, Why this comes first, Owner, Review date, Status e Result / how to undo. Para trabalho novo planejado, defina Status como “To do”.
Em What you found, identifique URL, dispositivo, métrica afetada e pista de laboratório repetida ou situação de campo. Em Why this comes first, diga qual tarefa do visitante importa e quantos tipos de página parecem afetados, se souber. Atribua uma pessoa em Owner e uma data em Review date.
Use Result / how to undo para a comparação posterior e, quando pertinente, a ação exata de reversão e quem pode executá-la. Por exemplo, uma mudança de configuração de plugin pode ser desfeita desativando a configuração e limpando seu cache.
Siga o procedimento de imagens relacionado apenas quando, após comparar os achados, você selecionar uma melhoria específica de imagem como a próxima ação de valor para uma página importante. Uma pista recorrente de LCP relacionada a imagens é uma evidência para comparar, não uma decisão por si só. Pese o papel da imagem e a mudança possível contra achados como deslocamento de layout ou bloqueio da renderização. Se uma dessas ações tiver prioridade maior, mantenha-a primeiro e encaminhe ao responsável adequado; o caminho de imagens não será necessário.
Se a mesma página pública importante do WordPress mostrar repetidamente resposta lenta do servidor, use o procedimento de cache de páginas relacionado para testar se um cache simples é adequado. Trate o cache como uma possível correção; o relatório isolado não prova que resolverá o problema.
Se o PSI apontar para código do tema, scripts, hospedagem, CDN ou problema de layout, atribua a tarefa a um desenvolvedor ou especialista em hospedagem. Inclua URL afetada, dispositivo, métrica, pista recorrente e links dos relatórios do PSI em What you found; peça que investiguem essa causa.
Este acompanhamento ocorre quando o responsável termina uma alteração. O plano de ação priorizado está concluído antes desta etapa.
Após concluir a alteração atribuída, repita as três execuções de laboratório do PSI para a mesma URL e dispositivo. Adicione três linhas Lab com Before/After como “After” e Run como 1, 2 e 3.
Compare o intervalo de cada métrica-alvo e observe se o Main finding original mudou. Se os intervalos se sobrepuserem, variarem em direções diferentes ou outra alteração ocorrer ao mesmo tempo, escreva “Unclear” no resultado de Action plan e explique o motivo. Não afirme um ganho claro apenas pela mudança na pontuação.
Em uma data posterior, confira novamente os dados de campo do PSI quando a janela atualizada de 28 dias incluir visitas relevantes após a alteração. Adicione uma nova linha Field para aquela URL e dispositivo. Preserve a linha anterior com data e compare somente identificações Data shown correspondentes.
