[Frage Web] Weniger Dateien vs Cache - Ladezeit

Hallo,

mich würde mal eure Meinung und oder Erfahrung interessieren...

Was ist eurer Meinung nach besser:
a) bei jeder Seite die aufgerufen wird, nur die Dateien (CSS - JS - etc) einbinden die tatsächlich für diese Seite benötigt werden?

b) beim ersten Aufruf gleich alle Dateien laden lassen, damit diese gleich im Cache des Browsers landen und somit für jede Andere "Sub-"Seite zur Verfügung stehen?

Ergänzende Frage:
Würde b) nicht auch für alle Seiten außer der ersten die aufgerufen wird, das Problem mit "above the fold" lösen? Da ja die Dateien nicht mehr geladen werden müssen?

---------------------

Was macht Ihr so um die Ladezeit zu verbessern (OnPage - CDNs etc. lassen wir mal außen vor)?

Ich bin aktuell bei b) plus device optimierte Bilder - SVGs - sprites - BrowserCache - gezip - den Code Serverseitig komprimieren mit möglichst wenig Leerzeichen, Umbrüchen, Leerzeilen etc.

Mittlerweile verbanne ich selbst Analytics hinter den Footer...
Nur noch absolut Sinnvolles ist im Head an Scripten, wie zum Beispiel Mail (Ent-)Verschlüsselung, js und touch Erkennung und sowas.

Teilweise auch prefetch bzw. prerender - da bin ich mir aber nicht ganz sicher obs tatsächlich sinnvoll ist...


Viele Grüße

hab persönlich jetzt keine Erfahrungen vorzuweisen, aber ich denke, wenn sich die zu ladenden Dateien nicht oft ändern müsste man sie doch mit der HTML5 storage funktion auf dem Rechner ablegen können. Beim erneuten Aufruf würden dann nur noch die Updates und der neue Inhalt gezogen.

Sekunde mal, über 200 Aufrufe und nur eine Antwort... schade...

Nur das laden was gerade sichtbar ist. Den Rest per Ajax auf scroll/click event nachladen.

Zum Thema JS in den Footer packen (weil du von deinem Analytics-Skript geschrieben hast):

Es gibt für das <script> Tag das Attribut "async", siehe https://developer.mozilla.org/de/docs/Web/HTML/Element/script#attr-async.

Bei mir hat nahezu jede Seite eine eigene CSS- und JS-Datei. Das hat zwar den Nachteil, dass mehr geladen werden muss (über die ganze Seite betrachtet), für mich aber den Vorteil, dass ich mir keine großen Gedanken bzgl. der Struktur meiner JS-Dateien machen muss, d.h. irgendeine Form von clientseitigem Routing, etc.

deineMudda schrieb:

hab persönlich jetzt keine Erfahrungen vorzuweisen, aber ich denke, wenn sich die zu ladenden Dateien nicht oft ändern müsste man sie doch mit der HTML5 storage funktion auf dem Rechner ablegen können. Beim erneuten Aufruf würden dann nur noch die Updates und der neue Inhalt gezogen.

Zum Vergrößern anklicken....

Der Browser hat seit Ewigkeiten eine bessere Funktion, die sich Cache nennt.. basiert auf der HTTP-Spezifikation, ist viel robuster als eine eigene Lösung und funktioniert einfacher.

Zum Thema:

Google hat eine ganz nette Übersicht für Optimierungsmaßnahmen. Du solltest auf jeden Fall auf Dinge wie den Closure Compiler (o.ä.) für Javascript und css.min für CSS benutzen, um deine Dateien zu kombinieren und zu verkleinern. Speziell das Reduzieren auf möglichst wenige Dateien ist fast wichtiger als das eigentliche komprimieren. Dann solltest du richtig cachen (siehe dieses Bild, aus den oben verlinkten Docs), da ist speziell der Punkt "revalidate each time?" von großem Interesse, denn cachen ist nicht gleich cachen. Aber ich glaube, diese Punkte hast du ohnehin schon beachtet (ein Blick in die Doku oben lohnt trotzdem).

Zu deinem konkreten Problem: hängt imho vom Einzelfall ab. Wenn du z.B. nur auf einer Unterseite die JS-Bibliothek XY benötigst, dann würde ich diese definitiv nicht auf der Hauptseite mitladen. Da musst du abwägen, was wie oft gebraucht wird, was wiederverwendet werden kann und so weiter. Bei CSS lohnt es sich hingegen schon, denn das sollte sich ja nicht sooo stark unterscheiden von Seite zu Seite.

Wenn du schnelle Seitenaufrufe haben willst, würde ich auf jeden Fall auf HTTP/2 setzen. Das Protokoll ist deutlich effizienter als HTTP/1.1, der Overhead pro Anfrage ist sehr viel keiner als im alten Protokoll. 100 kleine Dateien sind praktisch genau so schnell übertragen wie 1 große Datei mit HTTP/1.1, welche alle 100 enthält.
Damit ist das zusammenfügen von Abhängigkeiten überflüssig (kann sogar ein Nachteil sein) und man sollte mehr darauf achten den HTTP Cache optimal zu nutzen. Also Assets logisch aufteilen und möglichst selten neu laden.
Wenn man HTTP Caching verstehen will kann ich einen Artikel von HTTP-Standard "Chef" persönlich empfehlen.

Und wie schon erwähnt bei js "async" verwenden, wenn möglich. Der Code muss damit natürlich umgehen können, zu jedem beliebigen Zeitpunkt ausgeführt werden zu können.
Eine Kombination aus document.readyState und DOMContentLoaded löst das Problem in den meisten Fällen

Ansonsten:
Das <picture> Element und Co. für optimale Bilder pro Gerät.
rel="prefetch" etc. wird in den Browser aktuell ausgebaut, wenn man Netzwerkanfragen manuell optimieren will.
Und wenn man richtig weit gehen will: Service Worker mit der neuen Cache API. Damit kann man Webanwendungen praktisch "installieren" und danach im Hintergrund syncen / aktualisieren. Da ist aber vieles noch unfertig bzw. komplett unbekannt.

Hmm ja das mit dem async hab ich mir auch schon überlegt, allerdings wenn man bibliotheken wie jquery verwendet bekommt man ein problem oder nicht?

Bei bildern verwende ich zur zeit noch http://www.amazon.de/TYPO3-Extbase-...3-9443634?ie=UTF8&refRID=1VCEXQ4A3F9H4KSWS8JN

Die erfahrung zeigt das das script bzw das cookie schnell genug gesetzt wird und dadurch keine vermeindlich falschen bilder geladen werden...
Das reduziert ein klein wenig den html code und ich bin browser unabhängig...

Nachteil , cookies müssen erlaubt sein...

Weiß jetzt aber auch nicht ob das picture tag trotzdem generell besser bzw performanter wäre... und wie großder performance unterschied ist...

Hmm ...

Http2 schön und gut nur habe ich darauf ja keinen Einfluss, sondern der hoster...:-)

Mit jQuery hat man gleich die ready-Funktion. Da hängt der Code ja eh meistens dran.

Und wenn der Hoster kein HTTP/2 unterstützen will, sollte man ihn so lange nerven, bis er es tut Zumal es den Ressourcenverbrauch auf dem Server auch verringern könnte. Man benötigt halt SSL, aber ein guter Hoster sollte auch das bieten.

Wie meinst du das mit jQuery?

Es geht ja eher ums downloaden der Dateien und weniger wann der Code ausgeführt wird.
Aber du bringst mich auf eine Idee - muss ich mal testen.

Du optimierst immer die Ladezeit der aktuellen Seite. Stell dir einfach vor, du wärst gerade mobil mit gedrosseltem UMTS auf deiner Seite, da willst du nichts laden, was du noch nicht benötigst... Du kannst natürlich sobald die Seite geladen ist, andere Resourcen vorladen (prefetching).

Einfache Aussagen, die du befolgen kannst:

1. Expires Header!
2. nur laden, was du auch gerade benötigst
3. Externe Dateien kombinieren um die Anzahl an Requests zu Senken (nicht mehr nötig für HTTP/2)
4. externe Resourcen auf mehrere Subdomains sharedn (Browser öffnen nur 2-5 parallele Verbindungen zu einer Domain)
   • mit HTTP/1.1 konnte man so das Limit der max. parallelen Verbindungen umgehen
   • dies ist mit HTTP/2 nicht mehr nötig (und mit SSL auch kontraproduktiv)
   • man kann aber beides kombinieren, wenn die Subdomains im gleichen SSL-Zertifikat enthalten sind, öffnet HTTP/2 nicht mehrere Verbindungen zum Server sondern ignoriert die Subdomain einfach
5. sonst kann man die Liste natürlich ewig weiterführen, weil es noch viele mögliche Optimierungen gibt. In der Regel übertreiben die meisten es auf dem Gebiet aber total, wenn sie damit mal anfangen. Wenn du keine groben Schnitzer machst, reicht es schon die Anzahl der externen Libraries zu senken. Du kannst ja mal deine Seite posten, wenn du magst

Was ich mache und i.R. vollkommen ausreichend ist:

• lange Cachezeit mit Cache-Control public (damit auch mit SSL gecacht wird)
• Einsatz externer Libraries auf das Minimum beschränken
• Assets kombinieren (wenn ich keine HTTP/2 Webanwendung baue)
• Assets schon vorher komprimieren (js/css minify, Bilderkompression)
• Gzip
• auf einer Seite nur einbinden, was ich brauche
• eventuell schaue ich mir nochmal Google PageSpeed Ergebnisse an, aber die vorgeschlagenen Optimierungen sind dann meist sehr aufwendig mit wenig Gewinn

Alles leicht getan, und deckt soweit alles an praxisnahen Optimierungen ab.