{"id":20092,"date":"2026-07-28T11:50:13","date_gmt":"2026-07-28T09:50:13","guid":{"rendered":"https:\/\/webhosting.de\/redis-object-cache-konfigurationsfehler-wordpress-performance-tuning\/"},"modified":"2026-07-28T11:50:13","modified_gmt":"2026-07-28T09:50:13","slug":"errore-di-configurazione-della-cache-degli-oggetti-redis-ottimizzazione-delle-prestazioni-di-wordpress","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/redis-object-cache-konfigurationsfehler-wordpress-performance-tuning\/","title":{"rendered":"Redis come cache di oggetti: errori tipici di configurazione e loro conseguenze"},"content":{"rendered":"<p>La cache Redis migliora sensibilmente le prestazioni di WordPress, ma i tipici errori di configurazione portano rapidamente a <strong>Instabilit\u00e0<\/strong> e strani picchi di latenza. In questo articolo illustrer\u00f2 gli errori pi\u00f9 comuni, le loro <strong>Conseguenze<\/strong> e come utilizzo Redis come cache di oggetti in WordPress in modo sicuro e veloce.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>Separazione<\/strong> La gestione della cache e delle sessioni previene la perdita di dati e un carico I\/O superfluo.<\/li>\n  <li><strong>maxmemory<\/strong> e scegliere con attenzione la politica di eviction, altrimenti si rischia lo swapping.<\/li>\n  <li><strong>Persistenza<\/strong> Configurare in modo appropriato: senza cache, sessioni con AOF\/RDB.<\/li>\n  <li><strong>Sicurezza<\/strong> Da tenere presente: bind, password, utilizzo delle reti interne.<\/li>\n  <li><strong>TTL<\/strong> controllare, per evitare stampede e danni da RAM.<\/li>\n<\/ul>\n\n<h2>Perch\u00e9 Redis \u00e8 efficace come cache di oggetti in WordPress<\/h2>\n\n<p>WordPress genera molte query MySQL per ogni richiesta, che io risolvo con un <strong>persistenza<\/strong> Cache degli oggetti e memorizzazione temporanea nella RAM. In questo modo si riducono i tempi di risposta, il database funziona in modo pi\u00f9 fluido e i contenuti dinamici appaiono chiaramente agli utenti <strong>pi\u00f9 veloce<\/strong>. \u00c8 fondamentale che Redis non venga utilizzato come soluzione universale, ma come livello di accelerazione mirato per oggetti ricorrenti. Mantengo alto il tasso di successo della cache scegliendo la politica di eviction adeguata e impostando correttamente i limiti di memoria. Senza questi principi, il potenziale rimane inutilizzato e la cache funge pi\u00f9 da zavorra che da turbocompressore.<\/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\/07\/redis-konfiguration-fehler-7813.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Errori di configurazione comuni a livello di server<\/h2>\n\n<p>Molti errori derivano dalla configurazione del server, non da <strong>WordPress<\/strong>. Chi inserisce la cache e le sessioni in un\u2019unica istanza, associa dati volatili e dati persistenti, creando una combinazione poco felice di evictions, fork e flush. Altrettanto critico: l\u2019assenza o la dimensione eccessiva di <strong>maxmemory<\/strong>, che finisce nello swap e blocca ogni richiesta. A ci\u00f2 si aggiungono impostazioni di persistenza eccessivamente aggressive, come AOF su \u201ealways\u201c, che fanno impennare gli I\/O di scrittura e rallentano il processo principale. Ecco una sintesi del motivo per cui, nella pratica, ci\u00f2 si manifesta spesso come un Redis apparentemente \u201elento\u201c: <a href=\"https:\/\/webhosting.de\/it\/perche-redis-e-piu-lento-del-previsto-errori-tipici-di-configurazione-cacheopt\/\">perch\u00e9 Redis sembra pi\u00f9 lento<\/a>.<\/p>\n\n<h2>La giusta distinzione: cache e sessioni<\/h2>\n\n<p>Creo sempre un'istanza cache temporanea senza <strong>Persistenza<\/strong> e conservo le sessioni, i carrelli della spesa e dati simili in un\u2019istanza separata e permanente. Nell\u2019istanza di cache disattivo gli snapshot e l\u2019AOF, e lavoro con <strong>tutte le chiavi-lru<\/strong>, in modo da liberare spazio per le chiavi utilizzate raramente. Nell\u2019istanza di sessione attivo l\u2019AOF con \u201eeverysec\u201c e scelgo intervalli RDB moderati per bilanciare coerenza e velocit\u00e0 di scrittura. In questo modo evito che un comando `flushdb` eseguito intenzionalmente svuoti la cache dei login o dei carrelli. Inoltre, la manutenzione rimane pianificabile, poich\u00e9 definisco ruoli e limiti chiari per ogni istanza.<\/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\/07\/redis_konfig_fehler_7583.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ostacoli specifici di WordPress<\/h2>\n\n<p>In WordPress stesso vedo spesso una configurazione errata <strong>wp-config.php<\/strong>, host errati, password dimenticate o costanti inserite nel posto sbagliato. Altrettanto frequente: un file object-cache.php danneggiato o obsoleto, che dopo gli aggiornamenti dei plugin genera pagine bianche. In caso di emergenza, rimuovo il file per far ripartire WordPress e reinstallo il plugin Redis da zero. Parallelmente, verifico se pi\u00f9 plugin di caching controllano contemporaneamente la cache degli oggetti e, di conseguenza, <strong>Conflitti<\/strong> provocare. Il motivo per cui un\u2019integrazione errata d\u00e0 l\u2019impressione che la cache degli oggetti rallenti il sistema viene spiegato in questo articolo pratico: <a href=\"https:\/\/webhosting.de\/it\/la-cache-degli-oggetti-di-wordpress-rallenta-serverboost\/\">La cache degli oggetti rallenta WordPress<\/a>.<\/p>\n\n<p>\u00c8 importante anche gestire in modo accurato i gruppi di cache. Definisco gruppi globali per i dati condivisi (ad es. le opzioni) e contrassegno i gruppi di breve durata come <em>non persistente<\/em>, in modo che non finiscano nella cache degli oggetti e non causino evacuazioni inutili. Ci\u00f2 impedisce il churn quando i cronjob generano migliaia di transienti di breve durata. Quando utilizzo un file drop-in, mi assicuro che <strong>wp_cache_add_global_groups<\/strong> e <strong>wp_cache_add_non_persistent_groups<\/strong> impostati in modo ottimale \u2013 ci\u00f2 stabilizza notevolmente l'Hitrate e il consumo di RAM.<\/p>\n\n<h2>wp-config.php: impostazioni di base sintetiche<\/h2>\n\n<p>Le costanti pi\u00f9 importanti devono essere inserite sopra la riga \u201estop editing\u201c, in modo che WordPress le carichi tempestivamente e il <strong>Connettore<\/strong> collega in modo stabile. Impostiamo host, porta e, facoltativamente, un numero di database separato per separare chiaramente le installazioni. Un key-salt separa le chiavi per ogni sito, in particolare in ambienti multisito o condivisi. Se l\u2019autenticazione \u00e8 attiva, la password deve essere obbligatoriamente inserita nella configurazione, altrimenti si rischia che siano visibili <strong>Errore<\/strong> nel frontend. La tabella seguente offre una panoramica concisa e pratica delle impostazioni pi\u00f9 comuni.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>costante<\/th>\n      <th>Scopo<\/th>\n      <th>Esempio<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>WP_REDIS_HOST<\/strong><\/td>\n      <td>Host\/IP dell'istanza Redis<\/td>\n      <td>\u201a127.0.0.1\u2018<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>WP_REDIS_PORT<\/strong><\/td>\n      <td>Porta di connessione<\/td>\n      <td>6379<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>WP_REDIS_DATABASE<\/strong><\/td>\n      <td>Numero DB opzionale per la separazione<\/td>\n      <td>1<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>WP_CACHE_KEY_SALT<\/strong><\/td>\n      <td>Prefisso per una separazione netta delle chiavi<\/td>\n      <td>\u201aexample_com_\u2018<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>WP_REDIS_PASSWORD<\/strong><\/td>\n      <td>Password, se l'opzione `requirepass` \u00e8 attiva<\/td>\n      <td>\u201apassword segreta\u2018<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/07\/redis-object-cache-konfig-fehler-8234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Limiti di memoria, eviction e TTL sotto controllo<\/h2>\n\n<p>Senza una chiara <strong>maxmemory<\/strong> la cache tende a riempirsi eccessivamente, costringendo il server a ricorrere allo swap, il che rallenta improvvisamente le visualizzazioni delle pagine. Inizio con un approccio prudente, misuro la percentuale di hit e aumento gradualmente la memoria, in modo che PHP-FPM, MySQL e il sistema operativo abbiano ancora spazio a disposizione. Per i dati effettivi della cache utilizzo una politica di evizione basata su LRU, in modo che le chiavi utilizzate raramente facciano spazio quando la RAM scarseggia. Inoltre, imposto le impostazioni appropriate <strong>TTL<\/strong> e distribuisco leggermente i tempi di esecuzione per evitare processi di massa e sovraccarichi della cache. Se dovessero verificarsi picchi di carico, controllo innanzitutto gli eviction, le latenze e la pressione sulla memoria prima di intervenire sul codice o sul database.<\/p>\n\n<p>Per configurazioni pi\u00f9 complesse, mi affido a <em>stale-while-revalidate<\/em>-Modello: un oggetto ha un TTL rigido e un \u201eperiodo di grazia\u201c pi\u00f9 flessibile. Durante la fase flessibile, restituisco temporaneamente i dati precedenti e lascio che in background venga ricostruita una singola richiesta (Lock\/MuteX). In questo modo stabilizzo le risorse con elevato parallelismo (pagina iniziale, archivi delle categorie) ed evito che decine di worker PHP calcolino lo stesso costoso errore. Una leggera randomizzazione dei TTL per chiave (jitter) distribuisce gli aggiornamenti ed evita effetti di gregge intorno al minuto intero.<\/p>\n\n<h2>Serializzatore, compressione e driver PHP<\/h2>\n\n<p>La scelta del serializzatore influisce sul consumo di RAM e sul tempo di elaborazione della CPU. Quando possibile, utilizzo, <strong>igbinary<\/strong> come serializzatore, perch\u00e9 memorizza gli array PHP in modo pi\u00f9 compatto rispetto alla funzione `serialize` di PHP. A seconda della struttura dell\u2019oggetto, ci\u00f2 consente un notevole risparmio di memoria e riduce gli eviction. La compressione (ad es. LZF\/Zstd) \u00e8 vantaggiosa solo per valori molto grandi: valuto il costo in termini di CPU rispetto allo spazio di memoria guadagnato e decido caso per caso a seconda del progetto. L\u2019obiettivo \u00e8 raggiungere un equilibrio stabile tra hit rate, carico della CPU e I\/O.<\/p>\n\n<p>Per quanto riguarda il driver PHP, preferisco utilizzare quello nativo <strong>phpredis<\/strong>-Extension per le sue prestazioni e le connessioni persistenti stabili. Su singoli server, se possibile, mi connetto tramite un socket Unix anzich\u00e9 tramite TCP: ci\u00f2 riduce la latenza e risparmia overhead. Importante: impostare correttamente i permessi dei file per l\u2019utente del server web, altrimenti le connessioni falliscono in modo silenzioso. Impostiamo i timeout di connessione e di lettura in modo conservativo (nell\u2019ordine dei millisecondi), in modo che i socket bloccati non blocchino interi pool PHP-FPM.<\/p>\n\n<h2>Architettura: Redis condiviso vs. Redis dedicato<\/h2>\n\n<p>Decido consapevolmente se Redis debba funzionare insieme ad altri servizi o in modo esclusivo, poich\u00e9 entrambe le opzioni presentano chiari <strong>Scambi di opinioni<\/strong> . Sulle istanze condivise condivido le risorse, il che riduce i costi ma diminuisce l\u2019isolamento; le istanze dedicate mi garantiscono il controllo su limiti, politiche e sicurezza. Per i negozi online in produzione e i siti molto frequentati, un Redis autonomo \u00e8 vantaggioso perch\u00e9 i fattori di disturbo sono minori. Chi desidera valutare differenze, rischi e vantaggi pratici trover\u00e0 qui una guida concisa: <a href=\"https:\/\/webhosting.de\/it\/redis-condiviso-vs-dedicato-prestazioni-sicurezza-cacheboost\/\">Condiviso vs. dedicato<\/a>. Inoltre, mi occupo del monitoraggio per individuare tempestivamente eventuali colli di bottiglia, prima che gli utenti se ne accorgano.<\/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\/07\/redis_cache_errors_tech_2431.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Alta disponibilit\u00e0: replica e failover<\/h2>\n\n<p>Per garantire un\u2019elevata disponibilit\u00e0, prevedo delle repliche, ma con moderazione: la cache degli oggetti \u00e8 volatile e, in caso di emergenza, pu\u00f2 essere svuotata; \u00e8 pi\u00f9 importante disporre di un servizio primario veloce e stabile. Una replica asincrona aiuta a effettuare rapidamente il passaggio in caso di errore; mi assicuro tuttavia che WordPress accetti tempestivamente il nuovo primario (DNS, nome host o IP interni). Un cluster Redis in modalit\u00e0 sharding \u00e8 solitamente sovradimensionato per la classica cache degli oggetti di WP; \u00e8 sufficiente un server primario con replica\/e e un failover pulito. Sono fondamentali timeout brevi e un passaggio automatizzabile, affinch\u00e9 i processi PHP non attendano a lungo connessioni inattive.<\/p>\n\n<h2>Aspetti interni del sistema operativo e di Redis che garantiscono le prestazioni<\/h2>\n\n<p>Un Redis stabile trae vantaggio dall'ottimizzazione del sistema operativo: disattivo <strong>Pagine trasparenti di grandi dimensioni<\/strong>, imposta <strong>vm.overcommit_memory=1<\/strong> e imposta limiti ragionevoli per i file aperti e <strong>maxclients<\/strong>. Ci\u00f2 riduce i problemi legati al \u201ecopy-on-write\u201c in caso di fork (riscritture RDB\/AOF) e impedisce che le connessioni vengano rifiutate. Per l\u2019AOF, imposto \u00abeverysec\u00bb nell\u2019istanza della sessione e attivo le opzioni che disaccoppiano le riscritture, in modo che il processo principale rimanga costante. \u00c8 importante anche che le riscritture RDB o AOF non vengano attivate continuamente: monitoro le dimensioni dei file e la frequenza delle riscritture e regolo le soglie prima che l\u2019I\/O diventi un collo di bottiglia.<\/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\/07\/konfigurationsfehler-redis-cache-9204.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configurazione sicura della rete<\/h2>\n\n<p>Rendere Redis accessibile al pubblico \u00e8 una decisione dalle gravi conseguenze <strong>Errore<\/strong>, poich\u00e9 gli hacker potrebbero leggere, svuotare o manipolare i contenuti. Integro il servizio in locale o in una rete privata, attivo l\u2019autenticazione e blocco le porte non necessarie nel firewall. Per le configurazioni multi-server, preferisco utilizzare VPN o reti interne anzich\u00e9 IP pubblici. Inoltre, verifico regolarmente che comandi di amministrazione come \u201eCONFIG\u201c, \u201eFLUSH\u201c o simili siano stati limitati o rinominati, in modo che i plugin funzionino correttamente <strong>lavoro<\/strong>. La sicurezza non \u00e8 un compito da svolgere una volta sola, ma un controllo ricorrente nell'attivit\u00e0 quotidiana dell'azienda.<\/p>\n\n<h2>Comandi costosi e osservabilit\u00e0<\/h2>\n\n<p>Comandi come <strong>KEYS<\/strong> oppure l'esecuzione di FLUSHALL durante il funzionamento pu\u00f2 richiedere alcuni minuti e rallentare sensibilmente il sito. Sostituisco KEYS con SCAN, eseguo i flush solo in modo controllato e monitoro la latenza di Redis insieme ai tassi di errore. A tal fine mi aiutano i log di WordPress e metriche quali Used Memory, Evictions, Hit-Rate e tempi di sincronizzazione AOF. Se le richieste sembrano lente, controllo prima questi indicatori prima di approfondire l\u2019analisi di PHP o MySQL. La visibilit\u00e0 \u00e8 fondamentale per capire se riesco a individuare rapidamente le cause o se mi limito a curare i sintomi, che poi si ripresenteranno in seguito <strong>verificarsi<\/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\/07\/redis_cache_fehler_8472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<p>Utilizzo inoltre lo Slowlog per individuare i valori anomali, la misurazione della latenza di Redis e campionamenti periodici con INFO per monitorare la frammentazione, le dimensioni dello spazio delle chiavi e le riscritture. Un valore basso dell\u2019hit ratio associato a un elevato consumo di memoria \u00e8 un segnale d\u2019allarme: significa che ho a che fare con oggetti \u201eerrati\u201c (troppo grandi, di durata troppo breve) o con gruppi che dovrei impostare come non persistenti. Identifico le \u201echiavi grandi\u201c a campione e poi decido se limitare i plugin che le generano o ridurre i TTL.<\/p>\n\n<h2>Distribuzione, riscaldamento e svuotamento della cache<\/h2>\n\n<p>Al momento del rilascio evito i total flush. Utilizzo invece un approccio basato sulla versione <strong>WP_CACHE_KEY_SALT<\/strong> (ad es. con Build-Hash), in modo che le vecchie voci scadano mentre vengono inserite quelle nuove. In questo modo si evitano gli avvii a freddo. Un warmup mirato delle pagine pi\u00f9 importanti (pagina iniziale, prodotti pi\u00f9 venduti, tassonomie centrali) subito dopo il deploy riempie la cache sotto un carico controllato. Durante gli interventi di manutenzione, pianifico riavvii graduali delle istanze Redis e mi assicuro che PHP-FPM elimini rapidamente i vecchi socket e stabilisca nuove connessioni. Ci\u00f2 garantisce che il sito rimanga sempre reattivo.<\/p>\n\n<h2>Tasti grandi, pulizia dei dati e plugin<\/h2>\n\n<p>Alcuni plugin salvano array di opzioni o dati transitori di dimensioni molto grandi nella cache degli oggetti. Ci\u00f2 riduce la frequenza di accesso, consuma RAM e aumenta i costi di trasferimento per ogni richiesta. Ho fissato limiti rigidi: i singoli valori che superano alcune centinaia di kilobyte non devono essere inseriti nella cache degli oggetti. Regola: ci\u00f2 che viene riutilizzato raramente o varia notevolmente a livello di utente dovrebbe avere una durata pi\u00f9 breve o non essere memorizzato affatto. Preferisco aggregare i dati in modo ordinato una sola volta sul lato server, piuttosto che trasferirli come un grosso blob ad ogni visualizzazione della pagina.<\/p>\n\n<h2>Lista di controllo pratica per il go-live<\/h2>\n\n<p>Prima del lancio, verifico la connessione con la <strong>Istanza<\/strong>, controllo l'host, la porta, la password e il numero del database attivo direttamente nella schermata di stato del plugin. Successivamente svuoto la cache in modo mirato, ricarico pi\u00f9 volte la pagina iniziale e quelle dei prodotti e osservo i tempi di risposta e l'hitrate. Verifico se i cronjob o gli strumenti di importazione generano un numero eccessivo di chiavi temporanee, occupando inutilmente la RAM. Successivamente simulo picchi di carico con modelli di accesso realistici per osservare gli eviction e le latenze in condizioni di stress. Infine, salvo la configurazione, documento i valori limite e imposto avvisi per la memoria, la latenza e i tentativi falliti, in modo da poter intervenire tempestivamente <strong>reagire<\/strong>.<\/p>\n\n<ul>\n  <li>Connessioni: testare socket\/TCP, timeout e persistenza; simulare percorsi di errore.<\/li>\n  <li>Memoria: verificare maxmemory, la politica di eviction e l'utilizzo di igbinary; monitorare l'hitrate.<\/li>\n  <li>Gruppi: impostare gruppi non persistenti per le chiavi di churn, scegliere con attenzione i gruppi globali.<\/li>\n  <li>Carico: definire il piano di warmup, eseguire il prewarmup delle pagine critiche, attivare le strategie anti-stale contro gli stampede.<\/li>\n  <li>Persistenza: istanza cache senza durabilit\u00e0, istanza di sessione con AOF ogni secondo; monitorare le riscritture.<\/li>\n  <li>Sicurezza: collegarsi alle interfacce interne, autenticazione attiva, limitare i comandi di amministrazione, verificare il firewall.<\/li>\n  <li>Monitoraggio: impostare avvisi per slowlog, latenza, evictions, frammentazione e tempi di sincronizzazione AOF.<\/li>\n<\/ul>\n\n<h2>Sintesi: prevenire gli errori, guadagnare velocit\u00e0<\/h2>\n\n<p>Una cache di oggetti Redis veloce si ottiene grazie a una chiara <strong>Rulli<\/strong>, limiti ben definiti e una strategia di persistenza adeguata. Separo la cache dalle sessioni, imposto limiti di memoria prudenti e scelgo allkeys-lru per i dati transitori. In WordPress mantengo il file wp-config.php snello, controllo l\u2019object-cache.php ed evito plugin di caching in competizione tra loro. Per me, la sicurezza tramite bind, password e reti interne \u00e8 fondamentale tanto quanto il monitoraggio, affinch\u00e9 le anomalie vengano individuate tempestivamente. Chi segue questi principi non trasforma Redis in una fonte di errori, ma in uno strumento affidabile <strong>Livello di prestazione<\/strong> per contenuti dinamici.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scopri gli errori di configurazione pi\u00f9 comuni della cache a oggetti Redis in WordPress e come risolverli per ottenere le massime prestazioni dalla tua cache Redis.<\/p>","protected":false},"author":1,"featured_media":20085,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[733],"tags":[],"class_list":["post-20092","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":"126","_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":"redis 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":"20085","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20092","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=20092"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20092\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20085"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20092"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20092"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20092"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}