Optimierung « Schnurpsel

Black Hat Sith / White Hat Jedi – SEO-Wettbewerb

Der schwarze Hut

Es gibt mal wieder einen SEO-Wettbewerb, gewissermaßen um das Sommerloch zu füllen. Der Start war am 27. Juli und er läuft noch bis zum 31. August. Der Gesamtwert der Preise von 40000 Euro wirkt recht spektakulär und auch der Ablauf und die Wertung der Teilnehmer klingen durchaus innovativ, was einen SEO-Wettbewerb angeht.

So wird nicht nur an einem Stichtag zu einer bestimmten Zeit das Ranking bei Google herangezogen. Vielmehr gibt es an fünf Tagen vor Ende des Wettbewerbs jeweils um 19 Uhr eine Punktevergabe für die Rankings von Platz 1 bis 40. Hier zählen aber nur „Text-Suchergebnisse“, also keine Bilder, Videos, News usw. Wer dann in der Summe die meisten Punkte hat, hat gewonnen. Einfach, aber durchaus mal etwas Neues bei einem SEO-Contest.

Und noch etwas ist anders als sonst, es gibt zwei Suchbegriffe, auf die optimiert werden soll: Black Hat Sith und/oder White Hat Jedi

Ausgerufen hat den SEO-Wettbewerb die Website CineStock, Anbieter für lizenzfreie Cinemagraphs, Videos, Bilder und Musik. Cinemagraphs bzw. Cinemagramme sind laut Wikipedia Standbilder, die eine oft kleine, sich wiederholende Bewegung enthalten. Sie erscheinen dem Betrachter eher als Bild statt als ein kurzes Video.

Onpage-SEO, nie davon gehört!

Wenn man sich die Seite zum Wettbewerb bei cinestock ansieht, wird klar, warum sie einen SEO-Wettbewerb ausgerufen haben. Denn die Seite benötigt dringen etwas Onpage-Optimierung. Eine vernünftige, technische Optimierung der Webseiten selbst ist die Basis jeder SEO-Maßnahme. Da können Inhalte und externe Links noch so gut sein, wenn die Seite lahm daherkommt, sind die Besucher schnell wieder weg und auch Google wird nicht mit Top-Rankings winken.

Cinestock – Netzwerkanalyse

Insgesamt 227 Abfragen laden mal eben knapp 170 MB herunter. Das dauert dann auch mit meiner DSL-100 Anbindung stolze 18 Sekunden.

So werden die Logos der 36 Sponsoren und 26 Medienpartnern als einzelne JPEG-Bilder eingebunden.

Cinestock – Medienpartner Logos

Den Vogel schießt hier das 193×50 Pixel „große“ Logo von „SEO-Trainee“ ab, das als JPEG mal eben mit 650 kB zu Buche schlägt. Als PNG dürfte es etwa 10 kB groß sein.

Generell ist für Logos und Grafiken das PNG-Format besser geeignet und bei einer Vielzahl von kleinen Bildchen sollte man auch über Techniken wie CSS-Sprites oder Ähnliches nachdenken.

Aber gut, das PNG-Format kommt dann doch noch zum Einsatz. Allerdings hier nun für Bilder, die eher Foto-Charakter haben und für die daher besser das JPEG-Format geeignet ist.

Cinestock – Bilder (als PNG)

Am Ende der Seite findet man „Content für deine Seite“, eine Liste mit 20 Fotos der Größe 1920×1080 Pixel im PNG-Format und weiteren 35 Cinemagramme mit einer Breite von 650 Pixel als animierte GIF-Dateien. Gut, für die Cinemagramme ist wegen der Animation das GIF-Format die einzige Option. Aber für die Fotos wäre man mit JPEG-Bildern besser gefahren, das Bild „Black Hat Pokal 3“ ist als PNG über 3 MB groß, als JPEG dürfte es bei noch guter Qualität um 300 kB groß sein.

Aber unabhängig von der Eignung oder Nichteignung des Bildformates ist es keine gute Idee, 55 recht große Bilder auf einer Seite direkt als Bild in der Originalgröße einzubinden. Hier hätte es eine Galerie mit kleinen Vorschaubildern, die auf das Originalbild verlinken, auch getan.

Und was ist mit Facebook?

Allein 61 externe Requests gehen zum Facebook-CDN (fbcdn.net), davon 11 CSS, 29 JS und 15 mp4-Videos. Was für Videos eigentlich? Ganz oben am Anfang der Seite ist ein FB-Video als Erklärvideo eingebunden, aber was ist mit den 14 anderen?

Viele, externe Ressourcen sind der Seitengeschwindigkeit auch nicht gerade zuträglich.

SEO fängt mit Onpage an

Liebe Betreiber von CineStock, bevor Ihr einen SEO-Wettbewerb startet, solltet Ihr erst einmal die SEO-Hausaufgaben machen. Sonst verpuffen die positiven Effekte des Wettbewerbs ganz schnell unter der ächzenden Last einer lahmen Webseite!

Mit den Google-Webmastertools bekommt man einen guten Überblick, wie oft der Googlebot vorbeischaut und wieviele Daten er in welcher Zeit Abfragt.

Pro Tag gecrawlte Seiten

Auf dem Diagramm ist noch das Ende vom November, der ganze Dezember und Januar und der Anfang vom Februar zu sehen. Scheinbar tritt der Googlebot auch über den Jahreswechsel etwas kürzer, feiert Weihnachten und Silvester und legt dann erst Mitte Januar wieder richtig los.

Pro Tag heruntergeladene Kilobyte

In etwa parallel dazu verläuft normlerweise die Kurve zu den täglich heruntergeladenen Datenmengen. Klar, je mehr Seiten angefragt werden, um so mehr Daten fallen da durchschnittlich an.

Eines fällt aber auf, denn obwohl die Anzahl der pro Tag abgefragten Seiten ab Mitte Januar und im Februar höher liegen als noch im November, ist die Datenmenge nicht in gleichem Maße angestiegen. Der Grund ist recht einfach. Ich hatte Anfang/Mitte Dezember die gzip-Komprimierung für die Seiten aktiviert.

Dauer des Herunterladens einer Seite (in Millisekunden)

Die Geschwindigkeit der Seitenauslieferung ist die für den normalen Nutzer, also den Besucher einer Website der wohl wichtigste, technische Wert. Wenn erstmal ein paar Sekunden nach dem Aufrufen einer Seite oder länger nichts passiert, ist das aus Anwendersicht eher unerfreulich.

Der Wert lag im November bei etwa 1,5 Sekunden und schließt damit an die Zahlen vom Oktober an. Anfang Dezember bin ich dann Dank SpeedPlus wieder zu Strato zurückgekehrt und seitdem liegen die Ladezeiten fast immer bei erfreulichen 0,8 Sekunden. Aber eben nur fast. Wie man im Diagramm sieht, gab es schon im Dezember und Anfang Januar Ladezeitspitzen, die dann im Februar nochmal deutlich zunahmen. Allerdings ist das eher darin zu sehen, daß durch die größere Anzahl der pro Tag abgefragten Seiten auch die Wahrscheinlichkeit für den Googlebots auf eine Lastspitze zu treffen, größer war.

Ungeachtet dessen gibt es aber diese Lastspitzen, die nicht nur der Googlebot „sieht“, sondern auch der normale Nutzer bemerkt. Wenn man Pech hat, dauert das Laden einer Seite wieder 4 bis 6 Sekunden, ganz so wie vor der SpeedPlus-Zeit bei Strato. Diesmal ist es aber meiner Meinung nach nicht die schlechte PHP-Performance, sondern eher die Datenbank. Die Datenbankserver sind zwar grundsätzlich nicht wirklich lahm, legen aber ab und zu ein paar Gedenkminuten ein, wie mir scheint. Und genau dann dauert der Seitenaufruf wieder mehrere Sekunden. Kürzlich gab es auch wieder mal einen Totalausfall, der dann zu einem 500er Fehler führt.

Hin und weg

Nun sind zwar PHP und Webserver bei Strato schnell, aber die Datenbank klemmt mitunter. Deshalb bin ich vorerst wieder zu meiner externen Datenbank zurückgekehrt. Das eigentlich langsame ist hierbei die Datenübertragung über das Internet zwischen Strato (Karlsruhe/Berlin) und Host-Europe (Köln). Um das etwas abzudämpfen, habe ich zusätzlich ein Datenbank-Cache-Plugin installiert, welches häufig benötigte Daten auf dem Webspace bei Strato im Dateisystem ablegt, um diese nicht jedesmal neu übertragen zu müssen. Zumal sich viele Daten, z.B. die Artikel und Seiten normalerweise eh nicht ändern.

Nun werde ich das Alles mal weiter beobachten, wie das mit den Ladezeiten so aussieht und hoffe aber trotzdem, das Strato die Datenbankaussetzer in den Griff bekommt.

Schnurpsel

Black Hat Sith / White Hat Jedi – ganz ohne SEO