DruckversionAndere Möglichkeiten
Verwenden naher Server oder eines verteilten Netzwerkes aus Servern
Die geografische Entfernung zwischen Client und Server spielt rein physikalisch eine große Rolle bei der Performance einer Webseite. Es hat offensichtlich Performancevorteile, wenn die Daten zum Besucher nicht all zu weite Strecken im Internet zurücklegen müssen. Wenn Sie überwiegend Besucher aus Deutschland erwarten, dürfte beispielsweise ein Webserver in Deutschland oder dem nahen europäischen Ausland bzgl. der Performance besser sein als ein Webserver in den USA.
Wenn Sie allerdings internationale Besucher erwarten, müssten Sie im Grunde verschiedene Lokalitäten mit Daten vorhalten. Dennoch dürfte es nur für größere Angebote von Interesse sein, Inhalte über verschiedene, geografisch verteilte Server anzubieten. Dann müssen Sie aber auf einer Einstiegsseite die Lokalität des Besuchers über die Auswertung bestimmen und ihn dann auf ein Angebot auf einem möglichst nahen Server weiterleiten. Das kann man beispielsweise auf Grund der IP-Nummer des Absenders oder (meist einfacher) entsprechender HTTP-Header machen.
Mit einem ausgefeilten System kann man darüber hinaus auch intern die Datenbereitstellung optimieren.
Setzen eines Ablaufdatums
Über einen so genannten Expires-Header kann man ein Ablaufdatum für Komponenten festlegen. Im Umkehrschluss bedeutet das auch, dass die Dateien mit so einer Angabe vor dem Erreichen des Ablaufdatums vom Browser gecached werden können. In der Regel werden Expires-Header in Verbindung mit Bildern verwendet, aber sie lassen sich auch mit anderen Komponeten wie Skripts, Style Sheets oder Flash-Animationen verwenden.
Das Ablaufdatum einer Komponente
Komprimierte Inhalte übermitteln
Fast alle modernen Browser kommen mit komprimierten Inhalten im Gzip-Format zurecht. Das können Sie leicht nachprüfen, indem Sie mit einem Sniffer die HTTP-Header analysieren. Sie finden dort im Request meist einen Eintrag Accept-Encoding: gzip, deflate.
In einem Sniffer erkennen Sie den HTTP-Header
Wenn einem Webserver diese Angabe übermittelt wird, kann ein Client mit so komprimierten Inhalten umgehen. Dann kann der Webserver über ein Header-Feld 'Content-Encoding' kennzeichnen, dass er eine Antwort komprimiert verschickt (Content-Encoding: gzip) und Daten entsprechend komprimieren.
Dieser "Artikel" sollte überarbeitet werden. Momentan ist es nur eine Aufzählung von Ursachen. Wie man dann etwas behebt, wird im Großteil der Punkte nicht aufgeführt.
Ergänzend möchte ich noch ein paar Tipps zu Bildern geben: optimieren. pngslim umfasst gleich mehrere derartige Programme für bestmögliche Kompression. Diskussion dazu hier:
- Wird keine Animation benötigt, verwendet man statt GIF besser PNG, das in fast allen Fällen besser komprimiert (Ausnahme sind da eigentlich nur ganz kleine Bilder um 100 Bytes).
- Die Kompression von PNG-Bildern lässt sich mit Programmen wie pngout
- BMP hat im Web nichts verloren.
- Für Fotos nimmt man am ehesten JPEG, für manche Computergrafiken (etwa Knöpfe, Symbole) und auch Comics bietet PNG evtl. die bessere Kompression, insbesondere bei wenigen Farben, obwohl es verlustfrei ist (solange man mit der Qualität des JPEG-Bildes nicht zu stark runtergeht).
Außerdem: Stilanweisungsdateien für verschiedene Zielmedien (etwa screen, print) werden üblicherweise alle sofort geladen und nicht erst bei Bedarf. Daher lassen sich dort auch noch HTTP-Anfragen einsparen, wenn man diese Dateien nicht mit dem (X)HTML-Attribut media="…" referenziert, sondern nur eine einzige Datei einbindet, die die entsprechenden Stilangaben in @media-Blöcken enthält. Auch lassen sich so Stilangaben, die mehrere Medien betreffen (etwa @media screen, projection, handheld) meiner Meinung nach einfacher zusammenfassen.
Heinz