{"id":20746,"date":"2026-08-17T18:25:40","date_gmt":"2026-08-17T16:25:40","guid":{"rendered":"https:\/\/webhosting.de\/http-cache-control-header-richtig-einsetzen-web-optimierung\/"},"modified":"2026-08-17T18:25:40","modified_gmt":"2026-08-17T16:25:40","slug":"korrekt-brug-af-http-cache-control-headeren-weboptimering","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/http-cache-control-header-richtig-einsetzen-web-optimierung\/","title":{"rendered":"Korrekt brug af HTTP Cache-Control-headeren til effektiv weboptimering"},"content":{"rendered":"<p>Jeg viser dig, hvordan du bruger HTTP-headeren <strong>Cache-kontrol<\/strong> anvender m\u00e5lrettet for at reducere indl\u00e6sningstider, spare p\u00e5 foresp\u00f8rgsler og styre browser-cacher effektivt. Du f\u00e5r klare retningslinjer, fornuftige kombinationer og praktiske indstillinger til HTML, CSS, JS, billeder og API\u2019er \u2013 uden g\u00e6tterier, men med <strong>konkrete<\/strong> H\u00e5ndgreb.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<p>F\u00f8lgende centrale aspekter vil helt sikkert f\u00f8re dig til en hurtig og <strong>p\u00e5lidelig<\/strong> Cache-strategi.<\/p>\n<ul>\n  <li><strong>max-alder<\/strong> som tidsindstilling: styrer holdbarheden i sekunder<\/li>\n  <li><strong>offentlig\/privat<\/strong>: fastl\u00e6gger, hvem der m\u00e5 gemme i cachen<\/li>\n  <li><strong>no-cache<\/strong> vs. <strong>ingen opbevaring<\/strong>: genindf\u00f8re i stedet for at forbyde<\/li>\n  <li><strong>ETag<\/strong> og <strong>Sidst \u00e6ndret<\/strong>: Betingede hentninger sparer data<\/li>\n  <li><strong>Versionering<\/strong> + <strong>uforanderlig<\/strong>: lange cacher uden gamle spor<\/li>\n<\/ul>\n\n<h2>Grundl\u00e6ggende: Hvad g\u00f8r Cache-Control-headeren?<\/h2>\n<p>Hovedet indeholder instruktioner, der angiver, om, hvor l\u00e6nge og af hvem et svar i <strong>Cache<\/strong> m\u00e5 ligge. Her skelner jeg mellem klientcacher i browseren og f\u00e6lles cacher som proxyservere eller CDN\u2019er, der ofte betjener flere brugere og dermed yderligere <strong>Effektivitet<\/strong> . Mens den for\u00e6ldede Expires-header bruger en dato, anvender jeg med Cache-Control relative tidsintervaller via max-age, hvilket er mindre fejlbeh\u00e6ftet. P\u00e5 den m\u00e5de bestemmer jeg, hvor l\u00e6nge en ressource forbliver \u201efrisk\u201c, og om den skal revalideres f\u00f8r brug. P\u00e5 den m\u00e5de holder jeg muligheden \u00e5ben for at kontrollere dynamisk indhold og opbevare statiske filer lokalt i meget lang tid.<\/p>\n<p>Cache-Control g\u00e6lder b\u00e5de i svar og i anmodninger, hvilket er nyttigt for mig i forbindelse med revalidering, f.eks. sammen med ETag eller Last-Modified for <strong>Betinget<\/strong> Anmodninger. Jeg indstiller for eksempel aggressive v\u00e6rdier for u\u00e6ndrede ressourcer og forsigtige regler for HTML. Denne opdeling sikrer, at efterf\u00f8lgende anmodninger s\u00e5 vidt muligt hentes fra browserens cache og dermed <strong>Serverbelastning<\/strong> falder. Det er vigtigt med et velplanlagt samspil, s\u00e5 jeg ikke utilsigtet blokerer ressourcer eller lader dem udl\u00f8be for tidligt. Den, der f\u00f8lger disse grundprincipper, l\u00e6gger grundlaget for korte indl\u00e6sningstider og klare regler for cache-adf\u00e6rd.<\/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\/08\/weboptimierung-cachecontrol-4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Vigtige retningslinjer forklaret p\u00e5 en forst\u00e5elig m\u00e5de<\/h2>\n<p>Med <strong>max-alder<\/strong> Jeg fasts\u00e6tter en ressources levetid i sekunder, regnet fra leveringstidspunktet. For billeder, CSS, JS og skrifttyper v\u00e6lger jeg ofte 31536000 (et \u00e5r), s\u00e5 gentagne bes\u00f8g n\u00e6sten udelukkende bruger det, der er gemt lokalt. HTML-sider indstiller jeg til en kortere gyldighedsperiode, f.eks. 300 sekunder, eller kombinerer dem med revalidering, s\u00e5 \u00e6ndringer hurtigt bliver synlige. En lang gyldighedsperiode uden filversionering f\u00f8rer let til gamle versioner i cachen, derfor varierer jeg filnavnene ved hver udgivelse. P\u00e5 den m\u00e5de kombinerer jeg stram aktualitet med <strong>h\u00f8j<\/strong> Cache-hitprocent.<\/p>\n<p>Direktiverne <strong>offentlig<\/strong> og <strong>privat<\/strong> bestemme, hvem der m\u00e5 cache. Jeg tildeler indstillingen \u00bbPublic\u00ab til indhold uden personalisering, s\u00e5 ogs\u00e5 proxyservere og CDN\u2019er kan cache det. Indstillingen \u00bbPrivate\u00ab tildeler jeg, n\u00e5r det kun er brugerens browser, der skal gemme en kopi, f.eks. p\u00e5 kontosider. P\u00e5 den m\u00e5de forhindrer jeg, at personlige data ender i f\u00e6lles cacher og der <strong>g\u00e5 galt<\/strong>. Denne skelnen sparer besv\u00e6r og beskytter f\u00f8lsomme oplysninger.<\/p>\n<p><strong>no-cache<\/strong> bliver ofte misforst\u00e5et: Det forbyder ikke cachelagring, men kr\u00e6ver en revalidering hos serveren, f\u00f8r indholdet kan bruges igen. Det passer til indhold, der \u00e6ndres regelm\u00e6ssigt, uden at det skal indl\u00e6ses helt forfra ved hvert bes\u00f8g. Med ETag eller Last-Modified gemmer klienten data lokalt og sp\u00f8rger blot, om de stadig er aktuelle. P\u00e5 den m\u00e5de undg\u00e5r jeg un\u00f8dvendige bytes og bevarer alligevel <strong>Indhold<\/strong> frisk. For meget f\u00f8lsomme data er no-cache dog stadig for lempelig.<\/p>\n<p><strong>ingen opbevaring<\/strong> er den strengeste foranstaltning, da den forbyder enhver lagring i browseren og i proxyservere. Jeg bruger det til login-sider, betalingsprocesser eller dokumenter med fortrolige oplysninger. P\u00e5 den m\u00e5de ligger der ingen kopier i midlertidige mapper, som ved et uheld kunne falde i de forkerte h\u00e6nder. N\u00e5r jeg bruger no-store, kombinerer jeg det ofte med max-age=0 for at forhindre enhver genbrug <strong>at udelukke<\/strong>. Her g\u00e5r sikkerhed forud for ydeevne.<\/p>\n<p><strong>skal-revalidere<\/strong> tvinger en foresp\u00f8rgsel til serveren, s\u00e5 snart tidsfristen er udl\u00f8bet. Hvis serveren g\u00e5r ned, m\u00e5 cachen ikke blot forts\u00e6tte med at levere ressourcen. Denne direktiv er velegnet til omr\u00e5der, hvor konsistens er vigtigere end en fleksibel nedbrudsstrategi. Jeg anvender den, n\u00e5r for\u00e6ldede data ville f\u00f8re til forkerte beslutninger. Reglen skaber klare <strong>Forpligtelse<\/strong> under afviklingen.<\/p>\n\n<h2>Udvidede retningslinjer for delte cacher og driftssikkerhed<\/h2>\n<p>Ud over de grundl\u00e6ggende indstillinger bruger jeg <strong>s-maxage<\/strong>, <strong>stale-while-revalidate<\/strong> og <strong>stale-if-fejl<\/strong>, for m\u00e5lrettet at styre proxyservere\/CDN\u2019er og sikre en j\u00e6vn brugeroplevelse for brugerne, selv i tilf\u00e6lde af forstyrrelser. <em>s-maxage<\/em> indstiller en egen TTL kun for f\u00e6lles cacher (browsere ignorerer dem). P\u00e5 den m\u00e5de kan jeg f.eks. holde cachen kort i browseren (max-age=600), men cache den l\u00e6ngere i Edge (s-maxage=86400). <em>stale-while-revalidate<\/em> g\u00f8r det muligt for cacher at forts\u00e6tte med at levere for\u00e6ldet indhold i et bestemt tidsrum, mens opdateringen allerede er i gang i baggrunden. <em>stale-if-fejl<\/em> tr\u00e6der i kraft i tilf\u00e6lde af fejl (f.eks. 500\/timeout) og sikrer en god brugeroplevelse ved at vise en lidt \u00e6ldre version i stedet for at vise en direkte fejlmeddelelse.<\/p>\n<p>Et praktisk eksempel p\u00e5 offentlige API-svar eller JSON-sitemaps, der sj\u00e6ldent \u00e6ndres, ser s\u00e5ledes ud: <code>Cache-Control: public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600<\/code>. P\u00e5 den m\u00e5de forbliver browsere relativt opdaterede, CDN'er er effektive, og brugerne m\u00e6rker hverken korte nedbrud eller forsinkede genvalideringer. Kritiske eller personaliserede omr\u00e5der lader jeg bevidst v\u00e6re uber\u00f8rte af s\u00e5danne bl\u00f8de retningslinjer.<\/p>\n\n<h2>Samspil med Expires, ETag og Last-Modified<\/h2>\n<p>Jeg bruger <strong>Udl\u00f8ber<\/strong> h\u00f8jst som en n\u00f8dl\u00f8sning, da Cache-Control kan styres mere pr\u00e6cist og har forrang, hvis begge er angivet. Med ETag leverer jeg et entydigt fingeraftryk af ressourcen, s\u00e5 browseren via If-None-Match kan igangs\u00e6tte en hurtig revalidering. Last-Modified angiver dato og klokkesl\u00e6t for den seneste \u00e6ndring og fungerer sammen med If-Modified-Since. Begge metoder sparer b\u00e5ndbredde, fordi serveren kun returnerer status 304, hvis indholdet er u\u00e6ndret. Samspillet holder data t\u00e6t p\u00e5 brugeren og reducerer <strong>Rundrejser<\/strong>.<\/p>\n<p>Skal jeg k\u00f8be den? <a href=\"https:\/\/webhosting.de\/da\/http-conditional-requests-cache-validation-optimisation-package\/\">Betingede anmodninger<\/a>, falder omkostningerne pr. sidevisning markant, uden at jeg blokerer for nyt indhold. Denne teknik supplerer korte max-age-v\u00e6rdier i HTML og sikrer, at siderne vises i deres aktuelle version. N\u00e5r det g\u00e6lder ressourcer med versionsstyring, foretr\u00e6kker jeg derimod at bruge lange gyldighedsperioder og undg\u00e5r un\u00f8dvendige valideringer. P\u00e5 den m\u00e5de aflaster jeg <strong>Server<\/strong> og fremskynder opf\u00f8lgende bes\u00f8g m\u00e6rkbart. Alt i alt skaber det en str\u00f8mlinet datavej med klare regler.<\/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\/08\/WebOptimizationCacheControl1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>ETag\/Last-Modified i praksis: st\u00e6rk, svag og skalerbar<\/h2>\n<p>I distribuerede ops\u00e6tninger s\u00f8rger jeg for, at ETags <em>konsekvent<\/em> beregnes p\u00e5 tv\u00e6rs af alle instanser. Filbaserede ETags, der inkluderer inoder, medf\u00f8rer un\u00f8dvendige fejl i klynger. I Apache indstiller jeg derfor bevidst ETag-beregningen s\u00e5ledes:<\/p>\n<pre><code># Apache: konsistente ETags for statiske filer\nFileETag MTime Size\n# Valgfrit: Fjern standard-ETag og indstil egen logik\n\n  #Header unset ETag\n<\/code><\/pre>\n<p>Med Nginx er det ofte nok <code>etag er aktiveret;<\/code> til statiske filer. Til <em>dynamisk<\/em> Jeg genererer selv ETags for svarene \u2013 helst som en hash af svarets br\u00f8dtekst. Hvis jeg har brug for en vis tolerance over for mindre \u00e6ndringer (f.eks. formaterede tidsstempler), bruger jeg <strong>svage ETags<\/strong> (<code>W\/\"...\"<\/code>), som g\u00f8r det muligt at genkende semantisk identisk indhold som u\u00e6ndret p\u00e5 trods af forskelle i bytes. Som fallback bruger jeg Last-Modified, f.eks. til opdateringstidspunktet for dataposten. Vigtigt: ETag og Last-Modified <em>p\u00e5 samme tid<\/em> Det skader ikke at tilbyde det \u2013 klienten v\u00e6lger selv, hvad den underst\u00f8tter.<\/p>\n\n<h2>Brug Vary korrekt: Personalisering uden cache-kaos<\/h2>\n<p><strong>Varierer<\/strong> bestemmer, hvilke request-headere der indg\u00e5r i cache-n\u00f8glen. Jeg holder bevidst Vary kort: <em>Accept-Encoding<\/em> er standard (Gzip\/Brotli), <em>Accept-sprog<\/em> kun hvis jeg giver sprogspecifikke svar. Fra <em>Vary: User-Agent<\/em> Det frar\u00e5der jeg, fordi det f\u00e5r cachen til at vokse eksplosivt. Hvis indholdet afh\u00e6nger af cookies, foretr\u00e6kker jeg snarere <strong>privat<\/strong> eller <strong>ingen opbevaring<\/strong>, i stedet for at vedligeholde omfattende Vary-regler. For aktiver fjerner jeg om muligt overfl\u00f8dige cookies, s\u00e5 <strong>offentlig<\/strong>-Caching ved kanten tr\u00e6der i kraft. Hvis der anvendes API-godkendelse via header, kan <em>Vary: Autorisation<\/em> forhindre, at delte cacher blander svar fra forskellige brugere \u2013 men ofte er det dog s\u00e5dan, at <strong>privat<\/strong> det bedre og mere overskuelige valg.<\/p>\n<p>Jeg tjekker i DevTools, om Vary-headeren bliver sat utilsigtet (f.eks. af middleware), da en \u201ebred\u201c Vary-header reducerer hitraten markant. F\u00e5, bevidst udvalgte headere holder cachen overskuelig og <strong>effektiv<\/strong>.<\/p>\n\n<h2>Strategier efter indholdstype<\/h2>\n<p>Jeg skelner strengt mellem statisk og dynamisk indhold, s\u00e5 jeg kan udnytte fordelene ved begge dele. Statiske ressourcer f\u00e5r lange levetider og tydelig genkendelighed via versionerede filnavne. HTML og personligt indhold behandler jeg mere tilbageholdende, s\u00e5 \u00e6ndringer hurtigt bliver tilg\u00e6ngelige, og ingen data ender i forkerte cacher. API\u2019er differentierer jeg efter \u00e6ndringsfrekvens og informationernes f\u00f8lsomhed. Denne differentiering medf\u00f8rer <strong>Hastighed<\/strong> uden risiko for fortroligheden og <strong>Korrekthed<\/strong>.<\/p>\n<p>Den f\u00f8lgende tabel opsummerer praktisk anvendelige indstillinger og viser fordelene p\u00e5 et \u00f8jeblik.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Ressource-type<\/th>\n      <th>Eksempel p\u00e5 overskrift<\/th>\n      <th>Hvorfor?<\/th>\n      <th>Hint<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>CSS\/JS\/Billeder\/Skrifttyper<\/td>\n      <td>Cache-kontrol: offentlig, max-age=31536000, uforanderlig<\/td>\n      <td>Langvarig brug af <strong>Browser-cache<\/strong>, f\u00e6rre anmodninger<\/td>\n      <td>Versionsnummerering af filnavne for et overskueligt <strong>Rullende<\/strong> Opdatering<\/td>\n    <\/tr>\n    <tr>\n      <td>HTML ikke tilpasset<\/td>\n      <td>Cache-Control: no-cache, must-revalidate (eller max-age=300)<\/td>\n      <td>Aktualiteten er fortsat h\u00f8j, datam\u00e6ngden er fortsat lille<\/td>\n      <td>Med ETag\/Last-Modified for nem <strong>Revalidering<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Personlig HTML<\/td>\n      <td>Cache-Control: private, no-cache, must-revalidate<\/td>\n      <td>Ingen lagring i f\u00e6lles cacher<\/td>\n      <td>Beskytte sessionsdata og <strong>L\u00e6kager<\/strong> Undg\u00e5 at<\/td>\n    <\/tr>\n    <tr>\n      <td>API\u2019er, der er statiske \/ sj\u00e6ldent \u00e6ndres<\/td>\n      <td>Cache-Control: public, max-age=3600<\/td>\n      <td>H\u00f8j succesrate hos mange <strong>Klienter<\/strong><\/td>\n      <td>V\u00e6r fleksibel i forbindelse med hyppige implementeringer<\/td>\n    <\/tr>\n    <tr>\n      <td>API'er er meget dynamiske \/ f\u00f8lsomme<\/td>\n      <td>Cache-Control: no-store, max-age=0<\/td>\n      <td>Ingen lagring af f\u00f8lsomme data<\/td>\n      <td>Direkte <strong>Aktualitet<\/strong> i stedet for risiko<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>For billedgallerier, store JS-bundles eller webfonts betaler lange \u00bbmax-age\u00ab-v\u00e6rdier sig hurtigt. Jeg holder \u00f8je med versionsstrenge i filnavnene, s\u00e5 brugerne aldrig ser for\u00e6ldede bundles. HTML-koden holdes kort og bruger revalidering, s\u00e5 selv sm\u00e5 rettelser i tekster eller priser hurtigt kommer online. API'er f\u00e5r deres regler afh\u00e6ngigt af brugerprofil og behov for \u00e6ndringer. Denne kombination sikrer vedvarende <strong>flotte<\/strong> Sidevisninger og besparelser <strong>B\u00e5ndbredde<\/strong>.<\/p>\n\n<h2>SPA vs. MPA: Kort HTML-indeks, lange ressourcer<\/h2>\n<p>N\u00e5r det g\u00e6lder single-page-apps, mener jeg, at <em>Indeks-HTML<\/em> s\u00e6rligt kortvarig (f.eks. <code>no-cache, must-revalidate<\/code> eller <code>max-age=60<\/code>), da den styrer, hvilken version af bundlerne der indl\u00e6ses. Alle kompilerede chunks, skrifttyper og billeder er derimod strengt versionsstyrede og f\u00e5r <code>offentlig, max-age=31536000, uforanderlig<\/code>. P\u00e5 den m\u00e5de sikrer jeg, at en ny udgave med opdateret indeks-HTML straks henviser til de korrekte, nye filnavne, mens eksisterende brugere <em>store<\/em> Hente ressourcer fra den lokale cache.<\/p>\n<p>Query-strenge som cache-busting (<code>?v=123<\/code>) bruger jeg kun der, hvor filnavne ikke let kan \u00e6ndres. Det er bedre at bruge entydige filnavne (hashes), fordi de opdeler cachen mere entydigt og skaber f\u00e6rre s\u00e6rlige tilf\u00e6lde.<\/p>\n\n<h2>Serverkonfiguration: Apache og Nginx<\/h2>\n<p>I Apache inds\u00e6tter jeg som regel headerne i <strong>.htaccess<\/strong>, forudsat at modulet mod_headers er aktivt. Til statiske ressourcer tildeler jeg en lang gyldighedsperiode, mens HTML behandles strengere. I Nginx g\u00f8r jeg dette i location-blokke, ofte sammen med expires-direktivet som en sikkerhedsl\u00f8sning. Jeg tester hver \u00e6ndring med DevTools i fanen \u00bbNetv\u00e6rk\u00ab, s\u00e5 jeg kan se de reelle header-v\u00e6rdier. P\u00e5 den m\u00e5de undg\u00e5r jeg fejlagtige regler, der ellers kan medf\u00f8re dyre <strong>Forkerte foresp\u00f8rgsler<\/strong> producerer.<\/p>\n<pre><code># Apache (.htaccess)\n\n  \n    Header set Cache-Control \"public, max-age=31536000, immutable\"\n  \n\n  \n    Header set Cache-Control \"no-cache, must-revalidate\"\n<\/code><\/pre>\n<pre><code># Nginx (server-blok)\nlocation ~* \\.(jpg|jpeg|png|gif|css|js|woff2?)$ {\n    expires 365d;\n    add_header Cache-Control \"public, immutable\";\n}\n\nlocation ~* \\.(html)$ {\n    add_header Cache-Control \"no-cache, must-revalidate\";\n}\n<\/code><\/pre>\n<p>Jeg s\u00f8rger for, at der ikke er nogen konkurrerende regler i upstream-tjenester, der modvirker disse headere. Et upstream-CDN m\u00e5 for eksempel indstille sine egne TTL\u2019er, hvilket jeg bevidst skal styre. Hvis alle niveauer stemmer overens, forbliver ressourcerne p\u00e5lidelige <strong>kan findes<\/strong> og konsekvent. Hvis man her tjekker omhyggeligt, undg\u00e5r man langvarige fejlfindingssessioner. Sm\u00e5 tjek sparer meget senere <strong>Tid<\/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\/08\/futuristic-web-optimization-7643.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>CDN og proxy i praksis: Konfiguration af s-maxage og Stale-strategier<\/h2>\n<p>For Edge-caches tilf\u00f8jer jeg f\u00f8lgende til serverkonfigurationen: <em>s-maxage<\/em> samt Stale-direktiver. Eksempel fra Apache:<\/p>\n<pre><code># Apache: CDN-optimerede regler\n\n  \n    Header set Cache-Control \"public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600\"\n<\/code><\/pre>\n<p>Og i Nginx:<\/p>\n<pre><code># Nginx: Optimering af delt cache\nlocation ~* \\.(json|xml|map)$ {\n    add_header Cache-Control \"public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600\";\n}\n<\/code><\/pre>\n<p>Mange CDN\u2019er overholder disse direktiver direkte. Hvis dit edge-lag forventer egne headere (f.eks. surrogate-headere), afspejler jeg logikken der og holder browser- og delt cache-strategi klart adskilt. Takket v\u00e6re versionering har jeg sj\u00e6ldent brug for rensninger; hvis det alligevel sker, planl\u00e6gger jeg dem som et m\u00e5lrettet, lille indgreb.<\/p>\n\n<h2>S\u00e6rlige tilf\u00e6lde: Omdirigeringer, fejlsider og formularworkflows<\/h2>\n<p><strong>Omdirigeringer:<\/strong> 301-svar kan if\u00f8lge specifikationen caches. N\u00e5r jeg indstiller midlertidige omdirigeringer (302\/307), angiver jeg klare TTL-v\u00e6rdier eller indstiller bevidst <code>ingen opbevaring<\/code>, s\u00e5 intet bliver fastlagt. Permanente 301-omdirigeringer m\u00e5 have en moderat TTL \u2013 \u00e6ndringer er i s\u00e5 fald et bevidst og koordineret skridt.<\/p>\n<p><strong>Fejlsider:<\/strong> 404\/410-svar kan caches kortvarigt (f.eks. <code>max-age=60<\/code>), for at mindske bot-belastningen. Ved 500\u2019erne har jeg, afh\u00e6ngigt af omgivelserne, <code>stale-if-fejl<\/code> aktiv, s\u00e5 brugerne hellere ser en \u00e6ldre, velfungerende side end en fejlmeddelelse.<\/p>\n<p><strong>POST\/Download:<\/strong> Svar p\u00e5 POST-anmodninger caches som regel ikke normalt i browseren. Ved fileksport med personoplysninger (f.eks. regninger) indstiller jeg konsekvent <code>ingen opbevaring<\/code> plus sikker levering (f.eks. Content-Disposition), s\u00e5 intet ved en fejltagelse gemmes permanent. Ikke-personlige, store downloads (f.eks. udgivelser) kan derimod med fordel benytte offentlige cacher i l\u00e6ngere tid.<\/p>\n\n<h2>Undg\u00e5 typiske fejl<\/h2>\n<p>Mange forveksler <strong>no-cache<\/strong> med \u201eslet ingen cache\u201c, hvilket medf\u00f8rer un\u00f8dvendig belastning. Som det fremg\u00e5r, tillader \u00bbno-cache\u00ab cachelagring, men kr\u00e6ver revalidering. En anden klassiker: lange max-age-v\u00e6rdier uden versionsstyring i CSS eller JS, hvilket fastholder for\u00e6ldede filer. Manglende adskillelse mellem HTML og statiske ressourcer g\u00e5r ud over hastigheden, fordi HTML sj\u00e6ldnere m\u00e5 caches aggressivt. Den, der ignorerer dette, bremser <strong>Brugeroplevelse<\/strong> fra.<\/p>\n<p>Konflikter mellem server, CDN og applikation underminerer caching-effekterne uden at man l\u00e6gger m\u00e6rke til det. Kontroller derfor overskrivninger og mellemliggende lag, hvis headere \u00e6ndrer sig \u201esom ved et trylleslag\u201c. Her kan det v\u00e6re en hj\u00e6lp at se n\u00e6rmere p\u00e5 logikken og svark\u00e6den for at afsl\u00f8re forkerte prioriteter. En kortfattet tjekliste og typiske faldgruber omkring <a href=\"https:\/\/webhosting.de\/da\/http-cache-headers-saboterer-caching-cachefix\/\">Sabotage af cache-header<\/a> g\u00f8r kontrollen lettere. Klare prioriteter forhindrer <strong>Bivirkninger<\/strong> ved implementeringer.<\/p>\n\n<h2>G\u00f8re pr\u00e6stationsgevinster m\u00e5lbare<\/h2>\n<p>Jeg vurderer virkningerne af Cache-Control ved hj\u00e6lp af m\u00e5lepunkter som TTFB, LCP og antallet af <strong>Foresp\u00f8rgsler<\/strong> pr. sidevisning. Et kig i DevTools viser mig, om filer kommer \u201efra diskcachen\u201c eller \u201efra hukommelsescachen\u201c. Lighthouse, WebPageTest og lignende v\u00e6rkt\u00f8jer giver en indikation af, om browser-caching fungerer konsekvent. Jeg m\u00e5ler f\u00f8r og efter en \u00e6ndring, s\u00e5 jeg tydeligt kan se reelle forbedringer. Denne disciplin sikrer optimeringer <strong>forst\u00e5elig<\/strong> og m\u00e5lrettet.<\/p>\n<p>Store billeder, webfonts og bundles, der ikke l\u00e6ngere indl\u00e6ses ved efterf\u00f8lgende bes\u00f8g, har en s\u00e6rlig stor effekt. HTML forbliver t\u00e6t p\u00e5 serveren, s\u00e5 brugerne hurtigt f\u00e5r adgang til nyt indhold. API\u2019er drager m\u00e6rkbar fordel af, at hyppigt anvendte ruter har en moderat TTL. Resultaterne viser sig i form af kortere indl\u00e6sningstider, mindre datatrafik og en mere j\u00e6vn serverudnyttelse. Den, der konsekvent kontrollerer dette, sparer p\u00e5 lang sigt <strong>Ressourcer<\/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\/08\/WebOptimierung4102.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Service Worker og HTTP-cache: De m\u00e5 ikke modarbejde hinanden<\/h2>\n<p>Hvis jeg bruger en Service Worker, skal dens strategi stemme overens med mine HTTP-headere. Til statiske, versionerede ressourcer er \u201ecache-first\u201c med lang TTL og <em>uforanderlig<\/em> Fremragende. Til HTML eller API-data, der \u00e6ndrer sig ofte, foretr\u00e6kker jeg \u201enetwork-first\u201c eller \u201estale-while-revalidate\u201c, s\u00e5 brugerne hurtigt f\u00e5r svar, og opdateringerne kommer hurtigt igennem. Vigtigt: Service Workeren b\u00f8r respektere revalideringer (videreformidle If-None-Match\/If-Modified-Since) i stedet for kunstigt at fastholde indholdet.<\/p>\n<p>Jeg skelner desuden klart mellem de to: HTTP-cachen m\u00e5 gerne overtage en stor del af arbejdet; service workeren supplerer denne funktionalitet, den erstatter den ikke. P\u00e5 den m\u00e5de forbliver fejlfinding og drift overskuelige.<\/p>\n\n<h2>Forst\u00e5else af direktiver p\u00e5 anmodningssiden<\/h2>\n<p>Ogs\u00e5 anmodninger kan styre caching. <code>Cache-Control: no-cache<\/code> p\u00e5 <em>Anmodning<\/em> tvinger en genvalidering p\u00e5 serveren, <code>max-age=0<\/code> er det p\u00e5 samme m\u00e5de. <code>ingen opbevaring<\/code> I anmodningen forbydes lagring af svaret i k\u00e6den. I tilf\u00e6lde, hvor der er tale om offline-brug, kan <code>kun hvis det er gemt i cachen<\/code> v\u00e6re nyttigt: Klienten accepterer da kun svar fra cachen. Denne mekanisme er nyttig i apps, der skal levere en bestemt brugeroplevelse, selv n\u00e5r forbindelsen er d\u00e5rlig.<\/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\/08\/WebOptimization_9254.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gode r\u00e5d til din arbejdsgang<\/h2>\n<p>Jeg starter med at lave en statusopg\u00f8relse: Hvilke filtyper findes der, hvilke er personlige, og hvilke \u00e6ndres sj\u00e6ldent? Derefter fordeler jeg reglerne differentieret, s\u00e5 aktiverne forbliver l\u00e6nge i <strong>Cache<\/strong> forbliver, og HTML\u2019en forbliver opdateret. Versionsstrenge i filnavnet eliminerer risikoen for for\u00e6ldede pakker og muligg\u00f8r aggressive k\u00f8rselstider. I regelm\u00e6ssige vedligeholdelsesvinduer tjekker jeg headere og hitprocenter, s\u00e5 jeg kan opdage tendenser tidligt. Denne rutine holder hjemmesiden <strong>performant<\/strong> og forudsigelig.<\/p>\n<p>Jeg dokumenterer konfigurationer kort og klart, s\u00e5 fremtidige \u00e6ndringer ikke ved et uheld \u00f8del\u00e6gger noget. Deployment-scripts opdaterer filernes hashes automatisk, s\u00e5 jeg ikke glemmer nogen trin. Ved udgivelser bruger jeg udrulninger med begr\u00e6nset r\u00e6kkevidde for at teste funktionen i praksis. Feedback fra overv\u00e5gning og logfiler indg\u00e5r direkte i header-reglerne. Dermed forbliver strategien realistisk og <strong>effektiv<\/strong>.<\/p>\n\n<h2>Versionsstyring og uforanderlige aktiver<\/h2>\n<p>Jeg tilf\u00f8jer hash-v\u00e6rdier til filnavne, for eksempel app.20260817.js, og angiver derefter public, max-age=31536000, <strong>uforanderlig<\/strong>. P\u00e5 den m\u00e5de ved browseren, at filen aldrig skifter \u201estille og roligt\u201c, og undg\u00e5r dermed gentagne valideringer. Ved den n\u00e6ste udgivelse f\u00e5r filen et nyt navn, hvilket betyder, at browseren henter pr\u00e6cis den nye version. P\u00e5 den m\u00e5de undg\u00e5r jeg for\u00e6ldede versioner efter en implementering. Denne taktik passer godt sammen med mange <a href=\"https:\/\/webhosting.de\/da\/http-cache-kontrol-strategier-hosting-cachemaster\/\">Cache-Control-strategier<\/a> de mest forskelligartede stakke.<\/p>\n<p>Til HTML bruger jeg ikke immutable, fordi siden ofte \u00e6ndres, og jeg \u00f8nsker fleksibel revalidering. Det samme g\u00e6lder for API-svar med skiftende data. Skrifttyper og store billeder er s\u00e6rligt velegnede, fordi brugerne anvender dem flere gange p\u00e5 tv\u00e6rs af enheder. Det er stadig vigtigt med en fuldst\u00e6ndig tilknytning af hashes til release-versioner. Dokumentation og klare <strong>Navne<\/strong> undg\u00e5 forvekslinger i teamet og i builds.<\/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\/08\/weboptimization-header-8274.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktiske trin til test og fejlfinding<\/h2>\n<p>Jeg \u00e5bner DevTools og gennemg\u00e5r svarheaderne i fanen \u00bbNetv\u00e6rk\u00ab for at se Cache-Control, ETag, Expires og <strong>Varierer<\/strong> at kontrollere. En ny genindl\u00e6sning uden cache (Ctrl+F5) viser mig, om reglerne virkelig virker. Derefter indl\u00e6ser jeg siden som normalt og kontrollerer, hvilke elementer der hentes fra cachen. For proxyservere og CDN\u2019er kigger jeg p\u00e5 headers som Age eller X-Cache, hvis de er tilg\u00e6ngelige. Disse kontroller afd\u00e6kker konflikter og fejlagtige <strong>Prioriteringer<\/strong> hurtigt.<\/p>\n<p>P\u00e5 serverniveau sammenligner jeg konfigurationer og logfiler for at opdage afvigelser. En hyppig fejl: Et program tilf\u00f8jer headere efterf\u00f8lgende og overskriver serverreglerne. I CI\/CD-pipelines tester jeg automatisk headere p\u00e5 staging-milj\u00f8et for at undg\u00e5 uventede problemer i produktionssystemet. Ved problemer anvender jeg midlertidigt korte TTL\u2019er, indtil \u00e5rsagen er fundet. Med klare tests holder jeg <strong>Kontrol<\/strong> om caching-adf\u00e6rden i alle lag.<\/p>\n\n<h2>Browserens virkelighed: Lagertyper og rydning<\/h2>\n<p>Browsere skelner mellem hukommelsescache og diskcache. Ofte anvendte, sm\u00e5 filer drager fordel af hukommelsescachen (ekstremt hurtige hits), mens store filer ofte gemmes p\u00e5 harddisken. Mobile enheder rydder mere aggressivt op \u2013 derfor planl\u00e6gger jeg ikke en strategi, der udelukkende bygger p\u00e5 meget lang browserpersistens, men sikrer mig i stedet med gode metoder til fornyelse. <em>uforanderlig<\/em> Det forhindrer ganske vist un\u00f8dvendige genindskrivninger, men kun s\u00e5 l\u00e6nge oplysningen ikke er blevet slettet af pladsm\u00e6ssige \u00e5rsager.<\/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\/08\/futuristic-web-optimization-7643.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>At tage v\u00e6k<\/h2>\n<p>S\u00e6t <strong>Cache-kontrol<\/strong> M\u00e5lrettet: lange gyldighedsperioder og \u00bbimmutable\u00ab for versionerede ressourcer, forsigtige regler og revalidering for HTML og personligt indhold. Kombiner \u00bbmax-age\u00ab med \u00bbETag\u00ab eller \u00bbLast-Modified\u00ab, s\u00e5 du sparer b\u00e5ndbredde og sikrer, at indholdet er opdateret. Kontroller alle niveauer, inklusive CDN, s\u00e5 reglerne ikke modarbejder hinanden. Undg\u00e5 at bruge no-store som en refleks, og brug det kun der, hvor databeskyttelse har absolut prioritet. Med en klar opdeling efter indholdstype, konsekvent versionering og l\u00f8bende m\u00e5ling opn\u00e5r du m\u00e6rkbart hurtigere sider og bevarer <strong>Suver\u00e6nitet<\/strong> om din caching.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan du bruger HTTP Cache-Control-headere korrekt for at forbedre browser-caching og weboptimering. Der er fokus p\u00e5 sikre og effektive caching-strategier.<\/p>","protected":false},"author":1,"featured_media":20739,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[679],"tags":[],"class_list":["post-20746","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-seo"],"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":"166","_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":"Cache-Control","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":"20739","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20746","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=20746"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20746\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20739"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20746"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20746"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20746"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}