Das Putzlowitsch Test- und SEO-Blog

Black Hat Sith / White Hat Jedi – ganz ohne SEO

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!

Ein Kommentar »

Geschwindigkeit und Sichertheit – https geht auch schnell

Sicher ist sicher

Vor gut sechs Wochen habe ich meine putzlowitsch.de-Website auf https umgestellt.
Das SSL-Zertifikat ist schon immer in meinem Webhosting-Paket bei All-Inkl im Preis enthalten. Nun habe ich es endlich aktiviert.

Putzlowitsch mit Comodo-SSL Zertifikat

Sichtbarer Effekt ist das Schloß-Symbol in der Adressleiste, welches auf eine sichere Verbindung hinweist. Die Übertragung der Daten vom Browser des Nutzers zum Server und umgekehrt ist verschlüsselt. Das Zertifikat wird vom Browser ohne weitere Nachfrage akzeptiert, weil es in der Zertifikatshierarchie auf ein vertrauenswürdiges Root-Zertifikat von “AddTrust External CA Root” zurückgeht.

Ein technisch bedingter Nebeneffekt ist, daß meine Putzlowitsch-Domain auch eine eigene IP-Adresse bekommen hat, da All-Inkl nicht wie Strato das SNI-Verfahren verwendet. Im Unterschied zu 1&1, wo bei aktivem SSL das gesamte Webhosting-Paket eine gesonderte IP-Adresse erhält, ist es bei All-Inkl aber nur die per SSL gesicherte Domain.

Für Google eine neue Web-Site

Obwohl ich die Nicht-SSL-Version meiner Putzlowitsch-Seiten per 301-Redirect auf die https-Version weiterleite, ist es für Google erstmal eine neue Website. Erwartungsgemäß war der Google-Bot kurz nach der Umstellung auf meinen Seiten sehr aktiv.

Gut zu sehen ist das in den Google-Webmaster-Tools unter „Crawling-Statistiken“:

Pro Tag gecrawlte Seiten
Pro Tag gecrawlte Seiten

Waren es vorher ungefähr 500 bis 1500 Seiten am Tag, gab es kurz nach der Umstellung einen Spitzenwert von fast 7500 Seiten.

Pro Tag heruntergeladene Kilobyte
Pro Tag heruntergeladene Kilobyte

Entsprechend zeigt sich das auch bei der durch den Google-Bot heruntergeladenen Datenmenge.

Die eigentlich spannende Frage ist aber die nach der Gewschwindigkeit

Sicher muß nicht langsamer sein

Nachdem meine Schnurpsel-Seite hier durch die https-Umstellung einen merk- und meßbaren Geschwindigkeitverlust erlitten hat, war ich gespannt, ob sich das bei All-Inkl ähnlich darstellt.

Ich habe durchaus erwartet, daß die Seiten etwas langsamer werden, denn die Verschlüsselung benötigt auch bei All-Inkl natürlich Rechenzeit. Nach der Umstellung fühlte sich die Seite nicht langsamer an. Und wie schnell werden die Seiten für den Google-Bot ausgeliefert?

Hierzu habe ich wieder einen Blick in die Google-Webmastertools geworfen. Dort kann man sich die Ladezeiten für die Seitenabrufe durch den Googlebot ansehen.

Dauer des Herunterladens einer Seite (in Millisekunden)
Dauer des Herunterladens einer Seite (in Millisekunden)

Größere Schwankungen bei der Ladezeit gab es seit Anfang Oktober, warum auch immer, bereits vor der HTTPS-Umstellung. Danach ist für mich zumindest keine signifikanter Anstieg zu erkennen. Die Werte schwanken im Bereich von 500 bis 1100 Milliskunden.

„Gefühl“ und Meßwerte zeigen, die Seite ist durch SSL-verschlüsselte Auslieferung nicht wirklich langsamer geworden.

Noch schneller

In der Ladezeit-Grafik ist ab dem 26. November ein interessanter Kurvenverlauf zu sehen. Die Zeiten für die Auslieferung der Seiten an den Google-Bot liegen seitdem fast konstant bei knapp unter 300 ms. Was ist passiert?

Mein Webhostingpaket bei All-Inkl liegt nun schon seit mehreren Jahren auf einem Server, der mittlerweile nicht mehr der schnellst ist. Ein großer Nachteil war aus meiner Sicht, das dort nur die veraltete PHP-Version 5.2 als Standard lief. Man kann zwar per .htaccess die PHP-Version ändern, aber dann läuft PHP nicht mehr als Apache-Modul, sondern als FastCGI im Kontext des FTP-Benutzers. Genau das wollte ich aber nicht.

Die einzige Möglichkeit, eine aktuelle PHP-Version (5.6) als mod_php zu bekommen, ist der Umzug auf einen anderen Server, bei dem das neue PHP als Standard läuft.

Gesagt, getan. Am Abend des 25.11. habe ich meinen Wunsch dem Support vorgetragen und wurde noch direkt in die nächtlichen Updates und Umzüge eingetaktet. Am nächsten morgen war alles erledigt und meine Websites liefen mit PHP 5.6.

Und nicht nur das, sie waren sogar spürbar (und meßbar, siehe oben) schneller.

SSL muß nicht langsam sein

Putzlowitsch Chrome-Timeline

Alles in allem bin ich mit der HTTPS-Umstellung bei All-Inkl für meine „Putzlowitscher Zeitung“ sehr zufrieden. Ob und was es sonst nocht bringt, werde ich sehen. Technisch gesehen und von der Geschwindigleit her war es in jedem Fall ein Erfolg. :-)

3 Kommentare »

Geschwindigkeit vs. Sichertheit – https bremst Seite aus

Sicher ist sicher

Vor gut einem Monat habe ich meine schnurpsel.de-Website auf https umgestellt. Für das Shared-Webhosting bietet Strato zu einem monatlichen Preis von 2,99 Euro ein einfaches Single-Domain-Zertifikat an, welches ich nun hier auch nutze.

Schnurpsel mit Strato-SSL

Sichtbarer Effekt ist das Schloß-Symbol in der Adressleiste, welches auf eine sichere Verbindung hinweist. Die Übertragung der Daten vom Browser des Nutzers zum Server und umgekehrt ist verschlüsselt. So weit, so gut.

Sicher ist langsamer

Ich habe durchaus erwartet, daß die Seiten etwas langsamer werden, denn die Verschlüsselung benötigt natürlich Rechenzeit. Die ersten Test der auf https umgestellten Domain bestätigten das auch. Die Seiten werden merklich langsamer geladen. Aber wie langsam ist nun dieses Langsam, wenn es sogar merkbar ist?

Hierzu habe ich einen Blick in die Google-Webmastertools geworfen. Dort kann man sich die Ladezeiten für die Seitenabrufe durch den Googlebot ansehen.

Google-Webmastertools: schnurpsel.de mit https

Vor der Umstellung lag die Ladezeit zwischen 0,5 und 1 Sekunde. Das ist sicher kein Spitzenwert, aber durchaus akzeptabel. Nach der Umstellung bewegt sich die Zeit im Bereich von 1,5 bis 2 Sekunden, eine merkliche Verschlechterung.

Die Zeitfresser

Die konkreten Ladezeiten habe ich mir in den Entwicklertools von Chrome angesehen. Die Timeline und die „Resource network timing“ gibt Aufschluß darüber, wie lange etwas beim Aufruf einer Seite dauert.

Da ich keine „Meßwerte“ für schnurpsel.de aus der Zeit vor der https-Umstellung besitze, habe ich die Werte für ein Testblog, auch bei Strato gehostet, als Vergleich herangezogen.

Strato ohne https

Die Timeline für schnurpsel.de sieht so aus:

Die Zeiten für „Blocking“ und „DNS Lookup“ haben nichts mit dem Webserver selbst zu tun und liegen im normalen Rahmen.

Interessant wird es dann beim „Connecting„, der Zeit für den Verbindungsaufbau mit dem Server auf der Netzwerkebene (TCP) und eben auch für die erste SSL-Aushandlung. Die Zeit hat sich von etwa 30 ms ohne SSL auf fast 300 ms mit SSL mal eben verzehnfacht.

Die „SSL„-Zeit gibt es ohne https natürlich nicht. Hier wird die verschlüsselte Verbindung mit dem Schlüsselaustausch, Prüfung des Zertifikates usw. abschließend ausgehandelt. Das schlägt noch einmal mit mindestens 250 ms zu Buche.

Die Zeit für das Senden („Sending“) kann man praktisch vernachlässigen, sie liegt immer im Bereich von wenigen Millisekunden.

Die Wartezeit („Waitung“) ist die Zeit die vergeht, bis nach dem Senden der Anforderung (Request) die Antwort (Response) beim Browser eintrifft. Für WordPress ist es die Zeit, die benötigt wird, um die Seite zu erstellen, also Laden von WordPress, der Plugins und des Themes, Datenbankabfragen, Erzeugen der Ausgabe usw. Die Zeit liegt bei der Schnurpsel-Seite höher als bei der Testseite, weil einfach viel mehr Daten zu verarbeiten sind. Die Testinstallation ist praktisch eine leere WP-Seite.

Zu guter Letzt müssen die Daten vom Server zum Browser übertragen werden, was der „Receiving“-Zeit entspricht. Auch hier dauert es bei Schnurpsel Erwartungsgemäß länger, weil mehr Daten zu übertragen sind.

Langsames SSL bei Strato

Die zusätzliche Zeit von 550 ms (300 ms + 250 ms) paßt ganz gut zu dem, was in den Webmastertools von Google angezeigt wird. Wobei das eher die Untergrenze darstellt, die Verlängerung der Ladezeit durch SSL kann auch höher ausfallen.

Srato mit https (700 ms)

Letztendlich stellt sich mir nun die Frage, was besser oder schlechter ist. Die deutlich merkbar längere Ladezeit spricht gegen https, das mehr an Sicherheit, verbunden mit größerem Vertrauen und „Professionalität“, aber dafür.

Ich werde bei https bleiben und hoffe einfach, daß Strato da irgendwie noch was an der Geschwindigkeit verbesserm kann. Bei anderen Sachen haben sie es ja früher oder stäter auch geschafft. :-)

12 Kommentare »

Das Strato SSL Zertifikat – gut für den Nutzer (und für Google)

Sicher ist sicher

Gestern bestellt, heute schon aktiv, so schnell ging das mit dem Strato-SSL-Zertifikat für meine Domain schnurpsel.de. Zu erkennen ist das an dem Schloß-Symbol oben in der Adresszeile des Browsers.

Schnurpsel mit Strato-SSL

Alle Daten, die zwischen Eurem Webbrowser und meiner Website hin- und hergeschickt werden sind nun verschlüsselt. Das bedeutet, daß niemand mitlesen kann, welche Seiten Ihr aufruft oder welche Daten Ihr als Kommentar abschickt.

Der Spaß kostet mich zwar 2,99 Euro im Monat, aber das ist es mir wert. :-)

Das Strato Single-Domain SSL-Zertifikat

Strato bietet für die Webhosting-Pakete zwei Zertifikate an. Ein Single-Domain-Zertifikat für 2,99 Euro im Monat, das genau für die Domain gilt, für die es bestellt wird. In meinem Fall ist das schnurpsel.de, es funktioniert aber auch für www.schnurpsel.de. Das war noch nicht immer so, wie hier ein Nutzer schreibt.

Es gibt zudem ein Wildcard-Zertifikat für 9,99 Euro im Monat, das auch alle Subdomains mit abdeckt, wie z.B. testblog.schnurpsel.de oder bilderdieb.schnurpsel.de. Aber das ist mir dann doch zu teuer und die Subdomains sind praktisch nur Testseiten.

So sehen die Daten des Zertifikates aus:

Strato SSL-Zertifikat für www.schnurpsel.de

Ausgestellt ist es von Strato für www.schnurpsel.de, als Alternativ-Name ist aber auch schnurpsel.de eingetragen.

Das Zertifikat wird vom Browser ohne weitere Nachfrage akzeptiert, weil es in der Zertifikatshierarchie auf ein vertrauenswürdiges Root-Zertifikat von „Equifax Secure CA“ zurückgeht.

Besonderheiten beim Strato-SSL-Zertifikat

Viele Domains unter einer IP-Adresse

Ursprünglich funktioniert SSL nur dann, wenn unter einer IP-Adresse genau eine Website, also Domain angesprochen wird. Das liegt daran, daß die Verschlüsselung bereits bei der ersten Kontaktaufnahme des Browsers mit dem Server ausgehandelt wird und zu dem Zeitpunkt noch keine Information über die gewünschte Domain übertragen wird.

Beim Shared Webhosting der großen Anbieter wie auch Strato tummeln sich unter einer IP-Adresse aber viele Domains, so das hier SSL nicht ohne Weiteres funktioniert. Der Weg aus dem Dilemma ist eine Erweiterung des SSL-Standards von 2003 für das Multidomain-Hosting, die Server Name Indication (SNI). Hier wird der gewünschte Domainname bereits bei der Aushandlung, allerdings unverschlüsselt, übertragen.

Damit ist es möglich, auch mehrere Domains unter einer IP-Adresse mit individuellen SSL-Zertifikaten anzusprechen. Genau diese Erweiterung nutz auch Strato für die SSL-Zertifikate.

Die Sache hat eber einen kleinen Haken. Ältere Browser oder Geräte unterstützen den SNI-Standard nicht und so sind Websites damit nicht erreichbar. Der oben verlinkte Wikipedia-Artikel enthält eine Liste der Browser- und Systeme, die SNI unterstützen.

Die http auf https Weiterleitung

Damit künftig die Seite nur noch über https aufgerufen werden kann, sollten die http-Aufrufe auf https-Aufrufe weitergeleitet werde. Dazu bietet Strato im Kundenbereich die Option „SSL erzwingen“ an.

Strato-Option SSL erzwingen

Eigentlich eine feine und bequeme Sache, wäre da nicht ein Problem. Die Weiterleitung, die mit dieser Option ausgelöst wird, hat den Status 302 Found, was folgendes bedeutet:

„Die angeforderte Ressource steht vorübergehend unter der im „Location“-Header-Feld angegebenen Adresse bereit. Die alte Adresse bleibt gültig.“

Genau das wollen wir aber nicht, die Seite soll nun immer und nur per https erreichbar sein. Richtig wäre also der Status 301 Moved Permanently:

„Die angeforderte Ressource steht ab sofort unter der im „Location“-Header-Feld angegebenen Adresse bereit (auch Redirect genannt). Die alte Adresse ist nicht länger gültig.“

So soll es sein. Mein Tip daher für Euch: Setzt nicht die Option im Strato-Kundenmenü aktiv, sondern macht die Umleitung in der .htaccess selber. Das ist auch nicht weiter kompliziert. Bei mir steht folgendes drin:

# HTTPS erzwingen 
RewriteCond %{ENV:HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Das muß natürlich nach dem RewriteEngine On, aber am besten noch vor allen anderen RewriteRules stehen.

Warum Strato per 302 weiterleitet, keine Ahnung. Vielleicht sollte man sie mal auf den Fehler hinweisen. Mit den Statuscodes haben die es eh nicht so, wenn ich da noch an die Sache mit dem 410 denke.

https – ein Rankingvorteil bei Google

Als ich gestern das SSL-Zertifikat bei Strato bestellt hatte, wußte ich noch nicht, daß Google heute bekannt geben würde, daß die sichere SSL-Verschlüsselung ein Ranking-Faktor ist. Tja, Zufälle gibt es manchmal. :-)

Ist also alles prima und ich habe intuitiv das Richtige getan. Oder doch nicht?

Mir ist aufgefallen, daß meine Seiten hier bei Schnurpsel jetzt langsamer geladen werden. Zumindest kommt es mir so vor. Und da die Seitengschwindigkeit auch ein Rankingfaktor ist bleibt abzuwarten, was nun passiert. Überwiegt der Vorteil durch SSL oder der Nachteil durch die schlechtere Geschwindigkeit. Ich werde sehen…

19 Kommentare »

Wie schnell ist meine Webseite?

Nützliche Diagramme in den Webmastertools

In den Google-Webmastertools gibt es unter „Diagnostics->Crawl stats“ eine Übersicht zu den Aktivitäten des Google-Bots. Man kann sich für einen Zeitraum von 3 Monaten die Anzahl der jeweils pro Tag gecrawlten Seiten bzw. die heruntergeladene Kilobytes und die Dauer des Herunterladens einer Seite (in Millisekunden) als Grafik ansehen.

Mit letzterem Diagramm läßt sich recht gut die Leistungsfähigkeit des Webservers beurteilen. Die Zahlen sagen allerdings nicht unbedingt etwas darüber aus, wie schnell der normale Nutzer die Seiten angezeigt bekommt.

Ich habe mir die Daten für drei Webhoster angesehen.

All-Inkl

Google-Crawling bei All-Inkl - Juni bis August 2011

Bei All-Inkl habe ich unter anderem putzlowitsch.de gehostet. Die Seitenabrufzeiten des Google-Bots liegen bei fast konstanten 750 Millisekunden. Von Anfang Juni bis Anfang Juli gab es einen Anstieg auf ungefähr 1200 ms. Was da los war, kann ich nicht sagen.

Die Seitenabrufdauer ist mit den derzeitigen 0,75 Sekunden recht ordentlich. Auch die gefühlte Geschwindigkeit beim Aufruf der Putzlowitsch-Seiten ist für mein Dafürhalten gut bis sehr gut.

1&1

Google-Crawling bei 1&1 - Juni bis August 2011

Bei 1&1 habe ich zur Zeit keine wirklich wichtigen Seiten zu liegen. Das Diagramm zeigt die Zeiten für gerech.net, allerdings noch bevor ich dort das aktuelle WordPress (WP) 3.2.1 installiert hatte. Vorher gab es dort nur statische Seiten mit ein wenig SSI.

Die Zeiten liegen oft deutlich unter 750 Millisekunden, schwanken aber auch stärker. Insgesamt ist die Geschwindgkeit aber gut. Es bleibt abzuwarten, wie das nun mit WP und der intensiven Datenbanknutzung aussehen wird. Heute gab es zwischenzeitlich einige Probleme mit der Erreichbarkeit meiner 1&1-Seiten überhaupt.

Strato

Google-Crawling bei Strato - Juni bis August 2011

Strato war schon länger ein Performance-Sorgenkind. Nachdem die Sache mit PHP mittlerweile ganz gut läuft, scheint nun doch die Datenbank öfter mal die Seiten auszubremsen. Ich habe dazu im Moment eine kleine Test laufen, dessen bisheriger Verlauf aber auch Grund zur Hoffnung auf Verbesserung der Situation gibt.

Die Ladezeiten schwanken teils erheblich im Bereich von ungefähr 650 Millisekunden bis rauf zu 4,2 Sekunden. Auch die gefühlte Geschwindigkeit geht von zügiger Seitenanzeige bis zu lahmem Seitenaufbau. Zu bestimmten Zeiten kann das bis zu 20, 30 Sekunde gehen oder endet sogar im Timeout (Fehler 500).

Bei Strato läuft übrigens meine Schnurpsel-Seite hier.

Langsam, schnell oder mittelmäßig

Das Benutzererlebnis beim Besuch einer Webseite hängt von vielen Faktoren ab. Ein nicht unwichtiger Aspekt ist die Seitengeschwindigkeit. Die technische Basis dafür liefert die Performance des Webservers.

So gesehen bietet das Webhosting von All-Inkl eine gute Grundlage für schnelle Webseiten. Allerdings hängen die Leistungsdaten natürlich auch vom konkreten Hostingpaket ab. Insofern will ich nicht verschweigen, daß ich bei All-Inkl den Tarif „all-inkl Business 2011“, bei 1&1 „1&1 Homepage Business Pro“ und bei Strato „PowerPlus“ habe. In anderen Paketen kann die Geschwindigkeit anders aussehen.

Wie sieht denn bei Euch die Geschwindigkeitsgrafik in den Google-Webmastertools aus?

Keine Kommentare »