A próxima atualização da experiência da página do Google introduz sinais derivados do Core Web Vitals (CWV) no algoritmo de classificação oficial. Os Web Vitals são um conjunto de métricas que medem a velocidade com que as páginas carregam, tornam-se interativas e estabilizam visualmente para utilizadores reais que interagem com elas. Os sites que falham no teste Core Web Vitals vão ficar mais baixos do que no início de 2021.
A CWV consiste em métricas de 3 velocidades que têm um impactos significativo na experiência percebida do utilizador. Estes incluem o maior Contentful Paint (LCP) para medir os tempos de carregamento, First Input Delay (FID) para medir a interatividade e a capacidade de resposta, e o Cumulative Layout Shift (CLS) para medir a estabilidade visual. Embora a velocidade do website tenha estado na vanguarda de muitas empresas de comércio eletrónico, está prestes a tornar-se um dos fatores mais importantes no panorama online. Aqui estão as métricas em que você deve se concentrar e como melhorar a velocidade para cada um.
Quais são os Core Web Vitals
Fazer uma boa primeira impressão online é fundamental. Os compradores querem ver os produtos imediatamente, navegar rapidamente e fazer o check-out facilmente, sem interrupções. Se as suas expetativa não forem satisfeitas, elas vão saltar e nunca voltar. O Core Web Vitals ajuda a resolver este problema ao avaliar as páginas de experiência que fornecem aos compradores móveis à medida que navegam num site em tempo real.
Embora a maioria das ferramentas do Google dependa de testes sintéticos em ambientes simulados (conhecidos como dados de laboratório), os Core Web Vitals são medidos usando dados de campo recolhidos a partir da experiência do utilizador do Google Chrome (crux), uma base de dados de utilizadores do Chrome do mundo real. Os dados de campo captam os efeitos dramáticos de variáveis do utilizador real, como o dispositivo, as condições da rede e/ou as definições. Dependendo das condições de um utilizador, o desempenho de um site pode variar drasticamente e afetar as suas pontuações vitais do Core Web.
Cada métrica da VOC tem limites diferentes para ser considerada boa, moderada ou pobre. No entanto, todos eles têm uma coisa em comum: O Google usa o percentil 75 ao classificar páginas nesses grupos. Uma página que atinge o limite para ser considerada rápida por 75% dos carregamentos de páginas ou mais é uma boa experiência.
Não é possível otimizar o que não sabe, por isso vamos conhecer cada uma das três métricas que compõem os Core Web Vitals.
Fonte: https://web.dev/vitals/
Pintura com maior conteúdo (LCP)
Os utilizadores normalmente sentem que a página foi carregada quando o maior elemento de conteúdo é totalmente visível no ecrã, ou seja, pela velocidade do maior Contentful Paint, ou LCP. Os elementos de conteúdo podem incluir elementos de nível de bloco, imagens (incluindo imagens dentro de arquivos SVG) e vídeos. Para o comércio eletrónico, os LCPs normalmente medem a velocidade a que a imagem do produto/imagem do herói carrega. Se isto for lento, os utilizadores assumem que toda a experiência será semelhante, o que os leva a sair para o site de um concorrente.
Os LCPs de 2,5 segundos ou menos são considerados rápidos, as páginas com LCPs entre 2,6 e 4,0 segundos precisam de melhorias, e os LCPs com mais de 4,0 segundos são lentos.
TheTieBar.comcarrega LCP em 800 ms no Layer0 (Edgio)
No exemplo acima, o LCP da Tie Bar está marcado a 900 ms quando a imagem principal está totalmente pintada. O Tie Bar fornece consistentemente carregamentos de páginas inferiores a segundos para compradores móveis, ao mesmo tempo que oferece personalização, pesquisas de inventário em tempo real e preços dinâmicos em suas milhares de páginas no Edgio.
Normalmente, o LCP é afetado por um dos seguintes:
- Tempos de resposta lentos do servidor
- JavaScript e CSS bloqueadores de renderização
- Longos tempos de carregamento de recursos
- Problemas de renderização do lado do cliente
Para otimizar o LCP, considere o seguinte:
- Otimizar os tempos de resposta do servidor direcionando o tráfego para o pop CDN mais próximo disponível, armazenando ativos em cache, usando um service worker, e estabelecendo conexões de terceiros com o pré-conexão.
- Reduza o tempo de bloqueio do JavaScript minificando código (por exemplo, removendo espaços em branco), comprimindo dados com ferramentas como o Broti ou o gzip ,dividindo pacotes e enviando apenas o que é necessário no início, e servindo código com sintaxe mais recente com ferramentas como o Babel. Reduza o CSS removendo qualquer CSS não utilizado ou caracteres desnecessários, como espaçamento, recuo ou comentários, e alinhando CSS crítico, incluindo-o diretamente no cabeçalho da página.
- Para reduzir os tempos de carregamento de recursos, otimizar e comprimir ficheiros de imagem e texto, pré-carregar recursos essenciais e fornecer diferentes ativos com base na ligação de rede e ativos de cache usando um serviço de trabalho.
- Otimizar a renderização do lado do cliente reduzindo o tempo de bloqueio do JavaScript (ver nº 2 para otimizar para isso), usando a renderização do lado do servidor (SSR) e a pré-renderização.
Primeiro atraso de entrada (FID)
Embora a primeira impressão de um utilizador seja afetada pela velocidade com que a maior imagem é renderizada, é igualmente crucial que o seu site seja sensível quando o utilizador tentar interagir com ele. O Primeiro Atraso de Entrada, ou DIF, mede o tempo desde quando um utilizador interage pela primeira vez com uma página (cliques, toques ou pressionam uma tecla) até ao momento em que o navegador pode responder a essa interação.
Normalmente, um atraso de entrada ocorre porque o JavaScript é executado no encadeamento principal e todo o JavaScript é bloqueado por padrão. Isso significa que quando o navegador se depara com um arquivo JavaScript, ele deve pausar o que está fazendo para baixar, analisar, compilar e executar esse JavaScript. Quanto mais tempo isso demorar, mais demora a experiência do usuário e menos Google verá a página como utilizável.
O Google considera um DIC de 100 milissegundos ou menos tão rápido, entre 1,1 e 3,0 segundos como necessitando de melhorias, e mais de 3,0 segundos como lento. Embora seja importante lutar pelo percentil 75 para todos os Core Web Vitals, o Google recomenda olhar para os percentis 95 a 99 para a identificação pessoal em dispositivos móveis e desktop, pois isso representará as piores experiências do usuário e verificará as áreas que precisam de mais melhorias (pois se concentrará no ID para mais de 95% do carregamento de páginas).
Também é importante notar que, ao contrário do LCP e CLS, o DIF só pode ser medido no campo (e não será encontrado em dados de laboratório), pois requer interação real do utilizador.
As razões comuns para os FIDs lentos incluem:
- Tarefas longas que bloqueiam o tópico principal por 50 milissegundos ou mais
- Execução de script em primeira parte atrasando a preparação da interação
- Tempo de execução de JavaScript pesado
How para optime para DIF:
- Dividir código de longa duração em tarefas menores e assíncronas e utilizar a divisão de código.
- Mova o carregamento pesado de scripts (e a execução) de componentes não essenciais para fora do caminho crítico e minimize a busca de dados em cascata e a quantidade de dados que precisam ser pós-processados no lado do cliente.
- Use um web worker, como Comlink , Workway ou Workerize ,o que torna possível executar JavaScript em um tópico de fundo, dividir o pacote JavaScript em vários blocos (também conhecidos como lazy-loading) e carregar todos os scripts de terceiros com defer ou async.
Mudança de esquema cumulativa (CLS)
A estabilidade visual de uma página é outro fator que contribui para a experiência do utilizador e pode impedir que os compradores continuem a seguir o caminho para a compra. A terceira e última métrica no Core Web Vitals é a Mudança de Esquema Cumulativo, ou CLS, que mede a frequência com que os utilizadores experimentam mudanças inesperadas de esquema.
Você já experimentou esses casos: Está prestes a tocar em um link ou imagem de produto, mas logo antes de tocar na tela, a página se move, e bam , você clica em outra coisa sem querer. No melhor dos casos, estas situações são um ligeiro incómodo, mas, no pior dos casos, envia compradores à procura de uma experiência mais suave e menos fajosa na web.
O Google calcula esses movimentos de página multiplicando a fração de impactos, ou a quantidade de conteúdo visível deslocado na janela de visualização, pela fração de distância , ou a distância que um elemento instável se moveu no quadro dividido pela maior dimensão do ecrã (altura ou largura). O total de todas as pontuações individuais ( fração de impactos x fração de distância ) para cada turno inesperado de layout que ocorre enquanto um comprador navega resulta no CLS de uma página.
O Google considera um CLS inferior a 0,1 como bom, entre 0,1 e 0,25 como moderado, e superior a 0,25 como pobre.
Se encontrar um CLS pobre, é provável que seja devido a um dos seguintes:
- Uma imagem ou vídeo redimensionando-se
- Redimensionando anúncios
- Uma fonte que carrega tarde e é exibida maior ou menor do que o pretendido
Para melhorar esta métrica, considere o seguinte:
- Inclua as dimensões exatas das suas imagens e elementos de vídeo.
- Evite anúncios pop-up ou banners. Em vez disso, reserve estaticamente um grande espaço para o espaço de anúncios.
- Evite flashes de texto sem estilo ou invisível (FOIT/FOUT) com ferramentas como a exibição de fontes e a API de carregamento de fontes .
Como o Layer0 ajuda a otimizar a velocidade para cada métrica Core Web Vitals
Grandes e complexos websites de comércio eletrónico com milhões de páginas, milhares de SKUs, Testes A/B e personalização, preços dinâmicos e pesquisas de inventário em tempo real podem atingir velocidades de sub-segundos com Layer0. Na verdade, Layer0 é a única plataforma no mercado a garantir LCPs medianos de sub-500 ms.
No Layer0, o conteúdo renderiza instantaneamente, ou pinta, em uma página e torna-se imediatamente gravado devido à nossa CDN configurável, com reconhecimento de aplicativos, chamada CDN-as-JavaScript. Ele utiliza pré-busca avançada e computação de borda para transmitir conteúdo dinâmico (json/ssr/html) da borda para o navegador do usuário, antes mesmo de ser solicitado. Isso mantém os sites 5 segundos à frente dos toques dos compradores em todos os momentos.
Os sites no Layer0 têm uma taxa de acerto de 95% de cache para dados HTML e JSON na borda, enquanto sites em CDNs tradicionais têm uma média de 6%. Esta é uma enorme diferença na entrega do conteúdo que normalmente faz um site lento.
Na linha inferior
Os carregamentos rápidos de páginas diferenciam-se entre agradar aos compradores e assustá-los para o site do seu concorrente. Os Web Vitals principais consideram a primeira impressão de um usuário de velocidade, interatividade e estabilidade visual medindo o maior Contentful Paint, Primeiro Atraso de Entrada e Mudança de Layout Cumulativa. Se as velocidades forem maiores do que 2,5 s para LCP, 100 ms para identificação do veículo (FID) ou .1 para CLS, pode assumir que tanto os utilizadores como o Google percebem o seu site como lento. O Google vai baixar a sua classificação, e os consumidores vão saltar e nunca voltar.
Em apenas alguns meses, uma má experiência de página prejudicará a reputação da sua marca e afetará o seu ranking de SEO. Proteja o seu SEO arduamente ganho usando as táticas de otimização oferecidas acima, ou vá instantaneamente com Layer0 (agora Edgio).
Layer0 é a sua solução tudo-em-um para desenvolver, implantar, visualizar, experimentar, monitorar e executar o seu frontend. Shoe Carnival, REVOLVE, e 1-800-Flowers, são apenas alguns exemplos de sites de comércio eletrônico que oferecem velocidades abaixo de segundo e estão colhendo os benefícios disso. Se você tiver alguma dúvida sobre a atualização da experiência da página ou sobre como acelerar o seu site, teremos todo o gosto em colocá-lo em contato com um especialista em velocidade do site hoje.
A próxima atualização da experiência da página do Google introduz sinais derivados do Core Web Vitals (CWV) no algoritmo de classificação oficial. Os Web Vitals são um conjunto de métricas que medem a velocidade com que as páginas carregam, tornam-se interativas e estabilizam visualmente para utilizadores reais que interagem com elas. Os sites que falham no teste Core Web Vitals vão ficar mais baixos do que no início de 2021.
