Archiv des Autors: Heiko Mamerow

Über Heiko Mamerow

Buddhist, Vater, Freund, Internetseitenbauer, Sportler, Musikliebhaber & Verkehrsteilnehmer ;-)

WordPress Datenbank umziehen mit der Kommandozeile

Irgendwann trifft es alle einmal: Die Website muss umziehen. Vielleicht weil der Provider gewechselt werden soll oder weil ein Klon auf der lokalen Entwicklungsumgebung benötigt wird. Grundsätzlich lässt sich der Umzug a) mit Plugins oder b) mit der Kommandozeile erledigen.

In diesem Tutorial möchte ich den Umzug mit der Kommandozeile zeigen. Doch erst einmal möchte ich auf die Frage eingehen:

Warum überhaupt ein Umzug mit der Kommandozeile?

Die meisten entscheiden sich wahrscheinlich eher für ein Plugin. Jedenfalls gibt es schier unzählige Tutorials bei denen beschreiben wird, wie eine Website mit Hilfe eine Plugins umgezogen wird. Dagegen finden sich kaum Infos über den Umzug mit der Kommandozeile.

Die Umzugs-Plugins kommen der gewohnten Arbeitsweise entgegen. Sie sind schnell installiert und können zum Teil sogar von technisch eher unversierten Leuten verwendet werden. Es gibt ein Formular, wo die Umzugsdaten eingetragen werden. Ein Knopfdruck und ab geht die Post.
In einer idealen Welt…

In der Realität kann so ein Umzug mit einem Plugin sehr ernüchternd sein. Wer es nicht glaubt, schaue mal in die Supportforen von solchen Plugins. ;-)

Mein Argument für den Umzug mit der Kommandozeile ist Zuverlässigkeit. Ich hatte leider in der Vergangenheit viele Probleme beim Umzug von größeren WordPress-Datenbanken (>mehrere hundert MB groß) auf eng beschnittenen Webservern (v.a. wegen kurzer Laufzeiten von Scripten) Auf der Suche nach einer verlässlichen Alternative bin ich schließlich auf die Kommandozeile gestoßen. Seit zwei Jahren arbeite ich auf diese Weise. Ich transferiere fast täglich Datenbanken von meiner lokalen Entwicklungsumgebung zum Liveserver bei den Kunden und umgekehrt. Seit ich den Weg über die Kommandozeile nehme, ist mir beim Umzug noch nie ein Problem aufgetreten!

Darüber hinaus ist die Kommandozeile ein sehr mächtiges und nützliches Tool für das täglichen Arbeiten auf dem Rechner. Dazu vielleicht später mal mehr in einem anderen Beitrag.

Deine Kommandozeile, das unbekannte Wesen

Die Kommandozeile – aka Terminal aka Konsole aka Befehlszeile aka CLI – ist auf jedem Betriebssystem zu finden. Aber genutzt wird sie wahrscheinlich nur von einer Minderheit. Es gibt sehr viele Vorbehalte selbst bei gestandenen Entwicklern und Entwicklerinnen.

Kommandozeile

Die Kommandozeile: nur ein unscheinbares Fenster mit einem blinkenden Cursor.

Die Kommandozeile ist der Ein-/Ausgabebereich zur textbasierten Steuerung des gesamten Computersystems. Es werden mit der Tastatur Befehle eingetippt und Ergebnisse ausgegeben.

Weil es keine grafische Oberfläche gibt, kommt die Kommandozeile bzw. die Programme, die darüber laufen, mit weniger Ressourcen aus als vergleichbare Programme mit einer grafischen Bedienoberfläche. Und sie sind dadurch vergleichsweise schneller.

Aber das ist längst nicht alles. Es gibt sehr viel kleine Kommandozeilenprogramme, die alle miteinander kombiniert werden können und sich automatisieren lassen.

Die Bash = Standard-Kommandozeile unter Linux

Es gibt viele Komandozeilenprogramme. ich verwende in meinem Beitrag das wohl verbreitetste: die Bash. Falls Ihr ein anderes Programm benutzt, sollten meine Beispiele genauso funktionieren.

Ich werde hier keine Einführung in die Bash geben. Die unten genannten Beispiele sind selbsterklärend und für alle nachvollziehbar. Allerdings kann es nicht schaden, sich mal grundsätzlich mit dem Konzept und Arbeitsweise auseinanderzusetzen.

Datenbank-Umzug

Im folgenden Beispiel erkläre ich, wie eine WordPress-Datenbank von einem Liveserver auf einen Server mit einer anderen Domain umgezogen wird.

Liveserver: http://wpdbash.test/

Testserver: http://local.wordpress.dev/

Für den Umzug ergeben sich folgende Schritte:

  1. Datenbank (Dump) vom Liveserver exportieren
  2. Dump komprimieren
  3. Transfer zum Testserver
  4. Dump dekomprimieren
  5. Dump importieren
  6. URLs im Dump an den Testserver anpassen

Zum Einsatz kommt dafür: Das Kommandozeilenprogramm Bash und die WP-CLI.

Eine wichtige Grundvoraussetzung ist außerdem, dass ein Zugriff per ssh auf die beiden Server möglich ist.

WP-CLI ist dein Freund

Die WP-CLI ist ein Kommandozeilenprogramm, das sehr viele nützliche Kommandos für die Arbeit mit WordPress bereit hält. Es erleichtert uns viele Arbeitsschritte und macht den Umzug ganz sicher.

Ich muss ehrlich gestehen, dass ich die WP-CLI bisher nicht ernsthaft verwendet hatte, weil ich mir die extra Installation zu aufwendig war und ich die URL-Anpassung mit einem vorhandenen Bash-Tool erledigt hatte. Dank eines freundlichen Hinweises von David Stingl weiß ich nun aber, dass ich ab jetzt und in aller Zukunft meine Faulheit überwinden und die WP-CLI einsetzen werde!

Auch auf die Einführung der WP-CLI möchte ich hier verzichten. Installation und Anwendung ist – wie man es bei WordPress nicht anders gewohnt ist – umfassend und verständlich.

Schritt 1: Datenbank vom Liveserver exportieren

Ich gehe davon aus, dass der Liveserver irgendwo bei einem Hoster steht. Der Testserver befindet sich auf einer Vagrant Entwicklungsumgebung auf dem eigenen Computer.

Um von der Bash auf dem lokalen Rechner zum Liveserver zu gelangen verwendet man ssh:

ssh user@wpdbash.test

ssh – Startet ssh
user – Loginname für ssh Zugriff
wpdash.test – die Adresse des Liveservers

Anschließend fragt die Kommandozeile noch nach dem Passwort. Nach der erfolgten Einwahl ist das „Innere“ des Liveservers erreicht. Jetzt kann die Datenbank vom Liveserver exportiert werden. Das wird im Schritt 2 erklärt.

Aber zuvor sollte erst mal ein Sicherheitsbackup von der Datenbank angefertigt werden:

wp db export sicherheitsbackup.sql

wp – startet WP-CLI
db export – exportiert die Datenbank
sicherheitsbackup.sql – der Dateiname des Sicherheitsbackups

Das Sicherheitsbackup bleibt unangetastet. Für den „Fall der Fälle“ lässt es sich später so zurückspielen:

wp db import sicherheitsbackup.sql

Jetzt weiter mit dem eigentlichen Export:

wp db export wpdbash.sql

Es wurde nun also die Kopie der Datenbank (Dump) angelegt, die im weiteren für den Umzug verwendet wird.

Schritt 2: Dump komprimieren

Dieser Schritt ist zwar für den eigentlichen Umzug nicht notwendig. Aber durch die Komprimierung wird der Dump kleiner und lässt sich somit schneller über das Internet übertragen.

gzip wpdbash.sql

Vom gzip-Programm wurde der Dump umbenannt in: wpdbash.sql.gz

Schritt 3: Transfer zum Testserver

Die Arbeit auf dem Liveserver ist getan. Die ssh-Verbindung kann abgebrochen werden:

exit

Nun geht es in der Bash auf dem lokalen System weiter. Der Dump wird transferiert:

scp user@wpdbash.test:/liveserver/pfad/wpdbash.sql.gz /lokaler/pfad/wpdbash.sql.gz

scp – startet den Transfer
user – Loginname für ssh Zugriff
wpdbash.test – die Adresse des Liveservers
:/liveserver/pfad/wpdbash.sql.gz – Pfad auf dem Liveserver zum Dump
/lokaler/pfad/wpdbash.sql.gz – Pfad auf dem lokalen Rechner, wo der Dump hin soll

Schritt 4: Dump dekomprimieren

gzip -d wpdbash.sql.gz

-d – Dekomprimiert den Dump und benennt ihn wieder um: wpdbash.sql

Schritt 5: Dump importieren

wp db import wpdbash.sql

Schritt 6: URLs an den Testserver anpassen

Der Dump wurde nun in die WordPress Datenbank des Testservers importiert. Im letzten Schritt müssen noch die Pfade an die Testumgebung angepasst werden. Dazu reicht es, die URLs zu ersetzen:

wp search-replace 'wpdbash.test' 'local.wordpress.dev'

wp – startet WP-CLI
search-replace – startet das Suchen und Ersetzen Programm der WP-CLI
‚wpdbash.test‘ – das zu ersetzende (Liveserver)
‚local.wordpress.dev‘ – das Ersetzende (Testserver)
–export=wpdbash.sql – Die Datenbank wird in die Datei wpdbash.sql exportiert

Fertig! Die Datenbank wurde damit auf den Testserver übertragen. :-)

Performance Vergleich: WordPress vs. statische Webseite

Mit diesem Beitrag möchte ich klären, welchen Einfluss WordPress auf die Web-Performance einer Webseite hat. Und ich mache auch noch einen Verbesserungsvorschlag. ;-)

Hintergrund

Letzte Woche hatte das Smashing Magazine eine Preview der neuen Website veröffentlicht. Dabei wurde bekannt gegeben, dass es eine Abkehr von WordPress geben soll. Was mich überraschte, war die Begründung: Es geht – neben der Zusammenführung von unterschiedlichen Plattformen – um die Verbesserung der Performance.

Das führte mich zur Frage:

Gibt es einen Unterschied in der Performance zwischen WordPress getriebenen Webseiten und statischen Webseiten?

Methode

Um der obigen Frage nachzukommen, hatte ich mir folgende Methode überlegt: Ich vergleiche die Web-Performance von identischen Webseiten, die mit und ohne WordPress angetrieben werden.

Natürlich ist klar, dass eine dynamisch generierte Webseite – wie es z.B. bei WordPress – von Hause aus langsamer sein muss als eine statische Webseite. Denn die Seiten werden erst beim Seiten Aufruf generiert. Die Generierung benötigt Zeit und kostet Performance. Darum kommen sinnvollerweise Caching Plugins zum Einsatz, die generierte Seiten archivieren. So dass sie nicht bei jedem Aufruf neu erzeugt werden müssen. Entsprechend habe ich auch das Page Caching berücksichtigt.

Versuchsaufbau

  • Server: Varying Vagrant Vagrants in der Standardkonfiguration.
  • WordPress
    • Plugins
    • Theme: Twenty Seventeen
      • Header-Image
      • Google Fonts entfernt, um Ladzeiten von externen Dateien auszuschliessen
    • Permalinks: Post name
  • Statische Seite
    • 1:1 Kopie der WordPress Startseite als HTML Dokument in einem eigenen Verzeichnis
    • Alle Assets ebenfalls in eigenes Verzeichnis kopiert und die entsprechenden Links auf die Assets im HTML Dokument angepasst.

Ich hatte eine exakt gleiche Dummy Webseite auf drei verschiedene Arten generiert und gemessen. Sie sahen alle so aus:

image-582141

Screenshot der Dummy Webseite

Ergebnisse

Gemessen hatte ich mit dem Developer Tool von Chrome. Hier die Screenshots der Ergebnisse:

1) Webseite mit WordPress

image-582142

2) Webseite mit WordPress und Page Caching

image-582143

3) Statische Webseite

image-582144

Auswertung

Die Ladezeiten für die Assets liegen bei allen drei Seiten auf dem selben Niveau und können somit vernachlässigt werden. Sie haben keinen Einfluss auf die Unterschiede in der Performance.

Die drei Messungen unterscheiden sich lediglich bei den Ladezeiten für das Document. Wie zu erwarten ist die Ladezeit der Webseite mit WordPress am höchsten: 63 ms. Wenn diese Seite im Page Cache vorgeladen wird, gibt es schon eine ordentliche Performance Verbesserung: 15 ms. Aber diese Zeit liegt trotzdem noch deutlich hinter der Ladezeit für die statische Webseite: 8 ms.

Woher kommt der Unterschied beim Caching vs. Statisch?

Page Caching bedeutet, dass die Webseite als statische HTML Datei generiert wird. Webseite 2) und 3) sind also identisch. Trotzdem wird 2) von WordPress langsamer ausgeliefert. Der Grund ist klar: anders als bei 3) liegt die vom Cashing Plugin vorgenerierte Datei nicht an dem Ort, der in der URL angegeben ist. Der URL Aufruf muss erstmal auf das Caching-Archiv umgeleitet werden. Dieser Prozess dauert seine Zeit und dass macht den Unterschied zwischen 2) und 3).

Zusammengefasst: Der Unterschied in der Performance zwischen mit WordPress gecachten und statischen Webseiten ergibt sich aus der Charakteristik der Cache-Archivierung und des Mappings. Dem geschuldet ist der kleine Verlust in der Performance.

Schlussfolgerung

Aus den obigen Messungen lässt sich schließen, dass WordPress generierte Webseiten tatsächlich langsamer sind als Ihre statischen Pendants.

ABER ! ! !

Allerdings sind die Performance Einbussen durch WordPress relativ gering, wenn Page Caching zum Einsatz kommt. Und selbst diese relativ geringe Performance Einbusse ließe sich noch weg bekommen, …

Verbesserungsvorschlag

…wenn das Page Caching anders gelöst würde. Indem die generierten Seiten nicht irgendwo in einem Cache Archiv umgeleitet werden, wäre der kleine Performance Nachteil zu den rein statischen Webseiten aufgehoben.

Prinzip des Page Cachings, wie es mit den WordPress Plugins bisher umgesetzt wird:

/
- index.php
- wordpress/
            - cache-archive/
                             - index.html
                             - blog.html
                             - products.html
                             - portfolio.html
                             - contact.html
                             - about-us.html
            - wp-admin/
            - wp-content/
            - wp-includes/
            - etc...

Der Seitenaufruf muss erst in das Cache Archiv weitergeleitet werden. Das kostet Zeit.

Neuer Ansatz für ein Page Caching mit „echten“ Seiten, deren HTML-Dokumente vom Caching Plugin direkt in die Root gelegt werden:

/
- index.html
- blog.html
- products.html
- portfolio.html
- contact.html
- about-us.html
- index.php
- wordpress/
            - wp-admin/
            - wp-content/
            - wp-includes/
            - etc...

Hier würde der Seitenaufruf direkt bei der Seite landen, weil sie schon dort liegt. Eine Weiterleitung erübrigt sich. Mit diesem Ansatz gäbe es keine Nachteile.

 

Automatisiertes Web-Performance Monitoring mit SpeedTracker

Die Grundlage für die Web-Performance Optimierung (WPO) sind Messdaten. Zum einen weil durch Messwerte die Schwachstellen in der Performance bestimmbar (und lokalisierbar) werden und zum anderen, weil die Messungen den Erfolg (oder Misserfolg) der Optimierungsmaßnahme zeigt.

Von Methoden- und Messfehlern einmal abgesehen, sind bei der Performance Optimierung auf Grundlage einer Datenbasis „alternative Fakten“ nicht möglich. Diese Ehrlichkeit macht mir WPO sehr sympathisch. :-)

Messdaten aber wie?

Der Quasi-Standard für die Performancemessung von Internetseiten ist WebPagetest.

image-582126

Hiermit lassen sich alle wichtigen Daten messen – wie zum Beispiel Ladezeiten, Rendering, Anfragen, Dateigrößen usw. Darüber hinaus werden die Messungen – in einem persönlichen Account – bis zu einem Jahr vorgehalten und lassen sich historisch vergleichen.

Für die schnelle IST-Stand-Analyse ist WebPagetest neben den Developer Tools in den Browsern meiner Meinung nach das beste „Messwerkzeug“ überhaupt.

Messdaten grafisch aufbereitet – Monitoring

Zugegeben die Möglichkeit des historischen Vergleichs von Messdaten bei WebPagetest sind schon enorm. Allerdings sind sie relativ umständlich zu abzufragen und nicht geeignet um z.B. dauerhaft Entwicklungen (Trends) aufzuzeigen. Vor allem deshalb, weil die Daten manuell gemessen werden müssen. Es wäre also gut, wenn die Messungen a) automatisiert und b) grafisch aufbereitet werden.

Dank der WebPagetest RESTful API lassen sich alle Messungen „remote“ ausführen und dadurch steuern (Automatisierung), grafisch aufbereiten und archivieren.

Bis hierhin klingt das alles einleuchtend und ganz gut. ABER: Das Messen und Auswerten von Daten über einen längeren Zeitraum wird sehr aufwändig und unübersichtlich. Ohne geeignete Software oder -Service wird das Monitoring von mehreren Websites ganz schnell unübersichtlich und artet in sehr viel Arbeit aus.

Auf dem Markt gibt es bereits entsprechende Tools, die diese Arbeit leisten. Allerdings – und ganz zu Recht! – sind diese Services nicht umsonst. Das macht den Einstieg in die Performance Optimierung unmöglich. Auch für gemeinnützige Web-Projekte mit schmalen Budgets war da nichts zu machen. Bisher fehlte eine kostenlose Alternative.

Aber Rettung ist da: SpeedTracker

Performance Monitoring mit SpeedTracker – Open Source und kostenlos

SpeedTracker ist ein Werkzeug, mit dem sich die Web-Performance von Websites über längere Zeit automatisiert messen lässt. Die Daten werden grafisch aufbearbeitet und auf einer Übersichtsseite ausgegeben:

image-582127

Um SpeedTracker zu betreiben wird lediglich ein GitHub Account benötigt. Wer einen Free Account hat, sollte bedenken, dass die Messdaten dann natürlich öffentlich einsehbar sind. Mit einem Premium Account sind die Daten – bzw. das gesamte Repository – öffentlich nicht sichtbar.

Keine Installationsanleitung!

Ich spare mir die Anleitung für die Installation bzw. Konfiguration. Das ist alles sehr gut bei SpeedTracker beschrieben: https://speedtracker.org/docs

Wer SpeedTracker auf einem eigenen Server betreiben möchte, kann dies natürlich auch. Dazu muss die API angepasst werden. Ich selber habe damit allerdings noch keine Erfahrung.

Performance Budget

Viel Interessanter als die Auslagerung auf einen eigenen Server finde ich die Möglichkeit, ein Performance Budget zu bestimmen. Damit können „Limits“ für bestimmte Messwerte gesetzt werden. Wird so ein Limit überschritten, dann lässt dieses Ereignis ganz praktisch per E-Mail oder Slack mitteilen.

Einschränkung

Das ganze Monitoring bis hin zu GitHub lässt sich kostenlos betreiben. Aber natürlich bringt das auch gewisse Grenzen. Die Messungen pro Tag und Profil sind eingeschränkt:

  1. Je Profil kann maximal zweimal täglich gemessen werden.
  2. Es können insgesamt (also alle Profile zusammen) nur 200 Messungen pro Tag durchgeführt werden.

Die Beschränkung hat mir bisher nie in Probleme gemacht, obwohl ich das recht intensiv nutze.

Allerdings gab es mal eine Ausnahme: In Vorbereitung auf meinen Performance-Vortrag beim WordCamp Köln wollte ich 202 Websites von den Teilnehmerinnen und Teilnehmern auf Performance messen. Mit den obigen Einschränkungen hätte das zwei Tage gedauert. Weil ich aber nur einen Tag Zeit hatte, hatte ich einen Trick angewendet: Einfach einen weiteren API-Key von einem anderen Account (wichtig: andere E-Mail-Adresse!) anfordern… ;-)

WebPerformance / DevOps

Die Hielscher Ultrasonics GmbH ist mein ältester „Dauerkunde“. Die Website ist das wichtigste Marketinginstrument der Firma. Damit vertreibt sie weltweit Ihre Produkte (Made in Germany!).

Die größte Herausforderung ist ganz klar die Web Performance und die weltweite Erreichbarkeit. Also auch für Länder mit eher langsamen Internet und alten Browsern.

Projekt:Relaunch Website, Performance Optimierung und regelmäßiger Support der Firmenwebsite
Kunde:Hielscher Ultrasonics GmbH
Leistung:Theme Entwicklung (Custom Theme), Web Performance Optimierung, WordPress, Serveradministration
Herausforderung:
  • Responsive Webdesign
  • Browserkompatibilität auch für Internet Explorer 9
  • fortlaufend Erweiterung und Umbau
  • Mehrsprachigkeit: 79 Sprachen (z.T. automat. Übersetzung)
  • Aufbereitung für Content Delivery Network
  • Minifizierung der Bilder und des Codes
  • SSL
  • HTTP/2
  • Server Push
  • Security
Online seit:2012 (1. Relaunch), 2014 (2. Relaunch)
URL:www.hielscher.com

WordPress Integration

Bei diesem Projekt wurde ich von der RapidComp GmbH als „WordPress Fachmann“ eingesetzt. Es galt für mich, aus bestehenden „HTML-Klick-Dummys“ ein Theme zu erstellen und lauffähige Website(s) mit Dummy-Content. Denn genau genommen war es nicht nur eine Website, sondern mehrere regionalisierte Website-Varianten: mit eigener Domain je Land und länderspezifisch angepassten Content und Sprache.

Die größte Herausforderung war für mich die Umsetzung von Mehrsprachigkeit, Multidomain und Regionalisierung mit nur einer WordPress-Installation. Normalerweise wäre das nämlich ein klassischer Fall für Multisite-WordPress. Aber das war hier leider nicht möglich.

Projekt:Relaunch einer Website der BillPay GmbH
Kunde:RapidComp GmbH
Leistung:Theme Entwicklung (Custom Theme)
Herausforderung:
  • Responsive Webdesign
  • Mehrspachigkeit: vier Sprachen
  • Multidomain: 4x
  • Regionalisierung: vier Länder – je zweisprachig
  • Single-Installation (!!!)
  • sehr viele Custom Fields, Post Types, Taxonomies, Custom Walker
Online seit:November 2016
URL:www.billpay.de

WordPress.tv – Das Video zum Vortrag über Datenkompression

Am 26.01.2017 hatte ich beim WP Meetup Berlin einen Vortrag zum Thema Datenkompression gehalten. Meinen Beitrag dazu gibt es hier. Aber das Video möchte ich natürlich nicht vorenthalten.

Es ist übrigens der erste Videomitschnitt beim Berliner Meetup. Das Ganze wird ermöglicht durch Bernhard Kau. Dazu hat er sich eigens ein komplettes Aufnahmeequipment zugelegt, erledigt die Aufzeichnung, schneidet und lädt alles hoch. Er will ab jetzt immer die Vorträge in Ton und Bewegtbild festhalten und auf WordPress.tv veröffentlichen.

DANKE BERNHARD! :-)

 

 

Datenkompression – Ein praktischer Leitfaden für den Einstieg

Am Donnerstag war mal wieder WP Meetup in Berlin und ich habe einen Vortrag über Datenkompression gehalten. Da ich kein Freund von Vortragspräsentationen im Internet bin, habe ich mich also nachträglich hingesetzt und alles als Blogbeitrag runter geschrieben.
Bitte sehr…. :-)

Datenkompression ist gut für Web Performance

Datenkompression ist eine Methode für Web Performance. Im Grund geht es bei der Datenkompression darum, die Dateigröße mithilfe von ziemlich cleveren Regeln (Algorithmen) zu verkleinern. Dabei werden z.B. wiederkehrende Zeichen (Muster) im Code zusammengefasst.

Das klingt schon mal ziemlich kompliziert. Ist es auch. Ohne intensives Informatik- bzw. Mathematikstudium geht da gar nichts. Aber die gute Nachricht: Datenkompression müssen wir nicht studieren, um sie erfolgreich benutzen zu können. Es reicht zu wissen, wie Datenkompression angewendet wird. ^^

Kleine Dateien

Mit der Datenkompression auf dem Webserver lassen sich Dateien um ca. 30 – 70% verkleinern. Dadurch können sie im Internet schneller übertragen werden. Das wiederum sorgt für schnellere Ladezeiten.

Ein kleines theoretisches Rechenbeispiel:

UnkomprimiertKomprimiert
Dateigröße:100 MB30 MB
Übertragungsrate:10 Mbit/s (DSL)
Dauer:80s24s

In diesem Beispiel benötigt eine unkomprimierte Datei, die 100 MB groß ist bei einer normalen DSL-Verbindung 80 Sekunden. Die gleiche Datei wäre komprimiert nur noch 30 MB groß und wäre dann schon in 24 Sekunden. Diese Datei wäre also ca. dreimal schneller am Ziel!

(Natürlich ist das obige Beispiel nur eine theoretische Berechnung. In der Praxis spielen noch viele andere Einflussfaktoren eine Rolle bei der Übertragungsgeschwindigkeit.)

Wie kommt Datenkompression zum Einsatz?

Jede Internetseite besteht aus mehreren Dateien. Das ist mindestens ein Dokument (z.B. index.html) und eine oder mehrere CSS-, Javascript- und Bild-Dateien und ein paar Web-font-Dateien und vielleicht noch vieles andere

Immer wenn jemand im Browser eine Internetseite anschauen möchte, werden diese Dateien von einem Webserver zum Browser übertragen. Als Faustregel lässt sich sagen: Je größer die Datei, desto länger dauert die Übertragung. Und je länger die Übertragung dauert. Desto länger müssen die Leute am Browser warten. Aber warten mag niemand. Um die Warterei auf die Internetseite zu verkürzen, können die Dateien komprimiert werden und werden dadurch schneller Übertragen. Aber wie?

Kompression beim Server und Dekompression beim Browser läuft automatisch.

Auf dem Webserver wird ein Kompressionsprogramm installiert. Das sorgt dann automatisch dafür, dass die Dateien bevor sie den Webserver verlassen, komprimiert werden. Wenn die komprimierten Dateien dann beim Browser ankommen, sorgt der – wiederum automatisch – dafür, dass die Dateien ausgepackt (dekomprimiert) werden und dann ganz normal für die Internetseite weiter verarbeitet werden.

Von all dem bekommen wir als normale Anwenderinnen und Anwender nichts mit. Wir laden wir gehabt unsere Daten auf den Server bzw. in ein Content-Management-System und der Server kümmert sich selbstständig. Prima, so einfach kann Web Performance sein! ;-)

Datenkompression mit gzip

Das Kompressionsprogramm der Wahl ist immer noch gzip. Das sorgt für die automatische Komprimierung auf dem Server. Es eignet sich für die Kompression aller Dateien, die Text enthalten. Das wären z.B. Dateien mit den Endungen; .html, .php, .css, .js, . svg, .woff2

gzip ist für alle gängigen Webserver erhältlich. Bei den beiden meist verwendeten Servern Apache und nginx ist gzip normalerweise bereits als Modul in der normalen Installation mit dabei. Es muss allerdings aktiviert werden, weil es in der Normaleinstellung deaktiviert ist.

Um die Installation müsst Ihr Euch also nicht kümmern – lediglich um die Aktivierung, falls gzip noch nicht läuft.

Woher weiß ich, ob meine Internetseite Daten komprimiert?

Erfahrene Entwicklerinnen und Entwickler wissen natürlich wie sie die Kompression mit Hilfe des Developer Tools im Browser auslesen können. Für alle anderen ist es aber auch nicht schwierig. Es gibt jede Menge Websites, wo sich ein „gzip Check“ durchführen lässt. z.B. bei www.gziptest.com

Einfach die URL eingeben und schon wird einem gezeigt, ob die Internetseite gzip unterstützt. Bei meiner Seite sah der Check so aus:

…alles richtig gemacht. :-)

Was tun, wenn gzip noch nicht aktiviert ist?

Falls der obige Test negativ verlaufen sein sollte, keine Panik. Das lässt sich richten. Zunächst lohnt sich erstmal ein Blick in die Accountverwaltung bei Eurem Provider oder eine Suche im Support oder der FAQ. Wenn dort nichts zu finden, am besten Anschreiben und Fragen, wie Ihr gzip auf dem Server aktivieren könnt.

Falls Eure WordPress-Seite auf einem Apache Server läuft, könnt Ihr gzip über ein Plugin aktivieren. z.B. mit dem Plugin Check and Enable GZIP compression

Falls Eure Website auf einem nginx Server läuft, müsst Ihr den Provider/Administrator bitten. Ein Plugin kann da nicht helfen.

Brotli – Ein neuer Stern am Himmel

Zum Abschluss möchte ich noch eine Alternative zu gzip ins Spiel bringen: Brotli

Brotli ist ebenfalls ein Kompressionsprogramm. Und zwar ein relativ neues. Es wurde von Google entwickelt und bietet neben einer noch stärkeren Kompression auch noch weitere Vorteile. Unter anderem, komprimiert Brotli viel schneller. Was positive Auswirkungen auf die Performance hat. Wer sich für Vergleichsmessungen von Brotli vs. gzip interessiert, kann sich das mal anschauen: https://blogs.akamai.com/2016/02/understanding-brotlis-potential.html

Allerdings ist Brotli noch nicht wirklich relevant, denn es wird bisher noch nicht von allen Browsern (Dekompression) unterstützt und leider bieten die Provider meines Wissens nach bisher noch keinen Support dafür.

image-582026

Brotli Browser-Unterstützung. Stand 27.01.2017

Nichtsdesto wird Brotli in absehbarer Zeit gzip verdrängen und zum Standard werden. Dafür ist seine Performance einfach zu gut. Übrigens wird diese Website mit Brotli gepowert. ;-)

Unkomprimiert vs. gzip vs. Brotli

Last not least habe ich alle Möglichkeiten verglichen. Ich habe meine Startseite unkomprimiert, mit gzip und mit Brotli gemessen. Hier der Vergleich:

image-582027

Meine Startseite => unkomprimiert

image-582028

Meine Startseite => gzip

image-582029

Meine Startseite => Brotli

…Noch Fragen? ;-)

HTTP/2 Server Push – Die ersten Versuche

Soeben habe ich bei einem Kunden erfolgreich das HTTP/2 Server Push Feature aktiviert. Das Ergebnis kann sich schon mal sehen lassen:

image-582015

Die Zeiten sprechen für sich…

Die Aktivierung ist relativ simpel, WENN ein Server zur Hand ist, der Server Push unterstützt. Das ist leider mit nginx noch immer nicht der Fall. Und es steht in den Sternen, wann das je noch geschehen wird. Apache dagegen bietet Server Push schon standardmäßig mit dem HTTP/2 Modul an. Ergo denke ich immer lauter über einen Serverwechsel bei mir nach. Aber Apache ist nicht so meine Wahl… ;-)