Landing pages principais
Monitore páginas que apresentam o produto, serviço ou campanha, pois uma primeira experiência lenta pode afetar descoberta e conversão.
Monitore Core Web Vitals das páginas importantes do site
Acompanhe LCP, CLS e os indicadores de carga de páginas públicas selecionadas do domínio do projeto. Confira cinco métricas por URL e um resumo separado da página inicial com Speed Index; avalie uma correção focada com um resultado posterior. São testes controlados, não dados de campo de usuários reais.
Verificações de Core Web Vitals
LCP
Encontre URLs selecionados em que o conteúdo principal aparece tarde.
CLS
Analise mudanças inesperadas de layout nos URLs selecionados.
Medições laboratoriais diárias
Anote os valores atuais e confira um resultado posterior de laboratório depois de uma correção focada.
Monitore Largest Contentful Paint
Largest Contentful Paint mede quando a maior imagem, bloco de texto ou vídeo elegível fica visível na área da prova. Use o LCP de cada URL monitorada para escolher qual página precisa de uma investigação mais detalhada do carregamento.
- O Screpy exibe LCP em segundos: até 2,5 s é bom; acima de 2,5 s até 4 s precisa melhorar; acima de 4 s é ruim.
- Um FCP rápido seguido de LCP lento indica que parte do conteúdo apareceu antes do elemento principal. Investigue a entrega e a renderização desse elemento, em vez de presumir que toda a página ficou em branco.
- Confirme a imagem, a fonte ou o atraso de renderização com uma análise de desempenho feita pelo desenvolvedor. O número sozinho não identifica o elemento nem determina a correção.
example.comLaboratório
LCP2,1 s
Meça Cumulative Layout Shift
Uma página pode carregar rápido e ainda deslocar um botão ou parágrafo inesperadamente. Cumulative Layout Shift fornece uma pontuação de estabilidade em laboratório para cada URL monitorada, permitindo investigar movimentos separadamente da velocidade de carregamento.
- CLS não tem unidade de tempo: até 0,1 é bom no Screpy; acima de 0,1 até 0,25 precisa melhorar; acima de 0,25 é ruim.
- Revise o espaço reservado para imagens, anúncios e conteúdos incorporados, além das trocas de fontes. São possíveis causas; a pontuação do Screpy não identifica qual elemento se moveu.
- Um CLS baixo no teste de carregamento não descarta deslocamentos posteriores durante a visita. Confira a interação real e os dados de campo quando o problema aparece depois da carga.
CLS
0,04Confira Total Blocking Time
Total Blocking Time ajuda a detectar trabalho da thread principal que pode atrasar a resposta às entradas durante o carregamento. Leia TBT com LCP e FCP: conteúdo aparecendo rapidamente não significa necessariamente que a página responde rápido.
- TBT é exibido em milissegundos: até 200 ms é bom; acima de 200 ms até 600 ms precisa melhorar; acima de 600 ms é ruim.
- O tempo de bloqueio soma os trechos de tarefas longas que excedem 50 ms no intervalo medido. Não é o tempo total de execução de JavaScript.
- Se TBT estiver alto, analise tarefas longas e scripts desnecessários com ferramentas de desenvolvimento antes de alterar o código. O valor no painel não atribui o atraso a um script específico.
- TBT não é INP. INP mede interações e pode ser testado em laboratório executando essas interações; este recurso do Screpy não informa uma medição de INP.
example.comLaboratório
TBT180 ms
Compare FCP e TTFB
First Contentful Paint marca o primeiro conteúdo visível; Time to First Byte marca o começo da resposta. Ler ambos para a mesma URL ajuda a separar um atraso inicial de resposta do tempo necessário para colocar conteúdo na tela.
- FCP é exibido em segundos: até 1,8 s é bom; acima de 1,8 s até 3 s precisa melhorar; acima de 3 s é ruim.
- TTFB é exibido em milissegundos: até 800 ms é bom; acima de 800 ms até 1.800 ms precisa melhorar; acima de 1.800 ms é ruim. Conexão, redirecionamentos e resposta podem afetá-lo.
- Se TTFB for baixo e FCP lento, investigue o que atrasa a primeira exibição. Se a resposta for lenta, examine a entrega primeiro; nenhum valor isolado comprova uma causa no servidor ou na renderização.
Laboratório2.100 ms
TTFB450 ms
FCP1.100 ms
LCP2.100 ms
TBT95 ms
Monitore páginas importantes
Acompanhe um conjunto administrável de páginas públicas do projeto, em vez de tratar um único resultado da página inicial como o site inteiro. Use a cota do projeto prevista no plano para páginas onde problemas de carga ou layout têm maior impacto.
- A página inicial é adicionada quando o projeto é criado. Adicione outras URLs públicas do domínio do projeto ou seus subdomínios quando o plano permitir monitoramento.
- Escolha páginas representativas de produtos, categorias, artigos e entradas de conversão. Um problema recorrente de modelo pode justificar mais investigação, mas testar uma URL não mede todas as páginas que usam esse modelo.
- A entrada normaliza o protocolo e o domínio, adiciona HTTPS quando omitido e remove fragmentos. Caminhos e parâmetros de consulta continuam relevantes; uma URL normalizada duplicada é rejeitada.
- Uma página adicionada aguarda a primeira verificação agendada antes de aparecer na tabela. Adicionar a URL não inicia um teste imediato.
- Confirme a remoção para parar de acompanhar uma página e liberar seu espaço na cota. Isso remove o registro monitorado, não a página do seu site ou do Google.
example.comLaboratório
/1,4 s/shop/linen2,8 s/guides/seo1,9 sConfira o desempenho da página inicial
O resumo acima da tabela usa a página inicial verificada do projeto. Ele reúne as medições atuais de laboratório, incluindo Speed Index; a tabela abaixo mantém suas cinco métricas exibidas vinculadas a cada URL monitorada.
- Leia FCP, LCP, CLS, TTFB, TBT e Speed Index no resumo da página inicial. São valores dessa página, não uma média das páginas acompanhadas.
- Speed Index descreve a rapidez com que o conteúdo visível se forma durante a carga. O Screpy mostra segundos: até 3,4 s é bom; acima de 3,4 s até 5,8 s precisa melhorar; acima de 5,8 s é ruim.
- Cada barra representa a medição atual. Não é um histórico salvo, uma porcentagem de visitantes ou o percentil 75 dos dados de campo do Google.
- Sem resultado verificado da página inicial, o resumo fica indisponível. Não é substituído pelo resultado de outra URL monitorada.
example.comLaboratório
LCP2,1 s
TBT180 ms
CLS0,04
Acompanhe testes diários de laboratório
Páginas ativas elegíveis podem receber outra verificação agendada após um dia. Revise o resultado atual depois de uma mudança focada, considerando o plano e a disponibilidade da verificação, sem esperar um teste em horário exato garantido.
- Ordene os resultados por URL ou status CWV para organizar a revisão. FCP, LCP, CLS, TTFB e TBT permanecem visíveis para cada URL testada.
- O indicador CWV usa a pior classificação disponível de LCP, CLS e TBT. PASS significa que esse conjunto disponível é bom; FAIL inclui resultados que precisam melhorar e ruins.
- Confira valores ausentes mesmo que a linha mostre PASS. Uma métrica ausente não conta como medição saudável, e o indicador não certifica a avaliação do Google com LCP, INP e CLS de campo.
- Sem dados significa que o veredito de laboratório está indisponível. Um valor ausente não é zero, e uma verificação malsucedida não comprova que a página está saudável.
- Anote os valores atuais antes de publicar uma correção e compare com um resultado posterior da mesma URL. A tabela mostra resultados atuais, não um histórico salvo de antes e depois.
Diário09:00
123456789101112131415161718192021
Leia dados de desempenho com SEO MCP
Leve o resumo de laboratório salvo da página inicial a uma conversa com IA ou integração REST. Peça uma explicação das medições disponíveis e uma investigação focada, mantendo as evidências separadas da correção proposta.
- Autentique-se e selecione um projeto acessível. O acesso REST também exige que Core Web Vitals esteja disponível no plano do projeto.
- A resposta contém a URL inicial, o horário salvo da verificação e os valores disponíveis de FCP, LCP, CLS, TTFB, TBT e Speed Index. São dados da página inicial, não uma lista de todas as páginas monitoradas.
- Sem uma página inicial verificada, não há resumo; medições individuais ausentes continuam indisponíveis. Peça ao assistente que indique lacunas antes de concluir.
- A ferramenta MCP de Core Web Vitals lê dados salvos. Não inicia testes, adiciona páginas, identifica o elemento responsável nem transforma TBT em INP.
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Converse sobre Core Web Vitals. Com SEO MCP.
Leia o resumo salvo de laboratório da página inicial do projeto via SEO MCP. Explique métricas disponíveis com URL e horário da verificação e escolha o que investigar sem presumir um relatório de todas as páginas ou um novo teste.
- Screpy: Olá! Vamos analisar Core Web Vitals para example.com. O que você quer saber?
- Você: Explique os resultados salvos de laboratório da página inicial de example.com e indique o que ainda é desconhecido.
- Screpy: Neste exemplo da página inicial, LCP é 3,2 s e precisa melhorar; CLS é 0,04 e bom. Confira a URL e o horário salvos antes de usar os valores. Esses dois números não mostram todas as métricas, não medem INP nem identificam o elemento responsável. Posso sugerir uma investigação, não executar um novo teste. Exemplo de valores da página inicial em laboratório: LCP: 3,2 s. CLS: 0,04.
- Você: Transforme isso em um breve plano de ação.
- Screpy: Vou separar os resultados das recomendações. Revise as evidências, escolha uma mudança e confira os resultados depois. Seus próximos passos: Revise: Confira a fonte e a data de cada resultado.. Decida: Escolha a primeira mudança.. Verifique: Compare os resultados após a mudança..
- Você: Você pode explicar as evidências em linguagem simples?
- Screpy: Sim. Pergunte sobre um resultado compatível e explicarei o que mostra, de onde vem e o que continua incerto. Dados ausentes continuam indisponíveis; recomendações não são correções automáticas.
Transforme uma URL lenta em uma correção de desempenho testável.
Mantenha URL e método de medição estáveis, use a métrica mais fraca para direcionar a investigação e valide uma mudança em uma verificação posterior.
-
Escolha uma URL pública representativa
Escolha URLs públicas do domínio do projeto ou seus subdomínios. Comece pela página inicial, uma entrada de conversão e uma URL representativa de um modelo importante, dentro da cota do projeto.
-
Deixe a verificação agendada estabelecer uma linha de base
URLs ativas elegíveis recebem verificações agendadas recorrentes. Após a primeira tentativa, confira os valores disponíveis de FCP, LCP, CLS, TTFB e TBT da URL testada; o resumo separado da página inicial também inclui Speed Index.
-
Siga a métrica fraca até uma hipótese focada
Use a métrica fraca para escolher uma investigação: LCP para o conteúdo principal, CLS para movimentos inesperados, TBT para trabalho bloqueante e FCP com TTFB para a carga inicial. Speed Index da página inicial dá contexto visual, sem comprovar uma causa.
-
Mude uma causa e meça novamente
Anote os valores antes de uma mudança focada, mantenha a URL estável e compare um resultado agendado posterior. O painel mostra medições atuais: guarde a referência anterior separadamente e investigue mudanças repetidas, sem tratar uma oscilação isolada como prova.
Monitore as páginas onde uma regressão teria maior impacto.
Um conjunto pequeno de URLs representativas é mais fácil de investigar do que um painel cheio de páginas de baixo valor. Comece por jornadas críticas e modelos reutilizáveis.
Modelos de página compartilhados
Escolha uma URL representativa de produto, categoria, artigo ou documentação para revelar problemas de desempenho que podem se repetir no mesmo modelo.
Caminhos de conversão
Mantenha páginas de preços, cadastro, lead e entrada do checkout visíveis quando scripts, embeds, experimentos ou tags de terceiros alterarem o desempenho.
Páginas sensíveis a lançamentos
Acompanhe URLs afetadas por redesigns, mudanças de framework, novas mídias, atualizações do tag manager ou alterações de entrega antes de ampliar o padrão.
Interprete os resultados de laboratório sem exagerá-los.
O Screpy torna verificações recorrentes de desempenho acionáveis. Esses limites mantêm o resultado correto quando a pergunta real envolve dados de campo, causa ou impacto no ranking.
Dados de laboratório, não dados de campo
O Screpy executa testes controlados de páginas. O resultado não representa o conjunto de usuários reais do Chrome UX Report ou do Google Search Console.
TBT não é INP
TBT descreve trabalho bloqueante durante o período de carga medido. INP exige medições de interações e pode ser testado em laboratório executando-as; este recurso do Screpy não informa INP nem substitui evidências de resposta de usuários reais.
Um veredicto não é a causa raiz
Uma métrica ruim indica onde investigar. Confirme o elemento, a solicitação, o script, o modelo ou o comportamento do servidor antes de decidir o que alterar.
Desempenho não é garantia de ranking
Uma boa experiência de página ajuda usuários e pesquisa, mas não substitui conteúdo relevante, rastreabilidade, indexação, links ou outros sinais.
Use o fluxo de desempenho que corresponde à pergunta.
Monitore URLs selecionadas para resultados recorrentes de laboratório, audite o site para padrões técnicos repetidos ou leia a metodologia antes de comparar com relatórios de usuários reais.
Monitore URLs públicas selecionadas do projeto com verificações recorrentes: cinco métricas na tabela e seis no resumo separado da página inicial.
Rastreie o site para encontrar links, imagens e problemas de página ao redor de uma URL ou modelo afetado. Use os achados como contexto técnico, não como um registro detalhado de desempenho.
Entenda escopo, tempo e limites dos dados de laboratório do Screpy antes de compará-los com dados reais de usuários.
Documentação do Screpy
Aprenda a interpretar verificações de desempenho em laboratório
Use o guia para selecionar URLs, ler métricas de laboratório e distingui-las de dados de campo. Guarde uma referência inicial separadamente antes de comparar uma melhoria focada com um resultado posterior.
Respostas às perguntas sobre monitoramento de Core Web Vitals.
Entenda dados de laboratório e de campo, LCP, CLS, TBT, métricas de velocidade, verificações diárias, seleção de URLs, veredictos e limites das afirmações sobre experiência de página.
Quais páginas devo monitorar primeiro?
Comece pela página inicial, páginas públicas importantes, entradas de conversão e uma URL representativa de cada modelo relevante. As URLs adicionadas devem pertencer ao domínio do projeto ou seus subdomínios e caber na cota do plano. Uma amostra de modelo não testa todas as páginas dele.
Quais métricas são os Core Web Vitals oficiais?
Atualmente o Google define Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift como Core Web Vitals. O Screpy mede LCP e CLS em laboratório e informa TBT como diagnóstico junto a FCP, TTFB e Speed Index. TBT não é apresentado como INP.
O que o monitoramento de Core Web Vitals do Screpy mede?
A tabela de URLs do Screpy mostra FCP, LCP, CLS, TTFB e TBT de laboratório. O resumo da página inicial verificada acrescenta Speed Index. A tabela usa PASS/FAIL; respostas autenticadas de API e MCP também mostram a URL inicial e o horário salvo da verificação. Não são medições de usuários reais.
Os dados de Core Web Vitals do Screpy são baseados em usuários reais?
Não. O Screpy informa medições controladas para a URL verificada. Dados de campo do Chrome UX Report ou do Google Search Console refletem visitas reais em um período contínuo e podem variar por dispositivos, redes, localização e comportamento.
Por que o Screpy mostra TBT em vez de INP?
Este recurso mede a carga e fornece TBT como diagnóstico de bloqueio; não mede as interações necessárias para INP. INP pode ser testado em laboratório executando interações, mas TBT não é INP e não descreve todas as interações depois da carga.
Com que frequência as URLs monitoradas são verificadas?
URLs ativas elegíveis podem receber outra verificação agendada após um dia. O plano do projeto e a disponibilidade da verificação influenciam sua conclusão; não há garantia de resultado no mesmo horário diário. Uma nova URL aparece na tabela após a primeira tentativa de verificação.
Melhorar Core Web Vitals garante classificações melhores?
Não. O Google recomenda bons Core Web Vitals para usuários e pesquisa, mas a experiência da página é apenas parte de muitos sinais. Conteúdo relevante ainda pode classificar com experiência mais fraca, e uma página rápida não garante classificação.
Um PASS do Screpy significa que a URL passa nos Core Web Vitals do Google?
Não. O veredito usa a pior classificação disponível de LCP, CLS e TBT em laboratório e pode ter valores ausentes. O Google avalia dados de usuários reais, incluindo INP, com regras próprias de cobertura e percentis. Confira as métricas disponíveis e o relatório de campo adequado antes de concluir.