Eine Optimierung der Webseite hinsichtlich eines schnellen Aufbaus und geringer Datenmengen sollte immer beachtet werden!

In den letzten Jahren ist die Downloadrate im Internet stark angestiegen. Viele Nutzer können nicht nur in der Arbeit, sondern auch von zu Hause aus, große Datenmengen in kürzester Zeit anfordern und herunterladen. Trotzdem ist es nach wie vor wichtig, die Datenmenge gering zu halten und einen Server zu besitzen, der eine schnelle und starke Anbindung hat, um die Webseite schnellstmöglich zu übertragen. Seiten zur Bewertung der Suchmaschinenoptimierung werten oft die Ladezeit der Webseite aus und es ist gar nicht so einfach die volle Punktzahl in diesem Bereich zu erreichen. Man darf auch die steigende Anzahl an Nutzern mit mobilen Endgeräten (iPhone, Smartphone, Notebooks mit mobilem Internet) nicht vergessen, denen bei Weitem nicht die Downloadrate eines festen Internetanschlusses zur Verfügung steht. Natürlich sollte für diese Klientel eigentlich eine eigene Webseite/ein eigenes Template erstellt werden, jedoch ist auch zu beachten, dass das viel Arbeit und somit Mehrkosten mit sich bringen würde und sich das nicht alle Firmen leisten können oder wollen. Aber auch so kann man die Datenmenge einer Webseite verkleinern ohne das man Einbußen in der Qualität hinnehmen muss. Das hat zusätzlich auch noch den Vorteil, dass man sich Traffic spart und den Server für den Datenaustausch nicht so stark belastet. Auch das kann zu einer geringeren Requesttime führen (Zeit, die zur Rückantwort benötigt wird).

 Bildcodierung und Formatwahl

Ein sehr wichtiger Punkt bei der Einsparung von Datenmengen bildet die richtige Wahl des Formats und eine ausgewogene Balance bei der Bildcodierung. Im Wesentlichen werden drei Bildformate innerhalb der Webseiten genutzt. Bei diesen Bildformaten handelt es sich um JPEG/JPG (Joint Picture Expert Group), um GIF (Graphics Interchange Format) und um PNG (Portable Network Graphics). Neben diesen drei Formaten hat W3C auch noch SVG als standardisiertes Format freigegeben. Jedoch unterstützt der Internet Explorer von Microsoft erst ab Version 9 dieses Format nativ (Grundversion ohne Add-ons). Da jedoch noch viele Benutzer mit früheren Versionen des IE unterwegs sind würde ich vorerst auf dieses Format verzichten. SVG ist ein vektorbasiertes Format, das erheblich zur Datenreduktion, insbesondere bei Flächen, beitragen könnte. Ich bin mir sicher, dass dieses Format in naher bis mittlerer Zukunft Einzug in viele Webseiten halten wird. (Dann wenn nur noch ein kleiner Teil mit IE8 oder geringer unterwegs ist.)
Wann nehme ich welches Format her?
Folgende Tabelle geht vom Normalfall aus.

Benutzungsschema der Bilder

Ich persönlich würde PNG gegenüber GIF bevorzugen, insofern es sich nicht um ein animiertes Bild handelt!

 JPG und dessen Einsatzbereiche

JPG findet vor allem bei Fotobildern Verwendung und kann unterschiedlich stark codiert werden. Da JPG stets verlustbehaftet ist, sollte es in keinem Fall mehrfach abgespeichert werden, da Bildinformationen bei jedem speichern (mit Neuaufbau der Codierungstabelle) verloren gehen! Man sollte ein JPG stets aus einem Dateiformat erstellen, welches verlustfrei gespeichert wird. Speichert man ein JPG, so kann man dies mit unterschiedlicher Qualität machen. Je geringer man die Dateimenge halten will, desto verschwommener und artefaktbehafteter (Artefakte = Signalstörungen bei der Bildkompression) wird das Endprodukt im Normalfall. Man muss hier eine Balance zwischen guter Bildqualität und geringer Dateigröße finden. Sozusagen das beste Dateigrößen-Leistungs-Verhältnis. Wobei ich im Ernstfall ein gutes Bild mit großer Datenmenge einem Bild mit schlechter Qualität und geringer Datenmenge vorziehen würde.
Aus eigener Erfahrung kann ich sagen, dass sich JPG vor allem für Realbilder eignet und man die besten Ergebnisse mit den neuesten Photoshop-Versionen erzielen kann. JPG kann bis zu 16,7 Millionen Farben darstellen (24-bit-Darstellung). Da JPG jedoch verlustbehaftet ist, ist es nicht für alle Einsätze geeignet. Vor allem große einfarbige Flächen können mit anderen Formaten besser und mit geringerer Dateimenge dargestellt werden. Auch die fehlende Transparenzfähigkeit des JPG schließt einige weitere Einsatzmöglichkeiten aus.

 PNG und dessen Einsatzbereiche

PNGs gibt es in zwei Hauptausführungen, dem PNG-24 und dem PNG-8 (zudem gibt es noch ein PNG mit Graustufenpalette). Die Zahl dahinter deutet jeweils auf die Farbtiefe der einzelnen Grafik in Bit hin. So ist es dem PNG-24 möglich bis zu 16,7 Millionen Farben darzustellen, während das PNG-8 maximal 256 Farben darstellen kann. Des Weiteren ist es dem PNG-8 möglich auch weniger als 256 Farben aus einer dann indexierten Farbtabelle darzustellen. Natürlich kann das zu einer großen Einsparung bei der Datenmenge, aber auch zu Qualitätsverlusten führen. Hat man jedoch eine aus wenigen Farben bestehende Fläche, ist dieses Dateiformat optimal um ein Bild mit geringer Dateimenge und trotzdem sehr guter Qualität zu erzeugen. Natürlich muss man die Farbtiefe des PNG-8 dann den Gegebenheiten anpassen. Jedoch gilt auch hier: Lieber eine größere Dateimenge anstatt zu starker Einbußen der Qualität hinnehmen. Zudem bietet sowohl das PNG-24 als auch das PNG-8 die Möglichkeit von Transparenzen.

Das PNG-24 hat meistens eine größere Dateimenge als das PNG-8 kann jedoch auch weitaus mehr Farben darstellen. Insbesondere wenn Realbilder und Farbflächen innerhalb eines Bildes vorkommen, ist das PNG-24 die beste Wahl. Das Realbild erfordert eben eine große Palette an Farben und die Farbfläche erfordert eine farbechte Wiedergabe, die ohne Artefaktbildung (wie bei JPG) auskommt. Zudem sind beide PNG-Arten verlustfreie Datenformate, sprich man kann sie wiederholt abspeichern ohne das eine Neujustierung der Farbpalette stattfindet. Natürlich kann es sein, dass bei der Einpassung in die einzelnen Farbpaletten der PNGs beim erstmaligen Speichern Farbdaten verloren gehen, da die Endpalette kleiner als die Ausgangspalette sein kann.

Die Kompressionsrate ist meistens besser als die eines GIFs, was das PNG in den meisten Fällen zur besseren Alternative zum GIF macht. Das PNG ist ein modernerer Standard als das GIF, hat jedoch nicht die Möglichkeit animierte Inhalte darzustellen. Es gibt zwar Projekte die es ermöglichen animierte PNGs zu erstellen, oder auch das geplante MNG (Multiple-Image Network Graphics) wäre eine Möglichkeit, jedoch unterstützen nur wenige bzw. nicht alle wichtigen Browser diese Formate. Zudem sind sie derzeit unüblich und wenig genutzt.

 GIF und dessen Einsatzbereiche

Das GIF (Graphics Interchange File) ist ein schon lange genutztes Dateiformat, welches vor allem zu Beginn des modernen Internets zum Einsatz kam. Durch die geringe Dateigröße konnte man auch mit kleinen Downloadraten Bilder auf den Seiten betrachten. Durch die maximale Anzahl von 256 Farben ist das GIF jedoch stark in seinen Möglichkeiten begrenzt.
Ich persönlich benutze das GIF mittlerweile sehr selten, da es bessere Möglichkeiten der Darstellung durch PNGs und JPGs gibt. Wie auch das PNG kann auch das GIF Transparenzen darstellen. Zudem bietet das GIF auch die Möglichkeit animierte Inhalte darzustellen. Bei Animationen, die kurz sind und nicht allzu viel Farben benötigen, ist das GIF nach wie vor die erste Wahl. Aber auch nur aus Mangel an Alternativen. GIF bietet zudem die Interlacedarstellung, mit der es möglich ist ein Bild nach und nach (zeilenweise) zu laden. So wird das Bild nach und nach schärfer und man kann schon früh etwas erkennen. Jedoch ist dieser Vorgang eigentlich schon veraltet, da Bilder mittlerweile schnell ganz geladen werden können.

 Komprimierung von Javascripts und CS-Sheets

Neben einer Einsparung von Dateimengen bei Bildern kann auch bei den Stylesheets und den Javascripts Traffic eingespart werden. Natürlich sind diese Kompressionen stets verlustfrei. Es werden dabei Kommentare und unnötige Zeichen weggelassen, aber auch andere Wege bestritten, um die Dateigrößen zu reduzieren. Oft werden diese Dateien anschließend auch noch einer gzip-Komprimierung unterzogen. Das letztendliche Produkt kann sich, je nach Anzahl der Kommentare und der Kompressionstauglichkeit, in einem Bereich von einem Fünftel bis einem Zehntel der ursprünglichen Größe bewegen. Um zu demonstrieren, welchen Unterschied man durch das Komprimieren und Zippen erreichen kann, habe ich es in meinem Beispiel umgesetzt und bin zu folgenden Ergebnissen gekommen:
Insgesamt habe ich sechs Javascript-Dateien und drei CSS-Dateien, die mit der Startseite geladen werden müssen. Bei Versuch 1 komprimiere ich die JS-Dateien mit Hilfe der besten Komprimierung ohne Zippen auf http://compressorrater.thruhere.net/. Bei Versuch 2 wird die beste Komprimierung angewandt und anschließend noch mit gzip versehen. Bei Versuch 3 benutze ich Icespeed, ein Joomla-Plugin, das alle Javascript-Dateien in eine alles umfassende Javascript-Datei verwandelt (merged) und anschließend noch komprimiert, so wie gzipped. Analog macht es das Plug-in mit den Cascade-StyleSheets, als Grunddateien dienen mir in diesem Fall die unkomprimierten Ausgangsdateien. In Versuch 4 teste ich ob es einen Unterschied macht, die Dateien vorher noch auf den Stand von Versuch 1 zu bringen (Komprimieren und kein gzip) und anschließend das Prozedere von Versuch 3 durchzuführen. Bei dem Versuch YUI habe ich die YUI 2.4.6-Kompression (YUI 2.4.6 Compressor) auf die einzelnen Dateien angewendet und anschließend Icespeed benutzt, um die Dateien zusammenzuführen. Zusätzlich wurde dieses Paket dann auch noch gzip-komprimiert.

Komprimierungstabelle der JS-Dateien

--- Die gespeicherten Dateien kann man auf der DVD im Ordner Komprimierung unter dem jeweiligen Namen finden. ---
Fazit: Das Allerwichtigste und Augenscheinlichste vorweg: Eine Komprimierung der Daten ist für einen schnellen Zugriff und Einsparungen im Trafficbereich unumgänglich. Schon das Weglassen von Leerzeichen und Kommentaren kann zu einer guten Ersparnis bei den Datenmengen führen. Unterzieht man die Datei danach noch einer Kompression und verpackt es in einer gzip-Datei, lassen sich unglaubliche Mengen einsparen. Im besten Fall geschieht das mit einer einzelnen Datei, die zuvor aus einer Zusammenführung der Grunddateien erstellt wurde. Hierfür gibt es viele Plug-ins, die diese Aufgabe automatisch erledigen können.
In meinem Fall war dass das Joomla-Plugin IceSpeed, mit dessen Hilfe ich das beste Ergebnis erreicht habe. Die Grunddateien habe ich dabei durch den YUI 2.4.6 Compressor gejagt, was auf den ersten Blick zwar nicht so vielversprechend schien wie die Kompression bei Versuch 1, aber letztendlich war die zusammengeführte Datei dann wesentlich kleiner (76478 (unkomprimierte YUI-Sammeldatei) zu 89246 (unkomprimiert V1-Sammeldatei)).
Tipp: Natürlich kann man dieses Beispiel nicht auf alle anderen Webseiten übertragen. Um eine sehr gute Einsparung zu erreichen, sollte man mehrere Varianten ausprobieren und sich auch Gedanken darüber machen, ob es sinnvoll ist den Server die Komprimierarbeit machen zu lassen, da dieser dadurch auch belastet wird. Man sollte sich in jedem Fall ein geeignetes Plug-in besorgen und von der Möglichkeit der automatischen Zusammenführung der Dateien zu einer „Überdatei“ Gebrauch machen. Es ist nämlich fördernd für die Suchmaschinensichtbarkeit, wenn man weniger Dateien zum Start laden muss. Auch bessere Kompressionsraten lassen sich bei einer einzelnen Datei erzielen.
Info: Bei mir kam es zu Problemen, nachdem die ausschließlich vom Packer komprimierten Dateien zu einer zusammengefügt wurden. Die außergewöhnliche Komprimierweise kann hier zu Problemen führen.

Komprimierung der CSS-Dateien

Im Gegensatz zu den Javascript-Dateien werden CSS-Dateien viel öfter vom Webmaster geändert. Aus diesem Grund lege ich die CSS-Dateien in ihrer Grundform auf den Server und lasse IceSpeed die Arbeit verrichten. Sollte man kein Plug-in besitzen, müsste man die Dateien immer manuell komprimieren. Icespeed fügt die CSS-Dateien zu einer Datei zusammen, entnimmt unnützen Inhalt und unterzieht die Datei einer gzip-Komprimierung. So liegen die Dateien letztendlich, fürs menschliche Auge noch immer gut lesbar, auf dem Server, werden jedoch mit sehr wenig Datenmenge an den Nutzer übertragen!

 Minimierung der Requests

Requests (zu deutsch: Anfragen) bezeichnet die Anzahl der Dateien, die benötigt werden, um die Webseite vollständig anzuzeigen. Bei der Webseitenoptimierung sollte diese Zahl möglichst gering sein. Eine stilvolle Möglichkeit diese Anzahl zu verringern ist die Benutzung von Plug-ins, die mehrere vorhandene CSS- und/oder JS-Dateien in jeweils eine große Datei umwandeln. Dabei kann es jedoch auch zu Zusammenführungsproblemen kommen. Je nach Kompatibilität der Dateien zueinander und der Qualität des Plug-ins kann die Anzahl mehr oder weniger stark verringert werden.
Social Bookmark Buttons bestehen meist aus verschiedenen einzelnen Bilddateien, was die Anzahl der Requests unnötig in die Höhe schraubt. Man kann, anstatt auf mehrere kleine Bilddateien zurück zu greifen, auf eine große Bilddatei mit einer Imagemap verlinken. Leider gibt es derzeit kein Joomla-Plugin, dass sich so aufbaut. Eine Eigenkreation ist zwar zeitaufwendig, in diesem Fall jedoch auch sinnvoll. Man baut die verschiedenen Buttons im Bildbearbeitungsprogramm zu einem großen Bild zusammen. Am besten funktioniert das, wenn man gleich die richtigen Abstände mit einbaut. Anschließend verlinkt man die Buttons mit Hilfe einer Imagemap und weist ihnen ihren jeweiligen Raum zur Verlinkung zu.
Im Beispielfall der DaySpa-Seite wurde dadurch, aus den ausgewählten zwölf Buttons der Bookmarkingdienste, ein großer Button mit Imagemap. Schöner Nebeneffekt, neben der Einsparung von 11 Requests, war in diesem Fall zudem eine minimale Einsparung von 3KB an Datenmenge (6KB (Imagemap-Bild) zu vormals 9KB (Summe der kleinen Buttons)).

 HTML- und PHP-Komprimierung

Ein Teil des Einsatzspektrums der gzip-Komprimierung habe ich schon im vorhergehenden Punkt angesprochen. Dabei können nicht nur Javascript- und CSS-Dateien, sondern auch HTML- und PHP-Dateien in der Datenmenge verkleinert werden. Diese Komprimierung erfolgt eigentlich immer nur serverseitig, da der Inhalt ja dynamisch in der Datenbank abgelegt ist und man, anders als bei JS und CSS, sozusagen keine festen Daten besitzt. Deshalb ist immer darauf zu achten eine Balance zwischen dem Arbeitsaufwand des Servers und der übertragenen Datenmenge (Traffic) zu finden. Durch das gzip-Verfahren sind Einsparungen von 1/3 der Datenmenge keine Seltenheit. Für die Komprimierung gibt es verschiedenste Tools und Plugins. Ich selbst habe in diesem Fall das IceSpeed Plug-in benutzt, dass mir nebenbei auch die JS- und CSS-Zusammenführung und -Komprimierung erlaubt.

Nebeneffekt: Außerdem befreit dieses Tool, wie auch viele andere, die HTML-Seiten von unnötigem Ballast, wie Leerzeichen und Kommentare. Ein schöner Nebeneffekt hierbei ist die Steigerung des Inhaltsanteils an der Gesamtseite - bessere Code to Text Ratio. In meinem Beispiel habe ich anstatt einer Quote von 22,28% (3701 B/16612 B) einen Anteil von 23,99% (3639 B/15168 B) des Textes am gesamten Code.

 Wahl des richtigen Webspace-Providers

Die Wahl eines guten Webspace-Providers ist vor allem wichtig für einen schnellen Zugriff auf die Webseite. Ein guter Provider bietet eine sehr gute Anbindung des Servers und dazu einen Server mit sehr guter Hardware. Beides verhilft der Seite zu einer schnellen Abrufbarkeit. Während die Hardware die Seite schnell berechnet und ggf. codiert, sorgt die gute Anbindung dafür, dass die errechneten Daten schnell ihr Ziel erreichen. Eine gute und schnelle Erreichbarkeit der Webseite ist essenziell.
Neben guter Hardware und Anbindung ist zudem wichtig, dass man auf einen Webhoster setzt, der für seine seriöse Arbeit bekannt ist und nicht Gefahr läuft von den Ausschlussregeln der Suchmaschinen betroffen zu sein. Viele unseriöse Anbieter haben oft schlechte AGB und/oder schwarze Schafe unter ihren Kunden. Selbst wenn man selbst alles sauber und regulär einrichtet, kann es zum Ausschluss oder einer Herabstufung bei Suchmaschinen kommen, da oft ganze IPs gesperrt werden. So würde man ohne eigenes Verschulden herabgestuft. Aus diesem Grund ist zu empfehlen einen bekannten Provider mit guter Reputation oder zumindest einen Provider mit klaren AGB zu wählen.
Auch eine gute „Nachbarschaft“ auf dem Server wäre empfehlenswert. Es ist sehr leicht nachvollziehbar welche Domains Nachbarn der eigenen Domain sind. Auch von außen kann man über bestimmte Tools (z. B. whois.de) einsehen auf welchem Server sich die Page befindet und mit wem man sich die „Nachbarschaft“ teilt. Zudem werden Server, die Seiten mit unseriösem Inhalt anbieten, statistisch öfter gehackt als Server mit seriösen Domains.
Ich empfehle das Internet, vor Vertragsabschluss mit dem Webspace-Provider, nach Kritiken über diesen Anbieter zu durchforsten. Des Weiteren kann man auf den Seiten hostsuche.de oder auch webhostlist.de die Qualität des Anbieters mit der des Marktes vergleichen. Die Angebotspreise sind meist sehr moderat, sodass man nicht unbedingt das günstigste Angebot nehmen muss. Eine Investition in ein qualitativ hochwertiges Produkt ist hier nicht teuer und eine gute Entscheidung!