Magento 2 + Hyvä: escalar a 15 lojas e 9 idiomas

Escalar um ecommerce Magento 2 para 15 lojas e 9 idiomas a partir de uma única instância não é um exercício teórico. É um projeto real que desenvolvemos para a Loviux, uma ecommerce de bem-estar íntimo que opera em toda a Europa. Este artigo documenta as decisões técnicas, os problemas que encontrámos e a forma como os resolvemos.

Se trabalha com Magento à escala — como CTO, tech lead ou developer sénior — aqui encontrará o que aprendemos ao migrar de Luma para Hyvä, construir um checkout customizado sem frameworks pesados, automatizar a geração de conteúdo para mais de 9.000 produtos e manter um stack de desempenho que não falha durante o deploy.

Por que razão migrar de Luma para Hyvä (e o que muda realmente)

O Luma foi o frontend predefinido do Magento 2 durante anos. E durante anos, foi também o seu maior fardo técnico.

O custo real de manter o Luma

O stack do Luma assenta em RequireJS para o carregamento de módulos e Knockout.js para o data binding. Ambas são tecnologias de 2013 que o Magento herdou e nunca modernizou. O resultado prático num projeto com 15 lojas:

• O RequireJS gera uma cascata de pedidos HTTP que bloqueia o rendering. Num catálogo com milhares de produtos, cada página carregava entre 40 e 60 ficheiros JS antes de se tornar interativa.
• O Knockout.js acrescenta peso sem acrescentar valor. Para um ecommerce onde a interatividade real se limita ao carrinho, filtros e checkout, ter um framework completo de data binding é sobreengenharia.
• O CSS do Luma pesa cerca de 300 KB sem compressão. Cada personalização acrescenta camadas sobre camadas de LESS que ninguém se atreve a refatorizar.

Nos nossos testes, uma página de categoria em Luma demorava 4,2 segundos em LCP (Largest Contentful Paint) em dispositivo móvel. Inaceitável para um ecommerce onde cada segundo adicional de carregamento reduz a conversão em 7%, segundo dados da Google.

O que ganhámos com Hyvä + Tailwind CSS

O Hyvä substitui todo o frontend do Luma por uma arquitetura moderna: Alpine.js para interatividade, Tailwind CSS para estilos e zero dependências legacy.

Os números após a migração:

Não se trata de uma melhoria incremental. É uma mudança de ordem de grandeza. E num multi-store com 15 lojas, essa diferença multiplica-se: menos recursos de servidor por pedido, melhor cache, melhor experiência em cada um dos 9 idiomas.

A migração não foi trivial. Cada módulo de terceiros que utilizava o Luma (e tínhamos mais de 30) necessitou de um compatibility module para Hyvä ou de uma substituição. Documentámos cada dependência antes de começar e priorizámos por impacto no negócio. Os módulos que apenas afetavam o painel de administração não necessitaram de alterações; os que tinham templates .phtml de frontend, sim.

Multi-store à escala: 15 lojas, 9 idiomas, uma instância

O Magento suporta multi-store de forma nativa, mas a realidade de o gerir à escala é outra história.

Arquitetura de websites, stores e store views

A configuração da Loviux tem 3 níveis:

• Websites: agrupam lojas por zona de preços e impostos (UE sul, UE norte, Reino Unido)
• Stores: uma por país (Espanha, França, Alemanha, Itália, Países Baixos, Portugal, Polónia, Áustria, Suíça, Bélgica, Reino Unido, entre outras variantes)
• Store views: a camada de idioma. Um store pode ter múltiplas views (a Suíça tem 3: DE, FR, IT; a Bélgica tem 2: NL, FR)

No total, 15 store views a servir conteúdo em 9 idiomas: espanhol, inglês, português, francês, alemão, italiano, neerlandês, polaco e as variantes regionais.

Sistema de fallback de idioma customizado

Aqui encontrámos o primeiro desafio real. O Magento tem um fallback de traduções básico, mas não resolve o problema do conteúdo de catálogo.

O problema: quando um produto não tem descrição traduzida para alemão da Áustria (de_AT), o Magento apresenta um campo vazio. Não recorre automaticamente ao alemão padrão (de_DE). Isto significa que, sem um sistema de fallback, é necessário traduzir cada produto individualmente para cada locale, incluindo variantes que partilham idioma.

A nossa solução: construímos um plugin que interceta o carregamento de atributos localizados e aplica uma cadeia de fallback configurável:

O resultado: as variantes de país herdam automaticamente o conteúdo do idioma principal. Basta traduzir uma vez por idioma, e as diferenças regionais (preços, disponibilidade, textos legais) são geridas ao nível do store sem duplicar o catálogo completo.

Este mecanismo reduziu o esforço de tradução em 65% e eliminou o risco de ter milhares de produtos com campos vazios em lojas secundárias.

Checkout customizado com Magewire e Alpine.js

O checkout é onde um ecommerce ganha ou perde dinheiro. O checkout predefinido do Magento 2 (baseado em Knockout.js + UI Components) é funcional, mas pesado, lento e difícil de personalizar.

Por que razão descartámos React e Knockout

Avaliámos três opções:

1. Checkout Luma stock: descartado porque estávamos a migrar para Hyvä e manter Knockout apenas para o checkout seria incoerente.
2. Checkout com React (como o Hyvä Checkout): acrescenta uma dependência extra de ~130 KB e um build pipeline separado. Para um formulário de 3 passos, é desproporcionado.
3. Magewire + Alpine.js: o mesmo stack que o resto do Hyvä. Sem dependências extra, sem build pipeline adicional, sem conflitos de estado entre frameworks.

Escolhemos o Magewire. Trata-se de um port do Laravel Livewire para Magento que permite construir componentes interativos com PHP no servidor e Alpine.js no cliente. O resultado é um checkout que pesa menos de 15 KB de JS (sem contar o Alpine, que já está carregado globalmente).

Arquitetura de 3 colunas

Concebemos o checkout num layout de 3 colunas em desktop:

• Coluna esquerda: morada de envio e dados do cliente
• Coluna central: métodos de envio e pagamento
• Coluna direita: resumo da encomenda, cupões, totais

Os três painéis são renderizados no servidor com Magewire e atualizados via AJAX quando o utilizador altera dados. Não há SPA, não há router de cliente, não há estado partilhado a gerir entre frameworks. Cada componente Magewire é independente e comunica diretamente com o backend.

Em dispositivo móvel, as colunas colapsam num fluxo vertical com acordeões. O mesmo código, sem duplicação nem media queries de layout complexas.

Resultado: o checkout carrega em 1,1 segundos em móvel (LCP) e a taxa de abandono no passo de pagamento desceu 12% face ao checkout anterior com Luma.

Catálogo de mais de 60.000 produtos com pesquisa avançada

Um catálogo desta dimensão necessita de mais do que a pesquisa nativa do Magento (MySQL FULLTEXT). Necessita de pesquisa facetada rápida e relevante. Basta navegar o catálogo de vibradores para perceber a escala.

SmileElasticSuite com OpenSearch

Implementámos o SmileElasticSuite, a solução de pesquisa open source mais madura para Magento, ligada ao OpenSearch 2.x como motor de indexação.

Configuração principal:

• Pesquisa facetada com filtros dinâmicos por categoria: os filtros disponíveis alteram-se consoante a categoria atual (tamanho, cor, material, marca, intervalo de preço)
• Autocomplete com sugestões de produtos, categorias e termos de pesquisa
• Sinónimos por idioma: configurados por store view para que "gel lubrificante" e "lubrificante íntimo" devolvam os mesmos resultados
• Relevância ajustada: boost de produtos com stock, com imagem e com avaliações acima dos restantes

A reindexação completa do catálogo (60.000+ produtos x 9 idiomas) demora 8 minutos com um cron dedicado. As atualizações incrementais (preço, stock) são processadas em menos de 30 segundos.

Sincronização de stock com fornecedores

A Loviux trabalha com múltiplos fornecedores que enviam feeds de stock em formatos heterogéneos: XML, CSV e, num caso, um endpoint JSON personalizado.

Construímos um sistema de importação modular:

1. Parsers por fornecedor: cada fornecedor tem um adapter que normaliza o seu feed para o formato interno (SKU, quantidade, preço de custo, ETA)
2. Execução diária programada: um cron do Magento executa a sincronização todas as noites às 3h00 (hora de menor tráfego)
3. Logs e alertas: se um fornecedor não envia o feed ou o formato se altera, a equipa é notificada por email
4. Stock agregado: para produtos em regime de dropship, o stock visível é a soma de todos os fornecedores que os disponibilizam

Este sistema processa cerca de 15.000 linhas de stock todas as noites sem impacto no desempenho do frontend.

Pipeline de conteúdo com IA: 9.000 produtos em 9 idiomas

Aqui reside possivelmente o desafio mais interessante do projeto. Com mais de 9.000 produtos que necessitam de descrição em 9 idiomas, estamos a falar de 81.000 textos de produto. Fazê-lo manualmente não é viável, nem económica nem temporalmente.

O pipeline de 4 passos

Concebemos um pipeline automatizado com GPT-4o-mini (escolhido pela sua relação custo/qualidade para geração massiva):

Passo 1 — Extração de características: lemos as fichas técnicas do fabricante (nome, ingredientes, volume, tipo de produto, características especiais) e estruturamo-las num JSON normalizado.

Passo 2 — Geração nativa por idioma: em vez de gerar em espanhol e traduzir, geramos diretamente em cada idioma de destino. A diferença é notável: um texto gerado nativamente em francês soa natural; um traduzido do espanhol soa a tradução. O prompt inclui contexto de marca, tom e restrições legais do mercado de destino.

Passo 3 — Limpeza: eliminamos frases genéricas repetitivas ("este produto é perfeito para..."), corrigimos inconsistências entre idiomas (um produto não pode ter "150 ml" em Espanha e "5 oz" em França se vendemos em ml em toda a Europa) e aplicamos regras de estilo.

Passo 4 — Validação automática: cada texto gerado passa por verificações de comprimento mínimo/máximo, presença de keywords de produto, ausência de alucinações (ingredientes inventados, características falsas) e formato HTML correto para Magento.

Números do pipeline

• Custo total: ~420 EUR em tokens de API para os 81.000 textos
• Tempo de processamento: 14 horas para a geração completa
• Taxa de aprovação automática: 87% dos textos passaram a validação sem intervenção manual
• Revisão manual: os restantes 13% necessitaram de ajustes menores (principalmente produtos com características especiais não abrangidas pelas fichas do fabricante)

Comparado com tradução profissional (estimativa superior a 120.000 EUR e 4-6 meses), o pipeline de IA representou uma poupança de 99,6% em custo e de 95% em tempo. A qualidade não é a de um copywriter sénior, mas para descrições de produto funcionais e preparadas para SEO, é mais do que suficiente.

Stack de desempenho: Varnish, Redis, OPcache e PHP 8.4

O resultado fala por si: PageSpeed Insights 100 em dispositivos móveis para um Magento 2 com 15 store views e mais de 60.000 produtos. FCP de 1,4 segundos, LCP de 1,5 segundos, TBT de 30 ms e CLS de 0. Estes números são excecionais para qualquer ecommerce, e ainda mais para um construído sobre Magento.

O desempenho num ecommerce não é opcional. Um site lento perde vendas. Com 15 lojas a servir tráfego de toda a Europa, o stack tem de ser sólido.

Arquitetura de cache

A configuração de desenvolvimento Magento que montámos para a Loviux segue uma hierarquia de 4 camadas:

1. Varnish 7.x como reverse proxy: faz cache de páginas completas. Um hit de Varnish serve uma página em <10ms sem tocar em PHP. Configurámos VCL customizado para purge seletivo por store view, categoria e produto.
2. Redis para cache de aplicação e sessões: elimina acessos a disco. Duas instâncias separadas: uma para cache de configuração/blocos (DB 0) e outra para sessões (DB 2).
3. OPcache do PHP 8.4: precompila os ~40.000 ficheiros PHP do Magento. Com opcache.jit=tracing ativado, as funções hot path são compiladas para código máquina nativo.
4. Cache de full page no Magento como fallback para pedidos que contornam o Varnish (utilizadores autenticados, carrinho não vazio).

CSS bloqueante: uma decisão contraintuitiva para CLS 0

A sabedoria convencional diz: carrega o CSS de forma assíncrona, extrai critical CSS inline. Nós fizemos o oposto. Todo o CSS é carregado de forma bloqueante no <head>.

Porquê? Porque com Hyvä + Tailwind, o CSS total pesa ~35 KB (gzipped: ~8 KB). Carregá-lo de forma bloqueante acrescenta uns milissegundos ao First Contentful Paint, mas garante que o layout nunca se altera após o primeiro render. O resultado: CLS (Cumulative Layout Shift) de 0,000 consistente em todas as páginas.

Num projeto com dezenas de templates diferentes (home, categoria, produto, checkout, páginas CMS x 15 lojas), manter um sistema de critical CSS sincronizado seria um pesadelo de manutenção. Com 8 KB de CSS bloqueante, o trade-off não se justifica.

Deploy zero-downtime com symlink switching

O deploy em produção segue um fluxo que evita downtime:

1. Build em diretório temporário (/var/www/releases/YYYYMMDD-HHMMSS/)
2. composer install --no-dev, bin/magento setup:di:compile, bin/magento setup:static-content:deploy para os 9 idiomas
3. Warm-up de cache: executamos pedidos a páginas-chave para preencher o Varnish
4. Atomic symlink switch: ln -sfn altera o symlink /var/www/current para o novo release
5. php-fpm reload para que os workers carreguem o novo código
6. Purge seletivo do Varnish

Se algo falhar, o rollback consiste em alterar o symlink para o release anterior. Tempo de indisponibilidade: 0 segundos.

O setup:static-content:deploy para 9 idiomas demora ~12 minutos. É o passo mais lento do pipeline, mas como se executa antes do switch, não afeta o tráfego em produção.

SEO técnico multi-idioma

Um ecommerce com 15 lojas e 9 idiomas é um campo minado de SEO técnico. A Google precisa de compreender que página se destina a que país e a que idioma, sem confundir variantes.

Hreflang em todas as páginas

Cada página inclui etiquetas hreflang que apontam para todas as suas variantes:

São 14 hreflangs por página. Com um catálogo de 60.000 produtos, estamos a falar de 168.000 declarações hreflang apenas para produto. Geramos isto dinamicamente com um módulo que consulta os URL rewrites do Magento por store view.

Dados estruturados completos

Implementámos Schema.org JSON-LD em todas as páginas relevantes:

• Product: com offers, aggregateRating, brand, sku, gtin13 quando disponível. A Google apresenta rich snippets com preço e disponibilidade.
• CollectionPage: em páginas de categoria, com numberOfItems e breadcrumb.
• BreadcrumbList: navegação hierárquica completa (Home > Categoria > Subcategoria > Produto).
• Organization: dados da empresa na home e páginas de contacto.
• FAQPage: em páginas de categoria que contêm perguntas frequentes sobre o produto.

Tudo validado com o Rich Results Test da Google e sem erros na Search Console.

Sitemaps divididos por loja

Um sitemap único para 15 lojas ultrapassaria o limite de 50.000 URLs. Geramos sitemaps individuais por store view:

• loviux.pt/sitemap.xml → sitemap index que aponta para sitemap-products.xml, sitemap-categories.xml, sitemap-cms.xml
• Mesmo padrão para cada domínio (.es, .fr, .de, .it, .nl, .pl, .co.uk, .at, .ch, .be, .com)

Cada sitemap é regenerado diariamente às 5h00 e inclui <lastmod> baseado na última atualização real do conteúdo, não na data de geração. A Google valoriza a honestidade nos timestamps.

Integrações principais

Brevo para email marketing

Ligámos o Magento ao Brevo (anteriormente Sendinblue) para automatização de emails transacionais e marketing:

• Sincronização bidirecional de contactos (registo, compra, abandono)
• Emails transacionais (confirmação de encomenda, envio, fatura) servidos a partir do Brevo para melhor deliverability
• Workflows de abandono de carrinho segmentados por loja/idioma

GA4 Enhanced Ecommerce

Implementámos o tracking completo do GA4 Enhanced Ecommerce com 10 eventos padrão:

view_item, view_item_list, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase e refund.

Cada evento inclui a dimensão de store view para permitir segmentação de desempenho por país/idioma nos relatórios.

Cloudflare Turnstile

Substituímos o reCAPTCHA pelo Cloudflare Turnstile em todos os formulários: registo, login, contacto, newsletter e checkout como convidado. O Turnstile não apresenta challenges visíveis ao utilizador (é invisível por predefinição) e tem melhor rácio de aceitação do que o reCAPTCHA v3. Num ecommerce, cada ponto de fricção adicional no checkout é uma venda a menos.

O que retirámos deste projeto

Após meses de desenvolvimento, testes e otimização, estas são as aprendizagens que tiveram maior impacto:

1. O Hyvä não é opcional para projetos Magento 2 novos. Se inicia um projeto hoje com Luma, está a começar com dívida técnica. A diferença de desempenho é demasiado grande.

1. O fallback de idioma desenha-se antes de carregar o primeiro produto. Fazê-lo depois, com 60.000 produtos já carregados, teria sido um pesadelo de migrações de dados.

1. O Magewire é a resposta certa para checkout em Hyvä. O mesmo paradigma que o resto do frontend, sem dependências extra. O Laravel Livewire provou o conceito; o Magewire leva-o ao Magento.

1. A IA para conteúdo de produto não substitui os copywriters, mas escala onde eles não conseguem. 81.000 textos em 9 idiomas por 420 EUR é uma equação que não admite debate. A revisão humana continua a ser necessária para os 10-15% de edge cases.

1. CSS bloqueante com Hyvä faz mais sentido do que critical CSS. Quando o CSS total pesa menos do que uma imagem de avatar, a complexidade de manter critical CSS não compensa.

1. Deploy zero-downtime é obrigatório, não um nice-to-have. Com 15 lojas e tráfego 24/7 a partir de múltiplos fusos horários, não existe janela de manutenção segura.

Se a sua empresa precisa de escalar um ecommerce Magento 2, seja uma migração para Hyvä, uma configuração multi-store ou integrações complexas, contacte a nossa equipa. Temos mais de 15 anos a construir soluções de ecommerce que funcionam à escala real.