Ich habe das Gefühl, dass ETags einen erheblichen positiven Einfluss auf die Leistung beim Laden von Seiten haben würden, da die meisten HTML-Seiten nicht zwischengespeichert werden. Dies würde den Server davon entlasten, die Seite erneut auszuliefern, wenn der Client sie bereits heruntergeladen hat.
Gab es dazu schon Überlegungen?
Ich könnte mich irren, aber Discourse ist bereits stark von clientseitigem JavaScript abhängig, sodass der Client nur minimale Daten herunterlädt. Fast alles wird beim ersten Besuch geladen und anschließend zwischengespeichert. Ich weiß wirklich nicht, inwieweit ETags diesen Caching-Prozess verbessern könnten.
Zum Beispiel beträgt die Größe beim ersten Laden meiner Seite etwa 800 KB, beim zweiten Mal nur etwa 40 KB.
Discourse ist bereits sehr gut für Caching konzipiert und eingerichtet.
Die meisten Site-Ressourcen (JS, CSS) verfügen über eindeutige URLs, die bei jedem Update der Site mit einem Hash der Ressource generiert werden, sodass sie lange Cache-Zeiten haben können.
Ich glaube, dass auch Site-Uploads (Bilder, Avatare usw.) eindeutige URLs verwenden.
Die meisten vollständigen Seiten, die Sie sehen können, sind dynamisch und sollten nicht aggressiv gecacht werden. Es wäre zwar möglich, eine Art ETag-Caching zu implementieren, bei dem bei jedem Seitenaufruf geprüft wird, ob neue oder bearbeitete Beiträge vorliegen. Ich bin mir nicht sicher, warum das Team sich dagegen entschieden hat.
Ich hätte präzisieren sollen: Die Assets werden tatsächlich gut zwischengespeichert – worum es mir geht, ist das HTML-Dokument (erste Anfrage).
Die meisten vollständigen Seiten, die du siehst, sind dynamisch und sollten nicht aggressiv zwischengespeichert werden. Es wäre möglich, eine Art ETag-Caching zu implementieren, bei dem bei jedem Seitenaufruf geprüft wird, ob es neue oder bearbeitete Beiträge gibt. Ich bin mir nicht sicher, warum das Team sich dafür entschieden hat, dies nicht zu tun.
Ja, genau das meine ich im Wesentlichen, aber ich glaube nicht, dass ETags manuell so generiert werden – sie können auf dem bereitgestellten Roh-HTML basieren und dem Client mitteilen: „Hey, das ist exakt das, was du vorher gesehen hast, nutze einfach das.
Das ist der Punkt: Meines Wissens nach passiert das bereits mit dem JavaScript auf der Client-Seite. Sie haben also keinen HTML-Austausch.
Das HTML lädt JSON vom Server, und diese JSON-Anfrage könnte ETags verwenden. Derzeit ist dies jedoch nicht der Fall, wobei mir das Argument des Teams dafür nicht bekannt ist.
Die erste Anfrage an eine Seite hat definitiv gerenderten Inhalt, bevor JSON über XHR vom Server geladen wird – was du zu Recht erwähnt hast, findet ebenfalls statt.
Du kannst dies überprüfen, indem du die Netzwerk-Anfrage vom Typ „Document“ im Chrome Debugger ansiehst. Sie sollte (zumindest in meinem Fall) die bereits gerenderten Kategorien enthalten.
Hier ist ein Beispiel dafür, was aus der Dokumentanfrage gerendert wird:
Ihre Anfrage ist unsinnig, da Discourse eine JavaScript-Anwendung ist, die kein HTML lädt. Alle „Seiten
Deine Anfrage ist unsinnig, da Discourse eine JavaScript-App ist, die kein HTML abruft.\n\nIch respektiere deine Erfahrung und Expertise hier voll und ganz, aber ich habe Dutzende von JavaScript gerenderten Webanwendungen betrieben, die ETags in der Root-Antwort verwenden (falls der Inhalt wiederverwendet werden kann).\n\n> Alle „Seiten
Nur für Crawler-User-Agents, also ist dies keine nützliche Beobachtung.
Nur für Crawler-User-Agents
Das ist nicht das, was ich sehe, wenn ich dies ausführe:
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/
Das ist kein Crawler-User-Agent, und es wird dennoch die oben genannte Nutzlast zurückgegeben.
Unabhängig davon scheint die Antwort auf meine Anfrage nach ETags ein „Nein
Richtig, die Antwort ist aus philosophischen und technischen Gründen ein hartes, eindeutiges Nein.
(Assets sind ein anderes Thema, aber die Verwendung eindeutiger Dateinamen mit einer GUID ist ein weit überlegener Ansatz, sodass ETags im Allgemeinen eher veraltet sind.)
Auch für die API? Bei kleineren Anfragen kann ich verstehen, dass es sich wahrscheinlich nicht lohnt, aber die Themenansichten können bis zu 20 KB betragen, was sich summieren würde. Allerdings schauen sich nicht viele Leute Themen wiederholt an, es sei denn, es gibt neue Beiträge.
Genau das ist der Punkt. Bei wiederholten Aufrufen exakt desselben Inhalts: Wenn Sie offline sind, wird der gesamte Inhalt bereits aus dem Browser-Cache gerendert, ohne den Server zu kontaktieren.
Dies so zu erweitern, dass es auch geladen wird, wenn Sie online sind, erfordert eine Cache-Invalidierung, weshalb es natürlich schwierig ist.
Ah, gut zu hören, dass das funktioniert. Ich hätte gedacht, dass der Header cache-control: no-cache, no-store bedeutet, dass API-Antworten niemals in den Browser-Cache gelangen.
Das tun sie nicht. Nun, es ist kompliziert. Es sind mehrere Caches im Spiel 
Es gelangt nicht in den herkömmlichen Browser-Cache, den alle kennen und lieben. Es gibt jedoch eine Cache Web-API, die Browsern in JS zur Verfügung gestellt wird und die verwendet wird, um Antworten zu zwischenspeichern, um die Offline-Navigation von zuvor gelesenen Inhalten zu ermöglichen.
