Das Putzlowitsch Test- und SEO-Blog

Strato-Webhosting: Update durch Downgrade/Upgrade 3.0

Sicher ist sicher, mit SSL

Mittlerweile gehört https bzw. SSL bei Websites zum Standard. Das war nicht immer so und vor einigen Jahren mußte man für ein SSL-Zertifikat noch richtig viel Geld bezahlen. Zudem war man beim Shared-Webhosting von den Angeboten des Webhosters abhängig, denn in der Regel kann man da nicht so einfach selbst Zertifikate installieren.

Vor etwa 6 Jahren gab es dann auch bei Strato die Möglichkeit, ein SSL-Zertifikat zu bestellen und so habe ich zum günstigen Einführungsangebot von € 2,99 pro Monat zugeschlagen und meine Schnurpsel-Seite damit ausgestattet. Später kostete es dann 4,90 im Monat.

Nun ist aber einige Zeit ins Land gegangen und mit Let’s Encrypt hat seit Ende 2015 jeder zum Null-Tarif die Möglichkeit, seine Website mit Verschlüsselung abzusichern. Der Webhoster All-Inkl z.B. bietet seit April 2016 die Möglichkeit, so ein Zertifikat mit wenigen Klicks im Kundenmenü selbst zu installieren.

Die großen Webhoster mußten sich dem Druck beugen und bieten in aktuellen Webhostingpaketen kostenlose SSL-Zertifikate an. Bei IONOS (1&1) bekommt man pro Hostingpaket ein Wildcard-Zertifikat, das auch alle Subdomains umfaßt. Bei Strato gibt es pro Domain ein Single-Domain-Zertifikat.

Strato – ein SSL-Zertifikat pro Domain

Also warum soll ich jetzt das Zertifikat extra bezahlen, obwohl es im Pakte enthalten ist? Weil ich noch ein altes Hostingpaket „PowerWeb Plus“ habe. Das hat zwar praktisch die selben Features zum selben Preis wie das aktuelle „Hosting Plus“, nur ist es eben alt.

Hier mal die Pakete im Vergelich:

Leistung PowerWeb Plus Hosting Pus Hosting Basic
Speicherplatz 150 GB 150 GB 100 GB
Domains 6 10 5
SSL-Zertifikate 0 10 5
Subdomains 1000 1000 500
MySQL Datenbanken 50 50 25
E-Mail-Postfächer 8000 8000 4000
E-Mail-Aliasse 40000 40000 20000
E-Mail-Speicher 80 GB 80 GB 40 GB
SFTP-Zugänge 50 50 10
App-Installation 50 50 25
Laufzeit 12 Monate 12 Monate 12 Monate
Preis/Monat € 10,00 € 10,00 € 8,00

Es sollte doch möglich sein, ein Update vom alten „PowerWeb Plus“ zum neuen „Hosting Plus“ zu machen. Die befinden sich ja schließlich innerhalb der gleichen Leistungs- und Preisklasse.

Update durch Downgrade und Upgrade

Wie schon beim letzten und vorletzten mal, kann man dieses Update, oder Sidegrade, wie es der nette Mitarbeiter von „Strato hilft“ auf FaceBook nannte, nicht mit ein paar Klicks im Kundenmenü bewerkstelligen.

Ich kann ein Upgrade auf ein höheres Paket beauftragen, das wäre in meinem Fall das „Hosting Pro“ für 20 Euro im Monat, was mir aber dann doch zu teuer wäre. Und es geht auch ein Downgrade (ohne FAX :-) in das „Hosting Basic“ für 8 Euro. Ja, das würde mir von den Leistungsdaten her auch reichen, aber es geht mir ums Prinzip.

Ein Telefongespräch mit dem Support und eine E-Mail per Kontaktformular führten nur zu einer abschlägigen Antwort:

„Ich habe soeben Ihren Anliegen überprüft und möchte Sie kurz informieren, dass eine Umstellung von dem PowerWeb Plus Paket auf das neue Hosting Plus Paket Systembedingt nicht möglich ist, da das System erkennt diese Pakete als dasselbe Paket somit wird kein Upgrade noch Downgrade ermöglicht.“

Und nun? Ich hatte dann plötzlich noch so eine Idee…

Ich könnte ja erst ein Downgrade auf „Hosting Basic“ machen und anschließend ein Upgrade auf „Hosting Plus“. Dann wäre ich wieder in meinem 10 Euro Paket und hätte zudem ein paar Inklusiv-Domains dazu und vor allem die inklusiven SSL-Zertifikate.

Es mußten vorher nur zwei Fragen geklärt werden. Was passiert mit der überzähligen Domain, denn ich habe aktuell 6 Inklusiv-Domains, im Basic-Paket sind aber nur 5 enthalten. Und kann ich überhaupt so schnell hintereinander das Paket wechseln.

Das mit der Domain ist recht einfach und eindeutig:

„Sei unbesorgt, was deine Domains angeht. Diese bleibt dir weiterhin erhalten. Sofern du mehr als die maximale Anzahl an Inklusiv-Domains im Paket gebucht hast, wird jede weitere Domain als Exklusiv-Domain extra berechnet.“

Nur wollte ich keine Zusatzdomain extra bezahlen. Also habe ich kurzerhand die eine unwichtige Domain gekündigt. Dadurch war der Weg frei zum kostenlosen Downgrade ins Strato-Webhosting-Paket „Hosting Basic“

Auch zum Zeitfaktor gab es eine schnelle Antwort:

„Ein Wechsel innerhalb der Hosting-Palette ist jederzeit zu sofort möglich. D.h. in deinem Fall heute Downgrade zum Hosting Basic und morgen dann zum Hosting Plus.“

Gestern habe ich die Domain gekündigt, heute nun das Downgrade durchgeführt.

Strato-Webhosting-Paket Basic

Und wenn ich es mir recht überlege, auch das Basic-Paket reicht mir eigentlich. Damit Spare ich 2 Euro im Monat, das sind immerhin 24 Euro im Jahr und wenn ich das auf 10 Jahre hochrechne…

Upgraden kann ich dann ja später immer noch. :-)

Nachtrag: Mittlerweile habe ich doch das Upgrade durchgeführt, weil ich eine weitere Inklusiv-Domain nutzen wollte. Und soooo viel sind die 2 Euro extra im Monat nun auch wieder nicht. :-)

5 Kommentare »

Alte PHP-Version 5.6 bei Strato jetzt auf PHP 7.2 umstellen

Freundliche Nachricht von Strato

Gestern erreichte mich eine E-Mail von meinem Webhoster Strato:

„Wichtig: Ihre PHP-Version ist veraltet
Seit Januar 2019 ist Ihre PHP-Version 5.6 veraltet und es stehen keine Sicherheitsupdates mehr zur Verfügung.
Wir lassen Sie nicht im Regen stehen! Bis zum 15.07.2019 führen unsere Entwickler kostenlos die Sicherheitsupdates für Ihre Websites fort.

Sie möchten weiterhin Ihre alte PHP-Version behalten?
Dann übernehmen wir die Aufgabe der PHP Community und führen weiterhin selbst die Sicherheitsupdates für PHP 5.6 durch. Bitte haben Sie Verständnis, dass hierdurch Wartungsaufwand entsteht, den wir ab dem 16.07.2019 mit 5,33 Euro pro Auftrag pro Monat in Rechnung stellen. Dies nennt sich PHP Extended Support. …“

Eigentlich hatte ich mein Webhostingpaket bei der STRATO AG schon auf PHP 7.2 umgestellt, dachte ich.

Alles eine Einstellungssache

Also habe ich mich schnell im Strato-Kundenmenü angemeldet und wurde gleich mit einem Popup-Fenster begrüßt.

Strato-Webhosting: Veraltete PHP-Version-Hinweis

Ja aber ich habe doch schon vor Wochen auf PHP 7.2 umgestellt. Also fix mal auf den Button [PHP-Versio ändern] geklickt und siehe da:

Strato-Webhosting: PHP-Version einstellen

Hab ich es doch gewußt:
„Sie verwenden zur Zeit folgende PHP-Version: PHP 7.2

Stimmt im Prinzip auch, nur weiter unten steht dann der entscheidende Hinweis:
„Achtung: Sie nutzen in mindestens einer .htaccess Datei auf Ihrem Webspace PHP 5.6/7.0.“

Also gammelt da in einem nicht mehr aktiven Projekt irgendwo noch eine .htaccess-Datei herum, in der ich eine PHP 5er Version aktiviert hatte. Nur welche das ist, sagt mir die freundliche Strato-Meldung nicht.

Suchen und Finden

Mit meinem Basiswissen Unix/Linux sollte das aber kein Problem sein, zumal es bei meinem Paket auch ein SSH-Login gibt.
Also einfach per SSH im Paket anmelden und mit „grep -r …“ den Übeltäter aufspüren. Denkste. Bei SunOS/Solaris, das auf den Webservern bei Strato läuft, gibt es kein rekursives grep.

Aber es gibt ja das Internet und so habe ich schnell die passende Kombination aus find und grep gefunden:

find . -type f -name ".htaccess" -exec grep -l "application/x-httpd-php5" {} +

Und tatsächlich habe ich drei .htaccess-Dateien mit einer alten PHP5-Konfiguration gefunden.

Strato-Webhosting: ssh

In zwei Fällen war die Zeile

# AddType application/x-httpd-php5 .php

auskommentiert, also nicht mehr aktiv. Nur beim Test-Projekt /neueseite/test/ war der Eintrag „aktiv“, allerdings war die Installation nicht mehr mit einer Domain/Subdomain verknüpft und somit nicht aufrufbar.

Die beiden Ordner /schnurpsel_29/ und /neueseite/test/ habe ich einfach komplett entsorgt und bei der Gelegenheit auch sonst noch ein wenig im Webspace aufgeräumt.

Das ist mit „rm -r …“ in NullKommaNix erledigt, viel schneller als beim rekursiven Löschen per FTP.
Allerdings sollt man sich sicher sein, was man tut, denn „rm -r“ haut ohne Nachfrage alles weg. Und weg ist weg. :-)

Ein Kommentar »

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 »

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 »