Inscreva-se em minha Newsletter
Neste artigo vou descrever um pouco sobre o que eu sei sobre o Core Web Vitals e tentar fazer dar algumas dicas para você também conseguir uma boa pontuação nesse novo fator de ranqueamento do Google.
- O que é o Core Web Vitals?
- Como medir o Core Web Vitals?
- Qual a importância do Core Web Vitals para o SEO?
- Qual é o futuro do Core Web Vitals?
O Google recentemente adotou três métricas de experiência do usuário para se tornarem novos fatores de classificação. As métricas são projetadas para medir a velocidade de carregamento, interatividade e estabilidade visual e são conhecidas como Core Web Vitals. Junto com a compatibilidade com dispositivos móveis, a confiabilidade, a segurança, esses novos sinais serão usados para avaliar a experiência geral a fim de decidir, junto os demais fatores já conhecidos, a classificação de uma página.
Eles somente irão fazer parte do Core do Google a partir de 2021, se ainda não começou a otimizar seu site para o Core Web Vitals a hora é agora. Não deixe para depois, mas também não se desespere muito, pois ainda não sabemos o real peso que ele terá no Algoritmo do Google.
O que é o Core Web Vitals?
Core Web Vitals são o resultado de uma longa busca por métricas confiáveis de experiência do usuário. Ao longo dos anos, o Google testou uma série de métricas para medir a experiência real de interação do usuário com uma página web, muitas métricas chegaram perto, mas nenhuma atingiu o ponto. Até agora.
O Google sugere que esta nova combinação de três métricas de experiência do usuário é finalmente capaz de quantificar a primeira impressão que a página causa. Para uma motivação adicional, afirma que os sites que atendem aos padrões do Core Web Vitals têm 24% menos chances de perder visitantes durante o carregamento de páginas.
Você pode encontrar os dados do Core Web Vitals do seu site na seção Melhorias da sua conta do Google Search Console.
Largest Contentful Paint (LCP)
O Largest Contentful Paint avalia o desempenho de carregamento, é definido usando os seguintes benchmarks de experiência do usuário:
No momento, o LCP é a resposta do Google sobre o quão rápido uma página aparece. Antes do LCP, havia First Paint, First Contentful Paint, First Meaningful Paint, Time to Interactive, and First CPU Idle, e cada uma dessas métricas tinha suas próprias limitações. Agora, o LCP está longe de ser perfeito, mas por enquanto é a melhor medida para definir quando uma página foi carregada da perspectiva do usuário.
Para calcular o LCP, o Google cronometra a renderização do maior elemento de conteúdo (texto / imagem / vídeo) na tela. Conforme a composição da tela muda durante o carregamento, o Google muda para o elemento maior. Isso continua até que a página seja totalmente carregada ou o usuário comece a interagir com a página:
Existem muitos componentes que podem influenciar a velocidade de carregamento, mas as principais sugestões para melhorar o LCP incluem tempos de resposta do servidor mais rápidos, melhor carregamento de recursos, JavaScript e CSS com menos bloqueio de renderização e melhorar a renderização do lado do cliente.
Aqui estão algumas dicas que você pode implementar para melhorar o LCP do seu site:
- Remova todos os scripts de terceiros desnecessários: No meu site descobri que cada script de terceiros reduziu a velocidade de uma página em 34 ms.
- Revise sua hospedagem: Melhor hospedagem equivale a um melhor tempo de carregamento (incluindo LCP).
- Utilize lazy loading: O lazy loading faz com que as imagens sejam carregadas apenas quando alguém rola a página para baixo até a imagem ser visível. O que significa que você pode obter um LCP significativamente mais rápido.
- Remova os elementos com atributos excessivos: o Google PageSpeed Insights dirá se sua página tem um elemento que está reduzindo a velocidade do LCP.
- Minimize seu CSS: Um arquivo CSS muito grande pode atrasar significativamente os tempos de LCP. Experimente carregar apenas o CSS necessário para aquela página.
First Input Delay (FID)
O First Input Delay avalia a capacidade de resposta da página, é definido usando os seguintes benchmarks de experiência do usuário:
FID é o tempo que uma página leva para reagir à primeira interação do usuário (clicar, tocar ou pressionar uma tecla). Ao contrário dos outros dois sinais (LCP e CLS), o FID só pode ser medido em produção, pois exige que um usuário real escolha quando realizar a primeira ação. Em desenvolvimento, o FID é substituído por Total Blocking Time (TBT), que é o período entre a primeira exibição do conteúdo até a página tornar-se interativa. Está relacionado ao FID, mas informa valores maiores.
Interações que levam mais tempo tendem a ocorrer enquanto a página ainda está carregando, quando parte do conteúdo já está visível, mas ainda não é interativo pois o navegador está ocupado carregando o restante da página:
Para otimizar o FID se concentre no carregamento mais rápido da página, ou seja, divisão de código (requisitar somente o que aquela página vai precisar) e usar menos JavaScript.
Aqui estão algumas dicas que você pode fazer para melhorar o FID do seu site.
- Minimize (ou adie) JavaScript: é quase impossível para os usuários interagirem com uma página enquanto o navegador está carregando o JS. Portanto, minimizar ou adiar JS em sua página é a chave para o FID.
- Remova quaisquer scripts de terceiros não críticos: assim como com o FCP, os scripts de terceiros (como Google Analytics, mapas de calor etc.) podem afetar negativamente o FID.
- Use um cache de navegador: Isso ajuda a carregar o conteúdo em sua página com mais rapidez. O que ajuda o navegador do usuário a realizar as tarefas de carregamento de JS ainda mais rápido.
Cumulative Layout Shift (CLS)
O Cumulative Layout Shift avalia a estabilidade visual de uma página, é definido usando os seguintes benchmarks de experiência do usuário:
Quebra de layout, também conhecida como falha de layout ou falha de conteúdo, é aquele problema quando o conteúdo continua se movendo, mesmo depois da página estar totalmente carregada. Às vezes, é apenas irritante e outras vezes pode fazer com que você clique no item errado, provocando ainda mais alterações indesejadas na página.
A pontuação do CLS é calculada multiplicando a parte da tela que mudou inesperadamente durante o carregamento pela distância percorrida pelo usuário. No exemplo abaixo, metade da tela foi afetada pela mudança, conforme indicado pelo retângulo pontilhado. Ao mesmo tempo, a distância percorrida pelo conteúdo é de 15% da tela, conforme indicado pela seta azul. Assim, para calcular a pontuação do CLS, multiplicamos a área afetada (0,5) pela distância percorrida (0,15) e temos uma pontuação de 0,075 - de acordo com o benchmark.
O CLS é o mais fácil de otimizar do Core Web Vitals. Tudo se resume a incluir atributos de responsividade para suas imagens e vídeos e nunca inserir novo conteúdo acima do conteúdo existente. Por exemplo, você não deve possuir um script que adiciona um banner acima de uma parte da tela que já foi renderizada.
Aqui estão algumas dicas simples que você pode fazer para otimizar o CLS.
- Use as dimensões do atributo de tamanho definido para qualquer mídia (vídeo, imagens, GIFs, infográficos etc.): Dessa forma, o navegador do usuário sabe exatamente quanto espaço aquele elemento ocupa na página. E não vai mudar isso na hora, enquanto a página carrega.
- Certifique-se de que seus anúncios tenham um espaço reservado: caso contrário, eles podem aparecer repentinamente na página, empurrando o conteúdo para baixo, para cima ou para o lado.
- Adicione novos elementos abaixo da dobra: Dessa forma, eles não empurram para baixo o conteúdo que o usuário “espera” que fique onde está.
Como medir o Core Web Vitals?
Os componentes do Core Web Vitals podem ser medidos usando qualquer uma dessas seis ferramentas para desenvolvedores: PageSpeed Insights, Chrome UX Report, Search Console, Chrome DevTools, Lighthouse e Web Vitals Chrome Extension.
A principal diferença entre essas ferramentas é que algumas delas usam dados de usuários reais, enquanto outras medem o desempenho simulando o comportamento do usuário em um ambiente de desenvolvimento. Ferramentas que usam dados reais são uma escolha melhor, pois é isso que o Google usará como fator de classificação. Além disso, o FID só pode ser medido com dados reais e não pode ser reproduzido no ambiente de desenvolvimento. Na tabela acima, você pode diferenciar as ferramentas do laboratório, pois elas substituem o FID por Total Blocking Time (TBT).
As ferramentas também diferem em suas aplicações e níveis exigidos de proficiência técnica. O Search Console pode ser usado como o painel do Core Web Vitals, fornecendo uma visão panorâmica de todo o seu site, enquanto o DevTools e o Lighthouse são mais adequados para aprofundar e realizar o trabalho de otimização da página. A extensão do Chrome e o PageSpeed Insights são melhores para fazer avaliações mais rápidas.
Uma consequência peculiar, mas amplamente relevante, de depender de dados reais é que sua pontuação de otimização é influenciada por seu público. Se o seu público estiver usando dispositivos e redes mais lentos, seu site terá uma pontuação mais baixa do que um site otimizado de forma semelhante com um público mais bem equipado. Este é outro motivo pelo qual o uso de ferramentas que simulam o usuário podem gerar resultados enganosos.
Qual a importância do Core Web Vitals para o SEO?
O Google diz que usará o Core Web Vitals como um critério de desempate, caso haja várias páginas com conteúdo igualmente bom e relevante. Embora seja definitivamente mais uma coisa com que se preocupar, a otimização do Core Web Vitals não deve ser priorizada acima de conteúdo de qualidade, intenção de pesquisa e autoridade da página.
Quanto a cada elemento do Core Web Vitals, temos uma dica sobre seu peso em relação ao outro. Todos os três componentes são usados na versão mais recente do Lighthouse, onde podemos ver sua pontuação de otimização dividida pelo peso de cada componente, onde LCP é 25%, TBT (equivalente ao FID) é 25% e CLS é 5% . Embora digam que os pesos podem ser revisados em versões posteriores, parece que o CLS é atualmente muito menos importante do que os outros dois.
Qual é o futuro do Core Web Vitals?
A introdução do Core Web Vitals estabeleceu um novo ramo de otimização e ainda não está claro como os eventos irão se desenrolar, mas aqui está o que foi mapeado pelo Google até agora:
Sinais de classificação
Em algum momento de 2021, o Core Web Vitals se tornará um fator oficial de classificação. O Google garantiu aos webmasters que eles receberão um aviso de seis meses antes que essas alterações ocorram.
Top Stories
O Core Web Vitals substituirá AMP como um qualificador para entrar nos Top Stories. Anteriormente, o Google foi amplamente criticado por não estender os benefícios das AMP (pré-renderização, colocação nos Top Stories) para páginas não AMP igualmente rápidas, o Google que respondeu que não, porque ainda não há uma maneira confiável de medir a velocidade percebida de páginas não-AMP. Parece que o Core Web Vitals finalmente preencherá essa lacuna.
Novas métricas
No futuro, o Core Web Vitals pode ser expandido para incluir outras métricas de experiência do usuário. Alguns dos candidatos atualmente incluem atrasos de entrada para todas as interações (não apenas a primeira), suavidade (transições / animações) e métricas que permitirão a pré-renderização semelhante a AMP de páginas na SERP.
No meu ponto de vista a introdução do Core Web Vitals é uma boa notícia. O objetivo é remover alguns dos pontos mais comuns de UX, o que é definitivamente um passo em direção a uma web mais agradável, como o Google gosta de dizer. É também um passo para aumentar a transparência entre o Google e os proprietários de websites, não sabemos quase nada sobre o algoritmo de classificação, portanto, a adição de mais fatores oficiais é sempre bem-vinda. E agora que o Google está em um caminho para coletar métricas de UX confiáveis, talvez haja mais oportunidades de classificação para aqueles que estão dispostos.
O que eu mais gostei é que ele finalmente vai usar dados reais de usuários, o que não irá impor uma métrica padrão para todo mundo. Se a maior parte de seus usuários acessarem via Desktop, por exemplo, você não será totalmente penalizado por métricas coletadas de usuários acessando via mobile.