Velocidade do site e Core Web Vitals: o que conta para vender

Porque é que a velocidade se paga em vendas

Em França, «Core Web Vitals» é pesquisado 1000 vezes por mês, «temps de chargement» (tempo de carregamento) 210 vezes e «vitesse site internet» (velocidade do site) 170 vezes. A pergunta por trás destas pesquisas é sempre a mesma: o meu site perde clientes por ser lento?

Um estudo encomendado pelo Google à Deloitte em 2020 («Milliseconds Make Millions», 37 marcas europeias e americanas, sem revisão por pares) observou nos sites de comércio uma subida de 8,4% nas conversões e de 9,2% no valor médio da encomenda por cada décima de segundo ganha em telemóvel. Tome estes números pelo que são: uma correlação medida por uma parte interessada. O sentido, esse, não se discute.

O telemóvel é o terreno onde tudo se decide: nos nossos próprios sites que vendem, 61% das visitas medidas são feitas ao telemóvel, muitas vezes em 4G, com um polegar e pouca paciência.

As três Core Web Vitals, explicadas

O Google mede três sinais em visitantes reais (dados do Chrome) e considera uma página boa quando o percentil 75 dos seus carregamentos passa o limiar.

1. 1
   LCP (Largest Contentful Paint): o tempo de apresentação do maior elemento visível, muitas vezes a fotografia do produto ou o título. Bom limiar: 2,5 s.
2. 2
   INP (Interaction to Next Paint): o intervalo entre um gesto (tocar num botão, abrir um menu, escolher um tamanho) e a reação no ecrã. Bom limiar: 200 ms.
3. 3
   CLS (Cumulative Layout Shift): a deslocação dos elementos durante o carregamento, a que faz tocar no botão errado. Bom limiar: 0,1 ou menos.

Medir sem se enganar

Há dois tipos de medição, e confundi-los faz perder tempo.

• Os dados de campo: o que os seus visitantes reais vivem, ao longo de 28 dias. Aparecem no relatório «Core Web Vitals» da Search Console e no topo do PageSpeed Insights quando o site tem tráfego suficiente. São estes que o Google usa.
• Os dados de laboratório: um teste simulado, no momento em que o lança (a pontuação sobre 100 do PageSpeed Insights, o Lighthouse). Úteis para encontrar as causas, enganadores para julgar: uma pontuação de 60 em laboratório pode esconder um terreno a verde, e o inverso.
• Teste a partir de uma rede e de um aparelho realistas: um telemóvel de gama média em 4G, não o computador do escritório com fibra.
• Meça as páginas que vendem (página de produto, página de serviço, pagamento), não só a página inicial.

Corrigir primeiro: as imagens

Numa loja online, a fotografia do produto é quase sempre o elemento do LCP, e muitas vezes o mais pesado da página. O formato WebP faz ganhar sem perda visível: segundo o Google, uma imagem WebP com perdas é 25 a 34% mais leve do que um JPEG de qualidade comparável, e uma imagem WebP sem perdas 26% mais leve do que um PNG.

1. 1
   O formato certo: WebP (ou AVIF) para as fotografias, SVG para os logótipos e ícones.
2. 2
   O tamanho certo: uma imagem apresentada com 600 píxeis de largura não precisa de ter 4000. Sirva vários tamanhos com srcset e deixe o navegador escolher.
3. 3
   As dimensões declaradas: width e height em cada imagem, para que a página reserve o espaço e não se mexa (CLS).
4. 4
   O carregamento diferido para as imagens abaixo da dobra (loading=«lazy»), nunca para a imagem principal do topo da página, que deve pelo contrário ser prioritária (fetchpriority=«high»).

A seguir: os scripts e as extensões

Depois das imagens, são os scripts de terceiros que tornam o site lento: widgets de chat, pop-ups, carrosséis, píxeis publicitários, extensões de tema acumuladas ao longo dos anos. Cada um acrescenta código a descarregar e a executar, e degrada sobretudo o INP.

1. 1
   Inventariar: liste cada script de terceiros e o que rende. Uma ferramenta que ninguém consulta retira-se.
2. 2
   Diferir: carregue depois da apresentação tudo o que não é necessário para a compra (chat, vídeos, avaliações em widget).
3. 3
   Aligeirar o tema: um tema que carrega um slider, três tipos de letra e uma biblioteca de animações em cada página pesa em todo o site.
4. 4
   Tipos de letra: duas famílias no máximo, em formato WOFF2, com font-display: swap.
5. 5
   Cache e CDN: ficheiros estáticos guardados em cache durante muito tempo, servidos a partir de uma rede próxima do visitante.

O percurso de compra, onde cada segundo custa

A velocidade da página inicial mede-se em todo o lado; a do percurso de compra é muitas vezes esquecida. Ora, é aí que o comprador decidido espera: adição ao carrinho, abertura do carrinho, página de pagamento. Um botão que demora um segundo a reagir faz duvidar, e um comprador que duvida toca duas vezes ou vai-se embora.

Três reflexos. O botão de compra reage de imediato, mesmo que o processamento demore um pouco (um estado «em curso» visível). O pagamento passa por uma página alojada pelo prestador de pagamentos, rápida e já conhecida dos compradores, em vez de um formulário próprio carregado de scripts. E nada se intromete: nenhum pop-up de subscrição da newsletter entre o carrinho e o pagamento.

O plano numa semana

1. 1
   Dia 1: consultar o relatório Core Web Vitals da Search Console, telemóvel primeiro, e listar os grupos de URL a laranja ou a vermelho.
2. 2
   Dia 2: passar três páginas tipo (página inicial, produto ou serviço, pagamento) pelo PageSpeed Insights e anotar o elemento do LCP de cada uma.
3. 3
   Dia 3: converter e redimensionar as imagens desses modelos, declarar as suas dimensões.
4. 4
   Dia 4: retirar ou diferir os scripts de terceiros inúteis.
5. 5
   Dia 5: voltar a testar em laboratório e depois esperar que os dados de campo se atualizem (cobrem 28 dias) antes de julgar.