SEO

Auditoria Core Web Vitals: Lista De Verificação De 35 Etapas Com Correções, Exemplos E Muito Mais

11
May
2021

Giulia Oliveira

Analista de SEO, especialista em performance para ecommerce e soluções Google.

Uma lista de verificação de auditoria completa do Core Web Vitals com explicações, exemplos, possíveis correções, capturas de tela e muito mais.  

Core Web Vitals estão se tornando ações fundamentais em SEO.  A melhor maneira de preparar o seu site para a próxima atualização da experiência da página do Google é se familiarizar com esse aspecto.

Abaixo, estamos compartilhando com você uma lista de verificação de auditoria Core Web Vitals de 35 etapas que você pode usar para auditar um site em termos de velocidade do Google e métricas de desempenho conhecidas como Web Vitals. 

  • A lista de verificação abaixo é dividida em três seções, cada uma focando uma das três métricas do Core Web Vitals. 
  • Cada etapa descreve o impacto que um determinado elemento pode ter no LCP, FID ou CLS, explica por que isso é importante, fornece um exemplo e sugere possíveis correções. 
  • No final da lista, haverá um modelo para download que você pode usar para realizar a auditoria Core Web Vitals de qualquer site. 

Isso é tudo que você precisa para deixar o seu site ou o do seu cliente pronto para a atualização do Core Web Vitals. 

auditoria-core-web-vitals-lista-de-verificacao-de-35-etapas-com-correcoes-exemplos-e-muito-mais

 

Pesquisei na documentação do Google sobre Core Web Vitals e como melhorar cada métrica. Fiz o meu melhor para extrair todas as melhores práticas, dicas e possíveis correções de lá e colocá-las em um só lugar na forma de um guia relativamente fácil de digerir. Espero ter economizado pelo menos 7 dias de leitura aprofundada! 

Ferramentas para auditar Core Web Vitals

Obviamente, você deseja iniciar sua auditoria do Core Web Vitals medindo de fato as métricas do site que está auditando.

Aqui estão as ferramentas de que você precisará para fazer uma auditoria Core Web Vitals. Quanto mais ferramentas você usar, mais detalhada será sua análise. 

As ferramentas de campo para auditar Core Web Vitals:

auditoria-core-web-vitals-lista-de-verificacao-de-35-etapas-com-correcoes-exemplos-e-muito-mais-1

O relatório Core Web Vitals no Google Search Console para WebPeak. 

As ferramentas de campo fornecem dados do mundo real sobre como os usuários reais estão experimentando o site. Esses dados são mais precisos do que os dados de laboratório, que geralmente são apenas estimativas. 

As ferramentas de laboratório para auditar Core Web Vitals:

Chrome DevTools (uma ferramenta mais avançada que permite que você analise completamente como seu site está carregando)

auditoria-core-web-vitals-lista-de-verificacao-de-35-etapas-com-correcoes-exemplos-e-muito-mais-2

A captura de tela do Chrome DevTools e a medição do Core Web Vitals para WebPeak.

  • Lighthouse (ideal para fazer testes e testar melhorias no ambiente de laboratório)
auditoria-core-web-vitals-lista-de-verificacao-de-35-etapas-com-correcoes-exemplos-e-muito-mais-3

 

  • WebPageTest (ótimo se você quiser se aprofundar muito)
auditoria-core-web-vitals-lista-de-verificacao-de-35-etapas-com-correcoes-exemplos-e-muito-mais-4

A visualização em cascata em WebPageTest para WebPeak.

auditoria-core-web-vitals-lista-de-verificacao-de-35-etapas-com-correcoes-exemplos-e-muito-mais-5

As extensões do Chrome Web Vitals e os resultados do site WebPeak.

As ferramentas de laboratório fornecem dados para que você possa  usar para testar diferentes implementações, verificando assim se uma determinada correção funciona e pode realmente melhorar uma métrica específica. Os dados de laboratório fornecem uma ideia do desempenho de um site, mas não fornecem uma visão geral.  

Ferramentas para medir os vitais essenciais dauditoria-core-web-vitals-lista-de-verificacao-de-35-etapas-com-correcoes-exemplos-e-muito-mais-6a Web

Lista de ferramentas para medir Core Web Vitals recomendadas pelo Google. 

Verifique a lista de ferramentas para medir o Core Web Vitals em web.dev para saber mais.

Eu direi exatamente quais ferramentas usar para medir cada uma das três métricas do Core Web Vitals em apenas um momento.

Lista de verificação de auditoria do Core Web Vitals

Esta lista de verificação contém todas as coisas possíveis que você deve avaliar ao auditar o site em termos de Core Web Vitals, sinais de experiência da página do Google e desempenho geral e velocidade. 

Observe que a implementação dessas correções em muitos casos requer conhecimento de programação. Você - como um SEO - pode tratar esta lista de verificação como um conjunto de diretrizes para desenvolvedores que provavelmente implementarão essas correções sob sua orientação.  

Vamos entrar nisso!

Largest Contentful Paint (LCP)

O Largest Contentful Paint (LCP) mede o desempenho de carregamento de uma página da web. Um site fornecerá uma boa experiência ao usuário se sua métrica LCP for menor ou igual a 2,5 s.  

auditoria-core-web-vitals-lista-de-verificacao-de-35-etapas-com-correcoes-exemplos-e-muito-mais-7

Em termos simples, o LCP mede o tempo de carregamento percebido calculando a rapidez com que o conteúdo principal da página da web é carregado. Um bloco de texto ou uma imagem geralmente é considerado o conteúdo principal. 

As ferramentas de campo para medir o LCP:

auditoria-core-web-vitals-lista-de-verificacao-de-35-etapas-com-correcoes-exemplos-e-muito-mais-8

O relatório Core Web Vitals no Google Search Console.

As ferramentas de laboratório para medir o LCP: 

  • Chrome DevTools (mostrará o LCP do site testado)
  • Lighthouse (esta ferramenta funciona de maneira semelhante ao PSI porque o PSI coleta dados de laboratório do Lighthouse)
  • WebPageTest (uma ferramenta ideal para usuários avançados que desejam se aprofundar em como um site é carregado)
  • Extensão Web Vitals do Chrome (uma ótima ferramenta para testar Core Web Vitals para desktop e em um ambiente de laboratório)

Para os fins desta auditoria, recomendo que você use o Google PageSpeed ​​Insights e o relatório GSC Core Web Vitals para examinar os dados de campo relacionados ao LCP.  

Além disso, certifique-se de usar o Chrome DevTools, Lighthouse e WebPageTest para verificar o que é considerado o LCP da página da web testada. 

1. Verifique se o servidor está otimizado corretamente.

Um servidor sobrecarregado e não otimizado pode aumentar a quantidade de tempo que o navegador precisa para baixar os dados do site.

Qualquer consulta cara que leve muito tempo para ser concluída ou outros tipos de operações complexas que estejam acontecendo no lado do servidor influenciarão negativamente os tempos de resposta do servidor e as métricas de carregamento da página. 

Tempos de resposta lentos do servidor quase sempre levam a uma pontuação LCP baixa. 

Aqui está o que você pode fazer e as correções que você pode recomendar: 

  • Teste o site com a ferramenta Google PageSpeed ​​Insights:  A ferramenta indicará se há problemas de resposta lenta do servidor no site. Se a ferramenta indicar esse problema, investigue melhor. 
auditoria-core-web-vitals-lista-de-verificacao-de-35-etapas-com-correcoes-exemplos-e-muito-mais-9

As dicas de otimização fornecidas pelo Google PageSpeed ​​Insights no caso de um site com um servidor lento.

Muitos provedores de hospedagem permitem que você implemente algumas otimizações básicas de servidor. Recomendo que você verifique o que o provedor de hospedagem do site oferece. 

  • Uma das otimizações de servidor que você pode fazer é, por exemplo, atualizar o PHP para a versão mais recente.
  • O Google tem um bom guia sobre como otimizar um servidor sobrecarregado. Verifique isso se quiser se aprofundar no assunto.  

2. Verifique se um Content Delivery Network (CDN) é usado. 

A Content Delivery Network (CDN) é uma rede distribuída geograficamente de servidores que trabalham juntos para fornecer entrega rápida de recursos do site. 

Um site que usa um CDN carregará mais rápido porque seus usuários não terão que esperar por solicitações de rede para servidores localizados distantes. Servidores localizados na vizinhança serão usados ​​em seu lugar. 

Aqui está o que fazer ou recomendar:

  • Verifique se o site usa um CDN. Você pode usar a ferramenta CDN Finder para verificar isso rapidamente. 
auditoria-core-web-vitals-lista-de-verificacao-de-35-etapas-com-correcoes-exemplos-e-muito-mais-10

Se o site não usar um CDN, recomendamos que ele obtenha um. Existem muitos CDNs por aí. O mais popular é o Cloudflare, que é gratuito. 

3. Verifique se os ativos do site estão em cache.

O armazenamento em cache dos ativos do site é uma das melhorias de velocidade e desempenho mais importantes que afetam diretamente a métrica de LCP.   

Se o código HTML do site for estático (e não houver necessidade de alterá-lo a cada solicitação), então - graças ao armazenamento em cache - não há necessidade de recriá-lo desnecessariamente. Isso pode reduzir significativamente a métrica TTFB (Time to First Byte) e minimizar o uso de recursos. 

Aqui está o que fazer:

  • Use a ferramenta Google PageSpeed ​​Insights para verificar se os ativos do site estão armazenados em cache. 
  • A ferramenta indicará a lista de recursos que não são armazenados em cache ou não usam uma política de cache eficiente. 
  • Recomende aplicar o cache do servidor. Existem muitas maneiras diferentes de fazer isso:
  • Configure proxies reversos, como Varnish ou nginx, para que atuem como um servidor de cache ou forneçam conteúdo em cache.  
  • Configure seu provedor de nuvem, como Azure ou AWS para armazenar ativos em cache.
  • Use um CDN (veja o ponto acima). 

4. Verifique se as páginas HTML completas ou parciais em cache primeiro são exibidas.

A exibição de páginas HTML em cache primeiro permite armazenar em cache parte ou todo o conteúdo HTML de uma página da web, atualizando o cache apenas se o conteúdo for alterado. 

Isso pode ser feito com o uso de um service worker que será executado em segundo plano e interceptará todas as solicitações do servidor. Usar um service worker pode melhorar significativamente a métrica de LCP. 

Aqui está o que fazer e recomendar: 

  • Se o site não usa um service worker, recomendo o uso de um. 
  • O desenvolvedor deve saber como implementar um service worker para obter cargas úteis de HTML menores

5. Verifique se as conexões de terceiros são estabelecidas antecipadamente.

O LCP pode ser reduzido significativamente se as conexões de terceiros forem estabelecidas o mais cedo possível. 

Estabelecer conexões de terceiros é especialmente importante se as solicitações do servidor para origens de terceiros forem necessárias para exibir o conteúdo crítico da página da web. Um site pode usar rel="preconnect"ou rel="dns-prefetch"para fazer isso. 

Aqui está o que fazer ou recomendar:

  • Teste o site com o uso da ferramenta Google PageSpeed ​​Insights para verificar se as conexões de terceiros são estabelecidas antecipadamente. 
  • Se o site usar rel="preconnect", a ferramenta marcará isso como uma auditoria aprovada. Caso contrário, a ferramenta marcará isso como uma oportunidade.  

Você pode recomendar uma das seguintes soluções:

  • Usar rel="preconnect"
  • Usar rel="dns-prefetch"
  • Ou use rel="dns-prefetch"como substituto para navegadores sem suporte rel="preconnect"(mais recomendado)  

6. Verifique se o CSS está reduzido. 

Folhas de estilo e scripts são recursos de bloqueio de renderização que impactam negativamente o First Input Delay (FID) e o Largest Contentful Paint (LCP). 

O site deve ter a quantidade mínima de CSS de bloqueio de renderização necessária. A minimização é uma das maneiras de reduzir a quantidade de CSS de bloqueio.

Aqui está o que você precisa fazer:

  • Teste o site com o Google PageSpeed ​​Insights para ver se o CSS foi reduzido. 
  • A ferramenta indicará se o CSS está reduzido ou não. 
  • Se o CSS não estiver minimizado, recomende sua minimização. Dependendo de como o site é construído e da tecnologia usada, há muitas maneiras de minimizar o CSS.

Para sites que usam um empacotador de módulo ou ferramenta de construção, você deve recomendar a inclusão de um plugin especial para reduzir arquivos CSS.

7. Verifique se CSS não crítico foi adiado. 

CSS não crítico deve ser adiado porque pode ter um grande impacto na métrica de pintura com maior conteúdo e é um recurso de bloqueio de renderização.

Outra maneira de otimizar a entrega de CSS é adiando CSS não crítico, o que minimiza o tempo de bloqueio de CSS. 

Aqui está o que você pode fazer:

  • Você pode encontrar qualquer CSS não utilizado na página da web usando a guia Cobertura no Chrome DevTools. 
  • A ferramenta Google PageSpeed ​​Insights também detecta CSS não crítico que pode ser adiado. 
  • Recomende que qualquer CSS não usado seja totalmente removido ou movido para outra folha de estilo se for usado em uma página da web diferente. 
  • No caso de CSS não exigido para renderização inicial, recomendamos carregar arquivos de forma assíncrona com o uso de loadCSS.
    <link rel="preload" href="stylesheet.css" as="style" onload="this.rel='stylesheet'">

8. Verifique se o CSS crítico está embutido. 

Ao inserir estilos importantes embutidos, você tornará muito mais rápido para o navegador buscar CSS crítico, o que irá melhorar o LCP da página. 

Qualquer CSS crítico usado na seção acima da dobra do site deve ser incluído diretamente em <head>.

Aqui está o que fazer e recomendar:

  • Teste o site com o Google PageSpeed ​​Insights para verificar se o CSS crítico está embutido.

Se o CSS crítico não estiver embutido, recomende um dos seguintes:

  • Adicionando manualmente estilos embutidos ao site.
  • Usando uma biblioteca para automatizar o processo. Exemplos de bibliotecas incluem Critical, CriticalCSS ou Penthouse. Existe também um plugin de webfpack Critters.
  • No caso de sites WordPress, você pode usar um dos vários plugins de otimização. Eu recomendo WP Rocket.

9. Verifique se os arquivos JavaScript estão reduzidos e compactados.

Ao reduzir a quantidade de bloqueio de JavaScript, você pode reduzir significativamente a pontuação LCP do site. 

O site deve servir apenas a quantidade mínima de JavaScript necessária aos usuários. O objetivo da minimização do JavaScript é criar um arquivo JS mais leve, mas ainda válido, removendo qualquer espaço em branco ou código desnecessário.

Aqui estão as etapas a seguir:  

  • A ferramenta Google PageSpeed ​​Insights mostrará se os arquivos JavaScript estão reduzidos na página da web. 

Se JS não for minimizado, a auditoria deve recomendar a minimização JS. As correções que você pode recomendar incluem:

  • Uma ferramenta de compressão JS popular chamada Terser
  • O Webpack v4 ou superior possui um plugin que reduz os arquivos para esta biblioteca por padrão.

10. Verifique se o JavaScript não utilizado foi adiado. 

Quanto menos código JavaScript estiver na página da web, menos tempo o navegador precisa para executar JS e mais rápido ele pode responder a qualquer interação do usuário.

JavaScript sempre bloqueia a renderização. Ao reduzir a quantidade de JavaScript não utilizado, você pode melhorar as métricas de LCP e FID. A prática recomendada é carregar apenas o código necessário para a página da web ou em resposta à entrada do usuário. 

Aqui está o que você pode fazer:

  • Teste a página da web usando a ferramenta Google PageSpeed ​​Insights para verificar se ela detecta algum JavaScript não utilizado.
auditoria-core-web-vitals-lista-de-verificacao-de-35-etapas-com-correcoes-exemplos-e-muito-mais-11

Os exemplos de JavaScript não utilizado em um site (exibidos pelo Google PageSpeed ​​Insights).

  • Você também pode usar o Chrome DevTools (a guia Cobertura) para verificar a quantidade de JavaScript não utilizado na página da web.
  • Uma das melhores maneiras de corrigir esse problema é simplesmente adiar JavaScript não crítico e scripts de terceiros com o uso de async ou defer. 
  • Geralmente, todos os scripts de terceiros devem ser carregados por padrão com o uso de async ou defer. 

<script defer src="…"></script>

<script async src="…"></script>

11. Verifique se os polyfills não usados ​​são minimizados. 

Minimizar polyfills não usados ​​e otimizar seu uso para que sejam usados ​​apenas nos ambientes onde são necessários pode melhorar significativamente as métricas de carregamento de página, como o Largest Contentful Paint. 

Os navegadores modernos não devem fazer o download do código transpilado ou polyfills, a menos que seja necessário. 

Aqui está o que você pode recomendar: 

  • Os sites que usam o transpiler Babel podem @babel/preset-env incluir apenas os polyfills necessários para os navegadores de destino ou habilitar a opção de correções de bugs para otimizar ainda mais os polyfills desnecessários. 
  • Você pode usar  <script type="module"> para bloquear o envio do código transpilado para navegadores que não precisem dele.
  • Entregue dois pacotes separados com o uso do padrão de module/nomodule.
  • É função do desenvolvedor analisar o site e decidir se e como otimizar polyfills.
  • O desenvolvedor pode aprender mais sobre como otimizar polyfills não utilizados aqui. 

12. Verifique se as imagens estão otimizadas e compactadas. 

O tempo necessário para carregar diferentes tipos de recursos também pode impactar a maior pontuação de pintura com conteúdo da página da web.  

Os tipos de recursos que afetam o LCP incluem <img>elementos, <video>elementos, <image>elementos em um <svg>elemento, elementos com uma imagem de fundo carregada com url(), elementos de nível de bloco com nós de texto e outros tipos de elementos de texto embutidos. 

A melhor maneira de melhorar o tempo de carregamento é otimizando e compactando imagens.  

Aqui está o que você precisa fazer, verificar e recomendar:

  • O Google PageSpeed ​​Insights indicará se há algum recurso que precisa ser otimizado. A ferramenta também informará quais tipos de otimizações são recomendadas em um caso específico. 
  • Verifique se uma imagem é o maior elemento na janela de visualização após o carregamento da página. Exemplos comuns disso são imagens de banner, carrosséis grandes e imagens de herói. 

Algumas das maneiras de melhorar os tempos de carregamento e renderização de imagens incluem:

  • Evite usar uma imagem como a parte principal do conteúdo na janela de visualização. 
  • Comprimir imagens.
  • Use imagens responsivas.
  • Converta imagens em novos formatos, como JPEG 2000, JPEG XR ou WebP).

No caso de sites WordPress, você pode recomendar o uso de plugins, como WP Rocket e Imagify. 

13. Verifique se recursos importantes foram pré-carregados. 

O pré-carregamento de recursos importantes pode melhorar significativamente a pontuação LCP de uma página da web.  

Existem diferentes tipos de recursos que podem ser pré-carregados, mas é importante pré-carregar apenas os ativos críticos, como JavaScript, CSS de caminho crítico, fontes e imagens acima da dobra.

Aqui está o que fazer e recomendar em sua auditoria: 

  • Teste a página da web com a ferramenta Google PageSpeed ​​Insights. A ferramenta indicará se as solicitações de chave são pré-carregadas ou não. 
  • Se as solicitações de chave não forem pré-carregadas, recomendamos usar <link rel="preload">para pré-buscar esses recursos antecipadamente. 
  • No caso de sites WordPress, você pode automatizar esse processo usando um plugin especial, como o WP Rocket.  

14. Verifique se os arquivos de texto estão compactados. 

A compactação de recursos e arquivos de texto pode melhorar significativamente os tempos de carregamento de uma página da web e, assim, reduzir a pontuação do Largest Contentful Paint. 

O tamanho dos arquivos de texto, como HTML, JavaScript ou CSS pode ser muito reduzido com o uso de algoritmos de compressão, como Gzip ou Brotli

Aqui está o que fazer e recomendar:

  • Use a ferramenta Google PageSpeed ​​Insights para verificar se a compactação de texto já está habilitada no site. Muitas plataformas de hospedagem permitem a compactação de texto por padrão. 
  • Se a compactação de texto não estiver habilitada, recomendamos o uso de Gzip ou Brotli. 
  • A compressão Gzip é suportada por todos os navegadores, mas oferece resultados de compressão um pouco piores do que o Brotli, que é suportado por quase todos os novos navegadores. 
  • Observe que os ativos devem ser compactados com antecedência, em vez de instantaneamente. 

15. Verifique se a porção adaptativa é usada. 

A busca condicional de ativos dependendo do tipo de conexão de Internet do usuário e do dispositivo também pode melhorar significativamente os tempos de carregamento e LCP.

Se o site tiver grandes ativos que são essenciais para a renderização, é uma ótima ideia servir diferentes versões do mesmo recurso, dependendo do dispositivo ou da conexão do usuário. 

Aqui está o que você pode recomendar:

Se o site que você está auditando não usa veiculação adaptável e tem recursos enormes que podem ser veiculados condicionalmente, você pode recomendar uma das seguintes APIs:

Por exemplo, você pode recomendar a exibição de uma imagem em vez de um vídeo se a conexão com a Internet for mais lenta do que 4G. 

if (navigator.connection && navigator.connection.effectiveType) {

if (navigator.connection.effectiveType === '4g') {

// Load video

} else {

// Load image

}

}

Esta é uma técnica um pouco mais avançada, portanto, recomendo mais leituras sobre a veiculação adaptativa se você quiser implementá-la em seu site ou recomendá-la a seu cliente. 

Maior conteúdo de pintura e renderização do lado do servidor

Os três pontos a seguir da auditoria Core Web Vitals são especialmente importantes para sites que usam estruturas e bibliotecas, como Angular, React ou Vue, que em muitos casos processam páginas da web no cliente em vez de no servidor. 

16. Verifique se o JavaScript crítico está minimizado.  

Renderizar JavaScript (principalmente no cliente), pode ter um efeito negativo no LCP (especialmente se grandes arquivos JavaScript são usados). 

Se o JavaScript na página não estiver otimizado, os usuários podem não ser capazes de interagir com a página da web ou ver todo o seu conteúdo até que todo o JS crítico tenha sido baixado e executado. 

A melhor maneira de otimizar sites renderizados no lado do cliente é minimizar a quantidade de JavaScript usado. 

Aqui está o que fazer e recomendar:

  • Teste a página da web com a ferramenta Google PageSpeed ​​Insights para ver se o JavaScript está otimizado. A ferramenta indicará todas as oportunidades a esse respeito. 

Você pode fornecer as recomendações dos pontos 9, 10 e 11, que são:

  • Minificação de JavaScript
  • Adiar arquivos JavaScript não utilizados 
  • Minimizando polyfills não usados 

Deve ser o desenvolvedor quem toma a decisão final sobre se e como otimizar o JavaScript em um determinado site.  

17. Verifique se a renderização do lado do servidor é ou pode ser usada.

Usar a renderização do lado do servidor também pode ajudar a melhorar a métrica de LCP.

A renderização do lado do servidor funciona de forma que o conteúdo principal da página seja renderizado no servidor, não no cliente. Isso pode melhorar o LCP significativamente, mas, ao mesmo tempo, pode aumentar os tempos de resposta do servidor e piorar o tempo até o primeiro byte (TTFB) e o tempo até a interação (TTI).

Aqui está o que fazer ou recomendar:

  • Dependendo de quão pesado é o JavaScript do site e de qual é sua métrica de LCP, você pode recomendar o uso da renderização do lado do servidor. 
  • Lembre-se de que, neste caso, deve ser o desenvolvedor quem decide se e como implementar a renderização do lado do servidor.
  • O Google, felizmente, fornece uma grande quantidade de documentação útil sobre renderização e compartilha muitas das melhores práticas. 

18. Verifique se a pré-renderização é usada

A pré-renderização é outra maneira de melhorar a métrica de LCP 

A pré-renderização é menos complexa em comparação à renderização do lado do servidor, mas também pode ajudar a melhorar o LCP significativamente. Assim como com a renderização do lado do servidor, a pré-renderização tem um impacto negativo no tempo de interação (TTI), mas não afeta tanto os tempos de resposta do servidor. 

Aqui está o que verificar ou recomendar:

  • Suas recomendações devem depender de quão pesado é o JavaScript do site que você está auditando e como isso afeta seu LCP. 
  • Se aplicável, recomendar a implementação de pré-renderização. 
  • Certifique-se de que o desenvolvedor analise o site e tome a decisão final sobre o que implementar. 

Há muito a ser feito para melhorar o LCP, não é? Vamos agora analisar as duas métricas restantes.  

First Input Delay (FID)

O First Input Delay (FID) mede a interatividade de uma página da web. Um site proporcionará uma boa experiência do usuário se suas páginas tiverem uma pontuação FID igual ou inferior a 100 ms. 

auditoria-core-web-vitals-lista-de-verificacao-de-35-etapas-com-correcoes-exemplos-e-muito-mais-12

O primeiro atraso de entrada requer uma entrada real do usuário, portanto, não pode ser medido no laboratório.  O total blocking time (TBT) é a métrica mais próxima do FID, se correlaciona com o FID e pode ser medida em laboratório. Time to Interactive (TTI) também pode ser usado como um indicador de laboratório para FID. 

As melhorias no Tempo Total de Bloqueio (TBT) geralmente levam a melhorias no Atraso da Primeira Entrada (FID).  

A execução pesada do JavaScript geralmente é a principal causa de uma pontuação baixa do FID. Portanto, a melhor maneira de melhorar o FID é otimizar a análise, compilação e execução do JavaScript.  

As ferramentas para medir FID: 

  • Google PageSpeed ​​Insights  (esta é a ferramenta que você deve usar para auditar o FID por página, supondo que o relatório CrUX tenha dados suficientes para o site).
auditoria-core-web-vitals-lista-de-verificacao-de-35-etapas-com-correcoes-exemplos-e-muito-mais-13

Para os fins desta auditoria, recomendo que você use o Google PageSpeed ​​Insights e o relatório GSC Core Web Vitals para examinar o FID. Observe que o FID só pode ser medido com base nos dados de campo.  

Use ferramentas de laboratório, como  Chrome DevTools, Lighthouse e WebPageTest para examinar outras métricas, como TTI e TTB, que se correlacionam com FID e também bons indicadores de prontidão de interação. 

19. Verifique se as tarefas JavaScript longas estão divididas. 

Dividir tarefas longas de JavaScript em tarefas assíncronas menores pode melhorar visivelmente o Atraso da Primeira Entrada. 

Uma tarefa longa é um trecho de código JavaScript que bloqueia a thread principal por 50 ms ou mais. Durante longas tarefas de JavaScript, a IU pode não responder. Tarefas longas são consideradas um sinal de possível inchaço do JavaScript. 

A melhor maneira de reduzir o First Input Delay de um site é dividindo tarefas longas. 

Aqui está o que fazer e recomendar: 

  • Use a ferramenta Google PageSpeed ​​Insights para verificar se há otimizações de JavaScript a serem feitas.
  • Use o Chrome DevTools para verificar se há tarefas longas no site.
  • Tudo que você precisa fazer é registrar um rastreamento do carregamento de uma página da web (no painel Desempenho ). Todas as tarefas são mostradas em cinza e as tarefas longas têm bandeiras vermelhas. 
  • Você também pode usar o Lighthouse para verificar se há tarefas longas.
  • Analise tarefas longas e forneça seu feedback ao desenvolvedor, sugerindo que essas tarefas longas devem ser divididas em tarefas menores.
  • Você pode aprender mais sobre longas tarefas de JavaScript em web.dev. 

20. Verifique se a execução do script de primeira parte afeta negativamente a prontidão da interação. 

A execução ineficiente de script de primeira parte influencia a interatividade do site e as métricas, como FID, TBT e TTI. 

As principais causas de atrasos na prontidão da interação são o inchaço do JavaScript, tempos de execução pesados ​​do JavaScript, fragmentação ineficiente e grandes execuções de script. 

Aqui está o que você pode fazer ou recomendar:

  • Teste o site com o Google PageSpeed ​​Insights ou Lighthouse e verifique as pontuações das métricas que influenciam a prontidão de interação. 
  • As métricas a serem verificadas incluem First Input Delay (FID), Total Blocking Time (TBT) e Time to Interactive (TTI).
  • Você também pode usar o Chrome DevTools para verificar as métricas correspondentes ao FID. 

Pontue suas descobertas na auditoria. Você pode recomendar o seguinte:

  • Carregamento progressivo de código.
  • Renderização ou pré-renderização do lado do servidor, dependendo do tipo de site e do aplicativo.
  • Removendo scripts não essenciais do caminho de renderização crítico. 

21. Verifique se a busca de dados afeta negativamente a prontidão de interação. 

A busca de dados também pode ter uma influência negativa em muitos aspectos da prontidão de interação do site.  

Isso geralmente ocorre se um site depende de buscas de dados em cascata e se grande parte da execução do script ocorre no cliente. 

Aqui está o que você pode fazer e recomendar: 

  • Dependendo das pontuações de FID, TTI e TBT informadas pelo Google PageSpeed ​​Insights ou Lighthouse, você pode recomendar algumas otimizações de busca de dados JavaScript. 

As otimizações de JavaScript a serem recomendadas incluem táticas, como:

  • Minimizando buscas de dados em cascata. 
  • Minimizando a quantidade de JavaScript a ser processada e executada no cliente. 
  • As táticas que compartilhei com você anteriormente neste guia (minimização e compactação de JavaScript, adiamento de JavaScript não usado e minimização de polyfills não usados). 

Observe que deve ser o desenvolvedor quem toma a decisão final sobre como otimizar o JavaScript no site. 

22. Verifique se a execução de script de terceiros afeta negativamente a prontidão de interação. 

A execução de scripts de terceiros (especialmente se for pesada) pode ter um impacto negativo na latência de interação do site. 

Os scripts de terceiros podem manter o thread principal periodicamente ocupado e sem resposta. Felizmente, existem algumas práticas recomendadas de execução de script de terceiros, como carregamento sob demanda. 

Aqui está o que você pode fazer e recomendar:

  • Teste o site com o Google PageSpeed ​​Insights para ver se os scripts de terceiros influenciam negativamente as métricas, como FID, TTB e TTI. 
  • Verifique se o site inclui análises e tags de terceiros que afetam a latência de interação.
  • Verifique se os scripts de terceiros se antecipam aos scripts primários no que diz respeito à sua prioridade e largura de banda no thread principal. Você pode verificar isso no Chrome DevTools em Rede.

Relate suas descobertas e sugira possíveis técnicas de otimização, como:

  • Carregar anúncios abaixo da dobra depois de rolarem mais para perto da janela de visualização 
  • Priorizando o carregamento de scripts. 

A decisão final sobre quais scripts devem ser carregados mais cedo ou mais tarde deve ser feita pelo desenvolvedor.

23. Verifique se um web worker é ou pode ser usado (Comlink, Workway, Workerize).  

Graças aos web workers, o JavaScript pode ser executado em um thread em segundo plano, o que pode diminuir o tempo de bloqueio do thread principal e melhorar o FID. 

Uma das principais causas do longo atraso de entrada e da baixa disponibilidade geral de interação é um thread principal bloqueado. 

Aqui está o que fazer e recomendar: 

  • Teste o site com Google PageSpeed ​​Insights, Lighthouse e Chrome DevTools para verificar se o thread principal está bloqueado e o que o bloqueia. 

Dependendo do tipo de site, você pode recomendar o uso de um dos seguintes web workers

  • Comlink
  • Workway
  • Workerize 

Assim como nos pontos anteriores, cabe ao desenvolvedor tomar a decisão final sobre quais otimizações implementar exatamente.

24. Verifique se o JavaScript não utilizado é adiado (ver ponto 10).

Uma das melhores maneiras de reduzir a quantidade de JavaScript a ser executada em uma página da web é adiar ou remover inteiramente o JavaScript não utilizado. 

Ao adiar o JavaScript não utilizado, você pode melhorar tanto o Largest Contentful Paint quanto o First Input Delay.

Volte ao ponto 10 para ver instruções mais detalhadas sobre como adiar o JavaScript não utilizado. 

25. Verifique se os polyfills não utilizados são minimizados (consulte o ponto 11).  

Outra ótima maneira de reduzir o tempo de execução do JavaScript é minimizando polyfills não utilizados. 

Ao minimizar polyfills não usados, você pode melhorar o FID e o LCP.

Volte ao ponto 11 para ver instruções mais detalhadas sobre como minimizar polyfills não utilizados.  

Cumulative Layout Shit (CLS)

Cumulative Layout Shit (CLS) mede a estabilidade visual de um site. Um site fornecerá uma boa experiência do usuário se o CLS de suas páginas for igual ou inferior a 0,1. 

auditoria-core-web-vitals-lista-de-verificacao-de-35-etapas-com-correcoes-exemplos-e-muito-mais-14

Felizmente, existem muitas ferramentas que você pode usar para medir o CLS. 

As ferramentas de laboratório testam as páginas em um ambiente sintético, de modo que os valores CLS relatados por elas podem ser diferentes da experiência dos usuários do mundo real ao interagir com o site.

As ferramentas de campo para medir a mudança cumulativa de layout:

As ferramentas de laboratório para medir a mudança cumulativa de layout: 

Para os fins desta auditoria, recomendo que você use o Google PageSpeed ​​Insights e o relatório GSC Core Web Vitals para examinar os dados de campo no CLS. 

Com relação aos dados de laboratório, use Chrome DevTools, Lighthouse e WebPageTest para analisar CLS usando diferentes configurações e resoluções de tela. O Cumulative Layout Shift Gif Generator também pode ser muito divertido. Quanto mais ferramentas você usar, melhor e mais detalhada será sua auditoria. 

26. Verifique se há elementos de imagem ou vídeo sem dimensões. 

Imagens e vídeos sem as dimensões especificadas (especialmente na seção acima da dobra) podem causar mudanças de layout. 

Para evitar mudanças de layout, a regra é sempre incluir os atributos de altura e largura em imagens e vídeos. Também é possível usar as caixas de proporção de aspecto CSS que permitirão ao navegador alocar a quantidade necessária de espaço enquanto a imagem ou vídeo está sendo carregado. 

Aqui está o que fazer e recomendar:

  • Teste o site com o Google PageSpeed ​​Insights e Lighthouse e - dependendo da pontuação do CLS - recomende reservar a quantidade correta de espaço para elementos de imagem ou vídeo.

Recomende que os atributos de tamanho de largura e altura sejam definidos normalmente. Aqui está o código de exemplo: 

<!-- set a 640:360 i.e a 16:9 - aspect ratio -->

<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons" />

Todos os navegadores modernos definirão a proporção padrão das imagens com base nos tamanhos especificados, o que evitará mudanças de layout. 

27. Verifique se há espaço reservado estaticamente para o local do anúncio. 

Anúncios - especialmente se forem dinâmicos - são uma das causas mais populares de alterações de layout em sites.  

Existem muitas maneiras pelas quais os anúncios podem causar alterações de layout em uma página. A situação mais comum inclui inserir o contêiner do anúncio no DOM e redimensionar o contêiner do anúncio. 

A melhor maneira de evitar esses tipos de mudanças de layout é reservar espaço estaticamente para o local do anúncio. 

Aqui está o que você pode fazer e recomendar: 

  • Teste a página da web com a ferramenta Google PageSpeed ​​Insights para verificar sua pontuação CLS. 
  • Se possível, analise os dados fornecidos pelo relatório GSC Core Web Vitals.
  • Também recomendo analisar a pontuação Cumulative Layout Shift com outras ferramentas (como Chrome DevTools, Lighthouse e WebPageTest ) e usar diferentes resoluções de tela. 

Se houver problemas com o CLS, determine se esse é o anúncio culpado. Se for o anúncio, você pode recomendar um dos seguintes:

  • Reserve espaço estaticamente para o local do anúncio estilizando o elemento antes que a biblioteca de tags de anúncio seja carregada. 
  • Os anúncios colocados no fluxo de conteúdo também devem ter o tamanho do slot reservado, mas não devem causar problemas de CLS se forem carregados fora da tela. 

28. Verifique se os anúncios são colocados perto do topo da janela de visualização. 

Anúncios colocados perto do topo da janela de visualização (anúncios não fixos) também podem levar à pontuação baixa da métrica CLS. 

Os sites que usam anúncios não fixos na parte superior da janela de visualização devem ter cuidado extra para evitar ou minimizar as mudanças de layout. 

Aqui está o que você pode fazer e recomendar:

  • Verifique a página com a ferramenta Google PageSpeed ​​Insights para ver sua pontuação CLS. 
  • O relatório Core Web Vitals do Google Search Console também contém dados de campo valiosos sobre CLS.  
  • Verifique o valor da métrica CLS relatado por outras ferramentas, como Chrome DevTools e WebPageTest. Certifique-se de executar testes com diferentes resoluções de tela. 
  • Se houver problemas com o CLS, determine se esse é o anúncio culpado. 

Se for o anúncio colocado próximo ao topo da janela de visualização, você pode recomendar:

  • Mover o anúncio abaixo para que não seja colocado próximo ao topo da janela de visualização ou movê-lo completamente para fora da primeira tela.
  • Reservar espaço suficiente para o slot (conforme recomendado no ponto anterior). 

29. Verifique se o espaço reservado está recolhido quando nenhum anúncio é retornado. 

Mudanças de layout também podem ocorrer se o espaço reservado do anúncio for recolhido quando nenhum anúncio for retornado. 

A melhor maneira de evitar esse tipo de mudança de layout é mostrar o marcador de posição do anúncio, mesmo que o anúncio não seja retornado. 

Aqui está o que você pode fazer e recomendar: 

  • Teste a página da web com mais de uma ferramenta para ver como ela se comporta em diferentes cenários de anúncios.
  • Pode ser bastante desafiador replicar a situação em que nenhum anúncio é retornado e o espaço reservado é recolhido. Você pode tentar bloquear o código do anúncio e examinar o que acontece (você pode usar um bloqueador de anúncios para isso).  

Se o espaço reservado para anúncios que recolhe é o principal culpado, você pode recomendar o seguinte:

  • Reservando o maior espaço de anúncio possível. 
  • Sempre mostrando o marcador de posição do anúncio. 

As recomendações acima podem resultar em um espaço em branco, mas evitarão mudanças de layout.

30. Verifique se há espaço suficiente reservado para incorporações e iframes. 

As incorporações, como vídeos do YouTube, mapas do Google ou postagens de mídia social também podem causar mudanças de layout se não houver espaço suficiente reservado para eles. 

As incorporações podem ter a forma de um iframe embed, um snippet de HTML embutido ou um HTML substituto com uma tag JS. As plataformas que permitem a incorporação (WordPress, por exemplo) nem sempre sabem qual será o tamanho de uma incorporação e, portanto, não reserva espaço suficiente para essas incorporações. Isso, obviamente, leva a mudanças de layout.

Aqui está o que você pode fazer e recomendar: 

  • Teste a página da web com mais de uma ferramenta para analisar diferentes cenários de mudanças cumulativas de layout. 

Se você descobrir que é uma incorporação a culpada pela pontuação baixa do CLS de um site, você pode recomendar o seguinte:

  • Pré-calcule o espaço necessário para incorporações com um substituto ou espaço reservado.
  • Determine o tamanho da incorporação inspecionando-a com DevTools.
  • Defina um espaço reservado levando em consideração as dimensões da incorporação inspecionada. 

Certifique-se de que o desenvolvedor tome a decisão final sobre o que deve ser implementado e como. 

31. Verifique se o novo conteúdo foi inserido acima do conteúdo existente. 

Mudanças inesperadas de layout podem ocorrer se o novo conteúdo for inserido acima do conteúdo existente (por exemplo, conteúdo que aparece na parte inferior ou superior da janela de visualização). 

Esses tipos de mudanças cumulativas de layout geralmente são causados ​​por banners e formulários que mudam o restante do conteúdo. Eles geralmente incluem elementos, como inscrições em boletins informativos, caixas de conteúdo relacionados ou avisos de cookies. 

A única situação em que é normal inserir novo conteúdo acima do conteúdo existente é quando isso é feito em resposta à interação do usuário.

Aqui está o que você pode fazer e recomendar:

  • Examine a página da web em detalhes com o uso de pelo menos 2 ou 3 das ferramentas recomendadas para verificar diferentes cenários de mudança de layout. 
  • Se você determinar que a culpa é do novo conteúdo inserido sobre o existente, pode simplesmente recomendar a reserva do espaço necessário na janela de visualização (semelhante ao que você deve fazer com os anúncios). Isso pode ser feito usando uma interface do usuário esqueleto ou um espaço reservado. 

32. Verifique se a fonte substituta foi trocada por uma nova fonte (FOUT)

O Flash de texto sem estilo (Flash of Unstyled Text - FOUT) que pode acontecer durante o processo de download e renderização de fontes pode causar mudanças no layout. 

O Flash de texto sem estilo aparece quando a fonte substituta em uma página da web é trocada por uma nova fonte durante o carregamento. 

Aqui está o que fazer e recomendar:

  • A ferramenta Google PageSpeed ​​Insights indicará se a página da web tem problemas com fontes que causam FOUT. 
  • Recomende usar font-display: optional ou / e usar <link rel="preload">. 
  • A melhor solução a ser recomendada aqui é pré - carregar fontes opcionais. 

33. Verifique se o texto “invisível” é exibido até que uma nova fonte seja renderizada (FOIT)

O Flash de texto invisível (Flash of Invisible Text - FOIT) é outro problema comum que pode causar mudanças de layout em uma página da web. 

O Flash de texto invisível ocorre quando o texto “invisível” é exibido durante o processo de renderização de fontes da web. 

As recomendações e correções são as mesmas acima (para FOUT).  

34. Verifique se as principais fontes da Web estão pré-carregadas.

Se o site não pré-carrega fontes da web, é muito provável que haja mudanças de layout durante o processo de renderização e pré-carregamento. 

A melhor maneira de evitar quaisquer problemas de layout causados ​​por fontes da web é pré-carregar as fontes principais com o uso de <link rel="preload">. 

As recomendações e correções:

  • Teste a página da web com o Google PageSpeed ​​Insights e o relatório Core Web Vitals do Google Search Console. 
  • A ferramenta Google PageSpeed ​​Insights indicará se há algum problema com a renderização ou download de fontes. 

Se você determinar que essas são fontes da web que causam mudanças de layout, você deve recomendar o seguinte:

  • Usando font-display: optional 
  • Usando API de carregamento de fonte
  • Usando <link rel="preload">para as principais fontes da web
  • Combinando <link rel="preload">com exibição de fonte: opcional 

35. Verifique se há animações de propriedades que acionam mudanças de layout. 

Algumas propriedades CSS podem acionar mudanças de layout que levam a uma experiência do usuário insatisfatória. 

A maneira mais simples de evitar mudanças de layout resultantes de mudanças nos valores de propriedade CSS, é usar animações de transformação em vez de animações de propriedades. 

Exemplos de valores que podem causar mudanças de layout incluem box-shadow e box-sizing. 

Aqui está o que fazer e recomendar:

  • Teste a página da web com o Google PageSpeed ​​Insights e WebPageTest. 
  • Analise a cascata e determine o que causa mudanças de layout. 
  • Se você acha que as animações de propriedades são as culpadas, verifique a leitura adicional sobre gatilhos CSS e animações de alto desempenho.

Sinta-se à vontade para usar esta lista de verificação técnica de SEO em seu trabalho de auditoria diário. 

Core Web Vitals são “apenas” um de um total de cinco fatores de experiência da página do Google e um dos mais de 200 fatores de classificação do Google. 

Para dar ao site uma vantagem de SEO, também recomendo que você faça uma auditoria técnica aprofundada de SEO que verifica o site em termos de otimizações técnicas.  

E uma vez que uma experiência de página é um tópico tão quente agora, também sugiro que você faça uma auditoria de experiência de página do Google.

Novos tipos e modelos de auditoria de SEO estarão disponíveis em breve! Fique atento. 

Compartilhe esta auditoria Core Web Vitals com outros SEOs para que eles possam se tornar melhores SEOs! Obrigado! ❤️

*Texto retirado e traduzido de Core Web Vitals Audit: 35-Step Checklist With Fixes, Examples, And More.




Últimas Postagens WebPeak

Ferramentas de WebMaster

Novidade: Google lança Search Console Insights

Marketing

Industrias no ecommerce: mudanças no comportamento do consumidor

Marketing

Como PIX mudou o comportamento e compra online

E-Commerce

Como criar eventos Google Tag Manager