Wie eine Error 404 Seite den Server belasten kann

Auf Internetseiten werden gerne angepasste Error404-Seiten eingebaut. Das ist eigentlich ganz gut, weil der Besucher, der über einen Link zu einer nicht mehr existierenden Seite, gekommen ist, jetzt eine hübsche Seite zu sehen bekommt. Die in so einem Fall vom Webserver standardmäßig ausgelieferte Fehlermeldung ist ja nicht wirklich schön.
Technisch funktioniert diese automatische Weiterleitung zu der gestalteten Error404 Seite über die .htaccess Datei. Darin wird für den Webserver angegeben, welche Seite er ausliefern soll, wenn die angeforderte Seite nicht bekannt ist.
Der Eintrag sieht meist so aus:

ErrorDocument 404 /test/fehlerseite.htm

Jetzt weiß der Webserver, dass er in diesem Fall auf /test/fehlerseite.html umleiten soll. Diese Umleitung ist für den Webserver allerdings in keinster Weise belastend, das macht der mit Links. Soweit so gut.

Die Fehlerseiten werden üblicherweise im Layout des Webauftritts gestaltet. Wer es ganz toll macht, wertet den Referrer aus und reagiert darauf entsprechend.
So kann z.B. abhängig von Google Anfragen jetzt direkt die Suche mit dem passenden Suchbegriff gestartet werden. Das funktioniert allerdings nur mit dynamisch erstellten Seiten und erfordert auf dem Webserver dann schon auch ein bisschen Rechenarbeit und entsprechende Datenbankabfragen.

Aber auch, wenn nur auf die Startseite umgeleitet wird, muss diese ja erstellt werden.

Die ausgelieferte Fehlerseite verursacht damit praktisch die gleiche Serverlast wie jede andere Seite des Auftritts.

Interessant wird es nun bei fehlerhaften Grafiken in html und css in den ordentlichen Seiten.
Hier sind nicht mehr existierende css-Hintergrundgrafiken und in html eingebundene Grafiken eine gemeine Fehlerquelle. Schwer zu finden sind solche Anweisungen auch in javascript Code!
Html funktioniert ja so, dass die Webseite vom Webserver an den Browser ausgeliefert wird. Der Browser wertet das html und css aus und versucht die Seite aufzubauen.

In html eingebundene Bilder fordert der Browser dann beim Webserver an. Kann der Webserver die verlangte Datei jedoch nicht finden, leitet er nun auf die Fehlerseite um und liefert diese aus. Der Browser erkennt jetzt wiederum, dass er kein Bild geliefert bekommt und zeigt entweder nichts (bei css-Hintergrundgrafik) oder je nach Browser ein Ersatzbild (der IE zeigt das mit dem roten Kreuz an) oder ebenfalls nichts (Firefox) an.
Das bedeutet, dass jede im html oder css eingebundene Grafik, die auf dem Server nicht (mehr) vorhanden ist den Faktor der Serverlast pro ausgelieferte Seite um 1 erhöht. Also ein Hintergrundbild im css das auf dem Server nicht vorhanden ist sorgt dafür, dass sich die Serverlast für die Auslieferung dieser Seite verdoppelt.
Schließlich wird die Seite auf dem Server ja generiert und an den Browser ausgeliefert. Jede enthaltene Grafik, die der Server nicht finden kann, sorgt für einen Aufruf der Error404-Seite und damit für entsprechende zusätzliche Last.
Damit kann man die Reserven des Servers natürlich auch testen. Fünf solcher eingebauten Grafiken sorgen etwa für die fünffache Serverlast. Werden die Seiten dennoch einigermaßen flott ausgeliefert, kann man also davon ausgehen, dass der Server für die normale Seite also noch reichlich Reserven hat.

Wie kann man solche Fehler vermeiden?

Beim Schreiben von html und css Quellcode wird sehr gerne kopiert. Wenn die mit kopierten Anweisungen für die Grafiken dann nicht entfernt werden, wirkt sich das häufig nicht auf das Design der Seite aus und fällt damit nicht auf.
Erst beim Einsatz von firebug oder Yslow kann man sehen, dass die Seite Grafiken anfordert, die den Fehler 404 zurückmelden.
Insgesamt bestätigt mich diese Erfahrung nun in meiner Einstellung zu sauberem Quellcode.

Kommentar abgeben: