Largest Contentful Paint (LCP)
Estime quando a maior imagem ou bloco de texto visível termina de renderizar no teste de laboratório. Use um resultado lento para investigar o conteúdo principal, os recursos e a entrega.
Monitore Core Web Vitals das páginas importantes do site
Execute verificações diárias em laboratório para URLs públicas selecionadas e mantenha LCP, CLS, FCP, TTFB, TBT, Speed Index, o veredicto atual e o horário da verificação junto do seu fluxo técnico de SEO. Encontre regressões e teste correções focadas novamente sem confundir medições sintéticas com dados reais de usuários.
TL;DR
Demasiado longo; não lido
Mostrar resumo Ocultar resumo
TL;DR
Demasiado longo; não lido
O que o monitoramento de Core Web Vitals do Screpy faz?
O Screpy executa verificações recorrentes em laboratório para URLs públicas selecionadas. Ele informa LCP e CLS com FCP, TTFB, TBT, Speed Index, um veredicto de laboratório e a atualização da verificação para que as equipes encontrem regressões, investiguem uma causa específica e meçam novamente sem confundir resultados sintéticos com dados de usuários reais.
Escolha o escopo do monitoramento
- A página inicial é incluída quando um projeto é configurado para monitoramento.
- URLs públicas adicionais podem ser adicionadas dentro do limite do plano atual.
- Cada URL ativa pode receber uma nova verificação agendada após um dia.
- A URL exata e o horário da última verificação permanecem visíveis junto do resultado.
Leia os principais sinais de laboratório
- Largest Contentful Paint estima quando o conteúdo visível principal termina de renderizar.
- Cumulative Layout Shift mede movimentos inesperados durante o teste.
- Um veredicto de laboratório ajuda a mostrar primeiro as URLs que precisam de atenção.
- O veredicto é um diagnóstico sintético, não a avaliação de dados de campo do Google.
Use diagnósticos complementares
- First Contentful Paint acrescenta contexto do carregamento inicial.
- Time to First Byte ajuda a direcionar a investigação para o atraso da resposta inicial.
- Total Blocking Time mostra tarefas que bloqueiam a thread principal no laboratório.
- Speed Index resume a rapidez com que o conteúdo visível aparece durante o teste.
Interprete o resultado com segurança
- Compare dados de laboratório usando a mesma URL e o mesmo método de medição.
- Total Blocking Time não é Interaction to Next Paint.
- Uma métrica fraca direciona a investigação, mas não prova a causa raiz.
- Uma melhor experiência de página ajuda os usuários sem garantir classificações ou tráfego.
Leia as métricas de laboratório por trás de cada página verificada.
O relatório separa carregamento, estabilidade visual, resposta do servidor e diagnósticos da thread principal para que um único veredicto não esconda o sinal que precisa de investigação.
Cumulative Layout Shift (CLS)
Meça movimentos visuais inesperados durante o teste. Imagens sem dimensões, embeds, fontes e conteúdo tardio são pontos comuns de investigação.
First Contentful Paint (FCP)
Veja quando o primeiro texto, imagem ou outro conteúdo é pintado. FCP ajuda a localizar atrasos iniciais antes de o conteúdo principal aparecer.
Time to First Byte (TTFB)
Analise o atraso da resposta inicial do servidor observado pela verificação. Um valor lento pode apontar para hospedagem, cache, redirecionamentos ou trabalho no backend.
Total Blocking Time (TBT)
Meça por quanto tempo as tarefas da thread principal bloqueiam a capacidade de resposta no laboratório. TBT é um diagnóstico útil, mas não é a métrica real de usuário Interaction to Next Paint.
Speed Index
Resuma a rapidez com que o conteúdo visível aparece durante o teste em vez de depender de um único marco de renderização.
Veredicto de desempenho em laboratório
Use os veredictos Bom, Precisa melhorar ou Ruim para encontrar primeiro as URLs selecionadas que precisam de atenção. Ele resume resultados de laboratório, não a avaliação de usuários do Google.
Atualização da URL e da verificação
Mantenha cada resultado associado à URL pública exata e ao horário da última verificação para não usar uma medição antiga ou sem relação em uma decisão atual.
Mantenha páginas importantes em um ciclo recorrente de verificações.
Adicione URLs públicas representativas e analise o resultado mais recente após cada verificação diária. Cada veredicto permanece ligado à URL testada e ao horário da coleta.
- Monitorar a página inicial e URLs selecionadas de alto valor
- Ordenar páginas verificadas por veredicto ou URL
- Conferir o horário da última verificação antes de agir
Separe Core Web Vitals dos diagnósticos complementares.
Analise LCP e CLS com FCP, TTFB, TBT e Speed Index. O Screpy identifica TBT como diagnóstico de resposta em laboratório, e não como INP real de usuários.
- Inspecionar medições de carregamento e estabilidade visual
- Usar métricas de resposta e renderização para direcionar a próxima verificação
- Manter distintas as afirmações sobre laboratório e dados de campo
Passe de uma métrica fraca para uma mudança testável.
Use a métrica mais fraca para decidir se deve investigar renderização de conteúdo, reserva de layout, resposta do servidor, recursos ou trabalho da thread principal. Altere uma causa provável e meça a mesma URL novamente.
- Priorizar páginas críticas para o negócio e modelos compartilhados
- Investigar a página e o caminho de entrega antes de mudar o código
- Validar a correção focada com um resultado agendado posterior
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.
- 01
Escolha uma URL pública representativa
Comece pela página inicial, uma página de conversão ou uma URL de um modelo importante. Monitorar todas as páginas de baixo valor cria ruído antes de gerar insights.
- 02
Deixe a verificação agendada estabelecer uma linha de base
O Screpy verifica diariamente URLs monitoradas elegíveis e registra veredicto, métricas, URL testada e horário da verificação.
- 03
Siga a métrica fraca até uma hipótese focada
Use LCP, CLS, FCP, TTFB, TBT e Speed Index para decidir se deve investigar primeiro renderização, reserva de layout, resposta, recursos ou trabalho da thread principal.
- 04
Mude uma causa e meça novamente
Publique a menor correção relevante, mantenha estável a URL monitorada e use o próximo resultado agendado para conferir se a medição melhorou.
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.
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.
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 ajuda a diagnosticar a resposta em laboratório. INP exige interações reais, portanto um resultado TBT não deve ser apresentado como medição de INP.
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.
Execute verificações diárias para URLs públicas selecionadas e veja veredicto, métricas e atualização.
Rastreie o site para encontrar padrões repetidos de páginas, recursos, renderização e aspectos técnicos em uma URL ou modelo afetado.
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
Siga o guia do Screpy para escolher URLs, ler cada métrica com sua URL e data, distinguir dados de laboratório e de campo e testar uma melhoria focada.
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.
O que o monitoramento de Core Web Vitals do Screpy mede?
O Screpy executa verificações em laboratório para URLs públicas selecionadas. Ele informa LCP, CLS, FCP, TTFB, TBT, Speed Index, um veredicto de laboratório e o horário da última verificação.
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.
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.
Por que o Screpy mostra TBT em vez de INP?
Interaction to Next Paint depende de interações reais e é uma métrica de campo. Total Blocking Time pode ser medido em um laboratório controlado e revela trabalho da thread principal, mas as duas métricas não são intercambiáveis.
Com que frequência as URLs monitoradas são verificadas?
URLs ativas ficam elegíveis para uma nova verificação agendada após um dia. Atividade da fila, disponibilidade da página e plano atual podem afetar quando o resultado fica pronto; use o horário da última verificação antes de agir.
Quais páginas devo monitorar primeiro?
Comece pela página inicial, landing pages de alto tráfego, entradas de conversão e uma URL representativa de cada modelo importante. Adicione páginas em que uma regressão afetaria muitos visitantes ou em que a mesma implementação é reutilizada.
Um veredicto Bom do Screpy significa que a URL passa nos Core Web Vitals do Google?
Não necessariamente. O Screpy resume um teste de laboratório, enquanto a avaliação do Google usa dados reais de LCP, INP e CLS quando há dados de campo suficientes. Use o veredicto para orientar testes e compare com o relatório de campo quando precisar de uma avaliação real.
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.
Mantenha as verificações de desempenho focadas nas páginas importantes.
Escolha URLs públicas representativas, estabeleça uma linha de base diária em laboratório, investigue a métrica mais fraca e meça novamente após uma mudança focada.