Hyvä en SEO: hoe een snelle frontend je rankings verbetert

Hyvä en SEO: hoe een snelle frontend je rankings verbetert

Een Luma-shop laadt gemiddeld 4 tot 7 seconden. Een Hyvä-shop haalt vaak een Largest Contentful Paint onder de 1,5 seconde. Dat verschil voel je niet alleen als gebruiker. Google ziet het ook.

Maar laten we eerlijk beginnen. Snelheid alleen brengt je niet naar positie 1. Wij zien bij klanten dat een snelle frontend een versterker is, geen vervanger voor content, autoriteit en techniek. Hyvä lost je SEO-problemen niet op. Het haalt wel een rem van je af.

In dit artikel leggen we uit hoe die rem werkt: via Core Web Vitals, server-side rendering, structured data en crawl budget. En waar de grenzen liggen.

Core Web Vitals: een rankingfactor, geen hoofdrol

Google bevestigde in 2021 dat page experience meeweegt in de ranking. Core Web Vitals zijn daar de meetbare kern van. Sinds maart 2024 bestaan ze uit drie metrics:

• LCP (Largest Contentful Paint) — hoe snel het grootste element zichtbaar is. Doel: onder 2,5 seconde.
• INP (Interaction to Next Paint) — hoe snel de pagina reageert op input. Doel: onder 200 milliseconde.
• CLS (Cumulative Layout Shift) — hoeveel de layout verspringt tijdens laden. Doel: onder 0,1.

INP verving FID in maart 2024. Dat is relevant, want INP is veel zwaarder afhankelijk van JavaScript-uitvoering. En juist daar zit het probleem van klassieke Magento-themes.

Google meet deze waarden op twee manieren. Lab-data komt uit Lighthouse, een gesimuleerde test in een schone omgeving. Field-data komt uit het Chrome User Experience Report (CrUX): echte metingen van echte bezoekers. Voor ranking telt alleen de field-data. Een mooie Lighthouse-score met slechte CrUX-cijfers helpt je niets. Wij sturen daarom altijd op de field-data in Search Console, niet op een eenmalige labtest.

Hoe zwaar wegen CWV nu echt? Beperkt. Het is een tiebreaker. Als twee pagina's qua relevantie en autoriteit dicht bij elkaar liggen, wint de snelste. Bij volledig ongelijke content maakt snelheid weinig uit. Wie dat negeert, jaagt op de verkeerde knoppen.

Waarom Luma de Core Web Vitals sloopt

Het standaard Magento-theme (Luma) leunt op drie zware lagen: jQuery, RequireJS en Knockout.js. Samen vaak meer dan 1 MB aan JavaScript voordat er ook maar iets klikbaar is.

Dat raakt direct twee metrics:

• INP lijdt onder de main-thread blocking van al die scripts. De browser is bezig met parsen terwijl de gebruiker al wil klikken.
• LCP lijdt omdat kritieke rendering wacht op JavaScript dat eerst geladen, geparsed en uitgevoerd moet worden.

Wij meten bij Luma-shops in het veld regelmatig INP-waarden van 300 tot 600 milliseconde op mobiel. Ruim boven de grens van 200. Dat is geen configuratiefout. Dat is de architectuur.

Hoe Hyvä de Core Web Vitals omdraait

Hyvä gooit de zware laag eruit. Geen RequireJS, geen Knockout, geen jQuery. In plaats daarvan:

• Alpine.js — circa 10 KB voor lichte interactiviteit.
• Tailwind CSS — alleen de gebruikte classes worden gebouwd, vaak onder 20 KB.
• HTML-first rendering — de pagina is grotendeels bruikbaar voordat JavaScript klaar is.

Het resultaat in cijfers dat we consistent terugzien:

Deze getallen variëren per shop, hosting en aantal third-party scripts. Maar de richting is altijd dezelfde. We gingen dieper op de meetmethode in onze Hyvä vs Luma performance-vergelijking.

Belangrijk: Hyvä geeft je een goede uitgangspositie. Een marketingteam dat daarna vier tracking-scripts en een chatwidget toevoegt, kan de winst alsnog verdampen. De architectuur is goed. De discipline moet erbij.

Server-side rendering en HTML-first: wat Google ziet

Googlebot rendert JavaScript, maar in twee fasen. Eerst crawlt het de ruwe HTML. Daarna, soms dagen later, rendert het de JavaScript in een aparte render-wachtrij. Hoe meer content achter JavaScript verstopt zit, hoe groter het risico dat Google iets mist of vertraagd indexeert.

Hyvä is HTML-first. De Magento-backend rendert de volledige pagina server-side. Productnaam, prijs, beschrijving, categorieteksten — alles staat direct in de HTML. Alpine.js voegt daarna alleen interactie toe, geen content.

Voor Google betekent dat:

• Content is meteen leesbaar in de eerste crawl-fase. Geen wachten op rendering.
• Geen render-budget verspild aan zware client-side hydration.
• Minder kans op indexatiegaten bij grote catalogi.

Dit is een onderschat voordeel. Een React- of Vue-SPA op je productpagina's zonder degelijke SSR is een gok met je indexatie. Hyvä omzeilt dat probleem door de Magento-architectuur te respecteren in plaats van te vervangen.

Een concreet voorbeeld uit de praktijk. Bij een klant met een headless setup stond de prijs alleen in de gerenderde JavaScript, niet in de ruwe HTML. Google indexeerde productpagina's zonder prijs, waardoor de price-snippet in de SERP wegviel. Na de overstap naar Hyvä stond de prijs direct in de broncode. De rich snippet kwam binnen twee weken terug. Dat is het verschil tussen HTML-first en JavaScript-first in de echte wereld.

Structured data: rich results zonder gedoe

Structured data (JSON-LD) bepaalt of je rich snippets krijgt: sterren, prijzen, voorraadstatus, FAQ-blokken in de zoekresultaten. Die snippets verhogen je click-through rate, soms met dubbele cijfers, zonder dat je positie verandert.

Hyvä behoudt de structured data die Magento standaard genereert voor producten en categorieën. Omdat de rendering server-side gebeurt, staat de JSON-LD direct in de broncode. Google hoeft er niet voor te renderen.

Wat wij in de praktijk doen bij een Hyvä-implementatie:

• Product schema met price, availability en aggregateRating.
• BreadcrumbList voor de navigatiepaden in de SERP.
• Organization en LocalBusiness voor merkherkenning.
• FAQPage op content- en categoriepagina's waar relevant.

Let op: structured data is geen directe rankingfactor. Het verbetert je presentatie, niet je positie. Maar een hogere CTR op dezelfde positie levert wel meer verkeer. En dat is uiteindelijk waar het om gaat.

Crawl budget: snelheid betekent meer geïndexeerde pagina's

Google geeft elke site een crawl budget: het aantal pagina's dat het binnen een bepaalde tijd ophaalt. Voor een webshop met 200 producten is dat geen probleem. Voor een catalogus met 50.000 SKU's, gefilterde categoriepagina's en varianten wel.

Crawl budget hangt deels af van responstijd. Hoe sneller je server reageert, hoe meer pagina's Google per sessie ophaalt. Een trage Luma-shop met hoge Time To First Byte krijgt minder pagina's gecrawld per dag.

Hyvä helpt hier op twee manieren:

• Lagere TTFB en snellere page loads laten Googlebot meer pagina's per crawl-sessie verwerken.
• Minder JavaScript-rendering betekent minder render-budget per pagina.

Voor grote Magento-catalogi is dit een reëel SEO-voordeel. Snellere crawling betekent snellere indexatie van nieuwe producten en snellere herkenning van prijswijzigingen. Bij seizoensdrukte telt elke dag.

Wil je weten of crawl budget jouw bottleneck is? Check in Google Search Console de Crawl Stats: gemiddelde responstijd en aantal gecrawlde pagina's per dag. Daar zie je de waarheid, niet in een marketingverhaal.

Eerlijk: waar Hyvä je SEO niet redt

Tijd voor de nuance. Hyvä is een frontend-framework, geen SEO-strategie. Het lost een aantal technische problemen op. Andere niet.

Hyvä doet niets aan:

• Content — dunne categorieteksten en ontbrekende productbeschrijvingen blijven dun en ontbrekend.
• Backlinks en autoriteit — een snelle shop zonder linkprofiel rankt nog steeds niet voor competitieve termen.
• Keyword-targeting — verkeerde of ontbrekende keywords fix je niet met snelheid.
• Slechte URL-structuur of canonical-fouten — dat is configuratie, geen framework.

Wij zijn hier streng in. Een klant die overstapt op Hyvä en verwacht dat de rankings vanzelf stijgen, komt bedrogen uit. De realistische uitkomst: een betere uitgangspositie, hogere conversie door snellere checkout, en op termijn een lichte rankingwinst op concurrerende termen. Geen magie.

Wat de conversie betreft: snelheid verdient zichzelf vaak sneller terug via meer afgeronde aankopen dan via rankings. We dook daar dieper in bij Hyvä checkout vs Luma conversie. De SEO-winst is dan extra, geen hoofdreden.

Wanneer Hyvä de juiste keuze is

Hyvä is logisch als je:

• Een Magento 2-shop draait die te traag is op mobiel.
• Een grote catalogus hebt waar crawl budget speelt.
• Je conversie wilt verhogen via een snellere checkout.
• Toch al voor een redesign of replatform staat.

Hyvä is niet je eerste prioriteit als je content dun is, je geen autoriteit hebt opgebouwd of je technische SEO-basis (canonicals, redirects, sitemap) rammelt. Fix dat eerst.

Twijfel je of een migratie loont voor jouw specifieke situatie? Lees hoe een Hyvä-installatie op een bestaande shop verloopt, of leg je situatie aan ons voor via contact. Wij zeggen het eerlijk als snelheid niet je grootste probleem is.

Veelgestelde vragen

Is snelheid een directe rankingfactor in Google?

Ja, maar een beperkte. Core Web Vitals wegen mee als onderdeel van page experience. Het werkt vooral als tiebreaker tussen pagina's die qua relevantie en autoriteit dicht bij elkaar liggen. Bij ongelijke content maakt snelheid weinig uit.

Stijgen mijn rankings automatisch na een Hyvä-migratie?

Nee. Hyvä verbetert je technische uitgangspositie en Core Web Vitals, maar raakt content, backlinks en keyword-targeting niet aan. Reken op een betere basis en hogere conversie, met op termijn lichte rankingwinst op concurrerende termen. Geen directe sprong.

Wat is het grootste SEO-voordeel van Hyvä voor grote webshops?

Crawl budget. Door lagere TTFB en minder JavaScript-rendering haalt Googlebot meer pagina's per sessie op. Voor catalogi met tienduizenden SKU's betekent dat snellere indexatie van nieuwe producten en prijswijzigingen.

Behoudt Hyvä mijn structured data en rich snippets?

Ja. Hyvä rendert server-side en behoudt de JSON-LD die Magento genereert voor producten en categorieën. De structured data staat direct in de broncode, dus Google hoeft er niet voor te renderen. Wij breiden dit waar nodig uit met FAQ- en BreadcrumbList-schema.

Verlies ik SEO-waarde tijdens de migratie naar Hyvä?

Niet als het goed gebeurt. URL-structuur, redirects, canonicals en metadata blijven onaangeroerd, want Hyvä vervangt alleen de frontend, niet de Magento-backend. Risico ontstaat pas bij slordige uitvoering. Daarom toetsen wij de technische SEO-basis voor, tijdens en na de migratie.