it-swarm-eu.dev

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

Die Idee ist, den lokalen HTML5-Speicher zum Speichern von häufig aufgerufenem CSS und JavaScript 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 kenne den Browser-Cache, es wird noch einige Header-Zugriffsprüfungen geben,
Ich gehe davon aus, dass kein HTTP-Zugriff besser ist (in meinem Denken )

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

23
ajreal

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 JS & CSS-HTTP-Antwort so ein, dass sie zwischengespeichert werden kann. Es ist einfach und leicht.

Im 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? Verwenden Sie, wie Sie sagten, lokalen Speicher!

Wenn ein Browser die Site zum ersten Mal besucht, werden JS & CSS inline geschaltet. 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 bereits über JS & CSS verfügt. Der Render-HTML-Code verfügt also über Inline-JS, um JS und 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

11
Morgan Cheng

Tut der Browser das nicht schon für Sie und wahrscheinlich besser?

33
Bryan Boettcher

Was ist der Punkt?

Es gibt bereits eine gut etablierte Technik, die als clientseitiges Caching bezeichnet wird. Was bringt der lokale HTML5-Speicher in diesem Fall, welches 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.

Seien Sie sich auch einer anderen Sache bewusst. Browser haben spezielle Richtlinien für den Cache, und die meisten Browser können den Cache recht gut verwalten (nur ältere Inhalte entfernen usw.). Indem Sie Ihren selbst erstellten Cache implementieren, verhindern Sie, dass die Browser ihn korrekt verwalten. Es kann nicht nur selbst kritisiert werden, sondern es wird auch weh tun Sie bald oder später. Beispiel: Wenn die Benutzer einer Webanwendung Fehler melden, antworten Sie häufig, indem Sie sie bitten, ihren Cache zu leeren. Ich bin mir nicht sicher, was Sie in Ihrem Fall fragen werden, da das Löschen 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örend):

Ich kenne den Browser-Cache, es wird immer noch eine Header-Zugriffsprüfung geben

Sie scheinen kein Verständnis für das Zwischenspeichern von Browsern zu haben. Aus diesem Grund ist es wichtig zu verstehen, wie es zuerst funktioniert, bevor Sie mit der Implementierung Ihres eigenen hausgemachten Caching-Mechanismus beginnen. Erfinden Sie Ihr eigenes Rad nur neu, wenn Sie die vorhandenen Räder ausreichend verstehen und einen guten Grund haben, sie nicht zu verwenden. Siehe Punkt 1 von meine 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.
  • Expires gibt an , wann der Browser den Server fragen muss, ob sich der Inhalt geändert hat .

Mit diesen beiden Headern kann der Browser:

  • Vermeiden Sie es, den Inhalt immer wieder herunterzuladen. Wenn Last-Modified Auf 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 Expires einer Cache-Entität der 5. Mai istth, 2014 müssen Sie weder 2011 noch 2012 oder 2013 eine GET-Anfrage stellen, da Sie wissen, dass der Cache auf dem neuesten Stand ist.

Der zweite ist für CDNs unerlässlich. Wenn Google einem Besucher von Stack Overflow JQuery bereitstellt oder cdn.sstatic.net Bilder oder Stylesheets bereitstellt, die von Stack Overflow verwendet werden, möchten sie nicht, dass Browser jedes Mal nach einer neuen Version fragen. Stattdessen werden diese Dateien einmal bereitgestellt, das Ablaufdatum wird auf einen ausreichend langen Wert festgelegt, und das ist alles.

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

A screenshot of Stack Overflow timeline in Chrome shows 15 files, 3 being requested, 12 being served from cache directly with no requests to remote servers

Es stehen 15 Dateien zur Verfügung. Aber wo sind all diese 304 Not Modified Antworten? Sie haben nur drei Inhaltsanfragen, die sich geändert haben. 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 zu Beginn meiner Antwort sagte, kann ich nur eines finden: Wo Sie Teile von JavaScript bereitstellen, um sie über OMG, eval() zu verwenden. Aber in diesem Fall bin ich mir ziemlich sicher, dass es bessere Ansätze gibt, die entweder:

  • Effektiver mit den Standard-Cache-Techniken oder
  • Einfacher zu warten.
23

Das clientseitige lokale Caching sollte wesentlich optimierter sein als die Verwendung des lokalen HTML5-Speichers. Stellen Sie einfach sicher, dass sich Ihr Javascript und CSS in externen zwischenspeicherbaren 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 selbst auszuführen.

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

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

7
jfriend00

Anstatt das Rad neu zu erfinden, verwenden Sie einfach die HTML5-Offline-Funktionalität: http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html

5
ZippyV

Sie erzielen eine viel bessere Leistung, wenn Sie ein Content Delivery Network (CDN) wie Googles Codebibliothek verwenden. Nachdenklich geplant, sollte sich der Großteil Ihrer JS und CSS im Cache jedes Besuchers befinden, bevor er zum ersten Mal auf Ihre Website gelangt. Minimieren Sie den Rest.

Sie können das Browser-Caching jederzeit mit Ihrer handgerollten HTML5-Lösung vergleichen. Aber meine Wette ist, dass das native Caching die Hosen davon schlagen wird.

2
cczona

Die Verwendung von localStorage ist schnell (äh)! Mein Test hat gezeigt

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

Ich denke, das Speichern der HTTP-Anfrage bringt bereits einen großen Geschwindigkeitsvorteil. Jeder hier scheint vom Gegenteil überzeugt zu sein, also beweise mir bitte das Gegenteil.

Wenn Sie meine Ergebnisse testen möchten, habe ich eine winzige Bibliothek erstellt, in der Skripte in localStorage zwischengespeichert werden. Probieren Sie es auf Github aus https://github.com/webpgr/cached-webpgr.js oder kopieren Sie 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)};

Die Bibliothek anrufen

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');
});
2
select