WooCommerce webshop sneller maken begint bij uncached TTFB

Stappen om je WordPress website te versnellen: de Twize‑methode

We leveren snelheid door consequent te meten en te ontleden. Geen zware rapporten zonder actie, maar een cyclus van meten – oplossen – opnieuw meten.

• 0‑meting zonder ruis. We draaien een curl‑suite op home, PDP, PLP en cart plus POST‑endpoints (admin‑ajax en wc‑ajax fragments). Drie runs, zonder page‑cache, met een unieke no‑cache parameter.
• Eén request splitsen. We knippen het hele verzoek op: bootstrap, enqueue/wp_head‑callbacks, template/loop en footer. We leggen queries, de top‑10 zwaardste callbacks en de autoload‑grootte vast en noteren of Redis draait. Zo zie je welke fase je TTFB trekt.
• Impact per plugin. Op home, PDP, PLP en cart meten we welke plugin en welke plugins hoeveel milliseconden kosten. Geen schattingen, alleen echte meetwaardes per context. Zo behoud je functionaliteit, maar verdwijnt verspilde tijd.
• Rapportage per onderdeel. Na elke ingreep presenteren we dezelfde 3‑run tabel (min/avg/max TTFB). We stoppen bij ONS doel, niet bij een groen vinkje.

Deze aanpak dwingt focus. WordPress is flexibel, maar je wilt niet alles tegelijk aanpassen. Door per request‑fase en per plugin te werken, blijft elke stap controleerbaar en herhaalbaar.

Wat heeft er effect op de snelheid van WP en WOO?

We lossen knelpunten op in de volgorde die de meting aangeeft. Typisch doorlopen we deze stappen:

• Object‑cache (Redis). Directe winst als deze nog ontbreekt. Maar is een dure add-on. Zonder redis is onze test. Met Redis is meegenomen.
• Autoload verkleinen. Grote options zetten we op autoload=off. Transients komen niet op autoload te staan. Doel: autoload rond ~400KB zodat WordPress sneller kan bootstrappen vanuit de database.
• Selectief plugins laden. Init uitstellen of guards op ajax‑paden inzetten als de meting dat aantoont. We wissen nooit zomaar de actieve plugins; functionaliteit blijft intact, de timing verandert en sommige plugins worden niet geladen als ze alleen functie hebben op een bepaalde deel van de site, of in de admin.
• Collection‑ of view‑cache op PLP’s. Zware filter‑HTML of productgrids bouwen we niet elke request opnieuw. Ingelogd, POST en gefilterde queries slaan we over, zodat de interactie correct blijft.
• Navigatie optimaliseren. Een mega‑menu hoeft z’n HTML niet bij elke cache‑HIT opnieuw te laten parsen. We zorgen dat WordPress daar slim mee omgaat binnen de bestaande caching‑regels.
• Storefront‑ajax via wc‑ajax. Fragments, recently viewed en add‑to‑cart lopen via wc‑ajax in plaats van admin‑ajax. Dat houdt de TTFB snel en triggert minder onnodig database‑werk en bootstrap tijd.

Het resultaat is geen cosmetische winst in de front‑end, maar structurele TTFB‑verbetering. Juist wat je merkt op cart en checkout, waar cache vaak wordt voorbijgelopen en WordPress het echte werk doet.

WooCommerce sneller zonder de jacht naar groene vinkjes

We optimaliseren totdat de uncached frontend‑TTFB richting ~1,0s gaat; ≤ ~1,2s op homepage, PDP en cart is acceptabel. Daarna stoppen we. Een perfecte PageSpeed‑score klinkt leuk, maar zegt weinig als add‑to‑cart traag reageert. Daarom rapporteren we steeds dezelfde 3‑run tabel en houden we grip op oorzaak en gevolg.

De vinkjes komen daarna, die pakken we op in onze frontend optimalisatie. Maar waar Google Pagespeed teveel focus legt op een afbeelding te comprimeren van 120kb naar 100kb leggen wij veel meer nadruk op TTFB, INP en LCP. Daar heeft de gebruiker iets aan!

TTFB: de pagina is sneller klaar om op het scherm getekend te worden
LCP: Snel de eerste draw (fold) zien is essentieel!
INP: Snel de site kunnen gebruiken. Niets irritanter dan knopjes die nog niet werken omdat er een achtergrond proces nog bezig is!