{"id":20021,"date":"2026-06-15T08:34:43","date_gmt":"2026-06-15T06:34:43","guid":{"rendered":"https:\/\/webhosting.de\/http-conditional-caching-etag-last-modified-performance-guide\/"},"modified":"2026-06-15T08:34:43","modified_gmt":"2026-06-15T06:34:43","slug":"http-conditional-caching-etag-last-modified-and-performance-guide","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/http-conditional-caching-etag-last-modified-performance-guide\/","title":{"rendered":"Understanding HTTP Conditional Caching with ETag and Last-Modified"},"content":{"rendered":"<p>HTTP caching saves time and data by reloading resources only when they have actually changed. Via <strong>ETag<\/strong> and <strong>Last-Modified<\/strong> I use a conditional request to check whether the server responds with a 304 Not Modified status, which significantly reduces data transfer and server load.<\/p>\n\n<h2>Key points<\/h2>\n\n<p>The following key points highlight what I focus on when using conditional caching with <strong>ETag<\/strong> and <strong>Last-Modified<\/strong> eighth.<\/p>\n<ul>\n  <li><strong>Less traffic<\/strong>: Unmodified files return a 304 status code instead of the entire body\u2014this significantly reduces data usage and latency.<\/li>\n  <li><strong>Better performance<\/strong>: Shorter wait times improve UX and Core Web Vitals, which <strong>SEO<\/strong> helps.<\/li>\n  <li><strong>Two mechanisms<\/strong>: Last-Modified\/If-Modified-Since and ETag\/If-None-Match reliably validate the cache.<\/li>\n  <li><strong>Cache control<\/strong>: Directives control freshness, revalidation, and behavior in intermediate caches.<\/li>\n  <li><strong>Combination<\/strong>: Together, these two methods offer high accuracy and simple fallbacks.<\/li>\n<\/ul>\n<p>First, I check which resources change frequently and which ones rarely. For files that are rarely modified, I set a <strong>Last-Modified<\/strong>-time and add an ETag. For dynamic responses, I prefer to use the <strong>ETag<\/strong>, because any changes to the content are immediately noticeable. This way, I reduce the load on the servers, minimize latency, and deliver pages very quickly to returning visitors. This strategy strengthens the <strong>Core Web Vitals<\/strong> and thus, indirectly, visibility.<\/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\/06\/conditional-caching-8923.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>HTTP Conditional Caching: How to Check Validity<\/h2>\n\n<p>When the request is made again, the client sends additional headers along with the GET request, which I evaluate on the server side. If the resource has the same <strong>ETag<\/strong> If the content matches the cached version (If-None-Match), I return a 304 Not Modified response without a body. If the timestamp hasn\u2019t changed (If-Modified-Since), the server also responds with a 304. If the day or date is no longer correct, I send a 200 OK with new content plus an updated <strong>Last-Modified<\/strong> and ETag. This saves bandwidth, keeps the cache up to date, and ensures noticeably faster load times.<\/p>\n\n<h2>Last-Modified and If-Modified-Since in Everyday Use<\/h2>\n\n<p>The header <strong>Last-Modified<\/strong> I rely on the actual modification time of the file, such as the one from the file system. If a request later arrives with an \"If-Modified-Since\" header and the resource hasn't changed since then, I respond with a 304. This approach is straightforward, easy to understand, and ideal for static assets like CSS, JS, or images. Limitations arise from the second-based grid of HTTP timestamps and situations where content changes logically without a clear file modification timestamp. Where Last-Modified reaches its limits, a <strong>ETag<\/strong> control.<\/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\/06\/meeting_http_caching_4573.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>ETag and If-None-Match in Dynamic Systems<\/h2>\n\n<p>A <strong>ETag<\/strong> I generate it as a hash, a version ID, or from a database column that tracks state changes. Upon subsequent access, the browser sends an If-None-Match header; I compare the tag with my current value and respond accordingly with a 304 or 200 status code. This comparison detects any meaningful content changes without relying on file timestamps. This delivers very accurate results, especially with APIs, composite pages, or personalized fragments. It remains important that I keep ETags consistent in cluster environments so that no server accidentally uses a different <strong>Day<\/strong> generated.<\/p>\n\n<h2>Combining Cache-Control Properly<\/h2>\n\n<p>With <strong>Cache control<\/strong> I define how long content is considered fresh without a request and when the browser revalidates it. I set appropriate max-age values based on the frequency of changes and use must-revalidate if outdated data would be critical. A long validity period is suitable for versioned files, while frequently changing responses have a shorter lifespan and can then be reliably verified using ETag or date. This is how I combine fast response times with accurate timeliness. If you want to delve deeper, you\u2019ll find many examples at <a href=\"https:\/\/webhosting.de\/en\/http-cache-control-strategies-hosting-cachemaster\/\">Cache-Control Strategies<\/a>, that I use in my practice.<\/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\/06\/http-caching-etag-concept-3892.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Step-by-Step Guide to a Conditional GET Request<\/h2>\n\n<p>On the first request, the server returns a 200 OK response with Cache-Control, <strong>Last-Modified<\/strong> and ETag; the browser stores everything. On the next visit, the age of the cached data determines whether revalidation is necessary. If revalidation is required, the browser sends a request using If-None-Match and\/or If-Modified-Since. If the values match the current state, I send a 304 Not Modified response, and the client continues to use its cache. If they no longer match, a 200 OK response follows with a new body and updated <strong>Validation data<\/strong>.<\/p>\n\n<h2>Comparison: ETag vs. Last-Modified<\/h2>\n\n<p>Both methods give me control, but they differ in terms of effort, accuracy, and suitability. <strong>Last-Modified<\/strong> It stands out for its ease of implementation and clear semantics, as long as I have clean timestamps. The ETag accurately reflects the content, but requires some logic to generate. In many setups, I combine both and thus benefit from simplicity plus precise identification. The following table summarizes typical characteristics and helps with the decision.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Aspect<\/strong><\/th>\n      <th><strong>Last-Modified<\/strong><\/th>\n      <th><strong>ETag<\/strong><\/th>\n      <th><strong>Note<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Identity<\/td>\n      <td>Timestamp of the last change<\/td>\n      <td>Content hash or version ID<\/td>\n      <td><strong>Time<\/strong> vs. content-based identifier<\/td>\n    <\/tr>\n    <tr>\n      <td>Change detection<\/td>\n      <td>Second resolution, indirect<\/td>\n      <td>Directly focused on the content<\/td>\n      <td>ETag detects the smallest <strong>Diffs<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>implementation<\/td>\n      <td>Very lightweight; the file system is sufficient<\/td>\n      <td>Requires generation and consistency<\/td>\n      <td>Clusters need the same <strong>ETags<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Use<\/td>\n      <td>Static assets<\/td>\n      <td>Dynamic Responses<\/td>\n      <td>This combination covers many <strong>Cases<\/strong> from<\/td>\n    <\/tr>\n    <tr>\n      <td>Answers<\/td>\n      <td>304 with the timestamp unchanged<\/td>\n      <td>304 with the same date<\/td>\n      <td>200 for changes with a new <strong>Value<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/tech_office_caching_4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Best Practices: Efficiently Delivering Static Assets<\/h2>\n\n<p>Static files such as CSS, JavaScript, and images rarely change and are suitable for long-term use <strong>max-age<\/strong>-times. For versioned files, I set high values of up to one year and mark them as immutable so that the browser loads them without checking. For non-versioned assets, I choose shorter time limits and rely on revalidation via ETag and Last-Modified. This way, I avoid outdated content and keep traffic low. If I make sure not to <a href=\"https:\/\/webhosting.de\/en\/http-cache-headers-sabotage-caching-cachefix\/\">Sabotage cache header<\/a> By doing this, I achieve a high hit rate in the cache.<\/p>\n\n<h2>Practical Application: APIs and Dynamic Pages<\/h2>\n\n<p>When it comes to APIs, I usually rely on <strong>ETags<\/strong>, which I generate from the serialized result or a version column. If the data record changes, I generate a new tag, and clients recognize this immediately. For content with an unreliable timestamp, I often omit the Last-Modified header to avoid giving a false impression of recency. Additionally, I control the lifespan via Cache-Control and force revalidation upon expiration. This way, I reliably keep data fresh without making responses unnecessarily large.<\/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\/06\/developer_desk_caching_3947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Testing and Monitoring for Cache Hit Rate<\/h2>\n\n<p>I check headers such as <strong>ETag<\/strong>, Last-Modified, If-None-Match, and If-Modified-Since in the Developer Tools. I pay close attention to the response codes\u2014especially 304 versus 200\u2014to assess the effectiveness of my revalidation. If 304 is rarely encountered, I adjust Cache-Control, expiration times, and ETag generation. Logs and metrics show me which paths are returning unnecessarily large responses. For bundled improvements, I like to use a <a href=\"https:\/\/webhosting.de\/en\/http-conditional-requests-cache-validation-optimization-package\/\">Conditional Requests Package<\/a>, that combines configuration and testing.<\/p>\n\n<h2>Hosting Architecture and ETag Pitfalls<\/h2>\n\n<p>In multi-server setups, a <strong>ETag<\/strong> be independent of the instance, otherwise recognition will fail. I ensure that all nodes use the same logic and the same key for generation. Reverse proxies or CDNs must not modify ETags and should pass along condition headers correctly. For deployments using asset fingerprints, I avoid server-side ETag recalculation if the file already has a versioned URL. Consistent rules prevent inconsistent responses and keep the cache hit rate high.<\/p>\n\n<h2>Freshness vs. Validation: Using Directives Precisely<\/h2>\n\n<p>I make a clear distinction between <em>freshness<\/em> (How long can a cache use a copy without checking?) and <em>Validation<\/em> (How do I check if it's still valid?). About <strong>Cache control<\/strong> I control both with fine granularity: <strong>max-age<\/strong> specifies the lifetime on the client, <strong>s-maxage<\/strong> for shared caches such as proxies. <strong>public<\/strong> allows caching in shared caches, <strong>private<\/strong> it limits it to the end-user browser. <strong>must revalidate<\/strong> forces a prompt after expiration, while <strong>immutable<\/strong> prevents unnecessary revalidations for versioned assets. <strong>no-cache<\/strong> does not prohibit caching, but always requires revalidation; <strong>no-store<\/strong> on the other hand, completely prohibits saving. Older <strong>Expires<\/strong>- I only use headers as a fallback; I consistently rely on Cache-Control for the logic. And if I want to mitigate outages, <strong>stale-while-revalidate<\/strong> and <strong>stale-if-error<\/strong>, ...so I can share content that has recently expired while I update things in the background or work around errors.<\/p>\n\n<h2>Strong and weak ETags, compression, and variants<\/h2>\n\n<p>I deliberately distinguish between strong and weak validators. <strong>Strong ETags<\/strong> identify the exact same representation, byte for byte\u2014ideal if I also <strong>Range Requests<\/strong> wants to operate efficiently. <strong>Weak ETags<\/strong> (Prefix <code>W\/<\/code>) are sufficient when semantic equivalence is enough, such as in the case of minor, irrelevant formatting changes. What matters is how to handle <strong>Compression<\/strong>: If I serve both gzip- and Brotli-compressed content, a single ETag cannot apply to all variants. Either I generate the ETag based on the uncompressed version and also set an appropriate <strong>Vary: Accept-Encoding<\/strong>, or I generate consistent but unique ETags for each variant. This prevents false positives and 200 responses that should actually be 304s. In <strong>If-Range<\/strong> I combine range queries with a validator: If the ETag or date matches, I respond with a 206 Partial Content status code; otherwise, I return a 200 status code with the full body so that the client has a consistent baseline.<\/p>\n\n<h2>Mastering Vary headers and content negotiation<\/h2>\n\n<p>Whenever the server returns different representations depending on the request, I set <strong>Vary<\/strong> Correct. Typical candidates are <strong>Accept-Encoding<\/strong> (compression), <strong>Accept-Language<\/strong> (localization) or specific feature flags. I avoid using volatile headers such as <strong>User agent<\/strong> or even <strong>Cookie<\/strong> to vary, because that really messes up the cache hit rate. Where personalization is needed, I mark answers as <strong>private<\/strong> or <strong>no-store<\/strong> and clearly separate them from publicly cacheable resources. Important: Variations also affect ETags\u2014each variant needs its own, consistent validator. This ensures that browsers, proxies, and CDNs apply the same logic and that no variant is accidentally mixed up with another.<\/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\/06\/httpcaching-verstehen-2638.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Conditional requests beyond GET<\/h2>\n\n<p>Conditional requests don't just work when reading. For write methods, I use <strong>If-Match<\/strong> or <strong>If-Unmodified-Since<\/strong>in order to <em>missing updates<\/em> to prevent this. If the client sends the last seen ETag in a PUT or DELETE request via <strong>If-Match<\/strong> If the server status is still the same, I'll make the change; otherwise, I'll respond with <strong>412 Precondition Failed<\/strong>. To enforce discipline among clients, the server can also <strong>428 Precondition Required<\/strong> set up. For quick tests without a body, I use <strong>HEAD<\/strong>, which returns the same headers as a GET request; ideal when I want to test metadata. And with <strong>304<\/strong>-In my responses, I include all headers relevant to caching (Cache-Control, ETag, Expires, Last-Modified) so that the client can update its metadata without having to transfer the body.<\/p>\n\n<h2>Security, data protection and compliance<\/h2>\n\n<p>I do not store personal or sensitive content in the public cache. Here, I <strong>Cache control: private<\/strong> or <strong>no-store<\/strong>, so that the browser\u2014or no instance at all\u2014persists the content. Be careful with user accounts and dashboards: Responses with <strong>Set cookie<\/strong> or <strong>Authorization<\/strong> must not accidentally be publicly cacheable. ETags themselves can be misused as a tracking vector if they remain stable over a long period of time. I address this by actively using validators only where caching is intended, and by disabling them for user-specific routes or keeping their lifespan short. This way, I balance performance with data protection requirements.<\/p>\n\n<h2>Implementation details and performance costs<\/h2>\n\n<p>Generating an ETag should not cost more than the benefit it provides. For large files or expensive renders, I store the tag along with metadata (file checksum, build hash, database\u2014<em>row version<\/em>) and don't re-render it with every request. For composite pages, a <em>Versioning Strategy<\/em>: I construct the ETag from stable sub-ETags (e.g., template, data fragment, configuration) so that small changes result in a specific but reproducible new value. In clusters, I synchronize the generation logic in a shared library and test it in CI to ensure no instance deviates. For extremely large blobs, I rely on fast checksums (CRC64) or store build hashes instead of hashing the body on the fly. Where absolute byte-for-byte equality is not necessary, <strong>weak ETags<\/strong> as a pragmatic compromise.<\/p>\n\n<h2>Common mistakes and how to avoid them<\/h2>\n\n<ul>\n  <li><strong>Random ETags<\/strong>: If tags are regenerated with every request, revalidation is pointless. I ensure that values are deterministic and only change when there is an actual change.<\/li>\n  <li><strong>Incorrect combination of directives<\/strong>: <em>no-store<\/em> Using ETag doesn't help\u2014the browser doesn't cache the data anyway. I choose consistent combinations to achieve the desired behavior.<\/li>\n  <li><strong>Excessive Vary<\/strong>: Variations in the Cookie or User-Agent headers break the cache. I restrict Vary to genuine changes in representation.<\/li>\n  <li><strong>Compression traps<\/strong>: A shared ETag for gzip and br results in false positives. I properly associate ETags with the specific variant and set the Vary header correctly.<\/li>\n  <li><strong>Time drift<\/strong>: Inaccurate server clocks can skew the \"Last-Modified\" header. I keep time sources synchronized so that \"If-Modified-Since\" works correctly.<\/li>\n  <li><strong>Confusion regarding \"no-cache\"<\/strong>: Many people read this as \u201edo not cache.\u201c What is meant is \u201ealways revalidate.\u201c For a true prohibition, I use <em>no-store<\/em>.<\/li>\n<\/ul>\n\n<h2>Troubleshooting, Metrics, and Workflows<\/h2>\n\n<p>To troubleshoot, I start in the Network tab: Is this correct? <strong>Cache control<\/strong>? Occurs during rehabilitation <strong>304<\/strong> Instead of 200? That works. <strong>ETag<\/strong> and <strong>Last-Modified<\/strong> between the request and the response? I'll check <strong>Vary<\/strong>, to see if variants are detected correctly. In the logs, I check <em>Hit or Miss<\/em>-Output hit rates, 304 rates, and average response sizes per path. If the 304 rate increases, data volume and TTFB typically decrease noticeably. In load tests, I simulate repeat requests to measure revalidation costs rather than transfer costs. If anomalies arise, I gradually eliminate interfering factors: Set-Cookie, overly strict Vary rules, conflicting headers like Pragma. This allows me to quickly identify the bottleneck that is dragging down the hit rate.<\/p>\n\n<h2>Service Workers as a supplementary caching layer<\/h2>\n\n<p>When I use a service worker, I use it as an additional layer, not as a conflicting one. I let it handle the same <strong>Cache control<\/strong>-Respect signals and combine strategies such as <em>stale-while-revalidate<\/em> deliberately uses HTTP validation via ETag and Last-Modified. For offline scenarios, the worker can serve temporarily outdated resources and revalidate them in the background. It remains important that it correctly passes on the condition headers; otherwise, I lose the benefits of 304 over the network. This way, PWA scenarios also benefit from proper HTTP caching instead of circumventing its mechanisms.<\/p>\n\n<h2>SEO Impact and Core Web Vitals<\/h2>\n\n<p>Improve quick replies <strong>UX<\/strong> and user signals, which improves rankings. Returning visitors benefit in particular because their browsers retrieve many files directly from the cache or via a 304 response. This reduced latency has a positive effect on FCP, LCP, and TTFB, which I lower through targeted revalidation. In addition, the server saves processing time, which I can use for peak loads or complex requests. This allows me to maintain performance while ensuring content is delivered correctly and promptly.<\/p>\n\n<h2>Summary: My Action Plan<\/h2>\n\n<p>I rely on a clear <strong>Combination<\/strong> based on Cache-Control, Last-Modified, and ETag. For static assets, I set long expiration times and use revalidation as a safeguard when files aren\u2019t versioned. For dynamic responses, I generate robust ETags and maintain cluster consistency. I then use tools, metrics, and logs to check whether 304 responses occur frequently enough and adjust settings accordingly. This ensures fast delivery, lower load, and a better user experience through effective <strong>HTTP Caching<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Learn how HTTP conditional caching works with ETag and Last-Modified, how browser cache validation is implemented, and how you can use it to optimize load times, bandwidth, and server load.<\/p>","protected":false},"author":1,"featured_media":20014,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20021","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":"116","_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 Caching","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20014","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20021","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=20021"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20021\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/20014"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=20021"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=20021"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=20021"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}