1


 Einführung
 -Startseite
 -Zum Buch
 -Konventionen
 -Impressum

 Internet
 -Das Internet
 -Geschichte des Internets
 -Internet-Dienste
 -Internet-Organisationen

 Site-Management
 -Promotion
 -Erfolgskontrolle
 -Relaunch
 -Kommunikation
 -Community-Strategien

 Design-Theorie
 -Designtheorie - Einführung
 -Farben
 -Textgestaltung
 -Site-Strukturen und Navigation
 -Zielgruppenorientiertes Design
 -Usability

 Web-Sprachen
 -Einführung
 -HTML-Tutorial
 -HTML-Tags
 -XHTML-Tags
 -JavaScript-Tutorial
 -DHTML
 -JavaScript-Know-How
 -CSS-Tutorial
 -SSI

 Design-Praxis
 -Einleitung
 -Arbeitsmittel
 -Tabellen
 -Frames
 -Textgestaltung
 -Formular-Gestaltung
 -Navigation
 -Sitemaps
 -Webrides
 -Browserkompatibiltät
 -Ladezeiten-Optimierung

 Technik I
 -Einleitung
 -Datenbanken und SQL
 -Perl/CGI-Tutorial
 -PHP-Einführung

 Technik II
 -Einleitung
 -Perl-Scripts konfigurieren
 -Formulare verschicken
 -Ein Forensystem installieren
 -Redaktionssystem
 -Session-Management mit Perl
 -Newsletter-Verwaltung

eBook-Project by AboutWebDesign.de [LOGO]

5.11 Ladezeiten-Optimierung

Druck-Version | Startseite| Kontakt | AboutWebDesign.de
Inhaltsverzeichnis "Ladezeiten-Optimierung"

5.11.1 Einführung
5.11.2 Objektive Ladezeit
5.11.2.1 Faktoren
5.11.2.2 Quellcode-Optimierung
5.11.2.3 Grafik-Optimierung
5.11.2.3.1 Überblick
5.11.2.3.2 Das geeignete Programm
5.11.2.3.3 Tipps
5.11.3 Subjektive Ladezeit
5.11.3.1 Tabellen und Bilder
5.11.3.2 Warteerlebnis beeinflussen
Partnerprogramm



5.11.1 Einführung

Langsame Sites sind out, schnelle Sites dagegen machen Spaß und sind benutzerfreundlicher: Studien haben ergeben, dass Reaktionszeiten von mehr als 8 Sekunden den Gedankenfluss des Benutzers stören. Wenn Ihre Seite also mehr als 8 Sekunden zum Aufbau benötigt, ist das nicht optimal.

In diesem Kapitel stellen wir Ihnen Strategien vor, die Ladezeiten Ihrer Site zu verbessern. Dabei muss zwischen objektiver und subjektiver Ladezeit unterschieden werden. Erstere kann tatsächlich mit einer Stoppuhr gemessen werden, letztere dagegen bezieht sich nur darauf, wie lange dem Surfer der Seitenaufbau erscheint.
Nach oben

5.11.2 Objektive Ladezeit

Eine gute objektive Ladezeit ist ein guter Grundstein für eine zufriedenstellende subjektive. Denn: schlechte Ladezeiten mit Tricks zu kaschieren, um eine gute subjektive Ladezeit trotz einer schlechten objektiven Ladezeit zu erzeugen, ist schwierig bis unmöglich.

5.11.2.1 Faktoren

Die objektive Ladezeit hängt von verschiedenen Faktoren ab. Die Anbindungsgeschwindigkeit des Surfers spielt eine entscheidende Rolle: wer nur ein 28.8-Modem verwendet, hat zwangsläufig mit langen Ladezeiten zu kämpfen. Dieser Aspekt ist jedoch Sache des Surfers - Sie haben damit nichts zu tun. Achten Sie nur darauf, Ihre Erwartungen an den Surfer nicht zu hoch zu schrauben: mit einem 56K-Modem sollte die Site unter den magischen acht Sekunden bleiben.

Ein anderer Aspekt ist die Anbindung Ihres Servers. Hier sind Sie in der Pflicht, eine vernünftige Anbindung zu gewährleisten. Weiterhin müssen Sie dafür sorgen, dass Ihr Server vernünftig ausgestattet ist: Prozessorgeschwindigkeit und Hauptspeicher dürfen für Ihre Zwecke natürlich nicht unterdimensioniert sein.

Nicht zu vergessen ist die Site selbst: sind die verwendeten Server-Programme wie CGI-Scripts performant genug? Sind die Quellcodes und Grafiken sinnvoll optimiert? Genau auf diesen letzten Aspekt wollen wir uns hier konzentrieren, denn das ist der einzige Bereich, in dem wir Ihnen sinnvolle Ratschläge geben können.

5.11.2.2 Quellcode-Optimierung

Es geht also um die Optimierung von Quellcodes und Grafiken. Was heißt das im Detail? Konsequent durchgeführt, müsste ein Optimierungsprozess zur Folge haben, dass jedes überflüssige Byte aus den HTML-Quellcodes verschwindet. Glücklicherweise gibt es Programme, die das automatisiert erledigen: so z.B. HTML Tidy.

Wenn Sie die Optimierung dagegen lieber manuell durchführen wollen, achten Sie besonders auf folgende Konstrukte:
  • Unnütze Tags. WYSIWYG-Editoren wie Frontpage erzeugen so etwas gerne, besonders die älteren Versionen: <font face="Verdana"><font face="Arial">Text</font></font>

  • Unnütze Kommentare. Für den User sind sie nicht wichtig.

  • Unnötig komplizierte Tabellenstrukturen.


Nicht automatisch erledigen lassen sich dagegen Aufgaben, die ein Mindestmaß an Intelligenz erfordern: so macht es z.B. Sinn, CSS und JavaScript in externe Dateien auszulagern. Einmal heruntergeladen, sollten sie dann im Cache des Clients verbleiben. Ein erneuter Download der gleichen Informationen wird so verhindert.

Es lässt sich nicht leugnen, dass solche Optimierungen einen gewissen Zeitaufwand erfordern. Daher stellt sich die Frage, ob sie heutzutage überhaupt noch messbare Effekte haben. Wer anführt, dass ein halbes Kilobyte mehr Quellcode zum Downloaden die Geschwindigkeit nicht wesentlich beeinflusst, hat sicher Recht. Interessant wird dieses halbe Kilobyte vor allem dann, wenn Sie eine stark frequentierte Site betreiben: bei mehreren Tausend Besuchern pro Tag schlägt sich auch ein halbes Kilobyte im entstehenden Datentransfer deutlich nieder. Soll heißen: durch Quellcode-Optimierung (übrigens natürlich auch durch Grafik-Optimierung, aber dazu gleich mehr) sparen Sie Geld.

Aber auch für den Surfer können Quellcode-Optimierungen von Interesse sein: in dem Moment, in dem ein Code-Stück mehrere Dutzend Male hintereinander gereiht wird, macht es sich auch in Sachen Ladezeit bezahlt, dieses Code-Stück vorher gründlich optimiert zu haben. Ein klassisches Beispiel ist die News-Übersichtsseite mit 50 Meldungen. Wenn im News-Template 500 Byte eingespart werden, hat das eine Verringerung der Gesamt-Dateigröße um 25 Kilobyte zur Folge - das merkt jeder Surfer, sofern er denn nicht gerade mit einem Breitband-Zugang unterwegs ist.

5.11.2.3 Grafik-Optimierung

Die Optimierung der Grafiken einer Site findet statt in zwei Schritten: zunächst muss ein passendes Format für die Dateien ausgewählt werden. Dabei ist es durchaus möglich, dass die eine Hälfte Ihrer Grafiken besser mit JPEG komprimiert werden sollte, die andere Hälfte aber eher unter Verwendung des GIF-Algorithmus. Soll heißen: Pauschalisierungen funktionieren hier nicht, stattdessen ist eine Einzelanalyse gefragt.

Der nächste Schritt ist die Ausreizung des gewählten Formats: wie stark soll die Komprimierung sein, welche Qualitätsverluste handelt man sich dadurch ein? Auch hier wieder ist eine Einzel-Analyse unabdingbar - manche Bilder verzeihen hohe Kompressionsraten eher als andere.

5.11.2.3.1 Überblick

Um eine fundierte Entscheidung treffen zu können, welches Bildformat optimal geeignet ist, müssen Sie zunächst einmal die derzeit gängigen Bildformate kennenlernen. Hier steigen wir ein: mit einer detaillierten Übersicht.

Es gibt verschiedene, durchaus verbreitete Bildformate. Von Bedeutung für das Web sind aber derzeit nur drei: GIF, JPEG und PNG (in Zukunft voraussichtlich stark zunehmende Verbreitung). Grund: zumindest GIF und JPEG werden wohl von jedem modernen Browser unterstützt. Beide Formate beherrschen die Komprimierung von Bildinformationen und damit die Verkleinerung der Bilddateien recht gut und sind daher für das WWW prädestiniert. PNG dagegen hat noch so seine Schwierigkeiten, wenn es um Browserkompatibilität geht. Dafür komprimiert es besser und flexibler.

GIF ist das Format der Wahl, wenn es darum geht, Bilder mit großen, einfarbigen Flächen zu komprimieren, so z.B. Logos mit einem geringen Grafikanteil. Das Dateiformat unterstützt maximal 256 Farben. Kleine Spezialität: es ist möglich, eine Farbe transparent zu machen, so dass hinterher im Browser der Hintergrund sichtbar wird. Achten Sie bei der Optimierung von GIfs darauf, die Zahl der verwendeten Farben so weit wie möglich zu reduzieren. Sehr gerne genutzt wird auch die Möglichkeit, GIF-Dateien zu animieren. Dass das den Speicherplatzbedarf jedoch in die Höhe schnellen lässt, ist logisch.

JPEG dagegen verwendet eine andere Art der Kompression. Eine technische Erläuterung der verwendeten Verfahren würde jedoch den Rahmen dieses Kapitels sprengen. Der JPEG-Algorithmus komprimiert - im Gegensatz zu GIF - Konturen nicht verlustfrei. Das heißt, dass ein stark komprimiertes JPEG-Bild oft Artefakte oder Farbschlieren enthält. Es ist also nicht empfehlenswert, es mit der Kompression (der Grad ist in jeder guten Bildbearbeitung einstellbar) zu übertreiben. Dafür unterstützt JPEG über 16 Millionen einzelne Farben und ist damit gut geeignet für Fotos oder Grafiken mit sehr vielen Farben. Transparenzen werden nicht unterstützt.

PNG vereint die Vorteile beider Grafikformate: es ist sowohl für Fotos als auch für Grafiken und Schriften geeignet, Transparenzen sind (theoretisch, aktuelle Browser machen da noch Probleme) ebenfalls möglich. Komprimiert wird grundsätzlich verlustfrei.

In Zukunft wird besonders ein Format in Konkurrenz zu PNG stehen: JPEG2000. Im Moment wird dieses Format de facto noch nicht von den Browsern unterstützt, was sich aber wohl in den nächsten Monaten bis Jahren ändern sollte.

Ganz unabhängig von den "großen drei" Grafikformaten gewinnt ein anderes, bisher noch ziemlich unbekanntes Format an Bedeutung: SVG. Dieses Format hat mehrere Vorteile: zum einen kodiert es seine Bildinformationen in XML, also in einfachen Textdateien - SVG ist ein offener Standard. Zum anderen ist SVG ein vektorbasiertes Dateiformat. Das bedeutet, dass die Daten nicht Pixel für Pixel, sondern in geometrischen Formen gespeichert werden. In der Regel führt das zu einer Verminderung des Speicherplatzbedarfs. Zusätzlicher Bonus: SVG-Dateien lassen sich beliebig skalieren. Die Unterstützung für das neue Bildformat ist im Moment noch mager, was sich aber voraussichtlich bald ändern wird - schließlich kommt SVG vom W3C. Sogar eine Rolle als möglicher Flash-Konkurrent wird dem Newcomer zugetraut, es lohnt sich also auf jeden Fall, sich schon jetzt mit dem Format zu beschäftigen.

5.11.2.3.2 Das geeignete Programm

Ein geschickter Grafiker wird immer ein geeignetes Programm zur Optimierung seiner Bilder verwenden. Wer sich hier in seinen Favoriten gründlich einarbeitet, spart dann Zeit, wenn es darauf ankommt. Recht bekannt ist beispielsweise das Programm "Ulead SmartSaver", aber auch "Adbobe ImageReady" ist ein anerkanntes Produkt. Prinzipiell reicht eine normale Bildbearbeitung, um die nötigen Optimierungen vorzunehmen.

5.11.2.3.3 Tipps

Sie müssen versuchen, einen angemessenen Kompromiss zwischen Komprimierung und Bildqualität zu finden. Doch wie genau kommt man zu solch einem Kompromiss? Mit viel Erfahrung und etwas Spürsinn. Achten Sie jedoch prinzipiell darauf, die Site als Ganzes zu betrachten. Soll heißen: wenn einige Teile weniger stark komprimiert sind, vielleicht fällt dann eine zusätzliche Komprimierung anderer Teile nicht auf.

Achten Sie auch darauf, dass Ihre Bilddateien nicht "hässlich" werden. Gerade unter Verwendung des JPEG-Formats läuft man schnell Gefahr, seine Bilder unschön ausfransen zu lassen. Wem so etwas passiert, zeigt keine Professionalität.

Experimentieren Sie! So gibt es z.B. eine Variante des JPEG-Formats, "progressive JPEG" genannt. Oft lassen sich damit wesentlich bessere Ergebnisse erzielen, aber eben nicht immer. Alles einmal auszuprobieren kann jedenfalls nie schaden.

Wenn Sie fein strukturierte Grafiken verwenden, passen Sie auf, die Strukturen nicht zu zerstören. Wenn Sie mit Hilfe von Tabellen oder Frames bestimmte Grafiken erst auseinander schneiden und dann wieder pixelgenau zusammensetzen, versuchen Sie, die Komprimierung nah beieinander liegender Teile möglichst ähnlich zu halten, sonst passen die einzelnen Teilstücke hinterher nicht mehr richtig zusammen.
Nach oben

5.11.3 Subjektive Ladezeit

Es heißt, die subjektive Ladezeit wäre wichtiger als die objektive. Falsch ist das sicher nicht: Wenn der Benutzer schon lange warten muss, dann soll er es wenigstens nicht merken. Die subjektive Ladezeit lässt sich aber auch durch andere Faktoren beeinflussen: so z.B. durch eine intelligente Gestaltung der Quellcodes.

5.11.3.1 Tabellen und Bilder

Tabellen und Bilder sind im Zusammenhang mit Ladezeiten immer ein prekäres Thema. So wartet der Browser beispielsweise oft mit dem Aufbau des Layouts, bis alle Tabellen und Bilder vollständig geladen sind - es sei denn, der Webdesigner erleichtert dem Browser die Arbeit.

Zunächst einmal sind alle Bilder mit Größenangaben zu versehen, dann kann der Browser mit dem Rendern beginnen, ohne die Bilder vorher geladen zu haben. Auch für Tabellen empfiehlt sich die Angabe einer Breite. Und wer wirklich geschickt ist, der baut eine Vordefinition der Spalten direkt nach dem table-Tag ein:

        <table>
        <colgroup>
        <col width="300">
        <col width="200">
        </colgroup>
        ...

     


Eine andere Strategie ist es, eine große Tabelle in viele kleine aufzuteilen. Mit etwas Glück baut der Browser die Tabellen dann der Reihe nach auf - solange der User das Gefühl hat, dass sich etwas bewegt, langweilt er sich längst nicht so schnell. Optimal erscheint uns die Kombination aller drei Maßnahmen.

5.11.3.2 Warteerlebnis beeinflussen

Angedeutet wurde diese Strategie schon im letzten Absatz: solange die Bildschirminhalte Bewegung zeigen, akzeptiert der Surfer längere Wartezeiten: "Es tut sich ja schon was". Als Webmaster kann man diesen Effekt ausnutzen, um die subjektive Ladezeit zu verbessern.

Wer die Vorschläge aus dem letzten Abschnitt verwendet, hat hier schon viel gewonnen. Wenn diese Anregungen aber nicht anwendbar sein sollten, müssen Sie wohl oder übel auf andere Strategien zurückgreifen. Bei großen Downloads ist z.B. ein sogenannter "Loading Screen" immer eine gute Idee, der anzeigt, wie viel schon geladen wurde und wie viel noch geladen werden muss. Wer in den Loading Screen zusätzlich noch einige Elemente einbaut, die den Surfer beim Warten unterhalten könnten, kann mit zufriedeneren Usern rechnen.

Wann immer Sie aber an diesem Punkt angelangt sind, müssen Sie überprüfen, ob die von Ihnen gebotenen Inhalte wirklich längere Wartezeiten rechtfertigen. Surfer hassen das Warten - ein netter Loading Screen mildert das Übel vielleicht, beseitigt es aber nicht.
Nach oben
Partnerseite: Informationen zu HTML bei HTMLWorld.de.