Core Web Vitals voor cataloguspagina's in webshops

Cataloguspagina's in webshops, zoals categoriepagina's, zoekresultaatpagina's en productlijsten, hebben een specifiek Core Web Vitals-probleem dat bij eenvoudiger paginatypes niet voorkomt. Ze renderen veel afbeeldingen, veel productkaarten en vaak dynamische filters, en ze moeten tegelijk goed scoren op Largest Contentful Paint, Interaction to Next Paint en Cumulative Layout Shift. Dit artikel beschrijft de specifieke Core Web Vitals-aanpak voor cataloguspagina's.

Waarom cataloguspagina's zo lastig zijn

Een blogartikel heeft één hoofdelement voor de content. Een cataloguspagina heeft 20 tot 50 productkaarten, elk met een afbeelding, een prijs, een call-to-action en soms interactieve elementen zoals quick view of in winkelwagen. Elke kaart kan een layoutverschuiving veroorzaken en draagt bij aan het totale paginagewicht. De pagina kan op assetniveau technisch geoptimaliseerd zijn en toch zakken voor Core Web Vitals, omdat het gezamenlijke effect van veel elementen de drempelwaarden overschrijdt. Een website-audit kan helpen deze problemen te vinden.

Largest Contentful Paint op cataloguspagina's

De LCP is op cataloguspagina's meestal de eerste rij productafbeeldingen (boven de vouw). Drie acties helpen het meest. Ten eerste: laad de eerste rij productafbeeldingen expliciet vooraf (preload), want de browser weet zonder hulp niet welke afbeeldingen boven de vouw staan. Ten tweede: lever productafbeeldingen in moderne formaten (WebP, AVIF) in de getoonde grootte, niet in de originele grootte. Ten derde: zorg dat de hoofdafbeelding van de categorie (als die er is) het LCP-element is en stevig geoptimaliseerd wordt. Meer over beeldoptimalisatie lees je in onze gids Technical SEO Fixes for JavaScript-Heavy and Headless Sites.

Cumulative Layout Shift op cataloguspagina's

CLS is de meest voorkomende Core Web Vitals-fout op cataloguspagina's. De oorzaken zijn meestal: productafbeeldingen die laden zonder afmetingen in de HTML (de pagina verspringt als elke afbeelding binnenkomt), filters die na de eerste render boven het productraster worden ingevoegd, en advertenties of aanbevelingswidgets die laat verschijnen en de content naar beneden duwen. Voor elke oorzaak is een bekende oplossing: geef afmetingen van afbeeldingen op in de HTML, render filters server-side, reserveer ruimte voor widgets die laat laden. Meer over CLS lees je in ons artikel Lighthouse Audit: A Step-by-Step Guide.

Interaction to Next Paint op cataloguspagina's

INP is de nieuwere Core Web Vital die First Input Delay heeft vervangen. Op cataloguspagina's zakt hij meestal als filterinteracties een lange taak veroorzaken. Sorteren op prijs start een JavaScript-uitvoering van 500 ms. Een filter aan- of uitzetten start een herrender van 300 ms. Los voelt dat prima, maar samen overschrijden ze de INP-drempels. De oplossing is lange taken op te breken in kleinere stukken en web workers te gebruiken voor zware berekeningen.

Lazy loading of preloading

Het standaardadvies om alles met lazy loading te laden klopt niet voor content boven de vouw op cataloguspagina's. Als je de eerste rij productafbeeldingen met lazy loading laadt, vertraag je de LCP. Het juiste patroon is de eerste rij direct te laden (of loading="eager" als je het expliciet wilt maken) en alles onder de vouw met lazy loading. De meeste webshopplatforms doen dit standaard verkeerd. Om de prestaties van je website te verbeteren, kun je een website-audittool gebruiken om verbeterpunten te vinden.

Scripts van derden op cataloguspagina's

Op cataloguspagina's stapelen scripts van derden zich snel op: analytics, A/B-tests, personalisatie, chatwidgets, marketingpixels. Elk daarvan draagt bij aan de total blocking time. Controleer de scripts op een cataloguspagina en bepaal welke pas na de hoofdcontent geladen kunnen worden. De meeste marketingpixels kun je uitstellen zonder functionaliteit te verliezen.

Paginering of infinite scroll

Paginering is makkelijker te optimaliseren voor Core Web Vitals dan infinite scroll. Paginering laadt telkens een afgebakende pagina, infinite scroll voegt voortdurend nieuwe content toe, wat vooral voor CLS lastiger te optimaliseren is. Als je cataloguspagina's infinite scroll gebruiken en zakken op CLS, overweeg dan over te stappen op paginering als prestatieoplossing.

CDN-configuratie

Productafbeeldingen komen op de meeste webshopplatforms van een CDN. De instellingen voor beeldtransformatie van het CDN doen ertoe: automatische formaatconversie, automatische groottebeperking en edge-caching beïnvloeden allemaal de prestaties van cataloguspagina's. Controleer de CDN-configuratie specifiek voor het domein van de productafbeeldingen.

Server-side of client-side filteren

Client-side filteren (JavaScript toont en verbergt producten als filters veranderen) is snel voor gebruikers, maar levert geen SEO-waarde op, omdat filtercombinaties niet als aparte pagina's te crawlen zijn. Server-side filteren (elke filtercombinatie heeft een eigen URL) levert meer SEO-kansen op, maar laadt trager. Hybride aanpakken die server-side starten en client-side bijwerken geven je allebei, maar zijn lastiger goed te implementeren.

Het prestatiebudget

Stel een prestatiebudget in specifiek voor cataloguspagina's: LCP onder 2,5 seconden, CLS onder 0,1, INP onder 200 ms. Bouw het budget in de deploymentpipeline in, zodat een mislukte Lighthouse-test de build laat falen. Zo vang je achteruitgang op voordat die live gaat.

Continue monitoring

Een site-auditor die Core Web Vitals per pagina over tijd bijhoudt, ziet achteruitgang precies op de pagina's die ertoe doen. UtilitySEO en vergelijkbare tools doen dit automatisch. Het gaat vooral om de waarschuwing bij achteruitgang, zeker voor webshops waar Core Web Vitals direct de conversie beïnvloeden.

Werken aan Core Web Vitals op cataloguspagina's is een van de prestatie-investeringen met de hoogste ROI voor elke webshop. Het gecombineerde effect op conversie, posities en crawl-efficiëntie maakt de moeite de moeite waard, en de patronen hierboven dekken de meeste oplossingen die echt nodig zijn.