Object cache gemmer data, som WordPress allerede har hentet eller beregnet, i hurtig hukommelse. I stedet for gentagne SQL-forespørgsler kan WordPress genbruge eksempelvis options, opslag af indlæg, termdata eller transients. Persistent object cache ligger på tværs af requests og bruger typisk Redis eller Memcached; WordPress’ almindelige in-memory-cache lever kun under det enkelte request.
Hvorfor det kan forbedre TTFB
Når WordPress skal bygge et dynamisk svar, er databaseopslag og pluginlogik ofte en del af serverens svartid. Færre og hurtigere opslag kan sænke TTFB og øge kapaciteten under trafik. Det er særligt relevant for indloggede brugere, søgning, medlemsområder og WooCommerce, hvor en komplet HTML-cache ikke kan bruges konsekvent.
Object cache er ikke magi. Den gør ikke langsom PHP, store eksterne API-kald eller dårlige databaseforespørgsler usynlige. Den kan heller ikke erstatte full page cache for en offentlig artikel. Page cache undgår hele WordPress-processen; object cache gør processen billigere, når den er nødvendig.
WordPress-opsætning
De fleste hosts tilbyder Redis eller Memcached som en separat tjeneste. WordPress forbindes typisk gennem et kompatibelt plugin og et object-cache.php-drop-in i wp-content. Kontrollér i hostens panel eller pluginets status, at persistent cache faktisk er aktiv; installation af et plugin alene beviser ikke, at WordPress læser og skriver til cachetjenesten.
- Vælg én understøttet cache-motor og et WordPress-plugin, som passer til hostens opsætning.
- Brug et unikt prefix eller databaseindeks, hvis Redis deles mellem sites, så nøgler ikke kolliderer.
- Hold autoloadede data i wp_options under kontrol; cache reducerer belastningen, men løser ikke unødvendigt oppustede options.
- Kontrollér, at cache ryddes korrekt, når produktdata, indstillinger og indhold ændres.
Sådan måler og fejlsøger du
Mål først dynamiske, repræsentative URL’er, ikke kun en cachet forside: en konto, en WooCommerce-produktside eller en filtreret kategori. Sammenlign serverens responstid og antal databaseforespørgsler før og efter. På staging kan Query Monitor hjælpe med at finde langsomme forespørgsler, men måling på produktion bør ske forsigtigt og med minimal overhead.
Hold øje med cache-hit-rate, hukommelsesforbrug og fejl i applikationsloggen. En lav hit-rate kan betyde, at data udløber for hurtigt eller at nøgler varierer unødigt. Opstår der forkerte priser, lagerdata eller brugerspecifikke oplysninger, skal konfigurationen gennemgås med det samme. Målet er hurtigere dynamiske svar uden at gå på kompromis med korrekt data.