Quote

* Layout möglichst in eine Datei auslagern ("CSS-Datei" muss nur einmal geladen werden)

Das macht die Bandbreite aber in der Regel nicht geringer. Allerdiengs führt es dazu das eine Seite schneller geladen ist wenn weniger http zugriffe gemacht werden müssen.

Was du halt machen kannst ist soetwas wie CSS::Minifier zu nutzen das dann whitespaces u.s.w. entfernt das reduziert dann die bandbreite.

Quote

* http-Komprimierung
durch den Webserver. Können "alle" Browser damit umgehen?

In der Regel wird gzip Komprimiert. Ansonsten wird das grundsätzlich nicht immer aktiviert. Der Browser selber schickt immer Informationen zum Server und in diesem steht drin ob dieser gzip Komprimierung kann. Ein entsprechender Webserver wo du gzip Komprimierung aktivierst beachte diese informationen und komprimiert die daten nur dann wenn der browser diese information mitschickt. Auch das Catalyst Plugin Catalyst::Plugin::Compress::Gzip komprimiert nur wenn der Client es untertstützt.

Grundsätzlich ist soetwas empfohlen da dies wohl das meiste an bandbreiten einsparung bringen sollte.

Quote

html-komprimierung
css-komprimierung

Ob sich das lohnt? Naja grundsätzlich wenn du natürlich keine Kommentare mit schickst ist es natürlich weniger an Bandbreite. Ob es sich lohnt hängt von deiner anzahl deiner Kommentare ab.

Grundsätzlich wenn du aber schon http-komprimierung an hast sollte es wenig bringen wenn du ein paar kommentare entfernst. Du musst hierbei auch immer den nutzen faktor sehen. Wenn die Kommentare hilfreich sind zum Beispiel beim Entwickeln dann würde ich sie nicht entfernen.

Ansonsten wenn ich mal Template::Toolkit erwähnen darf. Wenn du dieses als Templating Modul nutzt es kennt auch Kommentar Deklartiven. Also soetwas "[%# Dies ist ein Kommentar %]" damit kannst du Kommentare in deinen Template Dateien hinterlegen die dir beim entwickeln helfen kann, diese kommentare werden aber beim bearbeiten nicht in der ausgangsdatei erzeugt.

Sofern du also kein Modul hast das automatisiert soetwas entfernt würde ich das nicht machen.

Quote

* AJAX (?)
Verstärker Einsatz von AJAX, damit nur Teile der Seite und nicht die ganze Seite neu geladen werden muss.
-> lohnt sich das?

Hängt von deiner verwendung ab.

Grundsätzlich kann es die Bandbreite reduzieren und auch die Server Load reduzieren, wenn du z.B. nur noch Daten in JSON form zurück schickst und arbeiten anstatt auf dem Server dann im Browser machst kann es ein positiven effekt haben.

Wenn du allerdiengs an jeder fitzel stelle anfängst Ajax Requeste abzufeuern kann deine Server-Load sowie auch die bandbreite steigen. Man kann also Grundsätzlich nicht ja oder nein sagen, sondern es hängt davon ab wie sehr du es nutzt. Grundsätzlich wäre dies aber möglich, ja.

Bei Ajax würde ich dir aber auch raten ein entsprechendes JavaScript Framework zu nehmen. Das dann vieles vereinfacht und du nicht ewig das rad von neuem entwickeln musst. Hierbei musst du dann natürlich auch bedenken das die JavaScript Bibliothek selber ebenfalls Bandbreite kostet. Allerdiengs in der Regel auch nur einmalig da die Bibliothek vrom Browser gecached werden sollte.

Bei Javascript selber und wenn du Code selber schreibst solltest du nur darauf achten das du es in einer extra Datei auslagerst. Weiterhin solltest du JavaScript verkleinern wozu es einige Tools gibt. wie der YUI Compressor Shrinksafe oder in Perl JavaScript::Minifier.

Beim Laden von JS ist es immer empfehlenswert wenn du JS dateien ganz zum schluß lädst. Wenn ein browser kein JS unterstützt verbringt dieser dann nicht erst die Zeit die JS Bibliotheken herunterzuladen wovon er sowieso nichts sieht, sondern er sieht erst die seite die sich dann später noch im verlaufe verändern kann.


Ansonsten generell zum verkleinern und um die Seite schneller zu machen gibt es einige Tools die man empfehlen kann. Zum Beispiel für Firefox das Plugin YSlow. Wenn du das mal auf deiner Seite ausführst bekommst du einige hinweise und optimierungsstellen wie du erreichen kannst das deine nutzer schneller deine Webseite sehen. Bei den angaben würde ich nur die Hinweise auf ein "CDN" ignorieren, aber das kannst du auch konfigurieren welche Regeln er nutzen soll und welche nicht.

sid hat ja schon viel gesagt. Nimmermüde, zu Erklären. ;)

* Layout
- Inhalte sollten so im HTML stehen, dass sie auch bei ausgeschaltetem CSS logisch aneinander gefügt sind. Das ist m. E. auch wichtig für benutzer assistiver Technik. OK, das hat jetzt eher was mit Usability zu tun als Bandbreite zu sparen.
- Javascripte (JS) sollten von extern eingebunden werden und ansonsten am Schluss der Webseite stehen. Dann ist wichtiger Content schon sichtbar, bevor das JS gestartet hat.


* gzip/deflate-Kompression
Zur Komprimierung der Inhalte auf dem Server möchte ich noch hinweisen, dass ältere Browser teilweise mit gzip nicht umgehen können oder wie Internet Explorer 6 und 7 zum Teil bei bestimmten Cache- und Proxy-Headern Probleme macht.
Bedenke, dass IE 6 noch eine Verbreitung von ca. 8-12% und 7 einen sehr großen Anteil haben können. Nicht alle verwenden den IE 8.

* Caching
Sinnvollerweise solltest du auch beim Cachehandling ansetzen, damit möglichst Unveränderliches im Browser-Cache gehalten werden kann.

* AJAX
AJAX ist so ein Sache. Nicht mit jedem Browser klappt das gut. Da musst du AJAX bzw. die -Bibliothek eben testen.

* Javascript-Frameworks
- Manche Javascriptbibliotheken machen den Fehler, zusätzliche Elemente nicht an der Stelle in den DOM-Baum einzubinden, wo sie aufgerufen wurden sondern am Schluss anzufügen und dann per CSS zu positionieren.
Mit assistiver Technologie geht dann aber der Fokus verloren, die Änderung der Webseite findet woanders statt, nicht dort wo es sein müsste.
- Wenn JS ausgeschaltet ist, funktioniert gar nichts, es braucht also einen Fallbackcontent. Nicht jede AJAX-Bibliothek geht mit jeden Browser.

* Grafiken
- Es lässt sich mit SVG auch was einsparen, zudem SVG skalierbar ist. Allerdings kann der IE kein SVG bzw. nur mit einem Adobe SVG-Plugin.
- Bitmapgrafiken sollten von Informationen wie EXIF oder sonstigem Dateinformationen (XMP und andere Metadaten) befreit sein. Dazu gibt es in den meisten Bildverarbeitungsprogrammen die Option "Speichern für Web" oder ähnlich.
- Bitmapgrafiken sollten optimiert sein. Bei JPGs kann in bestimmten Bildverarbeitungsprogrammen die Optimierung auch auf bestimmte Bildinhalte begrenzt werden, unwichtiges wird so stärker komprimiert; wenn möglich GIFs verwenden solange der Farbumfang nicht zu groß ist.

2010-01-09T13:21:14 Hagen

* "html-Komprimierung" (?)
d.h. alle Kommentare, unnötigen Leerzeichen und Leerzeilen entfernen
-> lohnt sich das?

da ich auch gerade daran bastele, kennt jemand was schnelleres als HTML::Strip::Whitespace? das braucht hier lokal ungefähr soviel wie der ganze restliche request, was die ausführungszeit verdoppelt, das ist natürlich auch nicht sinn der sache.
kann auch ein externes tool sein, das kann ich ja dann optional einbinden.

Danke für die Anregungen, ich werde mal probieren, was ich umsetzten kann.

Ist es auch möglich ein "Layout-Packet" (CSS, JS, Grafiken, ...) irgendwo (als auch außerhalb des Browser-Caches) abzulegen und dieses zu verwenden?

Warum das ganze?
Ich habe recht umfangreiche "Grunddaten" (d.h. Bilder, Karten, Icons; ggf. mehr als 100 MB) die sich nicht verändern. Außerdem könnten diese Daten vorher ("zu Hause") schon geladen werden bzw. per Stick transportiert werden.

Später ("Unterwegs") muss ich dann (hoffentlich) 'nur' Informationen in Textform (mobil) übertragen.

Das ganze ist vergleichbar (!) mit einer Positionsanzeige bei GMaps, die laufend aktualisiert wird. Ist das Kartenmaterial erstmal auf dem Rechner, brauche ich nur noch die aktuelle Position übertragen.