Lighthouse 100 op Magento met Hyvä — zo halen we het

Lighthouse 100 op Magento met Hyvä — zo halen we het

Een standaard Hyvä-installatie scoort vaak al 90+ op mobiel. Maar 90 is geen 100. De laatste tien punten kosten het meeste werk en leveren de meeste discussie op.

Wij zien bij klanten dat de sprong van 90 naar 100 zelden over Hyvä zelf gaat. Het gaat over images, third-party scripts en font loading. Hyvä geeft je een snel fundament. De rest doe je zelf.

In dit artikel laten we zien hoe wij concreet naar Lighthouse 95-100 gaan. Met echte cijfers, geen theorie.

Eerst dit: Lighthouse is geen doel

Lighthouse meet in een lab, op een gesimuleerde 4G-verbinding met throttled CPU. Dat is geen echte gebruiker. Google rankt op field data (CrUX), niet op je lab-score.

Wat telt:

• LCP (Largest Contentful Paint) — onder 2,5 seconden
• CLS (Cumulative Layout Shift) — onder 0,1
• INP (Interaction to Next Paint) — onder 200 ms

Een Lighthouse 100 die in het lab perfect is maar in het veld faalt, is waardeloos. Wij optimaliseren altijd op de echte cijfers eerst. De 100 in het lab volgt dan vanzelf.

Toch is die 100 nuttig. Het dwingt discipline af. Elke afgetrokken punt heeft een oorzaak die je kunt fixen.

Het verschil tussen Hyvä en Luma als startpunt

Met Luma begin je op een achterstand. KnockoutJS, RequireJS en jQuery laden samen al snel 400-700 KB JavaScript op de homepage. Dat haal je er niet meer uit zonder Luma te ontmantelen.

Hyvä laadt op een gemiddelde categoriepagina rond de 30-50 KB JavaScript (Alpine.js + Tailwind). Dat is een factor tien minder. De startscore is daarom totaal anders.

In onze eigen Hyvä vs Luma performance-vergelijking zagen we LCP-verschillen van meer dan 2 seconden op identieke hardware. De checkout-vergelijking liet hetzelfde patroon zien.

Conclusie: zonder Hyvä is Lighthouse 100 op Magento praktisch onhaalbaar. Met Hyvä is het werk.

Image strategie: hier verlies je de meeste punten

Images zijn op 8 van de 10 shops de grootste LCP-boosdoener. De productfoto of hero-banner is bijna altijd het LCP-element.

Wat wij doen:

AVIF is gemiddeld 30-50% kleiner dan WebP bij dezelfde kwaliteit. Een hero van 180 KB WebP wordt zo 95-110 KB AVIF.

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="..." width="1200" height="600">
</picture>

Zonder afmetingen reserveert de browser geen ruimte. Resultaat: layout shift en een hogere CLS. Vaste afmetingen zijn de goedkoopste CLS-winst die er is.

Een 1600px-image in een 400px-container is verspilling. Wij genereren responsive varianten met srcset en sizes, afgestemd op de echte breakpoints.

Een CDN dat on-the-fly converteert naar AVIF/WebP en resized op basis van de Accept-header scheelt enorm veel handwerk. Je upload één bron-image, de bezoeker krijgt het optimale formaat. Wij koppelen dit vaak aan een image-service zodat redacteuren geen rekening hoeven te houden met formaten.

Zet decoding="async" op niet-kritieke images. De browser blokkeert dan de main thread niet tijdens het decoden. Klein detail, telt op bij categoriepagina's met dertig productfoto's.

Alleen image-optimalisatie tilt een gemiddelde Hyvä-shop vaak van 88 naar 96. Het is de hoogste ROI van alle maatregelen in dit artikel.

Critical CSS en de Tailwind-purge

Hyvä gebruikt Tailwind met PurgeCSS. In productie blijft daardoor vaak maar 8-14 KB CSS over. Dat is al heel goed.

Toch trekt Lighthouse soms "render-blocking resources" af. Twee dingen:

• Controleer of de purge écht draait in je productie-build. Een misconfiguratie levert zomaar 200+ KB CSS op.
• Inline de critical CSS voor above-the-fold content. Bij Hyvä is de totale CSS zo klein dat je vaak de hele bundle inline kunt zetten zonder noemenswaardige kosten.

Let op je eigen custom CSS. Het zijn meestal niet de Hyvä-styles die opzwellen, maar wat een team er later bovenop bouwt. Wij zien shops waar de Hyvä-bundle nog netjes 12 KB is, maar er 90 KB aan losse component-CSS naast staat omdat iemand de purge-config niet snapte.

Praktisch advies: draai na elke grote frontend-wijziging een productie-build en check de werkelijke CSS-grootte in de Network-tab. Niet aannemen dat de purge nog klopt — controleren.

Font loading: de stille killer van LCP en CLS

Fonts veroorzaken twee problemen tegelijk: ze blokkeren rendering en ze schuiven tekst (FOIT/FOUT). Beide kosten punten.

Onze aanpak:

1. Self-host je fonts. Google Fonts via een externe CDN kost een extra DNS-lookup en connectie. Self-hosted scheelt 100-300 ms.
2. font-display: swap zodat tekst direct zichtbaar is. Geen onzichtbare tekst tijdens het laden.
3. Preload alleen het kritieke font.

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>

1. Gebruik WOFF2 en variable fonts. Eén variable font vervangt vaak 4-6 losse gewichtsbestanden.
2. Stel een fallback-font in met size-adjust om CLS bij font-swap te elimineren.

Een verkeerd geladen font kan op zichzelf al 5-8 Lighthouse-punten kosten. Dit wordt structureel onderschat.

Third-party scripts: waar de 100 sneuvelt

Hier verliest bijna iedereen. Je shop is technisch perfect, en dan plakt marketing er Google Tag Manager, Hotjar, een chat-widget en drie pixels op.

Wat wij in de praktijk meten:

• Google Tag Manager: 100-300 KB, plus alles wat erin geladen wordt
• Een chat-widget: vaak 200-500 KB, soms render-blocking
• Trustpilot/review-widgets: 50-150 KB, vaak met layout shift

Onze maatregelen:

• Lazy-load wat niet boven de fold hoeft. Een chat-widget hoeft niet bij eerste paint te laden. Laad hem na interactie of na een paar seconden idle.
• GTM later inladen. Niet in de blocking, maar na load of via een delay. De meeste tags hoeven niet binnen de eerste seconde te vuren.
• Pixels challengen. Wij vragen altijd: wordt deze data daadwerkelijk gebruikt? Vaak staan er pixels op van campagnes die jaren dood zijn.
• Facades voor embeds. Een YouTube-embed laad je als statische thumbnail die pas bij klik de echte player ophaalt. Scheelt zo 500+ KB.

Dit is geen technische maar een organisatorische strijd. Wij benoemen het eerlijk: een Lighthouse 100 met vijf marketing-tags actief is bijna onmogelijk. Soms is 92 met de juiste tooling het betere besluit.

INP: de nieuwe norm sinds 2024

INP verving FID als Core Web Vital. Het meet hoe snel je pagina reageert op interactie — een klik, een tap, een toetsaanslag.

Hyvä scoort hier sterk omdat Alpine.js veel lichter is dan KnockoutJS. Minder JavaScript op de main thread betekent snellere response. Wij meten bij Hyvä-shops doorgaans INP-waarden ruim onder de 200 ms.

Waar het misgaat:

• Zware third-party scripts die de main thread blokkeren
• Te grote Alpine-componenten die bij elke interactie veel werk doen
• Synchrone API-calls bij klikken (denk aan add-to-cart)

Fix: houd Alpine-componenten klein, debounce input-handlers, en doe netwerk-werk asynchroon. Een add-to-cart die de UI laat "hangen" tot de API antwoordt, is een INP-killer. Toon direct visuele feedback (optimistic UI) en verwerk het API-antwoord daarna.

Let ook op long tasks. Een JavaScript-taak langer dan 50 ms blokkeert de main thread en vertraagt elke interactie die in dat venster valt. Splits zwaar werk op met requestIdleCallback of een korte timeout, zodat de browser tussendoor kan reageren op de gebruiker.

Onze meetmethode: lab plus veld

Wij vertrouwen nooit op één Lighthouse-run. De variatie tussen runs is te groot.

Onze workflow:

1. Lab: Lighthouse via CLI, minimaal 5 runs, mediaan pakken. Niet de cijfers uit de browser-tab — die zijn vervuild door extensies.
2. Veld: CrUX-data via PageSpeed Insights en Search Console. Dit is wat Google echt ziet.
3. Real User Monitoring: waar mogelijk eigen RUM, zodat we INP per pagina-template kunnen volgen.

Een typisch traject bij een Magento-shop met Hyvä:

De grootste sprong zit altijd bij images en fonts. De laatste paar punten kosten het meeste werk en zitten in de third-party hoek.

Wanneer 100 niet het juiste doel is

Eerlijk: voor veel shops is 95 met goede field data beter dan een geforceerde 100. Als je voor die laatste punten je chat-widget moet slopen die conversie oplevert, ben je verkeerd bezig.

Lighthouse is een middel. Omzet en conversie zijn het doel. Wij adviseren regelmatig om bij 96-97 te stoppen en de energie in CRO te steken.

Overweeg je een overstap naar Hyvä, lees dan eerst hoe je Hyvä installeert op een bestaande Magento-shop. Wil je sparren over wat realistisch is voor jouw shop? Neem contact met ons op — wij zijn Hyvä Certified en kijken graag mee zonder verkooppraatje.

Veelgestelde vragen

Haalt Hyvä standaard al Lighthouse 100?

Nee. Een verse Hyvä-installatie scoort vaak 88-93 op mobiel. Het fundament is uitstekend, maar images, fonts en third-party scripts bepalen de rest. Die staan los van Hyvä.

Is AVIF al veilig om te gebruiken?

Ja. Alle moderne browsers ondersteunen AVIF sinds 2023. Met een -element en WebP/JPG als fallback dek je 100% van de bezoekers. Je verliest niets en wint 30-50% bestandsgrootte.

Waarom blijft mijn LCP hoog ondanks een hoge score?

Vrijwel altijd door je LCP-element. Controleer of je hero-image niet lazy-loadt, fetchpriority="high" heeft, en in AVIF/WebP wordt geserveerd op de juiste afmeting. Een verkeerd geladen LCP-image alleen al kost je 1-2 seconden.

Wat doe ik met marketing-tags die de score verpesten?

Lazy-load of vertraag ze. GTM hoeft niet render-blocking in de . Chat-widgets en embeds laad je pas na interactie of idle. Challenge daarnaast elke pixel: ongebruikte tags eruit.

Hoe belangrijk is Lighthouse echt voor SEO?

Indirect. Google rankt op field data (Core Web Vitals via CrUX), niet op je lab-score. Een hoge Lighthouse-score is een goede proxy, maar optimaliseer altijd eerst op de echte LCP, CLS en INP van je bezoekers.