Markus Baersch

Analytics · Beratung · Lösungen

Start » Blog » IT / Usability

10.11.2014

Gleich vorab: Ich bin kein Gegener von SSL. Überhaupt nicht. Aber es scheint mir, als würden derzeit zahlreiche Websites aus völlig falschen Gründen auf den SSL-Zug aufspringen... um sich dabei nicht selten derb selbst ins Knie zu schießen. Daher sollen hier nicht die zahlreichen Argumente für einen Umstieg auf https statt http aufgezählt werden, die ich gar nicht anzweifeln will, sondern ein paar m. E. wichtige Punkte zur Sprache kommen, die vor einer Umstellung bedacht, abgewägt und vor allem vorher geprüft werden sollten. Und wenn es nur ein paar böse Überraschungen vermeiden hilft 😉

Umstellung aus den falschen Gründen?

Der Grund für das stark angestiegene Interesse liegt oft in der Hoffnung auf bessere Rankings bei Google. Wie diese Hoffnung aufgekommen ist, soll hier nicht interessieren (und ist den meisten der wenigen Leser dieses Blogs ohnehin bestens bekannt), aber es gibt m. E. für 99,99% der Webmaster, die sich gerade aus SEO-Gründen mit SSL befassen, mindestens 100 andere Baustellen, an denen mit dem gleichen Aufwand viel mehr Effekt zu erzielen ist, wenn es um Rankings geht.

Nur weil das Thema gerade durch die SEO-Blogs geht und die großen Hoster ihre Kunden zusätzlich mit Dingen wie "Umstellung mit wenigen Klicks" - natürlich erst einmal auch noch kostenlos - locken, ist das noch lange kein Anlass zum Handeln, ohne sich zuvor über Gegenargumente bzw. potentielle Probleme Gedanken gemacht zu haben.

SSL Werbung bei 1und1
Beispiel 1&1: "Wenige Klicks". Jaja. Und dann geht der Spaß los...

Viele der Hindernisse sind technischer Natur. Das ist nicht für jeden Webmaster gleich abschreckend, bedeutet aber auf jeden Fall, dass diese gelöst werden müssen, wenn die Site nach einer Umstellung noch genau so funktionieren soll wie vorher. Hier sind ein paar Denkanstöße:

Die "Miesmacherliste" zur SSL-Umstellung

  1. Anpassung der Inhalte: Alle Verweise auf Bilder, Videos, Ressourcen in iFrames (bis hin zur eingebundenen Werbung etc.) müssen ggf. angepasst werden, wenn diese direkt auf eine http-Variante auf der eigenen Domain zugreifen. Oder eben auch auf einer anderen Domain... hoffentlich gibt es dort dann auch SSL. Ohne eine Anpassung drohen je nach Browser fehlende Bilder bzw. Ressourcen (was durchaus auch die Bedienbarkeit der Site beeinträchtigen kann!) oder zumindest unterschiedlich aufdringliche Warnhinweise beim Verschlüsselungssymbol bzw. sogar Warndialoge. Wer das in seinem Browser nach der Umstellung nicht sieht, mag sich sicher fühlen... ist es aber nicht! Beispiele gefällig?
    SSL Probleme

    Die nachträgliche Anpassung von Content ist also zwingend erforderlich, aber nicht immer einfach. Je nach Umfang mag sich der Aufwand in Grenzen halten oder ist vielleicht mit ein wenig "Suchen und Erstzen" erledigt. Komplexere / umfangreichere Websites und deren Content Management Systeme erfordern hier aber deutlich mehr als nur den einen Klick, den man beim Hoster zu erledigen hat! Wo Inhalte in einer Datenbank umgestellt werden müssen, braucht es nicht nur die erforderlichen Möglichkeiten zum Zugriff und entsprechendes Spezialwissen - es muss auch Backups und vernünftige Tests vor einer Umstellung im Livebetrieb geben. Hier steckt folgerichtig oft der größte Brocken an Arbeit. Wer diese erst beim Erwachen nach der Umstellung angeht, wird es mit Hektik kaum sorgfältig genug hinbekommen, auf Backups verzichten und sich ernsthafte Probleme einhandeln. Externe Kosten sind hier für viele Websitebetreiber nicht nur unvermeidbar, sondern im Vorfeld auch schlecht anzuschätzen.

  2. Ressourcen: Wie sieht es mit im CSS referenzierten Hintergrundbildern aus... oder @import-Anweisungen? Wenn CSS kein Problem ist, folgen spätestens bei internen - und vor allem externen - JavaScript-Dateien schnell ernsthafte Hürden für Webmaster, die nicht zufällig die entsprechenden Kenntnisse zur Analyse und Korrektur selbst mitbringen. Siehe oben: weitere Kosten drohen.
  3. Content Management System: Idealerweise geht alles einfach glatt. Das wird bei gängigen Systemen auch der Fall sein und höchstens ein paar Anpassungen in der Konfiguration erfordern, die sich sogar für "Laienadmins" ergoogeln lassen. Bei alten Systemen oder Exoten (ich betreibe mit meinem Blog selbst so ein Urvieh) sind Verweise im System inkl. "http://" statt nur "//" aber mitunter "sehr sehr hart" codiert. Kann man dann wirklich alles ändern (wieder: Die Kenntnisse und den Zugriff vorausgesetzt)? Was ist denn, wenn die Problemstellen nicht im Quelltext vorliegen, sondern in einer .NET oder ISAPI DLL oder noch gruseligeren Dingen auf dem Server vorliegen? Und überhaupt: Was ist bei einer Anpassung in Eigenregie, wenn es dann doch irgendwann Updates des Systems gibt?
  4. Templates: Je nach System kann die erforderliche Anpassung in den Themes bzw. Templates des CMS selbst HTML-feste Webmaster überfordern. PHP, Smarty oder gar proprietäre Lösungen mögen für "Nichtkenner" zu kryptisch für Selbsthife ausfallen. Schwupps, wieder Geld an den nächsten Profi ausgegeben, der das passende Spezialwissen mitbringt.
  5. Fremdcode / Erweiterungen: Weil fast alle Systeme mit AddOns, PlugIns, Modulen oder unter anderen abstrusen Bezeichnungen erweiterbar sind, ist das einen eigenen Punkt auf der Checkliste wert. Denn diese stammen oft aus fremder Feder und entziehen sich vielleicht sogar einer Analyse (und ggf. erforderlicher Korrektur). Auf jeden Fall erfordern solche Kandidaten einen Testlauf, der wieder mal Aufwand und / oder Kosten mit sich bringt.
  6. Rankings werden vermutlich nicht steigen: Alle vermuteten Rankingvorteile sind derzeit eher "hypothetisch" und wie oben beschrieben gibt es meistens Besseres zu tun. Selbst John Mu sagt, dass er sich den ganzen Kram selbst nicht antun würde... wenn das primäre Ziel nicht Sicherheit ist, sondern damit bessere Rankings erreicht werden sollen.
  7. Rankings können sogar leiden: Es sind sogar Rankingverluste statt einer Steigerung möglich - oder zumindest unnötige Probleme für Google & Co. Diese können durch Doubletten entstehen, die auf fehlende oder falsche Weiterleitungen auf die https-Variante zurückzuführen sind. Mit korrekten Weiterleitungen bleibt immer noch zu bedenken, dass eingehende Links i. d. R. nicht auf die https-Variante gehen. Man mag fragen: Wie viel geht ggf. durch die 301-Weiterleitungen auf https-Fassungen verloren und macht das zunichte, was mit dem angeblichen Rankingboost(chen) gewonnen wird? Auch steckt ein gewisses Risiko in vergessenen "Kleinigkeiten" wie Weiterleitungen auf nicht-SSL-Varianten in der eigenen .htaccess oder im System. Oder in auf einmal giftigen Canonicals mit http statt https. Und so weiter 😉
  8. Kosten des Zertifikats: Auch wenn in anderen Punkten schon reichlich Kosten angesprochen wurden, sind auch die Kosten einzurechnen, die das Zertifikat betreffen. Ein "ordentliches" (AKA eigenes und vertrauenswürdiges) Zertifikat kostet Geld. Was ist, wenn billige Wildcard-Zertifikate oder kostenlose Zertifikate von CloudFlare & Co. übermorgen einen Rankingnachteil statt eines Rankingboosts bedeuten? Vielleicht sind Billigzertifikate die Artikelverzeichnisse von morgen... wer weiß das schon?
  9. Nicht jede Site braucht SSL: Oft ist die Umstellung schlichtweg unnötig. Auf vielen Sites gibt es streng genommen außer dem Besucherverhalten, das ohnehin über zahlreiche Systeme aufgezeichnet wird (s.u.) und der IP nichts an potentiell schützenswerten Informationen, die bei der Benutzung der Site anfallen und auf dem Transportweg gefährdet sind. Selbst in Shops ist jenseits des Checkouts - heute noch - ein Verzicht auf SSL nicht unüblich. Außerdem werden Informationen wie Verhalten und IP durch SSL nicht wirklich "sicherer", solange diese durch eingebundene "Mithörer" wie SocialMedia-Plugins, Webanalysesysteme u. Ä. gespeichert und ggf. vom Systemanbieter oder auch Dritten aktiv genutzt werden.
  10. Falsche Sicherheit: Wer im einem Shop, Portal oder der Landingpage mit neugierigem Formular die Eingaben seiner Besucher und deren Übertragung zum eigenen Server schützen will, ist mit SSL gut beraten. Spätestens seit Firesheep ist das auch beim "informierten Verbraucher" angekommen. Außerdem mag sich der Hinweis auf verschlüsselte Übertragung sogar positiv auf die Abschlussrate auswirken (muss es aber nicht unbedingt, nur weil das in CaseStudies so steht!). Dass mit SSL aber die gespeicherten Daten noch lange nicht sicher sind, scheint nicht allen klar zu sein und so sind oft dahinter immer noch hochgradig unsichere Backendsysteme im Einsatz. So wird SSL zum Tropfen auf den heißen Stein und verhindert in keiner Weise automatisierte oder gar gezielte Versuche, an die sensiblen Daten zu gelangen. Wer seinen Shop wirklich sicher machen will, darf nicht beim SSL-Zertifikat aufhören, sondern muss sich um Verringerung der Angriffsfläche des Servers sowie Aktualität und Absicherung des Backends einschließlich der Datenbank kümmern.
  11. Performance: PageSpeed ist längst ein "akzeptierter" Rankingfaktor. Spätestens auf dem Umweg der Nutzersignale wird sich heute jeder SEO Gedanken um die Optimierung von Ladezeiten machen. Selbst wenn es für Suchmaschinen egal wäre: Besucher nehmen je nach Site selbst geringe Veränderungen wahr, was an veränderten Konversionsraten sogar in Experimenten nachweisbar ist. Durch SSL wird die Ladezeit aber messbar größer. Dazu gibt es hier einen kleinen "Videobeweis" 😉

SSL vs. Non-SSL im Ladezeitenvergleich

Ich habe mir den Spaß gegönnt und anhand meiner eigenen und sehr überschaubaren Website die Umstellung auf SSL durchgespielt. Da ich dies aber hauptsächlich deshalb angegangen bin, um Erfahrungen für größere Projekte zu sammeln und meine Website m. E. kein SSL braucht, habe ich diese Variante wieder deaktiviert. Nicht zuletzt wegen der unvermeidlichen Einbußen in den Ladezeiten.

Das "Test-Setup"

Beim Selbsversuch sind mir auch dank meines Blogs ein paar der o. a. eher exotischen Hindernisse in den Sinn (und in den Weg) gekommen. Zumindest für den Rest der Domain war die Umstellung aber mit vertretbarem Aufwand in ein paar Stunden erledigt. Das Zertifikat stammt von CloudFlare; ist also nicht auf meinem eigenen Server installiert. Das dürfte aber allein schon dank der Tatsache, dass CloudFlare als CDN genutzt wird und der Content so aus der gleichen Quelle wie das Zertifikat stammt, kaum störend ins Gewicht fallen.

Ergebnisse

Tests habe ich mit verschiedenen Services wie pingdom.com, pagespeed.de, gtmetrix.com und ein paar anderen gemacht und (bedingt durch die unterschiedlichen Standorte) eine relativ breite Streuung in den Ladezeiten gesehen. In allen Fällen aber waren die https-Fassungen der Seiten (ich habe nicht nur die Startseite getestet, sondern auch "ressourcenreichere" Inhalte) langsamer als die Versionen mit http. Mal mehr, mal weniger - aber stets langsamer.

Natürlich kann man diesen "Test" mit nur einem Kandidaten an einem einzelnen Tag und mit zufällig (bzw. vom jeweiligen Tool abhängigen) Rahmenbedinungen belächeln bzw. zumindest zurecht dessen Signifikanz anzweifeln. Totzdem finde ich das folgende Video der Ergebnisse von WebPageTest.org sehr anschaulich. Deshalb mag ich diese Präsentationsform auch viel lieber als alle Diagramme 😉 Datanerds mögen sich nun aber Tabellen und Wasserfalldiagramme wünschen - z. B. hier finden sich welche.

Ladezeitenvergleich mit und ohne SSL als Video

Um zu zeigen, dass die reinen Zahlen egal sind, im Ergebnis aber mit SSL stets langsamer ist als ohne, habe ich den Test dort einfach noch einmal wiederholt und dabei beide Varianten zweimal eingetragen, so dass vier - recht unterschiedliche - Ladezeiten herauskommen. Es bleibt aber dabei, dass https immer langsamer ist als http.

Wiederholter Ladezeitenvergleich als Video

Fazit? Empfehlung?

Eine Umstellung ist angesichts dieser Punkte für viele Betreiber möglicherweise wirtschaftlich betrachtet tatsächlich unsinnig. Oder zumindest unnötig. Der Eingriff geht jedenfalls im Regelfall sehr viel tiefer, als es zunächst klingen mag. Daher sollte man sich erstens aus gutem Grund (SEO als Hauptargument lasse ich nach aktuellem Stand nicht gelten) und zweitens entsprechend vorbereitet damit auseinandersetzen. Zu einer guten Vorbereitung ist umfängliches testen unabdingbar; vorher und nachher. Wer noch einen Plan B bei sich zeigenden Einbußen in Sichtbarkeit und Traffic zur Hand hat, sollte sich aber nicht aufhalten lassen. Viel Spaß 😉

Hat Dir der Beitrag geholfen?

Dann freue ich mich, wenn Du ihn mit anderen teilst! Wenn Du magst, gib einen aus ;)

© 2001 - 2024 Markus Baersch