A experiência da página e as métricas incluídas do Core Web Vital serão oficialmente utilizadas para posicionar páginas em maio de 2021.

Fonte: Google
A forma mais fácil de ver as métricas do seu website é com o relatório Core Web Vitals no Google Search Console. Com o relatório, pode ver facilmente se as suas páginas estão categorizadas como “URLs pobres”, “URLs precisam ser melhoradas” ou “bons URLs”.

No relatório, pode encontrar informações mais detalhadas sobre os problemas específicos e uma lista das páginas afetadas.

Facto 1: As métricas são divididas entre desktop e mobile, mas apenas sinais de mobile serão usados para posicionar as páginas. O Google está a mudar para a indexação 100% mobile-first (dispositivos móveis em primeiro lugar) em março, então faz sentido usar os sinais de velocidade móvel, uma vez que as páginas indexadas também serão baseadas nas versões mobile.
Facto 2: Os dados vêm do Relatório de experiência do utilizador do Chrome (CrUX), que regista dados de utilizadores do Chrome que optaram por participar. As métricas serão avaliadas no 75º percentil de utilizadores, portanto, se 70% dos seus utilizdaores estiverem na categoria “bom” e 5% na categoria “precisa de melhorias”, a sua página ainda será avaliada como “precisa de melhorias”.
Facto 3: As métricas serão avaliadas para cada página, mas se não houver dados suficientes, John Mueller afirma que sinais de seções de um website ou do website em geral podem ser usados.
Facto 4: Com a adição destas novas métricas, o AMP está a ser removido como requisito do recurso Notícias Principais em dispositivos móveis. Como as novas histórias não terão dados sobre as métricas de velocidade, é provável que as métricas de uma categoria maior de páginas ou mesmo de todo o domínio possam ser usadas para tal.
Facto 5: As Aplicações de Página Única não medem algumas das métricas, FID e LCP, através de transições de página. Falaremos sobre o que são num minuto.
Facto 6: As métricas podem mudar com o tempo e os limiares também. O Google já mudou as métricas utilizadas para medir a velocidade nas suas ferramentas ao longo dos anos, bem como os seus limiares para o que é considerado rápido ou não. É muito provável que tudo mude novamente no futuro. Na verdade, trabalhámos para melhorar as métricas anteriores no ano passado, mas precisamos trabalhar novamente para melhorar as novas métricas.
Apenas para nivelar as expectativas, lembre-se que existem mais de 200 fatores de posicionamento. Eu não esperaria muitas melhorias em melhorar o Core Web Vitals. Não se sabe o quanto impactarão as posições, mas é improvável que seja um sinal forte, especialmente considerando que muitos dos componentes de experiência da página já foram usados pelo Google para determinar o posicionamento.
Vamos examinar cada um dos principais elementos vitais da web em mais detalhe.
Aqui estão os três atuais componentes dos Core Web Vitals:
Largest Contentful Paint (LCP) — carregamento
LCP é o maior elemento visível carregado na janela de visualização.

Fonte: web.dev/vitals
O maior elemento geralmente será uma imagem em destaque ou talvez a tag <h1>, mas pode ser qualquer um destes:
- um elemento <img>
- um elemento <image> dentro de um elemento <svg>
- a imagem dentro de um elemento <video>
- a imagem de fundo carregada com a função url ()
- blocos de texto
<svg> e <video> podem ser adicionados no futuro.
Como ver o LCP
No PageSpeed Insights, o elemento LCP será especificado na seção Diagnósticos. Para a página testada, o LCP é nossa imagem em destaque na publicação do blog.

No DevTools do Chrome, siga estas etapas:
- Desempenho> verifique “Capturas de tela”
- Clique em ‘Iniciar criação de perfil e recarregar a página’
- LCP está no gráfico do tempo
- Clique no nó; este é o elemento para LCP

Otimizar LCP
Com o nosso elemento LCP nesta e em muitas outras páginas a ser a imagem de destaque, provavelmente podemos melhorar pré-carregando essa imagem ou possivelmente alinhando a imagem inteira para fazer o download da imagem com o código HTML. Basicamente, queremos carregar esta imagem mais rápido do que fazemos atualmente.
Recursos
- Otimizar Largest Contentful Paint — web.dev
- Investigar Largest Contentful Paint — Paul Irish (vídeo)
- Como Melhorar a Velocidade da Página do Início ao Fim — Ahrefs
Cumulative Layout Shift (CLS) — estabilidade visual
O CLS mede como os elementos se movem ou quão estável é o layout da página. Este leva em consideração o tamanho do conteúdo e a distância que ele percorre. Um grande problema com esta métrica é que ela continua a medir mesmo após o carregamento inicial da página. O Google recebe feedback sobre esta métrica específica, então provavelmente veremos algumas mudanças no futuro.

Fonte: web.dev/vitals
Pode ser irritante se tentar clicar em algo numa página que muda e acabar a clicar em algo que não pretendia. Isto está sempre a acontecer comigo. Clico numa coisa e, de repente, estou a clicar em anúncios e mesmo noutro website. É frustrante enquanto utilizador.

As causas comuns de CLS incluem:
- Imagens sem dimensões
- Anúncios, incorporações e iframes sem dimensões
- Injetar conteúdo com JavaScript
- Aplicar fontes ou estilos no final do carregamento
Como ver CLS
No PageSpeed Insights, em Diagnósticos, encontrará uma lista de elementos que estão a mudar.

Usando WebPageTest. No Filmstrip View, utilize as seguintes opções:
- Destacar as Mudanças de Layout
- Tamanho da Miniatura: Enorme
- Intervalo da Miniatura: 0,1 seg
Observe como a nossa fonte muda de estilo entre 5,1s‑5,2s, mudando o layout conforme a nossa fonte personalizada é aplicada.

Você pode querer tentar o Gerador de GIF para Mudança de Layout.

A Smashing Magazine também partilhou uma técnica interessante, na qual delinearam tudo com uma linha vermelha sólida de 3px e gravaram um vídeo do carregamento da página para identificar onde as mudanças de layout estavam a acontecer.
Otimizar CLS
Para a nossa página de testes, o que podemos querer fazer é pré-carregar a nossa fonte personalizada, descartar a fonte personalizada completamente (é duvidoso que o façamos), ou usar uma fonte padrão para o carregamento inicial da página e carregar a nossa fonte somente nos carregamentos de página subsequentes. Aqui há compromissos em termos de marca, estilo, consistência etc., e teremos que decidir qual o melhor caminho a seguir.
Recursos
- O Que Força o layout/refluxo — Paul Irish
- Otimizar Cumulative Layout Shift — web.dev
- Depuração de Layout Shifts — web.dev
- Perceber Cumulative Layout Shift — Annie Sullivan (vídeo)
- Como Evitar Mudanças de Layout Causadas por Fontes Web — Simon Hearne
First Input Delay (FID) — interatividade
FID é o tempo desde quando um utilizador interage com a sua página até que a página possa responder. Também pode pensar nisto como a capacidade de resposta. Isso não inclui scroll ou zoom.
Interações de exemplo:
- clicar num link ou botão
- inserir texto num campo em branco
- selecionar um menu suspenso
- clicar numa caixa de seleção.
Pode ser frustrante tentar clicar em alguma coisa e nada acontecer na página.

Fonte: web.dev/vitals
Nem todos os utilizadores irão interagir com uma página, portanto, eles podem não ter um valor FID. É também por isso que as ferramentas de teste de laboratório não terão o valor porque não estão a interagir com a página. Em vez disso use o tempo total de bloqueio (TBT — Total Blocking Time, em inglês).
Causas de FID
JavaScript a competir pelo thread principal. Há apenas um thread principal e o JavaScript compete para executar tarefas nele.
Enquanto uma tarefa está em execução, uma página não pode responder à entrada do utilizador. Este é o atraso que se sente. Quanto mais longa for a tarefa, maior será o atraso experimentado pelo utilizador. As pausas entre as tarefas são as oportunidades que a página tem de alternar para a tarefa de entrada do utilizador e responder ao que ele deseja fazer.
Otimizar FID
I don’t see any concerns for our site for FID, but in general, you want to break up long tasks and defer any JavaScript that isn’t needed until later.
Resources
- Otimizar First Input Delay — web.dev
- Como Melhorar a Velocidade da Página do Início ao Fim — Ahrefs
A diferença entre os dados de laboratório e os de campo é que os dados de campo olham para utilizadores reais, condições de rede, dispositivos, armazenamento em cache, etc., e os dados de laboratório são testados consistentemente com base nas mesmas condições, com a esperança de que os resultados do teste sejam repetíveis.
Dados de Campo
Dados de Laboratório
LCP | FID | CLS | |
---|---|---|---|
DevTools do Chrome | ✔ | ✘ (usa TBT) | ✔ |
Lighthouse | ✔ | ✘ (usa TBT) | ✔ |
WebPageTest | ✔ | ✘ (usa TBT) | ✔ |
PageSpeed Insights | ✔ | ✘ (usa TBT) | ✔ |
web.dev | ✔ | ✘ (usa TBT) | ✔ |
Gosto do relatório no GSC porque pode ver os dados de muitas páginas ao mesmo tempo, mas os dados estão um pouco atrasados e numa média contínua de 28 dias, portanto, as alterações podem levar algum tempo para aparecer no relatório. No Chrome 88, o Google está a adicionar Core Web Vitals direto no DevTools.
Também pode encontrar os pesos de pontuação para o Lighthouse a qualquer momento e ver as mudanças históricas.

Pensamentos finais
Deseja melhorar o Core Web Vitals para que os seus utilizadores tenham uma melhor experiência. Resta saber que impacto estes terão para o SEO, mas como mencionei no meu artigo sobre velocidade da página, estes devem ajudá-lo a registar mais dados nas suas análises, o que “parece” uma melhoria.
Trabalhe com seus desenvolvedores; eles são os especialistas. A velocidade da página pode ser algo extremamente complexo. Se estiver por conta própria, pode precisar de um plugin ou um serviço para lidar com isso, como o WP Rocket ou o NitroPack.