Como otimizar para a atualização da experiência da página no nível empresarial (estudo de caso internacional)
Publicados: 2021-06-23SEO em sua totalidade é um tópico enorme, sem mencionar o aspecto técnico.
Nos últimos dois meses, tem sido difícil vagar no campo do SEO técnico sem tocar ou ouvir sobre o Google Page Experience Update e os Core Web Vitals.
Você pode se perguntar o que é e como isso afetará você ou talvez esteja em dúvida de como trabalhar com ele para otimizar seu site – e por boas razões!
O objetivo é fornecer os insumos necessários em formato de estudo de caso para você usar em seu próprio site (ou do cliente) nestes últimos dias antes do 'lançamento'.
Mas devemos engatinhar antes de andar, então vamos começar com o básico.
O que é CWV e por que corrigi-lo?
Core Web Vitals é um conjunto de métricas específicas que o Google usa para avaliar a experiência do usuário de um site.
A intenção é usar essas métricas para avaliar como um site se classifica em seu conteúdo e garantir uma experiência satisfatória ao usuário.
Isso é como um usuário real decidiria deixar um site de carregamento lento, ou um com uma interface desafiadora, não importa quão bom seja o conteúdo.
O Core Web Vitals consiste em três estimativas de velocidade de página específicas e valores de interação do usuário:
- Maior pintura de conteúdo
- Atraso da primeira entrada
- Mudança de layout cumulativa
Os valores são avaliados individualmente no desktop e no celular para levar em conta a experiência em diferentes viewports e adaptadores de rede.
LCP (Largest Contentful Paint) – Experiência de carregamento
O LCP expressa quanto tempo leva para que a maior parte do conteúdo de um site esteja disponível (renderizado) na tela do usuário.
Quando o Core Web Vitals acredita que a otimização está disponível para esse parâmetro, geralmente ela se baseia nos arquivos de front-end (HTML, CSS, arquivos de imagem).
Isso ocorre porque muitos arquivos são necessários para renderizar o site no navegador do usuário. Também pode ser que os arquivos sejam muito grandes ou que o servidor não tenha capacidade suficiente para entregá-los a tempo.
Uma solução sugerida pode ser garantir que esses arquivos sejam menores, sejam enviados por meio de menos solicitações HTTP e dimensionem o servidor para corresponder ao tráfego e ao tamanho do site.
FID (First Input Delay) - Interatividade
O FID expressa quanto tempo leva antes que um usuário possa interagir com pressionamentos de botão do site, toques na tela de toque, entradas de teclado, etc.
Os problemas nessa categoria geralmente são causados pela quantidade de interação e renderização do DOM que é dinâmica ou baseada em Javascript.
O navegador priorizou o carregamento desses scripts e não aceitou a interação do usuário antes do carregamento. Quanto mais difícil for carregar e executar esses scripts, mais tempo levará antes de interagir com o site.
O FID é teoricamente melhorado reduzindo o tempo entre a página mostrada até permitir a interação. Em outras palavras, é possível dividir seus arquivos JavaScript em partes menores, se necessário.
Ao fazer isso, você pode priorizar o carregamento dos elementos essenciais para usar o site (cliques, toques, interações deslizantes, etc.) – deixando animações, efeitos e outros recursos extraordinários para carregar secundariamente.
Praticamente, o FID é medido como uma métrica de usuário individual – não mede o tempo antes que um usuário possa interagir com ele, mas sim o tempo antes que um usuário interaja com ele. É possível obter uma pontuação alta nessa métrica se o usuário obtiver informações de que o site não está disponível, por exemplo, por animações de carregamento ou espaços reservados para grandes conjuntos de dados.
CLS (Mudança de layout cumulativa)
O CLS indica se o site coloca novos botões, texto ou imagens após outros elementos de conteúdo em um site – se o site carregar elementos de forma assíncrona, pode alterar a estrutura do layout original e atrapalhar notavelmente a experiência do usuário.
Arquivos de imagem não otimizados geralmente causam isso ou possíveis fontes da Web que não podem ser pré-carregadas e aparecem após a marcação inicial estar em vigor. Widgets de terceiros incorporados também podem causar uma mudança no layout.
A solução geralmente é pré-carregar o conteúdo. Dessa forma, os elementos capazes de mudar o layout estarão no lugar antes que a página seja exibida pela primeira vez.
Como alternativa, você pode usar contêineres bloqueados para seu conteúdo. Dessa forma, o posicionamento do conteúdo inicial não muda à medida que alguns elementos começam a aparecer.
[Estudo de caso] Aumente o orçamento de rastreamento em páginas estratégicas
Leia o estudo de casoHora de andar
Agora que cuidamos do básico, é hora de colocá-lo em uso, e foi exatamente isso que fizemos com um caso de cliente.
Este caso específico foi divertido porque tinha vários tipos de erros e, portanto, foca em diferentes áreas de otimização.
Existem muitas áreas de foco e pontos de ação a serem observados em todo o caso - então aperte o cinto e aproveite a jornada.
Vou te acompanhar:
- O caso
- O que fizemos no caso
- Por que fizemos como fizemos
- Principais conclusões
O caso: Logpoint; negócios internacionais de segurança cibernética
O site, Logpoint.com, trabalha no ramo de segurança cibernética e é uma marca bem conhecida em todo o mundo.
Ser uma grande empresa internacional significa que muito tráfego passa pelo site. Portanto, é essencial garantir que os visitantes tenham a melhor experiência possível – e, portanto, um case ainda mais avançado para os Core Web Vitals.
A Experiência do Usuário é composta por muitos fatores diferentes, mas especialmente os Core Web Vitals são proeminentes na composição e medição da experiência como um todo.
A imagem acima ilustra a situação antes de iniciar nossa otimização do Core Web Vitals. O ponto de partida para a Logpoint não foi tão ruim, comparado a muitas outras empresas mais proeminentes, mas como mostra o gráfico, há espaço para melhorias.
Isso também pode ser algo com o qual você pode se relacionar.
É crucial garantir que todos os URLs possíveis estejam na categoria de “bom URL”, porque resulta na melhor experiência do usuário e porque o Google está tornando o Core Web Vitals um fator de classificação em meados de junho de 2021 com sua atualização: Página do Google Experiência.
O que fizemos no caso
Durante nossa otimização, toda a situação do Core Web Vitals mudou muito. Quando começamos, os principais problemas eram problemas de LCP e CLS no formato móvel e desktop – e, é claro, na velocidade da página.
O mundo muda e os sites também – então, se você otimizou para CWV meio ano atrás, pode parecer diferente agora.
Google Search Console (Princípios vitais da Web)
A primeira coisa que fizemos foi mergulhar nos diferentes tipos de erro e descobrir quais URLs foram afetadas. Como você já deve saber, o Google Search Console e sua guia Core Web Vitals têm uma visão geral do formato móvel e desktop.
Ao dar um passo adiante nos relatórios dos formatos, aparece uma visão geral dos tipos de erro, onde é possível ir ainda mais longe em um erro específico.
A partir do panorama, é possível dar um último passo adiante, e é a partir daqui que nosso trabalho começou.
Todas as URLs afetadas pelo tipo de erro são exibidas nesta etapa específica, possibilitando o início de nossa análise.
Informações do PageSpeed
Sabendo quais URLs foram afetadas, nosso próximo passo foi analisá-los para identificar os elementos causadores dos erros. É aqui que o PageSpeed Insights entra em ação. Ao analisar os URLs, entendemos a pontuação de integridade do PageSpeed, mas também conseguimos analisar os elementos que contribuem para os erros.
Chrome DevTool – Análise de desempenho
Para esclarecer os tipos de erro e os elementos que os causam, usamos a análise de desempenho encontrada no DevTool. Ao comparar essa ferramenta com os relatórios PageSpeed Insights e Core Web Vitals, garantimos uma visão mais abrangente dos insights fornecidos pelos diferentes meios e como eles se relacionam.
Cada ferramenta sozinha fornece uma perspectiva única dos detalhes, que por sua vez criam o todo maior.
Depois que o perfil foi concluído, várias caixas vermelhas apareceram na seção Experiência . Estes indicavam um carregamento de elemento, que de alguma forma alterava o layout movendo-se ou empurrando elementos adjacentes.
Clicar em um elemento revela um conjunto de informações úteis:
- Pontuação
Esse valor indica quantos pontos esse elemento específico ou evento de carregamento ocupa ao calcular a pontuação CLS acumulada. elementos adjacentes ao redor. - Pontuação cumulativa
Esse valor informa o total de todos os pontos de evento CLS para determinar quão ruim é a situação acumulada para a página fornecida. Para acomodar os padrões do Google, a pontuação CLS acumulada não pode exceder 0,1 pontos. Recomenda-se que a pontuação seja ainda menor, pois o CLS é um valor calculado individualmente e pode ser classificado pior pelo rastreador do Google do que ao calcular a pontuação em um computador. - Teve entrada recente
Esse valor informa se houve interação com o elemento até a mudança de layout. Para uma página HTML estática, raramente é um valor para se preocupar. Principalmente, ele informa se uma entrada do usuário causou ou não a mudança de layout. - Movido de / Movido para
Este valor revela onde o elemento estava inicialmente e onde estava sua nova posição após o movimento. Não é incomum que o componente tenha vários valores movidos de / movidos para se ele foi deslocado várias vezes. Passar o mouse sobre os valores exibe um esboço na tela de onde o elemento estava antes e depois que a mudança de layout ocorreu. - Nó relacionado
Esse valor faz referência ao nó DOM no fluxo de documentos, que foi movido. Dependendo de onde o erro está localizado, isso fornecerá um bom indicador na direção de qual elemento causou o deslocamento ou foi afetado por um elemento adjacente que, por sua vez, causou o deslocamento.
A causa dos erros
A principal razão para os erros do LCP foi devido a uma imagem de herói que aparece em todas as páginas do site.
Claro, existem muitas maneiras de otimizar uma imagem de herói como essa compactando e redimensionando, o que teria sido uma das opções se o Logpoint quisesse manter seu design e layout. No entanto, esse não era o caso, então removemos a imagem do herói que cuidava da maioria dos erros do LCP.
Outra causa dos erros do LCP foi a estrutura do código. O Logpoint usa um construtor de páginas, o que resulta em limites de configuração do construtor de como estruturar o design e o código.
Em alguns lugares no site, todo o layout tinha falhas, como p tags sendo aninhadas dentro de h1 , fazendo com que os elementos de texto se tornassem a maior pintura de conteúdo. Para corrigir isso, varremos o site para simplificar e otimizar a estrutura do código.
Como mencionado, o CLS também fez parte do problema, e foi desencadeado principalmente por dois elementos – que de fato afetaram um ao outro.
Os dois elementos
Em primeiro lugar, a Logpoint tinha incorporações do Youtube em seu site e, para ajudar no tempo de carregamento, implementaram uma miniatura. O problema era que a miniatura e o vídeo eram carregados simultaneamente, após o que o vídeo era removido pelo código JavaScript. Isso causou mudanças significativas no layout do site.
O segundo elemento que afetou o CLS foi o CookieBot implementado no site. Como esperado, o CookieBot deu permissões em relação aos vídeos, para que não pudessem ser visualizados até que o consentimento fosse dado.
É aqui que os dois elementos interagem entre si. O código JavaScript que remove o vídeo foi feito sob medida pelo desenvolvedor e foi programado para interagir com o consentimento do CookieBot.
Para resolver o problema, modificamos o script atrasando o carregamento do elemento de vídeo e o carregamento do próprio script.
É essencial mencionar que o Logpoint é um site grande com muitos componentes que interagem entre si de maneiras diferentes. Isso, combinado com o tema e o construtor de páginas, torna o site complexo e também limita algumas das opções de otimização.
A velocidade da página foi afetada
Isso, é claro, afetou o PageSpeed, então, enquanto focamos no Core Web Vitals, também trabalhamos na otimização disso. Para isso, instalamos os plugins: WP Engine para obter hospedagem rápida, WP Rocket para obter ótimo cache e otimização de HTML, CSS e JS e, por último, CloudFlare , para obter um ótimo provedor de DNS.
As variações de idioma criaram novos erros do Core Web Vitals…
Enquanto estávamos otimizando, a Logpoint passou por mudanças significativas em seu site, publicando muitas novas páginas em diferentes idiomas, com novos elementos e layout que resultaram no aparecimento de novos erros Core Web Vital – um novo tipo de erro CLS agora precisava ser corrigido.
Mais uma vez, passamos por nosso processo de análise. Nesse caso específico, as mudanças de layout foram causadas por um plug-in de bate-papo de terceiros. Na maioria das vezes, esse erro é corrigido adicionando e alterando as regras de CSS, mas devido ao chatbot ser implementado por terceiros, não conseguimos adicionar CSS personalizado a ele.
Portanto, nosso objetivo era postar uma solicitação de atualização com os desenvolvedores do plug-in, já que a adição estava causando um impacto visível em um site com muito bom desempenho e, alternativamente, encontrar um plug-in de bate-papo com uma melhor priorização de carga.
Por que fizemos o que fizemos
O fato de os Core Web Vitals estarem se tornando um fator de classificação é uma mudança fundamental na forma como as classificações dos mecanismos de pesquisa funcionam. Um site mal projetado que não tem foco na experiência do usuário simplesmente não funcionará mais.
O objetivo do Google é ajudar os proprietários de sites a criar sites que se concentrem na experiência do usuário e, ao incluir os Core Web Vitals como fatores de classificação, eles fazem exatamente isso.
O Google não é conhecido por jogar com cartas abertas ou por nos informar sobre suas atualizações com antecedência, mas com o Core Web Vitals e a atualização de experiência de página, fomos informados no início do processo.
Isso, é claro, nos deu tempo para dominar o conhecimento do Core Web Vitals, mas também significou que muitos elementos e ideias ainda não foram definitivamente decididos e alterados durante o período desde a introdução até agora.
Isso incluiu os resultados de ter uma pontuação perfeita no Core Web Vitals – apenas boas URLs.
No início, não havia certeza de como o fator de classificação do Core Web Vitals afetaria os URLs. Este tem sido um tópico há algum tempo – mas em junho todos nós saberemos mais sobre o impacto com certeza.
“As páginas que recebem uma pontuação de “bom” no Core Web Vitals estão alcançando um nível aspiracional de experiência do usuário e podem obter um impulso no componente de classificação da experiência da página.”
– Documentação Google
Da mesma forma, também não está claro se um relatório Core Web Vitals que não domina todos os tipos de erro seria afetado negativamente ou se ainda tem algum efeito positivo.
“Se você tiver páginas que não estão medindo “bom” em pelo menos uma das métricas do Core Web Vitals ou não passando nos outros critérios de experiência de página, recomendamos focar em melhorias nessas dimensões ao longo do tempo. Embora todos os componentes da experiência da página sejam importantes, priorizaremos as páginas com as melhores informações gerais, mesmo que alguns aspectos da experiência da página sejam inferiores.”
– Documentação Google
Além disso, uma ideia de um selo Core Web Vitals está na prancheta – assim como o conhecemos no selo AMP. Isso também ainda está para ser finalmente decidido.
“A diretriz geral é que também gostaríamos de usar esses critérios para mostrar um selo nos resultados da pesquisa, o que acho que houve alguns experimentos acontecendo em torno disso. E para isso, precisamos realmente saber que todos os fatores estão em conformidade. Portanto, se não estiver em HTTPS, essencialmente, mesmo que o resto esteja OK, isso não seria suficiente.”
– John Mueller, analista de tendências para webmasters, Google
Então, embora tenha havido muitas incertezas, uma coisa é certa! O Core Web Vitals veio para ficar e se tornará uma grande parte da batalha pelo tráfego orgânico – e é por isso que nos esforçamos mais para corrigir os erros do Core Web Vitals no Logpoint.
Principais conclusões
No final do caminho, é justo olhar para onde começamos – e espero que este caso tenha lhe dado o conhecimento e as ferramentas para começar a caminhar por conta própria.
Core Web Vitals é algo que prevejo ser o futuro do SEO. Estamos cada vez mais dependentes do tráfego orgânico para afetar o crescimento, e o Core Web Vitals nada mais é do que um relatório para aperfeiçoar a experiência do usuário.
Quando capacitamos o usuário e oferecemos a ele um produto que vale o seu tempo, é claro que ele vai querer interagir com ele.
Logpoint, sendo a estrela do show, passou por uma transformação graças aos insights do Core Web Vitals, permitindo-nos lidar com problemas de LCP e CLS, bem como integrações de terceiros e estrutura geral de código confusa.
Aderindo às melhores práticas ao mesmo tempo em que traçamos perspectivas para os insights fornecidos pelo Core Web Vitals, conseguimos reverter os aspectos técnicos do site de forma que ele fique acima da multidão – isso cabe ao Google decidir .
Uma dica conclusiva
Um conselho amigável meu antes de encerrarmos é focar na otimização de seus Core Web Vitals – não apenas por causa do fator de classificação, mas também porque tem um enorme impacto sobre os visitantes do seu site – e não é isso que SEO é tudo cerca de?
Isso não apenas aumentará o tempo no site, mas também diminuirá a taxa de rejeição e, esperançosamente, resultará em quantidades mais altas de classificações e conversões.
Escrito em colaboração com Andre Vestergaard, especialista técnico em SEO da Bonzer.