öffentlich
Redaktion Druckversion

Schlanke, schnelle Websites: So beschleunigen Sie den Aufbau von Webseiten

Mit einem langsamen Webseiten-Aufbau verärgern Sie Ihre Besucher

3.666665
(3)
Beitrag bewerten
Stand: 31. August 2007

Andere 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.

Bild vergrößern

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.

CSS-Regeln und Skripte

In der Praxis des Internets hat sich herausgestellt, dass sich die Performance einer Webseite erhöht, wenn man Style-Sheet-Regeln bereits im Kopfbereich einer Webseite lädt. Der Browser kann dann die Seite in der Regel schneller darstellen. Dies ist auch vollkommen W3C-konform.

Das Interessante ist aber, dass (externe) Skripte in vielen Fällen im Gegensatz dazu erst am Ende einer Webseite geladen werden sollten, wenn man die Performance einer Webseite erhöhen möchte. Und dies ist nicht W3C-konform. Es geht nicht in jeder Situation (insbesondere dann nicht, wenn bei dem Aufbau der Webseite Skriptfunktionalität aufgerufen wird, deren Implementierung bis zu dieser Stelle noch nicht geladen wurde). Aber wenn man gewährleisten kann, dass die Skriptfunktionalität erst nach dem vollständigen Laden des sichtbaren Bereichs einer Webseite benötigt wird, bauen viele Browser Webseiten durch diesen Trick erheblich schneller auf. Insbesondere Google nutzt solche Tricks intensiv.

Externe JavaScript- und CSS-Dateien verwenden

Wenn es irgendwie möglich ist, sollte man sämtliche Stilregeln und Skripte in externe Dateien auslagern. Dies widerspricht zwar der Forderung, die Anzahl der HTTP-Requests so weit wie möglich zu reduzieren, bringt aber dafür erhebliche andere Vorteile. Man erhält zum einen eine strenge Trennung zwischen Struktur, Funktionalität und Layout. Dies erhöht die Wartbarkeit und verbessert die Qualität einer Webseite.

In Bezug auf die Geschwindigkeit müssen aber vor allen mehrfach verwendete Stilregel und Skripte nur einmal geladen werden, wenn Sie auf mehreren HTML-Seiten verwendet werden (die externe Dateien können gecached werden).

Große Komponenten wiederverwenden

Besonders effektiv ist es natürlich, wenn Sie über Skripte und Style Sheets hinaus große Komponenten mehrfach verwenden können (sofern diese gecached werden). Sollten Sie beispielsweise das gleiche Bild für eine Schaltfläche mehrfach verwenden, ist das bedeutend performanter, als mehrere Bilder zu laden. So banal es klingt - man kann in einigen Situationen Komponenten auf unterschiedliche Weise benutzen und muss sie deshalb nur einmal laden. Wenn Sie ein Bild beispielsweise in verschiedenen Größen benötigen, laden Sie nur die größere Variante und skalieren das Bild für die kleinere Version. Aber Sie müssten in diesem Fall genau abwägen, ob beide Varianten in der Webseite tatsächlich angezeigt werden. Bei dieser Regel müssen Sie in jeder einzelnen Situation individuell entscheiden, ob so eine mehrfache Verwendung möglich und sinnvoll ist.

Reduzierung von DNS-Lookups

Das Domain Name System (DNS) dient dazu, symbolische Namen in physikalische IP-Nummern aufzulösen. Allerdings benötigt jeder dieser DNS-Lookups eine gewisse Zeit. Das ist bei der Eingabe einer Adresse im Browser absolut zu vernachlässigen. Aber bei einer Adressierung verschiedener Dateien in Referenzen in einer Webseite können sich mehrfache DNS-Lookups jedoch schon negativ auf die Performance auswirken. Da solche Namensauflösungen vom Browser jedoch eine gewisse Zeit gecached können, kann die Verwendung von wenigen Hostnamen für die verschiedenen Dateien einer Webseite durchaus eine Steigerung der Geschwindigkeit bewirken.

Minimieren des Codes von JavaScript und CSS und des Quellcodes der Website

Der zu interpretierende Quellcode von JavaScript- und CSS-Dateien muss vollständig zum Browser übertragen werden. Wenn solcher Code jedoch möglichst kompakt gehalten wird (kurze Bezeichner für Variablen und Funktionen, keine Kommentare, keine überflüssigen Leerzeichen und Zeilenumbrüche etc.) wird schlicht und einfach die Anzahl der zu übertragenden Zeichen reduziert. Das muss man der Regel nicht von Hand machen - es gibt einige freie Tools, die das bewerkstelligen.

In der Vergangenheit ist man sogar noch weiter gegangen: Der Code der HTML-Seite wurde so weit wie möglich komprimiert. Es beginnt damit, dass man für HTML-Befehle beispielsweise immer die kürzere Variante gewählt hat, wenn es mehrere Möglichkeiten gab. So gibt es beispielsweise die Befehle <strong> und <b>, die in der Praxis die gleiche optische Wirkung haben. Es ist offensichtlich, dass bei der Verwendung von <b> weniger Zeichen übertragen werden müssen.

Des Weiteren kann man im Rahmen einer Webseite das Prinzip der Fehlertoleranz ausnutzen und in vielen Fällen auf Abschluss-Tags verzichten. Oder man lässt auch andere Strukturen einer Webseite einfach weg, wenn es keine negativen Auswirkungen auf die Darstellung der Webseite hat.

Das widerspricht natürlich den Regeln des W3C für HTML-Dokumente und erst recht XHTML-Dokumente. Diese Regeln hat in der Praxis über die ganzen Jahre des World Wide Web sowieso kaum jemand vollständig eingehalten. Aber die optische Darstellung einer Webseite ist nur eine Seite der Medaille. Das semantische Web oder die Programmierung im Rahmen einer Webseite setzen sauber strukturierte Webseiten voraus. Wem dies nicht von Bedeutung ist, der kann den HTML-Code einer Webseite meist erheblich verkleinern.

Das wird in der Praxis tatsächlich immer noch angewendet (als Beispiel seien nur verschiedene Seiten von Google genannt), aber man muss sich wirklich fragen, ob die Anzahl der Byte, die man durch solche Textmanipulationen reduzieren kann, im Vergleich zu der Menge der Bytes, die für Grafik, Animation etc. verbraucht werden, wirklich noch ins Gewicht fallen.

Keine Dubletten in Skripten

Sofern Sie mehrere JavaScript-Dateien in einer Webseite einbinden, sind mehrfach vorkommende Funktionalitäten natürlich redundant. Und solche Redundanzen kommen nach offiziellen Untersuchungen großer Webseiten häufiger vor, als man auf den ersten Blick vermuten mag. Ebenso kommt es häufiger vor, dass externe Dateien sogar mehrfach in einer Webseite eingebunden werden. Und das führt in einigen Browsern dazu, dass mehrere HTTP Request gestartet werden (einige Browser erkennen nicht, dass eine Datei schon einmal eingebunden wurde). Eine Bereinigung erhöht sowohl die Qualität und Wartungsfreundlichkeit einer Seite als auch die Performance.

Konfiguration der ETags

Entity Tags (ETags) bezeichnet einen Mechanismus zur Bestimmung, ob eine Datei in dem Cache des Browsers mit einer Datei auf dem Server übereinstimmt (das können sowohl der Server als auch der Browser überprüfen). ETags sind weit flexibler als nur die Information über das Datum der letzten Modifikation. Ein ETag ist ein String mit eindeutigen Charakteristika der Version einer Komponente.

Ein ETag-String

Die Technik der ETags wird allerdings nicht von allen Webservern beziehungsweise allen Browsern einheitlich unterstützt.

Ladezeiten-Hemmer analysieren mit YSlow

Die kostenlose Firefox-Erweiterung "YSlow" von Yahoo zeigt Web-Entwicklern, warum eine konkrete Web-Seite langsam lädt und wo sie ansetzen können, um die Ladezeiten auf Trab zu bringen. Lesen Sie dazu den Beitrag auf akademie.de: YSlow: Ladezeit-Hemmungen analysieren und verbessern.

Beitrag bewerten

Ihre Wertung:

 

Ergänzend möchte ich noch ein paar Tipps zu Bildern geben:
- 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 optimieren. pngslim umfasst gleich mehrere derartige Programme für bestmögliche Kompression. Diskussion dazu hier:
- 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

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.

Downloads zu diesem Beitrag

Newsletter abonnieren