Het catalogusfilter van Woodmart en van Flatsome werkt met een request per filteractie. Op een kleine shop voelt dat als een soepele update. Op een catalogus van duizenden tot tienduizenden producten wordt die request traag, omdat PHP en MySQL het archief per klik opnieuw uitrekenen. InstantFilter doet na de eerste pageload geen filter-request meer.
Waarom is de Woodmart AJAX-filter traag op een grote shop?
Woodmart beschrijft het shopfilter als AJAX: je filtert op categorie, prijs, kleur, maat, merk, voorraad of een attribuut, en de resultaten updaten op hun plek, zonder dat de hele pagina opnieuw laadt. Dat staat op hun pagina over de shopping experience. De documentatie van het productfilter-formulier zegt hetzelfde nog een keer: op shop- en archiefpagina’s werken de filters met WoodMart AJAX filtering wanneer AJAX shop aan staat, onder Theme Settings → Product archive.
Een update zonder volledige reload is nog steeds een request. De browser vraagt de nieuwe set producten aan de server. WordPress start, WooCommerce bouwt de query, het theme stuurt HTML of JSON terug, en het grid wordt vervangen. Op een categorie met een paar honderd producten is die ronde kort. Zoek je op woodmart ajax filter slow, dan zit je op het moment dat de categorie duizenden SKU’s heeft en dezelfde ronde 800 ms tot 2.500 ms duurt, of een timeout geeft als de workers vol zitten.
Deze pagina schrijft Woodmart niet toe dat het bestand admin-ajax.php heet. De officiële tekst zegt AJAX shop en AJAX filtering. De kosten zitten in de request, niet in de bestandsnaam. In het Network-tabblad zie je een XHR op het moment dat je een filter aanzet. De tijd van die regel is de tijd die de shopper wacht.
Waarom is de Flatsome productfilter traag op een grote catalogus?
Flatsome documenteert Pjax, PushState Ajax, als ajax-gedreven navigatie. De UX Themes-docs, bijgewerkt op 10 juni 2024, zeggen dat dit navigatie en filteren soepeler maakt, en dat je het aanzet onder Advanced → Content Delivery door een AJAX-optie te activeren. Pjax haalt een nieuw fragment op en zet dat in de pagina, zonder een klassieke full reload.
flatsome product filter slow is die fragment-request op een zwaar archief. Het theme vraagt de server om de gefilterde producten. De server doet de WooCommerce-query. Bij 10.000, 20.000 of 50.000 producten duurt die query, en de worker blijft bezet tot ze klaar is. Pjax verandert hoe het resultaat in de pagina landt. Het verandert niet dat er een request is.
De docs noemen het experimenteel en wijzen erop dat scripts na een Pjax-refresh opnieuw moeten starten. Dat is een frontend-detail. Het verklaart haperende widgets na een filter. Het verklaart niet een trage query. Een trage query zie je in het slow query log en in de duur van de request, los van of het theme daarna een slider opnieuw initialiseert.
Wat is een theme AJAX catalog filter, los van de themanaam?
Een theme-filter tekent het WooCommerce-grid van het theme en ververst dat grid via een request. Woodmart en Flatsome zijn de twee namen die agencies het vaakst intypen, omdat die themes de filter meeleveren. Het patroon is hetzelfde bij andere themes die “AJAX shop” als schakelaar hebben: de zijbalk hoort bij de productloop van het theme, en elke klik vraagt die loop opnieuw aan.
Dat is een ander grid dan het grid van InstantFilter. InstantFilter filtert de theme-loop niet. Het archief is een eigen grid, en de klik na de load blijft in de browser. Een theme-filter en InstantFilter stapel je niet op dezelfde archieflijst. Je kiest welk grid de categorie tekent. Zolang het theme-grid de pagina is, blijft de request van het theme de filter.
Waarom wordt die request duurder naarmate de catalogus groeit?
De eerste HTML van de categorie kan gecachet zijn. De filterklik is een nieuwe combinatie en mist die cache. Elke combinatie van kleur, maat en prijs is een eigen query. Op een grote catalogus duurt de query langer, en meer shoppers doen die query tegelijk. Het plafond is het aantal PHP-workers. De uitleg van die mail staat in de post over filters die PHP-workers vullen.
De request zelf, of die nu van een theme of van een plugin komt, bootst WordPress. Dat bestand heet vaak admin-ajax.php, soms een eigen route van het theme. De bestandsnaam is het symptoom dat je in DevTools leest. De architectuur is: één klik, één boot, één query. Een lookup table van WooCommerce kan de attribuut-join inkorten. De boot blijft. Dat staat in de post over de product attributes lookup table.
PageSpeed blijft groen zolang het de gecachte categorie meet. De shopper meet de klik. Een agency die Woodmart of Flatsome op een shop van tienduizenden producten zet, ziet dat verschil pas als het assortiment groeit, niet bij de demo met een paar dozijn producten.
Hoe vervang je het theme-filter zonder het theme weg te gooien?
Het theme mag de header, de footer en de productpagina blijven tekenen. Het archief waar gefilterd wordt, moet het grid zijn dat na de load geen request meer doet. InstantFilter rendert dat archief server-side voor de eerste HTML, hydrateert, en filtert daarna lokaal in 1,5 ms tot 5 ms, met 0 SQL per klik. De hub voor die architectuur is de gids over waarom WooCommerce-filters traag worden.
Zet op staging de AJAX shop of de Pjax-filter uit voor het archief dat je vervangt, zodat twee filters niet dezelfde lijst proberen te verversen. Tel daarna in het Network-tabblad de requests per klik. Het theme-filter hoort een request te tonen zolang het aan staat. Het InstantFilter-archief hoort na de eerste load stil te zijn. De catalogusgrootte gebruik je als test, niet als titel.
Woodmart en Flatsome blijven bruikbaar voor alles wat geen filterarchief is. De trage klik zit in de catalogusfilter die het theme met een request ververst. Haal die klik van de server, en de worker-grafiek tijdens het filteren zakt weg, onafhankelijk van welk van de twee themes de rest van de shop tekent.
Hoe vergelijk je Woodmart of Flatsome met een stille klik?
Maak een staging-kloon met hetzelfde assortiment als productie. Laat het theme-filter aan. Open het Network-tabblad, wis de lijst, en zet één filter. Noteer de URL, de methode en de duur. Dat is de basislijn van Woodmart of van Flatsome op deze catalogus. Herhaal het met twee facetten achter elkaar, zodat je ziet of de tweede klik net zo duur is als de eerste. Een warme query kan iets sneller zijn. Ze blijft een request.
Zet daarna het archief op InstantFilter en doe dezelfde twee klikken. Na de eerste HTML hoort de lijst geen nieuwe filter-request te tonen. De duur die je noteert zit dan in de browser, in 1,5 ms tot 5 ms, niet in een worker. Bewaar de twee opnames. Ze zijn het antwoord aan de klant die vraagt waarom de demo van het theme snel was en de shop met het echte assortiment niet.
Laat de rest van het theme met rust tijdens die test. Als header, menu of productpagina ook requests doen, filter je die uit de vergelijking. Alleen de regel die verschijnt op het moment van de facet-klik telt. Zo blijft de conclusie over het catalogusfilter, en niet over een font, een pixel of een zoekbalk in de header.
Ga verder
Het theme levert de request. Deze pagina’s leggen uit wat die request kost.
- Waarom WooCommerce-filters traag worden
- Een request per filterklik
- PHP-workers vol tijdens het filteren
- De lookup table haalt de request niet weg
- Prijzen en proefperiode
