{"id":16643,"date":"2026-01-07T15:07:48","date_gmt":"2026-01-07T14:07:48","guid":{"rendered":"https:\/\/webhosting.de\/object-cache-datenbank-tuning-vorteile-redis-cacheboost\/"},"modified":"2026-01-07T15:07:48","modified_gmt":"2026-01-07T14:07:48","slug":"object-cache-database-tuning-vantaggi-redis-cacheboost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/object-cache-datenbank-tuning-vorteile-redis-cacheboost\/","title":{"rendered":"Perch\u00e9 la cache degli oggetti offre pochi vantaggi senza l'ottimizzazione del database"},"content":{"rendered":"<p><strong>Cache degli oggetti<\/strong> spesso porta a risultati deludenti se il database WordPress non viene curato e le query lente bloccano il server. Vi mostrer\u00f2 perch\u00e9 un approccio mirato <strong>Ottimizzazione del database<\/strong> \u00e8 il presupposto per una velocit\u00e0 tangibile e come entrambi insieme garantiscono un reale risparmio di tempo di caricamento.<\/p>\n\n<h2>Punti centrali<\/h2>\n<ul>\n  <li><strong>Colli di bottiglia DB<\/strong>: i metacampi non indicizzati e le opzioni gonfiate rallentano qualsiasi cache.<\/li>\n  <li><strong>sinergia<\/strong>: Page Cache accelera l'HTML, Object Cache alleggerisce le parti dinamiche.<\/li>\n  <li><strong>Prima la messa a punto<\/strong>: Indici, pulizia dell'autoload, riduzione delle query lente.<\/li>\n  <li><strong>Redis corretto<\/strong>: prestare attenzione a TTL, invalidazione, gruppi di chiavi e monitoraggio.<\/li>\n  <li><strong>Ospitare<\/strong>: RAM sufficiente, SSD veloci e configurazione pulita.<\/li>\n<\/ul>\n\n<h2>Perch\u00e9 la cache degli oggetti \u00e8 poco utile senza l'ottimizzazione del database<\/h2>\n<p>Una cache pu\u00f2 fornire solo dati che l'applicazione richiede in modo sensato; una cache lenta <strong>Banca dati<\/strong> limita quindi qualsiasi guadagno. WordPress genera molti oggetti per ogni richiesta, ma se le query sottostanti sono inutilmente grandi, senza indici o con caratteri jolly, il <strong>Vantaggio<\/strong> della cache degli oggetti. Il caching persistente con Redis o Memcached accelera le ripetizioni, ma le query scadenti rimangono tali, solo un po' meno frequenti. Se si aggiunge il carico, le nuove richieste alimentano la cache con risultati inefficienti e aumentano i tassi di errore. Per questo motivo mi occupo prima delle query, prima di intervenire sulla cache.<\/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\/01\/object-cache-serverraum-9271.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Nozioni di base: come funziona la cache degli oggetti in WordPress<\/h2>\n<p>Durante una richiesta, WordPress salva oggetti ricorrenti come opzioni, post o metadati nella memoria volatile. <strong>Cache<\/strong>, per evitare accessi duplicati al database. Con Redis o Memcached questa memoria diventa permanente, per cui molti risultati provengono dalla RAM e la <strong>TTFB<\/strong> diminuisce. Ci\u00f2 ha un effetto particolare sugli utenti registrati, sui carrelli della spesa o sulle aree riservate ai membri, dove la cache della pagina ha un impatto limitato. La qualit\u00e0 dei dati che vengono trasferiti nella cache rimane fondamentale: strutture pulite, snelle e ben indicizzate garantiscono i risultati migliori. Considero quindi il database come il primo punto di partenza per migliorare le prestazioni.<\/p>\n\n<h2>Perch\u00e9 la messa a punto viene prima di tutto: i freni tipici<\/h2>\n<p>Molte installazioni soffrono di tabelle gonfiate come wp_postmeta e wp_options, che senza <strong>Indici<\/strong> o con un autoload elevato. Se mancano le chiavi nelle colonne pi\u00f9 richieste, MySQL deve scansionare grandi quantit\u00e0 di dati, il che rallenta il <strong>Risposta<\/strong> ritardato. Anche le revisioni, i transienti scaduti e le voci spam allungano le tabelle e le invalidazioni della cache. Rimuovo i vecchi dati, creo indici significativi e controllo i piani di query. Solo quando la base \u00e8 corretta, una cache oggetto pu\u00f2 essere scalata in modo pulito.<\/p>\n\n<h2>Trappole frequenti nei database: wp_options, Autoload e Metafelder<\/h2>\n<p>La colonna autoload in wp_options carica molte voci ad ogni richiesta, il che senza <strong>Cura<\/strong> richiede molto tempo. Controllo le dimensioni dell'autoload, imposto le opzioni non necessarie su no e controllo come i plugin utilizzano i metadati in wp_postmeta. I plugin grandi e non specifici <strong>Domande<\/strong> con LIKE %muster% su meta_value uccidere l'utilizzo dell'indice. Chi desidera approfondire l'argomento trover\u00e0 informazioni di base su <a href=\"https:\/\/webhosting.de\/it\/wordpress-opzioni-autoload-prestazioni-ottimizzazione-database-boost\/\">Opzioni di caricamento automatico<\/a>, che ottimizzo costantemente nei progetti.<\/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\/01\/objectcache_meeting_9382.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cache delle pagine vs. cache degli oggetti: ruoli chiari, combinazione potente<\/h2>\n<p>Page Cache fornisce pagine HTML complete per i visitatori anonimi, mentre <strong>Oggetto<\/strong> La cache accelera le singole strutture di dati per le parti dinamiche. Utilizzo la cache di pagina per la massa e lascio che la cache degli oggetti si occupi dei resti personalizzati. Se il database va in tilt, la cache di pagina non \u00e8 in grado di salvare ogni situazione e Redis si riempie di oggetti inutili. La corretta separazione dei livelli garantisce tempi di risposta brevi e un carico ridotto sul server. Il confronto fornisce una panoramica compatta. <a href=\"https:\/\/webhosting.de\/it\/cache-di-pagina-vs-cache-di-oggetti-hosting-wordpress-boost\/\">Cache di pagina vs. cache di oggetti<\/a>, che utilizzo per la pianificazione.<\/p>\n\n<h2>Pratica: utilizzare e monitorare Redis in modo corretto<\/h2>\n<p>Grazie alla sua architettura in memoria, alle strutture dati e alla persistenza, Redis \u00e8 particolarmente adatto a WordPress quando il <strong>Dati<\/strong> dietro. Configuro i TTL in base alla percentuale di contenuti dinamici, misuro la frequenza di accesso e regolo gli eventi di invalidazione. TTL troppo brevi sovraccaricano il sistema, TTL troppo lunghi conservano i vecchi <strong>Stand<\/strong>. I gruppi chiave aiutano a eliminare gli oggetti in modo mirato in caso di aggiornamenti post, eventi relativi al carrello della spesa o cambi di utente. Solo con un monitoraggio accurato \u00e8 possibile aumentare sia la produttivit\u00e0 che la coerenza.<\/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\/01\/object-cache-datenbank-tuning-7462.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Limiti e insidie: quando la cache si ribalta<\/h2>\n<p>Senza RAM sufficiente, strategie TTL chiare e pulite <strong>invalidazione<\/strong> il numero chiave cresce pi\u00f9 rapidamente di quanto sia ragionevole. In molte pagine personalizzate, i tassi di errore rimandano al database, che ne risente doppiamente. Pertanto, controllo innanzitutto le query pi\u00f9 costose, ne riduco la cardinalit\u00e0 e elimino le chiavi cache inutili. Successivamente, stabilisco dei limiti massimi e osservo le evictions per riconoscere tempestivamente la pressione sulla memoria. In questo modo, il <strong>Cache<\/strong> un vantaggio e non diventa un secondo cantiere.<\/p>\n\n<h2>Panoramica rapida: colli di bottiglia, cause e misure<\/h2>\n<p>La tabella seguente mostra i sintomi tipici con la causa e una misura diretta che considero prioritaria negli audit, tenendo conto anche del <strong>MySQL<\/strong> Bilancio di accumulo tramite il <a href=\"https:\/\/webhosting.de\/it\/mysql-buffer-pool-ottimizzazione-delle-prestazioni-del-database\/\">Pool buffer MySQL<\/a>, per aumentare i risultati della cache del database stesso.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Sintomo<\/th>\n      <th>Causa<\/th>\n      <th>Misura<\/th>\n      <th>Effetto previsto<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>TTFB elevato per gli utenti connessi<\/td>\n      <td>Campi meta non indicizzati<\/td>\n      <td>Indice su wp_postmeta (post_id, meta_key)<\/td>\n      <td>Notevolmente meno <strong>Scansioni<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Picchi di RAM in Redis<\/td>\n      <td>TTL troppo ampi, troppe chiavi<\/td>\n      <td>Classificare TTL in base al tipo di dati, gruppi di chiavi<\/td>\n      <td>costante <strong>Tasso di successo<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Pagine di amministrazione lunghe<\/td>\n      <td>Caricamento automatico &gt; 1\u20132 MB<\/td>\n      <td>Svuotare Autoload, opzioni su no<\/td>\n      <td>Backend pi\u00f9 veloce<\/td>\n    <\/tr>\n    <tr>\n      <td>Molte letture DB nonostante la cache<\/td>\n      <td>Invalidazione errata durante gli aggiornamenti<\/td>\n      <td>Invalidazione basata sugli eventi<\/td>\n      <td>Risultati coerenti<\/td>\n    <\/tr>\n    <tr>\n      <td>IO-Wait sotto carico<\/td>\n      <td>Buffer pool piccolo \/ frammentazione<\/td>\n      <td>Aumentare il buffer pool, OPTIMIZE<\/td>\n      <td>Meno blocchi IO<\/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\/01\/objectcache_db_tuning_4327.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Procedura concreta: come recuperare il ritardo del database<\/h2>\n<p>Inizio con una panoramica dello stato delle tabelle e poi passo ai dettagli: SHOW TABLE STATUS, controllo del piano dell'indice, valutazione delle query con Explain, verifica del volume di autocaricamento, quindi <strong>OPTIMIZE<\/strong> ed eseguo mysqlcheck. Successivamente introduco il versioning per le modifiche SQL, al fine di mantenere gli indici riproducibili. Le revisioni e i transienti scaduti vengono eliminati, i cron job eseguono regolarmente la pulizia. Parallelamente aumento i limiti del server, come innodb_buffer_pool_size, in base al volume dei dati. Questa sequenza impedisce che il <strong>Cache<\/strong> modelli inefficienti.<\/p>\n\n<h2>Ottimizzazione di Redis: TTL, gruppi e monitoraggio<\/h2>\n<p>Nei progetti, separo gli oggetti di breve durata, come i carrelli della spesa, dagli oggetti di lunga durata, come le opzioni, in modo che <strong>TTL<\/strong>-Le strategie non entrano in conflitto. I gruppi chiave per sito o segmento di negozio riducono le perdite di dispersione durante la cancellazione, aumentando il tasso di successo. Impostiamo soglie a partire dalle quali gli eviction generano un allarme e analizziamo i tassi di errore per ogni percorso. Monitoriamo le modifiche nei plugin, poich\u00e9 le nuove funzionalit\u00e0 spesso comportano nuove <strong>Chiavi<\/strong> . In questo modo Redis rimane prevedibile e consente di risparmiare tempo prezioso.<\/p>\n\n<h2>Monitoraggio e valori target: cosa controllo regolarmente<\/h2>\n<p>Il mio obiettivo \u00e8 raggiungere un tasso di successo superiore al 90%, monitorare le metriche Redis e MySQL e confrontare le richieste per <strong>Percorso<\/strong> nel corso del tempo. Contrassegno le query lente e ne deduco le modifiche agli indici o alle strutture dei dati. Adatto i TTL ai modelli di traffico e ai cicli di pubblicazione. Soprattutto con WooCommerce, presto attenzione alle esplosioni di chiavi dovute a varianti e filtri. Questa disciplina mantiene il <strong>Latenza<\/strong> Stabile, anche quando il traffico aumenta.<\/p>\n\n<h2>Fattori di hosting: RAM, SSD e limiti ragionevoli<\/h2>\n<p>Una cache oggetti veloce richiede una memoria veloce, RAM sufficiente e impostazioni del server pulite, altrimenti i risultati perdono la loro <strong>Effetto<\/strong>. Pianifico le quote di RAM in modo che Redis, PHP e MySQL non competano per le risorse. Gli SSD riducono i tempi di attesa IO, il che si traduce in vantaggi in termini di accesso al database e persistenza della cache. Il ridimensionamento automatico e i servizi isolati aumentano la pianificabilit\u00e0 sotto carico. Nei confronti, con una buona ottimizzazione si registrano riduzioni TTFB fino al 70% (fonte: <strong>webhosting.com<\/strong>), che tuttavia sono ottenibili solo con una base dati pulita.<\/p>\n\n<h2>Tipici antipattern delle query e come li risolvo<\/h2>\n<p>Molti freni si trovano in punti poco visibili <strong>WP_Query<\/strong>-Parametri. Larghezza <em>meta_query<\/em>I filtri senza indici, i caratteri jolly all'inizio di LIKE (ad es. %wert) o ORDER BY su colonne non indicizzate generano scansioni complete della tabella. Riduco la cardinalit\u00e0 impostando meta_key in modo rigoroso, normalizzando i valori (interi\/booleani invece di stringhe) e <strong>indici combinati<\/strong> su (post_id, meta_key) o (meta_key, meta_value), a seconda del modello di accesso. Riduco al minimo i JOIN non necessari su wp_term_relationships utilizzando valori di conteggio precalcolati e, ove possibile, tabelle di ricerca. Inoltre, equalizzo le query con LIMIT e impagino in modo pulito, invece di caricare migliaia di record senza freni. Il risultato: meno lavoro per ogni richiesta, maggiore stabilit\u00e0. <strong>TTFB<\/strong>, migliori risultati della cache.<\/p>\n\n<h2>La realt\u00e0 di WooCommerce: varianti, filtri e caching<\/h2>\n<p>I negozi mostrano i limiti della cache: varianti, filtri di prezzo, disponibilit\u00e0 e contesto utente generano molte risposte diverse. Verifico se il <em>wc_product_meta_lookup<\/em>-Tabella venga utilizzata correttamente, in modo che le richieste di prezzo e di disponibilit\u00e0 funzionino in base all'indice. Nelle pagine delle categorie e di ricerca evito filtri liberamente combinabili e non indicizzati; invece, aggrego i filtri o limito la profondit\u00e0 dei filtri costosi. Incapsulo i dati del carrello e della sessione in gruppi di chiavi dedicati con TTL brevi, in modo che non sovrascrivano la cache globale. Per i frammenti dinamici (mini carrello, contatore badge) utilizzo l'invalidazione mirata al momento dell'evento, ad esempio in caso di modifiche alle scorte, invece di svuotare interi gruppi di pagine. In questo modo le pagine del catalogo e dei prodotti rimangono veloci, mentre gli elementi personalizzati rimangono aggiornati.<\/p>\n\n<h2>Prevenire il cache stampede: coordinamento anzich\u00e9 duplicazione dei carichi<\/h2>\n<p>Quando i TTL stanno per scadere, molte richieste spesso incontrano contemporaneamente una chiave vuota: il classico <strong>Stampede<\/strong>. Lo attenuo con due misure: in primo luogo <em>richiesta di coalescenza<\/em>, in cui solo la prima richiesta ricalcola i dati e le altre attendono brevemente. Secondo <em>aggiornamento anticipato<\/em> tramite \u201esoft TTL\u201c: la cache fornisce ancora dati validi, ma attiva in background un refill prima che scada il hard TTL. Dove opportuno, imposto piccoli <strong>Jitter<\/strong> su TTL per evitare l'esecuzione sincrona di grandi quantit\u00e0 di chiavi. Risultato: meno picchi di carico, tempi di risposta pi\u00f9 stabili, curve di corrispondenza coerenti.<\/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\/01\/entwicklercachedesk4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Coerenza grazie a una chiara invalidazione<\/h2>\n<p>I flush completi spesso cancellano troppo e producono tempeste di errori. Io lavoro con precisione. <strong>Hook di invalidazione<\/strong>: Quando si salva un post, si modifica lo stato, si aggiornano i metadati o si modificano i prezzi, vengono rimossi solo i gruppi di chiavi interessati. Per le pagine di elenchi e archivi costose, mantengo chiavi di indice snelle che vengono eliminate in modo mirato quando si modificano i contenuti. In questo modo, la cache degli oggetti rimane coerente senza perdere i suoi vantaggi. Importante: l'invalidazione fa parte del processo di implementazione: le nuove funzionalit\u00e0 devono dichiarare i propri percorsi di dati e le chiavi interessate.<\/p>\n\n<h2>Multisito e mandanti: separazione e sharding<\/h2>\n<p>Nelle configurazioni multisito \u00e8 strettamente <strong>Separazione degli spazi dei nomi<\/strong> Obbligo. Utilizzo prefissi univoci per ogni sito e, se necessario, database Redis separati o slot cluster per evitare contaminazioni incrociate. Separo i tenant molto diversi tra loro (ad es. blog vs. negozio) in gruppi di chiavi separati con politiche TTL specifiche. In caso di carico elevato, frammento le chiavi calde in modo che le singole partizioni non diventino un collo di bottiglia. Il monitoraggio viene effettuato per ogni sito, in modo che i valori anomali non vengano persi nel rumore complessivo.<\/p>\n\n<h2>Dimensionamento e politiche per Redis e MySQL<\/h2>\n<p>Per MySQL ho in programma il <strong>innodb_buffer_pool<\/strong> in modo che i dati attivi e gli indici possano essere inseriti; il tasso di successo nel buffer pool spesso determina la latenza di base. Con Redis definisco una chiara <em>maxmemory<\/em>-Strategia e una <em>Politica di sfratto<\/em>. Per le cache degli oggetti WordPress, una politica \u201evolatile\u201c si \u00e8 dimostrata efficace, in modo che solo le chiavi con TTL vengano sostituite. Misuro la frammentazione, la distribuzione delle dimensioni delle chiavi e il numero di hash\/elenchi di grandi dimensioni per individuare eventuali consumi di memoria imprevisti. Sul lato MySQL, controllo il <strong>Registro delle query lente<\/strong>, configurazioni senza cache delle query (MySQL 8) e puntare su connessioni ben dimensionate, affinch\u00e9 i carichi di lavoro non si perdano nei cambi di contesto.<\/p>\n\n<h2>Test, migrazioni e strategia di rollback<\/h2>\n<p>Indici e modifiche allo schema che gioco <strong>online<\/strong> per evitare tempi di inattivit\u00e0 e preparo un rollback. Innanzitutto registro i valori di riferimento (TTFB, query\/richieste, 95\u00b0 percentile), poi testo scenari di carico con cookie e richieste realistici. Per le modifiche della cache eseguo <em>Riscaldamento<\/em> in modo che i percorsi critici non entrino in produzione a freddo. Registro quali chiavi vengono create, quali tassi di hit cambiano e quali percorsi ne traggono vantaggio. Se un esperimento fallisce, ripristino la configurazione TTL e dell'indice precedente, documentandola in modo riproducibile.<\/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\/01\/objectcache-serverraum-8492.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Utilizzare correttamente gli effetti Edge e CDN Tile<\/h2>\n<p>Una cache edge alleggerisce l'origine da molte richieste, ma non risolve il problema del database con i contenuti personalizzati. Mi assicuro che l'HTML venga memorizzato nella cache in modo aggressivo per gli utenti anonimi, mentre le parti dinamiche arrivano tramite piccoli endpoint API con clear cache control header. Utilizzo con parsimonia i cookie che controllano la personalizzazione e mantengo le varianti entro limiti ragionevoli per limitare il numero di variazioni edge. La cache degli oggetti rimane l'acceleratore dietro l'edge: fornisce in modo rapido e coerente gli elementi che non possono essere memorizzati nella cache globale.<\/p>\n\n<h2>Caso speciale Ricerca e report<\/h2>\n<p>La ricerca di testo libero in post_content o meta_value tramite LIKE \u00e8 notoriamente lenta. Riduco gli spazi di ricerca, aggiungo <strong>TESTO COMPLETO<\/strong>-Indici su titoli\/contenuti o esternalizzazione di logiche di ricerca complesse in strutture specializzate. Per report e dashboard calcolo gli indicatori in modo incrementale e li memorizzo nella cache come oggetti compatti e chiaramente invalidabili. In questo modo evito che query rare ma pesanti occupino regolarmente la memoria di lavoro e la CPU e sovrascrivano la cache.<\/p>\n\n<h2>In breve: ecco come funziona realmente la cache degli oggetti<\/h2>\n<p>Per prima cosa do la priorit\u00e0 alla <strong>Banca dati<\/strong>, quindi la cache: impostare gli indici, ripulire l'autoload, eliminare le query lente, ottimizzare le tabelle. Successivamente, configuro Redis con TTL adeguati, gruppi di chiavi e regole di invalidazione chiare. La cache di pagina si occupa delle operazioni grossolane, mentre la cache degli oggetti si occupa di quelle pi\u00f9 precise, consentendo a MySQL di respirare grazie a un buffer pool di grandi dimensioni e a tabelle ripulite. Il monitoraggio mostra dove \u00e8 necessario intervenire per garantire tassi di successo, memoria e coerenza adeguati. In questo modo, tutti ne traggono vantaggio. <strong>Cache<\/strong>-Puntare su prestazioni reali, invece di limitarsi a mascherare i sintomi.<\/p>","protected":false},"excerpt":{"rendered":"<p>Perch\u00e9 la cache degli oggetti non offre quasi nessun vantaggio senza l'ottimizzazione del database: impara Redis, WordPress Caching e hosting optimization per ottenere la massima velocit\u00e0.<\/p>","protected":false},"author":1,"featured_media":16636,"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-16643","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":"1302","_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":"Object Cache","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":"16636","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/16643","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=16643"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/16643\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/16636"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=16643"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=16643"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=16643"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}