High performance front-end development met Hyvä

29 May 2026

Lees ons verhaal over onze ervaring met Hyvä, wat we er goed aan vinden en hoe we het toepassen in onze dagelijkse praktijk.

Performance is altijd een zeer belangrijk topic in e-commerce geweest en dan met name performance van de front-end. Rock-solid en clean code en goede standaarden is iets waar we erg veel waarde aan hechten.

Hoe je goede performance bereikt is een vak apart en iets wat tijd en energie kost. Na jaren, ook al was het met een heel team en veel focus, onze eigen aanpak gehanteerd te hebben was daar 1,5 jaar geleden Hyvä. Hyvä sloot bijzonder goed aan bij onze eigen werkwijze en werkte vanuit dezelfde filosofie; minder onnodige code, meer performance. Verschil is dat Hyvä met een team van 4 personen (still growing) full-time aan deze optimalisatie werkten, iets wat wij onszelf simpelweg niet kunnen permitteren en waar onze klanten ook niet mee geholpen zouden zijn. Onze klanten houden van performance, maar ze willen ook een hele goede ux en fijne features Om die reden zijn wij partner en contributor bij Hyvä, maar middels deze post vertellen we er graag meer over.

Meer over Hyvä? We vragen het Sean

Door onze collega Sean eens een aantal gerichte vragen te stellen, willen we een inkijkje geven in onze ervaring met Hyvä, wat we er goed aan vinden en hoe we het toepassen in onze dagelijkse praktijk.

We leggen uit hoe we onze projecten opzetten, hoe we onze maatwerk oplossingen ontwikkelen en in onze thema’s Hyvä verwerken. Ook vertellen we iets meer over kleine tweaks en handigheidjes die we gebruiken in onze development-flow.

Sean, wie ben je en wat doe je zoal bij Mooore Digital?

Ik ben dus Sean en werkzaam als front-end developer, dat houdt dus in dat ik mij bezig houdt met het visuele deel van web-applicaties; webshops, websites of web-apps. Bij Mooore Digital is dat heel vaak een webshop in Magento. Daar valt qua techniek heel veel onder, css, JavaScript zoals Vue, React Typescript, het HTML-deel en best veel andere technische zaken die er bij komen kijken met formatting, component-based development, etc.

Je werkt al een aardige tijd bij Mooore Digital en hebt op het gebied van performance ook altijd actief meegewerkt aan optimalisaties in performance. Welke belangrijke optimalisaties of aanpak om performance te verbeteren heb je in de afgelopen jaren gezien?

Binnen Mooore Digital zelf en in het algemeen waren er veel ontwikkelingen op dit gebied. De grootste optimalisatie in het algemeen is wel voor afbeeldingen en Javascript, dat zijn vaak de boosdoeners voor performance en dan zeker ook voor Magento. Magento laadt namelijk veel Javascript.

In de laatste jaren is Google ook erg druk bezig geweest om te stimuleren dat er niet te grote afbeeldingen of verkeerde afbeelding types worden gebruikt en dit zijn de zaken die ook de grootste invloed hebben op bijvoorbeeld je pagespeed score.

Met Mooore Digital hebben we hier de laatste jaren ook altijd op gefocust. Zo doen wij voor diverse klanten JavaScript optimalisaties waarbij we er voor zorgen dat dit geminimaliseerd wordt en natuurlijk andere kleinere zaken die ook veel impact hebben zoals Lazy loading, First meaningfull paint, Cloudflare inschakelen voor omzetting van afbeeldingen, etc., etc.

Voor JavaScript ontwikkelden we een best wel complexe built-tool om zo custom builds te maken voor JavaScript. Dat zorgt ervoor dat de Require JS bundels “plat geslagen” worden. Het Javascript wordt dan niet minder, maar we zorgen wel dat het selecter en daarmee beter wordt ingeladen. Dat heeft echt impact op grote shops waar relatief veel JavaScript nodig is. Dit doe je niet voor iedere shop, want voor kleinere shops waar al niet te veel JavaScript in zit zorgt het juist voor vertraging als je het niet goed doet.

Kun je nog iets meer vertellen over die custom builds? Iets waar we als Mooore Digital veel in geïnvesteerd hebben.

Ik kan hier natuurlijk nog veel meer over vertellen, maar ik zou hier misschien apart dieper op in moeten gaan. Dat houd je van mij tegoed, maar in het kort zorg je ervoor dat je de gevraagde JavaScript gerichter serveert voor de specifieke pagina’s waar dat gevraagd wordt. Je kunt het zien als een soort van inhoudsopgave voor de applicatie met betrekking tot de benodigde JavaScript.

Dit is een eigen doorontwikkeling op iets wat in de community al eens opgestart was, de winst die we behalen liggen in de sfeer van 30-50% verbetering. De catalogus pagina verbetert over het algemeen het meest, wel 50% dus.

Hyvä is eigenlijk een soort van basis thema, net zoals Luma dat bijvoorbeeld is, maar dan met out-of-the-box al veel optimalisaties. Kun jij in het kort uitleggen wat Hyvä precies is?

Hyvä is eigenlijk gewoon een kale versie van het Magento thema, wat erop neer komt dat het van alle onnodige JavaScript is ontdaan. Hyvä laadt in principe alleen nog maar JavaScript waar het echt nodig is en de rest doet ie allemaal statisch met behulp van PHP of PHTML, dus ook geen rare hacks meer om bijvoorbeeld form velden en dat soort dingen goed te maken. Het maakt veel gebruik van wat browsers tegenwoordig al out-of-the-box ondersteunen en zo hebben ze er bijvoorbeeld voor gekozen om één utility-achtige JavaScript te laden die door developers heel makkelijk geadapteerd kan worden en daarbij direct ook heel klein gehouden is. Doordat het zo is ingericht zoals ik net beschrijf laden we ook de JavaScript standaard al heel gericht, alleen voor daar waar dat nodig is; blokken en pagina’s. Dus eigenlijk wel onze eerdere filosofie die ik net al noemde, maar dan al helemaal standaard in het thema verwerkt.

Wat was voor jullie front-end team de belangrijkste reden om Hyvä meer te gaan gebruiken, wat spreekt jou zo aan bij dit product?

De belangrijkste reden is de versimpeling in de front-end techniek. Als je Magento Luma pakt, dan zit daar best wel veel in qua techniek. Denk bijvoorbeeld aan knock-out, dat moet je echt wel onder de knie hebben en knock-out.js is ook best wel een oud Javascript framework, dat gebruiken we eigenlijk nergens anders meer dan bij Magento. Zo moet je in diezelfde categorie ook jQuery kennen, niet jQuery 3 maar jQuery 1, en ook LESS terwijl heel de wereld praktisch SASS is. Veel oude technieken bij Magento Luma dus, maar bij Hyvä kunnen we de nieuwere technieken ook fijn gebruiken, wat ons sowieso natuurlijk aanspreekt. Daarnaast is het ook clean en schoner werken.

Verder kunnen we veel makkelijker gebruik maken van de mogelijkheden van PHP, we kunnen zo bijvoorbeeld icons, de informatie van adresgegevens, etc. met een view model laden. Dit soort dingen doen we niet meer in een XML, maar rechtstreeks in een PHTML. De code is veel meer gebundeld bij zijn bestand, wat de code stukken schoner en meer geschikt maakt om modulair te verwerken. Je hoeft minder op allerlei verschillende plekken te werken om alles werkend te krijgen.

We hebben met een Hyvä webshop als front-enders ook enorm veel vrijheid. We kunnen de technieken en frameworks gebruiken die we willen, maar door bijvoorbeeld zoiets als Tailwind kunnen we ook snelheid ontwikkelen, daar heb je een mooie basis aan die ook consistentie bevordert.

Hoe zit het met headless development en PWA’s? Wat denken jullie daarvan en hoe moeten we dan Hyvä zien?

Ik wil niet zo bot zijn dat ik zeg dat Magento PWA niet bestaat, maar voor de meeste webshops, ook de grote, is Magento PWA vaak overkill. Magento PWA vereist wel dat je met bepaalde technieken en standaarden moet werken, waardoor je eigenlijk al weer snel vast zit op technieken die je eigenlijk niet per se wilt. Dit is juist waar we vanaf willen en met Hyvä maken we in die richting in ieder geval een goede stap en kunnen we ook qua performance meten met PWA’s als we dat willen. Plus daarbij; Magento PWA geeft ook nog steeds ontzettend veel JavaScript mee en vergt het maken van een Magento PWA dus nog steeds zo enorm veel werk dat je je moet afvragen of dit middel het doel wel rechtvaardigt.

Als je echt de app ervaring wil, dan is het misschien wel wat anders maar zelfs dan zou je jezelf dus nog grotere vragen moeten stellen en bijvoorbeeld moeten overwegen om echt een custom PWA te ontwikkelen in een headless front-end met Magento als achterliggend systeem. Of natuurlijk een Hyvä shop

Als voorbeeld voor de ontwikkelingen: wij zijn ook wel bezig geweest met bijvoorbeeld Vue Storefront, hebben daar ook in trainingen geïnvesteerd, maar zelfs daarvan kunnen we bijna wel zeggen dat het niet de moeite waard is als je het vergelijkt met Hyvä en de resultaten die je daarmee kunt behalen.

Hoe zit het dan met headless en Hyvä?

Het betekent zeker niet dat headless dood is, dat is echt wel een toekomst, maar ook binnen Hyvä ontwikkelen we al wel headless. Je kunt heel makkelijk binnen de front-end headless componenten ontwikkelen en inladen, daarin zijn geen beperkingen.

We ontwikkelen allerlei integraties, ook wel uit andere systemen. Zo zetten we bijvoorbeeld WordPress in als content-manager in combinatie met de Gutenberg builder, dat integreren we ook gewoon binnen Hyvä.

Je kunt gewoon doorontwikkelen en steeds meer headless worden, zeker als je zaken behandelt als component. Dit mixen en zo een soort van hybride variant, statische front-end mixen met een dynamische front-end, is ook steeds meer standaard. Kijk bijvoorbeeld naar Astro, Eleventy, NextJS.

Bouw bijvoorbeeld je cart met een headless Loyalty component daarin, dat is prima mogelijk. De monoliet, zoals Magento met een Luma thema nu is, zal in ieder geval steeds minder voorkomen.

Inmiddels hebben jullie aardig wat projecten ontwikkeld met Hyvä, wat is je daarin opgevallen en hoe is het bevallen?

Wat mij opgevallen is, zeker bij de start van Hyvä, is dat Hyvä snel groeit en het ontwikkelen in Hyvä prettig gaat. Qua modules gaat het steeds sneller, worden modules steeds meer compatible en zijn ook grote vendors zoals AheadWorks, Amasty en dergelijke bezig om haar modules te wijzigen. Dit zijn positieve ontwikkelingen en het groeit door waarbij er ook vanuit een compatiblity-list wordt gewerkt door al deze vendors. Ook de niet traditionele module-makers houden al rekening met Hyvä, zo heeft een partner van ons, Tweakwise, recent haar module nog compatible gemaakt met Hyvä.

Voor wat betreft module-makers in het algemeen zal een deel van de markt misschien wel wegvallen qua aanbod, maar dat hoeft niet per se erg te zijn want vaak is de kwaliteit van juist die partijen die niet zo goed meekomen al wat onder de maat. Het omzetten van modules die ontwikkeld zijn in het Luma eco-systeem is niet gemakkelijk, dat kost veel tijd en de kleinere module-makers worstelen daar wel mee. Soms baseren we onze modules ook op bestaande modules en verbeteren we deze gelijk of breiden we het uit terwijl we het compatible maken met Hyvä.

Wat overigens ook belangrijk is om te weten, is dat je überhaupt makkelijker zelf modules ontwikkelt, dit omdat het Hyvä dus een heel schone front-end is. We bouwen onze logica dan gewoon in het thema.

Samenvattend kan ik zeggen dat er een paar kleine keuzes zijn waar we minder achter staan, zoals tailwind waar we zelf meer van de utility, css-variables en component-based werken zijn, maar dat we het verder in alle opzichten erg plezierig vinden werken.

Waar moet je op letten qua development, kun je daar iets meer over vertellen?

Ik heb er net natuurlijk al veel over verteld, maar voor Hyvä valt het eigenlijk wel mee. Alles is goed gedocumenteerd en niet al te moeilijk of onnodig ingewikkeld. Het enige wat ik wel wil meegeven is dat je qua development goed moet nadenken over hoe je je check-out wil ontwikkelen. Je kunt terugvallen op Luma, je kunt gebruik maken van de Hyvä check-out of zelf je custom check-out ontwikkelen.

Een custom check-out doen we aan de spreekwoordelijke lopende band en voor ons is dat dus niet heel anders, maar als je dus in Hyvä ontwikkelt zijn de opties die ik net noem dus aan de orde. Hyvä check-out is voor ons echter nog niet compleet genoeg, maar wat wel een enorm voordeel is, is dat je niet al die bloat hebt die je bij bijvoorbeeld Luma wel ziet.

Een Luma check-out gebruiken is ook nog steeds niet uit den boze. Dat kunnen we prima doen, maar meestal strippen we die check-out nog wel. De keuze hangt voor ons vaak af van eventuele modules. Dit naast Hyvä is eigenlijk geen probleem, we zien de check-out ook als iets los en er zijn genoeg opties om die keuze gewoon te maken. Heb je wat meer budget, ga dan voor een React check-out.

Wat zou je collega developers adviseren wanneer zij hun front-end uitwerking willen verbeteren qua performance? Heb je bepaalde tips en tricks?

Voor Hyvä vooral letten op wat je aan het doen bent, dat je het inladen van CSS en JavaScript schoon houdt. Hiermee bedoel ik dat je al de code die je nodig hebt, het liefst in components, gebruikt op plekken waar het gepurged kan worden. Ga daarom ook niet met al te ingewikkelde en overdreven geneste structuren werken, houd het plat.

Verder doe je er goed aan om met Alpine of anders Vanilla JavaScript te werken, dit past goed bij Hyvä. Je kunt er daarbij soms voor kiezen om toch bundles te maken, omdat je het dan kunt cachen daar de JavaScript niet in de pagina’s leeft maar dus een bundle bestand is. Hyvä doet, op de css na, bijna alles inline en dat is iets waar je je op in moet stellen en dus goed over na moet blijven denken. De vraag is: “inline of niet inline” maar ook hier zou ik apart een keer wat dieper op in moeten gaan, want er valt een hele hoop te vertellen over de kleine keuzes die je kunt maken qua optimalisaties.

Een belangrijke stap qua performance dus en prettig om die optimalisatie al meer out-of-the-box gedaan te hebben maar wat is de volgende stap? Waar gaan of zijn jullie nu mee aan de slag?

We zijn voor een aantal klanten bezig om een aantal modules Hyvä Compatible te maken en ook in de community worden er allerlei makkelijke modules ontwikkeld, iets waar ik zelf in m’n vrije tijd ook aan werk. Voor het css components deel zijn we binnen Mooore Digital ook steeds meer bezig om te kijken hoe we dit kunnen oplossen met de css components of native style en we dat ook met design-tokens kunnen pluggen om zo ook onze eigen blocks goed te kunnen mixen met andere technieken zoals Tailwind e.d..

Interessante inzichten allemaal, maar er is natuurlijk meer dan alleen Hyvä wat er toe doet. Om af te sluiten: als je performance belangrijk vindt, waar kijk je dan nog meer naar?

Font pre-loading! Pre-fetchen van 3rd party scripts.

Probeer altijd te kijken naar wat je kan lazy-loaden, werk aan je lay-out shifts, zorg dat je ruimte voor elementen al reserveert op je pagina. Alles wat de browser moet pre-renderen kost je gewoon onnodig veel extra. Afbeeldingen en zaken als webP heb ik al genoemd, maar ook daar zijn het de kleine dingen die er toe doen zoals bijv. je afbeeldingen altijd een width en een height meegeven, de grootte van hoe je het wilt tonen op de pagina, of het werken met picture-elements, source-settings voor verschillende devices, etc., etc.

Thanks Sean! Je bent namens Mooore Digital regelmatig op events te vinden, waar kunnen we je tegenkomen? Nog aanraders qua events?

Het is natuurlijk stil geweest vanwege corona, maar recent ging ik met een aantal collega’s naar Hyväcamp in Aachen. Dit is meer een Hackathon, Uncoference.

Op dit moment is er nog steeds niet veel qua events, maar houd de MUGS in de gaten en wellicht binnenkort een Mooore Digital MUG.

We hopen dat dit je als lezer enkele interessante inzichten heeft gegeven. Inzichten in hoe je met Hyvä aan de slag kunt, waar we als Mooore Digital zoal mee bezig zijn en wat we belangrijk vinden. Onderwerpen die nog op onze planning staan om dieper op in te gaan zijn; het goed managen van Magento updates, het Agile werken aan een MVP en meer van dit soort zaken waar we in ons dagelijkse werk mee te maken hebben.

Volg ons op LinkedIn of Instagram om op de hoogte te blijven.