Im zweiten Teil meiner Reihe SEO-Maßnahmen geht um das Thema Performance. Google hat sich nach einschlägiger Meinung für das Jahr 2010 vorgenommen Websites speziell auf die Performance hin zu messen und zu bewerten. Wir können also davon ausgehen, dass sogar der Pagerank-Algorithmus hierbei großen Veränderungen unterliegt.


Google zeigt uns die Schwächen auf

Google zeigt seit neuestem in den Webmaster-Tools die sogenannte Website-Leistung an. Diese gibt euch einen Eindruck davon wie die User den Aufbau der Seite empfinden und wie Ihr im Vergleich zum restlichen Web dasteht. Zudem gibt es ja schon seit langem unter dem Bereich Crawling-Statistiken den Punkt “Dauer des Herunterladens einer Seite“. Dieser gibt halt an wie lange Google für das Herunterladen einer Seite benötigt. Im ersten Fall wird also die Zeit gemessen, welche der User warten muss (schätzungsweise inkl. OnLoad-Ereignissen) und die zweite Zeit gibt an wie schnell die Seiten (oder besser gesagt die Bytes) heruntergeladen werden.

Für das Herunterladen ist quasi die Zeit gemeint, welche eure Anwendung benötigt den kompletten Inhalt aufzubereiten und auszuliefern. Umso schneller also eure Datenbankzugriffe und Code-Routinen arbeiten, desto besser das Ergebnis. Diesen Teil der Optimierung möchte ich hier auch nicht ansprechen, da dazu sicherlich eine komplette Programmiereinführung und -Vertiefung notwendig ist. Das leisten besser Schulungen und Bücher und würde den Rahmen dieses Artikels wenn nicht sogar dieses Blogs sprengen.


Performance beim Aufbau der Seite

Ich möchte mich heute dem zweiten Teil widmen. Die Performance der Auslieferung der Seite an den Client und dem Aufbau des gesamten Dom-Baums inkl. der nachgelagerten OnLoad-Events. Es geht hier eigentlich um zwei wesentliche Dinge. Einmal geht es um die Optimierung und Komprimierung der Ausgelieferten Komponenten wie die HTML-Seite, externe JavaScript- und Stylesheet-Dateien, aber auch Flash-Videos, Bilder etc. Zum Anderen geht es um die Reduzierung der HTTP-Request zwischen Client und Server.


Teil 1 – Optimierung und Komprimierung der Komponenten

Hier geht es Hauptsächlich erst einmal darum jeglichen Content, welcher zwischen Server und Client übertragen wird so gering wie möglich zu halten.

  • Optimierung der HTML-Struktur
    Umso schlanker und einfacher euer HTML-Aufbau ist, desto geringer ist auch die endgültige Größe des ausgelieferten Dokuments. Arbeitet also z.B. besser mit klar strukturierten externen CSS-Dateien und auf keinen Fall mit Inline-Styles. Auch eine unnötige Div-Verschachtelung (weil es vielleicht einfacher ist, als CSS-Probleme geschickt zu lösen) solltet Ihr vermeiden.
  • CSS optimieren
    Benutzt eindeutige Bezeichner und achtet besonders darauf z.B. IDs auch wirklich nur einmal auf jeder Seite zu benutzen. Ich halte es immer so, dass ich meine Ids und Klassen präfixe, damit ich nicht mit externem nachgeladenem Banner-Code oder dergleichen kollidiere. Zudem solltet Ihr Zeilenumbrüche und Leerzeichen so gering wie möglich halten. Denkt daran, jedes Bit will auch übertragen werden. Nutzt hierfür ggf. den Closure Compiler von Google. Hierzu habe ich schon einmal einen Artikel verfasst. Lagert auch auf jeden Fall alle CSS-Schnippsel in externen Dateien aus. Ansonsten greift das Browser-Caching hier nicht.
  • JavaScript optimieren
    Überlegt euch besser zweimal ob Ihr z.B. für nur ein ausblendbares Div direkt ein gesamtes Framework wie jQuery benutzen wollt. Dieses hat selbst in der komprimierten Fassung noch eine erhebliche Größe. Nutz auf jeden Fall auch den Closure Compiler um euren JS-Dateien zu komprimieren. Wie beim CSS gilt, dass Ihr am besten alle JS-Schnippsel in externe Dateien auslagert. Ansonsten greift auch hier das Browser-Caching nicht.
  • Bilder optimieren
    Ohne Bilder geht natürlich gar nichts mehr in der heutigen WWW-Welt. Diese nehmen aber auch meist den größten KB-Batzen einer kompletten Seit in Anspruch. Achtet deshalb darauf, dass diese weboptimiert und möglichst klein sind. Hier ist natürlich die KB-Größe gemeint ;) .
  • Caching aktivieren.
    Wenn es euch möglich ist, dann aktiviert auf jeden Fall serverseitig das Caching all eurer Komponenten (JS, CSS, Flash, Bilder usw.). das bedeutet halt, das beim zweiten Zugriff eines Users nur der dynamische teil eurer Seite vom Browser neu geladen werden muss.  Ich habe z.B. in meiner .htaccess-Datei stehen 


    <FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=172800, must-revalidate"
</FilesMatch>

<FilesMatch "\.(xml|txt)$">
Header set Cache-Control "max-age=172800, public, must-revalidate"
</FilesMatch>

<FilesMatch "\.(html|htm)$">
Header set Cache-Control "max-age=7200, must-revalidate"
</FilesMatch>

    Das heißt, dass alle HTML-Seiten 2 Stunden und alle sonstigen Elemente 2 Tage gecacht werden sollen.

  • Gzip aktivieren
    Dadurch wird der Inhalt eurer Dateien gezippt übertragen und vom Client wieder entzippt. Das reduziert die zu übertragenden KBs enorm. In meinen Affiliate -Projekten habe ich z.B. ganz oben in der jeweiligen Index.php-Datei den folgenden Code stehen:


    <?php
if(extension_loaded("zlib") AND strstr($_SERVER["HTTP_ACCEPT_ENCODING"],"gzip"))
@ob_start("ob_gzhandler");
else
@ob_start();
?>

    Hier in meiner WordPress-Welt nutze ich einfach das Plugin GZippy von Shamalt.


Teil 2 – Reduzierung der HTTP-Requests

Um das Problem grundlegend zu erklären, lest euch bitte meinen Artikel zu dem Thema CSS-Sprites und background-Repeat durch. Dort habe ich das Problem von zu vielen HTTP-Requests an den oder die Server erklärt. Im Folgenden möchte ich einmal die Punkte aufführe, die zu einer Reduzierung dieser Requests führen.

  • Zusammenführen von JS- und CSS-Dateien
    Kombiniert alle nur möglichen externen JavaScript-Dateien zu einer einzigen und jagt diese dann noch wie schon oben beschrieben durch den Closure Compiler von Google. Geht genauso mit allen CSS-Dateien um und Ihr habt eure Requests hierfür schon einmal auf 2 reduziert. Besser geht es nicht. Ein Beispiel wir Ihr z.B. dynamisch in einem nachgelagerten Deploy-Script den Closure Compiler mittels PHP benutzen könnt, könnt Ihr  auch in meinem Artikel nachlesen. Das vorherige zusammenführen der Dateien ist mit PHP-Mitteln auch schnell erledigt.
  • CSS-Sprites nutzen
    Alle fürs Layout notwendigen Grafiken und Icons sollten als Hintergrundbilder definiert und in einer einzigen Grafik-Datei abgespeichert werden. Diese könnt Ihr dann mittels background-image und background-position zuschneiden. Als Nebeneffekt zu der Reduzierung der Requests könnt Ihr auch so den Flicker-Effekt von sich ändernden Grafiken bei Mouse-Over verhindern. Es muss ja kein Bild mehr nachgeladen werden. Größere, oder nicht immer benötigte Bilder sollten aber lieber einzeln, oder in eigenen Sprites erstellt werden.
    !Übrigens! Dass Sprites und background-repeat sich nicht gegenseitig ausschließen müssen könnt Ihr hier nachlesen.
  • Nicht zu viele Banner
    Banner sind eigentlich die zwiespältigsten Elemente einer Website. Einerseits brauchen wir sie um Geld zu verdienen und andererseits sind sie dir größten Performance-Killer. Angefangen von nicht komprimierten JS-Dateien, nicht gecachten Bildern bis hin zu invalidem HTML-Code oder schlicht nur ewig langen Ladezeiten ist so gut wie alles dabei. Also setzt eure Banner auf jeden Fall mit Bedacht ein. Hier müsst Ihr ein gutes Verhältnis von User- und Google-Freundlichkeit und euren Einnahmemöglichkeiten finden.

Ähnliche Artikel: