Google Analytics causando falha no Core Web Vitals: Próximas etapas

Para proprietários de empresas online que desejam atrair, envolver e converter usuários, os Core Web Vitals que falharam são um aviso crítico.

Uma referência oficial de quão agradável é o seu site para usuários do mundo real, o Core Web Vitals do Google é um conjunto de três métricas de desempenho:

• Largest Contentful Paint (LCP) mede o tempo de carregamento inicial
• A interação com o Next Paint (INP) mede a capacidade de resposta
• Mudança cumulativa de layout (CLS) mede a estabilidade do layout

Juntas, essas métricas oferecem uma maneira padronizada de avaliar o desempenho de um site com base nas interações reais do usuário. A aprovação na avaliação indica que seu site carrega rapidamente, reage rapidamente e não se comporta de maneira anormal enquanto os usuários interagem com ele.

Portanto, é uma grande surpresa quando o próprio Analytics do Google parece estar causando falhas nas avaliações do Core Web Vitals.

Vamos investigar!

Como funciona o Google Analytics?

O Google Analytics funciona rastreando as interações do usuário em um site e fornecendo insights sobre o comportamento do usuário, fontes de tráfego e conversões. Ele é implementado em um site adicionando um snippet de código de rastreamento fornecido pelo Google Analytics.

Este snippet JavaScript, também conhecido como tag global do site (gtag.js), vai para a seção do seu site em cada página da web que você deseja acompanhar:

Este código coleta dados sobre as interações do usuário, como visualizações de páginas, cliques e conversões, e os envia aos servidores do Google para análise. Os proprietários de sites podem então acessar esses dados por meio do painel do Google Analytics para obter insights sobre o desempenho de seus sites e o envolvimento do usuário.

Até agora tudo bem.

Agora, vamos ver o que acontece nos bastidores.

Impacto no desempenho (uma análise mais detalhada)

Após uma inspeção mais detalhada com o cache desativado e sem otimizações de desempenho ativas, vemos que o gtag.js é carregado como uma única solicitação HTTP pesando minúsculos 111 KB, junto com um gtag do Microsoft Clarity de 769B.

No que diz respeito ao carregamento inicial da página, o código de rastreamento do Google Analytics exibe um comportamento esperado e não contribui para solicitações HTTP excessivas, JavaScript não utilizado ou thread principal bloqueado.

De onde vem o equívoco, então?

O Google Analytics realmente afeta os principais sinais vitais da Web?

Adicionar o rastreamento do Google Analytics ao seu site por si só não corre o risco de ser reprovado na avaliação Core Web Vitals (ou especificamente no Lagest Contentful Paint). Isso ocorre simplesmente porque o snippet colocado no cabeçalho das páginas da web é extremamente leve e não bloqueia nenhum dos processos vitais na renderização do conteúdo de uma página.

Então, por que os proprietários de sites estão vinculando Core Web Vitals com falha ao Google Analytics?

A diferença entre dados de laboratório e de campo

Nossa experiência mostra que ainda existe um mal-entendido considerável quando se trata de ler os relatórios do Google PageSpeed. Principalmente pela forma como o relatório evoluiu ao longo do tempo.

Vamos esclarecer a confusão.

Após a introdução do Core Web Vitals, a equipe do Google trabalhou duro para desviar a atenção para o que chamamos de “dados de campo” – agora exibidos no topo do seu relatório como a avaliação Core Web Vitals.

Ele é gerado com dados de usuários reais interagindo com seu site a partir do conjunto de dados CrUX (também conhecido como Relatório de experiência do usuário do Chrome).

Avaliação Core Web Vitals com base em dados de campo da amazon.com

Antes do Core Web Vitals do Google se tornar o padrão para uma excelente experiência do usuário, contávamos com a pontuação de desempenho (medida de 0 a 100), agora exibida após a avaliação CWV.

Pontuação de desempenho baseada em dados de laboratório da amazon.com

A razão pela qual ele foi despriorizado é que ele não representava com precisão o que acontece quando os usuários acessam seu site. A pontuação de desempenho é gerada com “dados de laboratório” do Lighthouse – em outras palavras, são os resultados de um ambiente simulado.

Como você pode ver nas capturas de tela acima, a Amazon está passando no Core Web Vitals com louvor, mas em um ambiente controlado, o tempo total de bloqueio (TBT), o índice de velocidade (SI) e os problemas de LCP são sinalizados para melhorias adicionais. Essa é uma ótima maneira de isolar problemas específicos e trabalhar para otimizá-los.

No entanto, no final das contas, o que mais importa é como os usuários reais experimentam seu site, e é aí que seu foco principal deve ir primeiro.

Veredicto Final

Concluindo, se você estiver reprovando no Core Web Vitals, é improvável que o rastreamento do Google Analytics seja o motivo. Em vez disso, certifique-se de não ler os resultados do laboratório em vez dos de campo e dê outra rolagem ao seu relatório PSI para explorar as seções Oportunidades e Diagnóstico.

E quanto ao Gerenciador de tags do Google e ao Google AdSense?

Na realidade, os proprietários de sites raramente chegam ao ponto de configurar análises e encerrar o dia.

O Gerenciador de tags do Google e o Google AdSense são ferramentas populares para empresas on-line que desejam rastrear eventos específicos e veicular anúncios em seus sites para obter receita extra com o tráfego recebido.

Embora o Google Analytics em si não seja uma fonte de problemas de desempenho, nossos engenheiros da NitroPack sempre conduzem análises aprofundadas para identificar os verdadeiros culpados.

Usando nosso exemplo anterior com kiteworks.com , vemos que após a interação com a página inicial, uma cadeia de tags de eventos extras (gtm.js) do Tag Manager é acionada.

E são muitas tags gtm.js extras, daí o número excessivo de solicitações HTTP.

Como o código do Google Analytics carrega primeiro, antes de tudo, quando seu site tem muitas tags de evento, você pode esperar que o snippet GA chame todos os outros gtm.js, resultando em atrasos no carregamento e resultados piores em métricas, como:

• Maior pintura com conteúdo
• Tempo total de bloqueio
• Primeira pintura com conteúdo (FCP)

No seu relatório PSI, tal string será sinalizada pelo aviso “Reduzir JavaScript não utilizado”:

E se o seu Gerenciador de tags do Google se parecer remotamente com isto, é hora de organizar e reorganizar:

Corrigindo “Redução de JavaScript não utilizado” causada pelo Gerenciador de tags do Google

Sua primeira etapa é atrasar scripts de terceiros com atributos async ou defer e deixá-los carregar em segundo plano. Esses atributos essencialmente transformam os scripts em não bloqueadores e reduzem o impacto geral do código de terceiros.

Embora semelhantes, esses atributos têm diferenças importantes:

• Os scripts com o atributo defer mantêm sua ordem relativa. O navegador não espera que eles renderizem a página, mas os executa em ordem. Por exemplo, temos dois scripts – script 1 e script 2 – nessa ordem. Se adiarmos ambos, o navegador sempre executará o script 1 primeiro, mesmo que o script 2 tenha sido baixado primeiro.
• Os scripts com o atributo async são completamente independentes. O que carregar primeiro será executado primeiro.

As tags Gtm carregam de forma assíncrona por padrão, mas quando há tantas, é como se você tivesse duas filas muito longas de solicitações - mesmo que estejam passando, elas só podem passar uma de cada vez e inevitavelmente terão que esperar sua vez.

Ao otimizar primeiro o número de eventos do Gerenciador de tags do Google e adiá-los em seguida, você pode garantir que o carregamento inicial não sofra atrasos desnecessários.

Reduza o JavaScript não utilizado e otimize todos os recursos do seu site com NitroPack →

Riscos e compensações com o Google AdSense

Quando os proprietários de sites dedicam blocos de anúncios em vários formatos em uma página da web, o Google AdSense fornece snippets de código (HTML/JavaScript) para cada bloco de anúncios que são colados no HTML das páginas do site onde os anúncios devem aparecer.

Quando um usuário visita uma página da web que contém o código de anúncio do AdSense, o navegador executa o código JavaScript fornecido pelo AdSense, gerando receita para o proprietário do site na impressão.

Infelizmente, devido às suas qualidades de bloqueio de renderização, os anúncios do AdSense podem afetar o desempenho do site (e especificamente Web Vitals como LCP e CLS).

Com o NitroPack, os proprietários de sites podem optar por “Otimizar anúncios”, o que atrasará o JS até a interação do usuário. Mas como o AdSense funciona com base em impressões, isso pode se traduzir em algumas perdas de receita publicitária.

Nesse caso, com base no comportamento do seu público, você deve decidir o que é mais benéfico para o seu negócio:

1) desempenho ideal para melhores experiências de navegação

ou

2) gerar o máximo de receita publicitária possível, mas eventualmente perder tráfego devido ao comportamento instável do site.

Perguntas frequentes

A auto-hospedagem do Google Analytics vale a pena?

Embora alguns proprietários de sites considerem o rastreamento auto-hospedado do Google Analytics para obter o Core Web Vitals ideal, há pouca necessidade de prosseguir com isso. Em vez de adicionar complexidade, custo e limitações potenciais em comparação com a dependência da infraestrutura do Google, concentre-se na otimização dos eventos do Gerenciador de tags do Google para atender aos padrões Core Web Vitals.