Core Web Vitals: Guia Completo de Otimização

Core Web Vitals, as novas métricas de experiência do usuário do Google, são formadas por três métricas que os webmasters e SEOs terão que ter em mente no futuro: carga, interatividade e estabilidade visual.

Como os Core Web Vitals são baseados na experiência do usuário, eles são medidos com dados de campo que são diferentes dos dados de laboratório usados anteriormente que indicam um momento específico durante o processo de carregamento da página.

Em combinação com outros componentes relacionados à segurança e facilidade de uso do site, os Vitais da Web Core serão adicionados ao fator de classificação da experiência da página em maio de 2021. Continue lendo para saber tudo o que você precisa saber sobre o Core Web Vitals, incluindo dicas de otimização e um bônus extra. Confira mais detalhes em nosso site.

Métricas do Core Web Vitals

core web vitals
O que você precisa saber sobre o core web vitals

No início de maio de 2020, o Google anunciou o lançamento iminente de seus novos capitais da web, indicadores-chave que serão usados para classificar a experiência do usuário em sites da web.

Quando o Core Web Vitals do Google for lançado em maio de 2021, eles incluirão três métricas que, em combinação com outras variáveis, constituirão um novo fator de classificação para uma experiência estável e segura do usuário em websites. Mais detalhes sobre o Fator de Ranking de Experiência de Página podem ser encontrados no artigo vinculado.

Os Core Web Vitals são medidos com dados de campo que o Google forneceu em vários relatórios e ferramentas, incluindo Lighthouse, Page Speed Insights e Google Developer Tools. Os Core Web Vitals são formados por três métricas que incluem:

  • Largest Contentful Paint
  • First Input Delay
  • Cumulative Layout Shift

Com o passar do tempo, os capitais Core Web serão adaptados aos últimos desenvolvimentos técnicos e mudanças no comportamento do usuário. Diante disto, o Google reavaliará anualmente os principais sinais vitais da web. Isto significa que as métricas do Core Web Vitals também podem mudar.

O foco em três métricas claras e coerentes do núcleo traz uma série de benefícios em sua estratégia de marketing. O Google pode analisar os sites com base em KPIs claramente comunicados. Isto dá aos webmasters, desenvolvedores web e SEOs uma base sólida quando discutem sua posição em relação a trabalhos e orçamentos específicos com os clientes. ou sua administração, a quem pode ser mostrada evidência dos resultados positivos inequívocos dos vitais vitais vitais da web otimizados.

Onde posso acessar o relatório dos principais sinais vitais da Web?

O Core Web Vitals do Google já foi integrado em todas as ferramentas de análise do Google. Por exemplo, o Core Web Vitals pode ser acessado via PageSpeed Insights, que também inclui a pontuação de velocidade da página (entre zero e 100) gerada a partir do Lighthouse. Os resultados para o Core Web Vitals são mostrados, por um lado, na forma de dados de campo e dados de laboratório.

Os dados de campo são dados anônimos usados para renderizar sites em navegadores usados por usuários reais em vários dispositivos e em várias velocidades de conexão. Os dados de laboratório, por outro lado, são baseados no carregamento simulado de páginas em um único dispositivo sob condições de rede definidas. É por isso que os valores podem ser diferentes.

Os resultados do Core Web Vitals também podem ser acessados no Console de Busca do Google na forma de uma visão direta das métricas para o domínio em questão, mostrando quantos e quais URLs são considerados bons (verde), quais precisam ser melhorados (amarelo), ou quais são pobres (vermelho). Os dados no Console de Busca são baseados no relatório de experiência do usuário no Chrome e refletem os dados reais do usuário do respectivo site para usuários em todo o mundo:

Acesso ao Core Web Vitals: Console de Busca do Google

Enquanto isso, o analista de tendências do Google Webmaster John Mueller fez algumas adições ao Core Web Vitals no Google Office Hours alemão no dia 29 de outubro de 2020. De acordo com isto, as métricas adicionais para o tempo de carregamento, como determinado em detalhes no Google Lighthouse, por exemplo, não desempenham um papel para a experiência da página como um fator de classificação.

Além disso, o Google Core Web Vitals seria determinado separadamente para celular e desktop. Na maioria dos casos, os valores móveis para o Core Web Vitals são piores do que para a página da área de trabalho. O Google então avalia isto separadamente; para a página não há então efeitos negativos nos rankings nos resultados da pesquisa no desktop, mas possivelmente para os rankings móveis, continuou Mueller.

Largest Contentful Paint (LCP): Com que rapidez minha página é carregada?

A Largest Contentful Paint (LCP) mede o tempo que passa até que o maior elemento de conteúdo de uma página tenha sido carregado. Estas podem ser imagens, blocos de texto ou elementos com uma imagem de fundo.

Para LCP, os tempos de carregamento de até 2,5 segundos são bons, qualquer coisa entre 2,5 e 4 segundos precisa ser melhorada – e qualquer coisa inferior a 4 segundos é pobre. O LCP de uma página é determinado com base no status de carregamento da página – porque, na maioria dos casos, o maior elemento é carregado no final.

Otimização para a Largest Contentful Paint

  • Servidor respondendo muito lentamente: Quanto mais tempo o navegador precisar para receber conteúdo do servidor, mais tempo levará para que a página seja carregada pelo usuário. É por isso que o Google recomenda o uso de um framework como React em vez de um arquivo HTML inteiro, para que o conteúdo de uma página seja enviado dinamicamente para o navegador. Também pode ajudar a estabelecer uma Rede de Entrega de Conteúdo (CDN) para permitir que as solicitações sejam enviadas a partir do servidor localizado mais próximo do usuário. Além de um cache eficiente, faz sentido estabelecer conexões de terceiros com antecedência para evitar um atraso evitável na última parte do carregamento da página.
  • JavaScript e CSS render-block: Antes que o navegador possa realmente renderizar elementos de conteúdo, ou seja, visualizá-los para o usuário, a marcação HTML tem que ser analisada no que é chamado de Modelo de Objeto de Documento (DOM). O problema aqui, entretanto, é que o analisador de HTML pára cada vez que as folhas de estilo CSS ou recursos JavaScript têm que ser carregados. Para eliminar este problema, o Google recomenda a mineração de arquivos CSS ou JavaScript, o adiamento de estilos não-críticos ou JS e a definição de atributos CSS críticos.
  • Carregamento de recursos muito lento: Imagens, vídeos ou blocos de conteúdo podem muitas vezes fazer com que os recursos sejam carregados muito lentamente. Aqui, o Google recomenda reduzir as imagens ao tamanho necessário, por exemplo, usando formatos de arquivo mais novos que tenham compressão de imagem superior, como JPEG 2000, JPEG XR ou WebP. Outra abordagem seria carregar previamente os principais recursos e comprimir arquivos HTML, CSS, ou JavaScript usando Gzip. A adaptação do Serving também pode ajudar aqui, dando-lhe a opção de configurar a página para carregar apenas uma pequena imagem em vez de um vídeo se a velocidade de conexão for inferior a 4G, por exemplo. Renderização do lado do cliente: Renderização Client-Side, onde as páginas web são renderizadas diretamente no navegador com a ajuda de estruturas JavaScript como React ou Angular, é um meio eficaz de garantir que a Maior Tinta Contenciosa carregue mais rapidamente para o usuário.

First Input Delay (FID): Quando o usuário pode interagir com uma página?

O First Input Delay (FID) mede o tempo desde quando um usuário interage pela primeira vez com um site até o ponto em que o navegador é capaz de responder a essa interação.

Muitas vezes os usuários vão a um site e imediatamente clicam em um texto ou clicam em um botão sem esperar que a página seja totalmente carregada primeiro. Muitas vezes nada de mais acontecerá porque o navegador está ocupado carregando a página.

Para evitar que os usuários fiquem impacientes e saiam da página novamente porque o navegador não está respondendo à sua entrada, a métrica FID mede o atraso que ocorre entre a entrada do usuário e a resposta do navegador.

Segundo o Google, qualquer coisa abaixo de 100 milissegundos é boa, qualquer coisa entre 100 e 300 milissegundos precisa ser melhorada, enquanto os valores FID acima de 300 milissegundos são considerados pobres. Detalhes sobre o First Input Delay podem ser encontrados na documentação do Google sobre o First Input Delay. Segue abaixo algumas dicas de Otimização para First Input Delay:

  • Dividir tarefas longas: Os atrasos são frequentemente causados pela execução do JavaScript, o que significa que os usuários podem não ser capazes de interagir com o site. Dividir as tarefas pode ajudar nisso. Para o Google, tarefas longas são aquelas em que um pedaço de código bloqueia o fio principal por mais de 50 milissegundos.
  • Priorizando a interatividade: Em outras palavras, dar prioridade ao código que é essencial para a interatividade com o site, o que significa que ele é carregado primeiro. Usando um Web Worker: Com um Web Worker, arquivos JavaScript pesados podem ser executados em uma thread separada, o que significa que a thread principal não é bloqueada.
  • Reduzindo o tempo de execução do JavaScript: Todos os arquivos JavaScript que são executados quando um site é carregado, devem ser analisados com o objetivo de adiar aqueles que não são essenciais.

Cumulative Layout Shift (CLS): Estabilidade visual em um site

Cumulative Layout Shift (CLS) refere-se à estabilidade visual durante a interatividade em um website. Quando um site carrega, mudanças de layout podem acontecer empurrando elementos para baixo da página, por exemplo, enquanto o próximo elemento está carregando acima. Quando o conteúdo se desloca como uma página carrega e o usuário já está interagindo com o site, isto pode ter efeitos indesejáveis.

Em outras palavras, o Cumulative Layout Shift mostra se e até que ponto mudanças inesperadas de layout (turnos) ocorrem enquanto o usuário está interagindo com o site. Por exemplo, quando um novo elemento de conteúdo está sendo visualizado e um botão muda de posição repentinamente sem que o usuário se movimente.Segue algumas dicas de otimização para Cumulative Layout Shift:

  • Especifique o tamanho das imagens e dos elementos de vídeo: Especificar o tamanho exato (L x H) das imagens e vídeos garantirá que não haverá surpresas desagradáveis para os usuários. Alternativamente, o espaço necessário para estes elementos também pode ser definido usando a relação de aspecto com CSS. Desta forma, o navegador manterá o espaço exato necessário para a imagem ou o vídeo livre enquanto ele estiver carregando.
  • Anúncios sem dados de altura / largura: De acordo com o Google, os anúncios são uma das razões mais comuns para a mudança de layout em websites. Isto porque as redes de publicidade – incluindo os anúncios do Google – frequentemente usam formatos de anúncios dinâmicos. Os elementos de espaço reservado podem ajudar aqui – dados históricos permitirão selecionar o tamanho mais provável para um determinado espaço publicitário.
  • Elementos dinâmicos de conteúdo: Elementos como newsletters ou banners de ofertas especiais, blocos de conteúdo relacionados, ou informações GDPR posicionadas como blocos no conteúdo principal de uma página podem resultar em mudanças de layout. Aqui, também, o Google recomenda o uso de elementos de espaço reservado. Isso descartará surpresas desagradáveis para o usuário se o conteúdo mudar enquanto uma página estiver sendo carregada.
  • Fontes da web: Baixar e renderizar fontes web pode causar mudanças de layout – por exemplo, quando a fonte fallback é substituída pela fonte web personalizada. É por isso que é aconselhável pré-carregar as fontes. As fontes web usadas também podem ser salvas em seu próprio servidor.

Conclusão

O Core Web Vitals do Google está preparado para se tornar a métrica principal para medir a experiência do usuário. Inicialmente, os Vitais Centrais da Web serão lançados com três métricas centrais para carregamento (Largest Contentful Paint), interatividade do site (First Input Delay) e estabilidade visual (Cumulative Layout Shift).

Além disso, o Core Web Vitals será fundido com os fatores de classificação existentes, tais como a facilidade de uso móvel ou HTTPS para trazer a você o novíssimo fator de classificação do Google: Experiência da página!

Para maior transparência no Core Web Vitals, o Google publicou uma documentação aprofundada que dá aos webmasters, desenvolvedores e SEOs todas as informações necessárias para entender completamente como os critérios individuais são definidos, quais elementos são cruciais e, mais importante, como os websites podem agora ser otimizados para o novo Core Web Vitals.

Se você ainda não o fez, recomendamos usar o Console de Busca para executar uma verificação adequada em seus próprios projetos web para ver como eles estão se desempenhando na frente dos Vitais Centrais da Web.

A maioria dos websites tem espaço para melhorias – e o Google nos deu as próprias ferramentas necessárias para fazer exatamente isso! Armado com a documentação aprofundada do Google e dicas de otimização para o Core Web Vitals, juntamente com ferramentas de análise como o Lighthouse, você pode aproveitar ao máximo o tempo enquanto aguardamos o lançamento do novo fator de classificação Page Experience.

Para aprender mais sobre o Core Web Vitals, conheça o Curso Camilo Dantas!

Como Anunciar no Facebook Ads Sem Ter a Conta Bloqueada