Penso che gli ETag avrebbero un impatto positivo significativo sulle prestazioni dei caricamenti delle pagine, dato che la maggior parte delle pagine HTML non è memorizzata nella cache. Questo eviterebbe al server di dover servire la pagina se il client l’ha già scaricata.
È stata presa in considerazione questa possibilità?
Potrei sbagliarmi, ma Discourse dipende già pesantemente dal JavaScript lato client, quindi ciò che il client scarica sono dati minimi. Quasi tutto viene caricato nella prima visita e poi memorizzato nella cache. Non so davvero quanto gli ETag possano migliorare quel processo di caching.
Ad esempio, il primo caricamento della mia pagina è di circa 800 KB, il secondo è di circa 40 KB
Discourse è già ben progettato e configurato per la memorizzazione nella cache.
La maggior parte delle risorse del sito (JS, CSS) dispone di URL univoci generati ogni volta che si aggiorna il sito con un hash della risorsa, in modo da poter avere tempi di cache elevati.
Penso che anche i file caricati sul sito (immagini, avatar, ecc.) utilizzino URL univoci.
La maggior parte delle pagine complete che è possibile visualizzare sono dinamiche e non dovrebbero essere memorizzate nella cache in modo aggressivo. Immagino che sarebbe possibile implementare un tipo di cache ETag che controlli ad ogni caricamento della pagina se non ci sono nuovi post o post modificati. Non sono sicuro del motivo per cui il team abbia deciso di non farlo.
Avrei dovuto chiarire: le risorse sono effettivamente ben memorizzate nella cache – di cui sto parlando è il documento HTML (prima richiesta).
La maggior parte delle pagine complete che puoi vedere sono dinamiche e non dovrebbero essere memorizzate nella cache in modo aggressivo. Immagino che sarebbe possibile implementare un tipo di caching con ETag che controlli ad ogni caricamento della pagina se non ci sono nuovi post o post modificati. Non sono sicuro del motivo per cui il team abbia deciso di non farlo.
Sì, è essenzialmente di questo che sto parlando, ma non credo che gli ETag vengano generati manualmente in quel modo – possono essere basati sull’HTML grezzo che viene servito e possono comunicare al client: “ehi, questo è esattamente ciò che hai visto prima, usa quello”
Il punto è che, a quanto ne so, questo avviene già con il JS lato client. Quindi, non c’è scambio di HTML.
L’HTML carica il JSON dal server, e quella richiesta JSON potrebbe utilizzare gli ETag. Attualmente non lo fa, anche se non sono sicuro della motivazione del team a riguardo.
La prima richiesta a una pagina ha sicuramente renderizzato il contenuto prima di caricare il JSON dal server tramite XHR, il che, come giustamente hai notato, sta effettivamente accadendo.
Puoi verificare questo ispezionando la richiesta di rete di tipo “Document” negli Strumenti per sviluppatori di Chrome: dovrebbe contenere (almeno nel mio caso) le categorie già renderizzate.
Ecco un esempio di ciò che viene renderizzato dalla richiesta del documento:
La tua richiesta è priva di senso perché Discourse è un’app JavaScript che non recupera HTML; tutte le “pagine” vengono costruite in tempo reale tramite codice JavaScript eseguibile.
La tua richiesta è insensata perché Discourse è un’applicazione JavaScript che non recupera HTML.
Rispetto pienamente la tua esperienza e la tua competenza in materia, ma ho gestito dozzine di applicazioni web renderizzate in JavaScript che utilizzano ETag nella risposta radice (se il contenuto può essere riutilizzato).
tutte le “pagine” vengono costruite in tempo reale tramite codice JavaScript eseguibile.
Lo screenshot che ho pubblicato sopra è l’HTML restituito prima dell’esecuzione di qualsiasi codice lato client, quindi c’è sicuramente qualcosa sul backend (presumo Rails) che serve questa rotta.
Ogni singola community Discourse che ho esaminato (tranne questa) restituisce inizialmente una versione del sito senza JavaScript con tutto il contenuto già renderizzato, presumibilmente per i crawler.
Mi scuso se ho completamente sbagliato, ma non credo di essere “insensato”; potrei semplicemente avere torto.
Solo per gli user agent dei crawler, quindi questa non è un’osservazione utile.
Solo per agenti utente crawler
Non è quello che vedo quando eseguo questo:
curl -H "User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36" https://community.midi.city/
Quello non è un agente utente crawler e sta restituendo il payload sopra.
Comunque, penso che la risposta alla mia richiesta di ETag sia “no”, quindi grazie per il feedback e forse sarà rivalutato in qualche momento.
Corretto, la risposta è un netto e definitivo no, sia per motivi filosofici che tecnici.
(Le risorse sono un discorso a parte, ma l’uso di nomi file unici con un GUID è un approccio nettamente superiore, quindi gli ETag sono in generale un po’ obsoleti.)
Anche per l’API? Potrei capire che per le richieste più piccole non ne valga la pena, ma le visualizzazioni dei topic possono arrivare fino a 20 KB, il che si accumulerebbe. Tuttavia, non molte persone visualizzano i topic ripetutamente a meno che non ci siano nuovi post..
Questo è il punto. Per visualizzazioni ripetute dello stesso contenuto esatto, se sei offline, rendiamo già tutto il contenuto dalla cache del browser senza toccare il server.
Aggiornare questa funzionalità per caricare anche se sei online richiede l’invalidazione della cache, quindi naturalmente è difficile.
Oh, bene sapere che funziona. Avrei pensato che l’header cache-control: no-cache, no-store significasse che le risposte API non entrerebbero mai nella cache del browser.
Non lo fanno. Beh, è complicato. Sono coinvolti più livelli di cache 
Non entra nella cache convenzionale del browser che tutti conoscono e amano. Ma esiste un’API Cache Web API esposta ai browser in JavaScript, utilizzata per memorizzare nella cache le risposte al fine di fornire la navigazione offline dei contenuti già letti.
