Profi Hosting für WordPress

WordPress ist das meist genutzte Website CMS auf der Welt. Damit die mit WordPress erstellte Website für den Betreiber und für die Besucher eines gutes Erlebnis wird, insbesondere bei vielen Nutzern/Besuchern, stellt sich zwangsläufig die Frage nach dem Hosting.

In vielen Fällen wird WordPress beim (billig) Hoster über eine 1-Click Anwendung im Kundenbereich auf ein nicht näher spezifizierten Webspace eingerichtet. Der Nutzer muss ein bisschen warten und dann kann er sich in das Backend einloggen und seine Website konfigurieren und bearbeiten.

Ein solches Szenario ist im Unternehmenskunden Umfeld eher seltener. Denn ein Unternehmenskunde möchte wissen was er kauft und was es taugt. Daher wenden sich Unternehmen auch häufig an Agenturen und Spezialisten, die auch in der Lage sind, individuelle Setups aufzusetzen und zu betreiben.

Hostingtyp und Performance

Die Schnelligkeit einer Website, sprich die Ladezeit beim Aufruf von Seiten und bei verschiedenen Klicks hängt natürlich nicht nur von der darunterliegenden Performance (RAM, CPU, Speicher). Techniken wie Caching, Datenkompression, Minifying beispielsweise haben einen großen Einfluss auf die Ladezeit, die Ressourcennutzung und somit auf die Anzahl Nutzer die gleichzeitig die Website besuchen können. Da diese Techniken mehr oder minder von der Hosting-Infrastruktur unabhängig sind, vergleichen wir hier nur die Hostingtypen.

Shared WordPress Hosting

Traditionell besteht das Shared Hosting nur aus einem Webserver (oft old school Apache) und es werden möglichst viele Websites darauf betrieben. Die Websites teilen sich die Ressourcen. Es ist zwar möglich die maximale RAM Nutzung zu bestimmen aber eine Garantie den RAM auch nutzen zu können gibt es nicht - die anderen Websites sind gleichberechtigte Partner und alle versuchen, sich die Ressourcen zu nehmen, die sie brauchen und maximal nutzen dürfen.

Solche Plattformen sind für anspruchsvolle Setups mit vielen Besuchern/Nutzern nicht wirklich geeignet.

Dedicated WordPress Hosting

Für anspruchsvollere WordPress Websites kann man auch eine eigene virtuelle Maschine (VM) nutzen, die mit keinen anderen Websites geteilt wird. So stehen die Ressourcen wirklich dediziert für die WordPress Instanz zur Verfügung. Entsprechend wird eine leistungsstarke VM  für viele Fälle in denen es darauf ankommt, viele HTTP Anfragen zu bearbeiten, die passende Lösung sein.

Verfügbarkeit

Verfügbarkeit ist nicht nur ein Marketing-Wert. Mit einer professionellen Infrastruktur (in einem zertifizierten Datacenter) mit nachweislichen Maßnahmen zur Vermeidung von Ausfällen wie z. B. Redundanz von Netzwerkverbindungen, Servern und RAID-Systemen lässt sich die Verfügbarkeit durchaus verlässlich interpretieren. Außerdem werden in solchen Fällen meist auch Service Level Agreements vereinbart, die nicht vorgesehene Incidents regeln.

Alle Dienste auf einer VM

Wenn ein Webserver, die Datenbank und die Daten allesamt auf einem (virtuellen) Server laufen, hat man ein tendenziell performantes Setup. Wenn aber die darunterliegende Hardware kaputt geht, geht gar nichts mehr. Dann muss ein Backup auf einem neuen Server eingespielt werden (und die IP muss ggf. zum neuen umgeroutet werden).

Web, Datenbank und Daten auf separaten Servern

Damit ein physikalischer Ausfall nicht gleich alle Dienste (Webserver, Datenbankserver, Daten) trifft und einen Totalausfall mit sich bringt, kann man die Dienste getrennt von einander betreiben.

Sie können Daten auf einem NAS ablegen, das auf einer anderen Hardware liegt. Wenn also die VM ausfällt, kann eine neue aufgesetzt werden, die Daten müssen aber nicht erst kopiert werden, die Datenpartition wird einfach (z. B. per NFS) eingebunden. Dasselbe kann mit dem Datenbank-Server gemacht werden.

So haben wir 3 Server für unsere WordPress Anwendung. Das klingt zunächst nicht schlecht, aber so toll ist es auch nicht, denn ein einzelner Server-Ausfall wird nicht abgefangen. Fällt die Datenbank aus oder die Datenpartition, ist die WordPress Website down. Es wird also geboten, für Redundanz der einzelnen Komponenten zu sorgen.

Multi Server WordPress Hosting von SaaS Web

Erklärungen zu dem Multi Server Setup

Im SaaS Web Hosting Portfolio gab es bislang entweder Private Cloud Shared Hosting oder Private Cloud single VM Hosting. Damit lassen sich Websites mit vielen Besuchern, großem Ressourcen Verbrauch und hoher Verfügbarkeit nicht ganz so gut abbilden. Das Public Cloud Multi Server Setup ist nun die Antwort auf solche Anforderungen. Es lässt sich übrigens auch in der SaaS Web Private Cloud einrichten...

Parallel laufende Webserver

Der Webserver wird redundant betrieben: es laufen parallel zwei oder mehr Server (mit Nginx). Sie greifen alle auf dieselbe NFS Datenpartition zu.

Cloud NAS

Die Cloud NAS ist ein redundantes NFS Server-System, das sich ein Festplatten-Pool (RAID) teilt, sodass ein einzelner NFS-Server Ausfall abgefangen werden kann.

Galera Cluster

Die Datenbank Server werden als Galera Cluster (mindestens 3 Server) zusammengeschaltet. Selbst wenn 2 Server ausfallen geht der Anwendung das Licht nicht aus. Das Cluster wird als Reverse Proxy (localhost) zu der WordPress Installation eingebunden - so muss WordPress nicht selbst entscheiden, welchen Server für die DB Verbindung benötigt wird.

Master/Slave Load Balancer

Damit die Webserver parallel betrieben werden können, benötigt das Setup einen Load Balancer, der die eingehenden HTTP-Anfragen an die Webserver verteilt. Um einen Load Balancer Ausfall zu verkraften, bekommt dieser auch einen Zwillingsbruder.

Failover IP

Mit der Failover IP kann die öffentliche IP (die mit der Website Domain matcht) dynamisch zwischen den Load Balancer wechseln. Das geschieht automatisch: wenn der Slave Load Balancer merkt, dass der Master ausgefallen ist, beantragt er die Zuweisung der IP.

Hier geht es zu den SaaS Web Managed WordPress Hosting Angeboten.

WordPress Management mit WP Steve

Unabhängig vom Hosting ist das Management der WordPress Instanz besonders wichtig. WordPress sollte stets up to date sein genauso wie das Theme und die installierten Plugins. SaaS Web hat hierfür eine WordPress Management Anwendung entwickelt mit der alle gehosteten Websites zentral verwaltet werden können. Standardmäßig werden 1x am Tag und bei jedem Update-Vorgang ein Backup der WordPress-Installation  durchgeführt.

Ladegeschwindigkeit der Website mit webpagetest.org testen

Immer mehr Speed

Das Thema Ladegeschwindigkeit ist kein Neues: schon zu Beginn des Webs war die Ladezeit ein wichtiger Faktor für den Erfolg einer Website - die Bandbreite der Internetanschlüsse war so gering - erinnern wir uns: 57k Modems waren vor 20 Jahren oftmals das Höchste der Gefühle; heute sind 50 MBit Anschlüsse keine Seltenheit mehr -, dass bereits ein paar hundert Kilobyte die Obergrenze für eine Seite war, bei der eine anständige Ladezeit möglich war.

Mit steigender Bandbreite hat sich die Lage im Bereich Desktop Computer zumindest theoretisch einigermaßen entspannt. Die immer größere Nutzung von mobilen Endgeräten und immer größerer Bildschirme mit hoher Auflösung (damals, vor 20 Jahren, z. B. 19" mit 1.200 x 800 Pixel, heute, z. B. 27" mit 2.560 x 1.440 Pixel) versetzt die Website Betreiber in eine ähnliche Lage wie vor zwanzig Jahren - es ist ein bisschen dasselbe Problem wie das Smartphone-Akku Problem: Akkus werden immer leistungsfähiger, aber die Geräte verbrauchen immer mehr Strom.

Ladegeschwindigkeit als Ranking-Faktor

Heute bekommt die Ladezeit eine neue Dimension: Suchmaschinen, allen voran Google, integrieren die Ladezeit in die Berechnung des Indexes. Vereinfacht gesagt: Je langsamer eine Website lädt, umso weiter hinten wird sie in Suchergebnissen angezeigt. Spätestens seit diesem Zeitpunkt ist das Thema bei professionellen Website Betreibern angekommen und ein regelrechtes Wettrennen hat begonnen.

Faktoren, die die Ladezeit beeinflussen

Es gibt mehrere Ebenen auf denen sich Optimierungen bemerkbar machen können. Einerseits die mit der Verbindung an sich zu tun haben, bzw. mit der "Power" - im Autovergleich: die Anzahl PS, ob das Auto aerodynamisch ist, wie viel es wiegt... Andererseits ob eine Website gut gebaut ist, unnötige Ladevorgänge von Elementen verhindert - im Autovergleich: der Fahrer; fährt er denn optimal, kennt er die Strecke oder muss er an allen Ampeln stehen bleiben? Es gibt sicher bessere Vergleiche als die mit dem Auto 😉 Jedenfalls werden die 2 Ebenen in den folgenden Absätzen genauer erklärt.

Hosting-Ebene: Infrastruktur, Webserver, Caching

  • Infrastruktur: generell spielt es eine Rolle ob die Website auf einem Shared Hosting Server oder einem dedicated Server betrieben wird. Die Geschwindigkeit beginnt bereits bei der Internet-Anbindung des Rechenzentrums und wie die Router des Anbieters die verschiedenen Server verbindet. Daraus resultiert nicht nur die Geschwindigkeit sondern auch der sogenannte Time to first Byte, eine Messgröße für die Zeit, die benötigt wird bis der erste Byte vom Server beim Client ankommt.
  • Web Server: der Webserver spielt ebenfalls eine Rolle in der Optimierung. Ganz allgemein sind Webserver mit Nginx schneller als Apache - das muss nicht unbedingt so sein, mit etwas Konfigurationsarbeit kann auch Apache fliegen. Aber nicht nur der Wechsel der Software bringt Geschwindigkeit. Auch Einstellungen wie Keep-Alive führen dazu, dass die Verbindung zum Webserver nicht nach jedem Request neu verhandelt werden muss.
  • Caching ist ein komplexes Thema, da es auf vielen Ebenen Caching gibt (CDN, HTTP Reverse Proxy wie Varnish Cache, local Cache, Datenbank Cache wie memcached oder Redis, ...). Caching gehört zu den effektivsten Optionen, um die Ladezeit zu verkürzen, je nach dem wie es eingesetzt wird. Es sei angemerkt, dass nicht immer alles gecacht werden kann - Seiten mit hoher Änderungsfrequenz wie z. B. Nachrichtenportale möchten, dass Besucher immer die neuesten Artikel zu sehen bekommen.

Website-Ebene: HTML/JS/CSS, Media-Elemente

  • Eine korrekte Seitenstruktur spielt eine große Rolle - wir reden gar nicht von kaputtem HTML. Die HTML-Struktur eines Dokuments sollte immer nur so schlank sein wie nötig und bizarre Verschachtelungen sollten möglichst vermieden werden. Entsprechend, wenn nicht zwingend notwendig, sollten Elemente nicht erst per Javascript eingefügt werden.
  • Media-Elemente, sprich Bilder sollten stets für das Endgerät optimiert sein - ein großes Bild für Desktop sollte in einer entsprechend kleineren Version auf einem Smartphone geladen werden.

Online Geschwindigkeitscheck mit www.webpagetest.org

Das kostenlose Projekt webpagetest.org ermöglicht für jeden die Ladezeit seiner (öffentlich zugänglichen) Website zu messen und zu analysieren.

So einfach geht's

Um eine Analyse der Website zu starten braucht man nur:

  • URL: Die Website URL eingeben, am Besten inklusive https und www, sonst wird die ggf. vorhandene Umleitung mit in die Ladezeit aufgenommen
  • Location: von wo soll denn gemessen werden? Tatsächlich spielt die geografische Lage auch eine Rolle - wobei webpagetest.org auch diesen Faktor in den Ergebnissen berücksichtigt und einen Korrekturfaktor implementiert.
  • Browser: es kann durchaus eine Rolle spielen welcher Browser getestet wird. Es lassen sich übrigens je nach Anbieter und Location auch mobile Browser auswählen
  • Anzahl Tests: es wird empfohlen mehrere Tests auszuführen um einen aussagekräftigeren Mittelwert zu erhalten
  • Repeat View: hier handelt es sich um die Ladezeit, wenn ein Client (Browser) wiederholt eine Seite lädt und ggf. Caching Effekte besser bemerkbar sein sollten - es wird empfohlen first view and repeat view auszuwählen

Übersicht des Ergebnisses

Für die schnelle Beurteilung des Ergebnisses dienen die 6 Indikatoren (A bis F - A ist die Bestnote).

Hier in kürze die Bedeutung der 6 Punkte:

  1. First Byte Time: Dauer für den Empfang des ersten Bytes des Webservers. Dieser Wert lässt sich nicht wirklich verändern. Der Wert ist abhängig von der physikalischen Hosting-Umgebung (Rechenzentrum, Server) und der momentanen Auslastung der Systeme.
  2. Keep-alive enabled: Option des Webservers, die bewirkt, dass die Verbindung zwischen Server und Browser offen bleibt und somit vermieden wird, dass jedes Mal der TCP-Handshake neu ausgehandelt werden soll. Eine Webseite hat oftmals 100 oder mehr Elemente, die geladen werden sollen - da kann eine vermeintlich kleine Optimierung schon mal was bewirken.
  3. Compress transfer: ebenfalls eine Webserver-Einstellung. Der Webserver kann die Daten komprimiert übertragen, sodass weniger Daten übertragen werden brauchen. Moderne Browser können inzwischen alle mit komprimierten Datenübertragung umgehen.
  4. Compress images: hier sind die Website-Betreiber gefragt. Der Indikator zeigt wie gut die Bilder, die geladen werden, komprimiert sind. Lässt sich die Größe (ohne Qualitätsverlust) verringern?
  5. Cache static content: kommen die angezeigten Elemente vom Cache oder wurden diese frisch vom Webserver ausgegeben?
  6. Effective use of CDN: werden die Inhalte von einem CDN (Content Delivery Network) ausgegeben?

Performance Results

In der oberen Tabelle sind weitere Werte abzulesen, die als Ergebnis des Geschwindigkeitstests zu verstehen sind. Hier wird die Geschwindigkeit der Anzeige der Website in einzelne Stufen unterteilt, um besser nachzuvollziehen, wo die Ladezeiten entstehen.

  • Load Time: die Zeit entspricht der Ladezeit der Website. Die Fully Loaded Zeit hingegen misst noch alle Aktivitäten bis zu 2 Sekunden nach der Load Time, also Elemente, die beispielsweise per Javascript nachgeladen werden.
  • First Byte (TTFB): die Zeit, die für den ersten Byte vom Server zum Browser benötigt, wenn die Website erstmals aufgerufen wird.
  • Start Render: Zeit, die der Browser benötigt, um mit der Anzeige der Website zu beginnen.
  • Speed Index: der Speed-Index ist ein Wert, um die gemessene Geschwindigkeit zu bewerten. Je kleiner dieser Wert ist, umso besser. Hier gibt es ausführliche Informationen wie dieser Index errechnet wird: https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index

Details - Wasserfall Diagramm

Im Wasserfall-Diagramm lässt sich sehr schnell erkennen wie viele Requests das Laden der Seite erzeugt und wie schnell die einzelnen Requests beantwortet werden. Anhand der Farbcodes lassen sich die Requests auch einstufen, ob DNS Anfrage, HTML/Text, Javascript/Text, Bilddaten oder andere Inhaltstypen geladen werden.

Content Breakdown

Der Bereich "Content Breakdown" ist besonders interessant um die Verhältnisse von Text, CSS, Javascript und Bilder zu sehen. So lässt sich auch besser entscheiden wo der größere Hebel ist, wenn es darum geht Prioritäten für die Optimierung festzulegen.

Bildanalyse

Der relativ neue Punkt "Image Analysis" bietet die Analyse der Bilddateien. Der Dienst prüft jedes einzelne Bild, bewertet die Kompression und benotet diese auch (A-F). Es ist dort auch möglich, den Cloud-Dienst kostenpflichtig in Anspruch zu nehmen, jedoch keine Pflicht. Die Optimierungen, falls welche sinnvoll möglich sind, können Sie selbst durchführen - es gibt dafür zahlreiche Bildbearbeitungsprogramme, die dafür genutzt werden können. Es gibt auch ein Artikel in diesem Blog zum Thema Bildoptimierung.

Ein professionelles Tool für null Euro

Webpagetest.org ist ein ausgereiftes Projekt mit dem die Optimierung von Websites wirklich gut vorangetrieben werden kann. Besonders nett ist, dass das Projekt völlig kostenfrei nutzbar ist und auch keine Registrierung erfordert. Hin und wieder müssen Sie etwas warten bis die Analyse-Anfrage durchgeführt wird - schließlich sind Sie nicht die einzige Person, die diesen Dienst in Anspruch nehmen.

WordPress Meetup Karlsruhe #7 am 16. Dezember bei SaaS Web

Dieses Mal findet das WordPress Meetup bei SaaS Web statt – die Karlsruher WordPress Gemeinde wird sich an einer neuen Location zusammen finden und feierlich Abschied vom Jahr 2015 nehmen bzw. die Weihnachtszeit einstimmen.

Für das letzte Meetup dieses Jahres werden 4 Vorträge gehalten:

  • Typografie im Web von Monique Koepke (Miss Koepke)
  • Speedup your WordPress mit Nginx und HTTP/2 von Martin Wolfert (1und1)
  • Speedup your site mit Caching von Daniel Jagszent (SaaS Web)
  • Einführung ins WP REST API von Martin Sotirov (Evil Ninja)

Natürlich wird es wie gehabt leckere Pizza aus der Pizzeria „Pizza & Gusto“ in der Burgerstraße geben und verschiedene Getränke zur freien Verfügung. Zum Abklang bieten wir wie immer ein leckeres Cocktail.

Hier geht es zur Anmeldung:

http://www.meetup.com/de/WordPress-Meetup-Karlsruhe/events/227158235/

Hier geht zu den Event-Details auf der Meetup-Website:

http://wpmeetup-karlsruhe.de/tribe-events/wordpress-meetup-karlsruhe-7/

Aktuell zählt die Meetup.com Gruppe 99 Mitglieder – 1 fehlt 🙂

Nginx nimmt fahrt auf, Apache nimmt ab

Die letzte Statistik von Netcraft zu der Verbreitung der Webserver zeigt gut wie beliebt Nginx im professionellen Umfeld ist. Das Wachstum von Nginx entspricht ungefähr der Abnahme von Apache – es erscheint durchaus plausibel, dass das Wachstum aus Wechslern besteht.

netcraft-webserver-apr2014

Hier noch der Link zu den 100 busiest Sites: http://toolbar.netcraft.com/stats/topsites

Webserver NginX überholt Microsoft IIS in der November Netcraft Survey

Endlich ist es soweit, Nginx überholt Microsoft IIS in der weltweiten Statistik (Netcraft November 2012). Microsoft IIS Webserver fällt auf 11,53% und Aufsteiger Nginx klettert auf 11,78% Marktanteil. Apache bleibt unangefochten die absolute Nummer 1 mit 55,66%.

Apache Webserver rules, Nginx rocks

Eine kürzlich veröffentlichte Statistik von Netcraft bescheinigt Apache den absoluten Spitzenplatz bei den Webservern weltweit. Mit knapp 58% im Januar 2012 ist er mehr als 4mal so verbreitet als die Nummer zwei der Liste.

Nginx, ein weiterer Open Source Webserver (BSD Lizenz), hat nach dieser aktuellen Studie gerade Microsoft IIS überholt und ist mit 12,18% (MS IIS 12,14%) Marktanteil auf Platz 2.

Es ist allerdings zu bemerken, dass die Anzahl Webserver mit Apache schlagartig im Mai-Juni 2011 zunimmt (fast eine Verdoppelung). Dieser „Sprung“ lässt sich wahrscheinlich nicht (nur) mit einer spontanen Zunahme an Apache-Webservern erklären. Vermutlich ist eine veränderte Messmethode der Grund..? Jedenfalls wäre der Vorsprung immernoch doppelt so hoch, wenn die Zunahme „linear“ verlaufen würde. Immer noch beachtlich!