{"id":19521,"date":"2026-05-30T15:02:41","date_gmt":"2026-05-30T13:02:41","guid":{"rendered":"https:\/\/webhosting.de\/http-conditional-requests-cache-validierung-optimierung-paket\/"},"modified":"2026-05-30T15:02:41","modified_gmt":"2026-05-30T13:02:41","slug":"http-voorwaardelijke-verzoeken-cache-validatie-optimalisatie-pakket","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/http-conditional-requests-cache-validierung-optimierung-paket\/","title":{"rendered":"Voorwaardelijke HTTP-verzoeken en cachevalidatie begrijpen"},"content":{"rendered":"<p><strong>HTTP Voorwaardelijk<\/strong> Verzoeken verminderen de overdrachtskosten door ervoor te zorgen dat de client een bron alleen volledig laadt als deze daadwerkelijk is gewijzigd sinds het laatste verzoek. Ik zal laten zien hoe <strong>Cache-validatie<\/strong> met ETag, Last-Modified, If-None-Match, If-Modified-Since en 304 Not Modified werkt betrouwbaar en de laadtijden zijn merkbaar korter.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>Validatie<\/strong> in plaats van een volledige download: 304 bespaart bandbreedte en tijd.<\/li>\n  <li><strong>ETag<\/strong> en Last-Modified werken samen voor een schone controle.<\/li>\n  <li><strong>Cachebeheer<\/strong> definieert versheid, verloopt alleen supplementen.<\/li>\n  <li><strong>Randvoorwaarden<\/strong> zoals If-Match beveiligde schrijfprocessen.<\/li>\n  <li><strong>Beveiliging<\/strong> vereist private\/no-store voor gevoelige inhoud.<\/li>\n<\/ul>\n\n<h2>Wat voorwaardelijke verzoeken doen in het dagelijks leven<\/h2>\n\n<p>Ik stel <strong>Voorwaardelijk<\/strong> verzoeken om de server een duidelijke vraag te stellen: Moet ik echt nieuwe gegevens overbrengen of is mijn cache voldoende? De browser of een proxy stuurt voorwaarden, de server controleert of een bestand is gewijzigd en antwoordt met 304 Not Modified zonder body. Dit patroon houdt HTML, CSS, JavaScript, afbeeldingen en API-reacties up-to-date en vermindert de belasting van de infrastructuur aanzienlijk. Voor langere geldige assets gebruik ik lange max-age waarden en zorg ik ervoor dat ze up-to-date zijn door middel van validatie. Als u de juiste <a href=\"https:\/\/webhosting.de\/nl\/http-cache-controle-strategieen-hosting-cachemaster\/\">Cachebeheerstrategie\u00ebn<\/a> haalt het maximale uit caches zonder risico op verouderde inhoud.<\/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\/05\/httpcache-0614.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Headers die cachevalidatie mogelijk maken<\/h2>\n\n<p>Voor betrouwbare <strong>Cache<\/strong>-De client heeft duidelijke signalen nodig van het antwoord om beslissingen te kunnen nemen. Ik gebruik Cache-Control voor versheid en regels, Expires af en toe als aanvulling, en Last-Modified en ETag voor de eigenlijke validatie. Last-Modified geeft een modificatietijd die snel kan worden gecontroleerd, terwijl ETag een versie-aanduiding geeft die ook wordt gebruikt voor dynamische inhoud. Het blijft belangrijk: no-cache betekent valideren voor gebruik, niet verwijderen. Als je deze semantiek correct toepast, zul je merkbaar minder gegevensverkeer krijgen terwijl de inhoud up-to-date blijft. <strong>Inhoud<\/strong>.<\/p>\n\n<h2>Volgorde van een voorwaardelijk verzoek zonder omwegen<\/h2>\n\n<p>Bij de eerste oproep slaat de client het bestand en de validatiewaarden op, zoals <strong>ETag<\/strong> of Last-Modified in de cache. Later verloopt de bron of is een nieuwe controle nodig voor gebruik en stuurt de client If-None-Match of If-Modified-Since. De server vergelijkt de informatie met de huidige status en stuurt ofwel 200 OK met een nieuwe body of 304 Not Modified zonder payload terug. De client blijft dan de bestaande kopie gebruiken en bespaart transmissie, TLS-werklast en tijd. Dit pingpongen lijkt onopvallend, maar de <strong>Effect<\/strong> op het gevoel van belasting en serverbelasting is duidelijk.<\/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\/05\/http_requests_besprechung_4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>ETag vs. Last-Modified in directe vergelijking<\/h2>\n\n<p>Ik gebruik <strong>Laatst gewijzigd<\/strong> Ik gebruik graag timestamps als een snelle, eenvoudige referentie, maar gebruik ETags voor een fijnmazige controle. Tijdstempels kunnen hun grenzen bereiken met zeer korte wijzigingsintervallen of dynamische uitvoer vervalsen. Ik maak ETags aan van bestandshashes, databaseversies of rendervarianten, waarbij elke verandering in de inhoud een nieuwe identifier genereert. Beide mechanismen kunnen worden gecombineerd: De client kan If-None-Match en If-Modified-Since parallel verzenden en de server selecteert de juiste controle. Hoe zorg je voor een betrouwbare <strong>Validatie<\/strong>, die evenzeer van toepassing is op statische als op dynamische bronnen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Criterium<\/th>\n      <th>Laatst gewijzigd<\/th>\n      <th>ETag<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>Nauwkeurigheid<\/strong><\/td>\n      <td>Tweede resolutie, geschikt voor bestanden<\/td>\n      <td>Versie-aanduiding voor elke inhoudswijziging<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Dynamiek<\/strong><\/td>\n      <td>Zwak met frequente, niet op bestanden gebaseerde wijzigingen<\/td>\n      <td>Sterk voor API's en gerenderde inhoud<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Uitgaven<\/strong><\/td>\n      <td>Laag, beschikbaar via het bestandssysteem<\/td>\n      <td>Laag tot matig, generatie in app\/proxy<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Conflicten<\/strong><\/td>\n      <td>Klokafwijkingen mogelijk<\/td>\n      <td>Mogelijk onjuist geconfigureerde zwakke\/sterke tags<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Juiste instellingen voor browser caching en API's<\/h2>\n\n<p>Voor statische activa gebruik ik lange <strong>maximumleeftijd<\/strong> en opslaan via ETag of bestandsnaam hash zodat updates onmiddellijk worden herkend. Ik markeer HTML- en API-responses vaak met no-cache zodat de client ze voor gebruik kan valideren zonder alles elke keer opnieuw te hoeven laden. Ik markeer gepersonaliseerde pagina's met private zodat gedeelde caches niets uitvoeren dat is bewaard voor anderen. Fouten worden vaak veroorzaakt door tegenstrijdige richtlijnen of ontbrekende validatieheaders, die ik voorkom met duidelijke regels. Als je de typische struikelblokken kent, kun je ze gemakkelijk vermijden; goede voorbeelden hiervan vind je in het artikel over <a href=\"https:\/\/webhosting.de\/nl\/http-cache-headers-saboteren-caching-cachefix\/\">Header-traps in caching<\/a>, waar ik me graag op ori\u00ebnteer.<\/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\/05\/http-conditional-cache-validation-3847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Statuscodes en voorwaarden effectief gebruiken<\/h2>\n\n<p>Ik organiseer <strong>Statuscodes<\/strong> duidelijk: 200 OK levert inhoud, 304 Not Modified bevestigt cachegebruik en 412 Precondition Failed annuleert als niet aan een voorwaarde wordt voldaan. Voor beveiligde schrijfoperaties gebruik ik If-Match zodat updates alleen worden uitgevoerd als de ETag overeenkomt met de verwachte versie. Lezen met If-None-Match of If-Modified-Since voorkomt overbodige payloads en houdt clients gesynchroniseerd. Consistent gedrag is belangrijk: Hetzelfde endpoint moet identiek reageren voor identieke precondities. Voor SEO en bots let ik op hoe caches en crawlers statusberichten interpreteren; een goed overzicht van <a href=\"https:\/\/webhosting.de\/nl\/http-statuscodes-crawling-hosting-optimalisatie-crawlboost\/\">HTTP-statuscodes en crawling<\/a> helpt bij het nemen van schone beslissingen.<\/p>\n\n<h2>Beveiliging en gegevensbescherming voor caching<\/h2>\n\n<p>Ik behandel gevoelige inhoud met <strong>geen opslag<\/strong> en ze dus geen kans geven om in de browser of proxy cache terecht te komen. Ik markeer gepersonaliseerde pagina's met Cache-Control: private en controleer of er geen persoonlijke gegevens in langlopende URL's in de cache staan. Ik ontwerp ETags neutraal, zonder conclusies te trekken over gebruikersaccounts of interne ID's. Ik schakel consequent alle caching uit voor inlogweergaven en bankflows. Als je gegevensminimalisatie, geschikte richtlijnen en schone headers combineert, verlaag je het risico en bescherm je je gegevens. <strong>Vertrouwelijkheid<\/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\/05\/http_cache_validierung_6789.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Implementatie: Stappen voor server en applicatie<\/h2>\n\n<p>In het begin scheid ik <strong>statisch<\/strong> van dynamische bronnen en beslis waar lange deadlines zinvol zijn en waar validatie prioriteit heeft. In Nginx, Apache of een app-server configureer ik cache control en activeer ik last-modified en ETags, waarbij ik het genereren van ETags in de applicatie plaats voor dynamische eindpunten. Bij het verwerken van inkomende verzoeken evalueer ik If-None-Match en If-Modified-Since en reageer ik met 304 als de voorwaarde overeenkomt. Voor schrijfoperaties gebruik ik If-Match en retourneer 412 bij afwijkingen om overschrijven te voorkomen. Dit cre\u00ebert een consistent gedrag dat effici\u00ebnt gebruik maakt van caches en tegelijkertijd <strong>Correctheid<\/strong> verzekert.<\/p>\n\n<h2>Gebruik meetgegevens, tests en monitoring op een verstandige manier<\/h2>\n\n<p>Ik controleer de <strong>Netwerk<\/strong>-tab van de DevTools om te controleren of bronnen uit de cache komen, gevalideerd worden of vers geladen zijn. Ik controleer status, leeftijdswaarden, ETags en de grootte van het overgedragen antwoord. Onder belasting meet ik latency, overdrachtsvolume en CPU van de server om het werkelijke effect van 304 reacties te zien. Logboeken van de reverse proxy laten zien of gedeelde caches hun werk doen en hoeveel validaties succesvol zijn. Ik gebruik deze gegevens om de max-age, cache control directives en ETag-strategie\u00ebn aan te passen totdat de responstijden en <strong>Raakpercentage<\/strong> stemming.<\/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\/05\/EntwicklerdeskCache3178.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hostingprestaties: waarom voorwaardelijke verzoeken geld besparen<\/h2>\n\n<p>Elke <strong>304<\/strong>-De gedeelde cache-respons bespaart bandbreedte, vermindert de TLS-overhead en verkort de responstijd, wat vooral belangrijk is voor veel gelijksoortige verzoeken. In hostingopstellingen met reverse proxies, loadbalancers en CDN's bereik ik het grootste effect als ik gedeelde caches duidelijk toesta of specifiek uitsluit. Minder overdracht betekent vaak ook lagere verkeerskosten in euro's en meer reserves voor echte belastingspieken. De gebruikerservaring wordt ook verbeterd doordat herhaalde paginaweergaven en API-polls sneller reageren. Op deze manier realiseer ik prestatiepotentieel dat pure hardware-upgrades alleen niet kunnen leveren en maak ik gebruik van bestaande <strong>Infrastructuur<\/strong> beter.<\/p>\n\n<h2>Veelgemaakte fouten en pragmatische oplossingen<\/h2>\n\n<p>Tegenstrijdige <strong>Kop<\/strong> zoals no-cache gekoppeld aan expires ver in de toekomst verwarren caches; ik stel duidelijke regels op zonder duplicatie. Ontbrekende ETags voor dynamische eindpunten leiden tot onnodige volledige downloads; ik voeg een betrouwbare identifier toe en evalueer if-none-match. Te korte max-age waarden verspillen potentieel met zelden veranderde bestanden; ik rek deadlines op en beveilig ze toch met validatie. Agressieve caching van HTML vertraagt zichtbare veranderingen; ik combineer no-cache met ETag en houd inhoud actueel. Met duidelijke beslissingen over versheid, validatie en geldigheid, los ik deze struikelblokken op en versterk ik de <strong>Planbaarheid<\/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\/05\/cache-validierung-5836.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gebruik Vary netjes en controleer representaties<\/h2>\n\n<p>Om ervoor te zorgen dat voorwaardelijke verzoeken veilig werken in gedeelde caches, zorg ik ervoor dat ik de juiste <strong>Vari\u00ebren<\/strong>. De header definieert welke request headers de weergave be\u00efnvloeden. Typische voorbeelden zijn <em>Accept-Encoding<\/em> (gzip, br), <em>Accept-Language<\/em> en <em>Accepteer<\/em>. Als ik inhoud per taal lever, stel ik Vary: Accept-Language in zodat een proxy niet de Duitse versie deelt in antwoord op een Frans verzoek. Voor gepersonaliseerde inhoud doe ik het bewust zonder Vary: Cookie en gebruik ik in plaats daarvan <em>Cachebeheer: priv\u00e9<\/em>, om een oncontroleerbare explosie van cachesleutels te voorkomen. Voor bronnen die alleen worden geleverd met geldige autorisatie, gebruik ik private of zorg ik voor een duidelijke scheiding met Vary: Authorisation of Vary op relevante headers. Consistentie is belangrijk: de geselecteerde set Vary-dimensies moet stabiel blijven, anders zullen de cache-hitrate en validatievoordelen instorten omdat er voortdurend nieuwe varianten worden gemaakt.<\/p>\n\n<h2>Sterke vs. zwakke ETags, compressie en bytegelijkheid<\/h2>\n\n<p><strong>Sterke ETags<\/strong> karakteriseren per byte identieke weergaven en maken nauwkeurige validatie mogelijk, ook in combinatie met bereikaanvragen. <strong>Zwakke ETags<\/strong> (W\/...) geven alleen inhoudelijke gelijkheid aan, niet noodzakelijk identieke bytes. In de praktijk gebruik ik sterke ETags als ik een unieke identifier kan genereren voor elke weergave (inclusief compressie). Zodra een reverse proxy on-the-fly gzip of brotli gebruikt, pas ik de ETag generatie aan of schakel over op zwakke ETags zodat de server en client niet ten onrechte verschillende bytes als identiek herkennen. Een robuuste variant is om de ETag te maken van de laatste bytes van het geleverde antwoord en tegelijkertijd gebruik te maken van <em>Vary: Accept-Encoding<\/em> worden ingesteld. Dit zorgt ervoor dat \u201egzip\u201c en \u201ebr\u201c elk hun eigen geldige ETags krijgen. Waar ik geen byte gelijkheid kan garanderen (bijv. verschillende timestamps in HTML), kies ik zwakke ETags die nog steeds betrouwbare 304 reacties toestaan zolang de betekenis van de pagina niet veranderd is.<\/p>\n\n<h2>Cachebeheer in fijnafstemming: s-maxage, must-revalidate, stale-while-revalidate<\/h2>\n\n<p>Naast <em>maximumleeftijd<\/em> Ik gebruik specifiek fijnere richtlijnen. <strong>s-maximum<\/strong> richt zich uitsluitend tot <em>Gedeelde caches<\/em> (CDN's, proxies) en stelt me in staat om daar agressiever te cachen dan in de browser. <strong>moet opnieuw worden gevalideerd<\/strong> dwingt klanten om verlopen inhoud niet heuristisch te gebruiken, maar altijd te valideren - handig voor kritieke gegevens. <strong>proxy-hervalideren<\/strong> adresseert deze verplichting specifiek voor gedeelde caches. Met <strong>stale-while-revalidate<\/strong> Ik sta toe dat een iets verouderde kopie kort wordt afgeleverd terwijl validatie op de achtergrond draait; gebruikers zien direct iets en de volgende aanvraag profiteert van verse metadata. <strong>stale-if-error<\/strong> als vangnet: Als de Origin faalt of fouten retourneert, mag de cache de laatst bekende kopie leveren voor een bepaalde tijd. Voor build-hashed assets combineer ik lange max-age met <em>onveranderlijk<\/em>, omdat de bestandsnaam samen met de inhoud verandert en tussentijdse validaties onnodig zijn. Voor HTML en API's blijft no-cache plus validator de gouden standaard om up-to-date te blijven en toch bandbreedte te besparen.<\/p>\n\n<h2>Verdere voorwaarden en methoden: HEAD, bereik en schrijfconflicten<\/h2>\n\n<p>Voorwaardelijke verzoeken zijn niet beperkt tot GET. A <strong>HEAD<\/strong>-request geeft alleen headers en is ideaal voor snelle validaties zonder body. Voor grote bestanden gebruik ik <strong>Bereik<\/strong>-verzoeken; met <strong>Als-bereik<\/strong> Ik zorg ervoor dat deelgebieden alleen worden verzonden als de bron nog steeds overeenkomt met de verwachte versie - anders antwoord ik met 200 en een volledige body. Voor schrijfbewerkingen zorg ik voor consistentie met <strong>Als-match<\/strong> ab: PUT, PATCH of DELETE werken alleen als de ETag van de client overeenkomt met de huidige versie; anders reageer ik met 412 Precondition Failed. Waar ik precondities wil afdwingen, bijvoorbeeld bij conflictgevoelige bronnen, gebruik ik 428 Precondition Required om clients If-Match te laten gebruiken. Ik kies bewust tussen 409 Conflict en 412: 412 signaleert geschonden randvoorwaarden, 409 benadrukt inhoudelijke conflicten (bijv. regels voor bedrijfslogica). Deze duidelijkheid vergemakkelijkt implementaties door clients en voorkomt blinde opheffingen.<\/p>\n\n<h2>Personalisatie, cookies en gegevensbescherming in de praktijk<\/h2>\n\n<p>Voor gepersonaliseerde pagina's markeer ik antwoorden met <strong>priv\u00e9<\/strong> of <strong>geen opslag<\/strong>. Ik vermijd het coderen van gebruikerstoestanden in e-tags omdat zulke \u201eper-gebruiker\u201c e-tags ongewild tracking markers kunnen worden. In plaats daarvan maak ik een strikt onderscheid tussen openbare en priv\u00e9weergaven. Ik zet alleen cookies in de cache key (Vary: Cookie) als dat absoluut noodzakelijk is, omdat ze het aantal varianten verhogen en de hit rate drastisch verlagen. Voor geautoriseerde API-reacties houd ik me aan <em>Cachebeheer: priv\u00e9<\/em> en, indien nodig, op Vary op de Authorisation header format. Zo zorg ik ervoor dat gedeelde caches niet per ongeluk vertrouwelijke antwoorden delen. In toepassingen met gemengde inhoud (openbaar basisraamwerk, gepersonaliseerde deelgebieden) vertrouw ik op gefragmenteerde caching of ESI\/SSI aan de rand, terwijl kritieke delen priv\u00e9 blijven. Het resultaat is gegevensbescherming zonder prestatieverlies.<\/p>\n\n<h2>Werking: CDN's, surrogaten en invalidaties<\/h2>\n\n<p>In CDN-opstellingen combineer ik <strong>s-maximum<\/strong> met duidelijke validators en - indien beschikbaar - gebruik surrogaat-specifieke richtlijnen om edge caches apart van de browser te beheren. Revalidatie vermindert de belasting op Origin, maar af en toe is een harde invalidatie nodig (bijv. voor een beveiligingsfix). Ik plan dan twee manieren: <em>Cache breken<\/em> via bestandsnaam-hashes voor statische activa en <em>Zuiveren<\/em>\/Invalidatie voor HTML en API's. Dit voorkomt \u201epurge storms\u201c en zorgt toch voor een korte time-to-freshness. Het is ook belangrijk om een consistente cache key te hebben in het CDN (inclusief host, pad, query parameters en relevante Vary headers). Voor query parameters maak ik bewust onderscheid tussen semantische (bijv. ?lang=) en puur tracking-gerelateerde parameters; deze laatste negeer ik in de cache key om fragmentatie te voorkomen. Dit houdt de keten van browser cache, tussenliggende proxy en CDN transparant en voorspelbaar.<\/p>\n\n<h2>304 in detail: Update header en metadata correct<\/h2>\n\n<p>Ook een <strong>304<\/strong>-Het antwoord bevat belangrijke metadata. Ik lever Datum, Cache-Control, ETag\/Last-Modified en - indien relevant - Expires en Vary opnieuw zodat de client zijn cache-items kan bijwerken. Content-Type en Content-Encoding hoeven niet per se herhaald te worden, maar kunnen bijdragen aan de duidelijkheid. Het is belangrijk dat 304 geen body payload bevat en dat ik consistente validators stuur: Het veranderen van de ETag in de 304 zonder de representatie te veranderen leidt tot verwarring. Als de richtlijnen worden aangepast (bijv. langere max-age), kan de client de metadata overnemen zonder de body opnieuw te hoeven laden - een kleine hefboom met een grote impact op de waargenomen prestaties.<\/p>\n\n<h2>Test- en debug-strategie\u00ebn voor schone validatie<\/h2>\n\n<p>Ik controleer specifiek de volgende punten in DevTools: <em>van schijfcache<\/em> vs. <em>van geheugencache<\/em> vs. <em>gerevalideerd<\/em>; Status 200\/304; Age header in antwoorden van gedeelde caches; ETag\/Last-Modified consistentie en het effect van Vary. Voor reproduceerbare tests deactiveer ik tijdelijk de browsercache of gebruik ik een priv\u00e9modus. Aan de serverkant evalueer ik logs op de 200\/304 ratio, de gemiddelde responsgrootte en CPU-gebruik. Waarschuwingssignalen zijn bijvoorbeeld veel 200 reacties op bronnen met korte wijzigingsintervallen (ontbrekende validators), revalidatielussen (afwijkende tijden\/klokdrift) of een ongebruikelijk groot aantal varianten per URL (overmatige Vary). Ik gebruik belastingstests om te controleren hoe s-maxage, stale-while-revalidate en if-none-match zich onder druk gedragen - en pas richtlijnen aan totdat doorvoer en latency overeenkomen.<\/p>\n\n<h2>Randgevallen en robuuste standaardinstellingen<\/h2>\n\n<p>Niet elke bron heeft duidelijke wijzigingsregels. Ik stel voorzichtige standaardwaarden in voor gegenereerde sitemaps, feeds of dashboards: <em>no-cache<\/em> plus ETag\/Last-Modified. Met onstabiele klokken tussen upstream systemen vermijd ik rigide secondevergelijkingen en geef ik de voorkeur aan ETags die onafhankelijk zijn van tijdstempels. Als de compressie variabel is (verschillende gzip niveaus), neem ik het resultaat van de compressie mee in de ETag generatie of schakel ik over op zwakke ETags. En als clients aanvragen zonder validators, stuur ik duidelijke signalen: Ofwel duidelijke versheid (max-age\/immutable) of duidelijke validatie (no-cache + ETag). Deze <em>robuuste standaardinstellingen<\/em> ervoor zorgen dat zelfs onvolledige of defecte clients geen ongewenste belastingspieken veroorzaken.<\/p>\n\n<h2>Korte samenvatting<\/h2>\n\n<p>Voorwaardelijke verzoeken verbinden <strong>Snelheid<\/strong> en tijdigheid door clients alleen volledige bronnen op te laten halen als de inhoud is gewijzigd. Ik gebruik cachecontrole voor versheid, combineer last-modified en ETag voor betrouwbare controles en reageer consequent met 304 als aan de voorwaarden wordt voldaan. Ik isoleer gepersonaliseerde en vertrouwelijke inhoud met private of no-store zodat er geen gegevens in gedeelde caches terechtkomen. Metingen in DevTools, logs en metrics laten me zien waar ik deadlines kan oprekken of validatielogica kan aanscherpen. Als je over deze bouwstenen nadenkt, zul je snellere pagina's, minder serverbelasting en een <strong>ronder<\/strong> Gebruikerservaring zonder gegevens te verspillen.<\/p>","protected":false},"excerpt":{"rendered":"<p>Leer hoe je met HTTP Conditional Requests en cachevalidatie met ETag, Last-Modified en Cache-Control je browsercaching optimaliseert en de prestaties verhoogt.<\/p>","protected":false},"author":1,"featured_media":19514,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-19521","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"94","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"HTTP Conditional","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":"19514","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/19521","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=19521"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/19521\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/19514"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=19521"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=19521"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=19521"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}