Escalar un ecommerce Magento 2 a 15 botigues i 9 idiomes des d'una sola instància no és un exercici teòric. És un projecte real que hem desenvolupat per a Loviux, una ecommerce de benestar íntim que opera a tota Europa. Aquest article documenta les decisions tècniques, els problemes que hem trobat i com els hem resolt.
Si treballes amb Magento a escala — com a CTO, tech lead o developer sènior — aquí trobaràs el que hem après en migrar de Luma a Hyvä, construir un checkout personalitzat sense frameworks pesants, automatitzar la generació de contingut per a +9.000 productes i mantenir un stack de rendiment que no cau durant el deploy.
Per què migrar de Luma a Hyvä (i què canvia realment)
Luma va ser el frontend per defecte de Magento 2 durant anys. I durant anys, va ser també el seu principal llast tècnic.
El cost real de mantenir Luma
L'stack de Luma es basa en RequireJS per a la càrrega de mòduls i Knockout.js per al data binding. Totes dues són tecnologies del 2013 que Magento va heretar i mai va modernitzar. El resultat pràctic en un projecte amb 15 botigues:
- RequireJS genera una cascada de peticions HTTP que bloqueja el renderitzat. En un catàleg amb milers de productes, cada pàgina carregava entre 40 i 60 fitxers JS abans de ser interactiva.
- Knockout.js afegeix pes sense aportar valor. Per a un ecommerce on la interactivitat real es limita a la cistella, filtres i checkout, tenir un framework de data binding complet és sobreenginyeria.
- El CSS de Luma pesa ~300 KB sense comprimir. Cada personalització afegeix capes sobre capes de LESS que ningú no gosa refactoritzar.
A les nostres proves, una pàgina de categoria amb Luma tardava 4,2 segons en LCP (Largest Contentful Paint) en mòbil. Inacceptable per a un ecommerce on cada segon extra de càrrega redueix la conversió un 7% segons dades de Google.
Què hem guanyat amb Hyvä + Tailwind CSS
Hyvä reemplaça tot el frontend de Luma per una arquitectura moderna: Alpine.js per a interactivitat, Tailwind CSS per a estils i zero dependències legacy.
Els números després de la migració:
No és una millora incremental. És un canvi d'ordre de magnitud. I en un multi-store amb 15 botigues, aquesta diferència es multiplica: menys recursos de servidor per request, millor memòria cau, millor experiència en cadascun dels 9 idiomes.
La migració no va ser trivial. Cada mòdul de tercers que feia servir Luma (i en teníem més de 30) va necessitar un compatibility module per a Hyvä o un reemplaçament. Vam documentar cada dependència abans de començar i vam prioritzar per impacte en el negoci. Els mòduls que només tocaven l'admin no van necessitar canvis; els que tenien templates .phtml de frontend, sí.
Multi-store a escala: 15 botigues, 9 idiomes, una instància
Magento dona suport a multi-store de manera nativa, però la realitat de gestionar-ho a escala és una altra cosa.
Arquitectura de websites, stores i store views
El setup de Loviux té 3 nivells:
- Websites: agrupen botigues per zona de preus i impostos (UE sud, UE nord, UK)
- Stores: una per país (Espanya, França, Alemanya, Itàlia, Països Baixos, Portugal, Polònia, Àustria, Suïssa, Bèlgica, Regne Unit, més variants)
- Store views: la capa d'idioma. Un store pot tenir múltiples views (Suïssa en té 3: DE, FR, IT; Bèlgica en té 2: NL, FR)
En total, 15 store views servint contingut en 9 idiomes: castellà, anglès, portuguès, francès, alemany, italià, neerlandès, polonès i les variants regionals.
Sistema de fallback d'idioma personalitzat
Aquí vam trobar el primer repte real. Magento té un fallback de traduccions bàsic, però no resol el problema del contingut de catàleg.
El problema: quan un producte no té descripció traduïda a l'alemany d'Àustria (de_AT), Magento mostra un camp buit. No cau automàticament a l'alemany estàndard (de_DE). Això vol dir que sense un sistema de fallback, cal traduir cada producte individualment per a cada locale, incloent-hi variants que comparteixen idioma.
La nostra solució: vam construir un plugin que intercepta la càrrega d'atributs localitzats i aplica una cadena de fallback configurable:
El resultat: les variants de país hereten automàticament el contingut de l'idioma principal. Només cal traduir un cop per idioma, i les diferències regionals (preus, disponibilitat, textos legals) es gestionen a nivell de store sense duplicar el catàleg complet.
Aquest mecanisme va reduir l'esforç de traducció en un 65% i va eliminar el risc de tenir milers de productes amb camps buits a botigues secundàries.
Checkout personalitzat amb Magewire i Alpine.js
El checkout és on un ecommerce guanya o perd diners. El checkout per defecte de Magento 2 (basat en Knockout.js + UI Components) és funcional però pesant, lent i difícil de personalitzar.
Per què vam descartar React i Knockout
Vam avaluar tres opcions:
- Checkout Luma stock: descartat perquè estàvem migrant a Hyvä i mantenir Knockout només per al checkout era incoherent.
- Checkout amb React (com Hyvä Checkout): afegeix una dependència extra de ~130 KB i un build pipeline separat. Per a un formulari de 3 passos, és desproporcionat.
- Magewire + Alpine.js: el mateix stack que la resta de Hyvä. Sense dependències extra, sense build pipeline addicional, sense conflictes d'estat entre frameworks.
Vam triar Magewire. És un port de Laravel Livewire per a Magento que permet construir components interactius amb PHP al servidor i Alpine.js al client. El resultat és un checkout que pesa menys de 15 KB de JS (sense comptar Alpine, que ja està carregat globalment).
Arquitectura de 3 columnes
Vam dissenyar el checkout amb un layout de 3 columnes en escriptori:
- Columna esquerra: adreça d'enviament i dades del client
- Columna central: mètodes d'enviament i pagament
- Columna dreta: resum de la comanda, cupons, totals
Els tres panells es renderitzen al servidor amb Magewire i s'actualitzen via AJAX quan l'usuari canvia dades. No hi ha SPA, no hi ha router de client, no hi ha estat compartit que gestionar entre frameworks. Cada component Magewire és independent i es comunica amb el backend directament.
En mòbil, les columnes col·lapsen en un flux vertical amb acordions. El mateix codi, sense duplicació ni media queries de layout complex.
Resultat: el checkout carrega en 1,1 segons en mòbil (LCP) i la taxa d'abandonament al pas de pagament va baixar un 12% respecte al checkout anterior amb Luma.
Catàleg de +60.000 productes amb cerca avançada
Un catàleg d'aquesta mida necessita més que la cerca nativa de Magento (MySQL FULLTEXT). Necessita cerca facetada ràpida i rellevant. N'hi ha prou amb el seu catàleg de vibradors per entendre l'escala.
SmileElasticSuite amb OpenSearch
Vam implementar SmileElasticSuite, la solució de cerca open source més madura per a Magento, connectada a OpenSearch 2.x com a motor d'indexació.
Configuració clau:
- Cerca facetada amb filtres dinàmics per categoria: els filtres disponibles canvien segons la categoria actual (talla, color, material, marca, rang de preu)
- Autocompletar amb suggeriments de productes, categories i termes de cerca
- Sinònims per idioma: configurats per store view perquè les cerques equivalents retornin els mateixos resultats
- Rellevància ajustada: boost de productes amb estoc, amb imatge i amb ressenyes per sobre de la resta
La reindexació completa del catàleg (60.000+ productes × 9 idiomes) tarda 8 minuts amb un cron dedicat. Les actualitzacions incrementals (preu, estoc) es processen en menys de 30 segons.
Sincronització d'estoc amb proveïdors
Loviux treballa amb múltiples proveïdors que envien feeds d'estoc en formats heterogenis: XML, CSV i en un cas, un endpoint JSON personalitzat.
Vam construir un sistema d'importació modular:
- Parsers per proveïdor: cada proveïdor té un adapter que normalitza el seu feed al format intern (SKU, quantitat, preu de cost, ETA)
- Execució diària programada: un cron de Magento executa la sincronització cada nit a les 3:00 AM (hora de menys trànsit)
- Logs i alertes: si un proveïdor no envia feed o el format canvia, es notifica l'equip per correu electrònic
- Estoc agregat: per a productes dropship, l'estoc visible és la suma de tots els proveïdors que el serveixen
Aquest sistema processa ~15.000 línies d'estoc cada nit sense impacte en el rendiment del frontend.
Pipeline de contingut amb IA: 9.000 productes en 9 idiomes
Aquí rau possiblement el repte més interessant del projecte. Amb +9.000 productes que necessiten descripció en 9 idiomes, parlem de 81.000 textos de producte. Fer-ho manualment no és viable ni econòmicament ni temporalment.
El pipeline de 4 passos
Vam dissenyar un pipeline automatitzat amb GPT-4o-mini (triat per la seva relació cost/qualitat per a generació massiva):
Pas 1 — Extracció de característiques: llegim les fitxes tècniques del fabricant (nom, ingredients, volum, tipus de producte, característiques especials) i les estructurem en un JSON normalitzat.
Pas 2 — Generació nativa per idioma: en lloc de generar en castellà i traduir, generem directament en cada idioma de destinació. La diferència és notable: un text generat en francès natiu sona natural; un traduït del castellà sona a traducció. El prompt inclou context de marca, to i restriccions legals del mercat de destinació.
Pas 3 — Neteja: eliminem frases genèriques repetitives, corregim inconsistències entre idiomes (un producte no pot ser "150 ml" a Espanya i "5 oz" a França si venem en ml a tota Europa) i apliquem regles d'estil.
Pas 4 — Validació automàtica: cada text generat passa per comprovacions de longitud mínima/màxima, presència de keywords de producte, absència d'al·lucinacions (ingredients inventats, característiques falses) i format HTML correcte per a Magento.
Xifres del pipeline
- Cost total: ~420 EUR en tokens d'API per als 81.000 textos
- Temps de processament: 14 hores per a la generació completa
- Taxa d'aprovació automàtica: 87% dels textos van passar la validació sense intervenció manual
- Revisió manual: el 13% restant va requerir ajustos menors (principalment productes amb característiques especials no cobertes per les fitxes del fabricant)
Comparat amb traducció professional (estimat en +120.000 EUR i 4-6 mesos), el pipeline d'IA va representar un estalvi del 99,6% en cost i del 95% en temps. La qualitat no és la d'un copywriter sènior, però per a descripcions de producte funcionals i preparades per a SEO, és més que suficient.
Stack de rendiment: Varnish, Redis, OPcache i PHP 8.4
El resultat parla per si sol: PageSpeed Insights 100 en mòbil per a un Magento 2 amb 15 store views i més de 60.000 productes. FCP d'1,4 segons, LCP d'1,5 segons, TBT de 30 ms i CLS de 0. Aquests números són excepcionals per a qualsevol ecommerce, i encara més per a un construït sobre Magento.
El rendiment en un ecommerce no és opcional. Un lloc lent perd vendes. Amb 15 botigues servint trànsit de tota Europa, l'stack ha de ser sòlid.
Arquitectura de memòria cau
La configuració de desenvolupament Magento que vam muntar per a Loviux segueix una jerarquia de 4 capes:
- Varnish 7.x com a reverse proxy: emmagatzema pàgines completes a la memòria cau. Un hit de Varnish serveix una pàgina en <10ms sense tocar PHP. Vam configurar VCL personalitzat per a purge selectiu per store view, categoria i producte.
- Redis per a memòria cau d'aplicació i sessions: elimina accessos a disc. Dues instàncies separades: una per a memòria cau de configuració/blocs (DB 0) i una altra per a sessions (DB 2).
- OPcache de PHP 8.4: precompila els ~40.000 fitxers PHP de Magento. Amb
opcache.jit=tracinghabilitat, les funcions hot path es compilen a codi màquina natiu. - Memòria cau de full page a Magento com a fallback per a requests que no passen per Varnish (usuaris autenticats, cistella no buida).
CSS bloquejant: una decisió contraintuïtiva per a CLS 0
La saviesa convencional diu: carrega CSS de forma asíncrona, extreu critical CSS inline. Nosaltres vam fer el contrari. Tot el CSS es carrega de forma bloquejant al <head>.
Per què? Perquè amb Hyvä + Tailwind, el CSS total és ~35 KB (gzipped: ~8 KB). Carregar-lo bloquejant afegeix uns mil·lisegons al First Contentful Paint, però garanteix que el layout mai no canvia després del primer renderitzat. El resultat: CLS (Cumulative Layout Shift) de 0.000 consistent a totes les pàgines.
En un projecte amb desenes de plantilles diferents (inici, categoria, producte, checkout, pàgines CMS × 15 botigues), mantenir un sistema de critical CSS sincronitzat seria un malson de manteniment. Amb 8 KB de CSS bloquejant, el trade-off no té sentit.
Deploy zero-downtime amb symlink switching
El deploy en producció segueix un flux que evita temps d'inactivitat:
- Build en directori temporal (
/var/www/releases/YYYYMMDD-HHMMSS/) composer install --no-dev,bin/magento setup:di:compile,bin/magento setup:static-content:deployper als 9 idiomes- Warm-up de memòria cau: executem requests a pàgines clau per omplir Varnish
- Atomic symlink switch:
ln -sfncanvia el symlink/var/www/currental nou release php-fpm reloadperquè els workers carreguin el codi nou- Purge selectiu de Varnish
Si alguna cosa falla, el rollback és canviar el symlink al release anterior. Temps d'indisponibilitat: 0 segons.
El setup:static-content:deploy per a 9 idiomes tarda ~12 minuts. És el pas més lent del pipeline, però com que s'executa abans del switch, no afecta el trànsit en viu.
SEO tècnic multiidioma
Un ecommerce amb 15 botigues i 9 idiomes és un camp minat de SEO tècnic. Google necessita entendre quina pàgina és per a quin país i quin idioma, sense confondre variants.
Hreflang a totes les pàgines
Cada pàgina inclou etiquetes hreflang que apunten a totes les seves variants:
Són 14 hreflangs per pàgina. Amb un catàleg de 60.000 productes, parlem de 168.000 declaracions hreflang només per a producte. Generem tot això dinàmicament amb un mòdul que consulta els URL rewrites de Magento per store view.
Structured data complet
Hem implementat Schema.org JSON-LD a totes les pàgines rellevants:
- Product: amb
offers,aggregateRating,brand,sku,gtin13quan està disponible. Google mostra rich snippets amb preu i disponibilitat. - CollectionPage: a pàgines de categoria, amb
numberOfItemsi breadcrumb. - BreadcrumbList: navegació jeràrquica completa (Inici → Categoria → Subcategoria → Producte).
- Organization: dades de l'empresa a la pàgina d'inici i pàgines de contacte.
- FAQPage: a pàgines de categoria que tenen preguntes freqüents de producte.
Tot validat amb el Rich Results Test de Google i sense errors a Search Console.
Sitemaps dividits per store
Un sitemap únic per a 15 botigues superaria el límit de 50.000 URLs. Generem sitemaps individuals per store view:
loviux.es/sitemap.xml→ sitemap index que apunta asitemap-products.xml,sitemap-categories.xml,sitemap-cms.xml- Mateix patró per a cada domini (.fr, .de, .it, .nl, .pt, .pl, .co.uk, .at, .ch, .be, .com)
Cada sitemap es regenera diàriament a les 5:00 AM i inclou <lastmod> basat en la darrera actualització real del contingut, no la data de generació. Google aprecia l'honestitat en els timestamps.
Integracions clau
Brevo per a email màrqueting
Hem connectat Magento amb Brevo (abans Sendinblue) per a automatització de correus transaccionals i màrqueting:
- Sincronització de contactes bidireccional (registre, compra, abandonament)
- Correus transaccionals (confirmació de comanda, enviament, factura) servits des de Brevo per a millor deliverability
- Workflows d'abandonament de cistella segmentats per botiga/idioma
GA4 Enhanced Ecommerce
Hem implementat el tracking complet de GA4 Enhanced Ecommerce amb 10 esdeveniments estàndard:
view_item, view_item_list, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase i refund.
Cada esdeveniment inclou la dimensió de store view per poder segmentar el rendiment per país/idioma als informes.
Cloudflare Turnstile
Hem substituït reCAPTCHA per Cloudflare Turnstile a tots els formularis: registre, inici de sessió, contacte, newsletter i checkout com a convidat. Turnstile no mostra challenges visibles a l'usuari (és invisible per defecte) i té millor ràtio d'acceptació que reCAPTCHA v3. En un ecommerce, cada fricció extra al checkout és una venda menys.
Què ens emportem d'aquest projecte
Després de mesos de desenvolupament, proves i optimització, aquests són els aprenentatges que més impacte han tingut:
- Hyvä no és opcional per a Magento 2 nou. Si comences un projecte avui amb Luma, comences amb deute tècnic. La diferència de rendiment és massa gran.
- El fallback d'idioma es dissenya abans de carregar el primer producte. Fer-ho després amb 60.000 productes ja carregats hauria estat un infern de migracions de dades.
- Magewire és la resposta correcta per al checkout a Hyvä. Mateix paradigma que la resta del frontend, sense dependències extra. Laravel Livewire va provar el concepte; Magewire el porta a Magento.
- La IA per a contingut de producte no substitueix els copywriters, però escala on ells no poden. 81.000 textos en 9 idiomes per 420 EUR és una equació que no admet debat. La revisió humana continua sent necessària per al 10-15% de casos especials.
- CSS bloquejant amb Hyvä té més sentit que critical CSS. Quan el teu CSS total pesa menys que una imatge d'avatar, la complexitat de mantenir critical CSS no compensa.
- Deploy zero-downtime és obligatori, no un nice-to-have. Amb 15 botigues i trànsit 24/7 des de múltiples zones horàries, no hi ha finestra de manteniment segura.
Si la teva empresa necessita escalar un ecommerce Magento 2, ja sigui una migració a Hyvä, un setup multi-store o integracions complexes, contacta amb el nostre equip. Fa més de 15 anys que construïm solucions d'ecommerce que funcionen a escala real.
