Como Melhorar o Core Web Vitals para SEO? Core Web Vitals são três novas métricas de desempenho que em breve impactarão a classificação de SEO. Aprenda como medi-los e melhorá-los para maximizar a experiência do usuário!
O Google anunciou atualizações para o algoritmo de classificação da Experiência da Página em maio de 2020. Esta atualização inclui dois destaques principais:
- Três novas métricas de desempenho serão usadas como sinais de classificação para SEO
- As notícias principais não exigem mais uma página HTML para AMP, e o desempenho se tornará um fator de classificação
A atualização é uma ótima notícia para os fãs da velocidade do site: o Google está colocando uma ênfase ainda maior na velocidade das experiências do usuário, oferecendo dois benefícios de SEO para proprietários de sites que proporcionam as experiências rápidas que os clientes esperam.
Para ter uma ideia de seu desempenho atual em relação a essas métricas, tente executar uma página por meio do PageSpeed Insights ou web.dev/measure . Essas ferramentas do Google fornecem uma pontuação de desempenho e informa como uma página se compara às novas metas de desempenho.
Essas métricas de desempenho foram projetadas para serem medidas universais de velocidade da página e bons proxies para a experiência do usuário percebida, elas devem ser medidas válidas de como a experiência é sentida em quase todas as páginas da web.
Dito isso, o Google afirmou que essas métricas estão sendo revisadas constantemente e podem mudar no futuro.
- Largest Contentful Paint é uma medida de desempenho de renderização, um bom substituto para o tempo de carregamento da página ou conteúdo DOM pronto.
- First Delay Input é uma medida de quanto tempo leva para o navegador responder a uma entrada discreta do usuário, como cliques ou toques.
- Cumulative Layout Shift é uma medida de quão instável a página era, uma soma de todas as mudanças inesperadas de layout no ciclo de vida da página.
Os valores recomendados acima são determinados a partir do 75º percentil de experiências reais do usuário: pelo menos 75% de suas visualizações de página devem exceder o valor Bom para passar nesta avaliação! Confira mais detalhes em nosso site.
Como o Google mede a velocidade
As três novas métricas de desempenho são relativamente novas no mundo do desempenho da web, como tal, atualmente são suportadas apenas por meio de API em navegadores baseados em Blink (Chrome, Chrome no Android, Chromium Edge).
Os dados que o Google usará para a atualização da experiência da página são retirados do Chrome UX Report (CRUX) , uma coleção de estatísticas de desempenho anônimas tiradas de carregamentos de páginas reais em navegadores Chrome em todo o mundo. CRUX mede todos os carregamentos de página regulares, tanto para páginas iniciais quanto para páginas intermediárias, independentemente do estado do cache. Ele não mede navegações suaves (alterações de rota) em aplicativos de página única.
Isso significa que as navegações suaves serão potencialmente penalizadas, com pontuações CLS mais altas do que o esperado e valores LCP ausentes ou injustamente altos. Infelizmente, ainda não existe uma boa solução para este problema. Isso torna ainda mais importante reduzir mudanças inesperadas de layout e otimizar o LCP tanto quanto possível!
A atualização vem com um conjunto de metas de velocidade recomendadas, que são medidas no 75º percentil nos dados CRUX, portanto, pelo menos 75% das experiências medidas devem atender ou exceder essas metas.
O cache e o status da sessão não estão disponíveis no conjunto de dados CRUX, então o valor do 75º percentil é obtido de todos os carregamentos de página, armazenados em cache ou não. O PageSpeed Insights fornecerá três conjuntos de métricas de desempenho, quando disponíveis:
- Campo – os dados de CRUX para o URL fornecido
- Resumo da origem – os dados de campo agregados de todas as suas páginas
- Laboratório – um teste executado em um servidor do Google que aplica a limitação
Se sua página não tiver tráfego suficiente para produzir os dados do campo, você obterá apenas o resultado do resumo da origem. As recomendações e os diagnósticos no PageSpeed Insights são produzidos a partir do teste de laboratório , as métricas de desempenho devem ser obtidas a partir dos resultados de campo. As recomendações devem dar uma ideia geral das áreas de melhoria que terão um impacto positivo nos resultados vitais da web.
Como Melhorar o Core Web Vitals para SEO?
Vamos falar sobre como medir, diagnosticar e melhorar cada uma das três novas métricas: LCP, FID e CLS, por sua vez. Lembre-se de que qualquer otimização para melhorar essas métricas quase certamente fará com que suas páginas pareçam mais rápidas e melhorará a experiência do usuário! Como (essenciais) os vitais da web se encaixam no ciclo de vida da página
Largest Contentful Paint (LCP)
LCP é um ponto de tempo medido quando o maior elemento acima da dobra é pintado na tela. Na maioria dos casos, será uma imagem / vídeo principal ou o bloco principal de texto da página. WebPageTest destaca o LCP com uma borda tracejada vermelha nos quadros da tira de filme
LCP é uma boa alternativa para “Tempo de carregamento da página”: ele mede tudo o que é necessário para seu site renderizar o conteúdo principal de uma página – DNS, TLS, HTML, CSS e JavaScript de bloqueio, mas não inclui scripts assíncronos ou conteúdo de carregamento lento .
O LCP ocorre apenas após a conclusão de três estágios de carregamento da página:
- HTML entregue e analisado
- Ativos de caminho crítico baixados, analisados e processados
- Recurso LCP baixado e renderizado (imagem, vídeo, fonte da web etc.)
Abreviada WebPagetest cascata que mostra que mais de 50 objetos carga antes LCP na tira de filme antes (linha LCP adicionado)
A entrega rápida de documentos é uma das coisas mais importantes que você pode fazer para melhorar a velocidade da página. Se você puder reduzir isso em 100 ms, todas as outras medidas de duração ficarão 100 ms mais rápido! A entrega rápida de documentos se resume a algumas otimizações importantes:
- DNS – DNS é o catálogo de endereços da internet. Otimize o DNS aumentando o TTL e usando um serviço DNS distribuído globalmente ( consulte esta postagem do blog para obter mais detalhes ).
- TCP – O fator de restrição no estabelecimento de uma conexão TCP é (normalmente) o tempo de ida e volta entre o usuário e o servidor. Use uma rede de distribuição de conteúdo para reduzir isso ao máximo.
- TLS – sites seguros requerem uma ou mais viagens de ida e volta adicionais para criar uma conexão segura. Certifique-se de que o grampeamento OCSP esteja habilitado no certificado do site (talvez até mesmo faça downgrade de EV para OV para conseguir isso!) E que seu servidor ou CDN esteja configurado para suporte TLSv1.3 (consulte O TLS já é rápido? ).
- TTFB – O tempo para o primeiro byte do seu site é limitado pela rapidez com que o servidor pode criar a resposta. Se possível, isso deve ser armazenado em cache em um CDN ou proxy reverso. Se o armazenamento em cache HTML não for possível (por exemplo, se houver personalização na página), certifique-se de que seu ambiente de servidor seja capaz de entregar páginas em 100 ms.
- HTML – pode parecer óbvio, mas o tamanho e a estrutura do seu documento HTML são essenciais para o desempenho. Certifique-se de que o documento HTML esteja compactado e com menos de 50 KB na rede. Preste atenção ao <head>do documento para garantir que o <title>seja o primeiro e que não haja nenhum bloqueio de <script>tags de terceiros aqui.
Depois que o HTML é baixado, o navegador analisa o documento linha por linha para encontrar recursos no caminho crítico. CSS e JavaScript na cabeça recebem prioridade muito alta, então as imagens no corpo são baixadas na ordem em que aparecem.
Se o analisador do navegador vir uma tag de script de bloqueio (ou seja, nenhum atributo asyncou defer), ele interromperá tudo o que estiver fazendo enquanto busca, analisa e executa esse script. Como tal, os scripts devem ser sempre assíncronos, quando a ordem de execução não é importante, ou adiados quando a ordem de execução é importante. Também faz sentido revisar os scripts embutidos para reduzir seu impacto.
Sempre que possível, divida seu pacote de JavaScript por página e por suporte a JavaScript moderno. Isso permitirá que você envie o menor pacote possível e use tecnologias modernas onde houver suporte. Observe que moduletem um comportamento de adiamento por padrão:
<script type=”module” src=”/app-homepage.esm.js”></script> <script nomodule src=”/app-homepage.js”></script>
A próxima etapa no caminho crítico é carregar as folhas de estilo: sem CSS, o navegador não sabe como renderizar a página, portanto, bloqueará a renderização em qualquer <link rel=”stylesheet”>tag.
Certifique-se de que o CSS seja agrupado por página para reduzir o peso desnecessário. Você pode buscar e armazenar em cache uma folha de estilo completa posteriormente no ciclo de vida da página usando o hack media = ”none” (garantindo que este arquivo não cause uma mudança de layout!):
<link rel=”stylesheet” href=”lazy.css” media=”none” onload=”this.media=’all'” >
O LCP é medido independentemente do estado do cache, portanto, certifique-se de que seus ativos estáticos (JavaScript, CSS, imagens e fontes) possam ser armazenados em cache no navegador por pelo menos uma hora com um cabeçalho de resposta como cache-control: max-age: 3600. Certifique-se também de que seus recursos de texto estão compactados com gzip ou brotli!
Um problema comum que vejo, especialmente em sites de comércio eletrônico, é um grande número de imagens não críticas que carregam no início da página, como em uma definição de mega menu.
O carregamento lento nativo é uma ótima técnica para otimizar o LCP, reduzindo a contenção da largura de banda durante o carregamento da página. O loadingatributo ainda não é suportado no Safari, mas está no WebKit e atualmente disponível no iOS Safari atrás de uma bandeira, portanto, podemos esperar suporte geral em breve! Ele é suportado em todos os navegadores que enviam dados para CRUX, então implementar agora para beneficiar os dados que irão conduzir a actualização da experiência da página.
<img src=”menu-img.jpg” alt=”…” width=”200″ height=”200″ loading=”lazy” > <img src=”hero-img.jpg” alt=”…” width=”1024″ height=”600″ loading=”eager” >
Certifique-se de que seu elemento hero tenha um loading=’eager’atributo e que as imagens abaixo da dobra ou ocultas por padrão tenham um loading=’lazy’atributo. Essa otimização simples permite que o navegador dê prioridade ao download de ativos importantes mais cedo, melhorando o LCP e a experiência do usuário. Leia mais em web.dev .
Nem é preciso dizer, mas se o elemento hero for uma imagem ou um vídeo, ele deve ser entregue no formato mais otimizado para o navegador. Isso pode significar que um serviço de terceiros como Cloudinary ou Akamai Image and Video Manager é uma boa opção para otimizar dinamicamente seu conteúdo de mídia.
O elemento hero não deve ser vinculado a JavaScript, portanto carrosséis de imagens e players de vídeo incorporados devem ser substituídos por imagens estáticas e <video>elementos nativos com um posteratributo de imagem apropriado . Se você tiver um pôster de vídeo, certifique-se de que ele esteja otimizado e use um preloadatributo válido como noneou metadatapara reduzir a contenção de largura de banda durante o carregamento da página. Leia mais sobre essas otimizações no Mozilla Developer Network.
First Delay Input (FID)
FID é uma medida de quanto tempo o navegador ficou ocupado com outras tarefas antes de poder reagir a um evento de entrada do usuário discreto, como um toque ou clique. Esta é uma indicação de quão responsiva a interface do usuário é para um usuário e quão ocupada a CPU está com o processamento de JavaScript.
A única maneira consistente de melhorar o FID sem degradar a experiência do usuário é reduzir o tempo gasto na execução do JavaScript, tanto no carregamento da página quanto durante o ciclo de vida da página. Uma maneira simples de manipular essa métrica seria ocultar seu conteúdo (talvez atrás de uma tela de carregamento / botão giratório) até que a execução do JavaScript seja concluída, para que os visitantes não tentem interagir antes de seu aplicativo estar completamente pronto. Isso provavelmente terá um impacto negativo em suas métricas de LCP e CLS, portanto, tenha cuidado!
Supondo que estamos tentando melhorar o FID e melhorar o desempenho visual, temos apenas algumas opções:
- Atrasar ou remover elementos de terceiros
- Adiar scripts não críticos
- Melhorar o desempenho JS
A primeira tarefa é executar um rastreamento de desempenho em uma página principal para ver onde o tempo do thread principal é consumido. Quaisquer grandes pedaços são motivo de preocupação e devem ser investigados.
Você pode agrupar a visualização por URL para determinar rapidamente quais scripts estão causando os problemas, neste caso o cookielaw SDK do banner é responsável por 200ms de tempo ‘próprio’, o que significa que o tempo foi gasto neste script em vez de devido às chamadas feitas por ele . Isso pode ser devido ao próprio script ser lento ou a implementação ser ruim, resultando em várias chamadas de função duplicadas.
Outra causa potencial para FID alto é o processo de hidratação. Se você tiver um aplicativo de página única renderizado do lado do servidor, o processo de hidratação adiciona a funcionalidade do aplicativo do lado do cliente ao seu HTML estático.
Embora esse processo resulte em uma primeira renderização (e LCP) mais rápida, ele pode atrasar a interatividade e aumentar o potencial de atraso quando um usuário tenta interagir. Se você estiver usando SSR com hidratação do lado do cliente, Addy tem uma breve descrição do problema com alguns recursos sobre como gerenciar essa lacuna de desempenho.
Cumulative Layout Shift
CLS é uma medida de quão estável é a IU à medida que o usuário carrega e interage com uma página. É uma soma de mudanças inesperadas de layout durante o ciclo de vida da página, como quando um banner de anúncio carrega e exibe o conteúdo principal da página.
As pontuações de mudança de layout são derivadas do impacto que a mudança tem na janela de visualização: um produto de quanto da janela de visualização muda e a que distância o elemento se move. Uma pontuação cumulativa perfeita é zero, 0,1 é bom. Veja a documentação oficial para mais detalhes.
Mudanças inesperadas de layout significam que não ocorrem imediatamente após uma interação discreta do usuário, portanto, provavelmente terão um impacto negativo na experiência do usuário.
O CLS é medido pelo CRUX em todo o ciclo de vida de uma página, desde o início da navegação até quando o usuário deixa a página. Todas as mudanças inesperadas de layout são somadas ao longo desse tempo e a pontuação total é usada para a medição; isso a torna uma métrica complicada de medir em um ambiente de laboratório. Isso também significa que ferramentas como WebPageTest e mPulse relatarão o melhor cenário para CLS, elas apenas coletarão esses dados enquanto a página estiver carregando e ignorarão mudanças adicionais, como aquelas que ocorrem durante a rolagem.
Otimizar o CLS durante o carregamento da página é razoavelmente simples, só precisamos evitar mudanças de layout! Existem várias causas para mudanças de layout, então vamos examinar algumas das causas e como evitá-las.
- Fontes da web – combine o caractere da fonte da web e o espaçamento entre linhas com a fonte substituta
- Anúncios – pré-aloque locais de layout para anúncios, use uma imagem substituta se os anúncios falharem ou forem bloqueados
- CSS de carregamento tardio – certifique-se de que o CSS de layout crítico está no caminho crítico
- Imagens – sempre adicione um atributo de largura e altura para imagens, para que o navegador possa alocar espaço antes do download da imagem
- Conteúdo dinâmico – sempre que possível, pré-alocar espaço de layout para elementos dinâmicos
Outras Métricas
Embora a atualização inicial da Experiência da página defina LCP, FID e CLS como os principais elementos vitais da web, eles podem mudar com o tempo! Há uma série de outras métricas que fornecem valor adicional e vale a pena monitorar e otimizar. Abaixo estão mais algumas métricas importantes que você pode querer rastrear e melhorar.
Tempo de interação (TTI)
O tempo de interação (TTI) é uma aproximação de quando a página parecerá interativa se um usuário tentar interagir. Este ponto de tempo é medido entre a Primeira pintura com conteúdo e quando o thread principal está livre de tarefas longas por pelo menos cinco segundos.
Baixar essa métrica o mais baixo possível garantirá que seus usuários tenham uma ótima experiência ao tentar interagir com suas páginas. Use TTI com TBT para obter uma visão geral de quão ocupado o navegador está ao carregar suas páginas.
Tempo total de bloqueio (TBT)
O tempo total de bloqueio (TBT) é uma medida de quão ocupada a CPU do navegador estava durante o carregamento da página, medida como a soma de tarefas longas (menos 50ms cada) entre o FCP e o TTI.
Reduzir esse tempo provavelmente melhorará a experiência do usuário e pode ajudar a melhorar o desempenho percebido também. Procure tarefas longas e grandes em seus perfis de JavaScript e tente reduzi-las, removê-las ou atrasá-las.
Como monitorar o desempenho
As ferramentas do Google, como PageSpeed Insights, Lighthouse e web.dev , darão a você uma medição dos principais elementos vitais da web. No entanto, os dados do ‘campo’ têm algumas limitações: os dados são coletados apenas de usuários do Google Chrome que optaram pela coleta anônima de estatísticas de uso e são agregados mensalmente com uma ou duas semanas de atraso. Portanto, se for a primeira semana de outubro, talvez você só tenha dados de todo o mês de agosto disponíveis.
Se você deseja acompanhar os sinais vitais da web mais de perto, procure uma solução de medição de usuário real como o Akamai mPulse . As ferramentas RUM podem coletar dados de desempenho de todos os navegadores que as suportam e fornecer uma visão em tempo real de como seu desempenho está acompanhando. Você também pode detectar problemas rapidamente com páginas ou dispositivos específicos, tornando os dados acionáveis.
Conclusão
A atualização da experiência da página proposta provavelmente ocorrerá em meados de 2021. Isso terá um impacto na classificação de SEO, bem como nos critérios de elegibilidade para as notícias principais no Google SERPs. O Google propôs três novas métricas de desempenho que serão usadas como sinais para esta atualização de SEO, com seleção baseada em sua proximidade com o desempenho percebido pelo usuário e a capacidade de coletar os dados em campo.
A otimização para essas métricas de desempenho, conforme medidas pelo Google em CRUX, pode ter um impacto positivo na classificação no futuro, mas certamente terá um impacto positivo na experiência do usuário. Sabemos que experiências mais rápidas levam a uma menor taxa de rejeição, maior duração da sessão, melhores índices de satisfação, maior conversão, aumento do tráfego de SEO, aumento da receita … Então, por que esperar ?!
A grande vantagem das otimizações de desempenho é que muitas podem ser alcançadas com ajustes relativamente menores no código, então vá em frente e teste suas páginas principais, identifique espaço para melhorias e faça mudanças positivas dentro de sua estratégia de marketing.
Para mais detalhes, conheça o curso do Camilo Dantas!