A Google atribui, cada vez mais, importância a user experience, neste sentido, no ano passado, adicionou novos indicadores que permitem avaliar a experiência do utilizador nos websites com vista a melhorar a experiência de navegação. Estes novos indicadores, mais conhecidos como Core Web Vitals, têm os parâmetros previamente estabelecidos pela Google e são uma combinação de conjuntos de indicadores ligados à velocidade, tempo de resposta e estabilidade visual de uma página web, e têm como objetivo proporcionar uma visão completa da qualidade da experiência do utilizador. 

As principais métricas que o Core Web Vitals utiliza para avaliar a experiência completa de um utilizador numa página web são: 

  • LCP, FID, CLS. 
  • “Mobile Friendly”;
  • Sítios web HTTPS (SSL);
  • Problemas de malware ou segurança (Search Console);
  • Experiência de Anúncios (Publicidade).
WEB Core vitals - web.de
Fonte: Backlinko – Core Web Vitals Study

Cada métrica do Core Web Vitals representa uma faceta distinta na experiência do utilizador, é mensurável e indica “the real-world experience”. Através dos Core Web Vitals, os proprietários das páginas web podem avaliar e, por consequente, melhorar a experiência dos utilizadores no seu website. 

Indicadores Core Web Vitals 

Os KPIs do Core Web Vitals têm três aspetos principais na medição da experiência do utilizador: a velocidade, o tempo de resposta e a estabilidade visual. 

Conheça melhor as especificidades destes indicadores e recomendações de optimização:

Métricas Web Core Vitals
Fonte: Web.de – Vitals

Largest Contentful Paint (LCP) 

O Largest Contentful Paint mede a velocidade da página percebida pelo utilizador, assumindo como fator mais relevante, o cálculo do tempo que o elemento principal do website leva a carregar. A métrica LCP veio substituir os indicadores já existentes como o Load ou o DOMContentLoaded (que não consideravam o fator “visibilidade do ecrã”).

Da mesma forma, o Largest Contentful Paint é mais fácil de compreender do que a First Meaningful Paint (FMP) e o Speed Index (SI), dois indicadores bastante complexos que, no entanto, ainda podemos encontrar na ferramenta Lighthouse.

Como especificado atualmente no API do LCP, nesta métrica são tidos em conta os seguintes elementos:

Os elementos <img>.
Os elementos <image> dentro de uma etiqueta <svg>.
Os elementos <video>.
Os elementos com uma imagem carregada em segundo plano utilizando um url(_).
Os blocos de texto.

Web Core Vitals - Largest Contentful Paint
Fonte: Web.de – LCP

Nestes dois exemplos, é percetível o funcionamento da métrica LCP, o tempo que o website demora a mostrar o maior elemento visto no ecrã, que, neste caso particular, são as duas imagens principais.

1. Qual o tempo ideal de carregamento? Segundo a Google, para alcançar uma “good user experience” é recomendado que o tempo de carregamento de uma página seja 2,5 segundos ou menor. 

2. Percentil 75% da Google – Para garantir que a meta dos 2,5 segundos está a ser atingida pela maioria dos utilizadores, recomenda-se que seja utilizado o percentil 75% da Google para percecionar a performance dos carregamentos da página, tanto em dispositivos móveis como em desktop. 

Percentil 75%

O Percentil 75% é o cálculo que a Google utiliza para considerar a performance global de um website e baseia-se no seguinte princípio: três quartos (¾) das visitas ao website devem obter uma experiência dentro dos valores estabelecidos como positivos nas métricas Core Web Vitals.  

Neste sentido, é importante sublinhar que este cálculo, pode ser, igualmente utilizado nos indicadores FID e CLS, medindo nestes casos, a interatividade e a estabilidade visual, respetivamente. 

Percentil 75% Core Web Vitals
Cálculo Percentil 75% da Google

Podemos verificar, ao analisar a tabela que no primeiro caso, a página encontra-se otimizada: de um total de 100 visitas a uma página web através da Google, 75 dos utilizadores tiveram uma experiência considerada “boa”, a média das métricas Core Web Vitals atingiu o limite sugerido pela Google, ou seja, o carregamento da página para esses 75 utilizadores foi igual ou inferior a 2,5 segundos. Nos restantes 25 utilizadores, o carregamento foi considerado fraco, ou seja, foi atingido um LPC maior que 2,5 segundos.

No segundo caso, o website necessita de otimização, na medida que, num total de 100 visitas, 60 utilizadores obtiveram uma “boa” classificação nas métricas Core Web Vitals, no entanto, 40 utilizadores tiveram uma classificação fraca para a mesma métrica. 

Otimização do indicador LCP

Algumas práticas para melhorar o tempo de carregamento (loading) do website:

Assegurar o carregamento assíncrono dos elementos CSS – Um dos aspetos mais importantes na melhoria do desempenho de uma página web é o carregamento do CSS que deverá ser efetuado, de uma forma a que não atrase a velocidade de processamento da página. Normalmente, os browsers carregam o CSS externo de maneira síncrona, o que pode suscitar possíveis atrasos. Pelo menos uma parte do CSS do site deve ser carregada antes da página ser renderizada.

Otimização de imagens – Para melhorar a velocidade do website, a otimização de imagens é crucial, na medida em que, as imagens são os principais consumidores de banda larga. Neste sentido, é importante escolher o formato, comprimir a imagem e determinar a dimensão ideal.

Melhorar o tempo de resposta do servidor – Reduzir o tempo de resposta do servidor é um princípio fundamental visto que irá melhorar todos os aspetos relacionados com a velocidade da página, incluindo as métricas Core Web Vitals (LCP, FID, FCP). O tempo de resposta do servidor é, também conhecido como o tempo até o primeiro byte (TTFB), ou seja, o tempo que o servidor web leva para responder à solicitação do browser, que inclui HTML, CSS, JavaScript, arquivos de fonte e outros ativos solicitados. 

First Input Delay (FID)

O First Input Delay mede o tempo necessário para que o utilizador possa interagir com o website. Trata-se da primeira impressão da capacidade de resposta da página web percecionada pelo utilizador e, como em todas as áreas, as primeiras impressões são frequentemente cruciais. 

Para um FID otimizado, a Google recomenda que o tempo de resposta seja menor que 100 milissegundos. Este cálculo, assume as ações: cliques, toques no teclado e “toques” na versão móvel.

Melhorar a execução do FID

O motivo mais comum de um FID lento é a execução de um JavaScript pesado, por outras palavras, o browser não consegue responder às interações do utilizador porque o thread principal está ocupado. Neste sentido, otimizar a performance do JavaScript é essencial para reduzir o tempo de interação. 

Alguns princípios para melhorar a interatividade do website:

Divisão das long tasks – Qualquer código que bloqueie por 50 milissegundos, ou mais, pode ser caracterizado como uma Long Task. Com vista a reduzir a quantidade de JavaScript que é carregado numa só página, pode ser útil, dividir o código de longa execução em tarefas assíncronas menores e eliminar o JavaScript que não necessita. 

Otimizar o website para uma rápida interação – O tempo de execução pesado e a fragmentação ineficiente podem diminuir a rapidez com que o website responde ao user input e impactar negativamente o FID. Neste sentido, carregar progressivamente o código e os recursos pode ajudar a melhorar o tempo de execução e, deste modo, tornar as interações mais fáceis. 

Usar Web Worker – Ter o thread principal bloqueado é uma das principais causas do atraso das interações. Neste sentido, os Web Workers possibilitam a execução de JavaScript num thread em segundo plano. Pode dividir o JavaScript em vários blocos, técnica conhecida como lazy loading e carregar os scripts de terceiros com defer ou async. Para tornar a utilização dos web Workers mais simples, pode utilizar as bibliotecas: Comlink, Workway e Workerize

Cumulative Layout Shift (CLS)

O último dos indicadores, o Cumulative Layout Shift dedica-se à medição da estabilidade visual do website. Neste ponto, a frequência com que os utilizadores percecionam uma alteração inesperada no formato da página pode representar um fator extremamente negativo. 

Para fornecer uma boa experiência ao utilizador, as páginas devem apresentar um CLS de 0.1 ou menor, quanto mais baixa a pontuação, mais agradável é a navegação.

Para calcular as pontuações individuais, a Google utiliza a seguinte fórmula:

Fonte: Web.dev CLS

Por exemplo, se houver um bloco de texto dentro de uma página que desce para mostrar outro elemento, a Google medirá a Impact Fraction, ou seja, a união das áreas visíveis de todos os elementos instáveis da imagem anterior e da imagem atual.

Fonte: Web.de – CLS

Na primeira imagem há um elemento de texto que ocupa metade da parte visível do ecrã e na seguinte, o elemento é deslocado para baixo em 25% da altura da janela. O retângulo com pontos vermelhos indica a união da área visível do elemento nos dois ambientes, que, neste caso, ocupa 75% da janela total, pelo que a sua Impact Fraction será de 0,75. 

Também com base no exemplo da Google, a maior dimensão da janela é a altura, e o elemento instável deslocou a altura da janela em 25%, o que resultou numa Distance Fraction de 0,25.

Assim, no exemplo, a Impact Fraction é de 0,75 e a Distance Fraction é de 0,25. Portanto, a pontuação de deslocação para o formato de página é 0,75 * 0,25 = 0,1875.

Melhorar a performance da métrica CLS

Na maioria dos websites pode evitar mudanças inesperadas de layout ao seguir alguns dos seguintes princípios:

Ter em atenção o tamanho das imagens/vídeos –
Incluir sempre os atributos de tamanho em elementos de imagens e vídeos ou reserve o espaço necessário com CSS aspect ratio boxes. Esta abordagem garante que o browser consegue alocar o espaço necessário no documento enquanto as imagens carregam.

Não inserir conteúdo sobre o que já existe – Exceto em resposta a uma interação de um utilizador, isto garante que qualquer mudança de layout que ocorra já seja expectável pelo utilizador. 

Utilizar animações que não alterem o layout  –  As animações e transições (quando bem concebidas) são uma ótima forma de atualizar e apresentar o conteúdo da página web, sem surpreender o utilizador. O conteúdo que muda inesperadamente cria, quase sempre, uma experiência negativa ao utilizador, no entanto, o conteúdo que muda de forma natural e gradual de uma posição para outra ajuda o utilizador a perceber o que está a acontecer na página web e guia-o para a mudança.

Ferramentas para medir as métricas do Core Web Vitals

Em conclusão, pode medir os indicadores anteriormente apresentados LCP, FID e CLS através do conjunto de ferramentas disponibilizadas pela Google: Lighthouse, PageSpeed Insights, Chrome DevTools, Search Console, Web.dev’s measure tool, Web Vitals Chrome extension e o Chrome UX Report API.

Medição Web Core Vitals
Fonte: Web.dev – Vitals Tools

Na Labelium já integrámos totalmente estes novos KPIs na nossa metodologia, tanto na fase de auditoria como nos nossos dashboards de monitorização do desempenho web para os nossos clientes.  Se quiser que o ajudemos na otimização dos KPIs que constituem o Core Web Vitals, convidamo-lo a contactar-nos. Os nossos especialistas em performance poderão analisar os pontos de melhoria e realizar os ajustes necessários. 

Contate-nos