Inhoud van dit artikel
- Core Web Vitals: wat Google meet
- Waarom Luma structureel zwaar is
- Hoe Hyvä het anders doet
- Media-optimalisatie: de grootste LCP-hefboom
- HTML-first is beter crawlbaar
- Wat Hyvä niet voor je regelt
- Hoe groot is het SEO-effect?
- Meten: baseline vóór de migratie
- Technische noot: Tailwind v4 en design tokens
- Suite versus losse tooling
- Adobe Commerce en B2B
- Wanneer Hyvä Commerce niet de juiste keuze is
- Hyvä als SEO-fundament
Hyvä is gebouwd als HTML-first frontend. De server levert complete pagina's, interactiviteit komt van een kleine laag Alpine.js, en de zware Luma-stack met RequireJS, Knockout en jQuery is weg. Dat heeft gevolgen voor Core Web Vitals, voor hoe Google je shop crawlt, en voor conversie. Dit artikel legt uit waar de winst zit, waar niet, en wat je zelf nog moet regelen.
Core Web Vitals: wat Google meet
Google beoordeelt de paginabeleving met drie metrics. Een pagina is "goed" als het 75e percentiel van echte bezoekers onder deze grenzen blijft:
| Metric | Wat het meet | Goed |
|---|---|---|
| LCP (Largest Contentful Paint) | Hoe snel het grootste zichtbare element staat | ≤ 2,5 seconde |
| INP (Interaction to Next Paint) | Hoe snel de pagina reageert op klikken en invoer | ≤ 200 ms |
| CLS (Cumulative Layout Shift) | Hoeveel de layout verschuift tijdens het laden | ≤ 0,1 |
INP verving in maart 2024 FID als responsiviteitsmetric. Oudere artikelen die nog over FID gaan, zijn op dat punt achterhaald.
Belangrijk onderscheid: Google kijkt naar velddata van echte Chrome-gebruikers (CrUX), niet naar een Lighthouse-score. Lighthouse is een labtest op één apparaat en één netwerkprofiel. Handig om te debuggen, maar een hoge Lighthouse-score is geen garantie voor groene Core Web Vitals in Search Console.
Waarom Luma structureel zwaar is
Een Luma-frontend laadt standaard een grote hoeveelheid JavaScript: RequireJS als module-loader, Knockout voor UI-componenten, jQuery en jQuery UI, plus alles wat extensies toevoegen. Dat raakt alle drie de metrics:
- LCP: render-blocking scripts en CSS vertragen het moment waarop de hero-afbeelding of productfoto verschijnt.
- INP: event handlers die pas na interactie via RequireJS worden geladen, en Knockout-observables die bij klikken veel DOM-werk doen, houden de main thread bezet.
- CLS: afbeeldingen en blokken zonder vaste afmetingen, en content die client-side wordt ingevoegd.
Dat is een architectuurprobleem, geen hostingprobleem. Een zwaardere server maakt de backend sneller, maar niet het JavaScript in de browser van je klant.
Hoe Hyvä het anders doet
Hyvä Commerce bouwt op Hyvä Theme, dat sinds november 2025 gratis en open source is. De frontend gebruikt:
- Tailwind CSS: alleen de classes die in je templates voorkomen, belanden in de stylesheet.
- Alpine.js: interactiviteit staat als attributen in de HTML (
x-data,x-on:click). Er is geen module-loader die eerst moet uitzoeken wat er geladen moet worden. - Geen RequireJS, Knockout of jQuery als basis.
Per metric betekent dat:
LCP
Omdat de HTML compleet van de server komt en er weinig render-blocking JavaScript is, hangt LCP vooral af van twee dingen die je zelf in de hand hebt: serverresponstijd (TTFB, dus caching en hosting) en de LCP-afbeelding. Op productpagina's is dat bijna altijd de hoofdfoto. Zorg dat die niet lazy wordt geladen, het juiste formaat heeft en waar zinvol fetchpriority="high" krijgt.
INP
Minder JavaScript betekent minder werk op de main thread. Alpine-componenten zijn klein en worden direct bij het laden geïnitialiseerd. INP gaat op een Hyvä-shop vooral mis door scripts van derden: tag managers, chatwidgets, review-widgets en A/B-testtools. Die moet je net zo kritisch bekijken als op elke andere stack.
Hyvä Checkout is gebouwd op Magewire, een Magento-port van Laravel Livewire, in combinatie met Alpine.js. De checkout-logica draait grotendeels server-side in PHP-componenten. Je hebt geen Knockout-checkout met honderden observables meer.
CLS
Statische HTML met vaste afmetingen voor afbeeldingen geeft weinig layout-verschuiving. Let wel op banners en cookiemeldingen die bovenaan de pagina inschuiven: die veroorzaken op elke stack CLS.
Media-optimalisatie: de grootste LCP-hefboom
Afbeeldingen zijn het grootste deel van het paginagewicht en bepalen meestal de LCP. Hyvä Commerce bevat daarvoor twee merchant-tools:
- Media Optimization: resizen en converteren naar WebP en AVIF, met keuze uit GD of Imagick als engine en instelbare kwaliteit. Een observer vervangt afbeeldingen in de pagina-HTML door de geoptimaliseerde versies, en de Hyvä CMS-componenten gebruiken het standaard. Hyvä markeert deze feature op het moment van schrijven nog als beta.
- Image Editor: bijsnijden en aanpassen in de admin, zodat contentmensen geen te grote bestanden meer uploaden.
Meer hierover in ons artikel over de image editor en media-optimalisatie. Zonder Hyvä Commerce regel je dit met een losse extensie of een image-CDN.
HTML-first is beter crawlbaar
Google kan JavaScript renderen, maar dat gebeurt in een tweede stap en kost resources. Een pagina die pas na client-side rendering inhoud krijgt, loopt het risico dat Google eerst een lege of halve pagina ziet, of later indexeert.
Hyvä verstuurt volledige HTML. Dat geeft:
- Content in de eerste respons. Productinformatie, prijzen en interne links staan direct in de HTML.
- Efficiënter crawlen. Snellere, lichtere pagina's betekenen dat Googlebot met hetzelfde crawlbudget meer pagina's ophaalt. Dat telt voor grote catalogi.
- Betrouwbare structured data. Schema.org-markup die server-side in de HTML staat, is direct leesbaar en hangt niet af van JavaScript-uitvoering.
Dit is ook het verschil met headless frontends: daar moet server-side rendering goed geconfigureerd zijn, anders indexeert Google een lege shell.
Wat Hyvä niet voor je regelt
Een snelle frontend is een goed fundament, geen complete SEO-setup. Deze punten staan los van het thema:
- Hreflang. Magento genereert standaard geen hreflang-tags voor meertalige storeviews. Daar heb je een extensie of maatwerk voor nodig, ook op Hyvä.
- Canonicals. Magento heeft opties voor canonical tags op product- en categoriepagina's, maar die moet je aanzetten en controleren.
- Gefilterde navigatie. Filtercombinaties kunnen duizenden URL's opleveren. Bepaal welke indexeerbaar zijn en blokkeer of canonicaliseer de rest.
- Structured data. Controleer welke Product-, Offer- en BreadcrumbList-markup je thema en extensies uitsturen, en valideer die met de Rich Results Test.
- Scripts van derden. Een snelle Hyvä-basis wordt zo traag als de zwaarste tag die je erbij zet.
Hoe groot is het SEO-effect?
Core Web Vitals zijn een rankingsignaal, maar relevantie weegt zwaarder. In de praktijk:
- Bij vergelijkbare relevantie heeft de snellere pagina een voordeel.
- Een duidelijk relevantere pagina wint ook met slechtere performance.
- Op categoriepagina's, waar veel shops vergelijkbare content hebben, telt de technische basis relatief zwaar.
Het grootste effect van snelheid zit vaak niet in de ranking zelf, maar in wat bezoekers doen nadat ze binnenkomen: minder afhakers op mobiel en meer sessies die doorlopen naar product en checkout.
Rekenformule voor je eigen businesscase
Gebruik je eigen cijfers. Het voorbeeld hieronder is een illustratie met aannames, geen voorspelling.
extra omzet per maand = (bezoekers_na × conversie_na − bezoekers_nu × conversie_nu) × gemiddelde orderwaarde
Aannames in dit voorbeeld: 10.000 organische bezoekers per maand, 1,2% conversie, € 85 gemiddelde orderwaarde. Stel dat het verkeer 5% stijgt en de conversie naar 1,3% gaat:
(10.500 × 0,013 − 10.000 × 0,012) × € 85 = (136,5 − 120) × € 85 ≈ € 1.400 per maand
Reken ook een scenario door waarin er niets verandert aan verkeer en alleen de conversie iets beweegt. Klopt je businesscase alleen in het optimistische scenario, dan is hij niet sterk genoeg.
Meten: baseline vóór de migratie
Zonder nulmeting kun je achteraf niets aantonen. Leg vóór de migratie vast:
- CrUX-velddata per paginatype (home, categorie, product, checkout) via PageSpeed Insights of het Core Web Vitals-rapport in Search Console.
- RUM-data als je die hebt. Real User Monitoring laat per pagina en per apparaat zien waar LCP en INP misgaan, in plaats van een gemiddelde over 28 dagen.
- Search Console: vertoningen, klikken en indexeringsstatus per paginatype.
- Conversie per apparaat uit je analytics.
Meet na livegang opnieuw, maar houd rekening met vertraging: CrUX werkt met een voortschrijdend venster van 28 dagen.
Technische noot: Tailwind v4 en design tokens
Sinds Hyvä Theme 1.4 werkt Hyvä met Tailwind CSS v4. De configuratie zit dan niet meer in tailwind.config.js maar in CSS. Design tokens definieer je als CSS custom properties, bijvoorbeeld in Tailwind v4-syntax:
@theme {
--color-primary: #0f4c81;
--color-secondary: #f2a900;
}
Tailwind maakt daar utilities als bg-primary en text-secondary van. Bestaande thema's op Tailwind v3 migreer je met de upgrade-helper van Hyvä. De CSS-build draait tijdens de deploy; op de productieserver is geen Node-tooling nodig. Voor SEO is vooral het resultaat relevant: een kleine stylesheet met alleen de classes die je gebruikt.
Suite versus losse tooling
Veel Magento-shops proberen performance te fixen met losse oplossingen: een image-CDN, een eigen JavaScript-build, een checkout van een derde partij en een CMS-laag erbovenop. Dat kan werken, maar elke Magento-update vraagt dan om testen van vier losse onderdelen, en bij een teamwissel weet niemand meer precies hoe het in elkaar zit.
Hyvä Commerce bundelt thema, checkout, UI-componenten en merchant-tools in één suite met één update-pad. Minder losse extensies betekent minder conflicten en minder uitgestelde updates. Een codebase die bijgehouden wordt, blijft ook snel.
Adobe Commerce en B2B
Hyvä Commerce draait op Magento Open Source en Adobe Commerce vanaf 2.4.4. Voor compatibiliteit met Adobe Commerce-functies, de B2B-suite en diensten als Live Search heb je wel een Hyvä Enterprise-licentie nodig. Reken dat mee als je op Adobe Commerce zit. De prijzen staan in ons artikel over kosten en licentie van Hyvä Commerce.
Wanneer Hyvä Commerce niet de juiste keuze is
- Organisch verkeer is geen prioriteit en je shop heeft weinig bezoekers. Dan is de SEO-winst klein.
- Je wilt volledig headless, met een aparte React- of Next.js-frontend. Hyvä is geen headless oplossing.
- Je zit niet op Magento. Hyvä werkt alleen met Magento 2 en Adobe Commerce.
- Je huidige thema scoort al goed in de velddata. Dan boek je SEO-winst goedkoper met gerichte optimalisaties.
- Je hebt veel Luma-extensies zonder Hyvä-ondersteuning. Inventariseer die eerst.
- Je zit onder Magento 2.4.4. Dan is de Magento-upgrade de eerste stap.
- Alleen snelheid is het doel. Dan is het gratis Hyvä Theme genoeg; Hyvä Commerce betaal je vooral voor de merchant-tools.
Hyvä als SEO-fundament
De technische basis bepaalt hoeveel je content en linkbuilding opleveren. Goede content op een trage, slecht crawlbare shop laat resultaat liggen. Hyvä is daarom geen cosmetische thema-upgrade, maar een infrastructuurkeuze met SEO-gevolgen. Combineer het met goede on-page SEO en een doordachte interne linkstructuur.
Wil je weten wat het voor jouw shop oplevert? In een gratis Tech Check analyseren we je velddata, crawlbaarheid en technische setup, en vertellen we eerlijk of Hyvä in jouw geval de juiste stap is. Meer over onze aanpak op de Hyvä-pagina, of neem direct contact op.





