{"id":19521,"date":"2026-05-30T15:02:41","date_gmt":"2026-05-30T13:02:41","guid":{"rendered":"https:\/\/webhosting.de\/http-conditional-requests-cache-validierung-optimierung-paket\/"},"modified":"2026-05-30T15:02:41","modified_gmt":"2026-05-30T13:02:41","slug":"pacchetto-di-ottimizzazione-della-convalida-della-cache-per-le-richieste-condizionali-http","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/http-conditional-requests-cache-validierung-optimierung-paket\/","title":{"rendered":"Comprendere le richieste condizionali HTTP e la convalida della cache"},"content":{"rendered":"<p><strong>Condizionale HTTP<\/strong> Le richieste riducono i costi di trasmissione assicurando che il client carichi completamente una risorsa solo se questa \u00e8 stata effettivamente modificata dall'ultima richiesta. Mostrer\u00f2 come <strong>Convalida della cache<\/strong> con ETag, Last-Modified, If-None-Match, If-Modified-Since e 304 Not Modified funziona in modo affidabile e i tempi di caricamento sono notevolmente ridotti.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>Convalida<\/strong> invece del download completo: 304 consente di risparmiare larghezza di banda e tempo.<\/li>\n  <li><strong>ETag<\/strong> e Last-Modified lavorano insieme per un controllo pulito.<\/li>\n  <li><strong>Controllo della cache<\/strong> definisce la freschezza, scade solo l'integrazione.<\/li>\n  <li><strong>Condizioni preliminari<\/strong> come i processi di scrittura sicuri If-Match.<\/li>\n  <li><strong>Sicurezza<\/strong> richiede la memorizzazione privata\/no-store per i contenuti sensibili.<\/li>\n<\/ul>\n\n<h2>Cosa fanno le richieste condizionali nella vita quotidiana<\/h2>\n\n<p>Ho impostato <strong>Condizionale<\/strong> per porre al server una domanda chiara: Ho davvero bisogno di trasferire nuovi dati o la mia cache \u00e8 sufficiente? Il browser o un proxy invia le condizioni, il server controlla se un file \u00e8 cambiato e risponde con 304 Not Modified senza corpo. Questo schema mantiene aggiornati HTML, CSS, JavaScript, immagini e risposte API, riducendo in modo significativo il carico sull'infrastruttura. Per le risorse valide pi\u00f9 lunghe, utilizzo valori di et\u00e0 massima lunghi e mi assicuro che siano aggiornati attraverso la convalida. Se si dispone del giusto <a href=\"https:\/\/webhosting.de\/it\/strategie-di-controllo-della-cache-http-hosting-cachemaster\/\">Strategie di controllo della cache<\/a> ottiene il massimo dalle cache senza rischiare di avere contenuti obsoleti.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/httpcache-0614.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Intestazioni che consentono la validazione della cache<\/h2>\n\n<p>Per un'affidabile <strong>Cache<\/strong>-Il cliente ha bisogno di segnali chiari dalla risposta per prendere decisioni. Uso Cache-Control per la freschezza e le regole, Expires occasionalmente come supplemento, e Last-Modified e ETag per la validazione vera e propria. Last-Modified fornisce un tempo di modifica che pu\u00f2 essere controllato rapidamente, mentre ETag fornisce un identificatore di versione che viene utilizzato anche per i contenuti dinamici. Importante: no-cache significa convalidare prima dell'uso, non eliminare. Se si applica correttamente questa semantica, si otterr\u00e0 una notevole riduzione del traffico di dati, mantenendo il contenuto aggiornato. <strong>Contenuti<\/strong>.<\/p>\n\n<h2>Sequenza di una richiesta condizionale senza deviazioni<\/h2>\n\n<p>Alla prima chiamata, il client salva il file e i valori di convalida, come ad esempio <strong>ETag<\/strong> o Last-Modified nella cache. Successivamente, la risorsa scade o richiede un nuovo controllo prima dell'uso e il client invia If-None-Match o If-Modified-Since. Il server confronta le informazioni con lo stato attuale e restituisce 200 OK con un nuovo corpo o 304 Not Modified senza payload. Il client continua quindi a utilizzare la copia esistente, risparmiando la trasmissione, il carico di lavoro TLS e il tempo. Questo ping-pong sembra poco appariscente, ma la <strong>Effetto<\/strong> sulla sensazione di carico e sul carico del server \u00e8 chiaro.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/http_requests_besprechung_4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>ETag vs. Last-Modified a confronto diretto<\/h2>\n\n<p>Uso <strong>Ultima modifica<\/strong> Mi piace usare i timestamp come riferimento rapido e semplice, ma uso ETag per un controllo a grana fine. I timestamp possono raggiungere i loro limiti con intervalli di modifica molto brevi o falsificare i risultati dinamici. Creo gli ETag dagli hash dei file, dalle versioni dei database o dalle varianti di rendering, in modo che ogni modifica del contenuto generi un nuovo identificatore. Entrambi i meccanismi possono essere combinati: Il client pu\u00f2 inviare If-None-Match e If-Modified-Since in parallelo e il server seleziona il controllo appropriato. Questo \u00e8 il modo in cui garantisco un'affidabile <strong>Convalida<\/strong>, che si applica ugualmente alle risorse statiche e dinamiche.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Criterio<\/th>\n      <th>Ultima modifica<\/th>\n      <th>ETag<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>Precisione<\/strong><\/td>\n      <td>Seconda risoluzione, adatta ai file<\/td>\n      <td>Identificatore di versione per ogni modifica del contenuto<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Dinamica<\/strong><\/td>\n      <td>Debole per modifiche frequenti non basate su file<\/td>\n      <td>Forte per le API e i contenuti renderizzati<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Spese<\/strong><\/td>\n      <td>Basso, disponibile dal file system<\/td>\n      <td>Da basso a moderato, generazione in app\/proxy<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Conflitti<\/strong><\/td>\n      <td>Possibili deviazioni dell'orologio<\/td>\n      <td>Possibilit\u00e0 di configurare in modo errato i tag weak\/strong<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Impostazioni corrette per la cache del browser e le API<\/h2>\n\n<p>Per le risorse statiche, uso il lungo <strong>et\u00e0 massima<\/strong> e salvare tramite ETag o hash del nome del file, in modo che gli aggiornamenti vengano riconosciuti immediatamente. Spesso contrassegno le risposte HTML e API con no-cache, in modo che il client le convalidi prima dell'uso senza dover ricaricare tutto ogni volta. Contrassegno le pagine personalizzate con private, in modo che le cache condivise non mostrino nulla che sia stato conservato ad altri. Gli errori sono spesso causati da direttive contraddittorie o da intestazioni di convalida mancanti, che evito con regole chiare. Se si conoscono gli ostacoli tipici, \u00e8 possibile evitarli facilmente; buoni esempi di ci\u00f2 si trovano nell'articolo su <a href=\"https:\/\/webhosting.de\/it\/http-cache-headers-sabotare-caching-cachefix\/\">Trappole di intestazione nella cache<\/a>, su cui mi piace orientarmi.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/http-conditional-cache-validation-3847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Utilizzare efficacemente i codici di stato e le condizioni<\/h2>\n\n<p>Organizzo <strong>Codici di stato<\/strong> Chiaramente: 200 OK fornisce il contenuto, 304 Not Modified conferma l'uso della cache e 412 Precondition Failed annulla se una condizione non \u00e8 soddisfatta. Per le operazioni di scrittura sicure, uso If-Match, in modo che gli aggiornamenti abbiano effetto solo se l'ETag corrisponde alla versione prevista. La lettura con If-None-Match o If-Modified-Since evita payload superflui e mantiene i client sincronizzati. \u00c8 importante un comportamento coerente: Lo stesso endpoint deve rispondere in modo identico per condizioni preliminari identiche. Per la SEO e i bot, faccio attenzione a come cache e crawler interpretano i messaggi di stato; una buona panoramica di <a href=\"https:\/\/webhosting.de\/it\/codici-di-stato-http-crawling-ottimizzazione-hosting-crawlboost\/\">Codici di stato HTTP e crawling<\/a> aiuta a prendere decisioni pulite.<\/p>\n\n<h2>Sicurezza e protezione dei dati per la cache<\/h2>\n\n<p>Tratto i contenuti sensibili con <strong>no-store<\/strong> e quindi non hanno alcuna possibilit\u00e0 di finire nella cache del browser o del proxy. Contrassegno le pagine personalizzate con Cache-Control: private e controllo che nessun dato personale compaia negli URL memorizzati nella cache a lungo termine. Progetto ETag in modo neutrale, senza permettere di trarre conclusioni su account utente o ID interni. Disattivo costantemente la cache per le visualizzazioni di login e i flussi bancari. Se si combinano minimizzazione dei dati, direttive adeguate e intestazioni pulite, si riduce il rischio e si proteggono i dati. <strong>Riservatezza<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/http_cache_validierung_6789.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Implementazione: Passi per il server e l'applicazione<\/h2>\n\n<p>All'inizio separo <strong>statico<\/strong> delle risorse dinamiche e decido dove le scadenze lunghe hanno senso e dove la convalida ha la priorit\u00e0. In Nginx, Apache o in un server app, configuro il controllo della cache e attivo l'ultima modifica e gli ETag, inserendo la generazione degli ETag nell'applicazione per gli endpoint dinamici. Quando elaboro le richieste in entrata, valuto If-None-Match e If-Modified-Since e rispondo con 304 se la condizione corrisponde. Per le operazioni di scrittura, uso If-Match e restituisco 412 in caso di deviazioni per evitare la sovrascrittura. In questo modo si crea un comportamento coerente che utilizza le cache in modo efficiente e allo stesso tempo <strong>Correttezza<\/strong> assicura.<\/p>\n\n<h2>Utilizzate metriche, test e monitoraggio in modo sensato<\/h2>\n\n<p>Controllo il <strong>Rete<\/strong>-di DevTools per verificare se le risorse provengono dalla cache, sono in fase di convalida o sono appena caricate. Monitoro lo stato, i valori di et\u00e0, gli ETag e la dimensione della risposta trasferita. Sotto carico, misuro la latenza, il volume di trasferimento e la CPU del server per vedere l'effetto effettivo delle 304 risposte. I log del reverse proxy mostrano se le cache condivise stanno facendo il loro lavoro e quante convalide hanno successo. Utilizzo questi dati per regolare l'et\u00e0 massima, le direttive di controllo della cache e le strategie di ETag fino a quando i tempi di risposta e le <strong>Tasso di successo<\/strong> voto.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/EntwicklerdeskCache3178.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Prestazioni dell'hosting: perch\u00e9 le richieste condizionali fanno risparmiare denaro<\/h2>\n\n<p>Qualsiasi <strong>304<\/strong>-La risposta della cache condivisa risparmia larghezza di banda, riduce l'overhead TLS e accorcia il tempo di risposta, il che \u00e8 particolarmente importante per molte richieste simili. Nelle configurazioni di hosting con reverse proxy, bilanciatori di carico e CDN, ottengo il massimo effetto quando permetto chiaramente o escludo specificamente le cache condivise. Meno trasferimenti spesso significano anche minori costi di traffico in euro e maggiori riserve per i picchi di carico reali. Anche l'esperienza dell'utente \u00e8 migliorata, perch\u00e9 le visualizzazioni ripetute delle pagine e i sondaggi API rispondono pi\u00f9 rapidamente. In questo modo, realizzo un potenziale di prestazioni che i soli aggiornamenti hardware non sono in grado di fornire e utilizzo le risorse esistenti. <strong>Infrastrutture<\/strong> meglio.<\/p>\n\n<h2>Errori comuni e soluzioni pragmatiche<\/h2>\n\n<p>Contraddittorio <strong>Intestazione<\/strong> come no-cache abbinato a scadenze lontane nel tempo confondono le cache; stabilisco regole chiare senza duplicazioni. Gli ETag mancanti per gli endpoint dinamici portano a inutili download completi; aggiungo un identificatore affidabile e valuto se non c'\u00e8 corrispondenza. Valori di et\u00e0 massima troppo brevi sprecano potenziale con file modificati raramente; allungo le scadenze e le proteggo comunque con la convalida. Una cache aggressiva dell'HTML ritarda le modifiche visibili; combino no-cache con ETag e mantengo i contenuti aggiornati. Con decisioni chiare sulla freschezza, la convalida e la validit\u00e0, risolvo questi ostacoli e rafforzo il sistema. <strong>Pianificabilit\u00e0<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/cache-validierung-5836.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Utilizzare Vary in modo pulito e controllare le rappresentazioni<\/h2>\n\n<p>Per garantire che le richieste condizionali funzionino in modo sicuro nelle cache condivise, mi assicuro di usare la corretta opzione <strong>Variare<\/strong>. L'intestazione definisce quali intestazioni della richiesta influenzano la rappresentazione. Esempi tipici sono <em>Accetta codifica<\/em> (gzip, br), <em>Lingua accettata<\/em> e <em>Accettare<\/em>. Se fornisco contenuti per lingua, imposto Vary: Accept-Language in modo che un proxy non condivida la versione tedesca in risposta a una richiesta francese. Per i contenuti personalizzati, faccio deliberatamente a meno di Vary: Cookie e uso invece <em>Controllo della cache: privato<\/em>, per evitare un'esplosione incontrollabile di chiavi di cache. Per le risorse che vengono consegnate solo con un'autorizzazione valida, utilizzo private o garantisco una chiara separazione con Vary: Authorisation o Vary sulle intestazioni pertinenti. La coerenza \u00e8 importante: l'insieme selezionato di dimensioni Vary deve rimanere stabile, altrimenti il tasso di accesso alla cache e i vantaggi della validazione crolleranno a causa della creazione costante di nuove varianti.<\/p>\n\n<h2>ETag forti e deboli, compressione e uguaglianza dei byte<\/h2>\n\n<p><strong>ETag forti<\/strong> caratterizzano le rappresentazioni identiche byte per byte e consentono una validazione precisa, anche in combinazione con le richieste di intervallo. <strong>ETag deboli<\/strong> (W\/...) segnalano solo l'uguaglianza dei contenuti, non necessariamente byte identici. In pratica, uso ETag forti se posso generare un identificatore unico per ogni rappresentazione (compresa la compressione). Non appena un reverse proxy utilizza gzip o brotli al volo, adatto la generazione di ETag o passo a ETag deboli, in modo che il server e il client non riconoscano erroneamente byte diversi come identici. Una variante robusta \u00e8 quella di creare l'ETag dai byte finali della risposta consegnata e allo stesso tempo di usare <em>Vary: Accept-Encoding<\/em> da impostare. Questo assicura che \u201egzip\u201c e \u201ebr\u201c ricevano ciascuno il proprio ETag valido. Nei casi in cui non posso garantire l'uguaglianza dei byte (ad esempio, timestamp diversi nell'HTML), scelgo ETag deboli che consentono comunque risposte 304 affidabili, purch\u00e9 il significato della pagina non sia cambiato.<\/p>\n\n<h2>Controllo della cache nella regolazione fine: s-maxage, must-revalidate, stale-while-revalidate<\/h2>\n\n<p>Inoltre <em>et\u00e0 massima<\/em> In particolare, uso direttive pi\u00f9 fini. <strong>s-maxage<\/strong> si rivolge esclusivamente <em>Cache condivise<\/em> (CDN, proxy) e mi permette di effettuare la cache in modo pi\u00f9 aggressivo rispetto al browser. <strong>deve essere convalidato nuovamente<\/strong> obbliga i clienti a non utilizzare i contenuti scaduti in modo euristico, ma a convalidarli sempre - utile per i dati critici. <strong>proxy-revalidate<\/strong> affronta questo obbligo in modo specifico per le cache condivise. Con <strong>stale-while-revalidate<\/strong> Permetto di consegnare temporaneamente una copia leggermente obsoleta mentre la convalida \u00e8 in corso in background; gli utenti vedono subito qualcosa e la richiesta successiva beneficia di metadati freschi. <strong>stale-if-error<\/strong> come rete di sicurezza: Se l'origine fallisce o restituisce errori, la cache pu\u00f2 consegnare l'ultima copia conosciuta per un periodo di tempo definito. Per le risorse con build-hashed, combino un lungo max-age con <em>immutabile<\/em>, poich\u00e9 il nome del file cambia con il contenuto e le convalide intermedie non sono necessarie. Per l'HTML e le API, no-cache pi\u00f9 validatore rimane il gold standard per garantire l'aggiornamento e risparmiare larghezza di banda.<\/p>\n\n<h2>Ulteriori condizioni e metodi: TESTA, gamma e conflitti di scrittura<\/h2>\n\n<p>Le richieste condizionali non sono limitate a GET. A <strong>HEAD<\/strong>-request fornisce solo le intestazioni ed \u00e8 ideale per le convalide veloci senza corpo. Per i file di grandi dimensioni uso <strong>Gamma<\/strong>-richieste; con <strong>Se-Range<\/strong> Mi assicuro che le aree parziali siano inviate solo se la risorsa corrisponde ancora alla versione prevista, altrimenti rispondo con 200 e un corpo completo. Per le operazioni di scrittura, assicuro la coerenza con <strong>Se-Corrispondenza<\/strong> ab: PUT, PATCH o DELETE funzionano solo se l'ETag del client corrisponde alla versione corrente; altrimenti rispondo con 412 Precondition Failed. Quando voglio far rispettare le precondizioni, per esempio con risorse a rischio di conflitto, uso 428 Precondition Required per far s\u00ec che i client usino If-Match. Scelgo deliberatamente tra 409 Conflict e 412: 412 segnala le precondizioni violate, 409 enfatizza i conflitti di contenuto (ad esempio, le regole di business logic). Questa chiarezza facilita le implementazioni dei client ed evita le sovrascritture cieche.<\/p>\n\n<h2>Personalizzazione, cookie e protezione dei dati nella pratica<\/h2>\n\n<p>Per le pagine personalizzate, contrassegno le risposte con <strong>privato<\/strong> oppure <strong>no-store<\/strong>. Evito di codificare gli stati dell'utente in e-tag perch\u00e9 questi e-tag \u201eper utente\u201c possono involontariamente diventare marcatori di tracciamento. Invece, faccio una distinzione rigorosa tra rappresentazioni pubbliche e private. Imposto i cookie nella chiave della cache (Vary: Cookie) solo se assolutamente necessario, perch\u00e9 aumentano il numero di varianti e riducono drasticamente il tasso di risposta. Per le risposte API autorizzate mi attengo a <em>Controllo della cache: privato<\/em> e, se necessario, a Variare il formato dell'intestazione Autorizzazione. In questo modo mi assicuro che le cache condivise non condividano inavvertitamente risposte riservate. Nelle applicazioni con contenuti misti (struttura di base pubblica, sottoaree personalizzate), mi affido alla cache frammentata o all'edge ESI\/SSI, mentre le parti critiche rimangono private. Il risultato \u00e8 una protezione dei dati senza un calo delle prestazioni.<\/p>\n\n<h2>Operazione: CDN, surrogati e invalidazioni<\/h2>\n\n<p>Nelle configurazioni CDN combino <strong>s-maxage<\/strong> con validatori chiari e, se disponibili, utilizzare direttive specifiche per i surrogati per controllare le cache dei bordi separatamente dal browser. La riconvalida riduce il carico su Origin, ma di tanto in tanto \u00e8 necessaria un'invalidazione dura (per esempio, una correzione di sicurezza). Ho quindi previsto due modi: <em>Sfruttamento della cache<\/em> tramite hash dei nomi dei file per le risorse statiche e <em>Epurazione<\/em>\/Invalidazione per HTML e API. In questo modo si evitano le \u201etempeste di spurgo\u201c e si mantiene comunque un breve tempo di aggiornamento. \u00c8 anche importante avere una chiave di cache coerente nella CDN (compresi host, percorso, parametri di query e intestazioni Vary pertinenti). Per quanto riguarda i parametri di query, distinguo consapevolmente tra parametri semantici (ad esempio, ?lang=) e parametri puramente legati al tracciamento; ignoro questi ultimi nella chiave della cache per evitare la frammentazione. In questo modo la catena di cache del browser, proxy intermedio e CDN rimane trasparente e prevedibile.<\/p>\n\n<h2>304 in dettaglio: Aggiornare correttamente intestazione e metadati<\/h2>\n\n<p>Anche un <strong>304<\/strong>-La risposta contiene metadati importanti. Riporto Data, Cache-Control, ETag\/Last-Modified e, se rilevanti, Expires e Vary, in modo che il client possa aggiornare le sue voci nella cache. Content-Type e Content-Encoding non devono necessariamente essere ripetuti, ma possono contribuire alla chiarezza. \u00c8 importante che il 304 non contenga un payload del corpo e che invii validatori coerenti: Cambiare l'ETag nel 304 senza cambiare la rappresentazione porta a confusione. Se le linee guida vengono modificate (ad esempio, un'et\u00e0 massima pi\u00f9 lunga), il client pu\u00f2 adottare i metadati senza dover ricaricare il corpo: una piccola leva con un grande impatto sulle prestazioni percepite.<\/p>\n\n<h2>Strategie di test e debug per una validazione pulita<\/h2>\n\n<p>In DevTools controllo in particolare i seguenti punti: <em>dalla cache del disco<\/em> vs. <em>dalla memoria cache<\/em> vs. <em>riconvalidato<\/em>; Stato 200\/304; intestazione Age nelle risposte delle cache condivise; coerenza ETag\/Last-Modified ed effetto di Vary. Per test riproducibili, disattivo temporaneamente la cache del browser o utilizzo una modalit\u00e0 privata. Sul lato server, valuto i log sul rapporto 200\/304, la dimensione media delle risposte e l'utilizzo della CPU. I segnali di allarme sono, ad esempio, molte risposte 200 a risorse con intervalli di modifica brevi (validatori mancanti), cicli di riconvalida (tempi diversi\/deriva dell'orologio) o un numero insolitamente elevato di varianti per URL (Vary eccessivo). Uso i test di carico per verificare il comportamento di s-maxage, stale-while-revalidate e if-none-match sotto pressione e regolo le direttive finch\u00e9 throughput e latenza non corrispondono.<\/p>\n\n<h2>Casi limite e default robusti<\/h2>\n\n<p>Non tutte le risorse hanno regole di modifica chiare. Ho impostato dei valori predefiniti prudenti per le sitemap, i feed o i dashboard generati: <em>no-cache<\/em> pi\u00f9 ETag\/Last-Modified. In presenza di orologi instabili tra i sistemi upstream, evito confronti rigidi tra i secondi e preferisco ETag indipendenti dai timestamp. Se la compressione \u00e8 variabile (diversi livelli di gzip), includo il risultato della compressione nella generazione di ETag o passo a ETag deboli. E se i clienti richiedono senza validatori, invio segnali chiari: o freschezza chiara (max-age\/immutabile) o validazione chiara (no-cache + ETag). Questi <em>predefiniti robusti<\/em> garantire che anche i client incompleti o difettosi non provochino picchi di carico indesiderati.<\/p>\n\n<h2>Breve sintesi<\/h2>\n\n<p>Collegare le richieste condizionali <strong>Velocit\u00e0<\/strong> e tempestivit\u00e0, facendo in modo che i client recuperino risorse complete solo quando il contenuto \u00e8 cambiato. Uso il controllo della cache per la freschezza, combino l'ultimo modificato e l'ETag per controlli affidabili e rispondo coerentemente con 304 se le condizioni sono soddisfatte. Isolo i contenuti personalizzati e riservati con private o no-store, in modo che nessun dato finisca nelle cache condivise. Le misurazioni in DevTools, i registri e le metriche mi mostrano dove posso allungare le scadenze o rafforzare la logica di convalida. Se pensate a questi elementi costruttivi insieme, otterrete pagine pi\u00f9 veloci, un carico del server ridotto e una maggiore efficienza. <strong>rotondo<\/strong> Esperienza utente senza spreco di dati.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scoprite come le richieste condizionali HTTP e la convalida della cache con ETag, Last-Modified e Cache-Control ottimizzano la cache del browser e aumentano le prestazioni.<\/p>","protected":false},"author":1,"featured_media":19514,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-19521","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"89","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"HTTP Conditional","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"19514","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/19521","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=19521"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/19521\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/19514"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=19521"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=19521"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=19521"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}