Atualização de maio de 2021 do Google: uma análise mais detalhada do Core Web Vitals

ATUALIZAÇÃO: o mundo do marketing digital está em constante mudança, mas não se preocupe, estamos no controle disso. O Google mudou de idéia sobre o algoritmo que está por vir.

Leia as mudanças recentes aqui em nossa atualização, mas sinta-se à vontade para ler este blog também.

Em maio de 2021, o Google apresentará as métricas Core Web Vitals (CWV) para fazer parte de seu algoritmo de classificação de pesquisa. Aqui está o que você precisa saber e fazer antes disso ...

Todos nós sabemos que sites rápidos são importantes. Eles criam uma melhor experiência do usuário, resultando em maiores taxas de conversão e já levam em consideração a classificação de pesquisa móvel no Google, juntamente com outras métricas de experiência da página, como facilidade de uso para dispositivos móveis.

Mas o Google não para por aí. Em maio de 2020, eles nos falaram sobre o Core Web Vitals e, em 10 de novembro de 2020, anunciaram que, em maio de 2021, o Core Web Vitals será incorporado como um sinal de pesquisa no algoritmo de classificação geral.

Além disso, eles planejam “testar um indicador visual que destaca as páginas nos resultados da pesquisa que proporcionam uma ótima experiência de página”. Portanto, não apenas temos uma chance maior de classificações mais altas por meio da otimização CWV, mas também temos a perspectiva de taxas de cliques aumentadas nas páginas de resultados de mecanismos de pesquisa.

Agir agora para auditar e corrigir quaisquer problemas potenciais sinalizados com essas novas métricas CWV dará aos nossos sites uma chance melhor de classificações mais altas do Google quando essa mudança entrar em vigor em 2021.

Mas primeiro, uma recapitulação ...

Recapitulação: o que são Core Web Vitals?

Core Web Vitals são um conjunto de 3 novas métricas de experiência de página que vão para as pontuações gerais de velocidade do site. Essas métricas já desempenham um papel de destaque na ferramenta PageSpeed ​​Insights do Google, PSI, e no monitoramento de desempenho do Lighthouse em outros lugares.

As novas métricas CWV compreendem o seguinte:

Tinta com maior conteúdo (LCP)

Este é o tempo gasto antes que o maior elemento acima da dobra seja renderizado ao usuário. É responsável por 25% do mecanismo de pontuação de velocidade geral e, portanto, de vital importância para agilizar a entrega do maior item para 2,5 segundos ou menos no celular.

Vários fatores contribuem para um alto LCP, incluindo capacidade de resposta do servidor, scripts e estilos de bloqueio de renderização, complexidade de CSS, fontes e imagens

Atraso da primeira entrada (FID)

Isso mede a interatividade; quão responsiva é a página à entrada do usuário, por exemplo, por meio de toques ou cliques. A velocidade desejada na qual o navegador responde à primeira entrada deve ser de 100 ms ou menos.

Se o navegador estiver analisando ou executando muito JavaScript durante o carregamento da página, isso bloqueará a CPU ou bloqueará o 'thread principal', fazendo com que os dispositivos tornem-se menos responsivos à entrada. Um FID alto geralmente é um indicador de JavaScript complexo. Pode ser um único script ou função ou vários scripts.

As métricas PSI existentes para tempo de interatividade e tempo total de bloqueio estão relacionadas ao FID e, coletivamente, respondem por 35% das pontuações gerais de velocidade.

Mudança de layout cumulativa (CLS)

Esta é uma medida de estabilidade visual do conteúdo acima da dobra. Embora compreenda apenas 5% das pontuações gerais de velocidade, ainda vale a pena considerá-lo no quadro geral. Um CLS alto pode freqüentemente indicar uma ou mais mudanças no layout visual durante o carregamento da página, por exemplo, quando os banners são carregados deslocando o conteúdo da página para baixo.

Análise da pontuação de velocidade

O diagrama abaixo mostra uma análise da pontuação geral de velocidade e o papel que essas novas métricas CWV desempenham nas pontuações GPSI.

Dados de origem da atualização da pontuação do Lighthouse

Embora as métricas não CWV também formem a pontuação geral, incluindo First Content Paint (FCP), Time to Interactive (TTI) e Total Blocking Time (TBT), o foco nas três métricas CWV terá um impacto direto sobre as outras. Um LCP rápido não é possível, por exemplo, sem um FCP rápido e pontuações altas de FID são impactadas diretamente por TBT e TTI.

Dicas para a otimização do maior conteúdo de tinta

A métrica LCP é composta de vários fatores individuais e diretamente impactada por um alto FCP. Se o FCP está sendo sinalizado como ruim, você pode começar aqui. Qualquer coisa, desde conectividade de rede, capacidade de resposta do servidor, tempo para o primeiro byte TTFB e arquivos de bloqueio de renderização afetarão o valor de FCP. Para um mergulho mais profundo em algumas dessas recomendações de velocidade de página mais genéricas, verifique nosso eBook de velocidade de página sobre o assunto, além das dicas específicas do LCP abaixo.

Se o valor do LCP for muito maior do que o do FCP, precisamos ver como podemos otimizar a exibição desse elemento maior.

Determine o maior elemento

A primeira coisa que você provavelmente deseja fazer é determinar qual é o maior elemento. O maior elemento é baseado na área de pixel que pode mudar em diferentes pontos de interrupção, portanto, uma varredura visual pode não necessariamente identificar o elemento certo.

No PSI, deve haver um painel 'Maior elemento de pintura com conteúdo' na seção Diagnóstico. Alternativamente, você pode visualizar o LCP passando o mouse sobre o indicador na ferramenta de monitoramento de desempenho do Chrome, conforme mostrado abaixo.

No site Hallam no exemplo acima, o Monitor de desempenho mostra o LCP como o título principal 'Prosperar Online'. O ideal é que o LCP siga imediatamente o FCP como neste exemplo e, se houver uma lacuna entre os dois, precisamos tentar entender o porquê.

As fontes estão otimizadas?

Se o maior elemento acima da dobra for a tipografia, precisamos nos certificar de que a entrega da fonte seja o mais simplificada possível. Isso inclui:

1. Use a exibição de fontes CSS: swap; para garantir a exibição imediata da fonte enquanto o arquivo da fonte está sendo carregado. Tanto o Google Fonts quanto o Typekit da Adobe têm a capacidade de definir o parâmetro de 'exibição' da fonte.
2. Tente hospedar localmente arquivos de fonte .woff e .woff2 no ​​servidor em vez de fazer solicitações de domínio cruzado para fontes de terceiros. O Google Fonts é muito rápido, as fontes Typekit são mais lentas e algumas fundições de fontes de terceiros podem ser menos confiáveis.
3. O pré-carregamento de arquivos de fonte pode ajudar. As fontes hospedadas localmente geralmente serão incluídas na folha de estilo principal do site, mas essa folha de estilo deve ser baixada e analisada antes que uma solicitação adicional seja feita à fonte contida. O pré-carregamento informa ao navegador para iniciar o download da fonte mais cedo, sem esperar que o CSS seja analisado.
4. Use pré-conexão e pré-busca de dns para fundições de fontes de terceiros. Essas diretivas ajudarão a estabelecer conexões DNS, TLS e TCP entre domínios de terceiros antes que a solicitação seja feita às fontes.
5. Inclua apenas arquivos de fontes para tipografia exigida acima do display dobrável. Ativos de fonte para bibliotecas de ícones, como Font Awesome, são notoriamente pesados, mas as solicitações para eles (e a biblioteca de ícones correspondente CSS) geralmente podem ser adiadas e carregadas após o elemento <head>.
6. Não faça solicitações de domínio cruzado para arquivos de fonte na folha de estilo do site principal, pois isso depende da conectividade e da pesquisa adicional de um domínio de terceiros.
7. Considere as fontes seguras para a web. Eles não exigem nenhum pedido de arquivos de fonte, embora possam ser muito limitados em termos de estética.

As imagens estão otimizadas?

Muitas vezes, o maior elemento acima da dobra será uma imagem tão importante para garantir que as imagens sejam otimizadas. O que se segue é uma boa prática geral, mas especialmente importante para o elemento LCP.

1. Use o tipo de arquivo de imagem correto. Imagens JPG devem ser usadas para fotografias, SVGs para gráficos vetoriais e ícones ou PNGs para imagens mais complexas e não fotográficas e se a transparência for necessária.
2. Certifique-se de que as imagens JPG sejam salvas ou produzam com qualidade de 50-60%. Nesse nível, não deve haver perda perceptível de qualidade. Além disso, certifique-se de que os metadados das imagens foram removidos.
3. Plug-ins ou serviços de compactação, como tinypng.com, podem otimizar imagens em massa e automaticamente e remover metadados desnecessários.
4. As imagens devem ter o tamanho adequado para a área em que estão sendo exibidas. Não envie a imagem de alta qualidade para desktop no celular.
5. As imagens devem ser geradas usando a tag <img> padrão com o atributo 'srcset' para imagens responsivas.
6. Abaixo da dobra ou imagens fora da tela devem usar o atributo loading = ”preguiçoso”.
7. Use o formato de arquivo de imagem .web de próxima geração para taxas de compactação ainda melhores. Isso pode facilmente economizar 30% e, em muitos casos, muito mais.
8. Considere pré-carregar a maior imagem acima da dobra para iniciar o download mais rápido antes de outro conteúdo potencialmente menos crítico.

Reduza arquivos de bloqueio de renderização

Qualquer arquivo JavaScript ou CSS carregado no elemento <head> </head> é considerado bloqueio de renderização, pois esses arquivos precisam ser baixados antes que a página possa começar a renderizar. Isso pode ter um grande impacto nas métricas FCP e LCP. Arquivos de bloqueio de renderização no cabeçalho só devem ser usados ​​se forem essenciais para a exibição inicial acima da dobra na página.

Remover quaisquer arquivos não usados ​​no <head>, carregar arquivos não críticos no rodapé ou combinar vários arquivos em menos arquivos reduzirá a quantidade de ativos de bloqueio de renderização.

Não use JavaScript para exibir o LCP

Antes da CWV, isso não era grande coisa. É comum que o JavaScript seja usado para animar ou exibir elementos acima da dobra, como texto esmaecido ou carrosséis de herói, geralmente com pouco ou nenhum impacto nas pontuações de velocidade.

Se a exibição do maior elemento depende do JavaScript, isso pode causar um longo atraso, pois o JavaScript precisa ser baixado, analisado e executado antes que o elemento apareça. Os arquivos JavaScript são normalmente (e com razão) carregados após o elemento <head>, de forma que não são 'bloqueadores de renderização', mas isso significa que eles ainda podem bloquear efetivamente a renderização do LCP.

Dê uma olhada no exemplo abaixo (logotipo borrado e título alterado), que é de um site de alta pontuação no PSI. O LCP (o texto do cabeçalho principal) está vários segundos mais longe do FCP, o que é causado pela exigência de JavaScript (representado pelas faixas amarelas) para baixar, analisar e executar antes que o texto possa aparecer gradualmente.

O desbotamento do texto em si também pode ser um problema, causando um atraso na exibição do maior elemento.

Técnicas JavaScript como essa podem reduzir imediatamente as pontuações gerais de velocidade em 25% e não devem ser usadas para impedir ou impedir o carregamento do maior elemento de forma alguma.

Executar scripts no carregamento da janela

JavaScript raramente é necessário (e não deveria ser exigido) para exibir conteúdo crítico acima da dobra, mas um problema comum que vemos é que as funções podem ser acionadas assim que o DOM estiver pronto. No popular framework jQuery, isso é feito por meio do evento 'ready'. O Gerenciador de tags do Google também pode acionar funções ou 'tags' no pronto.

Considere acionar todo o JavaScript não necessário para a exibição crítica de conteúdo no evento de carregamento da janela, após o conteúdo da página principal ser carregado para evitar qualquer interferência potencial com a renderização do conteúdo acima da dobra e o elemento LCP.

Mude o LCP

Não importa o quão otimizada e simplificada seja uma imagem, quase sempre levará mais tempo para baixar e exibir em vez de um elemento tipográfico. Embora seja inteiramente possível obter pontuações de LCP rápidas para imagens, às vezes um ajuste para reduzir o maior elemento de imagem para que seja menor do que o maior elemento de texto significa que o texto pode ser usado para o LCP.

Isso pode fazer uma grande diferença nas pontuações, se o design permitir, conforme mostrado no exemplo abaixo, onde o LCP foi alterado para um elemento de texto.

Dicas para otimização do atraso na primeira entrada

Como mencionamos antes, o FID mede o quão responsiva a página é à entrada do usuário. Ele combina o tempo para TTI interativo e o tempo total de bloqueio TBT, que pode ser responsável por até 35% das pontuações gerais de velocidade.

Essas métricas são afetadas principalmente pela análise e execução de scripts à medida que a página é carregada; bloqueando o thread principal da CPU e potencialmente afetando a capacidade de resposta do dispositivo, especialmente para smartphones de gama baixa.

É importante observar que os 'Dados de laboratório' mostrados no PSI não medem o FID diretamente. Isso se deve à natureza interativa da medição de toques ou cliques do usuário, que é difícil de simular. Em vez disso, ele é reunido por 'Dados de campo'; medições coletadas de usuários reais ao longo de um período de 28 dias com base no Chrome User Experience Report CrUX.

Dessa forma, otimizar para FID diretamente é um pouco mais difícil, pois não podemos mudar algo e esperar 28 dias para que mais dados sejam coletados. Devemos, portanto, usar as métricas TTI e TBT nos dados de laboratório para isso, pois tempos baixos para essas métricas se correlacionam a um FID baixo.

Então, como fazemos para otimizar essas métricas?

Audite o seu JavaScript

JavaScript pode vir em todas as formas e tamanhos e não é incomum que um único vídeo incorporado, widget de bate-papo, script ReCaptcha ou integração HubSpot seja a única causa por trás das altas métricas de FID, TTI e TBT.

Os painéis de diagnóstico no Page Speed ​​Insights são um bom lugar para começar. A seção para 'Minimizar o trabalho do thread principal' informará quanto tempo de execução é usado pelo JavaScript, a seção 'Reduzir o tempo de execução do JavaScript' indicará quais arquivos têm tempos de análise e execução altos e 'Reduzir o impacto de terceiros code 'irá destacar e agrupar scripts de terceiros de alto impacto.

A captura de tela abaixo mostra um site que sofre de vários scripts pesados, com uma métrica de tempo de interação de 15 segundos. Muitos scripts são de terceiros, incluindo HubSpot e Vimeo.

Para uma análise mais profunda e visualização de como esses scripts afetam o carregamento da página, a ferramenta Monitor de desempenho do Chrome pode ser uma ótima maneira de detalhar quais scripts e funções são disparados, o impacto relativo desses scripts e em que ponto de carregamento da página eles scripts longos estão sendo executados.

O exemplo abaixo é do mesmo site e mostra JavaScript representado pelas barras amarela, rosa e laranja, com barras mais longas mostrando tarefas de execução mais longas. Quando clicamos nessas tarefas mais longas, podemos ver os scripts destacados correlacionados aos grandes scripts destacados pelo PSI acima.

Assim que tivermos uma imagem melhor de quais scripts estão afetando o desempenho, existem várias técnicas que podemos usar para minimizar seu impacto, conforme descrito abaixo.

Carregar scripts de forma assíncrona

Por padrão, o JavaScript será executado em sequência. Se houver scripts que não dependem do carregamento de outros, esses scripts devem ser carregados com o atributo 'async' para que não bloqueiem a análise e execução de outros scripts.

Carregar JavaScript condicionalmente

Um problema comum que vemos em muitos sites é que scripts pesados ​​são carregados globalmente ou em páginas quando não são necessários. Se você precisar usar o ReCaptcha, por exemplo, para ajudar a impedir o spam em envios de formulários, certifique-se de carregar scripts apenas nas páginas que possuem formulários.

Simplifique os pacotes de JavaScript

Bibliotecas JavaScript como jQuery UI ou Bootstrap são freqüentemente usadas para fornecer recursos e funções JavaScript adicionais. Se estiver usando um pacote, certifique-se de incluir apenas os recursos relevantes dentro do pacote para evitar que JavaScript desnecessário seja baixado e analisado.

Scripts de carregamento lento quando necessário

Mesmo que o JavaScript seja carregado apenas nas páginas em que é necessário, o script em si não precisa necessariamente ser analisado e executado durante o carregamento da página ou do evento de carregamento da janela. Carregar JavaScript apenas quando é realmente necessário pode fazer uma grande diferença nas métricas de TTI, TBT e FID. aqui estão alguns exemplos:

1. Incorporação de vídeos, como YouTube e Vimeo, costuma ter alto impacto. Considere carregar apenas esses scripts ao clicar na miniatura de um vídeo.
2. As integrações de formulários de terceiros, como HubSpot, podem ser intensas. Se o formulário aparecer em um modal ou na parte inferior de uma página, considere carregar ou injetar o script necessário na rolagem ou ativação modal em vez do carregamento da página.
3. Os widgets de chat ao vivo podem afetar as pontuações gerais de velocidade em até 35%. Considere mover o widget de chat ao vivo para uma página de contato dedicada com suporte ao CTA global de 'chat ao vivo' ou injetar o script de chat ao vivo apenas quando um botão 'chat conosco' for clicado.
4. Adicionar o atributo 'loading = ”lazy” no conteúdo baseado em iFrame incorporado pode ajudar, mas é um novo recurso do navegador e precisará ser testado dependendo do embed de iFrame usado.

Avalie as ferramentas de business intelligence

Analisar o comportamento do usuário com ferramentas como Hotjar ou software de teste A / B como VWO é realmente importante para a inteligência de negócios e, em muitos casos, seus benefícios compensarão o impacto na velocidade do site.

Dito isso, ainda vale a pena avaliar a importância de executar essas ferramentas 24 horas por dia, 7 dias por semana, dependendo da frequência com que os dados são analisados. O teste A / B deve ser desativado se nenhum teste ativo estiver em execução, por exemplo, e as ferramentas de análise de comportamento, como o Hotjar, puderem ser desativadas depois que dados suficientes forem coletados e processados.

Dicas para otimização cumulativa de mudança de layout

O deslocamento cumulativo de layout (CLS) pode ser responsável por apenas 5% das pontuações gerais de velocidade, mas ainda assim, uma parte importante do quadro geral, especialmente porque a grande quantidade de elementos de deslocamento no carregamento da página pode ser uma experiência chocante para o usuário.

Determine o elemento CLS

Às vezes, pode parecer óbvio que elemento ou elementos causam uma mudança no conteúdo, mas sempre vale a pena verificar isso por meio do painel Layout Shift no PSI, conforme mostrado abaixo.

A métrica CLS deve estar abaixo de 0,1, mas no exemplo acima, isso é excedido em mais de 400% e custará uma queda de 5% nas pontuações. Se este for um problema global, são 5% em todas as páginas.

Os elementos móveis devem ser identificados e tratados em ordem de impacto e podem incluir elementos acima e abaixo da dobra. Destacamos algumas das causas e resoluções mais comuns de mudança de layout abaixo.

Cuidado com a animação

É bastante comum que certas técnicas de animação sejam usadas para alterar a forma como o conteúdo é apresentado ao usuário, por exemplo, esmaecendo ou deslizando em imagens, texto ou painéis de conteúdo conforme o usuário rola a página para baixo. Embora possam ser esteticamente agradáveis ​​(dependendo de para quem você perguntar), é importante que essas técnicas não alterem nenhum conteúdo durante o carregamento da página.

Se você tiver que ocultar e dissolver o conteúdo para o usuário, certifique-se de que o tamanho do contêiner ou a altura total da página não mudem conforme o conteúdo é carregado. O conteúdo pode ser oculto (se necessário) usando regras de visibilidade CSS em vez de exibir: nenhum; que preservará a quantidade subjacente de espaço de que necessita.

Especifique as dimensões da imagem

Se a tag <img> não tiver os atributos de largura e altura definidos, ou se o CSS não estiver sendo usado para definir as dimensões ou proporção da imagem, os navegadores precisarão fazer o download da imagem antes de poder determinar a área de pixel necessária exibir dentro. Isso pode causar um deslocamento de qualquer conteúdo renderizado abaixo da imagem, conforme a imagem é carregada.

Especificar a largura e a altura da imagem ou definir as dimensões ou proporção da imagem (ou o contêiner pai) no CSS antes do download da imagem garantirá que os navegadores saibam a área em que a imagem precisa ser exibida e evitará o layout potencial mudança.

Banners

Anúncios, barras de leis de cookies ou qualquer outra informação usada para exibir informações importantes em um banner são provavelmente uma das causas mais comuns de um CLS alto.

É comum que o conteúdo do banner seja carregado de uma fonte de dados externa ou via JavaScript do mesmo site, o que significa que o tamanho do contêiner do banner pode não ser possível calcular até que o conteúdo seja carregado. Quando isso acontecer, o conteúdo abaixo do banner será deslocado para baixo assim que o conteúdo do banner for carregado e exibido para o usuário.

Existem várias resoluções para isso:

1. Defina uma altura mínima para o banner ou contêiner de banner em CSS para que o navegador possa renderizar efetivamente um espaço reservado. Embora isso possa ser problemático se a quantidade de conteúdo for dinâmica e desconhecida.
2. Absolutamente ou fixe a posição do banner na parte superior ou inferior da tela. Para banners que podem ser fechados ou descartados, esta é uma boa consideração, pois elementos fixos não afetarão o posicionamento de quaisquer outros elementos.
3. Observe a renderização do conteúdo do banner no lado do servidor, se possível, o que significa que o conteúdo e as dimensões do banner podem ser carregados antecipadamente antes de chegar ao usuário.

Resumo

Esperançosamente, você encontrará algumas das técnicas destacadas acima úteis para diagnosticar e solucionar problemas de desempenho relacionados ao novo Core Web Vitals do Google. Nos últimos meses na Hallam, ajudamos vários clientes a melhorar o desempenho de seus sites, tanto em termos de auditorias de velocidade quanto de melhorias diretas feitas por nossa equipe de desenvolvimento.

Se você achou este artigo útil, você também pode verificar nosso eBook de desempenho de site da Web, que apresenta um mergulho mais profundo em algumas das recomendações mais genéricas sobre a velocidade da página, das quais qualquer pessoa que esteja criando ou gerenciando um site pode se beneficiar.