Medindo e otimizando o Google Core Web Vitals: um guia técnico de SEO

Coletar dados sobre o desempenho do seu site é o primeiro passo para proporcionar uma ótima experiência ao usuário. Ao longo dos anos, o Google forneceu várias ferramentas para avaliar e gerar relatórios sobre o desempenho da web.

Entre eles estão Core Web Vitals, um conjunto de sinais de desempenho que o Google considera críticos para todas as experiências na web.

Este artigo aborda o conjunto atual de Core Web Vitals e dicas e ferramentas importantes para melhorar o desempenho da web e oferecer uma boa experiência de página aos usuários.

Uma olhada na evolução do desempenho da web

Já se foi o tempo em que melhorar o desempenho do site era algo simples.

No passado, recursos inchados e conexões lentas muitas vezes atrapalhavam os sites. Mas você pode superar os concorrentes compactando algumas imagens, ativando a compactação de texto ou reduzindo suas folhas de estilo e módulos JavaScript.

Hoje, as velocidades de conexão são mais rápidas. A maioria dos recursos é compactada por padrão e muitos plug-ins lidam com compactação de imagens, implantação de cache, etc.

A busca do Google por uma web mais rápida persiste. O PageSpeed ​​​​Insights (PSI) ainda está ativo no web.dev, servindo como a melhor ferramenta para avaliar carregamentos de páginas individuais.

Embora muitos achem que as classificações PSI são desnecessariamente punitivas, ainda é o mais próximo que podemos chegar de como o Google pode avaliar e classificar os sites por meio de sinais de velocidade da página.

Para passar na última iteração do teste de velocidade de página do Google, você precisará satisfazer a avaliação Core Web Vitals.

Compreendendo os principais sinais vitais da Web

Core Web Vitals são um conjunto de métricas integradas aos sinais mais amplos de pesquisa de experiência de página introduzidos em 2021. Cada métrica “representa uma faceta distinta da experiência do usuário, é mensurável em campo e reflete a experiência do mundo real de um usuário crítico- resultado centrado”, de acordo com o Google.

O conjunto atual de métricas Core Web Vitals inclui:

• Primeira pintura com conteúdo
• Atraso na primeira entrada (a ser substituído pela interação com a próxima pintura)
• Interação com a próxima pintura
• Hora do primeiro byte
• Maior pintura com conteúdo
• Mudança cumulativa de layout

Web.dev explica como cada métrica funciona da seguinte maneira.

Primeira pintura com conteúdo (FCP)

“A métrica First Contentful Paint (FCP) mede o tempo desde o início do carregamento da página até o momento em que qualquer parte do conteúdo da página é renderizada na tela. Para esta métrica, “conteúdo” refere-se a texto, imagens (incluindo imagens de fundo), elementos <svg> ou elementos <canvas> não brancos.”

O que isso significa para SEOs técnicos

O FCP é bastante fácil de entender. À medida que uma página web carrega, certos elementos chegam (ou “são pintados”) antes de outros. Neste contexto, “pintura” significa renderização na tela.

Depois que qualquer parte da página for renderizada – digamos que a barra de navegação principal seja carregada antes de outros elementos – o FCP será registrado nesse ponto.

Pense nisso como a rapidez com que a página começa a carregar visivelmente para os usuários. O carregamento da página não será concluído, mas terá sido iniciado.

Atraso da primeira entrada (FID)

“O FID mede o tempo desde a primeira interação de um usuário com uma página (ou seja, quando ele clica em um link, toca em um botão ou usa um controle personalizado baseado em JavaScript) até o momento em que o navegador é realmente capaz de começar processar manipuladores de eventos em resposta a essa interação.”

O que isso significa para SEOs técnicos

FID é uma métrica de capacidade de resposta de interação do usuário definida para ser substituída pela Interaction to Next Paint (INP) em março de 2024.

Se um usuário interagir com um elemento na página (ou seja, um link, classificar uma tabela ou aplicar navegação facetada), quanto tempo levará para o site começar a processar essa solicitação?

Interação com a próxima pintura (INP)

“INP é uma métrica que avalia a capacidade de resposta geral de uma página às interações do usuário, observando a latência de todas as interações de clique, toque e teclado que ocorrem durante a vida útil da visita de um usuário a uma página. O valor final do INP é a interação mais longa observada, ignorando os valores discrepantes.”

O que isso significa para SEOs técnicos

Conforme mencionado, o INP substituirá o FID como Core Web Vital em março de 2024.

O INP considera informações mais profundas (aparentemente remontando ao teclado) e é provavelmente mais detalhada e sofisticada.

Tempo até o primeiro byte (TTFB)

“TTFB é uma métrica que mede o tempo entre a solicitação de um recurso e o momento em que o primeiro byte de uma resposta começa a chegar.”

O que isso significa para SEOs técnicos

Depois que um “recurso” (ou seja, imagem incorporada, módulo JavaScript, folha de estilo CSS, etc.) for solicitado, quanto tempo levará para o site começar a entregar esse recurso?

Digamos que você visite uma página da web e nessa página haja uma imagem incorporada. Ele começa a carregar, mas ainda não terminou de carregar. Quanto tempo até que o primeiro byte dessa imagem seja entregue do servidor para o cliente (navegador da web)?

Maior pintura com conteúdo (LCP)

“A métrica Largest Contentful Paint (LCP) relata o tempo de renderização da maior imagem ou bloco de texto visível na janela de visualização, em relação a quando a página começou a carregar.”

O que isso significa para SEOs técnicos

LCP é uma das métricas mais importantes, mas a mais difícil de satisfazer.

Depois que a maior parte da mídia visual (ou seja, texto ou imagem) for carregada, o LCP será registrado.

Você pode ler isso como: quanto tempo leva para carregar a maior parte do conteúdo principal de uma página?

Talvez ainda haja pequenos bits sendo carregados mais abaixo na página e coisas que a maioria dos usuários não notará.

Mas, no momento em que o LCP é registrado, a parte grande e óbvia da sua página já foi carregada. Se demorar muito para que isso ocorra, você falhará na verificação do LCP.

Mudança cumulativa de layout (CLS)

“CLS é uma medida da maior explosão de pontuações de mudança de layout para cada mudança inesperada de layout que ocorre durante toda a vida útil de uma página.

Uma mudança de layout ocorre sempre que um elemento visível muda sua posição de um quadro renderizado para o próximo. (Veja abaixo detalhes sobre como as pontuações de mudança de layout individuais são calculadas.)

Uma explosão de mudanças de layout, conhecida como janela de sessão, ocorre quando uma ou mais mudanças de layout individuais ocorrem em rápida sucessão, com menos de 1 segundo entre cada mudança e um máximo de 5 segundos para a duração total da janela.

A maior explosão é a janela da sessão com a pontuação cumulativa máxima de todas as mudanças de layout dentro dessa janela.”

O que isso significa para SEOs técnicos

Antigamente, quando a otimização da velocidade da página era mais simples, muitos proprietários de sites perceberam que poderiam obter classificações de velocidade de página incrivelmente altas simplesmente adiando todos os recursos de bloqueio de renderização (geralmente, folhas CSS e módulos JavaScript).

Isso foi ótimo para acelerar o carregamento da página, mas tornou a web uma experiência de navegação mais problemática e irritante.

Se o seu CSS – que controla todo o estilo da sua página – for adiado, o conteúdo da página poderá ser carregado antes que as regras CSS sejam aplicadas.

Isso significa que o conteúdo da sua página será carregado sem estilo e, em seguida, saltará um pouco conforme o CSS for carregado.

Isso é realmente irritante se você carrega uma página e clica em um link, mas o link salta e você clica no link errado.

Se você tem um pouco de TOC como eu, essas experiências são absolutamente irritantes (mesmo que custem apenas alguns segundos).

Devido à tentativa dos proprietários de sites de “jogar” as classificações de velocidade da página adiando todos os recursos, o Google precisava de uma contramétrica, que compensasse todos os ganhos de velocidade da página em relação ao déficit de experiência do usuário.

Insira a mudança cumulativa de layout (CLS). Este é um cliente complicado, que vai arruinar o seu dia se você tentar aplicar aumentos de velocidade da página de maneira geral, sem pensar nos usuários.

O CLS basicamente analisará o carregamento da sua página em busca de mudanças problemáticas e regras CSS atrasadas.

Se houver muitos, você será reprovado na avaliação Core Web Vitals, apesar de ter satisfeito todas as métricas relacionadas à velocidade.

Avaliando seus Core Web Vitals para melhores resultados de UX e SEO

Uma das melhores maneiras de analisar o desempenho de uma única página da web é carregá-la no PageSpeed ​​​​Insights. A visualização é dividida em uma combinação de:

• Dados em nível de URL.
• Dados de origem (nível de domínio).
• Dados de laboratório.
• Dados de campo.

Para entender isso, precisamos ver um exemplo:

https://pagespeed.web.dev/análise/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Aqui, podemos ver as classificações e métricas de velocidade da página da página inicial do TechCrunch.

Acima, você pode ver que a avaliação Core Web Vitals falhou.

Em uma web que prioriza dispositivos móveis, é importante selecionar a guia Resultados para dispositivos móveis , que deve ser renderizada por padrão (esses são os resultados que realmente importam).

Selecione o botão Origem para ver a média dos dados gerais em todo o domínio do seu site, em vez de apenas na página inicial (ou em qualquer página que você colocar para digitalizar).

Mais abaixo na página, você verá a antiga e familiar classificação numérica da velocidade da página:

Então, qual é a diferença entre a nova avaliação Core Web Vitals e a antiga classificação de velocidade da página?

Essencialmente, a nova avaliação Core Web Vitals (Aprovado/Reprovado) é baseada em dados de campo (usuário real).

A classificação numérica antiga é baseada em rastreamentos simulados de dispositivos móveis e dados de laboratório, que são apenas estimativas.

Essencialmente, o Google mudou para a avaliação Core Web Vitals em termos de modificação das classificações de pesquisa.

Para ser claro, os dados simulados do laboratório podem fornecer uma boa análise do que está errado, mas o Google não utiliza essa classificação numérica em seus algoritmos de classificação.

Por outro lado, a avaliação Core Web Vitals não oferece muitas informações granulares. No entanto, esta avaliação é considerada nos algoritmos de classificação do Google.

Portanto, seu principal objetivo é usar diagnósticos de laboratório mais avançados para que você eventualmente passe na avaliação Core Web Vitals (derivada de dados de campo).

Lembre-se de que quando você faz alterações em seu site, embora a classificação numérica possa observar alterações imediatamente, você terá que esperar que o Google extraia mais dados de campo antes de poder passar na avaliação Core Web Vitals.

Você notará que tanto a avaliação Core Web Vitals quanto a antiga classificação de velocidade da página utilizam algumas das mesmas métricas.

Por exemplo, ambos fazem referência ao First Contentful Paint (FCP), ao Largest Contentful Paint (LCP) e ao Cumulative Layout Shift (CLS).

De certa forma, os tipos de métricas examinadas por cada sistema de classificação são bastante semelhantes. É o nível de detalhe e a fonte dos dados examinados que é diferente.

Você deve tentar passar na avaliação Core Web Vitals baseada em campo. No entanto, como os dados não são muito ricos, você pode querer aproveitar os dados e diagnósticos laboratoriais tradicionais para progredir.

A esperança é que você consiga passar na avaliação Core Web Vitals abordando as oportunidades de laboratório e diagnósticos. Mas lembre-se de que esses dois testes não estão intrinsecamente conectados.

Avaliando seus CWVs por meio do PageSpeed ​​​​Insights

Agora que você conhece as principais métricas do Core Web Vitals e como elas podem ser tecnicamente satisfeitas, é hora de analisar um exemplo.

Voltemos ao nosso exame do TechCrunch:

https://pagespeed.web.dev/análise/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Aqui, o FID está satisfeito e o INP falha apenas por uma margem estreita.

O CLS tem alguns problemas, mas os principais problemas são com o LCP e o FCP.

Vamos ver o que o PageSpeed ​​​​Insights tem a dizer em termos de oportunidades e diagnósticos .

Devemos agora mudar dos dados de campo para os dados de laboratório e tentar isolar quaisquer padrões que possam estar impactando os Core Web Vitals:

Acima, você pode ver uma pequena subnavegação no canto superior direito em caixa verde.

Você pode usar isso para restringir as diferentes oportunidades e diagnósticos a determinadas métricas do Core Web Vitals.

Neste caso, porém, os dados contam uma história muito clara, sem restringir.

Em primeiro lugar, somos instruídos a reduzir o JavaScript não utilizado. Isso significa que às vezes o JavaScript está sendo carregado sem ser executado.

Também há notas para reduzir CSS não utilizado. Em outras palavras, algum estilo CSS está sendo carregado e não está sendo aplicado (problema semelhante).

Também somos instruídos a eliminar recursos de bloqueio de renderização, que quase sempre estão relacionados a módulos JavaScript e folhas CSS.

Os recursos de bloqueio de renderização devem ser adiados para impedi-los de bloquear o carregamento de uma página. No entanto, como já explorámos, isto pode perturbar a classificação CLS.

Devido a isso, seria sensato começar a criar um caminho de renderização CSS crítico e um caminho crítico de renderização JavaScript. Fazer isso irá incorporar o JavaScript e CSS necessários acima da dobra, enquanto adia o resto.

Essa abordagem permite que o proprietário do site satisfaça as demandas de carregamento da página enquanto se equilibra com a métrica CLS. Não é uma coisa fácil de fazer e geralmente requer um desenvolvedor web sênior.

Como também encontramos CSS e JavaScript não utilizados, também podemos emitir uma auditoria geral do código JavaScript para ver se o JavaScript poderia ser implantado de forma mais inteligente.

Voltemos a Oportunidades e Diagnósticos :

Agora, queremos nos concentrar no diagnóstico. O Google restringe deliberadamente essas verificações por meio de conexões 4G ruins, de modo que itens como o trabalho do thread principal parecem tão longos (17 segundos).

Isto é deliberado para satisfazer usuários com baixa largura de banda e/ou dispositivos lentos que são comuns em todo o mundo.

Quero chamar sua atenção aqui para “Minimizar o trabalho do thread principal”. Essa entrada única costuma ser uma mina de ouro de insights.

Por padrão, a maioria das tarefas de renderização e execução de script (JavaScript) de uma página da Web são enviadas por meio do thread de processamento principal do navegador da Web do cliente (um único thread de processamento). Você pode entender como isso causa gargalos significativos no carregamento da página.

Mesmo que todo o seu JavaScript seja perfeitamente reduzido e enviado rapidamente ao navegador do usuário, ele deve aguardar em uma fila de processamento de thread único por padrão, o que significa que apenas um script pode ser executado por vez.

Portanto, enviar rapidamente cargas de JavaScript para o seu usuário é o equivalente a disparar uma mangueira contra uma parede de tijolos com uma lacuna de um centímetro.

Bom trabalho entregando, mas nem tudo vai dar certo!

Cada vez mais, o Google está empurrando a velocidade de resposta do lado do cliente como nossa responsabilidade. Goste ou agite, é assim que é (então é melhor você se familiarizar).

Você pode dizer frustrado: “Por que é assim!? Os navegadores da Web tiveram acesso a vários threads de processamento durante anos, até mesmo os navegadores móveis o alcançaram. Não há necessidade de que as coisas sejam tão estranhas, não é?

Na verdade sim. Alguns scripts dependem da saída de outros scripts antes de serem executados.

Com toda a probabilidade, se todos os navegadores de repente começassem a processar todo o JavaScript em paralelo, fora de sequência, a maior parte da web provavelmente travaria e queimaria.

Portanto, há uma boa razão para que a execução sequencial de scripts seja o comportamento padrão dos navegadores modernos. Continuo enfatizando a palavra “padrão”. Por que é que?

É porque existem outras opções. Uma delas é evitar que o navegador do cliente processe quaisquer scripts, processando-os em nome do usuário. Isso é conhecido como renderização do lado do servidor (SSR).

É uma ferramenta poderosa para desembaraçar nós de execução de JavaScript do lado do cliente, mas também é muito cara.

Seu servidor deve processar todas as solicitações de script (de todos os usuários) mais rápido do que o navegador do usuário médio processa um único script. Deixe isso penetrar por um momento.

Não é fã dessa opção? OK, vamos explorar a paralelização do JavaScript. A ideia básica é aproveitar os web workers para definir quais scripts serão carregados em sequência e quais podem ser carregados em paralelo.

Embora você possa forçar o carregamento do JavaScript em paralelo, fazer isso por padrão é extremamente desaconselhável. A integração de tecnologias como esta mitigaria em grande medida a necessidade de SSR na maioria dos casos.

No entanto, será muito complicado de implementar e exigirá (você adivinhou!) O tempo de um desenvolvedor web sênior.

O mesmo cara que você contratou para fazer a auditoria completa do código JavaScript também pode ajudá-lo com isso. Se você combinar a paralelização de JavaScript com um caminho crítico de renderização de JavaScript, você estará realmente voando.

Neste exemplo, aqui está o que é realmente interessante:

Você pode ver imediatamente que enquanto o thread principal fica ocupado por 17 segundos, a execução do JavaScript é responsável por 12 segundos.

Isso significa que 12 segundos dos 17 segundos de trabalho do thread são execução de JavaScript? Isso é altamente provável.

Sabemos que todo o JavaScript é enviado através do thread principal por padrão.

É também assim que o WordPress, o CMS ativo, é configurado por padrão.

Como este site está executando o WordPress, todos esses 12 segundos de tempo de execução do JavaScript provavelmente vêm dos 17 segundos de trabalho do thread principal.

Esse é um ótimo insight porque nos diz que a maior parte do tempo do thread de processamento principal é gasto na execução de JavaScript. E olhando para o número de scripts referenciados, não é difícil de acreditar.

Levando a cruzada para o Chrome Dev Tools

É hora de ser técnico e remover as rodinhas.

Abra uma nova instância do Chrome. Você deve abrir um perfil de convidado para garantir que não haja confusão ou plug-ins habilitados para sobrecarregar nossas descobertas.

Lembre-se: execute essas ações a partir de um perfil de convidado limpo do Chrome.

Carregue o site que deseja analisar. No nosso caso, é o TechCrunch.

Aceite cookies conforme necessário. Assim que a página for carregada, abra o Chrome DevTools (clique com o botão direito em uma página e selecione Inspecionar ).

Navegue até Desempenho > Capturas de tela.

Aperte o botão recarregar para registrar o carregamento da página. Será então gerado um relatório:

É aqui que todos precisamos respirar fundo e tentar não entrar em pânico.

Acima, em caixa verde, você pode ver um painel fino que ilustra as solicitações ao longo do tempo.

Dentro desta caixa, você pode arrastar o mouse para selecionar um intervalo de tempo e o resto da página e a análise se adaptarão automaticamente.

A região que selecionei manualmente é a área coberta por uma caixa azul semitransparente.

É aí que acontece o carregamento da página principal e o que estou interessado em examinar.

Neste caso, selecionei aproximadamente o intervalo de tempo e eventos entre 32 ms e 2,97 segundos. Vamos focar nosso olhar no interior do fio principal:

Você sabe que antes eu estava dizendo que a maioria das tarefas de renderização e execuções de JavaScript são forçadas através do gargalo do thread principal?

Bem, agora estamos olhando o interior desse segmento principal ao longo do tempo. E sim, em amarelo você pode ver muitas tarefas de script.

Nas primeiras linhas, conforme o tempo passa, há cada vez mais pedaços amarelos escuros confirmando todos os scripts em execução e quanto tempo eles levam para serem processados. Você pode clicar em pedaços individuais da barra para obter uma leitura de cada item.

Embora este seja um visual poderoso, você encontrará um visual mais poderoso na seção Resumo :

Isso resume todos os dados granulares, divididos em seções temáticas simples (por exemplo, Scripting , Carregamento , Renderização ) através do meio visual fácil de digerir de um gráfico de rosca.

Como você pode ver, o script (execução do script) ocupa a maior parte do carregamento da página. Portanto, nossa suposição anterior a partir da combinação de dados de campo e de laboratório do Google, que apontou o dedo para gargalos de execução de JavaScript no thread principal, parece ter sido precisa.

Em 2023, este é um dos problemas mais encontrados, com poucas soluções simples e prontas para uso.

É complexo criar caminhos críticos de renderização de JavaScript. É preciso experiência para realizar auditorias de código JavaScript e não é tão simples adotar a paralelização de JavaScript ou SSR.

Agora vamos dar uma olhada na árvore de chamadas :

Call Tree costuma ser mais útil que Bottom-Up .

Os dados são semelhantes, mas o Call Tree agrupará tematicamente as tarefas em grupos úteis, como Evaluate Script (execução de script).

Você pode então clicar em um grupo, expandi-lo e ver os scripts e quanto tempo eles demoraram para carregar. 11% do tempo foi gasto para carregar pubads_impl.jsm enquanto 6% do tempo foi gasto para carregar opus.js .

Não sei o que são esses módulos (e talvez você também não), mas é aqui que a jornada de otimização geralmente começa.

Agora podemos dar um passo atrás para:

• Pesquise esses scripts no Google e veja se eles fazem parte de bibliotecas de terceiros, o que fazem e qual é o impacto.
• Consulte o desenvolvedor sobre como eles podem ser implantados de forma mais inteligente.
• Limite o problema aos recursos individuais e procure alternativas.
• Enfrente o déficit de desempenho (ou, alternativamente, lute por mais recursos/largura de banda, um ambiente de hospedagem forte – se isso for realmente necessário).

Outras ferramentas para medir e otimizar Core Web Vitals

Se você conseguiu ficar comigo até aqui, parabéns. Em termos de Core Web Vitals profundo e análise de velocidade da página, usamos apenas:

• Informações do PageSpeed
• Chrome DevTools (guia Desempenho )

Sim, você realmente pode ser tão magro. No entanto, existem outras ferramentas que podem ser de grande ajuda para você:

• GTMetrix : Especialmente útil por seu gráfico em cascata (requer uma conta gratuita para cascata), que você pode aprender a ler aqui. Não se esqueça de que o GTMetrix será executado sem restrições por padrão, proporcionando resultados excessivamente favoráveis. Certifique-se de configurá-lo para uma conexão LTE.
• Google Search Console : se você configurar e verificar seu site, poderá ver muitos dados de desempenho e usabilidade ao longo do tempo, incluindo métricas Core Web Vitals em várias páginas (agregadas).
• Screaming Frog SEO Spider : pode ser conectado à API de velocidade da página, para permitir a busca em massa de notas de aprovação ou reprovação do Core Web Vitals (para várias páginas). Se você estiver usando a API gratuita de velocidade de página, não a use de maneira irracional

Melhorar as classificações de velocidade da sua página costumava ser tão simples quanto compactar e enviar algumas imagens.

Hoje em dia? É uma cruzada complexa do Core Web Vitals.

Prepare-se para se envolver totalmente. Qualquer coisa menos resultará em fracasso.