Lädt eine Webseite nur schleppend, sucht man die Schuld schnell beim Seitenbetreiber oder dem Webbrowser. Doch das Zusammenspiel von Webserver, Webseite und Browser-Software ist kompliziert. Eine Reihe von Kniffen hilft, das Laden der Webseite zu beschleunigen.
Baut sich eine Webseite im Webbrowser nur schleppend auf, fällt der Verdacht schnell auf eine zu geringe Bandbreite oder zu alte Hardware. Voreilige Schlüsse dürfen Sie allerdings nicht ziehen: Zwischen dem Abruf der Webseite und der Darstellung im Browser läuft ein recht aufwendiger Prozess, in dem etliche Faktoren eine Rolle spielen.
Dazu zählen die Daten selbst, die Konfiguration des Webservers inklusive dessen Hosting, die in die Webseite eingebettete und die sich Ihrem Benutzerprofil anpassende Werbung, das tatsächliche Ausgabegerät (Monitor, Smartphone oder Tablet) und selbstverständlich auch der Webbrowser, mit dem Sie die Webseite anschauen. Vom Ausliefern der Webseite bis zur Anzeige auf dem Bildschirm sind viele Komponenten beteiligt.
Als Nutzer haben Sie keinen Einfluss auf das Hosting und die Inhalte des Seitenbetreibers. Sie entscheiden jedoch selbst, welche eingebetteten Elemente Ihr Webbrowser am Ende auch darstellt und beeinflussen so die Darstellungsgeschwindigkeit ganz maßgeblich.
Webseite: Die Daten dahinter
Eine Webseite besteht generell aus in der Hypertext Markup Language HTML formulierten, strukturierten Textdaten. Diese umfassen einen Kopf (<header>...</header>) mit den Meta-Informationen sowie zwischen den Body-Tags (<body>...</body>) den tatsächlichen Inhalt der Seite. Aus der Abfolge der einzelnen HTML-Tags ergibt sich die Anordnung des Inhalts. Hinzu kommen Anweisungen zur Formatierung und konkreten Darstellung in Form von Cascading Style Sheets (CSS) sowie dynamische Inhalte wie Javascript und Flash.
Ein HTML-Dokument liegt entweder in statischer Form bereit oder entsteht dynamisch beim Aufruf auf dem Webserver, indem dieser Code einer bestimmten Programmiersprache ausführt. Dabei kommen serverseitige Sprachen zum Einsatz, wie etwa PHP, Java, Perl oder Python, oder auch Technologien wie Javascript und Ajax, die auch den Client mit einbeziehen. Content-Management-Systeme (CMS) kombinieren häufig mehrere der genannten Techniken.
Jede Webseite spezifiziert ein bestimmtes, regionenbezogenes Encoding, das der Autor des HTML-Dokuments bestimmt oder mithilfe der CMS-Software festlegt. Das Encoding ist häufig identisch zu der geografischen Region, in der der Autor lebt und arbeitet. Mittlerweile setzt sich allerdings der Einsatz von Unicode Stück für Stück durch.
Auf der Darstellungsebene sorgt oft der Widerspruch zwischen der im HTML-Kopf spezifizierten und im Dokument dann tatsächlich verwendeten HTML-Version für Kopfzerbrechen. Die Versionsangabe variiert je nach Entwicklungsstand und Intensität der Pflege der Webseite. Eher selten präsentiert sich eine Webseite aus einem Guss – zumeist stimmt sie nur über eine bestimmte Zeit hinweg.
Viele Projekte nutzen älteren Programmcode und einen Schreibstil, der den Zeitgeist der Entstehungsepoche des Projekts (oder einer bestimmten Funktionalität) atmet. Noch eine größere Bandbreite bezüglich der Herkunft und des Stils weist aus externen Quellen bezogener Fremdcode auf. Er erleichtert zwar die Verfügbarkeit und den Einsatz in möglichst vielen Projekten, sorgt jedoch auch für eine größere Vielfalt im Entwicklerzoo.
Hosting
In die Ausgabe mischen sich zudem auch die genutzten Dienste des Webhosters oder Cloud-Anbieters ein, dessen Hardware die Webdaten am Ende tatsächlich ausliefert. Darüber hinaus gilt es, den Einfluss der Netzwerk- und Speicherkonfiguration abzuwägen. Die Schlagworte lauten hier IPv4/IPv6, DNS sowie Arbeitsspeicher. Letzterer wird bei einem virtuellen Server oder geteiltem Webspace entweder vom Hoster fest zugewiesen oder dynamisch zugeordnet.
Die Größe und Nutzbarkeit richtet sich entweder nach dem aktuellen Bedarf, der tatsächlichen Verfügbarkeit oder einem vorher gewählten Tarif. Preiswerte Webhoster kalkulieren in der Regel auf Basis der Annahme, dass nicht alle Benutzer auf dem Server gleichzeitig mit voller Last arbeiten. Sollte dann doch einmal die kumulierte Last auf dem geteilten Server in die Höhe schnellen, müssen Sie mit Verzögerungen beim Ausliefern der Daten rechnen.
Webbrowser
Der Webbrowser übernimmt nun die Aufgabe, den Inhalt in Form einzelner Datenpakete sequenziell von der angegebenen URL zu beziehen, ihn zu interpretieren und daraus mithilfe seiner Rendering-Engine eine Darstellung zu erzeugen. Diese Interpretation zeigt er Ihnen dann in seinem Ausgabefenster an.
Zu Beginn lädt der Browser das angefragte HTML-Dokument mitsamt der im HTML-Kopf referenzierten externen Dateien aus dem Netz. Darunter befinden sich in der Regel eine oder mehrere Stilvorlagen (CSS-Dateien). Abbildung 1 zeigt das Ergebnis der Auswertung mithilfe der Developer Extension von Google Chrome [1] für die Webseite Bbbike.org [2].

Abbildung 1: Detaillierte Auswertung der einbezogenen Stilvorlagen mit der Developer Extension von Google Chrome.
Über den Menüeintrag Network | Stylesheets erhalten Sie die Information, dass die Seite vier Stilvorlagen lädt. Zusätzliche Details erscheinen, wenn Sie den Mauszeiger auf den entsprechenden Ladebalken in der Zeitleiste bewegen. Das Pendant zur Developer Extension für Firefox/Iceweasel heißt Firebug [3], für Opera gibt es Dragonfly [4]. Beide Werkzeuge leisten ähnliche Dienste. Dragonfly finden Sie von Haus aus im Menü unter Extras | Weiteres | Opera DragonFly (Abbildung 2).

Abbildung 2: Analyse der Ladezeiten der unterschiedlichen Elemente einer Webseite mittels Operas DragonFly.
Um herauszubekommen, welcher Anteil der geladenen Stilvorlagen auch tatsächlich zum Einsatz kommt, führen Sie über den Eintrag Audits eine Netzwerkanalyse durch. Abbildung 3 basiert auf Chrome und zeigt im Abschnitt Web Page Performance, dass im vorliegenden Beispiel 1,8 von 2,9 KByte Daten unnütz über die Leitung gehen. Das entspricht mehr als 60 Prozent der bezogenen Stilvorlagen, was sowohl das Datenvolumen wie auch die Geduld des Anwenders strapaziert. Insbesondere bei einem mobilen Zugriff mit Abrechnung über einen Volumentarif kommt es auf eine schlanke Webseite an.

Abbildung 3: Die Chrome Developer Tools zeigen den Nutzungsgrad der von einer Webseite angeforderten Stilvorlagen.
Nach dem HTML-Kopf bezieht der Browser alle im HTML-Body referenzierten externen Dateien. Dies umfasst in der Regel Bilder, die Vorschau von Videodaten sowie oft aktive Elemente wie etwa Flash-Videos oder Javascript-Funktionen. Welche Daten der Browser tatsächlich lädt, hängt jedoch von den Einstellungen und den installierten Plugins ab.
Mitunter fordert die geladene Webseite auch Daten an, die der Browser nachträglich von der Darstellung ausklammert und somit Bandbreite verschwendet. Abhilfe schaffen hier Addons wie etwa Just Disable Stuff [5] und Adblock Plus für Firefox [6]. Ersteres sorgt dafür, dass der Browser Bilddaten und oder Javascript gar nicht erst lädt (Abbildung 4), Adblock Plus unterdrückt die Anzeige von Werbebannern oder aufdringlichen Popup-Fenstern mit großformatigen Anzeigen.

Abbildung 4: Das Firefox-Addon Just Disable Stuff erlaubt das gezielte Ein- und Ausschalten von Javascript und Bildern.
In die gesamte Berechnung der Darstellung fließt zunächst der browsereigene, unveränderliche Funktionsumfang ein. Er spiegelt die Intention der Entwickler und der Maintainer der von Ihnen ausgewählten Software wider. Danach folgen die benutzerspezifischen Einstellungen, wie etwa explizit ausgewählte Schriften und Ausgabemodi. Gibt die angesurfte Webseite spezifische Schriften und Schriftstile vor, holt sich der Browser diese vom Webserver, von der Festplatte oder direkt aus dem Cache. Gibt es die referenzierte Schriftart nicht im System, dann greift der Browser auf eine passende Standardschrift zurück.
Medienformate
Am Ende beeinflusst selbstverständlich auch das Ausgabegerät maßgeblich die Darstellung der Webseite. Der Webbrowser optimiert dazu die Anzeige für große Bildschirme oder kleine Smartphone-Displays. Er sucht dazu in den HTML- und CSS-Codes nach Tags und spezifischen Attributen für die unterschiedlichen Medienformate, wie etwa all, print oder screen (siehe Tabelle “Tags für Medienformate”) [7]. Fehlen diese, greift der Browser auf eine vordefinierte Standarddarstellung zurück.
Tags für Medienformate
| Medientyp | Beschreibung |
|---|---|
| all | alle Ausgabemedien (Standardwert) |
| für Drucker, die Inhalte sichtbar auf Papier drucken. | |
| screen | für (Computer-)Bildschirme |
| speech | für Sprachsynthesizer (für ein zukünftiges CSS-Modul reserviert) |
Simulanten
Möchten Sie simulieren, wie sich Smartphones und Tablets mit Ihrer Webseite vertragen, helfen Ihnen dabei die Developer Tools von Google Chrome. Über den Eintrag Emulation gelangen Sie zu einer Auswahl verschiedener Ausgabegeräte, für die Google Chrome die Darstellung anpasst. Abbildung 5 zeigt als Beispiel die Ausgabe der Webseite http://www.gnupg.org auf einem Amazon-E-Book-Reader des Typs Kindle Fire.

Abbildung 5: Die Chrome Developer Tools zeigen auf Wunsch eine Webseite wie auf einem mobilen Gerät oder E-Book-Reader an.
Aufwendig
Beim Vorbereiten der Darstellung muss die Rendering-Engine des Webbrowsers eine ganze Reihe von Klippen umschiffen. Dazu zählt unter anderem, dass das tatsächliche Encoding der HTML-Datei oft nicht mit der Deklaration im Dokumentenkopf übereinstimmt: Das führt zu Fehlern bei der Interpretation von Zeichen.
Auch eine fehlerhafte Reihenfolge der Tags (Hierarchie), nicht zusammenpassende Bezeichner, eine inkonsequente Schreibweise der Tags (alles klein beziehungsweise groß oder bunt gemischt), Schreibfehler bei den Bezeichnern oder zulässigen Attributen für die vorher angegebene HTML-Variante sowie eine Mehrfachdeklaration von Tags und Schlüsselworten beeinträchtigen den Seitenaufbau.
Bei komplexen Seiten verwirren fehlende schließende Tags und vergessene Anführungszeichen bei Attributwerten die Engine. Gleiches gilt für eine Vermischung interner und externer Elemente sowie weiterer Inhalte, beispielsweise durch das Einbinden in einen Frame, iFrame [8] oder über ein Plugin. Fehler in den Modulen, insbesondere bei Flash, sorgen dabei stets für “Freude”.
Viele dieser Probleme besitzen einen historischen Bezug: Sie beruhen auf älteren Funktionen, die einmal eine bestimmte Funktion ermöglichen sollten, sich jedoch nicht durchsetzen konnten und jetzt nur noch als Überbleibsel existieren. Dazu gehören neben hochkomplexen Browserweichen für die Unterstützung prähistorischer Webbrowser auch die Ablösung von Flash durch HTML5.
Effekte
Wie bereits eingangs genannt, entspricht die Darstellung nicht immer den Erwartungen des Benutzers: Beim Seitenaufbau gehen Inhalte verloren, da der Webbrowser diese nicht darstellen kann, oder es ändert sich die Anordnung: Die Webseite sieht dann einfach anders aus als erwartet. Zudem bekommt die Rendering-Engine des Webbrowsers bei Fehlern deutlich mehr zu tun.
Das Parsen und Verarbeiten des HTML-Codes ist aufwendiger und dauert somit einfach länger. Die Analysefunktionen versuchen zudem, fehlerhaften Code automatisch zu reparieren. Das passiert meist im Hintergrund, ohne dass der Benutzer davon etwas mitbekommt, und es gelingt nicht immer vollständig. Verzögerungen fallen nicht in jedem Fall sofort auf, weil aktuelle Hardware meist ausreichende Leistungsreserven bietet.
Neben der Reparatur sorgen vielerorts individuell auf den Nutzer abgestimmte Inhalte aus externen Quellen wie Twitter, Facebook oder Google für Verzögerungen beim Seitenaufbau. Diese “zielgruppen- und nutzerbezogene Auswahl und Anpassung der Daten” oder schlicht “Personalisierung der Webseite” betitelte Vorgehensweise dient ausschließlich dazu, die Aufmerksamkeit auf bestimmte Inhalte zu lenken, und sorgt häufig für mehr als 70 Prozent der übertragenen Daten.
Textlastig
Großes Potenzial zum Beschleunigen des Seitenaufbaus bietet das Abschalten von Bildern – so Sie denn diesen drastischen Schritt gehen möchten. Je nach Browser geschieht dies auf unterschiedliche Art und Weise [9]. Firefox erlaubt das Blockieren von Bildern ausgewählter URLs sowie das Unterdrücken sämtlicher Bilder. Ersteres verbirgt sich hinter der Option Grafiken von Domain-Name blockieren auf dem Reiter Medien aus den Seiteninformationen, die Sie durch das Laden der entsprechenden Webseite, einen Rechtsklick auf eine freie Stelle und den Menüpunkt Seiteninformationen anzeigen aus dem Kontextmenü heraus aufrufen.
Für die zweite Variante rufen Sie im Webbrowser die Pseudo-URL http://about:config auf und setzen den Inhalt der Variablen default.image auf den Wert 2. Der in früheren Versionen von Firefox enthaltene Menüpunkt dazu ging im Laufe der Entwicklung verloren. Setzen Sie den Wert auf 3, so lädt Firefox nur noch Bilder, die von derselben Domain stammen. Fremde Bilder – etwa solche von Ad-Servern oder Social Networks – lässt Firefox dann links liegen [10].
Für mehr Komfort und Flexibilität sorgt eine dritte Option, das bereits angesprochene Plugin Just Disable Stuff (Abbildung 4). Es klinkt sich in das Menü ein und erlaubt Ihnen ohne Umwege das Ein- und Ausschalten von Bildern und Javascript über die Einträge Extras | Just Disable Images und Just Disable JavaScript.
Pipelining aktivieren
Normalerweise arbeiten Webserver HTTP-Anforderungen eines Clients nacheinander ab und beantworten die nächste Anfrage erst, nachdem die Antwort auf die aktuelle Anfrage vollständig empfangen wurde. Je nach Netzwerklatenz und Bandbreite führt dies zu spürbaren Verzögerungen beim Seitenaufbau. Das Protokoll HTTP/1.1 gestattet Webservern nun aber, mehrere HTTP-Anforderungen gleichzeitig zu verarbeiten, ohne dass sie das Ergebnis der vorhergehenden Anfrage abwarten müssen [12].
Pipelining umfasst den parallelen Datentransfer über einen Internet-Socket. Theoretisch unterstützen die meisten Webbrowser und Server diese Technik, aufgrund technischer Probleme auf der Server-Seite ist die Funktion allerdings meist deaktiviert. Google hat sie gar seit der Version 26 des Chrome-Browsers wieder komplett abgestellt. Auch andere Browser wie etwa Opera (ab Version 15), die auf der Chromium-Basis aufbauen, bieten kein Pipelining mehr an.
In Firefox lässt sich Pipelining hingegen in http://about:config mit dem Schlüssel network.http.pipelining nach wie vor aktivieren (Abbildung 6). Optional erhöhen Sie den Wert des Schlüssels max-persistent-connection-per-server – er bestimmt die Anzahl der parallel geöffneten Verbindungen – von 6 auf 24 (Abbildung 7).

Abbildung 6: In Firefox oder Iceweasel können Sie die Ladezeiten von Webseiten durch Aktivieren von Pipelining optimieren.

Abbildung 7: Je mehr Verbindungen Firefox beim Pipelining offenhält, desto besser nutzt er die Datenverbindung aus.
Neben der besseren Ausnutzung der Bandbreite führt Pipelining auch zu einer weitgehenden Reduzierung der Anzahl von TCP-Paketen im Netz. Mit einer typischen maximalen Segmentgröße (MSS) im Bereich von 536 bis 1460 Byte verpackt das Protokoll mehrere HTTP-Anforderungen zu einem einzigen TCP-Paket. Das verringert die Netzlast und somit auch die Beanspruchung der Infrastruktur. Beachten Sie jedoch, dass nicht alle Webserver Pipelining unterstützen.
Tracking
Viele Webseiten beobachten mit Tracking-Tools wie Google Analytics oder Piwik ihre Besucherströme und analysieren das Verhalten der Benutzer. So kommen die Betreiber zu Informationen darüber, wie oft und lange Anwender die Seite besuchen, woher sie kommen oder über welche Links sie die Seite wieder verlassen. Mithilfe des Addons Ghostery [11] sehen Sie, welche Spionagemittel der Betreiber auf Sie angesetzt hat, und schalten diese gegebenenfalls aus (Abbildung 8).

Abbildung 8: Mit Ghostery blockieren Sie Tracking-Mechanismen gezielt und spezifisch für jede Webseite.
Ausblick
Der vorliegende erste Teil dieser zweiteiligen Artikelreihe lieferte Ihnen einen ersten Überblick, welche Technologien in die Darstellung einer Webseite hineinspielen. Mit einfachen Schritten und Plugins begrenzen Sie als Benutzer die Darstellung der Inhalte im Webbrowser auf die wesentlichen Elemente.
Die Fortsetzung des Artikels in der nächsten Ausgabe vertieft den Streifzug mit Strategien und Werkzeugen für Redakteure, Entwickler und Administratoren. Auf dem Plan stehen Werkzeuge zur Validierung von HTML und CSS, die Sie beim Verfassen von sauberem Code unterstützen, sowie ausgewählte Module zum Beschleunigen Ihres Webservers.
Danksagung
Die Autoren bedanken sich bei Werner Heuser, Wolfram Eifler, Wolfram Schneider und Thomas Osterried für deren Kritik und Anregungen im Vorfeld dieses Artikels.
Autoreninfo
Frank Hofmann arbeitet in Berlin im Büro 2.0, einem Open-Source Experten-Netzwerk, als Dienstleister mit Spezialisierung auf Druck und Satz. Er ist Mitgründer des Schulungsunternehmens Wizards of FOSS. Seit 2008 koordiniert er das Regionaltreffen der Linux User Groups aus der Region Berlin-Brandenburg.
Der gebürtige Kanadier Gerold Rupprecht wohnt seit 25 Jahren in Genf und hat sich auf Finanzsoftware sowie das Evaluieren und die Optimieren IT-bezogener Prozesse spezialisiert. Seit dem Jahr 2000 unterstützt er das Gnustep-Projekt, beispielsweise als Organisator auf der FOSDEM.
Infos
[1] Google Chrome Developer Tools: https://developer.chrome.com/devtools
[2] Berlin By Bike: http://mc.bbbike.org/mc/
[3] Mozilla Firebug: https://addons.mozilla.org/de/firefox/addon/firebug/
[4] Opera Dragonfly: http://www.opera.com/dragonfly/
[5] Just Disable Stuff: https://addons.mozilla.org/de/firefox/addon/just-disable-stuff
[6] Adblock Plus: https://addons.mozilla.org/de/firefox/addon/adblock-plus/
[7] CSS-Media-Queries: http://wiki.selfhtml.org/wiki/CSS/Media_Queries#.C3.9Cbersicht_der_Medientypen
[8] “Benutzung und Definition von iFrames”: http://www.w3schools.com/tags/tag_iframe.asp
[9] “Wenn Sie Bandbreite sparen möchten, schalten Sie im Firefox Grafiken ab”: http://www.tippscout.de/firefox-grafiken-abschalten_tipp_5312.html
[10] MozillaZine Knowledge Base: http://kb.mozillazine.org/Permissions.default.image
[11] Ghostery: https://addons.mozilla.org/de/firefox/addon/ghostery/
[12] Pipelining-FAQ: http://www-archive.mozilla.org/projects/netlib/http/pipelining-faq.html





