Core Web Vitals: o que são e por que devemos nos preocupar?

Ceci Sousa
Inside SumUp
Published in
11 min readFeb 25, 2022
Ilustração de uma máquina de batimentos cardíacos ao lado de um estetoscópio, porém mostrando as linhas de medição de LCP, FID e CLS
LCP, FID e CSL: três métricas vitais para oferecer uma boa experiência em aplicações web

Já não é de hoje que o Google vem desenvolvendo uma importante iniciativa sobre métricas que avaliam se a experiência do usuário ao acessar um determinado site é boa ou não.

Foi a partir desse contexto que, em 2020, surgiram as Core Web Vitals — métricas que se aplicam a todas as páginas web para avaliar três aspectos da experiência do usuário: carregamento (LCP), interatividade (FID) e estabilidade visual (CLS).

Mas como essa sopa de letrinhas pode impactar diretamente o dia a dia de quem trabalha com o desenvolvimento de aplicações front-end?

Web Vitals versus Core Web Vitals: o que são?

Precisamos começar dando um passo para trás a fim de entender o que são as Web Vitals antes de finalmente descobrir o que seria o seu core (isto é, o seu núcleo ou parte central, digamos assim).

As Web Vitals são uma iniciativa do Google criada para nos fornecer orientação unificada em relação a sinais de qualidade dos sites, com a intenção de proporcionar uma experiência melhor em aplicações web. Em poucas palavras, as Web Vitals são métricas com foco na experiência do usuário.

“A otimização da qualidade da experiência do usuário é a chave para o sucesso no longo prazo de qualquer site na web” — Philip Walton, Senior Engineer no Google

Mas com tantas métricas existentes por aí, além de diversas ferramentas e inúmeras oportunidades de melhorias, como eu, desenvolvedora ou desenvolvedor web, vou saber por onde começar a otimizar o meu site? Depois da grande onda de incentivo aos sites mobile-friendly (que se adaptam aos dispositivos móveis), por exemplo, o que mais devemos priorizar ao desenvolver aplicações web?

Com o intuito de sanar essa nossa preocupação, foram divulgadas oficialmente em maio de 2020 as Core Web Vitals. Elas equivalem a métricas essenciais, as que mais importam e nas quais devemos focar, para garantir que um site é saudável e agradável ao usuário.

Por que devemos nos preocupar com as Core Web Vitals?

Para começar, ao oferecer uma experiência web mais satisfatória aos usuários em todos os navegadores e plataformas, também garantimos que os sites possam evoluir em relação às expectativas dos usuários de dispositivos móveis.

O Google acredita que essa mudança contribuirá para o sucesso dos negócios na web, aumentando o engajamento dos usuários e facilitando as transações em geral.

Com o objetivo de dar ainda mais ênfase a essa preocupação, inclusive, o Google passou a incluir a experiência dos usuários na página web aos diversos indicadores já usados hoje pela empresa para classificar os resultados da pesquisa no seu buscador.

Ou seja, as Core Web Vitals vão influenciar diretamente na classificação do seu site nos resultados de busca do Google. E ninguém quer aparecer na página 2, não é mesmo?

A maioria dos usuários que buscam por termos no Google não acessa os resultados além da primeira página
A maioria dos usuários que buscam por termos no Google não costuma acessar os resultados que se encontram além da primeira página

Em linhas gerais, as Core Web Vitals foram oficialmente adicionadas à já existente lista do Google de indicadores de experiência na página web, valendo mundialmente desde junho de 2021. E, dada a sua importância, elas têm sido chamadas por aí de “a grande atualização do Google em 2021” ou “o novo algoritmo do Google”.

Desde essa data, portanto, são estes os fatores que mais importam para o Google quando ele decide em qual posição mostrará um determinado site:

Diagrama que explica como funcionam as métricas de experiência na página em resultados da Pesquisa Google
Desde junho de 2021, as Core Web Vitals foram incorporadas às demais métricas de experiência da página, que influenciam nos resultados de busca do Google

Vemos as Core Web Vitals — em cor verde, na imagem acima — sendo oficialmente incorporadas à lista do Google de indicadores experiência na página, mas também vale a pena mencionar rapidamente o que são os outros três indicadores — também na imagem acima, em cinza — que já faziam parte desse algoritmo:

  • Mobile friendly: avalia se a página é otimizada para dispositivos móveis;
  • HTTPS: avalia se página é exibida com Hyper Text Transfer Protocol Secure (Protocolo de Transferência de Hipertexto Seguro), isto é, se ela utiliza este protocolo de comunicação da internet que protege a integridade e a confidencialidade dos dados entre o computador do usuário e a página web, garantindo que a conexão do site é segura.
  • No intrusive interstitials: avalia se o conteúdo da aplicação pode ser acessado facilmente, sem o uso dos famosos anúncios pop-up bem no meio da nossa tela.

A sopa de letrinhas: que métricas são essas?

Como já mencionado, as métricas que compõem o Core Web Vitals envolvem três principais aspectos da experiência do usuário: carregamento (LCP), interatividade (FID) e estabilidade visual (CLS).

Ao avaliar todas elas, o Google define uma pontuação específica para o seu site e utiliza esse resultado em sua ferramenta de busca. Vamos então entender o que cada uma dessas métricas significa e como podemos melhorá-las?

1) Largest Contentful Paint (LCP) ou Carregamento

Ilustração de uma página web sendo carregada, antes e depois de a imagem aparecer
Quanto tempo leva para o maior elemento da página carregar complemente?

O LCP mede o tempo de renderização do maior elemento visível dentro da viewport (janela de visualização) do usuário. Isso quer dizer que essa métrica calcula quanto tempo se passa entre o início do carregamento da página até a renderização do seu maior elemento.

Vale lembrar que o LCP não para de contar até que o maior elemento esteja completamente visível na tela.

Entre os elementos considerados pela métrica estão as imagens, os vídeos, os elementos com imagem de fundo e os grandes blocos de textos, por exemplo.

Um detalhe importante a se observar é que o LCP é diferente da métrica de First Contentful Paint (FCP) — que não faz parte das Core Web Vitals e mede o tempo desde o início do carregamento da página até o momento em que o primeiro elemento, seja qual for o tamanho dele, é renderizado na tela.

Para evitar essa confusão, o próprio Google nos fornece alguns exemplos de sites sendo carregados: vejamos nas imagens abaixo o tempo de carregamento do primeiro elemento (FCP) e também do maior elemento (LCP) nos sites da CNN, do Instagram e do buscador do Google.

Screenshots da versão mobile do site CNN
Site da CNN: o maior elemento da página a ser carregado é a imagem, que foi o último a aparecer… 😬
Screenshots da versão mobile do site Instagram
Site do Instagram: o maior elemento da página a ser carregado é o logotipo, que surgiu um pouco depois do FCP, mas não foi o último 🙂
Screenshots da versão mobile do site de buscas do Google
Site do buscador do Google: o maior elemento da página a ser carregado é o bloco de texto, que surgiu logo depois do FCP e já estava visível muito antes de toda a página terminar de ser carregada por completo 🥳

De acordo com o Google, podemos considerar 2,5 segundos ou menos como um bom tempo de LCP. Já sites com LCP entre 2,5 e 4 segundos são classificados entre aqueles que ainda precisam de melhorias. E, por fim, sites com LCP acima de 4 segundos são classificados como ruins, precisando de melhorias urgentes.

Gráfico que mostra como a métrica de LCP funciona

O que fazer para melhorar o LCP?

O LCP é afetada principalmente por quatro fatores:

  • Tempos de resposta lentos do servidor;
  • JavaScript e CSS que bloqueiam a renderização;
  • Tempos de carregamento de recursos;
  • Renderização do lado do cliente.

Para melhorar essa métrica:

  • Aplique carregamento instantâneo com o padrão PRPL (cujas dicas podem ser encontradas aqui);
  • Otimize o CSS;
  • Otimize as imagens;
  • Otimize as fontes;
  • Otimize o JavaScript.

2) First Input Delay (FID) ou Interatividade

Ilustração de um site cujo botão foi clicado e, após algum tempo, o spinner de loading foi carregado
Quanto tempo leva para o site reagir a uma interação do usuário?

O FID mede o tempo desde quando um usuário interage com a página (ao clicar num link ou botão, por exemplo) até o momento em que o navegador é realmente capaz de começar a processar o evento em resposta a essa interação.

Em outras palavras, o FID calcula o tempo entre a primeira interação — que envolva Javascript — do usuário com a página até o momento em que o navegador começa a processar uma resposta a isso.

O FID mede apenas o “atraso” no processamento do evento: ela não mede o tempo de processamento do evento em si, nem o tempo que o navegador leva para atualizar a UI (user interface ou interface do usuário) após a execução de um evento.

Vale mencionar que o FID só consegue ser medido por meio de dados reais de usuários. O Google disponibiliza uma série de ferramentas de medição das Core Web Vitals — sobre as quais vamos falar logo mais –, porém nem todas elas são capazes de medir o FID. Nesses casos, existe uma métrica substituta chamada TBT (Total Blocking Time ou tempo total de bloqueio).

Ilustrações que mostram que um site ainda está carregando quando o usuário clica no menu; somente após os demais componentes da página estarem visíveis é que o site conseguiu responder ao evento de clique
O site começa a carregar, tendo o menu como primeiro elemento a ser mostrado. O usuário clica no menu, porém o site não processa imediatamente esse evento: ele ainda está terminando de carregar os demais conteúdos e imagens da página… Quando o maior elemento finalmente é carregado, agora sim o site consegue processar o evento de interação do usuário com o menu 😬

De acordo com o Google, um FID abaixo de 100 milissegundos é considerado bom. Já um FID entre 100 e 300 milissegundos é um tempo razoável, que ainda precisa de melhorias. E, acima de 300 milissegundos, isso é considerado um FID ruim, que precisa de melhorias urgentes.

Gráfico que mostra como a métrica de FID funciona

O que fazer para melhorar o FID?

Um dos principais motivos para que nosso site seja mal avaliado quanto ao FID é a execução pesada de JavaScript. Para melhorar esta métrica, devemos otimizar a forma como o JavaScript processa, compila e executa apágina web.

Para melhorar essa métrica:

  • Reduza o impacto do código de terceiros: um script third-party é qualquer script hospedado em um domínio diferente do seu site (como o Google Tag Manager);
  • Reduza o tempo de execução do JavaScript, removendo códigos que não estejam sendo utilizados, diminuindo a dependência em cascata de componentes e minimizando os dados que requerem um pós-processamento no lado do cliente;
  • Minimize o trabalho da thread principal, movendo as operações que não são de interface do usuário para uma thread separada.

3) Cumulative Layout Shift (CLS) ou Estabilidade Visual

Ilustrações que mostram que, após o carregamento geral da página, um banner surgiu no topo e modificou o local de aparição dos demais elementos
Quão estável é o site após o carregamento geral da página?

Quando um site inesperadamente muda seu layout, isso pode levar o usuário a cometer algum tipo de erro — por exemplo, clicar por engano em um botão ou link que surgiu “do nada” após o carregamento geral da página.

O CLS mede a estabilidade visual de uma página, ajudando a quantificar a frequência com que os usuários experimentam essas mudanças inesperadas de layout, afetando negativamente sua experiência.

É importante lembrar que uma mudança no layout da página geralmente ocorre porque os elementos são carregados de forma assíncrona ou são adicionados dinamicamente à página acima do conteúdo existente.

O “culpado” desse comportamento pode ser uma imagem ou vídeo com dimensões desconhecidas, uma fonte que fica maior ou menor, ou até mesmo um anúncio ou widget de terceiros que se redimensiona dinamicamente.

A página já está carregada e o usuário precisa confirmar o pedido ou clicar no botão de voltar. No mesmo segundo em que ele iria clicar no botão de voltar, surge um banner que muda completamente a localização dos botões. Acidentalmente, o usuário acaba de confirmar um pedido de 56 itens… 😬

De acordo com o Google, um CLS abaixo de 0,1 é considerado bom; entre 0,1 e 0,25 é razoável, ainda precisando de melhorias; e um CLS acima de 0,25 é considerado ruim, precisando de melhorias urgentes. Para calcular sua pontuação, o navegador usa como base o tamanho da viewport (janela de visualização) e o movimento dos elementos.

Gráfico que mostra como a métrica de CLS funciona

O que fazer para melhorar o CLS?

As causas mais comuns de um CLS ruim são:

  • Imagens sem dimensões;
  • Anúncios, incorporações e iframes sem dimensões;
  • Conteúdo injetado dinamicamente;
  • Baixar e renderizar fontes da web de forma não otimizada.

Para melhorar essa métrica:

  • Sempre inclua atributos de tamanho em suas imagens e elementos de vídeo ou reserve o espaço necessário usando o aspect-ratio do CSS: essa abordagem garante que o navegador possa prever e alocar a quantidade correta de espaço na página enquanto a imagem é carregada;
  • Nunca insira conteúdo acima do conteúdo existente, exceto em resposta a uma interação do usuário — isso garante que qualquer mudança de layout seja esperada;
  • Banners e formulários podem causar esse deslocamento quando são inseridos acima do conteúdo já existente na página. Por isso, se for usá-los, reserve espaço com antecedência.

Como saber se meu site está saudável?

Simples! Por meio de ferramentas gratuitas, que permitem que todos os sites, desde os menores até os maiores, tenham visibilidade de seus respectivos desempenhos e do que precisa ser feito para melhorá-los.

Existem as ferramentas de campo (field tools), baseadas em dados reais. Para que isso seja possível, o Relatório de Experiência do Usuário Chrome coleta dados anônimos de medição de usuários reais para cada Core Web Vital. Esses dados são disponibilizados para as ferramentas PageSpeed, Search Console, Chrome UX Report e Extensão Web Vitals.

Além destas, há também as ferramentas de laboratório (lab tools), que nos ajudam a testar o desempenho de um site durante o processo de desenvolvimento, antes de uma atualização ou nova funcionalidade ser lançada aos usuários. Estas ferramentas, porém, não medem FID: em seu lugar, é possível olhar para a métrica de TBT (Total Blocking Time ou tempo total de bloqueio), que ajuda a quantificar o nível de não-interatividade de uma página. As mais conhecidas são o Lighthouse e o Chrome Dev Tools.

PageSpeed, Chrome UX Report, Search Console, Chrome Dev Tools, Lighthouse e Extensão Web Vitals listadas entre as ferramentas que ajudam a medir as Core Web Vitals
PageSpeed, Chrome UX Report, Search Console, Chrome Dev Tools, Lighthouse e Extensão Web Vitals listadas entre as ferramentas que ajudam a medir as Core Web Vitals

PageSpeed Insights

  • O PageSpeed é uma ferramenta do próprio Google que ajuda a compreender o desempenho das métricas de Core Web Vitals, considerando usuários reais do Chrome;
  • A ferramenta também fornece um conjunto de recomendações acionáveis sobre como o proprietário de um site pode melhorar a experiência da página.

Chrome UX Report

  • O relatório CrUX é um conjunto de dados públicos reais referentes à experiência dos usuários em milhões de sites. As informações são obtidas a partir de usuários que deram seu consentimento ao Google;
  • Uma das formas de obter acesso aos dados é usando a sua API RESTful, cujos dados são atualizados diariamente e agregam os dados dos últimos 28 dias.

Chrome DevTools

  • Integrada ao navegador Google Chrome, trata-se de um conjunto de ferramentas para desenvolvedores web;
  • Para utilizar, basta clicar no site com o botão direito do mouse e selecionar a opção “Inspecionar”, obtendo acesso ao HTML, Console, Network, etc.

Search Console

  • O Search Console é mais uma ferramenta do Google que, através de dados reais, fornece informações sobre a performance de todas as páginas do seu site.

Lighthouse

  • Ferramenta automatizada de auditoria de sites que nos ajuda a diagnosticar problemas e identificar oportunidades para melhorar a experiência do usuário;
  • Mede várias dimensões da qualidade da experiência do usuário num ambiente de laboratório, incluindo também dados de desempenho e acessibilidade;
  • Pode ser executada como extensão do Chrome ou como CI (Continuous Integration) no repositório do seu site, sendo rodada a cada novo pull request.

Extensão do Web Vitals

  • Ajuda a rastrear o desempenho de uma página em relação às métricas Core Web Vitals em tempo real.

Para resumir as Core Web Vitais em cinco frases!

  • Criadas pelo Google, as Core Web Vitals são métricas essenciais para garantir um site saudável.
  • Essas métricas avaliam carregamento (LCP), interatividade (FID) e estabilidade visual (CLS) de sites web.
  • Melhorar os resultados dessas métricas ajuda seu site a conquistar uma posição melhor na busca do Google em comparação com seus concorrentes.
  • As Core Web Vitais já estão valendo desde junho de 2021.
  • Não faltam ferramentas, relatórios e conteúdos gratuitos do próprio Google para te ajudar a medir e melhorar o desempenho do seu site.

Fontes & Referências

Quer uma nova oportunidade de carreira com desafios globais? Confira nossas vagas em Engenharia e Produto e conheça mais sobre a SumUp.

--

--

Ceci Sousa
Inside SumUp

Front-end engineer with experience in public relations — or maybe the opposite. But definitely a cat person.