Caching is de belangrijkste enkelvoudige snelheidswinst die beschikbaar is voor een WordPress-site: full-page caching levert kant-en-klare HTML zonder PHP überhaupt uit te voeren, en object caching houdt databaseresultaten in het geheugen. Deze handleiding behandelt beide, wat automatisch de cache omzeilt, en hoe je de cache leegt en opwarmt.
Waar Caching Zich Bevindt in KPanel
- Log in bij KPanel.
- Klik op Websites in de linkerzijbalk en klik vervolgens op de site.
- Open in het linkermenu van de site WordPress, daarna Caching.
Het directe adres is /websites/<site-id>/cache.
De groep WordPress verschijnt alleen voor WordPress- en WooCommerce-sites. Caching is hier een planrecht: full-page caching en de objectcache zijn inbegrepen bij Managed WordPress. Bij andere abonnementen toont de pagina een upgradepaneel dat beschrijft wat beschikbaar is, in plaats van de bedieningselementen.
Full-Page Cache
Full-page caching slaat de kant-en-klare HTML van een pagina op en levert deze rechtstreeks aan de volgende bezoeker. Voor een anonieme bezoeker betekent dit geen enkele PHP-uitvoering en geen databasequery's: het verzoek wordt beantwoord voordat WordPress ooit wordt geladen.
De kaart toont een Aan- of Uit-pil, en wanneer deze aan staat: de datum waarop deze is ingeschakeld, of de routering is bevestigd, en de levensduur van de cache.
Klik op Full-page-cache inschakelen om deze in te schakelen. Klik op Uitschakelen om deze weer uit te zetten.
De cache wordt automatisch geleegd wanneer je een bericht publiceert of bijwerkt, zodat je wijzigingen direct verschijnen in plaats van te wachten tot de levensduur verstrijkt.
Als je site voornamelijk door anonieme bezoekers wordt gelezen, is dit de meest waardevolle schakelaar op de pagina. Het is gebruikelijk dat het verschil een factor van tien bedraagt in de tijd tot de eerste byte, omdat het trage deel van een WordPress-verzoek nu juist het deel is dat niet meer plaatsvindt.
Legen en Opwarmen
Er verschijnen twee acties zodra full-page caching is ingeschakeld.
Cache legen maakt de cache onmiddellijk leeg. Gebruik dit na een wijziging die WordPress niet als een berichtupdate behandelt: het bewerken van een themabestand, het wijzigen van een widget, het bijwerken van een menu, of het aanpassen van een plugin-instelling die de uitvoer beïnvloedt. De volgende bezoeker van elke pagina krijgt een verse kopie.
Cache opwarmen haalt je pagina's vooraf op zodat ze al in de cache staan voordat een bezoeker erom vraagt. Na het opwarmen vertelt een banner hoeveel pagina's van het totaal vooraf in de cache zijn geplaatst en worden de eerste paar URL's vermeld.
De logische volgorde na een ontwerpwijziging is: eerst legen, dan opwarmen. Zo hoeft niemand de ongelukkige bezoeker te zijn die betaalt voor de eerste niet-gecachte weergave.
Voor de edge-cache voor je site, wat een aparte laag is, zie De CDN-cache legen.
Wat Nooit Wordt Gecachet
Sommige URL's moeten altijd PHP uitvoeren, omdat hun uitvoer per bezoeker verschilt of neveneffecten heeft. Deze paden worden automatisch omzeild en je hoeft niets te configureren:
| Pad | Waarom |
|---|---|
/wp-admin/ | WordPress-beheer is altijd dynamisch |
/wp-login.php | De inlogpagina wordt nooit gecachet |
/cart/ | WooCommerce-winkelwagen is per bezoeker |
/checkout/ | WooCommerce-afrekenen is per bezoeker |
/my-account/ | WooCommerce-accountpagina's zijn per bezoeker |
/wp-cron.php | Geplande taken moeten daadwerkelijk uitgevoerd worden |
/?wc-ajax=* | WooCommerce AJAX-eindpunten |
Naast de padregels spelen cookies een rol. Een ingelogde WordPress-gebruiker, of een bezoeker met een actief WooCommerce-sessiecookie, krijgt altijd een dynamische respons, zelfs op een pagina die voor iedereen anders wordt gecachet. Dat is de reden waarom een winkeleigenaar die zijn eigen site bezoekt vaak niets van het voordeel merkt, terwijl anonieme bezoekers dat wel doen.
Omdat je meestal ingelogd bent, zal het testen van cachegedrag in je normale browser je misleiden. Test in een privévenster, of in een browser waarin je niet bent aangemeld.
Objectcache
De objectcache is een andere laag. In plaats van kant-en-klare pagina's op te slaan, houdt deze de resultaten van databasequery's en WordPress-transients in het geheugen, zodat herhaald werk niet wordt herhaald.
De kaart toont een Aan- of Uit-pil, en wanneer deze aan staat: de datum waarop deze is ingeschakeld. Gebruik Inschakelen en Uitschakelen om dit te wijzigen.
Objectcaching helpt precies waar full-page caching dat niet kan: ingelogde gebruikers, beheerschermen, en pagina's per bezoeker zoals winkelwagen en afrekenen. Dat maakt het bijzonder waardevol voor drukke webshops en lidmaatschapssites, waar een groot deel van het verkeer geauthenticeerd is en daarom nooit in de paginacache terechtkomt.
Beide tegelijk laten draaien is de normale configuratie. Full-page caching behandelt anoniem verkeer, en de objectcache versnelt alles wat toch al PHP moet uitvoeren.
Kiezen Wat Je Inschakelt
- Contentsite, voornamelijk anonieme lezers. Full-page caching is de prioriteit. Objectcaching voegt daarbovenop een kleinere verbetering toe.
- WooCommerce-webshop. Schakel beide in. Full-page caching dekt nog steeds je product- en categoriepagina's voor bezoekers die browsen, terwijl de objectcache de winkelwagen, het afrekenen en de accountpagina's draagt die nooit gecachet kunnen worden.
- Lidmaatschaps- of communitysite waarbij bijna iedereen ingelogd is. Objectcaching doet het zware werk, omdat de meeste verzoeken de paginacache opzettelijk zullen omzeilen.
Probleemoplossing
Ik heb de site bijgewerkt, maar bezoekers zien nog steeds de oude versie. Leeg de cache en warm deze daarna op. Als het nog steeds verouderd is, bedenk dan dat er mogelijk ook een edge-cache is: zie De CDN-cache legen.
Caching doet niets voor mij. Je bent vrijwel zeker ingelogd. Controleer dit in een privévenster.
De winkelwagen of een formulier gedraagt zich vreemd voor anonieme bezoekers. De standaard commerce-paden worden automatisch omzeild, maar een aangepaste of door een plugin geleverde dynamische pagina op een niet-standaard URL is dat niet. Als een pagina nooit gecachet mag worden en niet op de omzeilingslijst staat, is het de moeite waard dit bij de klantenservice te melden zodat we naar de regel kunnen kijken.
De kaart geeft aan dat caching inbegrepen is bij Managed WordPress. Je huidige abonnement omvat dit niet. De banner linkt naar de abonnementenpagina.
Routeringcontrole in behandeling. De cache is ingeschakeld en de routeringsbevestiging is nog niet voltooid. Geef het een moment en ververs de pagina.
Een pagina toont de verkeerde gepersonaliseerde inhoud. Alles wat gepersonaliseerd is, moet worden uitgesloten van de paginacache of aan de kant van de client worden weergegeven. Als een plugin de uitvoer personaliseert op een verder cachebare URL zonder een sessiecookie in te stellen, kan de paginacache dat niet weten. Test in een privévenster en meld het bij de klantenservice als je dit tegenkomt.
Gerelateerde Pagina's
- Siteprestaties en APM om te meten of caching daadwerkelijk heeft geholpen.
- Sitebezoekersanalyse voor de hitratio van de edge-cache.
- De CDN inschakelen om een edge-cache vóór dit alles toe te voegen.
- Een back-up maken voordat je grotere wijzigingen aanbrengt op een live site.