Principais elementos vitais da Web para testes A/B: seu software de teste A/B está deixando seu site lento?

O Google acabou de lançar sua atualização Core Web Vitals e precisamos prestar atenção a ela.

Por que se importar?

Como CROs, normalmente não nos preocupamos muito com o lado do tráfego, pois estamos focados no que acontece quando as pessoas acessam nossos sites e as ações que realizam.

O problema é que essa nova atualização está focada na experiência do usuário, portanto, não é apenas relevante para nós como otimizadores, mas há uma chance de que seus testes possam realmente impactar negativamente as pontuações e o tráfego da experiência na página do seu site.

Não é ótimo, certo?

Neste artigo, vou orientá-lo sobre o que é essa atualização, como ela funciona, como seus testes podem afetá-la, algumas práticas recomendadas para não apenas reduzir o impacto dessa nova atualização de SEO, mas também como melhorar suas pontuações e talvez ganhe mais tráfego orgânico por causa disso.

Minha ferramenta de teste A/B deixará meu site e afetará a pontuação do meu Core Web Vitals?

Vamos tirar isso do caminho lá em cima. O aplicativo Convert é incrivelmente rápido e não deve afetar negativamente sua experiência na página ou pontuação no Core Web Vitals, contanto que você siga as práticas recomendadas para teste e configuração de CWV.

No entanto, nem todos os sites seguem as práticas recomendadas e, nessas situações, o teste A/B pode afetar a velocidade de carregamento da página, o atraso na primeira entrada, a mudança de layout cumulativa ou a maior exibição de conteúdo, dependendo de como você configurou o teste e o site .

As boas notícias?

Cada um desses elementos é facilmente corrigível. Abordaremos tudo isso enquanto percorremos este guia, além de como melhorar sua experiência de página básica e pontuações de CWV e não quebrá-las durante o teste.

Qual é a diferença entre o Core Web Vitals e a experiência da página do Google?

Eles parecem complicados e têm nomes sofisticados, mas basicamente se resumem ao rastreamento de momentos-chave na experiência da página de um usuário:

• Quão rápido sua página carrega?
• Com que rapidez o usuário pode ver os principais elementos da página e entender do que se trata?
• Em quanto tempo eles podem interagir com a página?
• Quanto tempo até que essa interação funcione desde o clique de um botão até a ação acontecer?
• Como é a aparência da página e é fácil de usar?

Por que nos importamos?

Nós nos importamos porque o Google se importa e é uma das raras ocorrências em que eles apontaram um fator de classificação específico, como ele funciona e como melhorá-lo. Quando isso acontece, vale a pena prestar atenção, pois é um sinal do que está por vir.

Por que o Google se preocupa com a experiência do usuário?

Simplificando, se eles estiverem recomendando resultados que forneçam uma experiência ruim ou um resultado incorreto, há uma chance de seus usuários começarem a migrar para seus concorrentes.

A experiência na página ainda não é considerada um fator importante de classificação. O Google declarou recentemente que, sendo tudo igual entre você e um concorrente, a experiência da página provavelmente atuará como o fator decisivo que determinará quem tem uma classificação mais alta, simplesmente porque você está fornecendo a melhor experiência, mas não é o único fator.

(Grande conteúdo, oferta, EAT e backlinks sempre moverão mais a agulha.)

No entanto… O Google parece estar fazendo grandes movimentos para que a experiência do usuário se torne um importante fator de classificação de pesquisa no futuro. Eles mudaram todos os resultados do índice de classificação para focar na experiência e nos resultados mobile-first.

Isso significa que, embora o Page Experience seja um algoritmo focado em dispositivos móveis, porque todo o índice agora é mobile-first, isso afeta todos os proprietários de sites e como eles aparecem nos resultados da área de trabalho.

Você pode ter um ótimo conteúdo no desktop, mas é a versão móvel, não a versão desktop, que afetará sua classificação nos resultados. Além disso, o Google também se preocupa com a velocidade de carregamento e o layout da página. Eles atualizaram e elevaram o nível do que é necessário várias vezes, definindo um padrão para o tempo de carregamento e muito mais, tudo para melhorar as pesquisas em dispositivos móveis.

Eu disse isso antes, mas é melhor ter uma ideia agora e começar a implementar as melhores práticas, principalmente porque a Experiência do Usuário pode afetar diretamente nossas campanhas de CRO e sua ferramenta de teste também pode afetar esses resultados de SEO…

Então, vamos detalhar cada uma dessas métricas de experiência de página, seus resultados atuais, o que cada métrica significa e como você pode atender a seus requisitos, juntamente com algumas coisas a serem lembradas para que seus testes não afetem negativamente sua pontuação.

Como medir seus principais Web Vitals atuais e resultados de experiência de página

Você pode tecnicamente usar o Google Search Console para isso, mas sinto que os dados podem ser um pouco vagos ou limitados. (Os resultados são listados como “ruim”, “precisa melhorar” ou “bom”.)

Em vez disso, vá até a ferramenta PageSpeed ​​Insights do Google e confira seu site lá.

A ferramenta Insights é muito fácil de usar. Basta inserir a URL da página que você deseja verificar, deixá-la em execução e, em seguida, analisar seus resultados para dispositivos móveis e computadores.

Seu objetivo é obter uma pontuação de 90 ou superior para dispositivos móveis e computadores.

Claramente, esta página precisa ser trabalhada , pois leva 14,7 segundos para que os usuários de dispositivos móveis possam interagir totalmente com esta página!

Agora, há uma razão pela qual esta página demora tanto para carregar no celular. São cerca de 11.000 palavras, com cerca de 30 imagens e 3 vídeos.

via GIPHY

Essa é uma página GRANDE!

Durante este artigo, continuarei aprimorando esta página de vendas à medida que trabalhamos com cada recomendação de relatório do Core Web Vitals, para que você possa ver a diferença na velocidade e pontuação da página.

Então, depois de atualizar o site e a página para atender à experiência da página e aos principais elementos vitais da Web, mostrarei como a configuração de testes A/B nesta página pode afetar meus resultados.

• Qualquer coisa em vermelho precisa funcionar o mais rápido possível.
• Qualquer coisa em amarelo pode ser melhorada.
• E qualquer coisa em verde atualmente atende aos requisitos.

Uma coisa interessante de se ver é que o aplicativo Convert Experiences está apenas diminuindo a velocidade da minha página em 107 milissegundos em segundo plano, enquanto o aplicativo Vimeo está causando um atraso de 1.567 milissegundos.

Isso não é culpa do aplicativo deles, mas, em vez disso, é porque eu preciso corrigir vários problemas com minha página e meu site que estão fazendo com que ele não funcione corretamente.

Antes que eu possa melhorar esses problemas, precisamos entender o que eles significam e como a ferramenta deu esse resultado…

Como a ferramenta PageSpeed ​​Insights chega a esses resultados?

A ferramenta PageSpeed ​​Insights usa a ferramenta de teste de desenvolvimento Lighthouse do Google para ter uma ideia do desempenho da sua página.

O Lighthouse aplica métricas de ponderação específicas com base no desempenho da sua página para chegar a essa pontuação.

Essas ponderações são baseadas nos fatores de experiência do usuário mais importantes e geralmente mudam para refletir quando o Google adiciona novos recursos para rastrear UX. (Mais uma vez, é por isso que isso parece ser uma coisa importante para se concentrar hoje).

Se compararmos a última versão dessas ponderações com a versão mais recente do Lighthouse, podemos ver que a mudança de layout cumulativa e o tempo total de bloqueio receberam um peso muito maior em sua importância em comparação com as versões anteriores.

Isso significa que os outros elementos são subitamente menos importantes?

De jeito nenhum. Na verdade, eles provavelmente receberam menos peso à medida que mais sites são atualizados e atendem aos requisitos padrão de experiência de página.

Parece que o foco agora foi mudado para impedir que as páginas tenham layouts alterados à medida que a página é carregada e reduzir o tempo que leva para a página responder à entrada do usuário.

Essas são duas coisas importantes que precisamos considerar como testadores porque nosso teste pode fazer com que a página carregue mais lentamente ou o layout pode mudar quando testamos novos designs de layout.

A ferramenta Lighthouse pega essas ponderações e as aplica à sua página atual usando algo chamado dados de laboratório e campo para medir o desempenho da sua página.

O que são dados de laboratório e de campo?

Lab Data é basicamente uma simulação de condições específicas para criar um ambiente de controle. É o que a maioria dos usuários que lêem este artigo usarão para testar e melhorar sua página.

Considerando que Field Data é baseado na experiência real do usuário nessa página específica , mas é um pouco falho. Você precisa de muito tráfego ao vivo para essa página para obter resultados. Não apenas isso, mas esse tráfego deve ter vindo de usuários do Chrome que também optaram pelo Relatório de experiência do usuário do Chrome (CrUX), que nem todos usam ou optam.

Os dados de campo da pontuação do usuário são baseados no 75º percentil da experiência dos usuários nessa página.

Por que isso importa? Porque a experiência de cada usuário pode variar dependendo do dispositivo e da velocidade da internet.

Se 26% do seu público estiver navegando em um iPhone 5 com uma conexão lenta, sua pontuação pode cair para 74% e isso mostraria que sua página 'precisa de melhorias'.

Por fim, os Dados de campo são baseados em uma agregação contínua de 28 dias, de modo que os relatórios são baseados em resultados anteriores. As alterações de hoje não serão refletidas nos resultados por mais um mês.

Como você pode ver, os Dados de Campo não serão relevantes para todos nós. A boa notícia é que os dados de laboratório da ferramenta Insights são bons o suficiente e nos fornecem informações suficientes para ver como nossas alterações e atualizações afetam esse ambiente simulado, para que possamos ter uma ideia aproximada de como nosso site pode se comportar na natureza.

Portanto, agora que conhecemos nossos resultados de linha de base em nossas páginas com pior desempenho/mais importantes, podemos aprender o que todas essas métricas significam e como melhorá-las.

Quais são as métricas de experiência de página do Google, as três métricas principais da Web Vitals e como podemos melhorá-las?

Existem 4 métricas básicas de experiência de página e mais 3 em um subconjunto específico chamado Core Web Vitals (o foco da atualização mais recente do Google).

Cada uma dessas métricas básicas é bastante fácil de alcançar. Tudo o que você precisa é de um site responsivo, sem código desonesto, para não cobrir o site em pop-ups e rodar através de HTTPS.

Estes são apenas os elementos básicos embora. Existem mais 6 métricas de experiência de página usadas pelo Lighthouse quando ele mede o desempenho de sua experiência de página usando dados do laboratório.

Agora, embora existam 6 métricas de laboratório para focar, elas estão todas interconectadas. Isso significa que uma melhoria em um geralmente vê uma melhoria em outros.

Para ajudar a simplificar tudo isso, o Google os dividiu em 3 Core Web Vitals:

• Maior pintura de conteúdo
• Atraso da primeira entrada e
• Mudança de layout cumulativa

É aqui que precisamos melhorar e também é onde nossos testes podem afetar nossos rankings.

Vamos trabalhar com cada um desses Principais Web Vitais abaixo e o que você precisa fazer para melhorá-los, antes de analisar como seus testes podem afetar essas pontuações.

1. Maior Pintura de Conteúdo (LCP)

A maior pintura de conteúdo é baseada na velocidade de carregamento do maior elemento visível na tela. Pode ser uma foto de herói, uma imagem de fundo ou até mesmo o texto do título.

Essa pontuação foi projetada para replicar quanto tempo leva para o seu público começar a ver o conteúdo principal da sua página e ter uma ideia do que é a página.

Atualmente, o LCP é ponderado em 25% da sua pontuação CWV.

Seus leitores podem entender sua página é importante corrigir, mas é mais do que isso. Veja bem, a maioria dos problemas que causam um LCP lento geralmente são as causas principais do que torna as páginas mais lentas e causa outros problemas de CWV . Isso significa que, se você corrigir esses elementos do LCP, terá feito a maior parte do trabalho.

Seu objetivo deve ser carregar seu LCP em menos de 2,5 segundos.

Os principais problemas que diminuem sua pontuação/velocidade no LCP são:

• Tempos de resposta do servidor lentos
• JavaScript e CSS de bloqueio de renderização, causando atrasos nos elementos
• Tempos de carregamento de recursos lentos
• Renderização lenta do lado do cliente
• Otimização de imagem ruim/definida incorretamente.

Como melhorar sua pontuação LCP

Há várias coisas que você pode implementar para melhorar sua pontuação no LCP.

Aqui você pode ver minha pontuação LCP da página de vendas de exemplo antes de fazer qualquer um dos ajustes recomendados.

Atualmente, leva 3,4 segundos para o meu elemento LCP carregar na página, mesmo que seja apenas um título de texto, e minha página leva 14,7 segundos para carregar antes de se tornar interativa.

Se percorrermos a ferramenta PageSpeed ​​Insights e observarmos as oportunidades, há várias coisas que posso fazer para melhorar a velocidade geral da página e interromper algumas das coisas que estão diminuindo a velocidade do LCP.

Vamos passar por todos eles.

uma. Pré-carregar o elemento LCP

A primeira coisa que você precisa fazer é verificar qual é o elemento LCP real para sua página atual, pois pode variar entre as páginas.

Enquanto estiver na visualização móvel da ferramenta PageSpeed, role a página até a seção de diagnóstico e clique no elemento 'Maior Pintura de Conteúdo' e veja o que aparece.

Nesta página em particular, meu elemento LCP é meu título.

Posso melhorar a velocidade de carregamento do meu texto classificando outras coisas na minha página, como compactação e armazenamento em cache, mas e se meu elemento LCP fosse uma imagem?

Nesse caso, eu gostaria de pré-carregar a imagem na página para que ela começasse a carregar antes mesmo da página começar a renderizar.

Dessa forma, a imagem começa a ser carregada imediatamente e não é retardada por outros códigos ou solicitações.

Isso é uma coisa enorme.

A prática padrão é carregar lentamente todas as imagens em uma página, para ajudar na velocidade da página. Mas quando você faz isso com sua imagem LCP, na verdade, ela torna o carregamento mais lento, diminuindo sua pontuação LCP!

(Este é um grande problema se você também estiver testando A/B seu elemento LCP!)

então como nós consertamos isso?

Queremos escrever algum código para especificar que esse elemento LCP específico deve ser pré-carregado em uma página específica.

O script que você deseja adicionar é o script rel=”preload” e será algo assim:

Neste exemplo, estou dizendo a esta página específica para pré-carregar a imagem TRAFFIC-SMALL-HEADER (que é o elemento de imagem LCP para essa página). Também estou especificando várias opções de dimensão para que ele possa carregar uma imagem responsiva para dispositivos móveis e computadores.

Essa alteração por si só ajudará qualquer imagem de carregamento lento que esteja afetando sua pontuação no LCP.

Alguns temas WordPress ou Shopify permitem adicionar código personalizado no cabeçalho dessa página específica, enquanto alguns plugins permitem isso. Caso contrário, você também pode editar o arquivo header.php da sua página e adicionar o código diretamente.

Cobri alguns dos princípios básicos aqui, mas a maioria das correções que abordaremos podem variar dependendo do seu site e do que você usa. (Se você não estiver no WordPress ou tiver um desenvolvedor, faça com que eles verifiquem os conselhos de desenvolvimento do Google para otimizar o LCP aqui).

Como meu site é construído no WordPress, vou usar o plugin WPRocket, pois ele me ajudará a corrigir a maioria dos problemas com o LCP em um só lugar.

b. Use hospedagem dedicada/de alto desempenho

Uma correção super simples de implementar. Quando seu usuário carrega sua página da Web, ele envia uma solicitação ao seu host da Web para obter as informações da página e os arquivos armazenados, etc.

Alguns serviços de hospedagem na web funcionam em uma plataforma de hospedagem compartilhada. Isso significa que eles compartilham a infraestrutura entre vários sites. Por isso, significa que o tráfego de outros sites em sua hospedagem compartilhada pode diminuir o desempenho do seu próprio site.

Mudar para um serviço de hospedagem dedicado que é 100% apenas para o seu site não é apenas mais rápido, mas também mais seguro e pode ajudar com problemas de carregamento de página e tempos de resposta do servidor.

Aqui você pode ver que o tempo de resposta inicial do servidor do meu site foi de 2,67 segundos.

Depois de atualizar para um host dedicado, ele removeu completamente o atraso de resposta do servidor, economizando 2,67s no tempo de carregamento e também melhorou o Índice de velocidade e o tempo para interação.

c. Habilite o cache e aumente o comprimento do cache (se necessário)

O armazenamento em cache permite que você economize nas solicitações do servidor armazenando uma cópia salva do conteúdo do seu site para os usuários para que ele carregue rapidamente em visitas repetidas.

Dessa forma, se eles voltarem e quiserem ver o conteúdo novamente, ele carregará incrivelmente rápido.

d. Adiar JS Não Crítico + Remover JS Não Usado

Quando uma página é carregada, ela se reveza para carregar as coisas uma de cada vez (assíncrona) ou fica mais lenta e tenta carregar várias coisas ao mesmo tempo (sincronização). Isso não é tão ruim se você tiver um servidor rápido ou se o aplicativo de terceiros que você está extraindo carrega rapidamente, como o aplicativo Convert Experiences.

Mas podemos ajudar a melhorar nossa pontuação e velocidade da página adiando alguns elementos (instruindo-os para carregar depois de coisas mais importantes) ou removendo elementos que não precisam ser carregados em todas as páginas.

Isso geralmente é uma grande causa de problemas de carregamento do LCP, pois esses elementos tentam carregar antes do elemento LCP. (Eles também podem afetar o atraso da primeira entrada).

Você pode especificar quais JS, aplicativos ou plugins devem ser adiados ou removidos dentro do WPRocket. (Apenas certifique-se de definir o script Converter para carregar como prioridade e não ser adiado).

Dessa forma, qualquer JS não essencial é removido, outro JS é adiado até ser usado e o script Convert pode ser executado o mais rápido possível.

Nota:

Você também pode usar esta seção para priorizar o carregamento de qualquer elemento acima da dobra, como controles deslizantes ou carrosséis. Basta adicionar o código à seção de exclusão e ele será carregado normalmente.

e. Considere a minificação do código

Você também pode acelerar o tempo de carregamento da página minimizando o código JS e CSS em seu site. A minificação é usada para remover dados desnecessários ou redundantes sem afetar como o recurso é processado pelo navegador, por exemplo, comentários de código, espaços em branco e formatação, remoção de código não utilizado, uso de nomes de variáveis ​​e funções mais curtos e assim por diante.

Muitos plugins permitem que você faça isso.

Apenas certifique-se de verificar suas páginas após a aplicação, pois às vezes pode causar problemas. (Especialmente ao combinar código, e é por isso que não o usei aqui. Deve funcionar bem em teoria, mas tive problemas no passado.)

f. Otimize imagens para carregamento lento e capacidade de resposta (não apenas a imagem do LCP)

Algo que pode diminuir o desempenho da página é o tamanho da imagem e o volume de imagens que você possui.

Se você tiver uma página com muitas imagens, poderá melhorar a velocidade de carregamento carregando lentamente as imagens para que as que estão mais abaixo na página só comecem a ser exibidas à medida que o visualizador rola para baixo.

(Apenas lembre-se de pré-carregar a imagem LCP!)

Você também pode ajudar no carregamento da página especificando tamanhos de imagem específicos. (Às vezes, você pode carregar uma imagem enorme por acidente, o que diminui a velocidade da página à medida que a compacta no tamanho certo.)

g. Usar compactação de imagem e dimensionamento responsivo

Você pode fazer com que suas imagens carreguem ainda mais rápido reduzindo o tamanho do arquivo e fornecendo tamanhos responsivos para se adequar ao dispositivo em que o usuário está.

Tamanhos de arquivo menores significam que eles exigem menos recursos para o dispositivo do usuário carregar, mantendo a alta qualidade de sua perspectiva.

O WPRocket também se integra a um plug-in chamado Imagify para compactar e fornecer imagens responsivas (adicionando várias opções de scrset para diferentes tamanhos de tela).

h. Estabeleça conexões de terceiros o mais rápido possível

Se você tiver conteúdo ou scripts em seu site que podem retardar o carregamento da página, você pode configurá-lo para começar a pré-carregar elementos específicos o mais rápido possível para que eles carreguem mais rápido.

Lembra como meus vídeos estavam deixando minha página mais lenta antes?

Ao configurar solicitações de pré-busca de DNS de terceiros, posso acelerar o carregamento de todos esses vídeos.

eu. Use um CDN para reduzir o tempo de carregamento

Uma CDN ou Content Delivery Network ajuda a acelerar ainda mais a velocidade de carregamento do seu site, salvando as versões em cache do seu site em servidores mais próximos da localização do usuário.

Você pode fazer isso com algo como Cloudflare gratuitamente.

j. Use a compactação Gzip ou Brotli para otimizar o tamanho do arquivo

Você também pode acelerar ainda mais seu site usando um plug-in de compactação como Gzip ou Brotli, mas alguns CDNs farão isso automaticamente, então verifique o seu primeiro para ver se ele está instalado. (O Cloudflare tem isso embutido.)

Então, qual foi o impacto de fazer todas essas mudanças?

Melhorei a velocidade de carregamento do meu site, reduzindo de 13,5 segundos para 3,3 segundos no celular. Minha velocidade LCP agora é de 2,1 segundos.

Isso é uma economia de 10,2 segundos!

Nada mal, certo?

Ainda há algumas coisas para corrigir, mas elas devem melhorar à medida que trabalhamos nos outros 2 Core Web Vitals.

2. Atraso da primeira entrada (FID)

O atraso da primeira entrada é uma medida de quanto tempo leva para a página responder quando o usuário tenta realizar uma ação, como pressionar um botão ou clicar em um link.

As causas mais comuns de um FID ruim são:

• Execução de script primário causando um atraso na prontidão da interação.
• A busca de dados afeta a prontidão da interação.
• Execução de script de terceiros atrasando a latência de interação.

O atraso da primeira entrada é ponderado como 30% de sua pontuação CWV e seu objetivo é reduzir essa resposta para 100 milissegundos ou menos.

Como melhorar sua pontuação de atraso na primeira entrada

Não podemos medir o FID sem um usuário ativo, então, tentamos melhorar o Tempo Total de Bloqueio (TBT), pois ambos estão conectados.

Então, vamos olhar para os resultados da nossa página…

Quando eu medi minha página pela primeira vez, meu TBT era de 1,5 segundos (ou 1.560 milissegundos).

Desde que melhorei os elementos do LCP, ele caiu para 0,2 segundos (210 milissegundos) e 3,5 segundos até que seja totalmente interativo.

Isso ocorre porque já resolvemos alguns dos problemas que retardam o Total Blocking Time, simplesmente corrigindo alguns problemas de LCP, como minificação de código e adiando ou removendo JS.

Já está próximo da faixa de velocidade desejada, mas vamos mostrar algumas outras coisas que você pode fazer, caso sua pontuação ainda não esteja lá.

uma. Pré-carregar conteúdo e links

Aqui está um recurso interessante dentro do WProcket. Com o pré-carregamento de imagens LCP, estamos dizendo à página para começar a carregar a imagem LCP o mais rápido possível.

Com links de pré-carregamento e sitemaps, estamos dizendo ao site para começar a pré-carregar o conteúdo em segundo plano, quando o usuário passa o mouse sobre um botão ou link.

Isso significa que esses ativos começam a ser carregados antes mesmo que o usuário os solicite, acelerando esse FID e diminuindo o tempo total de bloqueio para as outras páginas nas quais eles clicam.

O benefício aqui é um FID mais rápido em outras páginas, então vamos ver mais algumas maneiras de melhorar a primeira página em que eles carregam.

A principal coisa que podemos fazer para melhorar o FID é remover o excesso de código do nosso site.

Vá em frente e carregue sua página no GTMetrix.

Uau, essa pontuação parece incrível, certo!?

Bem, isso é porque esta é sua pontuação no Desktop, não no seu celular. (A menos que você pague para personalizar o dispositivo e o local, o GTMetrix sempre mostrará uma simulação do carregamento da página de um usuário do Chrome em um desktop.)

Isso é bom, pois o que queremos ver é a seção Cachoeira, para ver as áreas em que o carregamento da página está atrasado.

As barras em bege são áreas que precisamos melhorar, pois são momentos em que outro código está sendo impedido de carregar.

Posso ver na cascata que alguns plugins e fontes antigos estão diminuindo o carregamento da página, para que eu possa voltar e pré-carregar essas fontes personalizadas.

Abra-os na cascata e copie e cole os URLs das fontes no WProcket. (Eu deveria tê-los adicionado antes, mas esqueci opa!)

Então, vamos ver algumas maneiras de remover mais bloqueios e excesso de código.

b. Remover Plugin Bloat

Se você já tem seu site há algum tempo, é muito fácil começar a coletar vários plugins e adicionar código em excesso que não é mais necessário.

Você pode acelerar seu site removendo plug-ins não utilizados ou plug-ins duplicados que realizam a mesma tarefa.

Você também pode:

• Atualize os plugins para ver se eles rodam mais rápido.
• Ou procure plugins alternativos que façam a mesma coisa por menos código.

c. Remover o inchaço do código do tema

Alguns temas têm código em excesso incorporado para fornecer opções de design ou estilo que você pode não precisar, fazendo com que as páginas demorem mais para carregar.

Você pode substituir seu tema atual por um mais leve que atenda às suas necessidades e ver grandes saltos na velocidade da página e no tempo de carregamento.

Pessoalmente, eu uso o tema gratuito Neve porque é limpo e leve, com apenas 75kb de tamanho total de instalação, mas você pode usar qualquer tema que desejar. (Basta pesquisar por temas de 'carregamento rápido' ou 'mobile first'.)

d. Remover inchaço da página

Outro grande problema que pode causar inchaço de página e problemas de CLS são os Construtores de Páginas, principalmente por causa do excesso de código que eles usam para representar determinados recursos.

Você pode ver uma pontuação DOM muito menor removendo os plug-ins do Page Builder ou simplificando o código da página, reconstruindo-o com o construtor ou criando uma página HTML personalizada.

Então, qual foi a minha pontuação depois de mudar isso?

Ainda não removi meu construtor de páginas, mas a pontuação ainda caiu para apenas 130 milissegundos de tempo total de bloqueio e a página carrega em 1,9 segundos.

Quer melhorar ainda mais a velocidade da sua página?

Há outro ótimo plugin que você pode usar chamado Asset Cleanup (é o que nossa equipe usa na Convert).

Ele permite que você especifique quais plugins ou ativos são carregados em cada página do seu site, ajudando você a remover plugins não utilizados de páginas específicas para que eles não aumentem o tempo de carregamento desnecessariamente.

Por exemplo, você pode ter um plug-in de formulário de contato em seu site, mas seu código está sendo carregado em uma página onde não é necessário.

Com o Asset Cleanup, você pode acessar essa página e rolar para baixo e dizer ao plug-in para não carregar nessa página específica.

3. Mudança de layout cumulativa (CLS)

Você já tentou clicar em algo em um site e, em seguida, ele se move e um anúncio ou banner é exibido?

Frustrante, certo?

É especialmente importante para nós como otimizadores, pois uma experiência de usuário ruim como essa pode causar problemas com IU quebrada ou simplesmente o público não entender o que fazer.

(Algumas pessoas sem escrúpulos vão realmente construir isso como um design escuro para obter cliques específicos, etc. Especialmente sites que vendem espaço publicitário…)

O CLS mede quantos elementos se movem em uma página (também conhecido como estabilidade visual) e, em seguida, pontua seu site com base nisso. Seu objetivo é impedir que esses sites criem essa experiência ruim para o usuário, e sua ponderação atual é de 15% da sua pontuação CMV.

Seu objetivo é obter uma pontuação CLS de 0,1 ou inferior.

No entanto, não são apenas os anúncios que podem afetar suas mudanças de layout. Na verdade, as causas mais comuns de uma pontuação baixa no CLS são:

• Imagens sem dimensões
• Anúncios, incorporações e iframes sem dimensões
• Conteúdo injetado dinamicamente, como anúncios na barra lateral ou no cabeçalho, que enviam conteúdo
• Fontes da Web causando FOIT/FOUT mudando de uma fonte genérica para uma fonte personalizada e afetando o espaçamento do layout
• Ações aguardando uma resposta de rede antes de atualizar o DOM.

A boa notícia é que já resolvemos muito disso corrigindo problemas com LCP e FID.

• Definimos as dimensões de imagem, anúncio e vídeo iframe.
• Nós pré-carregamos todas as fontes personalizadas para que elas não causem mudanças de layout.
• E se você removeu seus construtores de página, deveria ter reduzido os elementos DOM gerais de sua página, tornando-a mais rápida e fazendo menos solicitações!

Se você rolar para baixo na ferramenta PageSpeed ​​Insights e clicar em 'evitar grandes mudanças de layout', poderá ver quais elementos da sua página estão causando problemas de CLS.

No meu exemplo, é simplesmente o cabeçalho mudando para um layout responsivo para dispositivos móveis e não está afetando muito o CLS.

Seu site pode ser diferente, então dê uma olhada para ver o que está causando problemas e resolvê-los.

Então, agora que cobrimos cada área do Core Web Vitals e como melhorá-los, vamos ver como seus testes podem afetar suas pontuações.

Como os principais Web Vitals afetam o UX e os testes A/B (e como passar na avaliação dos principais Web Vitals ao usar o script de conversão)

Contanto que você siga as práticas recomendadas do que abordamos até agora, você não deve ter muitos problemas, mas vamos decompô-los.

Como não impactar negativamente a maior pontuação de conteúdo no teste A/B

Lembre-se de que os elementos LCP são o que é visto no visor ou na tela no carregamento inicial da página, portanto, você pode nem estar testando nenhum elemento LCP, mas apenas por precaução:

E se você estiver testando um elemento LCP, como um novo plano de fundo, imagem principal ou título?

O problema que você pode ter aqui não é com a ferramenta Convert Experiences, mas com práticas ruins para melhorias no LCP.

Like we mentioned earlier, most people make the mistake of lazy loading all images, including the LCP image, which affects the LCP score.

Convert Experiences uses both 'synchronous load' and 'body hide' methods to run tests. Simply put, the tool recognizes the element to be tested and then hides it as soon as it starts to load so the user never sees it, before changing it in under 50 milliseconds.

If you've lazy-loaded that LCP element though, the Convert Experiences app is going to have to wait for that element to load before it can do its job.

You can fix this by preloading the specific LCP elements on your control and test pages like we suggested above. This will get them to start loading immediately on page load, allow them to be recognized and hidden by the Convert app, and be replaced asap before the user notices.

Not only will this reduce flicker, but it will also give a good LCP score as the main LCP element (even when tested) will load fast.

And if the LCP element is not what you're testing? You should be pre-loading it anyway to improve that LCP score.

How to Improve First Input Delay when A/B Testing

The Convert code is incredibly fast, but your FID score still relies on all the other elements of your page.

Make sure to hit all the main requirements for speed that we talked about before so that there is no delay in the Convert code running. (Otherwise, the element you are testing will be hidden until it loads and then changes.)

• You can remove code bloat from other JS and defer them from running.
• You can also 'exclude' the Convert script from being deferred so that it loads up before any other JS so that it can make those test changes asap, while not hurting FID.

If you don't prioritize the Convert code and instead defer it by accident, it may not affect your FID score that much, but it might cause your test element to delay loading, while the script waits to run.

How To Decrease Cumulative Layout Shift Issues When A/B Testing

The potential issues with Cumulative Layout Shift and testing come down to how you run a layout test.

Ideally, you don't want to test massive layout changes with just the Convert Experiences editor. Instead, you want to test similar elements for variations ie swapping out a hero image for another image or swapping text for variations, etc. This means that the page layout stays the same, but a key element is swapped out for a variation.

But what if you want to test a minor layout shift, such as swapping the hero image and text location?

I recommend using Convert Experiences for small layout shifts to set up the test and then see how much it affects your CLS score before you push it live.

A real-world example:

Let's say that I set up that same flipped layout test as above. First, I would build the test inside the Convert Experiences app.

Then I can test this page variant in the page speed tool to get an idea of how it affects CLS.

Make sure you have the variant page open, and then click on the pen icon next to the variant in the Convert Experiences app, then select 'Open Force Variation URL':

This will load a pop up.

Make sure you have the variation page highlighted and then click to copy the URL.

You can input that URL into the PageSpeed Insights tool and measure the CLS and other CWV vitals for that variant.

Full disclosure:

In this particular example, I have not fixed any of the code bloat issues on this other page yet, but here you can see the original control page results based on just the LCP improvements.

A velocidade e o TBT são ótimos, mas o CLS está fora do nosso objetivo na página de controle, pois o construtor de páginas que uso no meu site ainda está causando problemas.

Mas, apenas por interesse, vamos comparar essa pontuação CLS na página de controle com os resultados da variante:

Como você pode ver, o CLS na página da variante pode ser usado, pois a pontuação ainda está dentro das diretrizes.

(Os problemas de velocidade seriam corrigidos assim que eu classificasse problemas de excesso de código com meu construtor de páginas, mas o aplicativo Convert Experiences e o teste de layout são executados incrivelmente rápido.)

Assim, pequenas alterações de layout podem funcionar, apenas certifique-se de testá-las antes de colocá-las ao vivo.

Mas e se você quiser testar grandes mudanças de layout, como um redesenho total ou elementos de página removidos ou adicionados?

via GIPHY

Nesse caso, eu seguiria a mesma prática recomendada para testar reformulações dinâmicas ou grandes alterações de layout, que é executar testes de URL dividida.

Em vez de usar o editor Convert WYSIWYG para ajustar e remover todos os elementos de texto em excesso, seria mais eficiente executar um teste de URL dividido com a página de variação totalmente editada e construída antecipadamente. (Esta é uma prática recomendada independentemente do CLS).

Dessa forma, você pode testar a página de variação versus o controle e obter um tempo de carregamento rápido para ambos, sem afetar sua pontuação CLS com essas grandes mudanças de layout.

Conclusão + Principais conclusões

Então aí está. Nosso guia completo para o Google Page Experience, a atualização 3 Core Web Vitals, como seus testes podem afetar esses sinais vitais e como melhorar sua pontuação.

Quer ajustá-lo ainda mais?

Dependendo das necessidades específicas do seu caso de uso, você pode até editar o aplicativo Convert Experiences para ser executado de forma assíncrona, interromper o recurso de ocultação do corpo ou até mesmo usar assíncrono e remover o recurso de ocultação do corpo ao mesmo tempo. (Você pode querer fazer isso para ajudar a carregar ainda mais rápido e parar outros ativos esperando que a ferramenta termine de carregar).

A maioria dos usuários nunca precisará fazer isso, especialmente se você seguir as práticas recomendadas que apresentamos até agora. (E se você ainda estiver com dificuldades, sempre poderá entrar em contato com nossa equipe de suporte se for um usuário do Convert Experiences.)

Lembrar:

• O aplicativo Convert Experiences é incrivelmente rápido, mas pode funcionar melhor se você seguir as práticas recomendadas para o Core Web Vitals e testes A/B.
• O Google raramente fornece informações sobre sinais de classificação específicos, portanto, a experiência da página e os principais pontos vitais da Web são importantes e podem continuar a se tornar mais importantes no futuro. (Eles já aumentaram os limites de velocidade do site desde versões anteriores.)
• De acordo com o Google, o Core Web Vitals é o desempate quando todas as outras coisas são iguais, por isso vale a pena fazer ao competir em alto nível. Se o conteúdo ou oferta for igual em qualidade e o Page Rank das páginas concorrentes for semelhante, a experiência do usuário ditará as classificações da página de pesquisa.
• O Core Web Vitals está preocupado com a experiência real do usuário na página, então isso é importante para o CRO. Vale a pena aplicar as práticas recomendadas, pois isso pode afetar a velocidade de carregamento da página, a taxa de rejeição, a CTR, a taxa de conversão e muito mais, especialmente em dispositivos móveis.
• Os Core Web Vitals podem até começar a afetar a experiência da página de destino do tráfego pago e como você aparece em leilões de anúncios/custo para veicular anúncios. Melhorar isso pode afetar os custos e a entrega do anúncio.
• Você precisa ter os elementos básicos para atender aos requisitos de experiência de página. Carregamento rápido, CDN, cache, HTTPS, antes de olhar para outros elementos para melhorar.
• O excesso de código e a ordem de carregamento podem afetar tanto o atraso da primeira entrada quanto a maior pintura de conteúdo. Você precisa saber como configurar, restringir, pré-carregar elementos ou adiar JSS e CSS para carregar sua página com eficiência.
• Ao testar o conteúdo que está acima da dobra (na área de visualização em qualquer dispositivo), esteja ciente do elemento LCP e da necessidade de pré-carregá-lo para reduzir problemas de LCP – especialmente se esse for o foco do seu teste.
• O aplicativo Convert Experiences é executado tão rápido que não afetará negativamente o Core Web Vitals, supondo que você esteja executando testes A/B em que grandes alterações de layout não mudam. (Troca de elementos por elementos semelhantes, texto por texto, imagens por imagens, variações de botões, etc). Caso contrário, isso afetaria o CLS. (Você sempre pode testar qualquer variação de mudança de layout antes de enviar ao vivo.)
• Ao realizar alterações de layout maiores, o teste de URL dividido é recomendado (como você faria de qualquer maneira para um teste dinâmico), pois isso afetará o CLS. Apenas certifique-se de atualizar a variação vencedora para o URL original e redirecionar 301 quaisquer links que as variações possam ter obtido (situação rara).