Com o tema Hyvä, o Magento 2 será sempre mais rápido do que com qualquer outro tema?

Imagine duas lojas Magento. A primeira utiliza Hyvä, mas logo à entrada carrega várias ferramentas de marketing, descarrega imagens enormes e gera a página de novo a cada pedido. A segunda tem outro tema, cuidadosamente otimizado, uma cache eficiente e apenas os scripts de que o cliente precisa.

Qual será mais rápida? O nome do tema não chega para responder.

Hyvä oferece ao Magento um ponto de partida muito bom para construir uma loja rápida. No entanto, não garante uma vantagem incondicional sobre qualquer outra implementação. O resultado depende de todo o percurso entre o clique no link e o momento em que o cliente vê o produto e pode comprá-lo.

Por isso, vale a pena combinar a implementação de Hyvä com uma revisão do servidor, dos módulos, das imagens e do design da interface. Só assim é possível trabalhar para um objetivo ambicioso: 95–100 pontos no Google PageSpeed Insights, mantendo as funcionalidades necessárias para vender.

O que significa, na prática, uma pontuação de 95–100 no PageSpeed?

De forma informal, falamos de «100% no PageSpeed», mas a ferramenta apresenta pontos numa escala de 0 a 100. Na parte baseada no Lighthouse, avalia quatro áreas diferentes:

Estas avaliações não se substituem umas às outras. Uma loja rápida pode ter botões pouco legíveis. Uma loja tecnicamente correta pode descarregar demasiado JavaScript. O Lighthouse é uma ferramenta de diagnóstico, e o âmbito das suas auditorias não cobre toda a qualidade de uma loja. Descrição do Lighthouse.

A pontuação Performance resulta de uma medição laboratorial e pode variar entre testes. O PageSpeed também mostra, quando disponíveis, dados de utilizadores reais provenientes do CrUX, recolhidos num período móvel de 28 dias. Uma nova implementação não altera imediatamente todo esse conjunto de dados. Como funciona o PageSpeed Insights.

Na prática, precisamos de dois objetivos: testes consistentemente bons e boas experiências para os clientes. Para Core Web Vitals, isto significa:

• LCP até 2,5 s — apresentação rápida do maior elemento na área visível;
• INP até 200 ms — resposta eficiente às interações;
• CLS até 0,1 — layout estável da página.

Estes limites são avaliados no percentil 75, separadamente para dispositivos móveis e computadores. O teste padrão de carregamento do Lighthouse não mede INP; para diagnosticar bloqueios do navegador utiliza, entre outros, TBT. Um TBT baixo não confirma automaticamente um bom INP. Core Web Vitals.

Como Hyvä ajuda a acelerar o Magento?

Hyvä reduz o peso do frontend em comparação com a Luma padrão. Utiliza Alpine.js para interações e Tailwind CSS para estilos. Menos código para descarregar e executar dá ao navegador mais margem para apresentar a oferta rapidamente. A documentação Hyvä aponta a redução de JavaScript e CSS como uma parte importante desta arquitetura. Desempenho de Hyvä.

No entanto, esta vantagem pode ser facilmente reduzida. Basta acrescentar a um frontend leve um slider complexo, chat, vários trackers e módulos que tragam dependências antigas do tema anterior.

Hyvä também não corrige uma consulta lenta à base de dados, uma cache que não funciona ou um servidor ocupado com importações. Por isso, a pergunta antes da implementação deve ser: o que está hoje a atrasar a compra e quais desses problemas serão resolvidos pela alteração do frontend?

1. Servidor: nginx e Varnish têm de fazer o trabalho certo

Antes de o navegador mostrar o produto, precisa de receber o documento HTML. Se esperar demasiado pelo primeiro byte da resposta, até um tema leve começa com atraso.

Nginx: entrega eficiente de recursos

Numa arquitetura Magento típica, o nginx trata, entre outros, de HTTPS, ficheiros estáticos e encaminhamento de pedidos para serviços seguintes. Vale a pena verificar a compressão de respostas textuais, HTTP/2 e cabeçalhos de cache para ficheiros CSS e JS versionados. A Adobe disponibiliza uma configuração nginx de exemplo como ponto de partida para uma implementação com Varnish. Configuração do Varnish no Adobe Commerce.

Não se deve atribuir o mesmo tempo de armazenamento a todas as respostas. Uma folha CSS versionada pode ser usada durante muito tempo a partir da cache do navegador. O preço, o conteúdo do carrinho e a resposta relativa a um cliente autenticado exigem outro tratamento.

Se o servidor escolher WebP com base no cabeçalho Accept, também é necessário verificar a chave de cache e o cabeçalho Vary: Accept. O navegador e as camadas intermédias de cache têm de distinguir as variantes da imagem.

Varnish: verificamos acertos na cache, não apenas se o serviço está instalado

Varnish permite servir páginas públicas a partir da cache sem que o Magento tenha de voltar a executar todo o trabalho. A Adobe recomenda a sua utilização em ambiente de produção. Gestão de cache do Magento.

O teste prático é simples: abrimos o mesmo endereço público várias vezes e verificamos se, depois da primeira resposta, aparecem acertos HIT. Em seguida, comparamos o tempo de resposta a partir da cache com o tempo de geração da página em MISS.

Se uma categoria popular contorna constantemente a cache, é necessário encontrar a causa: configuração, cookies, parâmetros do endereço, personalização ou funcionamento de um módulo. Comprar um servidor maior pode, nesse caso, apenas mascarar o problema.

A correção também é importante. A cache não pode disponibilizar o carrinho ou os dados de um cliente a outro utilizador. É necessário testar variantes da loja, moedas e grupos de clientes, bem como a atualização de conteúdo após a alteração de um produto. Um preço rápido, mas desatualizado, não é um sucesso de otimização.

Além de nginx e Varnish, verificamos PHP-FPM, OPcache, backend cache compatível com a versão do Magento, base de dados, cron e indexação. O número de processos PHP deve resultar da memória disponível e da carga real. Aumentá-lo sem medição pode piorar a situação.

2. Módulos para Hyvä: compatibilidade é apenas o início

Um módulo pode funcionar corretamente com Hyvä e, ainda assim, executar trabalho excessivo ao entrar na página. Uma boa otimização inclui, portanto, tanto a funcionalidade como o custo do seu arranque.

Na kowal.store, adaptamos os nossos módulos a Hyvä e desenvolvemo-los com foco em manter o desempenho deste tema após a instalação. Cuidamos para que novas funcionalidades não sobrecarreguem desnecessariamente o frontend — através da limitação de dependências e de uma forma adequada de carregar JavaScript e CSS. Veja os nossos módulos Magento 2 e escolha extensões para a sua loja. O efeito de uma implementação concreta deve ser confirmado por medição, porque também depende da configuração e das restantes integrações.

Tomemos o chat como exemplo. Um cliente que navega numa categoria precisa, no início, de um botão para abrir a conversa. A interface completa do chat e as suas bibliotecas podem ser descarregadas no momento da abertura. De forma semelhante, as sugestões completas da pesquisa podem ser preparadas quando o utilizador entra no campo de pesquisa, deixando imediatamente visível e funcional o formulário.

Esta abordagem também é descrita pela Hyvä nas recomendações relativas ao carregamento de JavaScript externo.

defer, async e atraso de componente são coisas diferentes

defer permite executar um script clássico externo depois de o documento ser processado e manter a ordem dos scripts desse tipo. async executa o script quando está pronto, sem garantia de ordem em relação aos outros. Nenhum destes atributos significa, por si só, que o ficheiro só será descarregado depois de um clique.

Hyvä também disponibiliza x-defer, que permite atrasar a inicialização de um componente Alpine, por exemplo, até este se aproximar da área visível. Isto não é um adiamento automático do descarregamento de todos os seus ficheiros. Também é necessário considerar eventos que o componente pode perder antes da inicialização, por exemplo, relacionados com dados do cliente. Documentação x-defer.

As alterações devem ser verificadas no carrinho, filtros, formulários e eventos analíticos. A simples presença do atributo defer não prova que o módulo esteja bem otimizado.

CSS: o aspeto necessário deve estar pronto antes da primeira renderização

Os estilos do cabeçalho, da lista de produtos e do layout móvel são necessários desde o início. Carregá-los demasiado tarde pode provocar piscar da página e deslocação de elementos. Ao mesmo tempo, uma categoria de produtos não precisa de descarregar todos os estilos de cada módulo instalado.

Vale a pena limitar folhas globais, remover resíduos do tema antigo e verificar o build de produção do Tailwind. No caso de classes criadas dinamicamente, é necessário garantir que as regras necessárias aparecem no CSS final. CSS crítico incorporado no HTML pode ajudar, mas exige manutenção e testes; não deve ser a primeira resposta para todos os problemas. Recursos que bloqueiam a renderização.

A analítica e os dados SEO também têm o seu custo

Ao trabalhar na otimização de uma loja em Magento 2, verificámos a carga da analítica numa página de categoria. GTM e gtag representavam cerca de 304 KB, ou 44% da transferência registada na primeira medição móvel. É uma boa razão para rever tags e acionadores. Isto não significa que se deva atrasar toda a analítica sem ponderação: tal alteração pode modificar o número de visitas e eventos registados.

Também vale a pena olhar para o próprio HTML. Dados JSON-LD extensos, informações de produtos duplicadas e configurações de módulos aumentam a resposta do servidor. JSON-LD não é executado como um programa JavaScript comum, mas ainda assim tem de ser transferido. Os dados estruturados da categoria devem corresponder à lista visível, à sua paginação e à sua ordem.

3. Imagens: formato, tamanho e momento do descarregamento contam

Uma imagem de origem com vários milhares de píxeis de largura não deve, sem necessidade, acabar num pequeno cartão de produto. Preparamos variantes ajustadas ao tamanho de apresentação e à densidade do ecrã, e srcset e sizes ajudam o navegador a escolher o ficheiro certo. WebP ou AVIF devem ser comparados em termos de qualidade e peso nas imagens concretas.

A distinção mais importante diz respeito às imagens visíveis de imediato e às que se encontram mais abaixo. A imagem que é LCP deve ser fácil de descobrir no HTML, sem loading='lazy'; fetchpriority='high' pode ser justificado. As imagens fora do primeiro ecrã são boas candidatas a lazy loading. As dimensões ou proporções reservam espaço para elas no layout. Imagens responsivas.

No entanto, não definimos prioridade alta para todas as imagens. O navegador precisa de saber o que é realmente mais importante. Fetch Priority.

Também verificamos banners CMS, logótipo, favicon, miniaturas de vídeos e gráficos de popups. A otimização tem de abranger o processo de adição de novos ficheiros; caso contrário, a campanha seguinte volta a introduzir imagens pesadas.

O simples facto de um endereço terminar em .png não determina o que o navegador descarrega. O servidor pode entregar WebP nesse endereço. Verificamos Content-Type e a transferência no separador Network.

4. Cores: o seu maior impacto vê-se na acessibilidade

Mudar um botão azul para verde não vai acelerar o Magento. A cor tem, no entanto, grande importância para a legibilidade e para a pontuação de Accessibility.

Os problemas surgem mais frequentemente em descrições cinzento-claras, botões em tons pastel com texto branco, etiquetas de promoção e texto sobre imagens. De acordo com WCAG, o contraste do texto normal deve ser de pelo menos 4,5:1, e o do texto grande de 3:1. Texto grande significa pelo menos 18 pt, ou seja, cerca de 24 px, ou 14 pt em negrito, ou seja, cerca de 18,7 px. Requisitos de contraste de texto.

Para elementos visuais importantes de controlos e indicações do seu estado, aplica-se também o requisito de contraste 3:1 em relação às cores adjacentes, com as exceções descritas na norma. Contraste de elementos não textuais.

Vale a pena definir a paleta de forma centralizada, por exemplo através de variáveis CSS ou da configuração de um módulo de cores. Assim, a alteração da cor do texto ou dos botões abrange toda a loja. Também é necessário verificar estados hover, focus, erros de formulários e filtros selecionados. Um contorno vermelho não deve ser a única informação de que um campo contém um erro.

O desempenho pode ser afetado pela forma como o aspeto é implementado: folhas adicionais, um script que muda cores depois do carregamento ou efeitos visuais pesados. A paleta em si, porém, não substitui a otimização de JS, imagens e servidor.

Porque é que um único bom resultado não chega?

Ao otimizar uma loja em Magento 2 com Hyvä, fizemos duas medições locais Lighthouse para a mesma página de categoria. Em mobile obtivemos 94 e 73 pontos. O LCP foi, respetivamente, 2,5 e 5,7 s, embora em ambos os casos dissesse respeito à mesma imagem do primeiro produto. Em desktop, a pontuação chegou a 100 pontos.

Todos estes testes reportaram a ultrapassagem do tempo limite de carregamento, pelo que tratámos os resultados como diagnósticos e potencialmente incompletos. Não eram resultados confirmados do PageSpeed Insights nem dados CrUX. Também não se trata de uma comparação de Hyvä com outro tema.

No teste mais fraco, a imagem foi descarregada rapidamente, mas a sua apresentação ocorreu mais tarde. Isto mostra porque é necessário separar o tempo de descarregamento do tempo de renderização. Continuar apenas a comprimir o ficheiro não explica esse tipo de problema. Análise das etapas de LCP.

No trabalho sobre a loja, comparamos várias tentativas, a mediana e a dispersão, mantendo as mesmas condições. Não tratamos relatórios com erros como ponto de referência estável. Também verificamos o comportamento depois da aceitação de cookies, depois de abrir a pesquisa e depois de adicionar um produto ao carrinho.

Checklist Magento e Hyvä: caminho para 95–100 pontos

A lista abaixo ajuda a planear a auditoria e a aceitação dos trabalhos. Não é uma garantia de quatro resultados 100/100. A avaliação depende da página, configuração, condições de teste e versão do Lighthouse. Um resultado verde também não substitui testes manuais de acessibilidade, auditoria de segurança nem estratégia SEO.

Medição e ponto de referência

• Foram analisadas a página inicial, categoria, produto, pesquisa e etapas de compra essenciais.
• Foram feitas medições separadas em mobile e desktop, em várias tentativas comparáveis.
• Foram registados a versão da ferramenta, perfil do dispositivo, estado dos consentimentos e intervalo dos resultados; os timeouts foram explicados.
• Foram verificados LCP, INP e CLS a partir do CrUX ou de monitorização própria, se disponíveis.
• Foram distinguidos os dados de um URL individual dos dados de todo o domínio.
• Foram testadas a primeira visita, o regresso do utilizador e o funcionamento após interação.

Servidor, nginx e Varnish — Performance

• Magento funciona em modo de produção, com recursos estáticos corretamente preparados.
• As páginas públicas alcançam Varnish HIT; também foi verificado o tempo de resposta em MISS.
• A cache distingue corretamente variantes da loja, e dados privados não entram numa resposta partilhada.
• A alteração de produto, preço ou conteúdo invalida corretamente a cache adequada.
• Nginx comprime os recursos textuais adequados e suporta um protocolo HTTP moderno.
• Ficheiros versionados têm cabeçalhos de cache adequados; HTML e respostas privadas têm uma política separada.
• PHP-FPM, OPcache e backend cache estão configurados de acordo com a versão do Magento e os recursos do servidor.
• Cron, indexação, importações e bots não provocam picos no tempo de resposta.

Módulos, JavaScript e CSS — Performance

• Cada módulo ativo tem uma justificação comercial; duplicados de funcionalidades desnecessários foram removidos.
• As integrações Hyvä não reintroduzem sem necessidade dependências pesadas do frontend anterior.
• JS e CSS dos módulos são carregados apenas nas páginas que utilizam as suas funcionalidades.
• Os scripts foram adiados respeitando dependências, ordem e eventos de inicialização.
• Foram testados x-defer seletivo e carregamento de componentes no momento de utilização.
• Os estilos críticos estão disponíveis antes da primeira renderização; não há piscar do layout.
• GTM, píxeis, chat e widgets tiveram os seus acionadores e custo de arranque revistos.
• As alterações de analítica mantêm o comportamento de consentimentos acordado e eventos de e-commerce corretos.
• HTML, DOM e JSON-LD não contêm dados desnecessários ou duplicados.
• Carrinho, filtros, ordenação, paginação e checkout funcionam após a otimização.

Imagens e estabilidade do layout — Performance

• Os gráficos têm dimensões, qualidade e formato adequados; a transferência real foi verificada.
• As variantes responsivas das imagens correspondem aos tamanhos de apresentação.
• O elemento LCP foi identificado separadamente para mobile e desktop.
• A imagem LCP não é atrasada por lazy loading nem por inicialização JS desnecessária.
• Foi atribuída prioridade alta apenas a recursos justificados.
• Imagens, banners e conteúdos incorporados têm espaço reservado no layout.
• Foram verificados logótipo, favicon, gráficos CMS e imagens adicionadas por módulos.
• O processo de publicação de novas imagens inclui a geração de variantes otimizadas.

Cores e utilização da interface — Accessibility

• Texto, preços, botões e mensagens têm o contraste exigido em fundos reais.
• Foi verificado o contraste de controlos importantes e a visibilidade do foco do teclado.
• Erro, promoção e seleção não são comunicados apenas por cor.
• Links e botões têm nomes acessíveis compreensíveis; formulários têm etiquetas.
• Imagens informativas têm texto alternativo adequado, e imagens decorativas têm alt vazio.
• Menu, filtros, popups e carrinho podem ser utilizados com teclado.
• Foram verificados o aumento da página, ecrã pequeno e utilização básica com leitor de ecrã.

Qualidade técnica — Best Practices

• A página e os seus recursos funcionam por HTTPS, sem mixed content.
• Foram explicados erros da consola, pedidos falhados e avisos indicados pela auditoria.
• Bibliotecas e módulos são mantidos; vulnerabilidades reportadas foram revistas.
• As imagens mantêm proporções, e as funcionalidades não utilizam APIs obsoletas sem necessidade.
• A pontuação elevada foi confirmada em conjunto com pagamentos, formulários e consentimentos funcionais.

Visibilidade técnica — SEO

• As páginas destinadas a indexação devolvem o estado correto e não têm noindex acidental.
• robots.txt não bloqueia páginas nem recursos necessários.
• O título e a meta description correspondem ao conteúdo da página.
• O canonical está correto; versões linguísticas e hreflang foram revistos separadamente.
• Os links de navegação são legíveis por robots, e a paginação funciona corretamente.
• Os dados estruturados foram verificados com uma ferramenta separada e correspondem ao conteúdo visível.
• Foram revistas a sitemap e a indexação no Search Console — também fora do âmbito da pontuação Lighthouse.

Os testes automáticos de acessibilidade abrangem apenas parte dos problemas possíveis. Mesmo uma pontuação 100 exige complemento com teste manual. Como é calculada a acessibilidade no Lighthouse.

Por onde começar o trabalho na sua loja?

Primeiro, vamos determinar pelo que o cliente está à espera. Se for pela resposta do servidor — começamos pelo backend e pela cache. Se for pela imagem — verificamos a sua deteção, descarregamento e apresentação. Se a página estiver visível, mas responder com atraso — analisamos o trabalho do JavaScript e dos componentes.

Depois, implementamos um grupo lógico de melhorias e repetimos as medições e os testes de compra. Assim, sabe-se o que ajudou e se o custo da alteração foi justificado. A simples obtenção dos limites de Core Web Vitals não garante uma pontuação de 95: Performance é calculada a partir de várias métricas ponderadas. Regras de pontuação do Lighthouse.

Hyvä permite começar com um frontend leve. Manter essa vantagem exige decisões conscientes em cada módulo, banner e ferramenta de marketing seguinte. Por isso, vale a pena tratar o desempenho como critério de aceitação das próximas implementações, e não como um projeto pontual terminado com uma captura de ecrã de um resultado verde.

Se está a planear uma implementação Hyvä ou quer acelerar uma loja existente, contacte a equipa kowal.store. O ponto de partida deve ser uma auditoria de páginas concretas e do percurso de compra — com uma lista de causas, prioridades e medições antes e depois das alterações.