Zur Bedienbarkeit einer Website gehört auch, dass Aktionen wie das Laden einer neuen Seite oder der Zugriff auf eine Datenbank in akzeptabler Geschwindigkeit stattfindet. Wenn eine Seite viele nützliche Funktionen bietet, aber spürbar langsam antwortet, wenn man eine Aktion auslöst, wird der Besucher nur so lange zurückkehren, bis er eine schnellere oder gefälligere Alternative gefunden hat.

Gerade bei dynamischen und vermeintlich „modernen“ Websites besteht also die Gefahr der Selbsttäuschung, wenn Tests nur über die direkte Anbindung an die Daten erfolgen und geringere Bandbreiten oder anders ausgestattete Systeme beim realen Besucher an der Tagesordnung sind.

Und auch Angebote, die oft oder für längere Zeit nicht verfügbar sind, werden keinen dauerhaften Erfolg verzeichnen können. Dabei ist es egal, ob die Ursache beim Betreiber oder dessen Hostingpartner liegt. Bekommt die Suchmaschine regelmäßig statt der gewünschten Inhalte eine Fehlermeldung als Antwort, verschwinden die Seiten aus dem Index und Besucher bleiben komplett aus. Ständig „mal verfügbare, mal offenkundig entfernte“ Seiten haben also keine realistische Chance auf dauerhafte oder gar gute Platzierung in Suchergebnissen. Und Usability braucht nun mal User….

Viel häufiger ist es aber die eigentliche „Antwortzeit“ des Servers bzw. CMS der Grund für eine eher träge Performance. Auf einzelnen Seiten kann dies dann zusätzlich durch den individuellen Content einer Seite noch verschlimmert werden; z. B. durch viel zu große und unoptimierte Grafiken. Und während die Verbesserung der „allgemeinen“ Performance, die von CMS, Serverpower, eingesetzter Datenbank und vielen anderen technischen Voraussetzungen abhängig ist, nicht ganz so einfach von der Hand geht, gibt es dennoch einige Punkte, die durchaus in der Hand des Webmasters oder des „Redakteurs“ einer Seite liegen und die die Ladezeit drastisch verringen können.

• Dazu gehören z. B. umfangreiche und immer gleiche Scripte oder CSS-Stilanweisungen, die nicht ausgelagert wurden, sondern in jeder Seite separat vorkommen. Um den Quellcode möglichst übersichtlich zu gestalten, sollten diese Elemente in separate Dateien ausgelagert werden, so dass nur ein einmaliges Laden erforderlich ist.
• Nicht immer sind ausgelagerte Scripte die Patentlösung: Wer nur eine oder zwei Funktionen (z. B. zur modernen Anzeige von Bildern oder der Erzeugung von „Diashows“ o. Ä.) aus einer umfangreichen JavaScript-Bibliothek einsetzt, zwingt den Besucher ggf. vollkommen unnötig zum Herunterladen umfangreicher Funktionssammlungen oder gar kompletter „Frameworks“ beim ersten Besuch der Startseite. Optimierung kann hier also in der Wahl einer schlankeren Funktionssammlung bestehen… oder der Zusammenstellung individueller Bibliotheken, die nur die wirklich verwendeten Funktionen enthalten, so dass nutzende Seiten nur das nachladen müssen, was auch wirklich gebraucht wird.
• Das größte Potential bergen aber in den meisten Fällen die eingesetzten Bilder. Sind diese wirklich alle in einem für das Web optimierten Format und einer zur Darstellungsgroße passenden Auflösung vorhanden? Allzu oft werden Bilder zwar als „Vorschaubild“ auf einer Seite dargestellt, indem dem anzeigenden <img>-Tag entsprechende Höhen- und Breitenangaben mitgegeben werden; das eigentliche Bild ist aber nach wie vor mehrere MB groß und muss vom Browser skaliert werden, um künstlich in Briefmarkengröße dargestellt zu werden.
• Von anderen (langsameren) Servern nachgeladene Informationen wie Feeds oder Bilder, die ggf. noch vor der Verwendung durch Scripte angepasst werden müssen, bis diese wie gewünscht auf der eigenen Seite (gern z. B. der Startseite) dargestellt werden können, sind bestens geeignet, eine eigentlich schnelle Site in eine Schildkröte zu verwandeln. Seien Sie also wachsam bei Einsatz sämtlicher externer Quellen in Form von verlinkten Inhalten, Mashups und implementierten AJAX-Widgets… Wenn das Ding heute gut funktioniert hat, muss es morgen nicht auch noch so sein.

Regelmäßige Prüfungen bei Verwendung externer Inhalte sind also dringend anzuraten. Und auch eine Messung der „gefühlten Performance“ sollte unbedingt nicht nur auf dem eigenen Rechner stattfinden, sondern auch auf möglichst kleiner dimensionierten Systemen oder auch mal einem mobilen Client. Mit Werkzeugen wie z. B. „Sloppy“ (einfach mal bei Google eingeben) gelingt zudem am eigenen Rechner die Simulation unterschiedlicher Verbindungsgeschwindigkeiten.  Auf jeden Fall sollten Sie z. B. mit der „Netzwerk Timeline“ aus dem Developer-Menü des Browsers „Safari“ eine grobe Prüfung Ihrer „wichtigsten“ Seiten wie z. B. der Startsteite vornehmen und mit Hilfe der zeitlichen Darstellung die Elemente der Seite identifizieren, die die Ladezeit maßgeblich beeinflussen… möglicherweise finden Sie hier ein paar zu große Scripte, schlecht optimierte Grafiken oder gar unnötige Verweise auf externe Dateien, die auf der eigentlichen Seite gar nicht eingesetzt werden.