{"id":13985,"date":"2025-10-13T16:36:08","date_gmt":"2025-10-13T14:36:08","guid":{"rendered":"https:\/\/webhosting.de\/caching-ebenen-hosting-guide-einfach-verstehen-rocket\/"},"modified":"2025-10-13T16:36:08","modified_gmt":"2025-10-13T14:36:08","slug":"caching-levels-hosting-guide-simply-understand-rocket","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/caching-ebenen-hosting-guide-einfach-verstehen-rocket\/","title":{"rendered":"Caching levels in hosting: opcode, object, page &amp; CDN caching explained"},"content":{"rendered":"<p><strong>Caching levels<\/strong> in hosting accelerate PHP execution, database access and the delivery of complete pages through to global provision via edge servers. I will show you how opcode, object, page and CDN caches work together, where they come into play and which settings have the greatest effect.<\/p>\n\n<h2>Key points<\/h2>\n\n<ul>\n  <li><strong>Opcode<\/strong> Cache pre-compiles PHP and reduces the load on CPUs for each request.<\/li>\n  <li><strong>Object<\/strong> Cache keeps frequent database results in RAM and saves queries.<\/li>\n  <li><strong>Page<\/strong> Cache delivers finished HTML to visitors in milliseconds.<\/li>\n  <li><strong>CDN<\/strong> Cache distributes content to edge servers worldwide and reduces latencies.<\/li>\n  <li><strong>Interaction<\/strong> of all levels eliminates bottlenecks from backend to edge.<\/li>\n<\/ul>\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\/2025\/10\/hosting-caching-server-8427.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>What caching layers do<\/h2>\n\n<p>I use four <strong>Levels<\/strong>to reduce loading times and server load: opcode, object, page and CDN. Each level addresses a different bottleneck and works on its own level of the infrastructure. In this way, I save CPU time when executing code, reduce database queries, deliver HTML directly and bring content geographically closer to the user. I prioritize the biggest bottleneck first and gradually add to the remaining caches. This clear <strong>Sequence<\/strong> makes optimization measurable and stable.<\/p>\n\n<h2>Opcode Cache: Execute PHP immediately<\/h2>\n\n<p>The opcode cache stores precompiled PHP opcodes in the <strong>RAM<\/strong>so that the interpreter does not work again with every request. I activate OPcache with sensible limits for memory, file cache and revalidation so that hot code paths are permanently available. CMS pages in particular benefit because recurring calls no longer trigger compilation. This noticeably reduces the CPU load and the response time of the web server. I regularly check the OPcache statistics to check the <strong>Cache hit rate<\/strong> high.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/10\/cachingmeeting2024_7582.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Object cache: Relieve database<\/h2>\n\n<p>The object cache stores frequent results from <strong>Queries<\/strong> in memory, for example menus, product lists or user rights. I use in-memory services such as Redis or Memcached for this and allocate meaningful TTLs for volatile data. This allows me to significantly reduce round trips to the database, which remains stable, especially with heavy traffic. In WordPress, I combine persistent object caching with targeted exclusions so that personalized content is not distorted. If you want to get started, you can find a compact guide in my article on <a href=\"https:\/\/webhosting.de\/en\/configure-caching-wordpress-redis-speed-up-performance-9324\/\">Redis for WordPress<\/a>. I observe the <strong>Miss rate<\/strong>to readjust keys with too short a service life.<\/p>\n\n<h2>Page Cache: Deliver HTML<\/h2>\n\n<p>The page cache creates complete <strong>HTML<\/strong>-pages that the system has generated dynamically. I define clear rules: anonymous visitors receive static copies, logged-in users bypass the cache. During updates, I specifically clear affected pages so that content remains up-to-date. This pays off, especially during traffic peaks, because I reduce the backend load to virtually zero. A practical sequence of steps is shown in my <a href=\"https:\/\/webhosting.de\/en\/caching-website-optimization\/\">Website caching guide<\/a>. I regularly check Time-To-First-Byte to ensure the <strong>Effect<\/strong> to verify.<\/p>\n\n<h2>CDN cache: globally fast<\/h2>\n\n<p>A CDN brings content to <strong>Edge<\/strong>-server close to the user, thus reducing latency. I cache assets such as images, CSS and JS and, if required, complete pages via full-page caching. Rules for cookies, headers and query parameters prevent incorrect delivery of personalized content. For international target groups, I noticeably shorten loading times and reduce the load on my origin server. If you want to read more about the setup, click on my overview of the <a href=\"https:\/\/webhosting.de\/en\/cdn-optimization-content-delivery\/\">CDN optimization<\/a>. I have purge mechanisms ready to ensure that when releases are made, fresh <strong>Versions<\/strong> to be delivered.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/10\/caching-ebenen-webhosting-3247.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparison of the caching levels<\/h2>\n\n<p>The following table classifies <strong>Use<\/strong> and effect so that I address the right level first.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Level<\/th>\n      <th>Storage location<\/th>\n      <th>Typical application<\/th>\n      <th>Main advantages<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Opcode cache<\/td>\n      <td>Server (RAM)<\/td>\n      <td>PHP-based websites, CMS<\/td>\n      <td>Faster execution, less CPU<\/td>\n    <\/tr>\n    <tr>\n      <td>Object cache<\/td>\n      <td>Server (RAM)<\/td>\n      <td>Frequent DB queries in shops\/CMS<\/td>\n      <td>Fewer queries, short response times<\/td>\n    <\/tr>\n    <tr>\n      <td>Page Cache<\/td>\n      <td>Server and\/or CDN<\/td>\n      <td>Anonymous page views<\/td>\n      <td>Very short TTFB, load reduction<\/td>\n    <\/tr>\n    <tr>\n      <td>CDN Cache<\/td>\n      <td>Edge server<\/td>\n      <td>Global delivery of pages\/assets<\/td>\n      <td>Low latency, high scalability<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>I set the levels in this <strong>Sequence<\/strong> first opcode, then object, then page and finally CDN. This way I avoid duplicating work and get the most noticeable effects first.<\/p>\n\n<h2>Interaction of the levels<\/h2>\n\n<p>In my process, the <strong>Opcode<\/strong> Cache first PHP without recompilation. The object cache delivers frequent data from RAM, leaving the database free. The page cache serves recurring pages directly and saves PHP and DB layers. A CDN provides content close to the user worldwide and intercepts traffic peaks. This chain reduces any waiting time because I specifically make each stage faster and reduce dependencies. I keep this <strong>Path<\/strong> transparent so that debugging remains easy.<\/p>\n\n<h2>TTL, purge and cache validation<\/h2>\n\n<p>I consciously forgive <strong>TTLs<\/strong> for each level so that content is neither too old nor too short-lived. For releases, I use purge by path, tag or key to purge specifically instead of deleting everything. Edge caches respect control signals such as cache control, surrogate control or ETag. For personalized content, I use Vary headers or cookie rules to prevent cache mixing. I test invalidation in staging systems before placing larger campaigns. This keeps content <strong>consistent<\/strong>even if I combine many levels.<\/p>\n\n<h2>Measurement: Hit rate and misses<\/h2>\n\n<p>I measure the <strong>Hit rate<\/strong> separately for each level so that cause and effect remain clear. For OPcache, I check memory allocation, revalidations and compilations. For the object cache, I observe misses per key and adjust TTLs. For the page cache, I correlate HIT\/MISS with TTFB to see the effect on users. In the CDN, I monitor regional latencies and edge hit rates to ensure that all sites perform reliably. These key figures control my next <strong>Optimizations<\/strong>.<\/p>\n\n<h2>Edge cases: dynamic content<\/h2>\n\n<p>I cache login pages, shopping baskets or personalized dashboards a lot <strong>careful<\/strong>. I work with exceptions, no-cache headers, short TTLs or Edge Side Includes (ESI) for sub-areas. Search parameters or session cookies can generate variants that I deliberately limit. APIs also benefit from caching, but require exact invalidation for releases. For highly volatile content, I use object cache rather than page cache. So answers remain <strong>correct<\/strong>without losing speed.<\/p>\n\n<h2>Configuration by hosting type<\/h2>\n\n<p>In shared hosting I activate <strong>OPcache<\/strong> and use a persistent object cache, if available. In VPS or dedicated environments, I provide Redis\/Memcached, isolate resources and set up monitoring. For page cache, I choose server-side solutions or integrated modules of the stack. I also activate a CDN if target groups are distributed or peaks are pending. I document all cache rules so that team members can roll out changes safely. Uniform <strong>Standards<\/strong> prevent misconfigurations.<\/p>\n\n<h2>Security and caching<\/h2>\n\n<p>I combine <strong>CDN<\/strong>-caching with protection mechanisms such as rate limiting and WAF rules. This buffers load peaks and keeps malicious patterns away before they reach the origin. TLS termination at the edge reduces latency and relieves the load on the host systems. I never cache sensitive content, for example admin areas or personal data. I check logs regularly so that cache bypasses and purges remain traceable. Security and <strong>Speed<\/strong> are not mutually exclusive if the rules are clear.<\/p>\n\n\n\n<h2>HTTP header in detail: precise control<\/h2>\n\n<p>Clean headers determine how reliably caches work. I use <strong>Cache control<\/strong> as the primary signal and combine it depending on the level: public, max-age for browsers\/proxies and s-maxage for shared caches. <strong>stale-while-revalidate<\/strong> allows you to briefly deliver outdated content while it is updated in the background. With <strong>stale-if-error<\/strong> I keep the site online, even if the source is temporarily unavailable. <strong>ETag<\/strong> and <strong>Last-Modified<\/strong> help with conditional queries; I use them specifically when content needs to be frequently revalidated instead of completely retransmitted. <strong>Vary<\/strong> I limit them to really necessary dimensions (e.g. cookie for logged-in users, accept encoding for compression) so that there is no uncontrollable explosion of variants. For edge caches I use <strong>Surrogate control<\/strong>to control CDN-specific TTLs without affecting browser caching.<\/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\/2025\/10\/cachingebenen-techoffice-9482.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cache warming and preloading<\/h2>\n\n<p>To avoid cold starts, I warm up caches <strong>proactive<\/strong> on: After a deployment, I have important routes, category pages and landing pages automatically rendered and placed in the page and CDN cache. I prioritize according to traffic, sales relevance and depth of navigation. Sitemaps, internal link graphs or logs from the last few days serve as a source. Preloading is throttled so that the source is not overloaded. For object caches, I prefill expensive aggregations or authorization structures so that the first wave of users after a release receives consistently fast responses.<\/p>\n\n<h2>Versioning and cache busting<\/h2>\n\n<p>I provide static assets with <strong>Content hash<\/strong> in the file name (e.g. app.abc123.css). This allows me to set very long TTLs without the risk of stale. On release, only the URL changes, caches keep old versions until they expire. For HTML or API responses, I work with <strong>Cache tags<\/strong> or structured keys that allow targeted purging (e.g. all pages of a product). Where tagging is not possible, I plan purges by path and ensure sufficient headroom in the cache so that new objects can be placed immediately. Important: no unnecessary <strong>no-store<\/strong> on assets, otherwise I give away global performance gains.<\/p>\n\n<h2>Avoid cache stampede<\/h2>\n\n<p>If a frequently used key falls out of the cache, there is a risk of a <strong>Thundering stove<\/strong>-situation. I prevent this with <strong>Request coalescing<\/strong>Only the first miss is allowed to calculate, all others wait for its result. In object caches, I set locks with a short TTL to prevent duplicate work. I also use <strong>Early Refresh<\/strong>If a key is about to expire, it is renewed by a few background processes, while users still receive the old, valid version. I use jitter (random offset) to distribute processes so that thousands of keys do not expire at the same time. At API level, idempotency helps to enable repetitions without side effects.<\/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\/2025\/10\/caching-hosting-desktop-1943.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Personalization, A\/B tests and variants<\/h2>\n\n<p>Where personalization is unavoidable, I limit it. <strong>minimal<\/strong> off. Instead of varying the whole page, I render small, non-cacheable fragments (ESI) or reload them on the client side. With <strong>A\/B tests<\/strong> I avoid cookie-based variants for all assets; otherwise everything ends up in the browser's private cache and shared caches become useless. Instead, I only encapsulate the relevant part of the page or work with server-side playout that does not break up the page cache. For currency or language selection, I define unique paths (e.g. \/de\/, \/en\/) instead of Accept-Language so that caches receive deterministic keys.<\/p>\n\n<h2>Compression, formats and Vary<\/h2>\n\n<p><strong>Gzip<\/strong> or <strong>Breadstick<\/strong> reduce the transfer size, but also influence cache keys: I keep Vary: Accept encoding lean and ensure that edge caches are allowed to save pre-compressed variants. I optimize images with modern formats (WebP, AVIF) and device-compatible sizes. I take care not to set any unnecessary vars on user agents in order to avoid a flood of variants. A few, clearly defined breakpoints or responsive image attributes that can be cached cleanly are better. For critical CSS\/JS bundles, I use long caching plus versioning to serve recurring traffic from the cache at practically zero cost.<\/p>\n\n<h2>OPcache fine-tuning in practice<\/h2>\n\n<p>For <strong>OPcache<\/strong> I plan RAM generously so that frequently used scripts are not displaced. I monitor the number of revalidations and compilations; if they increase, I increase the script memory or optimize the autoloader. <strong>file cache<\/strong> for preloading can reduce cold starts if deployments are rare. A consistent deploy strategy is important: If timestamps change frequently, OPcache invalidates permanently - I minimize unnecessary changes to many files at the same time. I use preloading to initialize critical classes at the start so that the first requests benefit immediately.<\/p>\n\n<h2>API and microservice caching<\/h2>\n\n<p>Receive APIs <strong>own<\/strong> Cache strategies. GET endpoints with stable results get clear TTLs and ETags, while POST\/PUT are not cacheable. I tag keys according to domain objects (e.g. user:123, product:456) and derive invalidation directly from system events. For GraphQL, I aggregate at field level and cache frequent subtrees to mitigate N+1 queries. I combine rate limits with caching so that expensive aggregations are not recalculated unchecked. Edge caches can store API responses regionally as long as consistency requirements allow.<\/p>\n\n<h2>Monitoring and observability<\/h2>\n\n<p>I extend answers by <strong>Diagnostic header<\/strong> (e.g. HIT\/MISS, Age, Revalidate) to see the behavior in the field. In logs, I correlate status codes, TTFB and upstream times; a sudden increase in MISS with a simultaneous CPU peak indicates cache eviction or faulty invalidation. I separate dashboards by level: OPcache utilization, Redis latencies, page cache hit rate, CDN edge hit rate and regional latencies. For releases, I define SLOs (e.g. 95th percentile TTFB below X ms) and rollbacks if the metrics tilt. I supplement synthetic checks with real user monitoring to cover real devices and networks.<\/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\/2025\/10\/hosting-caching-ebenen-7142.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Operation, costs and scaling<\/h2>\n\n<p>I also optimize TTLs under <strong>Cost aspects<\/strong>Longer CDN TTLs increase the edge hit rate and reduce origin traffic, but reduce purge windows. Short TTLs increase transfer and load. I control purges finely (by tag\/key) instead of globally to avoid edge cold starts. For multi-region setups, I take replication times into account so that one region does not remain stale while the other is already fresh. I plan capacity for stampedes (autoscaling, burst RAM) and have emergency routes ready that remain performant with greatly simplified responses even in the event of partial failures. This keeps the system economical and <strong>robust<\/strong>.<\/p>\n\n<h2>SEO and Core Web Vitals<\/h2>\n\n<p>Heavy use of cache improved <strong>TTFB<\/strong> and subsequently LCP, which has a positive impact on user satisfaction and crawling budget. It is important that caching does not deliver outdated metadata, canonicals or hreflang variants. I decouple HTML cache from highly volatile parts and update critical pages (homepage, categories) as a priority. For bot traffic, I set realistic TTLs and avoid unnecessary 304 responses by actually keeping content fresh instead of revalidating every request. This keeps the site fast and consistent - for humans and crawlers.<\/p>\n\n<h2>Briefly summarized<\/h2>\n\n<p>I arrange <strong>Caching<\/strong> strategic: accelerate code first, then data, then pages and finally distribute globally. This schedule delivers measurably better loading times and saves server costs. I keep TTLs, purges and exceptions cleanly documented so that releases run smoothly. Metrics such as hit rate, TTFB and edge latency guide my next steps. If you combine these levels consistently, you create fast, scalable and reliable <strong>Websites<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Find out everything you need to know about the central caching levels in hosting - from opcode to CDN cache. For the best performance and optimal hosting!<\/p>","protected":false},"author":1,"featured_media":13978,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[733],"tags":[],"class_list":["post-13985","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"2209","_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":null,"_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":"caching ebenen","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":"13978","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/13985","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=13985"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/13985\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/13978"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=13985"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=13985"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=13985"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}