{"id":16581,"date":"2026-01-05T18:23:33","date_gmt":"2026-01-05T17:23:33","guid":{"rendered":"https:\/\/webhosting.de\/http-cache-headers-sabotieren-caching-cachefix\/"},"modified":"2026-01-05T18:23:33","modified_gmt":"2026-01-05T17:23:33","slug":"http-cache-headers-saboterer-caching-cachefix","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/http-cache-headers-sabotieren-caching-cachefix\/","title":{"rendered":"HTTP-cache-headers: S\u00e5dan saboterer de din caching-strategi"},"content":{"rendered":"<p>HTTP-cache-headers bestemmer, hvordan browsere og proxyserver gemmer indhold i cachen \u2013 hvis de er indstillet forkert, bremser de indl\u00e6sningstiden og \u00f8ger serverbelastningen m\u00e6rkbart. I dette indl\u00e6g viser jeg, hvordan sm\u00e5 fejl i headers kan p\u00e5virke din <strong>Caching-strategi<\/strong> sabotere, og hvordan du med f\u00e5 rettelser kan blive m\u00e6rkbart hurtigere.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<p>F\u00f8lgende n\u00f8glebudskaber hj\u00e6lper mig med hurtigt at kontrollere HTTP-headere og holde dem rene p\u00e5 lang sigt.<\/p>\n<ul>\n  <li><strong>TTL<\/strong> V\u00e6lg rigtigt: Cache statiske aktiver meget l\u00e6nge, HTML kort og kontrolleret.<\/li>\n  <li><strong>Validering<\/strong> Brug: ETag og Last-Modified reducerer un\u00f8dvendige anmodninger.<\/li>\n  <li><strong>Konflikter<\/strong> Undg\u00e5: Origin- og CDN-headere skal passe sammen.<\/li>\n  <li><strong>Versionering<\/strong> Brug: Filhash'er muligg\u00f8r aggressive cache-strategier.<\/li>\n  <li><strong>Overv\u00e5gning<\/strong> Etablere: M\u00e5le HIT-raten og \u00f8ge den systematisk.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/http-cache-header-debug-3471.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad HTTP-cache-headers virkelig styrer<\/h2>\n\n<p>Cache-Control, Expires, ETag og Last-Modified bestemmer, om indholdet er nyt, hvor l\u00e6nge det er gyldigt, og hvorn\u00e5r browseren skal foresp\u00f8rge. Med <strong>max-alder<\/strong> definerer jeg levetiden, med public\/private placeringen i browseren eller delte caches. Direktiver som <strong>ingen opbevaring<\/strong> forhindrer lagring fuldst\u00e6ndigt, no-cache tvinger en revalidering f\u00f8r brug. For statiske filer er et \u00e5rs gyldighed v\u00e6rd, HTML f\u00e5r korte tider med intelligent revalidering. Jeg bygger desuden p\u00e5 <strong>uforanderlig<\/strong>, hvis filer garanteret forbliver u\u00e6ndrede via hash-version.<\/p>\n\n<p>Denne styring har direkte indflydelse p\u00e5 latenstid, b\u00e5ndbredde og serverbelastning. En \u00f8get <strong>HIT-rate<\/strong> forkorter ventetider og reducerer backend-arbejdet. Derudover optimerer jeg overf\u00f8rslen med <a href=\"https:\/\/webhosting.de\/da\/http-komprimering-konfiguration-ydeevneforbedring-optimeret\/\">HTTP-komprimering<\/a>, s\u00e5 der skal transporteres f\u00e6rre bytes. Hvis man adskiller disse ting tydeligt, aflastes CDN'er, proxyservere og browser-caches i lige h\u00f8j grad. S\u00e5dan sikrer jeg en problemfri <strong>Indl\u00e6sningstider<\/strong> igennem.<\/p>\n\n<h2>TTL-planl\u00e6gning i praksis<\/h2>\n\n<p>Den passende TTL afh\u00e6nger af \u00e6ndringsfrekvens, risiko og tilbagefaldsstrategi. For aktiver med filhash s\u00e6tter jeg 12 m\u00e5neder, fordi jeg kontrollerer \u00e6ndringer via nye filnavne. For HTML orienterer jeg mig efter indholdets dynamik: Start- eller kategorisider forbliver ofte aktuelle i 1\u20135 minutter, mens detaljesider med kommentarer er kortere. Det er vigtigt at have en <strong>Rollback-sti<\/strong>: Hvis der alligevel opst\u00e5r en fejl live, har jeg brug for en hurtig purge (Edge) og en tvungen revalidering (must-revalidate) for browsere. API-responser f\u00e5r korte TTL'er, men med <em>stale<\/em>-Direktiver, s\u00e5 brugerne kan se svarene i tilf\u00e6lde af fejl. Jeg dokumenterer disse profiler pr. rute eller filtype og forankrer dem i build-\/deploy-pipeline, s\u00e5 ingen \u201estille\u201c \u00e6ndringer utilsigtet underminerer friskhedspolitikken.<\/p>\n\n<h2>Hvordan fejlkonfigurationer saboterer strategien<\/h2>\n\n<p>For kort <strong>TTL'er<\/strong> som max-age=60 sekunder ved CSS, JS eller billeder tvinger konstante foresp\u00f8rgsler og \u00f8del\u00e6gger fordelene ved cachen. En global <strong>no-cache<\/strong> i CMS-ops\u00e6tninger bremser selv, n\u00e5r store dele af en side faktisk er stabile. Mangler ETag eller Last-Modified, indl\u00e6ser browseren filer helt forfra i stedet for at kontrollere dem p\u00e5 en smart m\u00e5de. Overfl\u00f8dige query-strings skaber fragmentering <strong>Cache-n\u00f8gler<\/strong> og s\u00e6nker HIT-raten betydeligt. Hvis Origin sender no-cache, ignorerer CDN kantcaches \u2013 hvilket resulterer i l\u00e6ngere veje og h\u00f8jere serverbelastning.<\/p>\n\n<p>Jeg kan se resultatet i m\u00e5lingerne: Flere anmodninger, h\u00f8jere <strong>CPU-tid<\/strong> og stigende svartider. Ved trafikspidser stiger risikoen for timeouts. Samtidig stiger b\u00e5ndbreddeforbruget, uden at brugerne m\u00e6rker nogen fordel. Med et kig i DevTools kan jeg hurtigt genkende s\u00e5danne m\u00f8nstre. Jeg begynder s\u00e5 med at justere <strong>Cache-kontrol<\/strong>, f\u00f8r jeg \u00f8ger serverressourcerne.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/httpcachemeeting_7294.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Anbefalinger pr. indholdstype: de passende direktiver<\/h2>\n\n<p>Afh\u00e6ngigt af indholdstypen bruger jeg forskellige <strong>Overskrift<\/strong>, s\u00e5 caches fungerer optimalt, og brugerne kan se aktuelle data. Nedenst\u00e5ende tabel viser gennempr\u00f8vede profiler, som jeg bruger i projekter.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Indhold<\/th>\n      <th>Anbefalet cache-kontrol<\/th>\n      <th>Gyldighed<\/th>\n      <th>Hint<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>JS\/CSS\/billeder (versioneret)<\/td>\n      <td>offentlig, max-age=31536000, <strong>uforanderlig<\/strong><\/td>\n      <td>12 m\u00e5neder<\/td>\n      <td>Brug filnavn med hash (f.eks. app.abc123.js)<\/td>\n    <\/tr>\n    <tr>\n      <td>Skriftfiler (woff2)<\/td>\n      <td>offentlig, max-age=31536000, uforanderlig<\/td>\n      <td>12 m\u00e5neder<\/td>\n      <td>V\u00e6r opm\u00e6rksom p\u00e5 CORS, hvis indl\u00e6st fra CDN<\/td>\n    <\/tr>\n    <tr>\n      <td>HTML (offentlig)<\/td>\n      <td>public, max-age=300, stale-while-revalidate=86400<\/td>\n      <td>5 minutter<\/td>\n      <td>Kort <strong>Friskhed<\/strong>, bl\u00f8d genindl\u00e6sning i baggrunden<\/td>\n    <\/tr>\n    <tr>\n      <td>HTML (personliggjort)<\/td>\n      <td>privat, max-age=0, no-cache<\/td>\n      <td>Revalidering<\/td>\n      <td>Ingen videregivelse i delte cacher<\/td>\n    <\/tr>\n    <tr>\n      <td>API'er<\/td>\n      <td>public, max-age=60\u2013300, stale-if-error=86400<\/td>\n      <td>1\u20135 minutter<\/td>\n      <td>Fejltilf\u00e6lde med <strong>stale<\/strong> afb\u00f8de<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Disse profiler d\u00e6kker typiske websteder og hj\u00e6lper med hurtigt at skabe konsistens. <strong>Regler<\/strong> Det er vigtigt at have en klar versionering for aktiver, s\u00e5 lange max-age-v\u00e6rdier ikke leverer for\u00e6ldede filer. HTML forbliver kortvarigt og opdateres via revalidering. API'er f\u00e5r korte tider og et sikkerhedsnet via stale-if-error. P\u00e5 den m\u00e5de forbliver siderne ogs\u00e5 ved forstyrrelser. <strong>brugbar<\/strong>.<\/p>\n\n<h2>Cache fejlkoder og omdirigeringer korrekt<\/h2>\n\n<p>Videresendelser og fejlside fortjener deres egne regler. <strong>301\/308<\/strong> (permanent) kan caches i CDN'er og browsere i meget lang tid; jeg angiver her ofte dage til uger for at undg\u00e5 omdirigeringsk\u00e6der. <strong>302\/307<\/strong> (midlertidige) f\u00e5r korte TTL'er, ellers bliver midlertidige tilstande \u201efrosset\u201c. For 404\/410 er det en god id\u00e9 at have en moderat friskhed (f.eks. minutter til timer), s\u00e5 bots og brugere ikke konstant foresp\u00f8rger; ved hyppigt skiftende indhold holder jeg 404 ret kort. <strong>5xx<\/strong>-Jeg cacher generelt ikke fejl, men bruger i stedet stale-if-error til midlertidigt at levere fungerende kopier. P\u00e5 den m\u00e5de forbliver platformen stabil, og jeg reducerer rerendering-belastningen ved hyppigt anmodede, men manglende stier.<\/p>\n\n<h2>Korrekt brug af validering: ETag og Last-Modified<\/h2>\n\n<p>Med <strong>ETag<\/strong> og Last-Modified kontrollerer browseren, om en ressource virkelig skal indl\u00e6ses igen. Klienten sender If-None-Match eller If-Modified-Since, og serveren svarer ideelt set med 304 i stedet for 200. P\u00e5 den m\u00e5de sparer jeg overf\u00f8rsel og reducerer <strong>Trafik<\/strong> tydeligt. For statiske filer er Last-Modified ofte tilstr\u00e6kkeligt, mens jeg bruger ETags til dynamisk genereret indhold. Vigtigt: Konsistent ETag-generering, s\u00e5 caches kan genkende hits.<\/p>\n\n<p>Jeg kombinerer gerne validering med <strong>stale<\/strong>-Direktiver. stale-while-revalidate holder siderne hurtige, mens de opdateres i baggrunden. stale-if-error sikrer p\u00e5lidelighed i tilf\u00e6lde af backend-problemer. S\u00e5ledes forbliver brugeroplevelsen stabil, og serverne sk\u00e5nes. F\u00f8lgende uddrag viser typiske indstillinger, som jeg bruger.<\/p>\n\n<pre><code>Header set Cache-Control \"public, max-age=31536000, immutable\"\n \/etc\/nginx\/conf.d\/caching.conf location ~* .(css|js|png|jpg|svg|woff2)$ { add_header Cache-Control \"public, max-age=31536000, immutable\"; }\n<\/code><\/pre>\n\n<h2>Avancerede direktiver og detaljer<\/h2>\n\n<p>Ud over max-age bruger jeg m\u00e5lrettet <strong>s-maxage<\/strong>, for at fylde Edge-caches l\u00e6ngere end browsere. S\u00e5ledes kan CDN f.eks. holde i 1 time, mens klienter genvaliderer efter 5 minutter. <strong>skal-revalidere<\/strong> tvinger browsere til at kontrollere udl\u00f8bne kopier f\u00f8r brug \u2013 vigtigt i sikkerhedsrelevante omr\u00e5der. <strong>proxy-revalidate<\/strong> retter pligten mod delte cacher. Med <strong>ingen transformation<\/strong> forhindrer jeg proxyservere i at \u00e6ndre billeder eller komprimering uden foresp\u00f8rgsel. For at sikre bred kompatibilitet sender jeg ud over Cache-Control valgfrit en <strong>Udl\u00f8ber<\/strong>-Dato i fremtiden (Assets) eller fortiden (HTML), selvom moderne cacher prim\u00e6rt overholder Cache-Control. Ved CDN-strategier adskiller jeg browser- og edge-regler: public + max-age for klienter, plus s-maxage\/Surrogate-Control for kanten. Denne opdeling maksimerer HIT-rater uden risiko for for\u00e6ldelse p\u00e5 slutapparater.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/http-cache-header-fehler-3017.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Samspil med CDN og edge-caches<\/h2>\n\n<p>Et CDN respekterer <strong>Origin-header<\/strong> \u2013 Forkerte direktiver ved oprindelsen deaktiverer globale caches. For delte caches indstiller jeg public og om n\u00f8dvendigt s-maxage, s\u00e5 kanter holder l\u00e6ngere end browsere. Surrogate-Control kan desuden levere regler for Edge-caches. Hvis no-cache rammer oprindelsen, afviser CDN den \u00f8nskede <strong>Opbevaring<\/strong>. Derfor koordinerer jeg bevidst browser- og CDN-strategien.<\/p>\n\n<p>Ved nye projekter unders\u00f8ger jeg desuden forudindl\u00e6sningsstrategier. Med <a href=\"https:\/\/webhosting.de\/da\/http3-push-preload-optimering-af-ydeevne-website-zoom\/\">HTTP\/3 Push &amp; Preload<\/a> Jeg indl\u00e6ser kritiske aktiver tidligt og reducerer renderingsblokeringer. Denne teknik erstatter ikke caching, men supplerer den. Sammen med lange TTL'er for aktiver forbedres startydelsen m\u00e6rkbart. S\u00e5dan arbejder jeg p\u00e5 netv\u00e6rksrangeringen, f\u00f8r <strong>Server<\/strong> overhovedet kommer til at svede.<\/p>\n\n<h2>Vary-strategien i detaljer<\/h2>\n\n<p><strong>Varierer<\/strong> bestemmer, hvilke foresp\u00f8rgselsheadere der genererer nye varianter. Jeg holder Vary minimalt: For HTML er det oftest Accept-Encoding (komprimering) og eventuelt sprog; for aktiver helst slet ikke. Et for bredt Vary (f.eks. User-Agent) \u00f8del\u00e6gger HIT-raten. Samtidig skal <strong>ETags<\/strong> som <em>repr\u00e6sentationsspecifik<\/em> Reflektere variant: Hvis jeg leverer gzip eller br, g\u00e6lder ETags pr. kodningsvariant, og jeg indstiller Vary: Accept-Encoding. Hvis jeg bruger svage ETags (W\/), s\u00f8rger jeg for at generere dem konsekvent, ellers opst\u00e5r der un\u00f8dvendige 200'ere. Fonts eller billeder skal som regel klare sig uden Vary, s\u00e5 n\u00f8glerne forbliver stabile. Mit princip: F\u00f8rst definere, hvilke varianter der er fagligt n\u00f8dvendige \u2013 f\u00f8rst derefter udvide Vary, aldrig omvendt.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/httpcacheoffice0983.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Overv\u00e5gning og diagnose i DevTools<\/h2>\n\n<p>Jeg starter altid i <strong>Netv\u00e6rksfane<\/strong> browser-v\u00e6rkt\u00f8jerne. Der kan jeg se, om svarene kommer fra cachen, hvor gamle de er, og hvilke direktiver der g\u00e6lder. Kolonnerne Age, Cache-Control og Status hj\u00e6lper med hurtige kontroller. En HIT-rate under 50% viser, at der er behov for handling, og m\u00e5lv\u00e6rdier p\u00e5 80% og mere er realistiske. Ved afvigelser tjekker jeg f\u00f8rst de tilh\u00f8rende headers.<\/p>\n\n<p>V\u00e6rkt\u00f8jer som PageSpeed eller GTmetrix bekr\u00e6ftede mine lokale <strong>M\u00e5linger<\/strong>. Jeg sammenligner derefter f\u00f8r\/efter \u00e6ndringer for at kvantificere fordelene. Hvis der tilf\u00f8jes store overf\u00f8rselsm\u00e6ngder, aktiverer jeg konsekvent moderne komprimering. P\u00e5 den m\u00e5de sparer jeg yderligere millisekunder. S\u00e5ledes dokumenterer jeg hver eneste tuning med h\u00e5rde <strong>Tal<\/strong>.<\/p>\n\n<h2>Automatiserede kontroller og CI<\/h2>\n\n<p>For at reglerne ikke bliver udvandet, integrerer jeg header-kontroller i CI. Jeg definerer m\u00e5lprofiler for hver sti og lader hver build kontrollere tilf\u00e6ldigt mod staging. Enkle shell-kontroller er ofte tilstr\u00e6kkelige:<\/p>\n\n<pre><code># Eksempel: Forventede direktiver for versionerede aktiver curl -sI https:\/\/example.org\/static\/app.abc123.js | grep -i \"cache-control\" # Forventet kortvarighed og revalidering for HTML\ncurl -sI https:\/\/example.org\/ | egrep -i \"cache-control|etag|last-modified\" # Inspicere Age-header og cache-status (hvis tilg\u00e6ngelig) curl -sI https:\/\/example.org\/styles.css | egrep -i \"age|cache-status|x-cache\"\n<\/code><\/pre>\n\n<p>I kombination med syntetiske tests planl\u00e6gger jeg regelm\u00e6ssige \u201eheader-audits\u201c. Resultaterne f\u00f8res tilbage til infrastrukturkoden. S\u00e5ledes forbliver <strong>Politikker<\/strong> stabil \u2013 uanset hvem der sidst har \u00e6ndret CMS, CDN eller serverkonfigurationen.<\/p>\n\n<h2>Hostingoptimering: Caching af sider, objekter og opkoder<\/h2>\n\n<p>Ud over browser- og CDN-caches satser jeg p\u00e5 <strong>Server-caches<\/strong>. Page Caching leverer f\u00e6rdige HTML-sider, Object Caching bufferer database-resultater, og OPcache besk\u00e6ftiger sig med PHP-bytecode. Disse lag aflaster backend betydeligt, n\u00e5r headere er korrekt indstillet. Kun kombinationen af hurtige kanter, sunde TTL'er og server-caches giver reelle topv\u00e6rdier. P\u00e5 den m\u00e5de holder jeg svartiderne stabile, selv n\u00e5r <strong>Trafik<\/strong> \u00f8ges.<\/p>\n\n<p>F\u00f8lgende markedsoversigt viser, hvad jeg l\u00e6gger v\u00e6gt p\u00e5, n\u00e5r det g\u00e6lder hosting. En h\u00f8j HIT-rate, Redis-tilg\u00e6ngelighed og en god pris er afg\u00f8rende for valget.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Hosting-udbyder<\/th>\n      <th>PageSpeed-score<\/th>\n      <th>Redis-underst\u00f8ttelse<\/th>\n      <th>Pris (starter)<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>webhoster.de<\/td>\n      <td>98\/100<\/td>\n      <td>Ja<\/td>\n      <td>4,99 \u20ac<\/td>\n    <\/tr>\n    <tr>\n      <td>Andet1<\/td>\n      <td>92\/100<\/td>\n      <td>Valgfrit<\/td>\n      <td>6,99 \u20ac<\/td>\n    <\/tr>\n    <tr>\n      <td>Andet2<\/td>\n      <td>89\/100<\/td>\n      <td>Nej<\/td>\n      <td>5,99 \u20ac<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/entwickler_httpcache_7291.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ugyldigg\u00f8relse og udrensningsstrategier<\/h2>\n\n<p>Cache-opbygning er kun halvdelen af arbejdet \u2013 den <strong>Invalidering<\/strong> afg\u00f8r sikkerhed og smidighed. For aktiver udl\u00f8ser jeg \u00e6ndringer via filhash, s\u00e5 der ikke er behov for rensninger. For HTML og API'er planl\u00e6gger jeg m\u00e5lrettede rensninger: efter implementering (kritiske ruter), efter offentligg\u00f8relse (kun ber\u00f8rte sider) eller efter funktionsflag. Jeg underst\u00f8tter gerne edge-caches via tags\/n\u00f8gler for at <em>Grupper<\/em> at t\u00f8mme i stedet for at finde stier enkeltvis. Hvor det er muligt, bruger jeg \u201eSoft Purge\u201c: Indhold markeres straks som \u201efor\u00e6ldet\u201c og valideres f\u00f8rst ved n\u00e6ste foresp\u00f8rgsel. P\u00e5 den m\u00e5de undg\u00e5r jeg belastningsspidser ved samtidige re-fetches. Det er vigtigt at have en organiseret kortl\u00e6gning: Hvilke begivenheder udl\u00f8ser hvilken purge? Denne logik skal versioneres i platformen.<\/p>\n\n<h2>Sikkerhed og databeskyttelse: offentligt vs. privat<\/h2>\n\n<p>Personlige sider h\u00f8rer hjemme i <strong>Privat cache<\/strong> i browseren, ikke i delte caches. Derfor indstiller jeg private, max-age=0 eller no-cache for s\u00e5danne indhold. Offentlige HTML-sider kan f\u00e5 public med kort friskhed. Hvis jeg er opm\u00e6rksom p\u00e5 cookies i anmodningen, forbliver indholdet rent adskilt. P\u00e5 den m\u00e5de forhindrer jeg, at fremmede brugere u\u00f8nsket <strong>Data<\/strong> andre ser.<\/p>\n\n<p>Samtidig anvender jeg strenge regler for betalings- og kontoomr\u00e5der. no-store forhindrer enhver lagring af f\u00f8lsomme svar. For resten af webstedet er jeg gener\u00f8s, s\u00e5 ydeevnen er i orden. Denne klare adskillelse holder platformen hurtig og sikker. Jeg dokumenterer <strong>Profiler<\/strong>, s\u00e5 alle involverede forbliver konsekvente.<\/p>\n\n<h2>Forst\u00e5 heuristisk caching<\/h2>\n\n<p>Hvis Cache-Control og Expires mangler, bruger caches <strong>heuristik<\/strong> tilbage \u2013 cirka en procentdel af tiden siden sidste \u00e6ndring. Dette f\u00f8rer til resultater, der er sv\u00e6re at gengive, og svingende aktualitet. Jeg undg\u00e5r s\u00e5danne automatismer ved eksplicit at angive Cache-Control for hver relevant rute. Hvor Last-Modified er un\u00f8jagtig (f.eks. ved dynamiske skabeloner), foretr\u00e6kker jeg ETags. P\u00e5 den m\u00e5de styrer jeg aktivt aktualiteten og f\u00e5r stabile m\u00e5linger p\u00e5 tv\u00e6rs af alle klienter.<\/p>\n\n<h2>Range-anmodninger og store filer<\/h2>\n\n<p>Afspil for medier og downloads <strong>R\u00e6kkevidde<\/strong>-foresp\u00f8rgsler (206 Partial Content) spiller en rolle. Jeg aktiverer Accept-Ranges og leverer konsistente ETags\/Last-Modified, s\u00e5 browsere kan genbruge dele korrekt. For versionerede videosegmenter (HLS\/DASH) indstiller jeg lange TTL'er; manifestene selv forbliver kortvarige. Vigtigt: H\u00e5ndter If-Range korrekt, s\u00e5 delomr\u00e5der ikke f\u00f8rer til for\u00e6ldede blandede tilstande ved \u00e6ndringer. For f\u00f8lsomt indhold g\u00e6lder fortsat: ingen lagring med no-store, selvom Range er i spil.<\/p>\n\n<h2>Hurtig fejlfinding af almindelige fejl: mit playbook<\/h2>\n\n<p>Jeg begynder med en oversigt over overskrifter: Hvilke <strong>direktiver<\/strong> leverer Origin, og hvad \u00e6ndrer CDN? Derefter definerer jeg TTL-profiler for hver indholdstype. Versionerede aktiver f\u00e5r et \u00e5r, HTML fem minutter plus revalidering. Jeg aktiverer ETag\/Last-Modified overalt, hvor det giver mening. Derefter kontrollerer jeg, om un\u00f8dvendige Vary- eller Query-parametre <strong>HIT-rate<\/strong> tryk.<\/p>\n\n<p>I n\u00e6ste trin tager jeg mig af netv\u00e6rksdetaljer uden for cachen. En forkert <a href=\"https:\/\/webhosting.de\/da\/charset-header-forsinker-webserverens-ydeevne\/\">Charset-header<\/a> eller manglende komprimering koster ogs\u00e5 tid. Derefter m\u00e5ler jeg igen: DevTools, syntetiske tests og om n\u00f8dvendigt Real-User-Monitoring. Hvis v\u00e6rdierne er korrekte, fastfryser jeg reglerne i konfigurationen og holder dem versioneret. S\u00e5dan vokser <strong>kvalitet<\/strong> Trin for trin.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/http-cache-serverraum-8123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Med korrekte <strong>HTTP-headere<\/strong> Jeg styrer, hvad der ligger hvor og hvor l\u00e6nge \u2013 og sparer tid og ressourcer. Lange TTL'er for versionerede aktiver, korte tider plus revalidering for HTML og meningsfulde stale-direktiver giver hastighed og robusthed. Rene cache-n\u00f8gler, konsekvent versionering og klare regler for public\/private forhindrer typiske forhindringer. Overv\u00e5gning leverer dokumentation og viser resterende huller. Hvis man g\u00f8r det p\u00e5 denne m\u00e5de, h\u00e6ver man <strong>Ydelse<\/strong> m\u00e6rkbar og stabil.<\/p>","protected":false},"excerpt":{"rendered":"<p>HTTP-cache-headers saboterer din caching-strategi ved hj\u00e6lp af caching-konfigurationsfejl. L\u00e6r hostingoptimering for at opn\u00e5 optimal ydeevne!<\/p>","protected":false},"author":1,"featured_media":16574,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-16581","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"1458","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"HTTP Cache Headers","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"16574","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/16581","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=16581"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/16581\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/16574"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=16581"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=16581"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=16581"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}