Ist es realistisch, den lokalen HTML5-Speicher zum Speichern von CSS und JavaScript zu verwenden?

22

Die Idee ist, den lokalen HTML5-Speicher zum Speichern von häufig verwendeten CSS- und JavaScript-Inhalten zu verwenden.

Zum Beispiel (Pseudocode):

var load_from_cdn = true;
if (lokalen Speicher erkennen)  
{
  if (Cache von CSS, js gefunden)
  {
     Laden Sie den lokalen Speichercache
     load_from_cdn = false;
  }
}
if (load_from_cdn)
{
   document.write ('<script> ...');
}

Ist das möglich oder realistisch?

Ich bin mir des Browser-Cache bewusst, es wird immer noch eine Überprüfung des Header-Zugriffs geben. Ich gehe
davon aus , dass kein HTTP-Zugriff besser ist (meiner Meinung nach ).

PS: Es scheint, dass lokaler Speicher nur Schlüssel-Wert-Paare unterstützt. Kann jemand dies beweisen?
(am besten mit einigen Beispielen)

ajreal
quelle
1
Wikipedia versuchte dies anscheinend mit großer Wirkung: twitter.com/catrope/status/408018210529615872 twitter.com/catrope/status/408018210529615872/photo/1
Dave
1
Das ist meine Idee vor 2 Jahren ... :)
Ajreal
Ihre Frage war das erste, was ich fand, als ich darüber googelte. Es gab hier viele Diskussionen darüber, ob es eine gute Idee war oder nicht, also dachte ich, ich würde ein paar anekdotische Beweise dafür liefern!
Dave
1
Das Bild ist irreführend. Wenn Sie weiter nach unten scrollen, können Sie sehen, dass der riesige Drop nicht tatsächlich war, weil localstorage besser war als Caching, sondern ein Fehler in der Caching-Konfiguration: "Es stellte sich heraus, dass er weniger spektakulär war :(. Die Grafik zeigt den internen Verkehr, Drop wegen auf localStorage versteckt Caching Bug "- twitter.com/catrope/status/408110382599782400
Jamie Barker
check out addyosmani.com/basket.js
xhh

Antworten:

11

Es ist absolut in Ordnung, lokalen Speicher zum Speichern von JS und CSS zu verwenden. Der lokale Speicher hat jedoch eine Beschränkung von 5 MB pro Domäne. Möglicherweise müssen Sie diese Strategie überdenken.

Für das Desktop-Web können Sie den Standard-Browser-Cache nutzen, um den Trick auszuführen. Stellen Sie einfach die HTTP-Antwort von JS & CSS so ein, dass sie zwischengespeichert werden kann. Es ist einfach und leicht.

Beim mobilen Web ist die Latenz hoch. Das Reduzieren von HTTP-Anforderungen ist daher von entscheidender Bedeutung. Daher ist es optimal, JS & CSS in externen URLs zu haben. Es wäre viel besser, JS & CSS inline zu haben. Dadurch werden HTTP-Anforderungen reduziert, der HTML-Inhalt jedoch aufgebläht. Dann was? Wie Sie sagten, verwenden Sie lokalen Speicher!

Wenn ein Browser die Site zum ersten Mal aufruft, werden JS und CSS eingebunden. Der JS hat auch zwei weitere Jobs: 1) Speichern Sie JS & CSS im lokalen Speicher; 2) Setzen Sie das Cookie, um zu kennzeichnen, dass sich JS & CSS im lokalen Speicher befinden.

Wenn der Browser zum zweiten Mal auf die Site zugreift, hat der Server das Cookie erhalten und weiß, dass der Browser JS & CSS bereits zugeordnet hat. Daher verfügt das Render-HTML über Inline-JS, um JS & CSS aus dem lokalen Speicher zu lesen und in den DOM-Baum einzufügen.

Dies ist die Grundidee, wie die mobile Version von bing.com erstellt wird. Möglicherweise müssen Sie die JS- und CSS-Versionskontrolle berücksichtigen, wenn Sie sie in der Produktion implementieren.

Vielen Dank

Morgan Cheng
quelle
Ja, ziemlich nah an dem, woran ich denke.
Ajreal
Google hat ein Modul für den Page Speed ​​Mod entwickelt, das genau dasselbe tut. Hier ist die Seite, auf der sie über die Waren sprechen, schlechte und unbekannte Entwickler.google.com/speed/pagespeed/module/…
tacone
upvoted, aber wtf bedeutet in diesem Fall "inline". "inline" hat ungefähr 5 verschiedene Bedeutungen.
Alexander Mills
1
Es ist tatsächlich auf 10 MB für Desktop und 5 MB für Handy erhöht
Roko C. Buljan
1
Sie nicht brauchen alle Cookies. lesen Sie können einfach , wenn die localstorage den Schlüssel / Wert hat Sie suchen und Sie müssen eine Version (aus offensichtlichen Ungültigkeits Zwecke) zur Verfügung stellen. Dieser Trick ist erst nach dem zweiten Zugriff auf die Site und auch dann
sinnvoll,
33

Tut der Browser dies nicht bereits für Sie und wahrscheinlich auch besser?

Bryan Boettcher
quelle
2
man würde hoffen
Alexander Mills
23

Was ist der Punkt?

Es gibt bereits eine etablierte Technik, die als clientseitiges Caching bezeichnet wird. Was bringt der lokale HTML5-Speicher in diesem Fall, wenn Caching fehlt?

Möglicherweise haben Sie eine seltsame Anwendung, die Teile des JavaScript-Codes dynamisch laden muss, damit Sie den Cache nicht effektiv nutzen können. Dies ist jedoch ein äußerst seltener Fall.

Beachten Sie auch eine andere Sache. Browser haben spezielle Richtlinien für den Cache, und die meisten Browser können den Cache gut verwalten (nur ältere Inhalte entfernen usw.). Indem Sie Ihren selbst erstellten Cache implementieren, verhindern Sie, dass der Browser ihn ordnungsgemäß verwaltet. Es kann nicht nur von sich aus kritisiert werden, sondern es wird Sie auch früher oder später verletzen. Beispiel: Wenn die Benutzer einer Webanwendung Fehler melden, werden Sie häufig aufgefordert, den Cache zu leeren. Ich bin nicht sicher, was Sie in Ihrem Fall fragen werden, da das Leeren des Caches niemals Probleme mit Ihrer Web-App lösen wird.


Als Antwort auf Ihre erste Bearbeitung (Ihre zweite Bearbeitung ist nicht zum Thema gehörig):

Ich bin mir des Browsercaches bewusst, es wird noch einige Headerzugriffsüberprüfungen geben

Es scheint Ihnen ein gewisses Verständnis für das Browser-Caching zu fehlen. Deshalb ist es wichtig zu verstehen, wie es funktioniert, bevor Sie mit der Implementierung Ihres eigenen Caching-Mechanismus beginnen . Erfinden Sie Ihr eigenes Rad nur dann neu, wenn Sie die vorhandenen Räder ausreichend kennen und einen guten Grund haben, sie nicht zu verwenden. Siehe Punkt 1 meiner Antwort auf die Frage "Das Rad neu erfinden und es NICHT bereuen" .

Wenn Sie einige Daten über HTTP bereitstellen, können Sie einige Header angeben, die sich auf den Cache beziehen:

  • Last-Modified gibt an, wann der Inhalt geändert wurde,
  • ExpiresGibt an, wann der Browser den Server fragen muss, ob sich der Inhalt geändert hat .

Diese beiden Header ermöglichen dem Browser Folgendes:

  • Vermeiden Sie es, den Inhalt immer wieder herunterzuladen. Wenn Last-Modifiedauf den letzten Monat eingestellt ist und der Inhalt bereits einige Stunden zuvor heruntergeladen wurde, muss er nicht erneut heruntergeladen werden.
  • Fragen Sie nicht nach dem Datum, an dem die Datei zuletzt geändert wurde. Wenn Expireseine Cache - Einheit ist 5. Mai th , 2014 Sie keine GET - Anforderung ausgeben müssen weder im Jahr 2011 noch im Jahr 2012 oder 2013, da Sie wissen , dass der Cache ist up-to-date.

Der zweite ist wichtig für CDNs. Wenn Google einem Besucher von Stack Overflow JQuery bereitstellt oder von Stack Overflow verwendete cdn.sstatic.netBilder oder Stylesheets bereitstellt, sollen Browser nicht jedes Mal nach einer neuen Version fragen. Stattdessen liefern sie diese Dateien einmal aus, setzen das Ablaufdatum auf einen ausreichenden Wert und das ist alles.

Hier ist zum Beispiel ein Screenshot von dem, was passiert, wenn ich zur Stack Overflow-Homepage komme:

Ein Screenshot der Stack Overflow-Zeitleiste in Chrome zeigt 15 Dateien, von denen 3 angefordert und 12 direkt aus dem Cache bereitgestellt werden, ohne dass Anforderungen an Remoteserver gestellt werden

Es gibt 15 Dateien zu bedienen. Aber wo sind all diese 304 Not ModifiedAntworten? Sie haben nur drei geänderte Inhaltsanforderungen. Für alles andere verwendet der Browser die zwischengespeicherte Version, ohne eine Anfrage an einen Server zu stellen .


Abschließend müssen Sie wirklich zweimal überlegen, bevor Sie Ihren eigenen Cache-Mechanismus implementieren, und insbesondere ein gutes Szenario finden, in dem dies nützlich sein kann . Wie ich am Anfang meiner Antwort gesagt, kann ich nur eins: wo man Stücke von JavaScript dienen , sie zu verwenden , um durch, OMG, eval(). Aber in diesem Fall bin ich mir ziemlich sicher, dass es bessere Ansätze gibt:

  • Effektivere Verwendung der Standardcachetechniken oder
  • Einfacher zu warten.
Arseni Mourzenko
quelle
+1 für diesen. Es ist absolut sinnlos. Fast in allen Fällen absolut. Das Cachen mit einem eindeutigen, Hash-basierten Schlüssel ist viel besser.
Shabunc
1
Sie haben mit dem Browser-Cache nicht ganz recht. Bei einer harten Aktualisierung wird die gesamte Überprüfung des Browser-Cache bestanden.
Ajreal
1
Der Link zu reinventing the wheel and not regretting itist tot: '(
Esailija
4
Das Bowser-Caching ist nicht so einfach wie Sie vielleicht denken, und es ist auch nicht für alle Browser einheitlich. Zum Beispiel entscheiden sich einige Browser zufällig dafür, Web-Schriften zu laden (unabhängig von den Kopfzeilen - ich kann den Artikel dazu momentan nicht finden, aber ich denke, es war Dave Rupert, der dies entdeckt hat). Außerdem zwingen ETAGs Browser, zu überprüfen, ob eine Ressource aktualisiert wurde ... und manchmal können Sie ETAG nicht entfernen (z. B. Amazon S3). Wenn Ihre CSS-Datei also einen ETAG-Header sendet, wird immer nach Updates gesucht (304s) sind noch eine Nutzlast). Um unnötige Anforderungen zu vermeiden, ist ein benutzerdefiniertes Caching erforderlich.
Ryan Wheale
7

Das clientseitige lokale Caching sollte wesentlich optimierter sein als die Verwendung von lokalem HTML5-Speicher. Stellen Sie einfach sicher, dass sich Ihr Javascript und CSS in externen cachefähigen Dateien befinden und Ihre Seite über den Browser-Cache viel schneller geladen werden sollte, als wenn Sie versuchen, sie aus dem lokalen Speicher zu extrahieren und sie selbst auszuführen.

Außerdem kann der Browser beim Laden der Seite mit dem Laden externer Ressourcen beginnen, bevor Sie tatsächlich JavaScript auf dieser Seite ausführen können, um Ihre Ressourcen aus dem lokalen HTML5-Speicher abzurufen.

Außerdem benötigen Sie ohnehin Code auf der Seite, um aus dem lokalen HTML5-Speicher zu laden. Fügen Sie also all Ihre JS in eine externe, zwischenspeicherbare JS-Datei ein.

jfriend00
quelle
2

Mit einem Content Delivery Network (CDN) wie der Codebibliothek von Google erzielen Sie eine wesentlich bessere Leistung . Nachdenklich geplant, sollte sich der Großteil Ihrer JS- und CSS-Dateien im Cache jedes Besuchers befinden, bevor sie zum ersten Mal auf Ihre Website gelangen. Minimieren Sie den Rest.

Sie können das Browser-Caching immer mit Ihrer handgerollten HTML5-Lösung vergleichen. Aber ich wette, dass das native Caching die Hosen runterhauen wird.

cczona
quelle
2

LocalStorage ist schnell (er)! Mein Test zeigte

  • Laden von jQuery von CDN: Chrome 268ms , FireFox: 200ms
  • Laden von jQuery aus localStorage: Chrome 47ms , FireFox 14ms

Ich denke, das Speichern der HTTP-Anfrage bringt schon einen großen Geschwindigkeitsvorteil. Alle hier scheinen vom Gegenteil überzeugt zu sein. Bitte beweisen Sie mir das Gegenteil.

Wenn Sie meine Ergebnisse testen möchten, habe ich eine winzige Bibliothek erstellt, in der Skripts in localStorage zwischengespeichert werden. Schau es dir auf Github https://github.com/webpgr/cached-webpgr.js an oder kopiere es einfach aus dem folgenden Beispiel.

Die komplette Bibliothek:

function _cacheScript(c,d,e){var a=new XMLHttpRequest;a.onreadystatechange=function(){4==a.readyState&&(200==a.status?localStorage.setItem(c,JSON.stringify({content:a.responseText,version:d})):console.warn("error loading "+e))};a.open("GET",e,!0);a.send()}function _loadScript(c,d,e,a){var b=document.createElement("script");b.readyState?b.onreadystatechange=function(){if("loaded"==b.readyState||"complete"==b.readyState)b.onreadystatechange=null,_cacheScript(d,e,c),a&&a()}:b.onload=function(){_cacheScript(d,e,c);a&&a()};b.setAttribute("src",c);document.getElementsByTagName("head")[0].appendChild(b)}function _injectScript(c,d,e,a){var b=document.createElement("script");b.type="text/javascript";c=JSON.parse(c);var f=document.createTextNode(c.content);b.appendChild(f);document.getElementsByTagName("head")[0].appendChild(b);c.version!=e&&localStorage.removeItem(d);a&&a()}function requireScript(c,d,e,a){var b=localStorage.getItem(c);null==b?_loadScript(e,c,d,a):_injectScript(b,c,d,a)};

Aufruf der Bibliothek

requireScript('jquery', '1.11.2', 'http://ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js', function(){
    requireScript('examplejs', '0.0.3', 'example.js');
});
wählen
quelle
3
Ihre Maßnahmen sind irrelevant. (1) Wenn der Benutzer neu auf der Website ist, hat er ohnehin keine jQuery im lokalen Speicher. (2) Wenn andererseits der Benutzer Ihre Website bereits besucht hat, hat er jQuery im Cache, was bedeutet, dass es nicht vom CDN geladen wird. Dies führt auch zu einem dritten Punkt: (3) Lokaler Speicher ist für eine bestimmte Site geeignet, während jQuery auf Googles CDN von vielen Sites gemeinsam genutzt wird. Dies bedeutet, dass ein Nutzer, der beispielsweise Stack Overflow besucht hat, aber für Ihre Site neu ist, gewonnen hat Sie müssen jQuery nicht von CDN neu laden, wenn Sie dieselbe Version von jQuery verwenden.
Arseni Mourzenko
@MainMa Vielleicht ist diese Maßnahme nicht gut, ich sehe das jetzt, aber damit der Browser-Cache funktioniert, muss eine Anfrage an einen Server gesendet werden, der dann eine 304 zurückgibt. Diese Anfrage benötigt mehr Zeit, als die Datei direkt vom lokalen Speicher abzurufen . Korrigiere mich, wenn ich falsch liege.
wählen
@MainMa auch die Kommentare von überprüfen bitte programmers.stackexchange.com/a/105526/195684 es mehr Probleme mit dem Cache, wie der ETAG Vergleich sind , dass dieser Brauch schneller Cachen machen
wählen