Ich versuche, die Leistung einer Webanwendung zu verbessern. Ich habe Metriken, mit denen ich die Zeit für die Rückgabe der Haupt-HTML-Seite optimieren kann, aber ich mache mir Sorgen um die externen CSS- und JavaScript-Dateien, die von diesen HTML-Seiten enthalten sind. Diese werden statisch mit HTTP Expires-Headern bereitgestellt, aber sie werden von allen Seiten der Anwendung gemeinsam genutzt.
Ich mache mir Sorgen, dass der Browser diese CSS- und JavaScript-Dateien für jede angezeigte Seite parsen muss, so dass sich die gesamte CSS- und JavaScript-Funktionalität für die Website in gemeinsamen Dateien negativ auf die Leistung auswirkt. Sollte ich versuchen, diese Dateien zu teilen, so verlinke ich von jeder Seite nur zu dem CSS und JavaScript, das für diese Seite benötigt wird, oder würde ich für meine Bemühungen wenig zurückbekommen?
Gibt es irgendwelche Tools, die mir dabei helfen könnten, Messwerte zu generieren?
Kontext: Es stimmt zwar, dass der HTTP-Overhead wichtiger ist als die Analyse von JS und CSS, aber die Auswirkungen der Analyse auf die Browserleistung zu ignorieren (auch wenn Sie weniger als ein Megabyte JS haben) ist gut Möglichkeit, sich selbst in Schwierigkeiten zu bringen.
YSlow, Fiddler und Firebug sind nicht die besten Werkzeuge, um die Analysegeschwindigkeit zu überwachen. Sofern sie nicht in letzter Zeit aktualisiert wurden, unterscheiden sie nicht die Zeit, die benötigt wird, um JS über HTTP zu laden oder vom Cache zu laden, im Vergleich zu der Zeit, die beim Parsen der tatsächlichen JS-Nutzlast aufgewendet wurde.
Die Parse-Geschwindigkeit ist etwas schwierig zu messen, aber wir haben diese Metrik einige Male in Projekten verfolgt, an denen ich gearbeitet habe, und die Auswirkungen auf Pageloads waren sogar bei ~ 500.000 JS signifikant. Offensichtlich leiden die älteren Browser am meisten ... hoffentlich helfen Chrome, TraceMonkey und dergleichen, diese Situation zu lösen.
Vorschlag: Abhängig von der Art des Datenverkehrs, den Sie auf Ihrer Site haben, kann es sich lohnen, Ihre JS-Payload so zu teilen, dass einige große Teile von JS nie auf einem verwendet werden Die beliebtesten Seiten werden niemals an den Client gesendet. Dies bedeutet natürlich, dass wenn ein neuer Kunde eine Seite erreicht, auf der dieser JS benötigt wird, Sie ihn über die Leitung senden müssen.
Es kann jedoch durchaus sein, dass 50% Ihres JS von 80% Ihrer Benutzer aufgrund Ihrer Traffic-Muster nie benötigt werden. Wenn dies der Fall ist, sollten Sie kleinere, gepackte JS-Payloads nur auf Seiten verwenden, auf denen JS benötigt wird. Andernfalls erleiden 80% Ihrer Benutzer unnötige JS-Parsing-Strafen bei jedem einzelnen Pageraden .
Bottom Line: Es ist schwierig, das richtige Gleichgewicht zwischen JS-Caching und kleineren, gepackten Payloads zu finden. Aber abhängig von Ihrem Traffic-Muster lohnt es sich, eine andere Technik in Erwägung zu ziehen jede einzelne Seitenladung.
Ich glaube YSlow , aber bedenken Sie, dass Sie sich keine Sorgen machen sollten, wenn nicht alle Anfragen über eine Loopback-Verbindung laufen. Der HTTP-Overhead von aufgeteilten Dateien wirkt sich mehr auf Leistung als auf Parsing aus, es sei denn, Ihre CSS / JS-Dateien überschreiten mehrere Megabyte.
Um zu kamens großer Antwort hinzuzufügen, würde ich sagen, dass in einigen Browsern die Analysezeit für größere js-Ressourcen nichtlinear wächst. Das heißt, eine 1-Megabyte-JS-Datei dauert länger als zwei 500-k-Dateien. Wenn ein großer Teil Ihres Traffics also Personen sind, deren JS wahrscheinlich zwischengespeichert wird (Besucher zurückgeben) und alle Ihre JS-Dateien cache-stabil sind, kann es sinnvoll sein, sie zu trennen, selbst wenn Sie sie alle laden jeder Seitenaufruf.
Tags und Links javascript css performance