Core Web Vitals: O que é e como melhorar?

Conteúdo

Core Web Vitals foi um dos temas de Marketing Digital, mais comentados no ano de 2021.

Isso porque, antes daquele ano, o Google declarou que este indicador passaria a ser um dos fatores de ranqueamento em suas pesquisas.

De certa forma, essa declaração causou um alvoroço no mundo digital, especialmente para proprietários de sites e lojas virtuais.

Afinal, sempre que o Google faz alguma atualização em seu algoritmo, é necessário ficarmos atentos.

De fato, o Google implementou o Core Web Vitals em maio de 2021 e, ainda hoje, muitos sites não atendem os critérios mínimos desse indicador. Vale dizer, que esta métrica passará por nova atualização em 21 de março de 2024.

Core Web Vitals o que é e como melhorar

O que é o Core Web Vitals?

O Core Web Vitals é uma métrica criada pelo Google para retratar qual experiência o usuário tem ao acessar uma página de site ou loja virtual.

Assim, o objetivo do Google é fazer com que proprietários de sites entreguem melhor experiência aos usuários.

Portanto, é um indicador bastante simples, com apenas três métricas essenciais (as mais importantes), que procuram avaliar a velocidade de carregamento, interatividade dos usuários e estabilidade visual da página.

O que é o Core Web Vitals

 

Segundo o Google, o Web Vitals “é uma iniciativa do Google para fornecer orientação unificada para sinais de qualidades essenciais, para proporcionar uma ótima experiência ao usuário…”

Por outro lado, o Core Web Vitals é o subconjunto do Web Vitals, que se aplicam a todas as páginas da web e devem ser medidos por todos os proprietários de sites..”

Essas métricas do Google, se aplicam a cada página de websites individualmente. Podendo, com base em cada página individual, ter um Core Web Vitals indireto e geral do site, baseando-se pelo conjunto das páginas.

Por que o Core Web Vitals é importante para todos os negócios?

Basicamente, por três motivos principais que estão diretamente relacionados!

É um fator de ranqueamento no Google

Eu imagino que todos os proprietários de sites e lojas online, desejam aumentar o posicionamento e a visibilidade no Google.

Como as métricas essenciais, passaram a ser um fator de posicionamento nas pesquisas do Google, melhorar o Core Web Vitals, pode melhorar também o posicionamento.

Porém, passados três anos desde a implementação, não sabemos exatamente qual o peso do Core Web Vitals em relação a outros fatores de ranqueamento. O fato é o seguinte: vimos casos reais de sites perdendo posicionamento, quando os indicadores de experiência dos usuários pioram.

Experiência dos usuários

Ninguém gosta de acessar um site, que entrega uma experiência ruim de acesso. Por este motivo, levar o Core Web Vitals em consideração permite entregar aos visitantes uma experiência de acesso mais robusta.

Dessa forma, as métricas essenciais, permitem melhorar a experiência dos usuários (seus clientes), ao acessarem o site do seu negócio.

Mais desempenho para o negócio online

Todo empreendedor, espera ter sucesso em seu negócio.

A geração de mais vendas e mais lucros é o objetivo de todos os negócios.

Pesquisas do Google indicam que, a melhoria da velocidade de carregamento do site, está intimamente ligada a maior taxa de conversão e ROAS (Retorno Sobre Investimento).

Por que o Core Web Vitals é importante para todos os negócios

Quais são as métricas do Core Web Vitals?

Primeiramente, vou explicar em detalhes quais são essas métricas e fornecer exemplos visuais, quando possível.

Na próxima parte, vou indicar quais são as técnicas e processos para melhorar cada métrica do Core Web Vitals.

LCP – Largest Contentful Paint (Pintura da maior parte do conteúdo)

A métrica LCP do Core Web Vitals, está diretamente relacionada com a velocidade de carregamento da página.

LCP - Largest Contentful Paint

Todavia, não se trata do carregamento completo de uma determinada página, mas sim do carregamento do conteúdo “acima da dobra”.

Ou seja, é o conteúdo que aparece na tela, assim que acessamos um site, sem realizar nenhuma ação de rolagem de página.

Por outro lado, cada conteúdo carrega em momentos diferentes, por mais rápido que seja. Muitas vezes não percebemos este fato devido a rapidez no carregamento.

Veja esta imagem abaixo, que representa o carregamento do conteúdo:

LCP Pintura da Maior Parte do Conteúdo

Perceba que em um primeiro momento, pode carregar o fundo de uma página (primeira pintura); depois aparece na tela algum conteúdo, como um cabeçalho, ou algum texto (Primeira Pintura de Conteúdo).

Mas, neste momento ainda não é o conteúdo relevante para visualização do usuário (LCP).

Somente quando a página carrega os elementos importantes, ocorre o LCP, a métrica do Core Web Vitals.

Perceba que a Primeira Pintura de conteúdo não é ainda o LCP (o conteúdo mais importante).

O LCP de uma página é o tempo em milissegundos ou segundos que demora para o seu aparecimento na tela.

Existe um cálculo para isso, mas penso que não vem ao caso. Tendo em vista que, as ferramentas para testes (que indicarei abaixo), fazem esta medição e o cálculo é complexo.

FID – First Input Delay (Primeiro Atraso de Entrada)

Esta métrica do Core Web Vitals é um pouco mais difícil de entender.

Mas, apesar disso, vou dar exemplos que ajudarão a compreender.

FID - Primeiro Atraso de Entrada

O FID é utilizado para avaliar o tempo para a interatividade do usuário.

Podemos definir da seguinte maneira:

O FID mede o tempo, desde quando um usuário interage pela primeira vez com a página (por exemplo: um clique, rolagem de página etc.), até o momento em que o navegador é realmente capaz de responder a esta interação.

Talvez você já tenha acessado um site, clicou em um botão ou em um link, e percebeu uma demora para a sua ação responder.

É exatamente isso que mede o FID: o tempo em milissegundos que demora para esta resposta.

Porém, considere que o FID não é o tempo para a página ficar totalmente interativa (TTI).

O TTI é um indicador do Google Lighthouse, que não foi incluído no Core Web Vitals.

CLS – Cumulative Layout Shift (Mudança Cumulativa de Layout)

Mudança Cumulativa de Layout (CLS), mede a mudança de posição dos elementos de uma página, enquanto ela é carregada

CLS - Mudança Cumulativa no Layout

Esta é uma métrica, para avaliar a estabilidade visual de páginas.

Porém, para entender melhor, segue um exemplo visual:

Espero que tenha sido possível perceber, que quando ocorre mudança cumulativa no layout, os elementos mudam de posição, conforme são carregados.

O CLS  não é medido em tempo, como os outros indicadores, mas sim em proporção.

Há um cálculo um tanto sofisticado para medir o CLS.

Mas, você pode consultar os detalhes técnicos da medição do CLS.

INP – Interaction to Next Paint (Interação com Próxima Exibição) – Entra em vigor em 12/03/2024

O FID está com os dias contados. Em 12/03/2024 ele será substituído por outra métrica: INP (Interação com Próxima Exibição.

Será uma métrica bem mais exigente! Enquanto o FID mete o tempo de resposta somente da primeira interação do usuário, o INP medirá todas as interações do usuário na página. Antes, garantindo uma primeira interação adequada, as demais interações não influenciavam no Core Web Vitals. Agora, por outro lado, os sites precisam garantir boa usabilidade na interação de ponta a ponta.

Interação com Próxima Exibição (INP)

Será registrado o maior atraso de interação.

Qual será o impacto real do INP no Core Web Vitals?

O Google já está reportando o INP no Page Speed Insights, portanto, considere este caso real:

INP comparado com FID

Perceba que, considerando o FID deste site real, percebemos que existe uma certa “folga”, ou seja, não está próximo do limite indicado. Por outro lado, o INP está bem no limite: em 185ms.

Este é apenas o exemplo de um site com milhares de acessos por mês, dessa não representa o conjunto. Mas, pode indicar que será mais difícil cumprir a meta do INP, se comparado com o FID.

Tipos de dados do Core Web Vitals?

Vou explicar sobre os dois tipos de dados utilizados para analisar as métricas do Core Web Vitals.

Isso é importante, pois existem limitações e particularidades das ferramentas utilizadas para a análise.

Dados de Campo e Dados de Laboratório Core Web Vitals

Dados de Laboratório

Uma das formas de analisar as métricas do Web Vitals, é simular uma situação de acesso real a um site.

Nesta simulação são utilizados: uma conexão com a internet, uma localização do servidor e um dispositivo (desktop ou mobile), previamente especificados.

O relatório obtido através desta simulação é o que chamamos de “dados de laboratório”.

Eu chamo de “simulação”, pois não é um acesso de um usuário real que está sendo avaliado. Mas, uma situação controlada em um laboratório de teste.

Dados de Campo

Por outro lado, os “dados de campo” coletam informações reais de usuários, que acessaram um determinado site.

Com os dados de campo, está sendo avaliado o comportamento de carregamento de uma página, baseado nas tecnologias de usuários reais.

Para isso, o Google utiliza-se de dados de usuários, coletados quando utilizam o Google Chrome e outros meios.

Qual dos dados é o melhor?

Na minha percepção, é claro que os dados de campo são melhores que os dados de laboratório. Além disso, o Core Web Vitals, propriamente dito, só existe em dados de campo do Google.

Todavia, devido a algumas limitações nas ferramentas que testam o Core Web Vitals, muitas vezes, precisamos utilizar os dados de laboratório.

Além disso, frequentemente, os dados de laboratório podem fornecer mais detalhes sobre a situação e permitir ações de melhorias mais focadas.

Mas, vamos entender um pouco mais sobre isso na parte que eu trato sobre as ferramentas de teste.

Fatores que influenciam os dados do Core Web Vitals

Em primeiro lugar, é importante compreender que são muitos os fatores que influenciam estes indicadores do Google.

Não somente os indicadores, como também, a experiência real de um usuário.

Temos dois conjuntos de fatores!  Um relacionado aos usuários que acessam um site e o outro que parte de nós, proprietários ou desenvolvedores de websites.

Fatores que dependem dos usuários

Quando uma pessoa acessa o seu site ou a sua loja virtual, ela esta utilizando uma determinada tecnologia para fazer o acesso.

Essa tecnologia utilizada pelos usuários, influência os indicadores do Core Web Vitals.

Porém, em relação a isso, não temos nenhum controle.

Dispositivo utilizado

Um usuário pode acessar o seu site de um celular ou de um desktop, o que muda completamente a sua experiência de acesso e a velocidade de carregamento.

Ele pode possuir um dispositivo (celular ou computador), com bom desempenho ou com desempenho péssimo.

Se a capacidade do dispositivo (processamento e memória RAM), utilizada pelo usuário é ruim. O seu site vai carregar mais lentamente.

Conexão utilizada no acesso

O mesmo vale para a conexão utilizada quando o usuário está acessando o seu site.

É complemente diferente acessar um site com conexão Wi-Fi e conexão 3G.

Fatores que dependem dos proprietários de sites e lojas virtuais

Este é o tema central deste artigo: melhorar os fatores que dependem de nós.

Fatores Core Web Vitals que dependem dos proprietários de sites

Hospedagem do site ou loja

Mais abaixo, darei detalhes sobre como isso influência no Core Web Vitals e na experiência do usuário.

Todavia, é um fator que está em nosso controle melhorar.

Plataforma de criação

Algumas plataformas para a criação de sites ou plataforma e-commerce, são projetadas para o melhor desempenho.

Já outras, podem utilizar tecnologias defasadas ou práticas de desenvolvimento já ultrapassadas, o que pode ser um empecilho para a melhoria do desempenho.

Temas para WordPress

Para usuários do CMS WordPress, existem diversas opções de temas para serem utilizados.

Alguns temas são desenvolvidos pensando em SEO e desempenho. Por outro lado, outros ainda possuem uma estrutura menos amigável para o Core Web Vitals.

Podemos dizer que, alguns temas carregam mais rapidamente, já outros nem tanto.

Conteúdo inserido nas páginas

Alguns tipos de conteúdo que inserimos nas páginas de nossos sites ou lojas virtuais, podem ser prejudiciais para o desempenho.

É necessário conhecimento e planejamento para entender quais são esses conteúdos e entender também como inserir de modo correto em suas páginas.

Otimizações para o desempenho

São técnicas e processos que aplicamos para melhorar as métricas do Core Web Vitals.

Tratam-se de recursos técnicos que podemos aplicar para melhorar cada um dos indicadores e conseguir melhor desempenho.

Tecnologia dos usuários e nossas otimizações

Quanto mais “fraca” for a tecnologia que os usuários utilizam para acessar o seu site ou loja, mais você precisa otimizar para o desempenho.

Google Analytics, pode fornecer informações sobre as tecnologias utilizadas pelo público que acessa o seu site.

Mas, vamos imaginar o seguinte: você chegou a conclusão que 80% dos usuários que acessam o seu site, o fazem através de uma conexão 3G.

Além disso, percebeu que utilizam modelos de dispositivos móveis mais antigos.

Nesta situação, torna-se claro que o seu website precisa carregar muito rapidamente para compensar as tecnologias utilizadas pelos usuários.

Por outro lado, se o seu público utiliza celulares de última geração e conexão Wi-Fi, a sua preocupação com otimização do desempenho, pode ser menor.

Como medir o Core Web Vitals?

Esclarecida a diferença sobre tipos de relatórios para a análise das métricas do Core Web Vitals, vamos entender como testar.

PageSpeed Insights

PageSpeed Insights é a ferramenta oficial do Google para medir, não somente o Core Web Vitals, mas também o Lighthouse.

Basta inserir a URL do seu site no espaço indicado para efetuar o teste:

Page Speed Insights

Dois tipos de relatórios podem ser apresentados:

1. Relatório com dados de campo

Resultado Core Web Vitals

Conforme é possível observar na imagem, está sendo apresentado o relatório com os dados de campo.

Ou seja, o Google está reportando dados reais de usuários que acessaram o site.

Além dos “dados de campo”, mais abaixo, também são apresentados os dados de laboratório.

Perceba ainda que, são exibidas as “Principais métricas da Web” (Core Web Vitals), com uma tag azul.

2. Relatório com dados de laboratório

Por outro lado, pode acontecer que o Google não tenha dados de campo suficientes.

Page Speed Insights

Neste caso, só aparecem os “dados de laboratório”.

Acontece, porém, que o FID (Primeiro Atraso de Entrada) e agora o INP, não são métricas calculadas em laboratório. Pois, como vimos, é uma métrica que precisa de um usuário real.

Por outro lado, você consegue as informações de LCP e CLS calculadas em laboratório.

Então, o que fazer se o seu site não tem dados de campo suficientes para o Core Web Vitals?

Você deve utilizar o TBT (Total Blocking Time), ou Tempo Total de Bloqueio, que é calculado em laboratório. Esta métrica tem sido muito útil para simular o FID, mas precisamos avaliar se é útil para simular o INP.

Por hora, o TBT (métrica do Google Lighthouse), pode substituir o FID para dados de laboratório.

O FID e o TBT não são métricas exatamente iguais, mas considerando que o FID não pode ser calculado em laboratório, o TBT é um substituto bastante apropriado devido serem métricas parecidas.

Além disso, melhorar o TBT, também melhora o FID. Pois, o mal desempenho desses dois indicados, tem praticamente a mesma origem.

Por fim, é importante lembrar duas coisas:

1) O PageSpeed Insights, calcula as métricas em um servidor nos Estados Unidos (muito provavelmente).

Por este motivo, se os usuários do seu site encontram-se no Brasil, o relatório (com os dados de campo), não será real, devido o tempo de resposta do servidor.

2) Supomos também, que os dados de laboratório sejam realizados com uma conexão 3G para testes mobile.

Isso pode não ser a realidade do público que acessa o seu site.

GTmetrix para medir o Core Web Vitals

GTmetrix é uma ferramenta que mede o Core Web Vitals e o Google Lighthouse em laboratório.

GTmetrix Core Web Vitals

E por este motivo, também não reporta o FID (Primeiro Atraso de Entrada), assim como os dados de laboratório do PageSpeed Insights. E assim, devemos usar o TBT para o substituir.

Por outro lado, é a ferramenta mais completa e mais utilizada por proprietários de sites e lojas que realmente desejam melhorar o desempenho.

O relatório do GTmetrix é bastante rico, permitindo entender o problema de desempenho com mais profundidade.

Além disso, também permite selecionar a localização do servidor de teste. Isso é realmente importante, pois escolhendo, por exemplo, o servidor de São Paulo, o relatório é mais real.

Para utilizar os recursos da ferramenta, é necessário criar uma conta grátis, que dá direito a 50 testes por semana.

Existe também o plano pago, que permite realizar testes em dispositivos móveis e conexões 3G e 4G.

Dicas gerais para melhorar o Core Web Vitals?

Há algum tempo, efetuar melhorias no Core Web Vitals, exigia conhecimentos avançados em linguagens de programação.

Porém, para usuários da plataforma WordPress, tornou-se muito mais fácil.

Para usuários de outras plataformas, na grande maioria das vezes, precisará ainda desses conhecimentos.

Nesta parte, eu vou abordar dicas gerais, que melhoram o desempenho de um modo geral.

Em seguida, entro nos detalhes de cada métrica do Core Web Vitals.

Hospedagem: o primeiro sinal de velocidade!

Se a hospedagem do seu site é de baixo desempenho, mesmo com otimização, pode ser mais difícil melhorar significativamente a velocidade.

Hospedagem Melhora o Core Web Vitals

Se este for o seu caso, é necessário um cuidado maior na otimização para o Core Web Vitals.

Mas, mesmo nesta condição, é possível melhorias com a otimização adequada.

Por outro lado, hospedagem de alta performance, exige um investimento maior e muitas vezes não é viável para muitos proprietários de sites.

Nesta seção, vou esclarecer algumas questões importantes sobre como a hospedagem se relaciona com o desempenho do Core Web Vitals.

Servidor no Brasil garante melhores índices no Core Web Vitals?

Por um lado, o Google recomenda “reduzir o tempo de resposta do servidor”. E uma das formas de conseguir isso, é hospedar o site em um servidor no Brasil (mais próximo ao seu público).

Por outro lado, um servidor no Brasil cuja capacidade de processamento seja ruim, não resolve o problema.

Em suma, somente ter um servidor no Brasil, não garante desempenho superior nas métricas do Core Web Vitals.

Na verdade, eu já realizei teste com duas hospedagens, uma com servidor localizado nos EUA e outra localizada no Brasil. Ambas, com as mesmas configurações básicas e o mesmo conteúdo de página.

A conclusão foi que, apesar de o servidor localizado no Brasil ter um tempo de resposta menor, o desempenho foi o mesmo.

Core Web Vitals e hospedagem compartilhada

Sabemos que hospedagem compartilhada é a mais utilizada pelos proprietários de sites e lojas online.

Contudo, sabemos também, que é um tipo de hospedagem, mais básica, com desempenho menor.

Mas, com as otimizações corretas é possível melhorar bastante as métricas do Core Web Vitals.

Enfim, é possível contornar a distância do servidor com cachê de borda do Cloudflare e códigos do site, altamente otimizado para a velocidade.

O mundo ideal da hospedagem de sites

O mundo ideal, é hospedar o seu site ou loja em um servidor localizado no Brasil e ainda que possua alto desempenho.

Uma hospedagem premium para WordPress é a Kinsta. Trata-se de um servidor localizado em São Paulo com processador Intel Cascade Lake (projetado para desempenho).

Porém, este “mundo ideal da hospedagem” custa dinheiro. Exige um investimento bem maior.

Utilize uma plataforma otimizada para o Core Web Vitals, ou que permita melhorias

Existem diversas plataformas para a criação de sites, bem como, para a criação de lojas virtuais.

Todavia, a grande maioria ainda não está otimizada para o Core Web Vitals.

Além disso, a maioria das plataformas só permite melhorias alterando o código fonte, o que exige conhecimentos técnicos, bastante sofisticados.

Assim, o WordPress se destaca pelas opções e pela facilidade na otimização.

Otimização de imagens é um requisito básico

Otimizar imagens é essencial para diminuir o tamanho total da página e melhorar a velocidade de carregamento, de um modo geral.

Além disso, este processo está ao alcance de proprietários de sites em qualquer plataforma. Confira também o artigo SEO para Imagens.

As imagens podem ser grandes vilãs quando se refere ao Core Web Vitals, por isso, é indispensável realizar a otimização das imagens webpara a redução do seu peso.

Como melhorar o LCP, a métrica de velocidade do Core Web Vitals?

Vou explicar as otimizações mais importantes para melhorar o tempo do LCP.

Alguns são mais técnicas e outras mais fáceis de serem compreendidas e aplicadas.

Vamos começar pelas mais fáceis!

Utilizar poucos códigos de terceiros

Primeiramente, é importante entender que códigos de terceiros são vitais para diversas funcionalidades dos nossos sites.

Os códigos do Google Analytics e do Pixel do Facebook, por exemplo, são um caso típico desses códigos.

Porém, além deles, quais outros códigos você utiliza em seu site ou loja online?

Cada uma das ferramentas que você utilizar, será necessária a inclusão de códigos.

No entanto, esses códigos prejudicam a velocidade do carregamento da página (o LCP).

Portanto, selecione muito bem quais ferramentas são realmente essenciais para o seu site ou seu negócio.

Pré-conecte os códigos de terceiros

Para acelerar a conexão com códigos de terceiros, você pode ajudar utilizar “preconnect” no atributo rel do link.

Por exemplo:

Rel Preconnect para códigos de terceiros

Essas são as duas requisições necessárias para carregar o Pixel do Facebook.

Com a rel “preconnect” instruímos o navegador para iniciar a conexão com essas URLs, antes de realmente serem necessárias para a página.

As fontes do Google podem ser prejudiciais para o Core Web Vitals

São fontes bonitas, que enriquecem o design de sites.

Mas, apesar disso, elas prejudicam dois indicadores do Core Web Vitals: o LCP e o TBT.

Em primeiro lugar, porque a sua utilização gera duas requisições adicionais para:

https://fonts.gstatic.com/

https://fonts.googleapis.com/

Então, as dicas sobre este assunto são:

1) Pense se realmente deseja utilizar fontes do Google.

2) Utilize apenas uma fonte do Google.

3) Utilize pouco “peso” (espessura), de fonte. Por exemplo, peso 400, peso 500, etc.

Além disso, sempre que possível, utilize no atributo “font-display” o valor: “swap”.

Isso fará que seja exibida uma fonte padrão do sistema, antes de completar o download e exibição da Fonte Google.

Existe ainda, a opção de hospedar as fontes do Google localmente em seu servidor.

Algumas vezes melhora o desempenho, porém, outras não. Dependendo da situação melhora o LCP, mas piora o TBT. Vale a pena testar.

Evite utilizar ícones na tela de pintura

Os ícones são arquivos de fonte e tem o mesmo potencial de prejudicar o carregamento da página, que as fontes do Google.

Sempre que possível, substitua os ícones padrão por arquivos de imagens (ou SVG), que podem ser baixados aqui.

Pré-carregar os principais recursos melhora muito o LCP

Utilize a rel do link “preload” para carregar conteúdo acima da dobra antes dos demais.

Exemplo:

É um recurso útil para diversos tipos de arquivos, mas utilizar isso para imagens que estão acima da dobra, ajuda bastante no tempo de carregamento do LCP.

Lazy load de imagens é importante para o Core Web Vitals

Este recurso faz com que as imagens só sejam carregadas quando necessárias para a exibição.

lazy load “alivia” o carregamento inicial da página.

Por exemplo, quantidade de imagens carregadas inicialmente sem lazy load é expressiva (22 imagens):

Requisições sem lazy load de imagens

Por outro lado, veja a quantidade de imagens carregadas inicialmente com lazy load ativado (apenas 6 requisições de imagens), somente as necessárias para a exibição do conteúdo acima da dobra:

Requisições com Lazy Load de Imagens Core Web Vitals

Portando, aplique o lazy load para todas as imagens abaixo da dobra.

Elimine recurso que impede a renderização

As linguagem de programações CSS e Java Script, bloqueiam a renderização da página (exibição do conteúdo).

Isso porque, quando existem estes códigos, o navegador os analisa, antes de continuar a renderização.

Dessa forma, atrasa a aparição do conteúdo no navegador. Portanto, prejudica o tempo de LCP.

Algumas técnicas podem ser utilizadas para eliminar esses recursos que impedem a renderização.

1. Diminuir CSS e Java Script não utilizados

Em todas as plataformas, existem códigos de programação em CSS ou Java Script que não são utilizados efetivamente.

Para usuários de WordPress, existem diversas opções para reduzir o CSS não usado. Mas para Java Script é necessário realizar manualmente uma limpeza de ativos JS.

Você pode visualizar o tamanho do problema para o seu site, acessando o recurso de inspeção de código do Google Chrome.

Na imagem a seguir, você pode ter uma ideia sobre a quantidade de códigos não utilizados em um site (barra vermelha e coluna “Unused Bytes”).

CSS não usado e Java Script não usado

2. Implantar o CSS crítico

Os arquivos CSS são responsáveis pelo estilo da sua página.

Porém, muitos desses estilos CSS não são prioritários para a renderização da página.

Já indiquei que o conteúdo acima da dobra (sem rolar a página) é o conteúdo crítico para a percepção de velocidade de carregando e para o LCP.

Da mesma forma, o CSS crítico é o código de estilo estritamente necessário para a exibição do conteúdo acima da dobra.

3. Adiar a execução do Java Script (JS) – (defer)

O Java Script é uma linguagem de programação indispensável para páginas de sites e faz coisas incríveis.

Mas, é um recurso que bloqueia a renderização do conteúdo.

Isso acontece, pois quando é encontrada a tag:

<script src=’https://uxweb.com.br/wp-content/plugins/wordfence/js/wfi18n.1623076348.js?ver=7.5.4′ id=’wfi18njs-js’ defer></script> <script src=’https://uxweb.com.br/wp-includes/js/jquery/jquery.min.js?ver=3.6.0′ id=’jquery-core-js’ defer></script> <script src=’https://uxweb.com.br/wp-includes/js/jquery/jquery-migrate.min.js?ver=3.3.2′ id=’jquery-migrate-js’ defer></script>

Por fim, o atributo defer fará com que (em uma sequência de carregamento de recursos), os arquivos Java Script sejam carregados por último.

Parece difícil demais tudo isso?

Você pode estar pensando que estas ações são tarefas somente para programadores…

Mas, na verdade, com o WordPress é possível fazer tudo isso com aplicações fáceis e sem conhecer programação.

Eu já mencionei o Curso Acelera WP; que ensina técnicas para aumentar o desempenho, sem precisar programar absolutamente nada.

Como melhorar o FID, o indicador de interatividade do Core Web Vitals?

O FID (Primeiro Atraso de Entrada), métrica do Core Web Vitals, é fortemente impactada pelo Java Script. Assim como, o TBT (Tempo Total de Bloqueio), indicador do Google Lighthouse.

O tempo gasto na execução do Java Script, impede os usuários de interagirem com a página.

Não é somente o JS que causa bloqueio de interatividade, mas é o principal recurso que prejudica o FID e o TBT.

A métrica do TBT é bastante útil para entender como este bloqueio realmente ocorre.

Para o Google Lighthouse, qualquer execução de tarefa (por exemplo, a execução de um script Java), que demore mais que 50 ms, é uma tarefa que causou bloqueio ao usuário.

Por fim, já que entendemos a causa do problema, vamos às dicas.

Desempenho do servidor de hospedagem afeta o Core Web Vitals

Até o momento, eu não encontrei em nenhuma documentação ou artigo, que aborde a relação entre o desempenho do servidor e interativa (FID e TBT).

Porém, tenho duas razões para supor que a melhoria dessas métricas também é influenciada pela capacidade do servidor de processar rapidamente as solicitações:

1) Tanto o FID, quanto o TBT, são métricas avaliadas em milissegundos. Se envolve “tempo”, também envolve a velocidade de processamento do servidor.

2) Já percebi, quando realizei testes de Core Web Vitals para vários sites, que o Tempo Total de Bloqueio oscila de teste para teste. E, muitas vezes, é notório o aumento do TBT quando há uma sobrecarga no servidor.

Enfim, ter um servidor com bom desempenho e estável pode ajudar.

De qualquer modo, isso não é tudo. São necessárias algumas otimizações para lidar com essas tarefas que geram bloqueios de interatividade.

Google Fonts e ícones

Além de prejudicar o LCP, como mencionei acima, também podem gerar maior tempo de TBT.

Assim, todas as dicas acima sobre este tema, também valem para a interatividade dos usuários.

Porém, pré-carregar fontes com o atributo preload, conforme indicado acima, ajuda no LCP, mas pode piorar a interatividade (FID e TBT).

Por isso, o uso moderado de tipos de fontes google e ícones é sempre a melhor saída.

Código de terceiros no cabeçalho (head)

Praticamente todas as ferramentas que costumamos utilizar em nossos sites, pedem para inserir o código deles no cabeçalho do site.

Você sempre verá nas instruções de instalação:

“Insira o código entre as tags <head> e </head>”. Ou seja, no cabeçalho do site.

Minha orientação é não inserir onde eles indicam:

Dê preferência em inserir os códigos de terceiros no rodapé, entre as tags.

Normalmente funcionam bem, mas faça um teste para ter certeza de que estão funcionando bem para a sua utilização específica.

Esta ação pode ajudar a diminuir o TBT (Tempo Total de Bloqueio).

Atrasar Java Script

Eu falei mais acima sobre “adiar Java Script”, que pode melhor o LCP.

Apesar de os nomes serem parecidos “atrasar JS” é bem diferente de “adiar JS”.

Eu vou explicar a diferença, mas antes considere um caso interessante:

Eu realizei um teste no GTmetrix de uma página inicial, de uma loja em WooCommerce.

Conforme você pode ver abaixo, foram 44 solicitações de arquivos Java Script.

Requisições sem Java Script

Pode parecer uma quantidade enorme de arquivos JS. Por outro lado, esta quantidade de solicitações é comum em lojas virtuais.

Afinal, diversas funcionalidades próprias de e-commerce utilizam JS.

Apresento abaixo o TBT (Tempo Total de Bloqueio), para este teste:

TTB Tempo Total de Bloqueio sem Atrasar Java Script

É um valor bastante alto! A meta é apenas 150 ms.

Esta é uma situação, aparentemente, difícil de contornar.

Mas, com o recurso “Atrasar Java Script” é possível resolver este grande problema de desempenho.

O que faz o “Atrasar JS”?

Ele só carrega os arquivos Java Script após alguma interação dos usuários (cliques, rolagem de página, toque na tela etc.). O conceito é parecido com o lazy load de imagens.

Isso evita que o Java Script bloqueie a interatividade dos usuários.

Veja a diferença brutal de desempenho e quantidade de arquivos:

TTB - Core Web Vitals

Apenas um arquivo Java Script (essencial), foi carregado e 0 (zero) ms de TBT.

Problemas com o Atraso de Java Script

Isso mesmo! Nem tudo é perfeito.

O atraso de Java Script, tem um potencial grande de causar alguns problemas em seu site.

Não é possível numerar todos os problemas, mas por exemplo:

  • O menu mobile pode não funcionar adequadamente;
  • “Quebrar” algum elemento do site;
  • Efeitos de movimento podem parar de funcionar, ou não funcionar no momento certo.

Inclusive, consulte este caso: WP Rocket 3.9.2 corrige problemas com animação do Elementor

Por outro lado, existe um problema complementar relacionado aos códigos de terceiros.

Quando é implantado o atraso do Java Script, inclusive scripts do Google Analytics e Facebook, são carregados somente após a interação do usuário.

Se um usuário entrar no seu site e fechar a página antes da interação, esses scripts não vão registrar o acesso do usuário porque simplesmente não foram carregados.

Como melhorar o CLS (Mudança Cumulativa de Layout)

Chegamos, enfim, ao último indicador do Core Web Vitals.

Vou indicar as principais causas dessa experiência ruim para os usuários e como corrigir.

Defina explicitamente as dimensões das imagens

Este é o problema mais comum que prejudica o CLS.

Quando carregamos uma imagem em nosso site, devemos definir no código HTML as dimensões (largura e altura), explicitamente das imagens.

Dessa forma, antes de as imagens serem efetivamente carregadas, o espaço correto está reservado na tela para ela.

Por exemplo, abaixo podemos ver o código de uma imagem onde “width” e “height” estão especificadas como 800px e 450px.

width=”800″ height=”450″
src=”https://uxweb.com.br/wp-content/uploads/2021/08/otimizar-imagens-web-para-google-destaque.jpg” alt=”Otimizar Imagens Web para o Google”

Pode ocorrer que a plataforma utilizada para a criação do seu site, já faça isso por padrão.

Google Fonts e CLS

As fontes do Google, também podem gerar Mudança Cumulativa no Layout durante o seu completo carregamento.

Portanto, utilizar para o atributo “font-display” o valor: “swap” (que carrega a fonte padrão do sistema), pode ajudar a melhorar também o CLS.

Atenção ao conteúdo acima da dobra

O CLS é analisado acima da dobra, na janela de visualização.

Dessa forma, tenha uma atenção especial ao conteúdo que você insere nesta parte do seu site.

Dificuldade de implantar melhorias no Core Web Vitals

Este é um tema que mencionei rapidamente, mas precisamos entender um pouco mais sobre os caminhos de melhorias do Core Web Vitals.

Usuários de WordPress

Para usuários da plataforma WordPress, implementar essas melhorias é bem mais simples.

Existem diversas ferramentas que tratam os aspectos mais técnicos sem grandes dificuldades.

Por exemplo, o plugin WP Rocket e o plugin Perfmatters juntos, podem ajudar para a grande maioria das melhorias de desempenho.

Além disso, o curso Acelera WP indica todo o roteiro e explica detalhadamente como alcançar melhoria efetiva.

Não usuários de WordPress

Nesta categoria, incluem usuários de todos as outras plataformas para a criação de sites e lojas online.

Mas, é claro que, neste universo enorme, existem plataformas bem diferentes entre si.

Algumas delas já tem como padrão as melhores práticas para o Core Web Vitals, outras não.

Por outro lado, algumas permitem a edição do código fonte para realizar as melhorias, mas com certeza, para fazer isso será necessário um programador experiente.

Valores esperados para as métricas do Core Web Vitals?

Eu deixei esta parte por último, sobretudo porque, a esta altura imagino que você já tenha executado testes nas ferramentas indicadas e já visualizou os valores esperados para cada métrica.

Porém, vou explicar sobre estes valores esperados e algumas particularidades.

Valores diferentes para mobile e desktop

Para cada métrica do Core Web Vitals, os valores são diferentes para mobile e desktop.

O Google entende que conexão mais lenta em celulares, deve haver uma tolerância maior que em desktop.

Por exemplo, o valor esperado para o LCP em desktop é de 1,2 segundos, já em mobile é de 2,5 segundos.

Abaixo é possível visualizar o score oficial do Google para mobile.

Score Core Web Vitals

Page Speed Insights e GTmetrix

O Page Speed Insights do Google mostra o seu desempenho (baseado nos valores esperados), para mobile e desktop separadamente, o que é bem interessante.

Mas, os dados de laboratório não são adequados devido a localização do servidor de teste do Google.

Por outro lado, o GTmetrix apresenta os valores esperados para Desktop. Mesmo que você seja um usuário premium e realize um teste com dispositivo mobile e conexão 4G, os valores apresentados continuam sendo para Desktop.

Na última parte, logo mais, vou apresentar uma calculadora para você conhecer os valores esperados para mobile e desktop.

Valores esperados para o Core Web Vitals em laboratório

Mobile: 

LCP: 2,5 segundos

TBT: 200 milissegundos

CLS: 0,10

Desktop

LCP: 1,2 segundos

TBT: 150 milissegundos

CLS: 0,10

Calculadora do Lighthouse

Considerando que as métricas de laboratório do Core Web Vitals, também estão presentes nas métricas do Google Lighthouse, é possível utilizar a calculadora do Lighthouse.

Acesse a calculadora, e altere os valores para o mobile e desktop para entender melhor os valores esperados para os dois tipos de dispositivos.

Conclusão

Conhecemos todos os detalhes dessa métrica importante para o sucesso do seu negócio online.

Também apresentei os fatores que podem contribuir para a melhoria de cada métrica.

Eu espero que essas informações, ajudem você a melhorar a experiência dos usuários que acessam o seu site ou loja online.

Do mesmo modo, também desejo que seu site alcance um alto desempenho em velocidade e geração de negócios.

Por último, penso que a cada dia a exigência cresce para entregar um site ou loja online com excelente desempenho e experiência dos usuários aprimorada.