{"id":17058,"date":"2026-01-27T08:37:12","date_gmt":"2026-01-27T07:37:12","guid":{"rendered":"https:\/\/webhosting.de\/wordpress-browser-caching-fehler-serverboost\/"},"modified":"2026-01-27T08:37:12","modified_gmt":"2026-01-27T07:37:12","slug":"wordpress-browser-caching-fejl-serverboost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/wordpress-browser-caching-fehler-serverboost\/","title":{"rendered":"WordPress og browser-caching - ofte konfigureret forkert"},"content":{"rendered":"<p>WordPress browser-caching for\u00e5rsager ofte langsomme svar, fordi operat\u00f8rerne skal <strong>Cache-overskrift<\/strong> indstillet forkert eller slet ikke kontrolleret. Jeg vil vise dig, hvordan typiske fejlkonfigurationer returnerer 200 i stedet for 304, hvorfor TTL'er mangler, og hvordan jeg kan ops\u00e6tte caching i WordPress korrekt. <strong>Ydelse<\/strong> trim.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>Lang TTL<\/strong> for statiske aktiver forhindrer un\u00f8dvendige anmodninger.<\/li>\n  <li><strong>Klar adskillelse<\/strong> af statiske og dynamiske stier beskytter admin og login.<\/li>\n  <li><strong>Et system<\/strong> Bland ikke konkurrerende cache-plugins.<\/li>\n  <li><strong>Tjek overskrifter<\/strong> med DevTools og 304 status.<\/li>\n  <li><strong>Server-caching<\/strong> og browserens cache.<\/li>\n<\/ul>\n\n<h2>S\u00e5dan fungerer browser-caching i WordPress i virkeligheden<\/h2>\n\n<p>Browseren gemmer statiske filer lokalt, s\u00e5 det ikke er n\u00f8dvendigt at genindl\u00e6se dem. <strong>HTTP-anmodninger<\/strong>. Ved det andet bes\u00f8g l\u00e6ser den billeder, CSS og JS fra den lokale hukommelse og beder kun serveren om \u00e6ndringer. Det reducerer m\u00e6ngden af data, svartiderne bliver kortere, og det f\u00f8les straks mere responsivt at scrolle. <strong>flydende<\/strong> p\u00e5. Hvis der ikke er klare instruktioner, genindl\u00e6ses browseren helt hver gang, og tiden til interaktion lider. Korrekt indstillede cache control headers muligg\u00f8r 304-valideringer, reducerer b\u00e5ndbredden og reducerer belastningen p\u00e5 PHP og databasen. Jeg bruger dette konsekvent, fordi is\u00e6r tilbagevendende brugere har mest gavn af vedvarende caching.<\/p>\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\/wordpress-caching-problem-8392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvorfor konfiguration ofte mislykkes<\/h2>\n\n<p>Mange websteder leverer statiske filer med latterligt korte <strong>max-alder<\/strong>-v\u00e6rdier. Nogle plugins overskriver hinandens .htaccess og indstiller modstridende direktiver. Webstedet markerer ofte admin-stier forkert, hvilket f\u00e5r indhold fra \/wp-admin eller \/wp-login.php til at ende i cachen utilsigtet, og sessioner kolliderer. Jeg tjekker ogs\u00e5 forskellen mellem det f\u00f8rste og det tilbagevendende kald, da dette tydeligt forklarer reelle brugeroplevelser; sammenligningen passer med dette <a href=\"https:\/\/webhosting.de\/da\/wordpress-caching-sammenligning-forste-opkald-langsom-hastighed\/\">F\u00f8rste opkald vs. tilbagevendende opkald<\/a>. Hvis du derefter bruger foresp\u00f8rgselsstrenge uden versionering, vil du oprette gamle filer i hukommelsen og undre dig over <strong>For\u00e6ldet<\/strong> Stilarter.<\/p>\n\n<h2>Indstil WP-cache-headers korrekt<\/h2>\n\n<p>Jeg kontrollerer varigheden med <strong>Cache-kontrol<\/strong> og Expires, og jeg undg\u00e5r tvetydige ETags i milj\u00f8er med flere servere. For Apache indstiller jeg Expires til meningsfulde v\u00e6rdier og definerer \u201epublic, max-age\u201c for aktiver. For Nginx tilf\u00f8jer jeg add_header-direktiver og s\u00f8rger for, at HTML f\u00e5r kort tid eller \u201eno-store\u201c, hvis indholdet er personaliseret. Jeg deaktiverer ogs\u00e5 ETag-headere, hvis load balancere eller proxyer ikke genererer disse v\u00e6rdier konsekvent. P\u00e5 denne m\u00e5de h\u00e5ndh\u00e6ver jeg en klar adf\u00e6rd i browseren og undg\u00e5r <strong>Revalideringer<\/strong> med hvert klik.<\/p>\n\n<pre><code>.\n  ExpiresActive On\n  ExpiresByType image\/jpeg \"adgang plus 1 \u00e5r\"\n  ExpiresByType image\/png \"adgang plus 1 \u00e5r\"\n  ExpiresByType text\/css \"adgang plus 1 m\u00e5ned\"\n  ExpiresByType application\/javascript \"adgang plus 1 m\u00e5ned\"\n.\n\n\n  Header set Cache-Control \"public, max-age=31536000\" \"expr=%{CONTENT_TYPE} =~ m#^(image\/|font\/|application\/javascript)#\"\n  Header set Cache-Control \"no-cache, no-store, must-revalidate\" \"expr=%{REQUEST_URI} =~ m#(wp-admin|wp-login.php)#\"\n  Header uindstillet ETag\n.<\/code><\/pre>\n\n<pre><code># Nginx\nplacering ~* .(jpg|jpeg|png|gif|ico|webp|avif|css|js|woff2?)$ {\n    add_header Cache-Control \"public, max-age=31536000\";\n}\nlocation ~* \/(wp-admin|wp-login.php)$ {\n    add_header Cache-Control \"no-store\";\n}<\/code><\/pre>\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\/wordpress_caching_meeting_5823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Udvidede direktiver om cache-kontrol i hverdagen<\/h2>\n\n<p>Ud over \u201emax-age\u201c og \u201eno-store\u201c sikrer moderne direktiver m\u00e6rkbar stabilitet. \u201eimmutable\u201c signalerer til browseren, at en fil ikke \u00e6ndres, s\u00e5 l\u00e6nge filnavnet forbliver det samme - ideelt til versionerede aktiver. \u201estale-while-revalidate\u201c g\u00f8r det muligt at levere en udl\u00f8bet kopi, mens den opdateres i baggrunden. \u201estale-if-error\u201c holder en kopi klar, hvis Origin kortvarigt returnerer fejl. \u201es-maxage\u201c er rettet mod proxyer\/CDN'er og kan have andre v\u00e6rdier end \u201emax-age\u201c. Ogs\u00e5 vigtigt: \u201epublic\u201c tillader caching i delte proxyer; \u201eprivate\u201c er begr\u00e6nset til browseren. \u201eno-cache\u201c betyder ikke \u201eikke cachelagring\u201c, men \u201ecachelagring tilladt, men revalider f\u00f8r brug\u201c - en afg\u00f8rende forskel fra \u201eno-store\u201c.<\/p>\n\n<pre><code># Apache 2.4-eksempel (cache-aktiver endnu mere robust)\n\n  Header-s\u00e6t Cache-Control \"public, max-age=31536000, immutable, stale-while-revalidate=86400, stale-if-error=259200\" \"expr=%{REQUEST_URI} =~ m#.(css|js|woff2?|png|jpe?g|webp|avif)$#\"\n  Header set Cache-Control \"no-cache, must-revalidate\" \"expr=%{CONTENT_TYPE} =~ m#^text\/html#\"\n.<\/code><\/pre>\n\n<pre><code># Nginx-eksempel (304\/Include-omdirigeringer)\nlocation ~* .(css|js|woff2?|png|jpe?g|webp|avif)$ {\n    add_header Cache-Control \"public, max-age=31536000, immutable, stale-while-revalidate=86400, stale-if-error=259200\" always;\n}\nlocation ~* .html$ {\n    add_header Cache-Control \"no-cache, must-revalidate\" always;\n}<\/code><\/pre>\n\n<h2>Anbefalede cache-varigheder efter filtype<\/h2>\n\n<p>Jeg v\u00e6lger tidspunkterne efter \u00e6ndringsfrekvens, ikke efter vane, fordi <strong>Aktiver<\/strong> \u00e6ldes meget forskelligt. Billeder, logoer og ikoner forbliver normalt opdaterede i lang tid, mens CSS\/JS f\u00e5r hyppigere iterationer. Webfonte \u00e6ndres sj\u00e6ldent, men kr\u00e6ver ensartede CORS-overskrifter. HTML fungerer ofte som en container for dynamisk indhold og kan derfor v\u00e6re kort eller kun revalideret. API'er b\u00f8r have klart definerede regler, s\u00e5 klienter kan arbejde korrekt med <strong>JSON<\/strong> undg\u00e5.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Filtype<\/th>\n      <th>Cache-kontrol-anbefaling<\/th>\n      <th>Hint<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Billeder (jpg\/png\/webp\/avif\/svg)<\/td>\n      <td>offentlig, max-alder=31536000<\/td>\n      <td>Brug \u00e5rlig cache med filversionering<\/td>\n    <\/tr>\n    <tr>\n      <td>CSS\/JS<\/td>\n      <td>offentlig, max-age=2592000<\/td>\n      <td>Tilf\u00f8j version til filnavn for opdateringer<\/td>\n    <\/tr>\n    <tr>\n      <td>Skrifttyper (woff\/woff2)<\/td>\n      <td>offentlig, max-alder=31536000<\/td>\n      <td>Indstil Access-Control-Allow-Origin korrekt<\/td>\n    <\/tr>\n    <tr>\n      <td>HTML (sider)<\/td>\n      <td>no-cache, must-revalidate eller kort max-age<\/td>\n      <td>V\u00e6r meget forsigtig med dynamisk indhold<\/td>\n    <\/tr>\n    <tr>\n      <td>REST API (json)<\/td>\n      <td>privat, max-age=0, must-revalidate<\/td>\n      <td>Differentier efter endepunkt<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Undg\u00e5 konflikter med plugins<\/h2>\n\n<p>Jeg bruger h\u00f8jst <strong>Caching-plugin<\/strong> og tjek, om hostingen allerede specificerer regler p\u00e5 serverniveau. Kombinationer som W3 Total Cache plus WP Super Cache skaber ofte dobbelte direktiver, der oph\u00e6ver hinanden. WP Rocket tilbyder en hurtig ops\u00e6tning, men har brug for klare undtagelser for dynamiske stier og e-handel. Under alle omst\u00e6ndigheder tjekker jeg den genererede .htaccess, n\u00e5r jeg har gemt den, for at finde ulogiske overskrifter. Derefter tester jeg kritiske sider som checkout, login og personaliserede dashboards for at se, om de er korrekte. <strong>Omg\u00e5else<\/strong>.<\/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\/wordpress-browser-caching-fehler-9274.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Caching og cookies: indloggede brugere, WooCommerce, sessioner<\/h2>\n\n<p>HTML for indloggede brugere m\u00e5 ikke gemmes i den offentlige cache. WordPress s\u00e6tter cookies som f.eks. <code>wordpress_logged_in_.<\/code>, WooCommerce suppleret <code>woocommerce_items_in_cart<\/code>, <code>wp_woocommerce_session_.<\/code> og andre. I stedet for over <em>Variabel: Cookie<\/em> Jeg g\u00e5r helt uden om cacher for s\u00e5danne anmodninger. Det holder betalingsprocesserne stabile og de personaliserede omr\u00e5der korrekte. Jeg bruger ogs\u00e5 regler p\u00e5 serversiden, der s\u00e6tter mere restriktive overskrifter, n\u00e5r cookies genkendes.<\/p>\n\n<pre><code># Apache: Genkender cookies og indstiller bypass-overskrifter\n\n  SetEnvIfNoCase Cookie \"wordpress_logged_in_|woocommerce_items_in_cart|wp_woocommerce_session\" has_session\n  Header set Cache-Control \"private, no-store\" env=has_session\n.<\/code><\/pre>\n\n<pre><code># Nginx: Cookie-baseret bypass\nif ($http_cookie ~* \"(wordpress_logged_in|woocommerce_items_in_cart|wp_woocommerce_session)\") {\n    add_header Cache-Control \"private, no-store\" always;\n}<\/code><\/pre>\n\n<p>Mange caching-plugins tilbyder afkrydsningsfelter til dette (WooCommerce\/Cart\/Exclude checkout). Vigtigt: Nonces (<code>_wpnonce<\/code>) i formularer og Heartbeat API genererer hyppige \u00e6ndringer. Jeg s\u00f8rger for, at frontend-HTML med nonces ikke caches permanent eller fungerer via \u201eno-cache, must-revalidate\u201c.<\/p>\n\n<h2>M\u00e5lrettet behandling af HTML: personlig vs. generel<\/h2>\n\n<p>Ikke alle sider er ens. Artikler, landingssider og juridiske sider kan ofte caches med en kort TTL eller revalidering. Arkiver, s\u00f8gesider, dashboards, kontoomr\u00e5der og checkouts forbliver dynamiske. Hvis der er tale om sidecaching, f\u00f8lger jeg f\u00f8lgende praksis: Cach kun offentlig HTML uden cookies, ellers \u201eprivat\u201c eller \u201eno-store\u201c. Hvis du tester mikrocaching (f.eks. 30-60 sekunder for meget bes\u00f8gte, ikke-personaliserede sider), b\u00f8r du definere strenge undtagelser for foresp\u00f8rgselsparametre og sessioner. WordPress har med <code>DONOTCACHEPAGE<\/code> en konstant, som skabeloner kan indstille p\u00e5 vanskelige sider - jeg bruger den konsekvent for at undg\u00e5 fejl.<\/p>\n\n<h2>Kombiner caching p\u00e5 serversiden p\u00e5 en fornuftig m\u00e5de<\/h2>\n\n<p>Browsercaching slutter i klienten, men jeg aflaster ogs\u00e5 serveren med side-, objekt- og opcode-cache for real <strong>Belastningsspidser<\/strong>. Sidecaching leverer statisk HTML, f\u00f8r PHP overhovedet starter. Redis eller Memcached reducerer databaseforesp\u00f8rgsler for gentagne anmodninger og reducerer TTFB m\u00e6rkbart. OPcache leverer pr\u00e6-kompilerede PHP-bytecode-fragmenter og forkorter dermed udf\u00f8relsestiden. I sidste ende er det, der t\u00e6ller, en ren forbindelse mellem servercachen og browsercachen, s\u00e5 det andet bes\u00f8g er mere eller mindre en succes. <strong>\u00f8jeblikkeligt<\/strong> arbejder.<\/p>\n\n<h2>CDN-integration uden overraskelser<\/h2>\n\n<p>CDN'er bruger deres egen TTL-logik og reagerer p\u00e5 \u201es-maxage\u201c. Jeg skelner derfor klart: \u201emax-age\u201c for browsere, \u201es-maxage\u201c for Edge. Hvis implementeringer afventer, udl\u00f8ser jeg en m\u00e5lrettet oprydning i stedet for at \u00f8del\u00e6gge \u201eCache Everything\u201c globalt. Vigtigt: Cach kun HTML p\u00e5 Edge, hvis der ikke er cookies involveret. Ellers skabes der forkerte tilstande, fordi Edge-cachen deler personaliserede svar. For aktiver s\u00e6tter jeg lange TTL'er og stoler p\u00e5 versionering af filnavne. CDN'er kan ignorere foresp\u00f8rgselsstrenge - endnu en grund til at beholde versioner i filnavnet. Header-normalisering (ingen overfl\u00f8dige \u201eVary\u201c-v\u00e6rdier, konsekvent \u201eContent-Type\u201c) forhindrer oppustede cachen\u00f8gler.<\/p>\n\n<h2>Trin for trin: ren installation<\/h2>\n\n<p>Jeg starter med et plugin og aktiverer browsercaching for CSS, JS, billeder og skrifttyper, f\u00f8r jeg aktiverer <strong>.htaccess<\/strong> afslutte. Derefter s\u00e6tter jeg max-age h\u00f8jt for statiske aktiver og forsyner HTML med korte tider eller no-cache-regler. Jeg deaktiverer ETags, hvis flere servere er involveret, og stoler p\u00e5 Last-Modified plus 304. Derefter udl\u00f8ser jeg en preload, s\u00e5 vigtige sider straks er tilg\u00e6ngelige som statiske kopier. Endelig kontrollerer jeg shop-, login- og admin-stier, s\u00e5 der ikke gemmes privat indhold i <strong>buffer<\/strong> land.<\/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\/wordpress-caching-office-2974.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktisk diagnosticering med CLI og header-tjek<\/h2>\n\n<p>DevTools er obligatoriske, men jeg g\u00e5r mere i dybden med CLI-tests. A <code>curl -I<\/code> viser header uden download; med <code>-H<\/code> Jeg simulerer betingelser. For eksempel tjekker jeg, om revalideringer virkelig returnerer 304, om \u201ealder\u201c stiger fra en proxy\/CDN, og om cookies sl\u00e5r caching fra.<\/p>\n\n<pre><code># Vis overskrift\ncurl -I https:\/\/example.com\/style.css\n\nSimuler #-revalidering (If-Modified-Since)\ncurl -I -H \"If-Modified-Since: Tue, 10 Jan 2023 10:00:00 GMT\" https:\/\/example.com\/style.css\n\n#-test med cookie (burde tvinge bypass)\ncurl -I -H \"Cookie: wordpress_logged_in_=1\" https:\/\/example.com\/<\/code><\/pre>\n\n<p>Jeg s\u00f8rger for, at aktiver har en lang \u201ecache control\u201c-v\u00e6rdi, ideelt set \u201eimmutable\u201c. HTML b\u00f8r have \u201eno-cache\u201c eller en kort TTL. Hvis jeg stadig f\u00e5r 200 i stedet for 304, er der ofte omdirigeringer i spil, som ugyldigg\u00f8r ETags\/Last-Modified. Desuden g\u00e6lder \u201eadd_header\u201c i Nginx som standard kun for 200-svar - med \u201ealways\u201c indstiller jeg ogs\u00e5 overskrifterne for 304 og 301\/302.<\/p>\n\n<h2>Test og validering af overskrifter<\/h2>\n\n<p>Jeg \u00e5bner DevTools, genindl\u00e6ser siden \u00e9n gang, t\u00f8mmer cachen og genindl\u00e6ser for at f\u00e5 304 vs. <strong>200<\/strong> for at observere. I netv\u00e6rkspanelet tjekker jeg cachekontrol, alder, ETag\/load-modified og svarst\u00f8rrelser. Hvis der stadig er direkte hits i stedet for revalideringer, tjekker jeg for konflikter med omdirigeringer, cookies eller foresp\u00f8rgselsstrenge. I vanskelige tilf\u00e6lde hj\u00e6lper denne artikel om faldgruber med headers mig: <a href=\"https:\/\/webhosting.de\/da\/http-cache-headers-saboterer-caching-cachefix\/\">Sabotage af cache-header<\/a>. Jeg gentager kontrollen efter hver plugin-opdatering, fordi \u00e6ndringer i reglerne ofte sker lydl\u00f8st. <strong>passere<\/strong>.<\/p>\n\n<h2>Versionering, CDN og cache-busting<\/h2>\n\n<p>Jeg h\u00e6nger den <strong>Version<\/strong> til filnavne (style.23.css i stedet for style.css?ver=23), s\u00e5 browsere bevarer lange cacher og stadig indl\u00e6ser nyt indhold med det samme. Et CDN distribuerer statiske filer globalt, indstiller sine egne TTL'er i edge PoPs og forkorter RTT'erne drastisk. Vigtigt: Cach kun HTML i CDN'et, hvis der ikke er behov for personalisering, ellers vil der blive oprettet forkerte tilstande. Under implementeringen \u00e6ndrer jeg automatisk versionsnummeret, s\u00e5 brugerne aldrig sidder fast med gamle scripts. S\u00e5dan kombinerer jeg h\u00e5rde browser TTL'er med sikker <strong>Cache-brydning<\/strong>.<\/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\/wordpress-browsercache-setup2093.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ren versionering i WordPress-builds<\/h2>\n\n<p>Det mest p\u00e5lidelige er en build-pipeline, der skriver hashes i filnavne (f.eks. <code>app.9f3c.css<\/code>). WordPress indl\u00e6ser derefter pr\u00e6cis denne fil - browsere kan beholde den i et \u00e5r takket v\u00e6re \u201eimmutable\u201c. Hvis filnavne ikke kan \u00e6ndres, indstiller jeg versionsnummeret dynamisk ud fra fildatoen. Dette holder foresp\u00f8rgselsstrengene korrekte og p\u00e5lidelige.<\/p>\n\n<pre><code>\/\/ functions.php (fallback-versionering via filemtime)\nadd_action('wp_enqueue_scripts', function () {\n    $css = get_stylesheet_directory() . '\/dist\/style.css';\n    $ver = file_exists($css) ? filemtime($css) : null;\n    wp_enqueue_style('theme', get_stylesheet_directory_uri() . '\/dist\/style.css', [], $ver);\n});<\/code><\/pre>\n\n<p>Vigtigt: Hvis filnavnet indeholder versioner, kan \u201eimmutable\u201c indstilles. Hvis du kun bruger foresp\u00f8rgselsstrenge, b\u00f8r browsere v\u00e6re i stand til at revalidere, s\u00e5 opdateringer kommer p\u00e5lideligt frem. Jeg s\u00f8rger ogs\u00e5 for, at build-v\u00e6rkt\u00f8jer rydder op i gamle filer, s\u00e5 CDN'er ikke gemmer et un\u00f8digt stort antal varianter.<\/p>\n\n<h2>Cache og indl\u00e6s webfonte korrekt<\/h2>\n\n<p>Webfonte har brug for lange TTL'er, korrekte CORS-headere og valgfri forudindl\u00e6sning, s\u00e5 <strong>Spring i layout<\/strong> vises ikke. Jeg placerer woff2-filer p\u00e5 det samme dom\u00e6ne eller indstiller Access-Control-Allow-Origin rent. Derudover skal du definere font-display: swap, s\u00e5 teksten forbliver synlig med det samme, mens skrifttypen indl\u00e6ses. Hvis du vil optimere indl\u00e6sningstiden for dine skrifttyper, kan du finde nyttige tips her: <a href=\"https:\/\/webhosting.de\/da\/wordpress-webfonts-optimering-af-indlaesningstid-serverperf\/\">Indl\u00e6s webfonte hurtigere<\/a>. Med rene cache-headere og en forudg\u00e5ende forbindelse til CDN'er forkorter jeg FOUT\/FOIT m\u00e6rkbart og sikrer konsekvent <strong>Rendering<\/strong>-Resultater.<\/p>\n\n<h2>Korrekt indstilling af skrifttyper, CORS og Vary<\/h2>\n\n<p>Skrifttyper fra en anden oprindelse kr\u00e6ver CORS. Jeg indstiller <code>Adgangskontrol-Allow-Origin<\/code> (f.eks. til dit eget dom\u00e6ne eller \u201e*\u201c for virkelig offentlig) og undg\u00e5 en un\u00f8dvendig <code>Varierer: Oprindelse<\/code>, som puster cachen\u00f8gler op. Anbefales til skrifttyper: <code>offentlig, max-age=31536000, uforanderlig<\/code>. Preload forbedrer First Paint, men \u00e6ndrer ikke TTL - preload og hard caching supplerer hinanden. Jeg glemmer heller ikke, at komprimeret levering (<code>br<\/code>\/<code>gzip<\/code>) a <code>Vary: Accept-kodning<\/code> er n\u00f8dvendig for, at proxyer kan adskilles korrekt.<\/p>\n\n<h2>Typiske fejlm\u00f8nstre og hurtige l\u00f8sninger<\/h2>\n\n<p>Hvis der vises gammel kode efter en opdatering, vil <strong>Versionering<\/strong> p\u00e5 filnavnet. Hvis browseren genindl\u00e6ses helt hver gang, indeholder headers modstridende instruktioner, eller proxyer fjerner dem undervejs. Hvis en checkout annulleres, cacher webstedet sandsynligvis sider p\u00e5 sessionssiden eller API-svar. Hvis admin-stier glider ind i cachen, mangler der eksklusioner for wp-admin og login, eller et plugin cacher globalt. Jeg l\u00f8ser dette ved at deaktivere trin for trin, konsolidere overskrifter, udelukke kritiske stier og til sidst effekten med 304-status <strong>bekr\u00e6fte<\/strong>.<\/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\/wordpress-caching-fehler-9834.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ofte oversete detaljer, der g\u00f8r en stor forskel<\/h2>\n\n<ul>\n  <li><strong>Nginx add_header<\/strong> g\u00e6lder ikke for 304\/redirects uden \u201ealways\u201c - s\u00e5 mangler der cache-headers til validering. Jeg indstiller konsekvent \u201ealtid\u201c.<\/li>\n  <li><strong>Udl\u00f8ber vs. cache-kontrol:<\/strong> \u201eCache-Control\u201c har prioritet, \u201eExpires\u201c fungerer som en fallback for gamle klienter. Undg\u00e5 dobbelt, modstridende information.<\/li>\n  <li><strong>ETag i ops\u00e6tninger med flere servere:<\/strong> Inkonsistente ETags \u00f8del\u00e6gger 304. Jeg deaktiverer ETags eller bruger svage validatorer og stoler p\u00e5 \u201eLast-Modified\u201c.<\/li>\n  <li><strong>Varier til et minimum:<\/strong> \u201eVary: Accept-Encoding\u201c er obligatorisk for komprimering, \u201eVary: Cookie\u201c opbl\u00e6ser edge caches - bedre at omg\u00e5 cookie-baseret.<\/li>\n  <li><strong>SVG og MIME-type:<\/strong> Korrekt <code>image\/svg+xml<\/code> s\u00e6t, giv lang TTL og overvej inline SVG'er til kritiske ikoner.<\/li>\n  <li><strong>Undg\u00e5 omdirigeringsk\u00e6der:<\/strong> Hver 301\/302 kan miste validatorer og fremtvinge 200 - rene URL'er uden kaskader.<\/li>\n  <li><strong>Brug prioritet\/preload p\u00e5 en m\u00e5lrettet m\u00e5de:<\/strong> <code>fetchpriority=\"h\u00f8j\"<\/code> eller forudindl\u00e6sning af kritiske aktiver fremskynder det f\u00f8rste opkald; caching er effektivt for tilbagevendende brugere.<\/li>\n  <li><strong>G\u00f8r forskel p\u00e5 REST-API:<\/strong> Offentlige, sj\u00e6ldent skiftende JSON'er kan caches kortvarigt; slutpunkter med tokens\/cookies er strengt \u201eprivate\u201c.<\/li>\n<\/ul>\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Jeg er afh\u00e6ngig af klare <strong>Regler<\/strong>lange TTL'er for aktiver, korte eller revaliderede HTML-svar, versionering og et enkelt cache-plugin. Derefter kombinerer jeg browsercache med side-, objekt- og opcode-cache for at reducere serverbelastningen. Jeg tjekker DevTools, kigger efter 304, tjekker headers og eliminerer konflikter med omdirigeringer eller cookies. Til den praktiske test sammenligner jeg m\u00e5linger p\u00e5 det f\u00f8rste og de gentagne kald og fokuserer p\u00e5 m\u00e6rkbare forbedringer. Hvis du f\u00f8lger disse trin, kan du bringe WordPress op p\u00e5 et p\u00e5lideligt niveau for browsercaching. <strong>Hastighed<\/strong> og g\u00f8r b\u00e5de brugere og s\u00f8gemaskiner glade.<\/p>","protected":false},"excerpt":{"rendered":"<p>WordPress og browsercaching er ofte konfigureret forkert. L\u00e6r, hvordan du indstiller wp-cacheheaders korrekt for at f\u00e5 optimal wordpress-ydelse.<\/p>","protected":false},"author":1,"featured_media":17051,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[733],"tags":[],"class_list":["post-17058","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress"],"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":"1121","_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":null,"_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":"WordPress Browser Caching","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":"17051","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/17058","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=17058"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/17058\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/17051"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=17058"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=17058"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=17058"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}