{"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":"att-anvaenda-http-cachekontrollhuvudet-pa-raett-saett-webboptimering","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/http-cache-control-header-richtig-einsetzen-web-optimierung\/","title":{"rendered":"Att anv\u00e4nda HTTP-huvudet \u201dCache-Control\u201d p\u00e5 r\u00e4tt s\u00e4tt f\u00f6r effektiv webboptimering"},"content":{"rendered":"<p>Jag ska visa dig hur du anv\u00e4nder HTTP-headern <strong>Cache-kontroll<\/strong> anv\u00e4nder p\u00e5 ett m\u00e5linriktat s\u00e4tt f\u00f6r att minska laddningstiderna, spara p\u00e5 f\u00f6rfr\u00e5gningar och effektivt styra webbl\u00e4sarens cache. Du f\u00e5r tydliga riktlinjer, smarta kombinationer och praktiska inst\u00e4llningar f\u00f6r HTML, CSS, JS, bilder och API:er \u2013 utan gissningar, men med <strong>konkreta<\/strong> Handgrepp.<\/p>\n\n<h2>Centrala punkter<\/h2>\n<p>F\u00f6ljande viktiga aspekter hj\u00e4lper dig s\u00e4kert att snabbt och <strong>p\u00e5litlig<\/strong> Cache-strategi.<\/p>\n<ul>\n  <li><strong>max-\u00e5lder<\/strong> som tidsinst\u00e4llare: styr kylningstiden i sekunder<\/li>\n  <li><strong>offentlig\/privat<\/strong>: anger vem som f\u00e5r spara i cacheminnet<\/li>\n  <li><strong>ingen cacheminne<\/strong> mot. <strong>ingen lagring<\/strong>: ompr\u00f6va ist\u00e4llet f\u00f6r att f\u00f6rbjuda<\/li>\n  <li><strong>ETag<\/strong> och <strong>Senast modifierad<\/strong>: Villkorade h\u00e4mtningar sparar data<\/li>\n  <li><strong>Versionering<\/strong> + <strong>of\u00f6r\u00e4nderlig<\/strong>: l\u00e5nga cacher utan gamla problem<\/li>\n<\/ul>\n\n<h2>Grunderna: Vad g\u00f6r Cache-Control-rubriken?<\/h2>\n<p>Huvudet inneh\u00e5ller instruktioner som anger om, hur l\u00e4nge och av vem ett svar ska finnas i <strong>Cache<\/strong> f\u00e5r finnas. Jag skiljer h\u00e4r mellan klientcacher i webbl\u00e4saren och gemensamma cacher som proxyservrar eller CDN:er, som ofta betj\u00e4nar flera anv\u00e4ndare och d\u00e4rmed ger ytterligare <strong>Effektivitet<\/strong> medf\u00f6ra. Medan den f\u00f6r\u00e5ldrade Expires-headern anv\u00e4nder ett datum, anv\u00e4nder jag med Cache-Control relativa tidsperioder via max-age, vilket \u00e4r mindre felben\u00e4get. P\u00e5 s\u00e5 s\u00e4tt best\u00e4mmer jag hur l\u00e4nge en resurs f\u00f6rblir \u201ef\u00e4rsk\u201c och om den m\u00e5ste valideras p\u00e5 nytt innan den anv\u00e4nds. P\u00e5 s\u00e5 s\u00e4tt h\u00e5ller jag m\u00f6jligheten \u00f6ppen att kontrollera dynamiskt inneh\u00e5ll och att lagra statiska filer lokalt under mycket l\u00e5ng tid.<\/p>\n<p>Cache-Control g\u00e4ller b\u00e5de i svar och i f\u00f6rfr\u00e5gningar, vilket \u00e4r till nytta f\u00f6r mig vid omvalidering, till exempel i kombination med ETag eller Last-Modified f\u00f6r <strong>Villkorlig<\/strong> F\u00f6rfr\u00e5gningar. Jag st\u00e4ller till exempel in aggressiva v\u00e4rden f\u00f6r of\u00f6r\u00e4ndrade tillg\u00e5ngar och f\u00f6rsiktiga regler f\u00f6r HTML. Denna uppdelning s\u00e4kerst\u00e4ller att efterf\u00f6ljande anrop i m\u00f6jligaste m\u00e5n h\u00e4mtas fr\u00e5n webbl\u00e4sarens cache och d\u00e4rmed <strong>Serverbelastning<\/strong> minskar. Det \u00e4r viktigt med ett v\u00e4lplanerat samspel s\u00e5 att jag inte oavsiktligt blockerar resurser eller l\u00e5ter dem l\u00f6pa ut f\u00f6r tidigt. Den som tar dessa grunder till sig l\u00e4gger grunden f\u00f6r korta laddningstider och tydliga regler f\u00f6r cache-beteendet.<\/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>Viktiga riktlinjer f\u00f6rklarade p\u00e5 ett l\u00e4ttbegripligt s\u00e4tt<\/h2>\n<p>Med <strong>max-\u00e5lder<\/strong> Jag anger livsl\u00e4ngden f\u00f6r en resurs i sekunder, r\u00e4knat fr\u00e5n leveransdatumet. F\u00f6r bilder, CSS, JS och teckensnitt v\u00e4ljer jag ofta 31536000 (ett \u00e5r), s\u00e5 att \u00e5terkommande bes\u00f6kare anv\u00e4nder n\u00e4stan allt lokalt. F\u00f6r HTML-sidor st\u00e4ller jag in en kortare giltighetstid, cirka 300 sekunder, eller kombinerar dem med omvalidering s\u00e5 att \u00e4ndringar snabbt blir synliga. L\u00e5ng giltighetstid utan filversionering leder l\u00e4tt till gamla versioner i cachen, d\u00e4rf\u00f6r varierar jag filnamnen vid varje release. P\u00e5 s\u00e5 s\u00e4tt kombinerar jag snabb uppdatering med <strong>h\u00f6g<\/strong> Andel tr\u00e4ffar i cachen.<\/p>\n<p>Direktiven <strong>allm\u00e4nheten<\/strong> och <strong>privat<\/strong> styra vem som f\u00e5r cacha. Jag till\u00e5ter \u201dPublic\u201d f\u00f6r inneh\u00e5ll utan personalisering, s\u00e5 att \u00e4ven proxyservrar och CDN:er kan cacha det. Jag tilldelar \u201dPrivate\u201d n\u00e4r endast anv\u00e4ndarens webbl\u00e4sare ska beh\u00e5lla en kopia, till exempel p\u00e5 kontosidor. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rhindrar jag att personuppgifter hamnar i gemensamma cacheminnen och d\u00e4r <strong>g\u00e5 fel<\/strong>. Denna \u00e5tskillnad sparar besv\u00e4r och skyddar k\u00e4nslig information.<\/p>\n<p><strong>ingen cacheminne<\/strong> tolkas ofta felaktigt: Det f\u00f6rbjuder inte lagring, men kr\u00e4ver en omvalidering hos servern innan den anv\u00e4nds igen. Detta passar f\u00f6r inneh\u00e5ll som \u00e4ndras regelbundet utan att beh\u00f6va laddas om helt varje g\u00e5ng det h\u00e4mtas. Med ETag eller Last-Modified lagrar klienten data lokalt och fr\u00e5gar bara om de fortfarande \u00e4r aktuella. P\u00e5 s\u00e5 s\u00e4tt undviker jag on\u00f6diga byte och uppr\u00e4tth\u00e5ller \u00e4nd\u00e5 <strong>Inneh\u00e5ll<\/strong> f\u00e4rskt. F\u00f6r mycket k\u00e4nsliga data \u00e4r dock \u201dno-cache\u201d fortfarande f\u00f6r slapp.<\/p>\n<p><strong>ingen lagring<\/strong> \u00e4r den str\u00e4ngaste \u00e5tg\u00e4rden, eftersom den f\u00f6rbjuder all lagring i webbl\u00e4saren och i proxyservrar. Jag anv\u00e4nder detta f\u00f6r inloggningssidor, betalningsprocesser eller dokument med konfidentiella uppgifter. P\u00e5 s\u00e5 s\u00e4tt finns inga kopior i tillf\u00e4lliga mappar som av misstag skulle kunna hamna i fel h\u00e4nder. N\u00e4r jag anv\u00e4nder no-store kombinerar jag ofta detta med max-age=0 f\u00f6r att f\u00f6rhindra all \u00e5teranv\u00e4ndning <strong>att utesluta<\/strong>. S\u00e4kerheten g\u00e5r f\u00f6re prestandan h\u00e4r.<\/p>\n<p><strong>m\u00e5ste-omvalidera<\/strong> tvingar fram en f\u00f6rfr\u00e5gan till servern s\u00e5 snart tidsgr\u00e4nsen har l\u00f6pt ut. Om servern slutar fungera f\u00e5r cachen inte bara forts\u00e4tta att leverera resursen. Denna direktiv \u00e4r l\u00e4mplig f\u00f6r omr\u00e5den d\u00e4r konsistens \u00e4r viktigare \u00e4n en flexibel strategi vid driftstopp. Jag anv\u00e4nder den n\u00e4r f\u00f6r\u00e5ldrade data skulle kunna leda till felaktiga beslut. Regeln skapar tydliga <strong>Bindande karakt\u00e4r<\/strong> under f\u00f6rloppet.<\/p>\n\n<h2>Ut\u00f6kade riktlinjer f\u00f6r delade cacheminnen och drifts\u00e4kerhet<\/h2>\n<p>Ut\u00f6ver grundinst\u00e4llningarna anv\u00e4nder jag <strong>s-maxage<\/strong>, <strong>stale-under-validering<\/strong> och <strong>stale-om-fel<\/strong>, f\u00f6r att p\u00e5 ett m\u00e5linriktat s\u00e4tt styra proxyservrar och CDN:er och s\u00e4kerst\u00e4lla en smidig upplevelse f\u00f6r anv\u00e4ndarna \u00e4ven vid st\u00f6rningar. <em>s-maxage<\/em> st\u00e4ller in en egen TTL endast f\u00f6r delade cacher (webbl\u00e4sarna ignorerar den). P\u00e5 s\u00e5 s\u00e4tt kan jag t.ex. h\u00e5lla cachen kort i webbl\u00e4saren (max-age=600), men cacha den l\u00e4ngre i Edge (s-maxage=86400). <em>stale-under-validering<\/em> g\u00f6r det m\u00f6jligt f\u00f6r cacheminnen att forts\u00e4tta leverera f\u00f6r\u00e5ldrat inneh\u00e5ll under en viss tid, samtidigt som uppdateringen redan p\u00e5g\u00e5r i bakgrunden. <em>stale-om-fel<\/em> tr\u00e4der i kraft vid fel (t.ex. 500\/timeout) och skyddar anv\u00e4ndarupplevelsen genom att visa en n\u00e5got \u00e4ldre version ist\u00e4llet f\u00f6r att visa ett tydligt felmeddelande.<\/p>\n<p>Ett praktiskt exempel p\u00e5 offentliga API-svar eller JSON-sitemaps som s\u00e4llan \u00e4ndras ser ut s\u00e5 h\u00e4r: <code>Cache-Control: public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600<\/code>. P\u00e5 s\u00e5 s\u00e4tt h\u00e5lls webbl\u00e4sarna relativt uppdaterade, CDN:erna \u00e4r effektiva och anv\u00e4ndarna m\u00e4rker varken korta avbrott eller f\u00f6rdr\u00f6jda omvalideringar. Jag l\u00e5ter medvetet kritiska eller personaliserade omr\u00e5den vara op\u00e5verkade av s\u00e5dana mjuka riktlinjer.<\/p>\n\n<h2>Samverkan med Expires, ETag och Last-Modified<\/h2>\n<p>Jag anv\u00e4nder <strong>Upph\u00f6r att g\u00e4lla<\/strong> h\u00f6gst som en reservl\u00f6sning, eftersom Cache-Control g\u00e5r att styra mer precist och har f\u00f6retr\u00e4de om b\u00e5da \u00e4r inst\u00e4llda. Med ETag skickar jag ett unikt avtryck av resursen, s\u00e5 att webbl\u00e4saren via If-None-Match kan initiera en enkel omvalidering. Last-Modified anger datum och tid f\u00f6r den senaste \u00e4ndringen och fungerar tillsammans med If-Modified-Since. B\u00e5da metoderna sparar bandbredd, eftersom servern endast skickar tillbaka statuskoden 304 om inneh\u00e5llet \u00e4r of\u00f6r\u00e4ndrat. Detta samspel h\u00e5ller data n\u00e4ra anv\u00e4ndaren och minskar <strong>Rundresor<\/strong>.<\/p>\n<p>Ska jag ta den? <a href=\"https:\/\/webhosting.de\/sv\/http-villkorliga-foerfragningar-cache-validering-optimering-paket\/\">Villkorliga f\u00f6rfr\u00e5gningar<\/a>, minskar kostnaderna per sidvisning avsev\u00e4rt utan att jag blockerar nytt inneh\u00e5ll. Denna teknik kompletterar korta max-age-v\u00e4rden i HTML och s\u00e4kerst\u00e4ller aktuella visningar. N\u00e4r det g\u00e4ller tillg\u00e5ngar med versionshantering f\u00f6rlitar jag mig d\u00e4remot fr\u00e4mst p\u00e5 l\u00e5ng giltighetstid och undviker on\u00f6diga valideringar. P\u00e5 s\u00e5 s\u00e4tt avlastar jag <strong>Server<\/strong> och p\u00e5tagligt p\u00e5skynda uppf\u00f6ljningsbes\u00f6k. Sammantaget skapas en smidig datav\u00e4g med tydliga 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 praktiken: starkt, svagt och skalbart<\/h2>\n<p>I distribuerade milj\u00f6er ser jag till att ETags <em>konsekvent<\/em> ber\u00e4knas \u00f6ver alla instanser. Filbaserade ETag-v\u00e4rden som inkluderar inoder leder till on\u00f6diga missar i kluster. I Apache st\u00e4ller jag d\u00e4rf\u00f6r medvetet in ETag-ber\u00e4kningen s\u00e5 att:<\/p>\n<pre><code># Apache: konsekventa ETag-v\u00e4rden f\u00f6r statiska filer\nFileETag MTime Size\n# Valfritt: ta bort standard-ETag och st\u00e4lla in egen logik\n\n  #Header unset ETag\n<\/code><\/pre>\n<p>Med Nginx r\u00e4cker det ofta med <code>etag p\u00e5;<\/code> f\u00f6r statiska filer. F\u00f6r <em>dynamisk<\/em> Jag genererar ETags sj\u00e4lv i svaren \u2013 helst som en hash av svarstexten. Om jag beh\u00f6ver en viss tolerans vid mindre \u00e4ndringar (t.ex. formaterade tidsst\u00e4mplar) anv\u00e4nder jag <strong>svaga ETags<\/strong> (<code>W\/\"...\"<\/code>), som g\u00f6r att inneh\u00e5ll som \u00e4r semantiskt identiskt kan identifieras som of\u00f6r\u00e4ndrat trots skillnader i byte. Som reservalternativ anv\u00e4nder jag Last-Modified, till exempel till tidpunkten f\u00f6r uppdateringen av dataposten. Viktigt: ETag och Last-Modified <em>p\u00e5 samma g\u00e5ng<\/em> Det skadar inte att erbjuda det \u2013 klienten v\u00e4ljer sj\u00e4lv vad den st\u00f6der.<\/p>\n\n<h2>Anv\u00e4nd Vary p\u00e5 r\u00e4tt s\u00e4tt: Personalisering utan cache-kaos<\/h2>\n<p><strong>Varierande<\/strong> best\u00e4mmer vilka f\u00f6rfr\u00e5gningshuvuden som ska ing\u00e5 i cache-nyckeln. Jag h\u00e5ller medvetet Vary enkelt: <em>Accept-Encoding<\/em> \u00e4r standard (Gzip\/Brotli), <em>Acceptera spr\u00e5k<\/em> endast om jag ger spr\u00e5kspecifika svar. Fr\u00e5n <em>Vary: User-Agent<\/em> avr\u00e5der jag fr\u00e5n det, eftersom det f\u00e5r cacheminnet att sv\u00e4lla explosionsartat. Om inneh\u00e5llet \u00e4r beroende av cookies f\u00f6redrar jag att <strong>privat<\/strong> eller . <strong>ingen lagring<\/strong>, ist\u00e4llet f\u00f6r att underh\u00e5lla omfattande Vary-regler. N\u00e4r det g\u00e4ller tillg\u00e5ngar tar jag bort on\u00f6diga cookies i m\u00f6jligaste m\u00e5n, s\u00e5 att <strong>allm\u00e4nheten<\/strong>-Caching vid edge-enheten tr\u00e4der i kraft. Om API-autentisering via header anv\u00e4nds, kan <em>Vary: Auktorisering<\/em> f\u00f6rhindra att delade cacher blandar ihop svar fr\u00e5n olika anv\u00e4ndare \u2013 men ofta \u00e4r det dock s\u00e5 att <strong>privat<\/strong> det b\u00e4ttre och tydligare valet.<\/p>\n<p>Jag kontrollerar i DevTools om Vary-f\u00e4ltet st\u00e4lls in oavsiktligt (t.ex. av middleware), eftersom ett \u201ebrett\u201c Vary-f\u00e4lt minskar tr\u00e4fffrekvensen avsev\u00e4rt. Ett f\u00e5tal, noggrant utvalda rubriker g\u00f6r att cachen f\u00f6rblir \u00f6versk\u00e5dlig och <strong>effektiv<\/strong>.<\/p>\n\n<h2>Strategier efter inneh\u00e5llstyp<\/h2>\n<p>Jag g\u00f6r en tydlig \u00e5tskillnad mellan statiskt och dynamiskt inneh\u00e5ll f\u00f6r att kunna dra nytta av f\u00f6rdelarna med b\u00e5da. Statiska tillg\u00e5ngar f\u00e5r l\u00e5nga livsl\u00e4ngder och tydlig identifiering via versionerade filnamn. HTML och personligt inneh\u00e5ll hanterar jag mer f\u00f6rsiktigt, s\u00e5 att \u00e4ndringar snabbt blir tillg\u00e4ngliga och inga data hamnar i fel cacheminnen. API:er differentierar jag efter \u00e4ndringsfrekvens och informationens k\u00e4nslighet. Denna differentiering medf\u00f6r <strong>Hastighet<\/strong> utan att \u00e4ventyra sekretessen och <strong>Korrekthet<\/strong>.<\/p>\n<p>Tabellen nedan sammanfattar praktiska inst\u00e4llningar och visar f\u00f6rdelarna p\u00e5 ett \u00f6versk\u00e5dligt s\u00e4tt.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Typ av resurs<\/th>\n      <th>Exempel p\u00e5 rubrik<\/th>\n      <th>Varf\u00f6r<\/th>\n      <th>Ledtr\u00e5d<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>CSS\/JS\/Bilder\/Teckensnitt<\/td>\n      <td>Cache-kontroll: offentlig, max-age=31536000, of\u00f6r\u00e4nderlig<\/td>\n      <td>L\u00e5ng livsl\u00e4ngd <strong>Webbl\u00e4sarens cache<\/strong>, f\u00e4rre f\u00f6rfr\u00e5gningar<\/td>\n      <td>Versionshantering av filnamn f\u00f6r en \u00f6versk\u00e5dlig <strong>Rullande<\/strong> Uppdatera<\/td>\n    <\/tr>\n    <tr>\n      <td>HTML \u00e4r inte anpassad<\/td>\n      <td>Cache-Control: no-cache, must-revalidate (eller max-age=300)<\/td>\n      <td>Aktualiteten \u00e4r fortsatt h\u00f6g, datam\u00e4ngden \u00e4r fortsatt liten<\/td>\n      <td>Med ETag\/Last-Modified f\u00f6r enkel <strong>revalidering<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Anpassad HTML<\/td>\n      <td>Cache-Control: private, no-cache, must-revalidate<\/td>\n      <td>Ingen lagring i gemensamma cacheminnen<\/td>\n      <td>Skydda sessionsdata och <strong>L\u00e4ckage<\/strong> Undvik<\/td>\n    <\/tr>\n    <tr>\n      <td>API:er som \u00e4r statiska \/ s\u00e4llan \u00e4ndras<\/td>\n      <td>Cache-Control: public, max-age=3600<\/td>\n      <td>H\u00f6g tr\u00e4ffs\u00e4kerhet hos m\u00e5nga <strong>Kunder<\/strong><\/td>\n      <td>Var flexibel inf\u00f6r frekventa drifts\u00e4ttningar<\/td>\n    <\/tr>\n    <tr>\n      <td>API:er som \u00e4r mycket dynamiska\/k\u00e4nsliga<\/td>\n      <td>Cache-Control: no-store, max-age=0<\/td>\n      <td>L\u00e4gg inte undan k\u00e4nsliga uppgifter<\/td>\n      <td>Direkt <strong>Aktualitet<\/strong> ist\u00e4llet f\u00f6r risk<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>F\u00f6r bildgallerier, stora JS-paket eller webbtypsnitt l\u00f6nar sig l\u00e5nga max-age-v\u00e4rden snabbt. Jag \u00e4r noga med versionsstr\u00e4ngar i filnamnen s\u00e5 att anv\u00e4ndarna aldrig ser f\u00f6r\u00e5ldrade paket. HTML-koden h\u00e5lls kort och anv\u00e4nder omvalidering s\u00e5 att \u00e4ven sm\u00e5 korrigeringar av texter eller priser snabbt publiceras. API:er f\u00e5r sina regler beroende p\u00e5 anv\u00e4ndningsprofil och behov av \u00e4ndringar. Denna kombination ger varaktiga resultat <strong>flotta<\/strong> Sidvisningar och sparar <strong>Bandbredd<\/strong>.<\/p>\n\n<h2>SPA vs. MPA: Kort HTML-kod, stora resurser<\/h2>\n<p>N\u00e4r det g\u00e4ller enkel-sida-appar anser jag att <em>Index-HTML<\/em> s\u00e4rskilt kortlivade (t.ex. <code>ingen cachning, m\u00e5ste f\u00f6rnyas<\/code> eller . <code>max-age=60<\/code>), eftersom den styr vilken version av paketet som laddas. Alla kompilerade chunkar, teckensnitt och bilder \u00e4r d\u00e4remot strikt versionshanterade och f\u00e5r <code>public, max-age=31536000, immutable<\/code>. P\u00e5 s\u00e5 s\u00e4tt ser jag till att en ny version med uppdaterad index-HTML omedelbart h\u00e4nvisar till de korrekta, nya filnamnen, medan befintliga anv\u00e4ndare <em>stora<\/em> H\u00e4mta tillg\u00e5ngar fr\u00e5n den lokala cachen.<\/p>\n<p>Fr\u00e5gestr\u00e4ngar som cache-busting (<code>?v=123<\/code>) anv\u00e4nder jag bara d\u00e4r filnamnen inte g\u00e5r att \u00e4ndra s\u00e5 l\u00e4tt. Det \u00e4r b\u00e4ttre med unika filnamn (hashar), eftersom de segmenterar cachen p\u00e5 ett tydligare s\u00e4tt och ger upphov till f\u00e4rre specialfall.<\/p>\n\n<h2>Serverkonfiguration: Apache och Nginx<\/h2>\n<p>I Apache l\u00e4gger jag oftast in rubrikerna i filen <strong>.htaccess<\/strong>, f\u00f6rutsatt att modulen mod_headers \u00e4r aktiverad. F\u00f6r statiska resurser anger jag en l\u00e5ng giltighetstid, medan HTML hanteras str\u00e4ngare. I Nginx g\u00f6r jag detta i location-block, ofta tillsammans med direktivet expires som reservl\u00f6sning. Jag testar varje \u00e4ndring med DevTools i fliken \u201dN\u00e4tverk\u201d f\u00f6r att se de verkliga header-v\u00e4rdena. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rhindrar jag felaktiga regler som annars kan leda till kostsamma <strong>Felaktiga f\u00f6rfr\u00e5gningar<\/strong> skapa.<\/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 (serverblock)\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>Jag ser till att inga konkurrerande regler i uppstr\u00f6ms-tj\u00e4nster motverkar dessa rubriker. Ett uppstr\u00f6ms-CDN f\u00e5r till exempel st\u00e4lla in egna TTL-v\u00e4rden, vilket jag m\u00e5ste styra medvetet. Om alla niv\u00e5er st\u00e4mmer \u00f6verens f\u00f6rblir resurserna tillf\u00f6rlitliga <strong>l\u00e4tthittad<\/strong> och konsekvent. Den som granskar noggrant h\u00e4r undviker l\u00e5ngdragna fels\u00f6kningssessioner. Sm\u00e5 kontroller sparar mycket tid senare <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- och proxy-praktik: Konfigurera s-maxage och Stale-strategier<\/h2>\n<p>F\u00f6r Edge-cacher kompletterar jag serverkonfigurationen med <em>s-maxage<\/em> samt Stale-direktiv. Exempel fr\u00e5n Apache:<\/p>\n<pre><code># Apache: CDN-optimerade 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>Och i Nginx:<\/p>\n<pre><code># Nginx: Optimering av delad 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>M\u00e5nga CDN:er f\u00f6ljer dessa direktiv direkt. Om ditt edge-lager f\u00f6rv\u00e4ntar sig egna rubriker (t.ex. surrogatrubriker) \u00e5terspeglar jag logiken d\u00e4r och h\u00e5ller webbl\u00e4sar- och delad cache-strategi tydligt \u00e5tskilda. Tack vare versionshantering beh\u00f6ver jag s\u00e4llan rensa cachen; om det \u00e4nd\u00e5 beh\u00f6vs planerar jag det som ett m\u00e5linriktat, litet ingrepp.<\/p>\n\n<h2>S\u00e4rskilda fall: omdirigeringar, felsidor och formul\u00e4rfl\u00f6den<\/h2>\n<p><strong>Omdirigeringar:<\/strong> 301-svar kan enligt specifikationen cachelagras. N\u00e4r jag st\u00e4ller in tillf\u00e4lliga omdirigeringar (302\/307) anger jag tydliga TTL-v\u00e4rden eller st\u00e4ller medvetet in <code>ingen lagring<\/code>, s\u00e5 att ingenting blir fastst\u00e4llt. Permanenta 301-omdirigeringar f\u00e5r ha en m\u00e5ttlig TTL \u2013 \u00e4ndringar blir d\u00e5 ett medvetet och samordnat steg.<\/p>\n<p><strong>Felrapporter:<\/strong> 404\/410-svar kan cachelagras under en kort tid (t.ex. <code>max-age=60<\/code>), f\u00f6r att minska bot-belastningen. Vid 500-talet har jag, beroende p\u00e5 omgivningen <code>stale-om-fel<\/code> aktiv, s\u00e5 att anv\u00e4ndarna hellre ser en \u00e4ldre, fungerande sida \u00e4n ett felmeddelande.<\/p>\n<p><strong>POST\/Nedladdning:<\/strong> Svar p\u00e5 POST-f\u00f6rfr\u00e5gningar lagras vanligtvis inte i webbl\u00e4sarens cache. F\u00f6r filexporter som inneh\u00e5ller personuppgifter (t.ex. fakturor) anv\u00e4nder jag konsekvent <code>ingen lagring<\/code> plus s\u00e4ker leverans (t.ex. Content-Disposition), s\u00e5 att inget lagras av misstag. Icke-personanpassade, stora nedladdningar (t.ex. utg\u00e5vor) kan d\u00e4remot med f\u00f6rdel utnyttja offentliga cacher under l\u00e5ng tid.<\/p>\n\n<h2>Undvik typiska misstag<\/h2>\n<p>M\u00e5nga f\u00f6rv\u00e4xlar <strong>ingen cacheminne<\/strong> med \u201eingen cache alls\u201c, vilket leder till on\u00f6dig belastning. Om man l\u00e4ser det korrekt till\u00e5ter no-cache cachelagring, men kr\u00e4ver omvalidering. En annan klassiker: l\u00e5nga max-age-v\u00e4rden utan versionshantering f\u00f6r CSS eller JS, vilket g\u00f6r att f\u00f6r\u00e5ldrade filer beh\u00e5lls. Bristande \u00e5tskillnad mellan HTML och statiska resurser g\u00e5r ut \u00f6ver hastigheten, eftersom HTML s\u00e4llan f\u00e5r cachas aggressivt. Den som ignorerar detta bromsar <strong>Anv\u00e4ndarupplevelse<\/strong> fr\u00e5n.<\/p>\n<p>Konflikter mellan server, CDN och applikation saboterar cachingeffekterna utan att man m\u00e4rker det. Kontrollera d\u00e4rf\u00f6r \u00f6verskrivningar och mellanlager om rubriker \u00e4ndras \u201esom genom ett trollslag\u201c. H\u00e4r kan det vara bra att titta p\u00e5 loggen och svarskedjan f\u00f6r att avsl\u00f6ja felaktiga prioriteringar. En kortfattad checklista och typiska fallgropar kring <a href=\"https:\/\/webhosting.de\/sv\/http-cache-headers-sabotera-caching-cachefix\/\">Sabotage av cachehuvud<\/a> underl\u00e4ttar kontrollen. Tydliga prioriteringar f\u00f6rhindrar <strong>Biverkningar<\/strong> vid drifts\u00e4ttningar.<\/p>\n\n<h2>Att g\u00f6ra prestationsvinster m\u00e4tbara<\/h2>\n<p>Jag utv\u00e4rderar effekterna av Cache-Control med hj\u00e4lp av m\u00e5tt som TTFB, LCP och antalet <strong>F\u00f6rfr\u00e5gningar<\/strong> per sidvisning. En titt i DevTools visar mig om filer h\u00e4mtas fr\u00e5n \u201efrom disk cache\u201c eller \u201efrom memory cache\u201c. Lighthouse, WebPageTest och liknande verktyg ger indikationer p\u00e5 om webbl\u00e4sarens cachelagring fungerar konsekvent. Jag m\u00e4ter f\u00f6re och efter en \u00e4ndring s\u00e5 att jag tydligt kan se verkliga f\u00f6rb\u00e4ttringar. Denna disciplin s\u00e4kerst\u00e4ller optimeringar <strong>begriplig<\/strong> och m\u00e5linriktat.<\/p>\n<p>Stora bilder, webbteckensnitt och paket som inte laddas vid uppf\u00f6ljande bes\u00f6k har en s\u00e4rskilt stor effekt. HTML-koden f\u00f6rblir n\u00e4ra servern f\u00f6r att anv\u00e4ndarna snabbt ska f\u00e5 tillg\u00e5ng till nytt inneh\u00e5ll. API:er gynnas m\u00e4rkbart n\u00e4r ofta anv\u00e4nda rutter har en m\u00e5ttlig TTL. Resultaten visar sig i form av kortare laddningstider, mindre datavolym och en j\u00e4mnare serverbelastning. Den som konsekvent kontrollerar detta sparar p\u00e5 l\u00e5ng sikt <strong>Resurser<\/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 och HTTP-cache: l\u00e5t dem inte motarbeta varandra<\/h2>\n<p>Om jag anv\u00e4nder en Service Worker st\u00e4mmer dess strategi \u00f6verens med mina HTTP-headers. F\u00f6r statiska, versionerade tillg\u00e5ngar passar \u201ecache-first\u201c med l\u00e5ng TTL och <em>of\u00f6r\u00e4nderlig<\/em> Utm\u00e4rkt. F\u00f6r HTML eller API-data som \u00e4ndras ofta f\u00f6redrar jag \u201enetwork-first\u201c eller \u201estale-while-revalidate\u201c, s\u00e5 att anv\u00e4ndarna snabbt f\u00e5r svar och att uppdateringar kommer in i realtid. Viktigt: Service Workern b\u00f6r respektera omvalideringar (vidarebefordra If-None-Match\/If-Modified-Since) ist\u00e4llet f\u00f6r att artificiellt beh\u00e5lla inneh\u00e5ll.<\/p>\n<p>Jag vill dessutom g\u00f6ra en tydlig \u00e5tskillnad: HTTP-cachen f\u00e5r g\u00e4rna ta hand om en stor del av arbetet; service workern kompletterar funktionen, den ers\u00e4tter den inte. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir fels\u00f6kning och drift \u00f6versk\u00e5dliga.<\/p>\n\n<h2>Att f\u00f6rst\u00e5 direktiv p\u00e5 beg\u00e4randesidan<\/h2>\n<p>\u00c4ven f\u00f6rfr\u00e5gningar kan styra cachelagringen. <code>Cache-Control: no-cache<\/code> p\u00e5 <em>Beg\u00e4ran<\/em> tvingar fram en omvalidering hos servern, <code>max-age=0<\/code> \u00e4r liknande. <code>ingen lagring<\/code> I beg\u00e4ran f\u00f6rbjuds lagring av svaret l\u00e4ngs kedjan. F\u00f6r offline-fall kan <code>endast om den finns i cachen<\/code> kan vara anv\u00e4ndbart: Klienten accepterar d\u00e5 endast svar fr\u00e5n cachen. Denna mekanism \u00e4r till hj\u00e4lp i appar som ska erbjuda en definierad upplevelse \u00e4ven vid svag anslutning.<\/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>B\u00e4sta praxis f\u00f6r ditt arbetsfl\u00f6de<\/h2>\n<p>Jag b\u00f6rjar med en inventering: Vilka filtyper finns, vilka \u00e4r anpassade och vilka \u00e4ndras s\u00e4llan? D\u00e4refter till\u00e4mpar jag regler p\u00e5 ett differentierat s\u00e4tt s\u00e5 att tillg\u00e5ngarna bevaras l\u00e4nge i <strong>Cache<\/strong> f\u00f6rblir of\u00f6r\u00e4ndrad och HTML-koden h\u00e5lls uppdaterad. Genom att ta bort versionsstr\u00e4ngar i filnamnen undviker man risken f\u00f6r f\u00f6r\u00e5ldrade paket och m\u00f6jligg\u00f6r snabba k\u00f6rningstider. Under regelbundna underh\u00e5llsperioder kontrollerar jag rubriker och tr\u00e4fffrekvenser f\u00f6r att tidigt kunna uppt\u00e4cka trender. Denna rutin h\u00e5ller webbplatsen <strong>h\u00f6gpresterande<\/strong> och f\u00f6ruts\u00e4gbar.<\/p>\n<p>Jag dokumenterar konfigurationer kort och tydligt s\u00e5 att framtida \u00e4ndringar inte av misstag f\u00f6rst\u00f6r n\u00e5got. Distributionsskripten uppdaterar automatiskt filernas hashv\u00e4rden s\u00e5 att jag inte gl\u00f6mmer n\u00e5got steg. F\u00f6r releaser anv\u00e4nder jag utrullningar med begr\u00e4nsad r\u00e4ckvidd f\u00f6r att testa beteendet i drift. Feedback fr\u00e5n \u00f6vervakning och loggar fl\u00f6dar direkt tillbaka till header-reglerna. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir strategin realistisk och <strong>effektiv<\/strong>.<\/p>\n\n<h2>Versionshantering och of\u00f6r\u00e4nderliga tillg\u00e5ngar<\/h2>\n<p>Jag l\u00e4gger till hashv\u00e4rden i filnamnen, till exempel app.20260817.js, och anger sedan public, max-age=31536000, <strong>of\u00f6r\u00e4nderlig<\/strong>. P\u00e5 s\u00e5 s\u00e4tt vet webbl\u00e4saren att filen aldrig byts ut \u201etyst\u201c och slipper g\u00f6ra omvalideringar. Vid n\u00e4sta release f\u00e5r filen ett nytt namn, vilket g\u00f6r att webbl\u00e4saren laddar just den nya versionen. P\u00e5 s\u00e5 s\u00e4tt undviker jag f\u00f6r\u00e5ldrade versioner efter en distribution. Denna taktik passar bra ihop med m\u00e5nga <a href=\"https:\/\/webhosting.de\/sv\/http-cache-kontroll-strategier-hosting-cachemaster\/\">Strategier f\u00f6r cachekontroll<\/a> de mest skiftande stackarna.<\/p>\n<p>F\u00f6r HTML anv\u00e4nder jag inte immutable, eftersom sidan ofta \u00e4ndras och jag vill ha flexibel omvalidering. Detsamma g\u00e4ller f\u00f6r API-svar med varierande data. Typsnitt och stora bilder \u00e4r s\u00e4rskilt l\u00e4mpliga eftersom anv\u00e4ndarna \u00e5teranv\u00e4nder dem flera g\u00e5nger p\u00e5 olika enheter. Det \u00e4r viktigt att ha en fullst\u00e4ndig koppling mellan hashv\u00e4rden och releaseversioner. Dokumentation och tydliga <strong>Namn<\/strong> undvika f\u00f6rv\u00e4xlingar inom teamet och 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>Praktiska steg f\u00f6r testning och fels\u00f6kning<\/h2>\n<p>Jag \u00f6ppnar DevTools och granskar svarsrubrikerna p\u00e5 fliken \u201dN\u00e4tverk\u201d f\u00f6r att kontrollera Cache-Control, ETag, Expires och <strong>Varierande<\/strong> att kontrollera. En ny uppdatering utan cache (Ctrl+F5) visar mig om reglerna verkligen fungerar. D\u00e4refter laddar jag sidan som vanligt och kontrollerar vilka element som h\u00e4mtas fr\u00e5n cachen. F\u00f6r proxyservrar och CDN tittar jag p\u00e5 rubriker som Age eller X-Cache, om s\u00e5dana finns. Dessa kontroller uppt\u00e4cker konflikter och felaktiga <strong>Prioriteringar<\/strong> snabbt.<\/p>\n<p>P\u00e5 serverniv\u00e5 j\u00e4mf\u00f6r jag konfigurationer och loggar f\u00f6r att uppt\u00e4cka avvikelser. Ett vanligt fel: En applikation l\u00e4gger till header i efterhand och skriver \u00f6ver serverreglerna. I CI\/CD-pipelines testar jag header automatiskt i stagingmilj\u00f6n f\u00f6r att undvika \u00f6verraskningar i produktionssystemet. Vid problem anv\u00e4nder jag tillf\u00e4lligt korta TTL-v\u00e4rden tills orsaken har hittats. Med tydliga tester h\u00e5ller jag <strong>Kontroll<\/strong> om cachingbeteendet i alla lager.<\/p>\n\n<h2>Webbl\u00e4sarens verklighet: lagringstyper och rensning<\/h2>\n<p>Webbl\u00e4sare skiljer mellan minnes- och diskcache. Sm\u00e5 filer som anv\u00e4nds ofta drar nytta av minnescachen (extremt snabba tr\u00e4ffar), medan stora resurser ofta hamnar p\u00e5 h\u00e5rddisken. Mobila enheter rensar mer aggressivt \u2013 d\u00e4rf\u00f6r planerar jag inte in n\u00e5gon strategi som uteslutande bygger p\u00e5 mycket l\u00e5ng webbl\u00e4sarpersistens, utan s\u00e4krar mig med bra metoder f\u00f6r omvalidering. <em>of\u00f6r\u00e4nderlig<\/em> Det f\u00f6rhindrar visserligen on\u00f6diga omvalideringar, men bara s\u00e5 l\u00e4nge posten inte har tagits bort p\u00e5 grund av utrymmesbrist.<\/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>Att ta bort<\/h2>\n<p>St\u00e4ll in <strong>Cache-kontroll<\/strong> Anv\u00e4nd f\u00f6ljande strategier: l\u00e5nga giltighetstider och \u201dimmutable\u201d f\u00f6r versionerade tillg\u00e5ngar, f\u00f6rsiktiga regler och omvalidering f\u00f6r HTML och personligt inneh\u00e5ll. Kombinera \u201dmax-age\u201d med \u201dETag\u201d eller \u201dLast-Modified\u201d f\u00f6r att spara bandbredd och s\u00e4kerst\u00e4lla att inneh\u00e5llet \u00e4r aktuellt. Kontrollera alla niv\u00e5er, inklusive CDN, s\u00e5 att reglerna inte motverkar varandra. Undvik att anv\u00e4nda no-store bara av reflex, och anv\u00e4nd det endast d\u00e4r dataskydd har absolut prioritet. Med tydlig uppdelning efter inneh\u00e5llstyp, konsekvent versionering och l\u00f6pande m\u00e4tning uppn\u00e5r du m\u00e4rkbart snabbare sidor och beh\u00e5ller <strong>Suver\u00e4nitet<\/strong> om din caching.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e4r dig hur du anv\u00e4nder HTTP-rubriken \u201dCache-Control\u201d p\u00e5 r\u00e4tt s\u00e4tt f\u00f6r att f\u00f6rb\u00e4ttra webbl\u00e4sarens cachelagring och webboptimering. Fokus ligger p\u00e5 s\u00e4kra och effektiva cachelagringsstrategier.<\/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":"178","_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\/sv\/wp-json\/wp\/v2\/posts\/20746","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=20746"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/20746\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/20739"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=20746"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=20746"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=20746"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}