Um die Nutzerklientel von WebLogs, Onlineshops und vielen weiteren Internetdienstleistern besser an die jeweilige Marke zu binden, entwickelten sich viele Webauftritte zu wahren Erlebnisportalen. Die Interaktivität hat jedoch ihren Preis. Denn übermäßig lange Ladezeiten wiegt die beste Website nicht auf. Ein Schritt in die richtige Richtung: Weshalb Sie verbreitet eingesetzte Open Source Frameworks, wie jQuery oder Mootols, über Googles ‚Hosted Library‘ beziehen sollten.
Die Ladezeiten solcher hochgradig interaktiven Sites schießen, durch den vermehrten Gebrauch von JavaScript-Bibliotheken und hochauflösenden Grafiken, durch die Decke. Aktuelle Caching-Methoden greifen zumeist auch erst nach dem ersten Seitenaufruf. Bis dahin kann es aber bereits zu spät — und der Besucher abgesprungen — sein.
Die Ladezeit ist die erste Hürde die der Seitenbesucher zu nehmen hat. Hierzu einige interessante Zahlen
Einer Infografik von StrageLoopsNetworks.com zum Thema ‚Web Performance‘ zufolge, brechen 57% der potentiellen Seitenbesucher einen Ladevorgang nach 3 Sekunden ab.
Schlimmer noch: 80% der Abgesprungenen werden diese Webseite negativ in Erinnerung behalten und nicht aus eigenem Antrieb zurückkehren. Weitere 40% der Abgesprungenen werden die Website negativ in ihrem sozialen Umfeld erwähnen. Hier bewegen wir uns dann, off- wie online im viralen Marketing.
Negatives virales Marketing oder: „Ein enttäuschter Kunde macht alles immer noch schlimmer“
Im viralen Marketing greift dann ein u.U. weiterer kritischer Effekt: Strangeloop führt hier die verzerrte Wahrnehmung von Zeit seitens des Wartenden auf. So empfindet der Besucher die Wartezeit zum Ladezeitpunkt bereits um 15% länger als sie eigentlich ist.
Kommuniziert der Besucher seine Erfahrungen zur Ladezeit einer Webseite zu einem späteren Zeitpunkt, beschreibt er die Ladezeit um 35% länger als sie tatsächlich war.
In diesem Zusammenhang sollte man nun aber nicht dazu verleiten lassen, lediglich das Symptom zu bekämpfen. Den enttäuschten Seitenbesucher auf diesen Artikel zu leiten, um ihm seine Fehlinterpretation klar zu machen, kann nicht das Ziel sein. Was also kann am eigentlichen Problem, einer übermäßig langen Ladezeit beim erstmaligen Seitenaufruf, gearbeitet werden? Einen ersten, recht einfach umsetzbaren Ansatz, finde ich in der Auslagerung von häufig verwendeten Open Source JS-Bibliotheken.
Googles ‚Hosted Library‘: Ein zentraler Knotenpunkt für JS-Frameworks
Um es gleich vorweg zu nehmen: jQuery kann im Kontext dieses Artikels für viele weitere Bibliotheken stehen. Die gleichen Überlegungen können beispielsweise auch auf Mootools, jQuery UI oder Prototype angewandt werden. Neben den bereits genannten, sind noch einige weitere JS-Frameworks über Googles Hosted Library zu beziehen.
Die Quelle von Bibliotheken & Frameworks zentralisieren um Redundanzen im Browsercache zu vermeiden
Was denken Sie wie viele jQuery-Frameworks der gleichen Version gerade in Ihrem Browsercache versauern? Obwohl in ihrem Browser-Cache vermutlich weit mehr als 2 JS-Bibliotheken des gleichen Typs lagern, wird es im Laufe des Tages sicher dazu kommen, dass Sie genau diese JavaScript-Bibliothek auch noch ein drittes mal herunterladen.
Diese Redundanzen treten auf, da viele Websites eine eigene Instanz dieser jQuery-Bibliothek auf dem Webspace vorhalten.
Funktional besteht höchstwahrscheinlich kein Unterschied zur Quellversion. Soweit ich das Feld momentan überblicken kann, identifiziert jeder gängige Webbrowser die Ressourcen einer Webseite gleich: Über den Uniform Resource Locator, kurz URL.
Bei jedem Seitenaufruf mit neuem Quellverweis — also ein abweichender URL zu den bereits geladenen Instanzen — wird das komplette Framework erneut heruntergeladen, anstatt die bereits im Cache vorhandene Instanz zu verwenden. Lagern Sie Ihre jQuery-Bibliothek jedoch zu Google aus, besteht durchaus die Wahrscheinlichkeit, dass der Besucher die benötigte jQuery-Variante bereits im Browsercache zwischengespeichert hat. Bspw. durch den vorherigen Besuch der Website eines Dritten, welche ebenfalls die jQuery-Bibliothek von Google bezieht. Somit müsste jQuery auch beim erstmaligen Seitenaufruf nicht geladen werden. Das sind ca. 18kB, welche nicht durch die Leitung geschubst werden müssen. Weshalb nur 18kB?
Google liefert über den Hosting-Service eine stark geschrumpfte und per gzip komprimierte Variante aus.
Ohne gzip ist die gleiche Version 56kB groß. Bei älteren Browsern kann u.U. schon einmal diese Variante angefordert werden. Um Ihnen nebenbei die Relevanz einer konsequent durchgeführten Kompression weiter zu verdeutlichen, sei auch noch der Speicherbedarf der Entwickler-Variante mit 120kB genannt.
Der angesprochene Netzwerkeffekt: Die Effektivität dieses Konzepts steigt und fällt mit der Nutzerzahl
Google hostet derzeit 24 Versionen des jQuery-Frameworks. Die Wahrscheinlichkeit eine bestimmte Variante von jQuery bereits im Browsercache vorzufinden, steigt also mit jedem Seitenbetreiber, sofern er auf die Google Hosted Library setzt.
Umso mehr Teilnehmer desto öfter werden Ihre Besucher einen schnelleren Seitenaufbau erleben.
Jetzt zählt Ihre Meinung!
Wie stehen Sie zu meiner Sichtweise? Sehen Sie Probleme bei der Umsetzung oder verfügen Sie möglicherweise bereits über Erfahrungen zu diesem Thema? Lassen Sie es mich wissen!