Como Melhorar os Core Web Vitals

Os Core Web Vitals (CWV) constituem um conjunto de métricas que auxiliam o Google na análise do desempenho geral das páginas web.

As Core Web Vitals (CWV) são um conjunto de métricas que ajudam o Google a avaliar o desempenho geral das páginas da web.

Estas três métricas são:

1. Largest Contentful Paint (LCP)
2. First Input Delay (FID)
3. Cumulative Layout Shift (CLS)

Cada uma das três Core Web Vitals representa um aspeto distinto da experiência do utilizador.

Juntamente com outras web vitals, LCP, FID e CLS fazem parte dos sinais de experiência de página do Google que são usados para fins de classificação.

As CWV medem e avaliam três aspetos das páginas web: carregamento, interatividade e estabilidade visual.

A primeira Core Web Vital é LCP (Largest Contentful Paint). A métrica LCP é usada para medir o tempo que a maior imagem ou o maior bloco de texto dentro de uma viewport predefinida leva para se tornar visível a partir do momento em que uma página começa a carregar. O benchmark atual do Google para Largest Contentful Paint é inferior a 2,5 segundos.

A segunda Core Web Vital do Google é FID (ou First Input Delay). A métrica FID avalia a capacidade de resposta da página e mede o tempo que leva para uma página responder à entrada do utilizador (clique, toque ou pressionamento de tecla). Um bom First Input Delay é considerado inferior a 100 milissegundos.

Por último, mas não menos importante, a métrica CLS mede a estabilidade visual de uma página. Se as páginas web tiverem elementos instáveis durante o carregamento da página, haverá uma pontuação CLS fraca. Uma boa pontuação Cumulative Layout Shift deve ser igual ou inferior a 0,1.

Como as Core Web Vitals se correlacionam com impressões e cliques orgânicos

Se ler algum dos estudos de caso sobre Core Web Vitals, encontrará muitas informações contraditórias sobre o quanto uma boa pontuação CWV se correlaciona com impressões e cliques orgânicos. Coloquei deliberadamente esta seção no início do estudo para mostrar como a otimização das CWV funcionou para nós e por que a tornamos uma das nossas principais prioridades para este ano.

O relatório CWV na Google Search Console tem um limite de 3 meses nos dados disponíveis. Portanto, para monitorizar o nosso progresso de forma mais conveniente do que as ferramentas do Google, criámos uma integração entre a API da Google Search Console e o PowerBI da Microsoft. Desta forma, conseguimos combinar todos os dados num único painel e recolher todos os dados históricos sem limitações.

Ponto de Partida

Todo o processo de otimização das CWV começou com a verificação da nossa situação atual na Google Search Console.

Além da Search Console, pode usar o PageSpeed Insights do Google para verificar as CWVs no seu site. No entanto, é importante entender a diferença fundamental entre os dois e como eles avaliam as CWVs.

A Search Console baseia-se em dados de campo, ou seja, nos dados do Chrome User Experience Report (CrUX), o que significa que as pontuações CWV são baseadas em como os utilizadores reais vivenciam as páginas. Esses dados são atualizados a cada 28 dias, então você terá que esperar todo esse tempo antes de poder ver os resultados das melhorias de desempenho.

O PageSpeed Insights determina as pontuações com base em dados de laboratório, uma simulação do que o Google considera ser um utilizador médio da web. Pode verificar qualquer página a qualquer momento.

Portanto, o PageSpeed Insights é útil quando você deseja ter uma estimativa rápida do que está acontecendo com as CWVs numa determinada página.

Como melhorámos as métricas das Core Web Vitals

Quando soubemos pela primeira vez das três Core Web Vitals, a sua otimização parecia uma tarefa trivial. Consultámos o relatório do Lighthouse, PageSpeed Insights e Search Console e seguimos as recomendações que nos foram dadas. O que poderia dar errado?

Apenas algumas semanas depois, percebemos que poderiam haver centenas de problemas que levavam a pontuações CWV fracas. Portanto, para compartilhar a nossa experiência e poupar-lhe muito tempo, fiz o meu melhor para reunir tudo o que foi feito num formato facilmente compreensível.

Servidores e CDNs geoespecíficos

– Métricas afetadas: TTFB, LCP –

O tempo de resposta do servidor é crucial e pode anular todos os esforços de otimização de CWV se não for tratado antecipadamente. Uma das métricas que ajudam o Google a avaliar o tempo de resposta de um servidor chama-se Time to First Bite (TTFB) e, embora não seja uma Core Web Vital, faz parte de outras Web Vitals.

O TTFB mede o tempo entre o momento em que um utilizador chega a um site e o momento em que o primeiro “mordisco” de informação é carregado. Geralmente, o TTFB deve ser inferior a 600 ms.

Um
TTFB fraco afeta negativamente o LCP, pelo que torná-lo o mais baixo possível é fundamental. Na maioria dos casos, a pontuação TTFB pode ser melhorada simplesmente mudando para um provedor de hospedagem melhor. No entanto, não foi esse o caso de link-assistant.com.

Link-assistant.com tem um público global, e o Google utiliza dados de monitorização de utilizadores reais (RUM) para determinar se uma página específica cumpre os critérios das Web Vitals. Isto significa que, se o TTFB for bom para, por exemplo, os EUA e mau para a Índia, este último acabará por baixar a pontuação final do TTFB.

Antes das CWVs se tornarem tão importantes, tínhamos apenas uma localização de servidor, nos EUA. Obviamente, isso não era suficiente para um site que tinha um público multinacional.

Isso levou-nos a supor que os volumes de tráfego da Índia eram muito altos para um único servidor. Então, muito provavelmente o servidor estava sobrecarregado, o que resultava num TTFB fraco para todas as localizações que não a Índia. Adicionámos então dois novos servidores: um em Osaka e outro em Singapura.

Como os servidores adicionais foram adicionados há apenas cerca de uma semana, teremos de esperar que os resultados finais se manifestem. No entanto, a melhoria já é visível para a maioria das localizações.

O mesmo problema com o TTFB foi observado nas Américas. Não só as pontuações TTFB não melhoraram para as localizações nos EUA, como também houve tempos de resposta do servidor enormemente altos para os utilizadores no Brasil e no Chile.

Aqui tirámos algumas conclusões. Primeiro, nosso tráfego orgânico nas Américas é tão pesado quanto na Índia, então dois servidores provavelmente não conseguem lidar com o fluxo sem comprometer o TTFB.

Segundo, um dos nossos servidores estava no Wowrack. Nossa equipe de desenvolvimento descobriu que este servidor estava gravemente sobrecarregado, tinha especificações técnicas bastante antigas e estava localizado na infame zona “Internet mais antiga” na costa oeste dos EUA, o que resultou em atrasos significativos de conexão entre os utilizadores e o próprio servidor.

Como solução final, configurámos recentemente um servidor AWS adicional, pelo que agora temos três servidores nos EUA. Os resultados das melhorias que fizemos ainda não são significativos, mas iremos acompanhá-los e atualizar este estudo posteriormente.

No geral, a otimização do TTFB para link-assistant.com permitiu-nos melhorar significativamente esta métrica, o que, por sua vez, resultou numa melhoria também do LCP. Um resultado vencedor para nós.

Além disso, quando estávamos confiantes de que o TTFB estava bom o suficiente, garantimos que todos os nossos assets estáticos (imagens, CSS, Javascript) fossem carregados das CDNs em vez dos nossos servidores. Embora indiretamente, ter todos os assets estáticos nas CDNs ajuda a melhorar as pontuações TTFB, pois os servidores não ficam sobrecarregados com pedidos adicionais para carregar imagens, CSS ou JS.

Nota

Adquirir servidores adicionais é uma solução cara, que não é 100% obrigatória em todos os casos. Se o seu site atende a um público local, pode usar com segurança apenas um servidor próximo ao seu público-alvo. Se você estiver tendo problemas com o TTFB, tente soluções menos radicais, como mudar o provedor de hospedagem. Se os problemas persistirem, consulte este artigo do Google.

Adiar JS de terceiros

– Métricas afetadas: LCP –

JS de terceiros inclui tudo, desde botões de compartilhamento do Facebook até rastreadores do Google Analytics presentes numa página. Esses elementos da página consomem sempre muitos recursos de renderização. Além disso, sempre que um navegador encontra uma peça de JS assim, ele pausa a renderização do HTML até que termine de renderizar o JS. Tudo isso leva inevitavelmente a um LCP fraco.

O que fizemos foi primeiro analisar quais scripts JS de bloqueio de renderização tínhamos nas nossas páginas. Da pesquisa, vimos que os principais bloqueadores eram os botões de compartilhamento de mídia social, os blocos de comentários do Facebook, os embeds do YouTube e o Sleeknote, que usávamos para pop-ups.

Por exemplo, os vídeos incorporados do YouTube sozinhos poderiam contribuir com até 30% de economia de tempo para o LCP:

Embora não fosse obrigatório, livrámo-nos de todos os scripts de terceiros onde foi possível para obter melhores pontuações de LCP.

Ao mesmo tempo, havia páginas onde queríamos manter os botões de compartilhamento de mídia social, Sleeknote ou rastreadores do GA.

Para manter esses elementos da página sem comprometer o LCP, nós os afastamos do caminho de renderização crítico. Isso foi feito adicionando um dos seguintes atributos à tag ”
<script>:

• Async.
  Este atributo diz ao navegador para executar o script de forma assíncrona sem pausar a análise de uma página. Usamos este atributo para scripts que eram sensíveis ao carregamento tardio (Google Analytics):

Apenas para fins de completude, aqui está uma explicação visual dos atributos defer e async:

Vale a pena notar que você precisa evitar usar o atributo defere usar async para vários scripts de rastreamento. No nosso caso, perdemos quase 15% dos dados de metas no Google Analytics após mover o script de rastreamento para o final do pipeline de renderização.

Observação

A mesma técnica foi aplicada ao nosso JS personalizado. Analisamos todo o JavaScript utilizado em nossas páginas e analisamos quais partes eram irrelevantes para removê-las e quais partes precisavam ser mantidas: na maioria dos casos, fizemos com que elas fossem carregadas de forma assíncrona com o atributo async.

2. Otimização do uso de caracteres

– Métricas afetadas: LCP, CLS –

Os caracteres da web são fundamentais para um design atraente, melhor legibilidade e identidade da marca, mas também são arquivos pesados que podem levar tempo para carregar e prejudicar tanto o LCP quanto o CLS.

Se um caractere de terceiros for usado para um bloco de texto que representa o elemento LCP, a pontuação LCP pode ser negativamente afetada porque o navegador levará tempo para carregar e buscar esse caractere.

Quanto à Mudança de Layout Cumulativa (Cumulative Layout Shift), o principal problema dos caracteres de terceiros é que, antes que um determinado caractere seja carregado, o navegador exibirá um caractere do sistema. Uma vez carregado, o caractere de terceiros pode ocupar mais espaço na tela, afetando assim a estabilidade visual de uma página, causando uma mudança de layout e levando a uma pontuação CLS ruim.

Veja como uma mudança de layout se parece:

Antes que as Core Web Vitals se tornassem uma coisa, tínhamos muitos caracteres diferentes em uma única página.

Às vezes, esses caracteres nem eram usados, mas ainda eram carregados. Como você pode ver na captura de tela abaixo.

O caractere Roboto era usado exclusivamente no tooltip pop-up, que não era visível em dispositivos móveis, mas ao mesmo tempo o caractere ainda era carregado.

Também utilizávamos muitos caracteres externos, como o Google Fonts, que eram armazenados fora do nosso servidor.

Portanto, a primeira coisa que fizemos foi remover todos os caracteres externos e mudar para os do sistema (Arial, Helvetica, Verdana, Tahoma, etc.). Essa solução simples funcionou extraordinariamente bem para nós e vimos uma grande melhoria nas pontuações LCP e CLS.

Também percebemos que pode haver casos em que precisaríamos usar caracteres de terceiros. Para esses casos, tornamos o caractere auto-hospedado em nossos servidores e o pré-carregamos na seção head do HTML de uma página. Como toque final, também garantimos que não usaríamos caracteres de ícones. Estes são os caracteres usados para substituir imagens esquemáticas, como uma lupa, usada para barras de pesquisa. Esses ícones foram substituídos por imagens SVG hospedadas em nossos servidores para que o navegador não precise carregá-los de fontes externas a cada vez.

Observação Importante

Auto-hospedar caracteres da web pode não ajudar a melhorar o LCP se o seu site não usa CDN e HTTP/2. Tente experimentar tanto com caracteres auto-hospedados quanto de terceiros para ver qual solução funciona melhor para você.

3. Extrair CSS e JS críticos

– Métricas afetadas: LCP –

CSS é um recurso que bloqueia a renderização, o que significa que uma página não pode ser renderizada até que o navegador recupere e analise todos os arquivos CSS. Se o CSS for pesado, levará muito tempo para carregar, afetando diretamente a pontuação LCP.

No nosso caso, não era apenas o tamanho do CSS que utilizávamos. Antes do início do trabalho de otimização, tínhamos uma única folha de estilo CSS para todas as páginas, com mais de 70.000 linhas. O mesmo CSS pesado era carregado para cada página, mesmo que não fosse realmente usado ali.

Para resolver isso, primeiro consultamos o relatório de cobertura nas Ferramentas do Desenvolvedor do Chrome. Em seguida, examinamos todo o conteúdo desse arquivo CSS e nos livramos de todas as linhas irrelevantes. Isso nos permitiu reduzir significativamente seu tamanho real e a porcentagem de bytes não utilizados.

Observação

Para reduzir ainda mais o tamanho de nossos arquivos CSS e garantir que eles não afetem negativamente a pontuação LCP, também os submetemos a um processo de minificação de CSS.

Folhas de estilo CSS frequentemente contêm comentários, espaços em branco e quebras de linha supérfluos, e livrar-se de tudo isso pode muitas vezes ajudar a reduzir o tamanho final do arquivo em até 50%. Usamos o CSS Minifier para reduzir o tamanho do nosso CSS e o JSCompress para fazer o mesmo com o JavaScript que bloqueia a renderização.

No final, nossa equipe de desenvolvimento desenvolveu uma ferramenta dedicada, que agora lida com a minificação automaticamente.

Além disso, assim como aconteceu com o JS, não havia necessidade de carregar o mesmo CSS enorme para cada página a cada vez. Portanto, extraímos apenas os estilos necessários para a área acima da dobra de uma página específica e os adicionamos ao arquivo HTML dessa página.

4. Compressão de conteúdo HTTP

– Métricas afetadas: LCP –

A compressão de conteúdo HTTP é uma excelente prática para reduzir o tamanho dos arquivos transferidos entre o servidor e o navegador. Isso pode reduzir significativamente os tempos de carregamento das páginas e melhorar a pontuação LCP.

Para comprimir o conteúdo HTTP, configuramos a compressão gzip em nosso servidor. Isso permitiu reduzir drasticamente o tamanho dos arquivos que são enviados ao navegador, melhorando assim o LCP.

A compressão gzip é uma técnica de compressão de dados que reduz o tamanho dos arquivos sem perder informações. Isso permite transferir arquivos mais rapidamente e, portanto, melhorar o tempo de carregamento das páginas.

5. Otimização de imagens

– Métricas afetadas: LCP –

Imagens não otimizadas podem lentificar o carregamento das páginas e afetar negativamente a pontuação LCP. Portanto, prestamos atenção especial à otimização de imagens para melhorar o desempenho das Core Web Vitals.

Para otimizar imagens, seguimos as seguintes etapas:

• Redimensionamos as imagens para as dimensões reais em que precisam ser exibidas na página. Reduzir as dimensões físicas das imagens pode reduzir significativamente seu tamanho de arquivo e acelerar o processo de carregamento.
• Usamos um formato de compressão adequado para cada imagem. Por exemplo, imagens com poucos detalhes e cores sólidas foram convertidas para formatos como PNG ou SVG, que oferecem melhor compressão para este tipo de imagem. Imagens com muitas gradientes ou detalhes complexos foram convertidas para o formato JPEG, que é mais adequado para imagens complexas.
• Utilizamos ferramentas de compressão de imagem para reduzir ainda mais o tamanho dos arquivos. Essas ferramentas reduzem o tamanho dos arquivos sem perda de qualidade visual.
• Implementamos a compressão progressiva de imagens para melhorar a experiência do usuário durante o carregamento das páginas. A compressão progressiva permite a exibição de uma prévia da imagem enquanto ela é carregada, em vez de esperar o carregamento completo.

Otimizar imagens teve um impacto significativo na pontuação LCP e no tempo geral de carregamento das páginas. Notamos uma melhoria notável no desempenho após a implementação dessas otimizações.

6. Ajustes finais

Após concluir as etapas anteriores, fizemos os ajustes finais para otimizar ainda mais as Core Web Vitals.

Realizamos uma análise completa de nossas páginas para identificar quaisquer outros problemas que pudessem afetar a pontuação das CWV. Por exemplo, verificamos se havia scripts ou recursos adicionais bloqueando a renderização ou causando atrasos na interatividade.

Também verificamos o uso de cookies em nosso site e minimizamos o número de cookies usados para evitar lentidão no desempenho.

Finalmente, realizamos inúmeros testes e monitoramos constantemente o desempenho das Core Web Vitals usando ferramentas como Google Search Console, PageSpeed Insights e Lighthouse.

Resultados das otimizações das Core Web Vitals

Após realizar todas as otimizações descritas acima, notamos uma melhoria significativa nas pontuações das Core Web Vitals.

A pontuação LCP melhorou notavelmente, com tempo de carregamento inferior a 2,5 segundos. A pontuação FID diminuiu para menos de 100 milissegundos, tornando a página mais responsiva à entrada do usuário. A pontuação CLS permaneceu abaixo de 0,1, garantindo maior estabilidade visual.

Essas melhorias tiveram um impacto direto no desempenho geral das páginas. Notamos um aumento significativo em cliques orgânicos e impressões, indicando uma melhor experiência do usuário e um melhor posicionamento no ranking do Google.

A otimização das Core Web Vitals é um processo contínuo

É importante sublinhar que a otimização das Core Web Vitals é um processo contínuo. O desempenho das páginas pode deteriorar-se com o tempo devido a novas alterações ou atualizações, pelo que é fundamental monitorizar constantemente as CWV e fazer as correções ou melhorias necessárias.

Continuaremos a acompanhar as Core Web Vitals de link-assistant.com e a implementar otimizações adicionais, se necessário. Manter uma boa experiência do utilizador e um alto posicionamento no ranking do Google é fundamental para o sucesso do nosso website.

Considerações Finais

As Core Web Vitals tornaram-se um fator essencial de ranking para o Google. Otimizar as CWV pode ter um impacto significativo no desempenho das páginas, na experiência do utilizador e no posicionamento no ranking do Google.

No nosso estudo de caso sobre as Core Web Vitals, demonstrámos como melhorámos as CWV para link-assistant.com e como isso nos ajudou a recuperar de uma queda súbita de posições no ranking.

As otimizações que efetuámos incluem a configuração de servidores e CDNs geoespecíficos, o adiamento de JS de terceiros, a otimização da utilização de fontes, a extração de CSS e JS críticos, a compressão de conteúdo HTTP, a otimização de imagens e os ajustes finais.

Estas otimizações levaram a uma melhoria significativa das Core Web Vitals e tiveram um impacto positivo no desempenho das páginas e nos resultados orgânicos.

Lembre-se que a otimização das Core Web Vitals é um processo contínuo. É importante monitorizar constantemente o desempenho das páginas, fazer correções ou melhorias e manter-se atualizado sobre as últimas diretrizes e melhores práticas do Google para garantir uma experiência de utilizador otimizada e um alto posicionamento.

Artigo retirado de Link-Assistant

Pubblicato in Marketing Digital, SEO