Kort fortalt: Moderne browsere kan lægge en komplet side (HTML + DOM-tilstand og mere) i en back/forward cache. Når brugeren trykker tilbage, genindføres snapshot’et - ofte næsten med det samme - uden at hele dokumentet loader forfra.
Hvorfor bfcache betyder noget i praksis
- Oplevet hastighed slår ofte “rå” load-tider: mange brugere navigerer frem og tilbage mellem liste og detalje, artikel og oversigt, checkout og indkøbskurv.
- Analytics og tags skal forstå at siden kan genskabes uden et klassisk
load-event - ellers tæller I forkert eller kører dobbelt logik. - Fejl i lifecycle (fx
unload) kan blokere bfcache og tvinge fuld reload, så jeres “tilbage” føles langsommere end naboens site.
Hvad lægges der egentlig i bfcache?
Tænk på det som et fotografi af sidens tilstand på navigationsøjeblikket: DOM, visse runtime-tilstande og hvad browseren kan genskabe sikkert. Det er ikke bare “gem HTML i disk-cache”. Derfor er det hurtigere end et normalt fetch af samme URL - men det stiller også krav til at siden må fryses uden at bryde sikkerhed eller stabilitet.
Ting der ofte blokerer eller svækker bfcache
unload/beforeunload-lyttere - klassisk problem. Mange gamle analytics-mønstre bruger dem; moderne anbefaling er at brugepagehideog tjekkeevent.persistedfor at vide om siden går til bfcache.- Visse HTTP-headers og dokumentpolitikker - fx no-cache-kombinationer eller indstillinger der signalerer at dokumentet ikke må gemmes på den måde (detaljer varierer med browser og version; tjek aktuel dokumentation når I debugger).
- Åbne forbindelser, WebSockets, visse embeds der kræver fuld teardown eller ikke tåler at blive “frosset”.
- Hukommelsespress på lav-end enheder - browseren kan vælge at droppe snapshot for at frigøre RAM.
Document caching (Cache-Control) og bfcache er forskellige lag. Du kan have fin browser-cache på HTML og stadig miste bfcache pga. JavaScript API-brug eller headers.
Måling og fejlsøgning
Chrome DevTools → Application eller Performance kan hjælpe med at se om en navigation var bfcache. I felt er CrUX og egen RUM nyttige for at forstå om jeres brugere overhovedet har mange tilbage-navigationer - men felt rapporterer ikke bfcache som en enkelt knap; det handler om at kombinere værktøjer og sessionstests.
Forhold til Core Web Vitals
bfcache er tæt på oplevelse, ikke en separat CWV-metrik. INP kan føles bedre når brugeren hurtigt er tilbage på en side der allerede er klar. LCP på en cold load påvirkes ikke direkte af bfcache - men brugerens samlede session føles ofte bedre når frem/tilbage er snappy.
Relaterede begreber
- prefetch - anden teknik til at forberede næste navigation
- service worker - andet cache-lag; ikke det samme som bfcache
- HTTP-cache og edge caching
FAQ
Kan jeg tvinge bfcache til at blive brugt?
Du kan fjerne kendte blokeringer (fx problematiske unload-handlere og visse headers), men du kan ikke garantere bfcache for alle brugere. Hukommelsespres, privat browsing og browserpolitik kan stadig forhindre snapshot.
Påvirker bfcache SEO eller ranking direkte?
Ikke som et separat ranking-signal. Effekten er indirekte: hurtigere tilbage-navigation kan påvirke engagement. Teknisk SEO handler stadig om crawlbar HTML, canonical og kvalitet af indhold.
Hvorfor ser jeg ikke bfcache i Lighthouse på samme måde som i felt?
Lab-tests kører ofte enkeltstående navigationer uden den samme historik som en rigtig bruger der går frem og tilbage mellem sider. Brug DevTools Application/Performance og feltdata for at se om jeres rigtige flows rammer bfcache.
Er bfcache det samme som HTTP-cache eller service worker-cache?
Nej. bfcache er et snapshot af hele dokumentets tilstand i hukommelsen til frem/tilbage-navigation. HTTP-cache gemmer svar pr. URL. Service workers kan cache strategisk, men bfcache er en browsermekanisme på et andet lag.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Få edge cache-hit på HTML: undgå cookies, forkert Vary og dårlige cache keys
Mange sites har CDN, men får stadig høj TTFB fordi HTML ikke caches. Lær et praktisk workflow til at få cache-hit på offentlige sider uden at servere forkert indhold.
Forbedr TTFB med caching, edge cache og hurtigere serverrespons
Lær hvordan du reducerer TTFB med page cache, edge cache, korrekt cache strategi og bedre serverrespons på HTML.
Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning
Lær at finde ud af om din server eller reverse proxy buffer HTML-svar, og få streaming (chunked) til at flytte første visning og LCP i den rigtige retning.
Range request i praksis: når 206 Partial Content ikke sker (og hvad det koster)
En feltguide til at spotte når browseren forsøger at bruge Range request, men ender med at få hele filer retur (200 i stedet for 206). Lær at se det i DevTools og ret fejl i proxy/CDN/origin.
Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis
Reverse proxy-laget kan være årsagen til høj TTFB, mystiske cache misses og 502/504-fejl. Lær hvad du skal kigge efter i headers og waterfall, og få et praktisk debug-flow.
Vary-header og caching: undgå forkert indhold og lav cache-hit-rate
Vary bestemmer hvornår caches skal gemme flere varianter af samme URL (fx gzip vs brotli eller dansk vs engelsk). Lær de typiske fejl, og hvordan du tester med headers og curl.
