WooCommerce-filtering die wél samenwerkt met caching

Traditionele AJAX-filters omzeilen je paginacache (zoals WP Rocket of Redis) door unieke query-strings aan de URL toe te voegen, waardoor je server gedwongen wordt om elke filterklik vanaf nul te verwerken. Om je WooCommerce-categoriepagina’s volledig gecachet te houden terwijl je toch razendsnel kunt filteren, moet je overstappen op een frontend-first architectuur die producten direct in de browser filtert.

Waarom omzeilen WooCommerce-filters de WP Rocket-cache?

Je hebt uren besteed aan het optimaliseren van je WooCommerce-shop. Je hebt WP Rocket geïnstalleerd, Redis object caching geconfigureerd, je afbeeldingen geoptimaliseerd en je Time To First Byte (TTFB) is razendsnel. De shop voelt ontzettend soepel aan wanneer je van de ene naar de andere categorie bladert. Je bent ervan overtuigd dat je performance op orde is.

Maar op het moment dat een klant op een filter in de zijbalk klikt, hangt de pagina plotseling 3 seconden. Het laad-icoontje draait, de CPU van de server piekt en de geoptimaliseerde ervaring waar je zo hard aan hebt gewerkt, valt volledig uit elkaar. Dit is een frustrerend probleem dat veel webshopeigenaren herkennen: de site is snel, totdat de klant hem echt gaat gebruiken.

Als je zoekt naar woocommerce filter bypass cache of wp rocket woocommerce filter niet gecachet, ben je waarschijnlijk tegen deze muur aangelopen. Paginacaches (WP Rocket, LiteSpeed Cache, Varnish) slaan statische HTML op voor “schone” URL’s zoals /shop/schoenen/. Caching-systemen volgen een strikte regel: cache nooit dynamische, gebruiker-specifieke verzoeken. Dit is om te voorkomen dat een klant de gefilterde resultaten van een andere klant te zien krijgt.

Wanneer een gebruiker een filter selecteert, voegen traditionele AJAX-plugins een query-string toe, waardoor de URL verandert van /shop/schoenen/ naar /shop/schoenen/?filter_kleur=blauw&filter_maat=large. Zodra de caching-laag dat vraagteken (?) ziet, wordt de statische HTML-cache omzeild en wordt het verzoek direct naar de server gestuurd. Onze performance-gids behandelt de volledige AJAX-waterval en de impact hiervan op de laadtijd.

Wat gebeurt er met PHP-workers wanneer filters AJAX gebruiken?

Omdat de cache wordt omzeild, komt het verzoek rechtstreeks bij je PHP-workers terecht. WordPress moet opstarten, WooCommerce moet laden, de filter-plugin voert SQL-queries uit, rendert de nieuwe HTML en stuurt een AJAX-respons terug — vaak pas 1 tot 5 seconden later bij grote catalogi. Dit proces herhaalt zich bij elke klik, wat een enorme belasting vormt voor de server.

Tijdens een uitverkoop of actieperiode concurreert de belasting van het browsen met de belasting van het afrekenen. Tien shoppers die tegelijkertijd filteren, kunnen tien gelijktijdige zware PHP-processen betekenen, terwijl verzoeken voor het winkelmandje en de betaling in de wachtrij komen te staan voor dezelfde pool van PHP-workers. Dit is hoe categoriepagina’s de checkout kunnen vertragen, zelfs als het aantal bestellingen op dat moment normaal is. Je verliest omzet omdat je server te druk is met het tellen van blauwe schoenen.

Lees waarom wp_postmeta queries filters traag maken voor de technische achtergrond van dit probleem aan de database-kant.

Waarom lost Redis trage WooCommerce-filterklikken niet op?

Redis en Memcached zijn object-caches — ze slaan de resultaten van database-queries op in het RAM-geheugen. Dat helpt bij het herhaaldelijk lezen van dezelfde opties, transiënten of post-meta. Het is een fantastische tool voor algemene site-snelheid, maar het is geen vervanging voor paginacaching en het elimineert de AJAX-roundtrips niet.

Bij elke filterklik betaal je nog steeds voor: netwerkvertraging (latency), het opstarten van WordPress, de uitvoering van de plugin en het renderen van de HTML. Redis kan misschien wat milliseconden afschaven van individuele database-opdrachten, maar de architecturale kosten blijven bestaan. Hosting-support raadt vaak Redis aan wanneer filters traag zijn — dit bestrijdt de symptomen, maar niet de oorzaak van de trage filter-architectuur zelf.

Vergelijk AJAX vs frontend-first filtering om te zien waar het werk daadwerkelijk zou moeten plaatsvinden voor de beste performance.

Hebben LiteSpeed Cache en Varnish hetzelfde probleem met filters?

Ja. Elke volledige paginacache die de URL als sleutel gebruikt, zal de cache omzeilen of missen wanneer filter-plugins query-parameters toevoegen of een POST-verzoek sturen naar admin-ajax.php. LiteSpeed Cache, NGINX fastcgi_cache en Cloudflare APO gedragen zich allemaal op dezelfde manier: schone categorie-URL’s worden goed gecachet, maar dynamische filter-interacties niet.

Sommige teams proberen filter-query-strings uit te sluiten van de regels voor het omzeilen van de cache — waardoor het caching-systeem gedwongen wordt om elke unieke filtercombinatie als een aparte HTML-pagina op te slaan. Dit zorgt voor een explosie van de cache-grootte (duizenden variaties per categorie) en vereist nog steeds een verzoek naar de server bij een “cache miss”. Voor shops met veel attributen is dit simpelweg niet schaalbaar en leidt het tot een vervuilde en inefficiënte cache.

Hoe controleer je of WooCommerce-filters je paginacache omzeilen?

Het is belangrijk om te meten wat er echt gebeurt onder de motorkap van je shop. Je kunt dit eenvoudig zelf testen met de volgende stappen:

1. Laad een categoriepagina terwijl je niet bent ingelogd. Controleer de respons-headers op cache HIT-markers of WP Rocket debug-headers.
2. Klik op een filter. Houd het tabblad Netwerk in de gaten — als je admin-ajax.php ziet of een nieuw documentverzoek met query-strings, dan is de paginacache omzeild.
3. Vergelijk de TTFB bij de eerste keer laden met de TTFB na een filterklik. Een sprong van 50ms naar 2s bevestigt dat PHP het verzoek dynamisch moet afhandelen.
4. Schakel in WP Rocket tijdelijk cache-logging in en bevestig dat filter-URL’s nooit als gecachete items verschijnen.

WooCommerce plaatst ook cookies voor winkelmand-sessies. Paginacaches omzeilen terecht ingelogde gebruikers of gebruikers met een actief winkelmandje — maar filter-AJAX zou geen winkelmand-cookies nodig moeten hebben. Als je filter-plugin cookie-writes triggert bij het browsen, verlies je mogelijk de cache voor alle categoriebezoekers, niet alleen voor degenen die filters gebruiken.

Hoe kun je WooCommerce-categoriepagina’s cachen en toch direct filteren?

Om dit conflict met caching definitief op te lossen, moet je het filteren loskoppelen van serververzoeken. Frontend-first plugins zoals InstantFilter downloaden een gecomprimeerd JSON-codebook bij de eerste keer dat de pagina wordt geladen. De categorie-URL blijft schoon — bijv. /shop/schoenen/ — waardoor WP Rocket de gecachete HTML kan blijven serveren.

• 100% paginacache hit-rate voor de initiële HTML bij herhaalbezoeken.
• Geen omzeiling van de cache door query-strings bij filter-interacties — ze raken PHP nooit aan.
• SSR blijft behouden voor SEO; zoekmachines zien de volledige productenlijst bij de eerste scan.
• Statische JSON kan apart van de HTML op een CDN worden gecachet, net als afbeeldingen of scripts.

Wanneer de gebruiker op een filter klikt, kan de URL worden bijgewerkt voor het delen van de link (via de History API), maar er wordt geen verzoek naar de server gestuurd. De browser werkt het grid in milliseconden bij op basis van de JSON-index. Dit is de enige manier om echte snelheid te garanderen zonder je server te belasten.

Bewijs nodig op schaal? Bekijk hoe we 50.000+ producten filteren zonder serverbelasting. Vergelijk architecturen op InstantFilter vs FacetWP of start een proefperiode via de prijzen van InstantFilter.

Test eerst op een staging-omgeving met WP Rocket ingeschakeld voordat je live gaat — onze documentatie over probleemoplossing behandelt veelvoorkomende combinaties van cache-plugins en CDN-instellingen.

Moet je WooCommerce-shoppagina’s uitsluiten van de WP Rocket-cache?

Het uitsluiten van /shop/ of productcategorie-URL’s van de paginacache is een veelgebruikte “oplossing” wanneer filters gecachete pagina’s breken. Het garandeert dat de HTML altijd vers is, maar het verwijdert de performance-winst waarvoor je WP Rocket in de eerste plaats hebt geïnstalleerd. Elk bezoek aan een categorie wordt een volledige PHP-render — precies het tegenovergestelde van wat je wilt tijdens piektijden in het verkeer.

Een betere verdeling: houd de categorie-HTML gecachet met schone URL’s en verplaats de filter-interacties naar de client-kant. De JSON-exports van InstantFilter zijn statische bestanden — ze kunnen op hetzelfde CDN staan als je CSS en JavaScript, zonder de HTML-cache te verstoren wanneer producten worden bijgewerkt. Dit zorgt voor een robuuste en snelle architectuur.

Hoe gaat InstantFilter om met WooCommerce winkelmand-cookies?

WooCommerce plaatst cookies zodra er items in het winkelmandje worden geplaatst. De meeste paginacaches omzeilen gebruikers met deze cookies om te voorkomen dat er verouderde prijzen of een foutieve winkelmand-UI wordt getoond. Het filteren met InstantFilter vereist geen nieuwe cookies bij elke klik op een checkbox — dus anonieme bezoekers die door categorieën bladeren, kunnen nog steeds de gecachete HTML ontvangen. Dit is essentieel voor het behoud van een hoge snelheid voor het grootste deel van je verkeer.

Nadat een product aan het winkelmandje is toegevoegd, kan WooCommerce fragmenten verversen via AJAX — dat staat los van het filteren in de catalogus en is normaal gedrag. Het doel is om te voorkomen dat filter-plugins dynamische PHP forceren bij elke interactie in de zijbalk, niet om legitieme winkelmand-updates te blokkeren.

Wat moet je testen op staging voordat je live gaat?

Voordat je de nieuwe architectuur naar je live shop pusht, is het verstandig om een aantal zaken te controleren:

• Controleer of de paginacache een HIT geeft voor uitgelogde gebruikers, vóórdat er op een filter wordt geklikt.
• Controleer in het tabblad Netwerk dat er geen admin-ajax.php verzoeken worden gedaan bij filterklikken nadat de JSON is geladen.
• Bevestig dat het JSON-codebook één keer wordt geladen en een 200-status (uit cache of CDN) teruggeeft bij herhaalbezoeken.
• Controleer of het delen van gefilterde URL’s nog steeds werkt als je gebruikmaakt van History API permalinks.
• Test of de checkout en winkelmand-AJAX nog steeds correct functioneren met de WooCommerce-compatibiliteitsinstellingen van WP Rocket.

Documenteer de TTFB en de vertraging bij filterklikken voor en na de wijziging — stakeholders zullen om cijfers vragen. Onze vergelijkingsgids voor filter-plugins helpt je om de architecturale beslissing verder te onderbouwen dan alleen de cache-instellingen.

Grote catalogi versterken elke “cache miss”. Als AJAX-filters je PHP-workers nu al belasten, zal het toevoegen van Redis zonder de architectuur te veranderen het probleem alleen maar uitstellen. Frontend-first filtering verwijdert het terugkerende serverwerk volledig — dezelfde aanpak die we gebruiken voor catalogi met meer dan 50.000 producten.

Waarom schaden filter-plugins de Core Web Vitals op categoriepagina’s?

Core Web Vitals richten zich op de eerste keer laden — LCP, INP, CLS — maar de gebruikerservaring van filters beïnvloedt de “Interaction to Next Paint” (INP) wanneer shoppers de zijbalk gebruiken. AJAX-filters moeten wachten op netwerkantwoorden voordat ze het grid kunnen bijwerken; laad-icoontjes en verschuivingen in de layout schaden de waargenomen kwaliteit, zelfs als de LCP van de eerste weergave prima was.

Frontend-first filtering handelt klikken af in JavaScript nadat het JSON-codebook is geladen — doorgaans in minder dan 5ms per interactie in onze tests met grote catalogi. Gecachete HTML zorgt nog steeds voor een snelle LCP, maar het filteren stopt met het afstraffen van de INP tijdens lange browsesessies. Dit is vooral merkbaar op mobiele apparaten waar de processor minder krachtig is.

Mobiel verkeer vergroot de nadelen van AJAX omdat de netwerkvertraging op mobiele netwerken vaak hoger is dan op wifi. Zie onze gids over mobiele filtervertraging voor de impact op conversie en stappen om dit te testen met vertraagde netwerken.

Kun je gefilterde URL’s met query-strings cachen in WP Rocket?

WP Rocket en vergelijkbare plugins bieden de mogelijkheid om URL’s met query-strings te cachen, maar dit werkt alleen goed wanneer de lijst met parameters beperkt en voorspelbaar is. Productfilters genereren echter een enorme hoeveelheid combinaties — Kleur x Maat x Merk x Prijs — die de cache-opslag laten exploderen en nog steeds leiden tot een “miss” bij het eerste bezoek aan elke unieke combinatie.

Het vooraf genereren van gecachete HTML voor elke mogelijke filterstatus is onpraktisch bij catalogi met tientallen attributen. Client-side filtering met één enkele gecachete HTML-shell plus één JSON-index voorkomt deze explosie van combinaties volledig — en houdt je hostingfactuur voorspelbaar, zelfs tijdens piekmomenten in de verkoop. Het is de enige schaalbare oplossing voor moderne e-commerce.

Blijf ontdekken

Caching en filtering werken alleen samen met de juiste architectuur:

• Waar WooCommerce-filters je site vertragen
• Trage filters oplossen: wp_postmeta
• 50.000 producten direct filteren
• Documentatie over probleemoplossing
• InstantFilter prijzen

Veelgestelde vragen over WooCommerce-filter caching