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 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)

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

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

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:

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.

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.

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

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.

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