Das Putzlowitsch Test- und SEO-Blog

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 »

LSR schlägt auf Google-Bildersuche durch – Welt, Auto- und Computerbild verschwunden

Kein Text

Das Leistungsschutzrecht für Presseverleger (LSR) schützt bereits kleine Ausschnitte aus Zeitungsartikeln (und Vorschaubilder) für ein Jahr nach der Veröffentlichung.

Diese Snippets und Thumbnails werden normalerweise von Suchmaschinen in den Suchergebnissen angezeigt. Das ist nach Inkrafttreten des LSR aber nicht mehr möglich, es sei denn, die Presseverleger gestatten es ausdrücklich, ggf. für eine Vergütung.

Google hat sich vor einigen Tagen entschlossen, in den Suchergebnissen keine Snippets und Thumbails von Verlagen anzuzeigen, die der Verwendung nicht zugestimmt haben. Klar, man will ja nicht gegen Gesetze verstoßen.

Für die normale Suche sieht es nun so aus, daß Artikel zwar noch in den Suchergebnissen gelistet werden, aber nur mit Titel und Link zur Seite.

Google-Suche: Ebola (welt.de ohne Snippet)

Während beim „Spiegel“ und der „Zeit“ ein zweizeiliger Textausschnitt angezeigt wird, findet man beim Artikel der „Welt“ nur die Überschrift und den Link.

Kein Bild

Da zu den geschützten Presseerzeugnissen auch die Artikelbilder zählen, werden in Google-News nun auch entsprechend keine Bilder mehr angezeigt. Auch bleiben nur die Überschrift und der Link zum Artikel übrig.

Für die Google-Bildersuche hat das allerdings ganz andere Folgen, denn die Bildersuche macht ohne Vorschaubildchen keinen Sinn. Der Verzicht auf die Bilder kommt einem Rauswurf aus der Bildersuche gleich. Im Bidox gehören aktuell deshalb drei Online-Presseerzeugnisse zu den Verlierern der Woche:

LSR-Auswirkung in der Bildersuche

Betroffen sind „Autobild“, „Computerbild“ und „Welt“. In der Vorwoche lagen die Seiten im Bidox noch auf Platz 30, 39 bzw. 48

Ich kann zwar nicht beurteilen, wie hoch der Traffic über die Bildersuche bei den Verlagen war, aber im Unterschied zur normalen Suche bzw. Google-News fällt er nun komplett weg.

Ich vermute mal, daß niemand so richtig die durschlagende Wirkung des LSR auf die Bildersuche im Blick hatte.

Andere Beiträge zum Thema (extern):

6 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 »

Strato-AppWizard verhindert WordPress-Update, so geht es trotzdem

WordPress mit wenigen Klicks installieren

Sie sind ja ganz nett, diese Ein-Klick-Installationen bei den großen Webhostern wie 1&1 (Click&Build), Host Europe (Webanwendungen) und Strato (AppWizard). Mit wenigen Klicks kann man im Konfigurationsbereich des Hostingpaketes ein komplettes WordPress installieren. Man muß sich nicht um die Einrichtung von Datenbanken, die Anpassung der wp-config.php-Datei und den Upload per FTP kümmern.

Leider haben diese Installationen auch Nachteile. Bei Strato soll man das WP-Update per AppWizard durchführen. Schlecht ist es nur, wenn gar kein Update oder nur die kleinen Updates angeboten werden.

Strato AppWizard WP-Update

Für die älteren Versionen gibt es nur die kleinen Updates (3.0→3.0.4, 3.5.1→3.5.2) und bei 3.8 sieht es ganz schlecht aus. Vermutlich ist auch gar kein Updated er Hauptversion, also z.B. von 3.8 auf 3.9 oder 4.0 vorgesehen.

Kein Update möglich

Normalerweise ist es ja kein Problem, das Update direkt im Adminbereich von WordPress durchzuführen. Nur leider wird diese Möglichkeit von den 1-Klick-Paketen schlicht und ergreifend ausgeknipst, ist nicht vorhanden.

Strato-AppWizard - kein WP-Update

Nun habe ich mich auf die Suche begeben, an welcher Stelle denn das Update wegkonfiguriert wird. Fündig wurde ich in der Datei wp-includes/capabilities.php. Dort gibt es Funktionen mit denen Abgefragt werden kann, welche Rechte ein angemeldeter Nutzer hat, also was er alles im Adminbereich tun darf.

So sieht dort eine Funktion im StratoAppWizard-Paket aus:

function current_user_can( $capability ) {
	$current_user = wp_get_current_user();

	if ( empty( $current_user ) )
		return false;

	$args = array_slice( func_get_args(), 1 );
	$args = array_merge( array( $capability ), $args );

	if ( $capability == 'update_core' ) { return false;	} else { return call_user_func_array( array( $current_user, 'has_cap' ), $args ); }
}

Die Frage, ob der aktuelle Nutzer WordPress updaten darf (‚update_core‘), wird in der letzten Zeile immer mit false beantwortet. Es darf als niemand, es wird gar nicht erst geprüft, ab man als Admin dieses Recht hat. Nö, die Funktion sagt immer nein.

WP-Update wieder hervorzaubern

Entsprechend simpel ist die Lösung des Update-Problems. Man muß einfach die originale Funktion wieder herstellen. Das geht einfach mit einem FTP-Programme oder auch mit dem Strato Web-FTP.

Wir wechseln in das Verzeichnis /WordPress_01/wp-includes/, wobei die Nummer am Ende die laufende Nummer der AppWizard-Installation ist.

Strato Web-FTP capabilities.php

Dort finden wir die Datei capabilities.php und direkt darunter eine capabilities.php.bak.1387242074, ggf. mit einer anderen Zahl am Ende. Das ist die nicht manipulierte, originale WordPress-Datei. Genau die brauchen wir.

Nun können wir einfach zuerst die capabilities.php in capabilities.php.strato umbenennen und anschließen die capabilities.php.bak.1387242074 in capabilities.php.

Das Umbenennen geht im Strato-WebFTP mit der rechten Maustaste auf der Datei.

Strato Web-FTP - Datzei umbenennen

Das wars auch schon, im Adminbereich sollte nun das Update auf die neue WP-Version angeboten werden.

Getestet habe ich das nur mit der Version 3.8, bei den älteren Versionen könntes aber prinzipiell genauso funktionieren.

WP Version 3.2.x und 3.4.x

Bei WordPress Version 3.2.x und 3.4.x hat Strato das Core-Update an einer anderen Stelle ausgeschaltet (Veränderung in der Datei /wp-include/update.php). Es wäre aber zu aufwändig, diese Änderungen rückgängig zu machen.

Strato AppWizard WP-Update 3.5.1

Als Ausweg bleibt hier das schrittweise Update im Strato-AppWizard bis zur WordPress-Version 3.5.1-4. Bei dieser Version ist das Update nicht gesperrt und damit dann direkt im WP-Backend möglich.

Strato auf die Sprünge helfen

Es ist ja nun nicht das erste Mal, daß ich eine Strato-Problem bzw. -Fehler ausbügeln muß. Wenn ich da so an das www/ohne-www Problem oder die Sache mit der Remote-Adresse denke. Das früher fehlende mod_rewrite will ich gar nicht erst an die große Glocke hängen.

Wie auch immer, ich hoffe, daß ich dem einen oder anderen leidgeplagten Strato-User ein bißchen helfen konnte. Dann hat es sich doch schon gelohnt. :-)

39 Kommentare »