Is er een probleem dat snel moet worden opgelost?Spoedfix nodig?Vraag spoedhulp aan →
Blog

Praktische Magento 2-gidsen over upgrades, beveiliging, snelheid en migratie, geschreven door het MageBooster-team.

Core Web Vitals voor Magento 2: een praktische checklist voor INP en LCP

De huidige drempels voor LCP, INP en CLS, hoe je ze meet en een geprioriteerde checklist met Magento-specifieke fixes voor snellere webshops.
Magento 2-consultancy

In het kort

Een Magento 2-pagina haalt de Core Web Vitals als bij het 75e percentiel van echte bezoeken de LCP maximaal 2,5 seconden is, de INP maximaal 200 ms en de CLS maximaal 0,1. Bij de meeste webshops boek je de grootste winst met een werkende full page cache, een snelle LCP-afbeelding, minder JavaScript op de main thread en strakkere controle over tags van derden. Meet eerst met velddata en los het daarna op in de volgorde hieronder.

Core Web Vitals zijn de drie metrics van Google voor gebruikerservaring op het gebied van laden, interactiviteit en visuele stabiliteit. Voor een Magento 2- of Adobe Commerce-webshop zijn ze ook een nuttige gezondheidscheck: een slechte score wijst meestal op dezelfde problemen die conversie kosten, zoals trage niet-gecachete pagina's, zware RequireJS-bundels en tagmanagers die de main thread blokkeren.

Deze gids behandelt de huidige drempels, hoe je ze goed meet en de Magento-specifieke fixes die de cijfers meestal in beweging brengen.

De huidige drempels

Google beoordeelt elke metric op het 75e percentiel van de paginaladingen, apart voor mobiel en desktop. Sinds 12 maart 2024 heeft Interaction to Next Paint (INP) First Input Delay (FID) vervangen als metric voor responsiviteit.

MetricMeetGoedeKan beterSlecht
LCP (Largest Contentful Paint)Laden≤ 2.5 s2,5 s tot 4,0 s> 4,0 s
INP (Interaction to Next Paint)Responsiviteit≤ 200 ms200 ms tot 500 ms> 500 ms
CLS (Cumulative Layout Shift)Visuele stabiliteit≤ 0.10,1 tot 0,25> 0,25

PageSpeed Insights beoordeelt een pagina of origin als geslaagd wanneer het 75e percentiel van alle drie de metrics Goed is. Als er niet genoeg INP-data is, kan de beoordeling ook op alleen LCP en CLS slagen.

Hoe je meet: eerst velddata, dan labdata

CrUX en PageSpeed Insights

Het Chrome User Experience Report (CrUX) verzamelt data van echte gebruikers bij Chrome-gebruikers die daarvoor in aanmerking komen. De CrUX API levert een voortschrijdend gemiddelde over 28 dagen dat dagelijks wordt bijgewerkt, en PageSpeed Insights toont dezelfde velddata over de afgelopen 28 dagen. Voor URL's met weinig verkeer is soms alleen data op origin-niveau beschikbaar, of helemaal niets.

Een fix die je vandaag uitrolt, is pas na weken volledig zichtbaar in CrUX. Search Console groepeert bovendien vergelijkbare URL's, waardoor één trage template duizenden URL's naar beneden kan trekken. Controleer de resultaten per template: home, categorie, product, winkelwagen, checkout en zoeken.

Lighthouse en labtools

Lighthouse in PageSpeed Insights of Chrome DevTools geeft je een herhaalbare labmeting met diagnostiek. Gebruik die om oorzaken te vinden, zoals render-blocking resources of long tasks. Zie een labscore niet als je Core Web Vitals-resultaat. Labmetingen kunnen INP niet meten, want INP vereist echte gebruikersinteracties.

Real user monitoring (RUM)

CrUX vertelt je dát een template traag is. RUM vertelt je waarom, op welke apparaten en bij welke interacties. De open-source web-vitals JavaScript-bibliotheek van Google rapporteert LCP, INP en CLS uit echte sessies, inclusief attributiedata zoals het LCP-element en het doel van de traagste interactie. Stuur die events naar je analyticstool of een RUM-dienst en segmenteer op paginatype.

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

function send(metric) {
  navigator.sendBeacon('/rum', JSON.stringify({
    name: metric.name,
    value: metric.value,
    pageType: document.body.className, // Magento adds page-type classes to body
    attribution: metric.attribution
  }));
}

onLCP(send);
onINP(send);
onCLS(send);

Magento-specifieke fixes

1. Serverresponstijd en full page cache

Time to First Byte is het eerste deel van de LCP. De LCP-richtlijnen van Google splitsen LCP op in vier onderdelen (TTFB, resource load delay, resource load duration en element render delay) en stellen dat TTFB ongeveer 40% van het totaal zou moeten zijn. Een niet-gecachete Magento-pagina kan het grootste deel van het LCP-budget al opmaken voordat de browser ook maar één regel HTML binnenkrijgt.

De best practices van Adobe voor configuratie raden Varnish aan als page cache in productie. Schakel het in en vertel Magento waar purges naartoe moeten:

bin/magento config:set --scope=default --scope-code=0 system/full_page_cache/caching_application 2
bin/magento setup:config:set --http-cache-hosts=127.0.0.1:6081

Exporteer daarna de VCL via Stores > Settings > Configuration > Advanced > System > Full Page Cache. Controleer vervolgens je hitrate. Veelvoorkomende oorzaken van cache-misses in Magento zijn blokken met cacheable="false" in layout XML (waardoor de hele pagina niet meer gecachet kan worden), trackingparameters die de cache versnipperen en klantspecifieke content die server-side wordt gerenderd in plaats van via private content sections.

# Find layout XML that disables FPC for a whole page
grep -rn 'cacheable="false"' app/code app/design vendor/*/*/view/frontend/layout

Adobe raadt ook aan om indexers voor betere performance op Update on Schedule te zetten, zodat het opslaan van catalogusgegevens tijdens drukte geen zware herindexering veroorzaakt:

bin/magento indexer:set-mode schedule
bin/magento indexer:status

Let op: volgens Adobe moet de Customer Grid-index op Update on Save blijven staan.

2. Cache warming

Na elke deploy of volledige cache flush komen de eerstvolgende bezoekers bij PHP terecht. Warm direct na de deploy de waardevolste URL's op: home, topcategorieën, topproducten en belangrijke CMS-pagina's. Op Adobe Commerce op cloudinfrastructuur regelen de WARM_UP_PAGES en WARM_UP_CONCURRENCY post-deployvariabelen dit. Op self-hosted stacks volstaat een eenvoudige crawler over een sitemap (dit voorbeeld gebruikt GNU grep):

curl -s https://www.example.com/sitemap.xml \
  | grep -oP '(?<=<loc>)[^<]+' \
  | head -500 \
  | xargs -P 4 -I{} curl -s -o /dev/null -w "%{http_code} %{time_starttransfer} {}\n" {}

Maak van volledige cache flushes ook geen routine. Leeg specifieke cachetypes en vertrouw waar mogelijk op invalidatie op basis van tags.

3. De LCP-afbeelding

Op product- en categoriepagina's is het LCP-element meestal de hoofdafbeelding van het product of een herobanner. Google is duidelijk: lazy-load de LCP-afbeelding nooit en overweeg fetchpriority="high" erop te zetten, maar geef hooguit één of twee afbeeldingen een hoge prioriteit.

  • Verwijder loading="lazy" van de eerste galerijafbeelding en van banners boven de vouw.
  • Op Luma wordt de productgalerij via JavaScript geïnitialiseerd nadat de placeholderafbeelding is geladen. Controleer in DevTools welk element als LCP wordt gerapporteerd en zorg dat die afbeelding vroeg in de HTML wordt opgevraagd (of wordt gepreload) in plaats van pas door een script te worden ontdekt.
  • Lever afbeeldingen in de juiste afmetingen. De image cache van Magento schaalt productafbeeldingen per view; zorg dat de afmetingen in je view.xml overeenkomen met de werkelijke weergavegrootte.
  • Gebruik moderne formaten. Op Adobe Commerce op cloudinfrastructuur kan Fastly Image Optimization afbeeldingen automatisch naar WebP omzetten. Bij andere hosting gebruik je een image-dienst van een CDN of een betrouwbare extensie.
  • Lazy-load wel afbeeldingen onder de vouw, zoals productrasters na de eerste rij.

4. JavaScript: bundling en minificatie vs Hyvä

INP-problemen in Magento ontstaan meestal doordat de main thread bezet is. Luma laadt veel RequireJS- en Knockout-modules, en extensies voegen er nog meer aan toe.

De eigen documentatie van Adobe is voorzichtig over de ingebouwde opties. Die beschrijft dat native bundling alle bundels laadt, ook als een pagina er maar een paar nodig heeft, raadt tools van derden zoals r.js aan voor bundling en minificatie, merkt op dat HTTP/2 een goed alternatief voor bundling kan zijn en raadt de verouderde instellingen voor het samenvoegen van JS en CSS af. Minificatie kun je veilig inschakelen:

bin/magento config:set --lock-config dev/js/minify_files 1
bin/magento config:set --lock-config dev/css/minify_files 1

Voor thema's op basis van Luma zijn bundels per paginatype (common, catalog, checkout), gebouwd met r.js, de gedocumenteerde geavanceerde route.

De andere route is de frontend vervangen. Hyvä Theme bouwt de storefront opnieuw op met veel minder JavaScript, op basis van Alpine.js en Tailwind CSS. Sinds 10 november 2025 is Hyvä Theme gratis en open source (OSL3 + AFL3); Hyvä Checkout en de andere commerciële producten blijven betaald. Hyvä is een project, geen instelling: elke frontend-extensie heeft een Hyvä-compatibele versie of een herschrijving nodig, dus audit eerst je lijst met extensies.

5. Scripts van derden

Tagmanagers, chatwidgets, reviewwidgets, A/B-testtools en personalisatiescripts zijn veelvoorkomende oorzaken van een slechte INP en CLS. Loop ze een voor een na:

  • Verwijder tags die niemand gebruikt. Audit de tagmanager-container minstens elk kwartaal.
  • Laad niet-essentiële widgets pas na interactie van de gebruiker of als de browser niets te doen heeft, niet bij het laden van de pagina.
  • Reserveer ruimte voor alles wat laat rendert (reviewsterren, banners, cookiebalken) om layoutverschuivingen te voorkomen.
  • Breek lange taken in je eigen code op. Google definieert een long task als alles boven 50 ms en raadt aan de main thread vrij te geven met scheduler.yield(), met setTimeout als fallback waar dat niet wordt ondersteund.

6. Layoutstabiliteit

Google noemt afbeeldingen zonder afmetingen, advertenties en embeds, webfonts en dynamisch ingevoegde content als de belangrijkste oorzaken van layoutverschuivingen. Kijk in Magento naar placeholders van productafbeeldingen, het renderen van swatches, updates van de minicart en customer sections, en promobalken die door extensies worden ingevoegd. Geef afbeeldingen een expliciete breedte en hoogte (of aspect-ratio) en houd containers op een vaste hoogte terwijl de content laadt.

Checklist op prioriteit

  1. Haal per template de data uit CrUX en Search Console op. Bepaal welke metric faalt en waar.
  2. Voeg RUM toe met de web-vitals bibliotheek om het LCP-element en de traagste interacties te achterhalen.
  3. Controleer of Varnish (of Fastly) cache-hits serveert op home-, categorie- en productpagina's. Verwijder overbodige cacheable="false" blokken.
  4. Zet indexers op Update on Schedule en stop met routinematige volledige cache flushes.
  5. Warm na elke deploy de belangrijkste URL's op.
  6. Repareer de LCP-afbeelding: geen lazy loading, fetchpriority="high", de juiste afmetingen, WebP waar mogelijk.
  7. Schakel minificatie van JS en CSS in; schakel het samenvoegen van JS uit; test bundling per paginatype of HTTP/2 zonder bundling.
  8. Audit scripts van derden en stel ze uit.
  9. Reserveer ruimte voor elementen die laat laden om de CLS onder 0,1 te krijgen.
  10. Blijft de INP op Luma na de stappen hierboven slecht, laat dan een Hyvä-migratie afbakenen.
  11. Meet opnieuw zodra er 28 dagen aan velddata is.

Veelgestelde vragen

Is FID nog een Core Web Vital?

Nee. INP heeft FID op 12 maart 2024 vervangen als Core Web Vital. Toont een oud rapport of een oude tool nog FID, gebruik dan INP.

Waarom toont PageSpeed Insights een goede score terwijl Search Console zegt dat mijn pagina's niet voldoen?

De performancescore komt uit één Lighthouse-labmeting. Search Console gebruikt CrUX-velddata van echte Chrome-gebruikers over 28 dagen. Voor Core Web Vitals telt de velddata, en die omvat ook trage apparaten en netwerken die een labmeting niet altijd weerspiegelt.

Heb ik Hyvä nodig om de Core Web Vitals op Magento te halen?

Niet per se. Veel Luma-webshops verbeteren flink met werk aan caching, afbeeldingen en scripts. Hyvä wordt het overwegen waard als de INP slecht blijft door de hoeveelheid JavaScript die de Luma-frontend en de extensies laden.

Hoe lang duurt het voordat fixes zichtbaar worden?

CrUX gebruikt een voortschrijdend venster van 28 dagen, dus reken op een geleidelijke verbetering over ongeveer vier weken na de uitrol. RUM-data laat het effect direct zien.

Haalt je Magento-webshop de Core Web Vitals niet?

We auditen caching, frontend en scripts van derden en geven je een geprioriteerd verbeterplan voor je webshop.

Plan een performance-audit

Bronnen

Deze pagina is automatisch vertaald. Zie je een fout? Laat het ons weten, dan passen we het meteen aan.

Gratis webshop-audit

Stuur ons de gegevens van je webshop. We controleren snelheid, beveiliging en extensies en sturen je binnen 3 werkdagen drie quick wins.

Laten we praten

Vraag een offerte aan

Vertel ons over je webshop, dan reageren we binnen één werkdag. Liever chatten? Stuur ons een WhatsApp

MageBooster Boek een UnoPim-demo Bekijk UnoPim live met producten zoals de jouwe. Een nieuwe PIM of een overstap van Akeneo: we sturen je een plan, een planning en een offerte.
✓ Officiële UnoPim-partner✓ AI-agent ingericht voor je team✓ Gekoppeld aan Magento
MageBooster Start je Hyvä-project Vanaf nul of vanuit je huidige webshop. We reageren met een projectplan, een tijdlijn en een offerte.
✓ Design en structuur door ons✓ Voor Hyvä geoptimaliseerde server✓ Bonusmodules inbegrepen
Word partner