Caching – Hvad er caching?

Caching er at gemme et færdigt resultat, så det ikke skal laves igen næste gang nogen beder om det. På en WordPress-side betyder det, at serveren gemmer den færdige HTML i stedet for at bygge siden op forfra ved hver eneste besøgende — starte PHP, spørge databasen, køre hvert aktivt plugin igennem og sætte det hele sammen. Caching er den enkeltændring der flytter mest på en langsom hjemmeside, og det er næsten altid det første jeg sætter op.

De fire typer caching

De fire arbejder på hvert sit sted i kæden, og de udelukker ikke hinanden. En velopsat side bruger som regel alle fire.

HTML-cache (sidecache) gemmer den færdige side som en fil på serveren. Næste besøgende får filen serveret direkte, uden at PHP eller databasen bliver rørt. Det er den type der giver den største og mest umiddelbare gevinst, og det er den de fleste mener, når de siger “cache-plugin”.

Objektcache gemmer resultatet af databaseforespørgsler i hukommelsen, typisk med Redis eller Memcached. Den hjælper dér hvor HTML-cache ikke kan hjælpe: i backend, på indloggede brugere, og på sider der ikke må caches. På en stor webshop er den forskellen på en administration der er til at arbejde i og en der ikke er.

Browsercache ligger hos den besøgende. Serveren sender en Cache-Control-header med, som fortæller browseren hvor længe den må beholde billeder, CSS og JavaScript. Ved næste besøg hentes de filer slet ikke — de ligger allerede på maskinen. Den gør ikke det første besøg hurtigere, men den gør alle de næste hurtigere.

Edge-cache i et CDN gemmer indholdet på servere rundt om i verden og leverer det fra den nærmeste. Den skærer den geografiske afstand væk. Er alle dine besøgende danske, og står din server i Danmark, er der ikke meget afstand at spare — så tag de tre andre først.

Optimering af TTFB med caching

TTFB — Time to First Byte — er tiden fra browseren beder om siden, til det første byte af svaret kommer tilbage. Det er ren ventetid, hvor der ikke er tegnet en eneste pixel, og den ligger foran alt andet. Grænsen for en god TTFB er 0,8 sekund.

Her er hvad HTML-cache reelt gør ved det tal. På de sider jeg måler, falder TTFB til under 80–150 millisekunder, når sidecachen rammer. Det gælder også på sider hvor den samme URL uden cache tager flere sekunder. Forskellen er ikke en forbedring på tyve procent — det er en helt anden størrelsesorden, fordi arbejdet ikke bliver udført.

Optimér alligevel siden bagved

Og her kommer jeg med en holdning, som ikke alle deler: du skal have TTFB uden cache ned omkring de 800 millisekunder — helst lavere — selv når cachen dækker over problemet.

Grunden er, at cachen ikke altid er der.

• Den første besøgende efter en tømning betaler den fulde pris. Det gør de hver gang du opdaterer et indlæg, retter et produkt eller rydder cachen.
• Sider der ikke må caches har aldrig en cache at falde tilbage på. På en webshop er det kurv, kasse og Min konto — altså præcis de sider hvor en kunde er tættest på at betale.
• Indloggede brugere får som regel serveret siden udenom cachen.
• Google crawler også de sider ingen har besøgt. En URL langt nede i arkivet ligger sjældent i cachen, når crawleren rammer den.
• Din egen administration kører altid uden sidecache. En langsom side bagved er langsom hver eneste gang du selv arbejder i den.

En side der er hurtig uden cache og hurtig med cache er robust. En side der kun er hurtig med cache er et korthus — det ser fint ud i en test, og det falder sammen præcis når det gør ondt.

Forskellen på HTML cache og browser cache

De to bliver blandet sammen, fordi de begge hedder cache, og fordi begge gør siden hurtigere. Men de arbejder forskellige steder.

HTML-cache ligger på serveren og gemmer selve siden. Den hjælper det første besøg, den hjælper alle besøgende, og den er dét der trækker TTFB ned.

Browsercache ligger hos brugeren og gemmer de filer siden består af. Den gør ikke det første besøg hurtigere — filerne skal hentes én gang — men den fjerner hentningen ved alle efterfølgende besøg og ved klik videre til næste side.

Du skal have begge. HTML-cache uden browsercache betyder, at hver eneste sidevisning henter den samme CSS-fil forfra. Browsercache uden HTML-cache betyder, at serveren bygger siden op igen ved hvert besøg, uanset at billederne allerede ligger hos brugeren.

Implementering af effektiv cache strategi

Rækkefølgen betyder noget, og den er den samme hver gang:

1. Slå HTML-cache til. Det er her gevinsten er. Mål TTFB før og efter, så du ved hvad du fik.
2. Sæt undtagelserne op. Kurv, kasse og Min konto må aldrig caches. Det samme gælder indloggede brugere og alt der er personligt.
3. Sæt Cache-Control på de statiske filer. Billeder, skrifttyper, CSS og JavaScript kan sagtens ligge længe hos brugeren, når filnavnene er versionerede.
4. Læg objektcache på, hvis siden er stor eller har mange indloggede — Redis eller Memcached.
5. Sæt et CDN foran, hvis du har besøgende uden for landet eller meget tunge filer.
6. Ryd cachen når du udgiver noget. De fleste plugins gør det selv, men kun for den side du rettede — ikke nødvendigvis for forsiden og arkiverne der viser den.

Caching løser ikke alt. En side med 900 kB JavaScript er stadig tung at tegne, selv når serveren svarer på 80 millisekunder. Se render-blocking ressourcer, minificering og lazy loading for den anden halvdel af arbejdet.

Bedste WordPress plugins til HTML cache

WP Rocket er det jeg oftest ender med. Det koster penge og findes ikke som gratis udgave, men det virker ud af boksen, det kender WooCommerce, og opsætningen tager minutter frem for eftermiddage.

LiteSpeed Cache er gratis og har over 7 millioner installationer. Vær opmærksom på ét forhold, som ofte bliver overset: den fulde sidecache kræver en LiteSpeed- eller OpenLiteSpeed-server. Kører din side på Apache eller Nginx, får du stadig billedoptimering, minificering, kritisk CSS og objektcache — men ikke den del der trækker TTFB ned. Spørg din host hvilken server du kører på, før du vælger det.

W3 Total Cache har omkring 900.000 installationer og bliver aktivt vedligeholdt af BoldGrid. Det kan mere end de fleste og har flere knapper at skrue på — godt hvis du ved hvad du laver, og en hurtig vej til noget der går i stykker hvis du ikke gør.

WP Super Cache vedligeholdes af Automattic, som også står bag WordPress.com. Over en million installationer, enkelt og stabilt.

Cache Enabler fra KeyCDN er letvægtsvalget. Omkring 100.000 installationer, og næsten ingen indstillinger — hvilket er hele pointen.

Og en advarsel: Comet Cache blev tidligere anbefalet mange steder, også her på siden. Sidste rigtige udgivelse er fra februar 2017. Pluginet er forladt, får hverken sikkerhedsrettelser eller kompatibilitetsopdateringer, og bør ikke bruges på en side i drift.

De tre fejl jeg finder oftest

To cache-plugins der slås indbyrdes. Det er den mest almindelige. Der bliver installeret WP Rocket, og et halvt år efter kommer der et “speed booster” ovenpå, eller hosten slår sit eget optimeringsplugin til. Så minificerer to plugins hinandens output, og to systemer tror hver især at de ejer cachen. Resultatet er en side der er langsommere end før, og fejl der kommer og går alt efter hvem der ryddede sidst. Kør ét cache-plugin. Min egen hastighedstest kigger netop efter det, fordi jeg finder det så tit.

En cache der aldrig bliver ryddet. Du retter din CSS, ser ingen forskel, retter den igen. Filen ligger stadig i cachen — måske i pluginets, måske i CDN’ets, måske begge steder. Ryd altid begge lag, når du har ændret noget, og tjek i en privat browserfane frem for i den du lige har arbejdet i.

En webshop hvor kurven bliver cachet. Den er sjældnest og dyrest. Kunde nummer to får kunde nummer ets kurv serveret, fordi kurvsiden røg med i sidecachen. WooCommerce sætter selv cookies som woocommerce_cart_hash, woocommerce_items_in_cart og wp_woocommerce_session_, og de skal være undtaget både i sidecachen og i databasecachen. Læs mere under hastighedsoptimering af WooCommerce.

FAQ om cache

Hvad er cache på en hjemmeside?

Cache er gemte kopier af noget der allerede er beregnet eller hentet, så det kan leveres igen uden at blive lavet forfra. På en hjemmeside kan det være den færdige HTML, resultatet af en databaseforespørgsel, eller de billeder og CSS-filer browseren allerede har hentet.

Hvor meget hurtigere bliver min side af cache?

På serversiden er forskellen stor. Jeg måler typisk en TTFB under 80–150 millisekunder med HTML-cache, også på sider hvor den samme URL uden cache tager flere sekunder. Hvor meget den føles hurtigere afhænger så af resten: billeder, JavaScript og hvad der blokerer visningen.

Skal jeg bruge cache på min hjemmeside?

Ja. Der findes ingen WordPress-side der ikke bliver hurtigere af sidecache. Det eneste du skal være omhyggelig med, er undtagelserne — kurv, kasse, Min konto og indloggede brugere.

Kan cache ødelægge noget?

Ja, og det sker. De to typiske er en webshop hvor kurven bliver cachet, og en side hvor rettelser ikke slår igennem fordi cachen ikke er ryddet. Begge dele skyldes opsætningen, ikke caching som princip.

Hvor længe bør data blive i cachen?

Statiske filer med versionerede navne kan ligge i måneder hos brugeren. HTML bør ligge kortere — timer til dage — og skal ryddes automatisk, når indholdet ændrer sig. Har du et cache-plugin, gør det som regel det sidste selv.

Hvordan påvirker cache min SEO?

Indirekte, men mærkbart. Cache trækker TTFB ned, og TTFB ligger foran LCP, som er et af Googles Core Web Vitals. Derudover kan Googles crawler nå flere sider på den samme tid, når serveren svarer hurtigt. Cache alene giver ikke en god placering — det gør indholdet — men en langsom server kan koste dig en.