Full page cache, også kaldet HTML page cache, gemmer den færdige HTML-version af en side. Når den næste anonyme besøgende anmoder om samme URL, kan cachelaget svare uden at starte WordPress, indlæse plugins, køre PHP og hente data fra databasen. Det gør svaret både hurtigere og billigere for serveren.

Hvorfor det betyder noget for hastighed

På et typisk WordPress-site skal WordPress bygge hver side dynamisk, hvis der ikke er cache. Selv få hundrede millisekunders PHP- og databasearbejde lægger sig oven på netværkstiden. Full page cache reducerer især TTFB, hvilket giver browseren mulighed for tidligere at begynde at hente og vise indhold. En bedre TTFB kan dermed understøtte LCP, men den kompenserer ikke for et for stort LCP-billede eller render-blokerende CSS.

Cache hjælper også under trafikspidser. Når mange besøgende læser samme artikel eller produktside, kan de få den samme cachede HTML i stedet for at belaste WordPress én gang pr. request.

Hvad det er – og ikke er

  • Det er ikke browsercaching, som genbruger CSS, JavaScript og billeder i brugerens browser.
  • Det er ikke object cache, som gør WordPress’ databaseopslag hurtigere, når PHP faktisk skal køre.
  • Det er ikke sikkert at cache personaliserede svar, login, søgning, kurv, checkout eller konto uden præcise regler.

WordPress-opsætning

Cachen kan ligge i et plugin, på hostens server eller ved et CDN. Et host- eller edge-lag er ofte mest effektivt, fordi requestet kan afvises før PHP. Vælg ét tydeligt ansvarligt cachelag frem for flere plugins med overlappende funktioner. Flere lag kan godt fungere, men kun når purge-regler og headers er koordineret.

Konfigurér automatisk rydning, når indhold, menuer eller relaterede arkiver opdateres. Sæt cookie- og URL-undtagelser for dynamiske flows. I WooCommerce skal du kontrollere, at cart fragments, kurv og checkout ikke får cachet en anden brugers tilstand.

Sådan måler og fejlsøger du

Test først en side som udlogget besøgende i et privat vindue. Se responsheaders efter for eksempel HIT, MISS eller hostens cacheheader, og mål flere gentagne indlæsninger. En HIT bør have væsentligt lavere TTFB end en MISS. Test derefter efter en redigering, så du ved, at cachen bliver ryddet korrekt.

Hvis en side fortsat er langsom ved cache-hit, skal du undersøge netværksafstand, HTML-størrelse og frontend-ressourcer. Hvis den kun er langsom ved miss, er næste skridt at profilere WordPress, plugins, database og object cache.