Velocidade em telemóvel de uma loja PrestaShop: o que medir e o que melhora de verdade

Testa a sua loja no computador do escritório, com fibra, e corre bem. O seu cliente abre-a num telemóvel de gama média, com rede irregular, no autocarro. Para ele, a mesma página demora vários segundos a mostrar a fotografia do produto e responde com atraso quando toca em «Adicionar ao carrinho». É essa segunda experiência que conta, tanto para vender como para a Google, que indexa e avalia as páginas pela sua versão móvel.

Laboratório e campo: duas medidas diferentes

Antes de mudar alguma coisa, distinga dois tipos de dados:

• Dados de laboratório: os que dá um teste simulado como o Lighthouse ou a parte inferior do PageSpeed Insights. Úteis para diagnosticar, porque medem sempre nas mesmas condições, mas são uma simulação.
• Dados de campo: o que utilizadores reais do Chrome viveram nos últimos dias, agregado. É o que aparece no topo do PageSpeed Insights (se houver tráfego suficiente) e no relatório Core Web Vitals da Search Console.

Ficar obcecado com a pontuação de laboratório é um erro frequente. Uma loja pode ter 60 no Lighthouse e passar com dados reais, ou 90 e chumbar porque os seus utilizadores usam telemóveis lentos. O que a Google usa como sinal são os dados de campo.

As três métricas, em linguagem de loja

São avaliadas sobre o percentil 75 das visitas: não basta que corra bem para a maioria, tem de correr bem para três em cada quatro.

O que trava o PrestaShop num telemóvel

Tempo de resposta do servidor

Se o servidor demora a gerar a página, tudo o resto começa tarde. No PrestaShop pesam as consultas à base de dados de cada página, os módulos que acrescentam lógica em hooks do front office, um PHP antigo e um alojamento sem recursos suficientes. Uma cache de página completa, que serve às visitas anónimas o HTML já gerado, costuma ser a melhoria individual mais visível neste ponto.

CSS e JavaScript de que essa página não precisa

Cada módulo tende a carregar os seus ficheiros em todas as páginas: o CSS do formulário de contacto na ficha de produto, o script do configurador na página inicial. Num telemóvel, descarregar, interpretar e executar tudo isso atrasa a apresentação e, sobretudo, piora o INP, porque o processador do telefone está ocupado quando o utilizador toca no ecrã.

Scripts de terceiros

Chats, píxeis de publicidade, mapas de calor, widgets de avaliações. Cada um acrescenta pedidos e trabalho de processador. Muitos não são necessários até o utilizador interagir com a página.

Imagens

Fotografias de produto carregadas em tamanho grande, sem formatos modernos, ou um carrossel na página inicial que obriga o telemóvel a descarregar uma imagem pensada para ecrãs de computador. O elemento LCP de uma ficha é quase sempre a fotografia principal: se for pesada ou for carregada em diferido, o LCP ressente-se.

Tipos de letra

Várias famílias tipográficas, com muitos pesos, carregadas a partir de servidores externos. Além do peso, atrasam o texto ou fazem-no saltar quando é aplicado o tipo de letra definitivo.

O que melhora de verdade, por ordem

1. Servidor e PHP atualizados. Uma versão de PHP com suporte e um PrestaShop atualizado são mais rápidos por si só e permitem usar ferramentas de cache e otimização atuais que não funcionam em versões antigas.
2. Cache de página para visitas anónimas, com exclusões corretas para carrinho, pagamento e conta, e limpeza automática quando mudam produtos ou preços.
3. Retirar CSS e JS das páginas onde não são usados, em vez de apenas os combinar e minificar. Juntar tudo num único ficheiro grande não reduz o que o telemóvel tem de processar.
4. Atrasar os scripts de terceiros até à primeira interação, com uma lista de exceções para o que tem de carregar sempre.
5. A imagem principal sem carregamento diferido e com o tamanho certo; o resto, em diferido. Reserve o espaço de imagens e banners com as suas dimensões para evitar saltos.
6. Tipos de letra servidos a partir do seu servidor, só com os pesos que usa e com font-display ajustado.

Como medir o antes e o depois

• Registe os dados de campo dos modelos principais (página inicial, categoria, ficha) antes de começar.
• Use o laboratório para confirmar que a alteração faz o que espera num URL concreto.
• Espere que os dados de campo se atualizem: refletem um período de várias semanas, por isso a melhoria não aparece no dia seguinte.
• Teste também num telemóvel real de gama média, com a ligação limitada a partir das ferramentas do navegador: é o mais parecido com o que vive boa parte dos seus clientes e revela problemas que a fibra do escritório esconde, como menus que demoram a abrir ou botões que se mexem.
• Veja também o seu negócio: taxa de conversão em telemóvel, rejeição nas fichas, carrinhos iniciados.

A velocidade é mais um sinal entre muitos para a Google, e ninguém lhe pode prometer posições por a melhorar. O que é certo é que uma loja rápida em telemóvel perde menos clientes pelo caminho.

Como resolver no PrestaShop

O Pack Tienda rápida da Rekire reúne as peças deste artigo: All In One Cache (cache de página completa em disco com limpeza automática ao guardar produtos, categorias ou preços, cache de consultas em Redis a partir do PrestaShop 8 e gestão do OPcache), o respetivo serviço de configuração e formação, RKR OptiMatters e Cache Buster. O OptiMatters faz o inventário dos CSS e JS que cada tipo de página carrega, com o seu peso e o módulo de origem, permite retirá-los, diferi-los ou atrasá-los até à primeira interação por página, dispositivo ou controlador, serve as Google Fonts a partir do seu servidor só com os pesos que usa e inclui um modo antes/depois visível apenas para quem tem sessão iniciada no back office.