Irgendwie ist mir das total entgangen, deshalb "Sorry" für die Verspätung :-) Resource Package ist ein Vorschlag von Alexander Limi für ein durchaus gängiges und absolut reales Problem: Viele Seiten verlangen vom Browser, dass er eine ganze Reihe von Ressourcen wie Stylesheets, JavaScripts und Bilder herunterlädt, bevor die Seite vollständig dem Benutzer präsentiert werden kann.
Dabei entsteht jedoch das Problem, dass Browser ein Limit haben, wie viele gleichzeitige Verbindungen sie zu einem einzigen Server herstellen, einerseits um diesen nicht zu sehr zu belasten, andererseits natürlich auch, um die Verbindungen des Clients nicht zu überstrapazieren. HTTP/1.1 spricht hier von 2 Verbindungen. IE8 geht da ein bisschen weiter und bietet 6. In Anbetracht von Seiten, die mehr als 30 Ressourcen laden wollen, ist selbst das nur ein Tropfen auf den heißen Stein. Aus diesem Grund gilt auch schon seit Längerem die Devise für die Entwicklung performanter Websites, die Anzahl der nötigen Verbindungen möglichst gering zu halten.
Eine Lösung
Die Idee von Alexander Limi ist hierfür eine Lösung, die ziemlich ins extrem geht: Ressourcen sollen in einem einzigen Zip verpackt an den Benutzer ausgeliefert werden, welches über einen <link>-Tag im Header verlinkt wird. Alles andere bliebt gleich: Bilder, CSS, JavaScript et al. werden nach wie vor direkt im Markup verlinkt und stehen somit allen Browsern zu Verfügung. Browser die jetzt Resource Packages unterstützen, laden zunächst das Archiv herunter und fragen danach lediglich jene Ressourcen noch an, die nicht darin enthalten waren.
<link rel="resource-package" type="application/zip" href="/resources/package.zip" />
Das Archiv selbst hat ein denkbar einfaches Format. Es enthält lediglich die Ressourcen, sowie ein Manifest, durch das der Browser vorab die Information erhält, welche Dateien wirklich im Zip enthalten sind, ohne dieses zuvor vollständig entpacken zu müssen. Die URLs für die enthaltenen Dateien werden danach vom Browser relativ zum Pfad das Packages aufgelöst, weshalb es sich anbietet, dieses auf einer Ebene mit den gepackten Ressourcen auf dem Webserver anzubieten. Also beispielsweise:
/resources/package.zip /resources/css/core.css /resources/css/print.css /resources/css/screen.css /resources/img/logo.png ...
Wobei das package.zip folgenden Inhalt hätte:
manifest.txt css/core.css css/print.css css/screen.css img/logo.png ...
Im Allgemeinen finde ich das wirklich eine feine Sache und ich finde es noch toller, dass es abhängig vom Community-Feedback nicht einmal schlecht für eine Implementierung in Firefox 3.7 aussieht. Durch die Verwendung von bereits existierenden Formaten und der einfachen Einbindung und Struktur ist es ein angenehm einfacher und pragmatischer Vorschlag.
Allgemein einsetzbar?
Für mich persönlich sehe ich vorerst hier eine Möglichkeit, "Standard-Ressourcen" einer Seite zu bundlen. Damit meine ich Stylesheets, Scripts und Bilder, die auf dem Großteil einer Website Verwendung finden. Hier wird man sich sicherlich ansehen müssen (je nach Website), ob man nicht auch sämtliche andere Unterressourcen (Stylesheets für die Kontaktseite etc.) gleich mit ins zip packen kann, oder ob es sich aufgrund der Zugriffszahlen etc. eher anbietet, die weiterhin getrennt zu halten.
In seinem Blogpost erwähnt Alexander Limi auch immer YouTube und die dort verwendeten Video-Thumbnails als Vorteil von Ressource Packages über klassische Lösungen wie CSS Sprites. Auf jeder Videoseite werden auch immer eine Reihe von Vorschlägen für anderen Content abgebildet, deren Previews allesamt aus einem Resource Package bezogen werden könnten. Auf Suchergebnisseiten wäre das zwar deutlich komplexer (da die Packages noch dynamischer zusammengebaut werden müssten), aber sicher auch ein interessantes Problem :-)
Tool-Support
Falls Resource Packages wirklich kommen, wird es hierfür sicherlich auch recht schnell Tools geben, die es Webentwicklern einfach machen, diese schnell und dynamisch zu erzeugen, damit eben auch Suchseiten davon profitieren können. Aber auch für die Erstellung der Packages im allgemeinen und statischen Fall, wird sich vermutlich der eine oder andere finden, der für Tools wie Coda und Asset-Manager im Allgemeinen Plugins schreibt, zumal die manifest.txt ja zu Beginn des Archivs sein muss. Und Tools wie 7zip, Winzip und Freunde bieten derzeit keine einfach Möglichkeit, die Reihenfolge der Dateien in einem Zip zu manipulieren (zumindest nicht, dass ich wüsste).
Zusammenfassend kann ich nur sagen: Ich hoffe es kommt bald … und wird wirklich von allen Browser-Herstellern in absehbarer Zeit unterstützt :-)
Do you want to give me feedback about this article in private? Please send it to comments@zerokspot.com.
Alternatively, this website also supports Webmentions. If you write a post on a blog that supports this technique, I should get notified about your link 🙂