Archiv des Autors: Heiko Mamerow

Über Heiko Mamerow

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

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… ;-)

 

RTL Schreibrichtung bei WordPress Themes mit PostCSS automatisch erstellen

Wer die Internationalisierung seines WordPress Themes ermöglichen möchte, wird sich auch über die Schreibrichtungen Gedanken machen. Insbesondere werden zwei CSS-Varianten benötigt. Einmal für LTR (links nach rechts) und einmal für RTL (rechts nach links). Zwei CSS-Varianten können den Aufwand für die Thementwicklung deutlich erhöhen. Im Beitrag möchte ich darauf eingehen, wie sich dieser Aufwand stark reduzieren lässt.

image-581993

Die selbe Website einmal LTR und einmal RTL.

RTL Methoden bei WordPress

Grundsätzlich gibt es zwei Schreibrichtungen in horizontaler Richtung:

  1. LTR (von links nach rechts)
    z.B. Deutsch, Englisch, Französisch, Spanisch
  2. RTL (von rechts nach links)
    z.B. Arabisch, Hebräisch and Persisch

Über LTR müssen wir uns keine Gedanken machen. Das ist von hause aus gegeben. Für die Unterstützung von RTL werden im Codex zwei Möglichkeiten vorgestellt:

a) Ersetzungsmethode

Bei dieser Methode wird der Link im Dokument auf die originale Stylesheet Datei entfernt und durch ein RTL-Pendant (style-rtl.css) ersetzt.

b) Ergänzungsmethode

Bei der zweiten Methode bleibt die originale Stylesheet Datei (z.B. style.css) erhalten. Dafür wird zusätzlich die Datei rtl.css ergänzt. In rtl.css sind nur die für RTL relevanten Anpassungen enthalten. Weil rtl.css nach style.css geladen wird, überschreiben deren angepasste Regeln die original Regeln.

Wann eignet sich welche Methode?

Im Prinzip ist es egal, ob die originale Stylesheet Datei ersetzt oder ergänzt wird. Beides führt zum selben Ergebnis.

Ich präferiere die Ersetzungsmethode, weil sie die Webperformance nicht beeinflusst.

Die Ergänzungsmethode dagegen hat negativen Einfluss auf die Performance der Website, weil

  1. Durch die zusätzliche Datei wird ein zusätzlicher Request ausgelöst.
  2. Das Überschreiben der originalen Regeln erzeugt zusätzlichen Aufwand für den Browser.

RTLCSS

Egal, welche Methode gewählt wird, sie erfordern beide einen Aufwand in Umsetzung und Organisation für den Stylesheet. Glücklicherweise unterliegen die nötigen Anpassungsarbeiten relativ einfachen Regeln, die sich sehr gut automatisieren lassen. Und überglücklicherweise haben schon fleißige Leute Tools entwickelt, mit denn sich die entsprechenden Styles erstellen lassen.

Das von mir verwendete Tool ist RTLCSS. Es ist ein Konvertierungsscript für RTL. Es lässt sich sowohl in Verbindung mit einem Automatisierungstool oder auch als Online-Tool nutzen.

RTLCSS als Online Tool

Die RTLCSS Online ist sehr einfach zu bedienen. Damit lassen sich die schnellsten Ergebnisse erzielen. Der konvertierte Code kann für die Ersetzungsmethode ohne Nacharbeit genutzt werden. Wenn der Code für die Ergänzungsmethode verwendet werden soll, sollten nachträglich – von Hand – die unnötigen Styles rausgefiltert werden, um unnötige Überschreibungen zu vermeiden.

RTLCSS Online
image-581994

Screenshot RTLCSS Online: links der original Code; rechts die RTL-Version

RTLCSS Online sei allen empfohlen, die bereits ein fertiges Theme haben und es für RTL nachrüsten wollen.

RTLCSS mit npm

Die Verwendung von RTLCSS Online im Prozess der Thementwicklung ist allerdings umständlich. Weil nach jeder Änderung im Originalcode das Tool manuell bedient werden muss.

RTLCSS lässt sich aber prima in Verbindung mit einem Buildtool/Taskrunner verwenden. Ich zeige das hier am Beispiel von npm.

Ja, richtig gelesen. Denn npm lässt sich prima als Buildtool „missbrauchen“. Die gleichen Aufgaben lassen sich natürlich auch mit den anderen Buildtools erledigen…

Setup für die Ersetzungsmethode

Grundlage für das Setup sind: Node.js, npm (Npm ist in Node.js enthalten.) und PostCSS. Das sollte schon vorher installiert sein.

Schritt 1. Das Plugin RTLCSS installieren:

npm i -g rtlcss

Schritt 2. Im Rootverzeichnis des Projektes (Also dort, wo das Theme entwickelt wird.) npm initiieren. – z.B. im Terminal im Rootverzeichnis des Theme Projektes eingeben:

npm init

Schritt 3. In die frisch erzeugte Datei package.json den Task anlegen.

Nach dem Init wird die package.json erzeugt. Diese Datei im Editor öffnen und dann bei script das Folgende ergänzen:

{
  "name": "beispiel",
  "version": "1.0.0",
  "description": "Nur ein Beispiel",
  "main": "index.php",
  "author": "Heiko Mamerow",
  "license": "GPL-3.0",
  "scripts": {
    "rtl": "postcss -c ./npm-scripts/rtl.json",
  }
}

rtl => Der Name des Tasks
postcss => Es wird PostCSS ausgeführt.
-c => öffnet eine PostCSS Konfigurationsdatei für diesen Task
./npm-scripts/rtl.json => relativer Pfad zu Konfigurationsdatei

Schritt 4. Natürlich muss die angegebene Konfigurationsdatei noch erstellt werden. Also im gewünschten Pfad die Datei rtl.json anlegen. (Pfad und Dateiname kann natürlich angepasst werden.)

Schritt 5. rtl.json im Editor öffnen und eingeben:

{
  "use": [
   "rtlcss"
  ],
  "input": "./css-src/main-src.css",
  "output": "./schnell/assets/css/rtl.css",
  "map": "file"
}

use => Array; Dort nennen wir das PostCSS Plugin, was in diesem Task zur Anwendung kommen soll. Also: rtlcss
input => Pfad zum original Stylesheet
output => Pfad zum RTL Stylesheet (Wenn die Datei noch nicht vorhanden ist, wird sie später vom Task angelegt.)
map => Angabe, ob eine CSS-Map angelegt werden soll. (Ist nicht notwendig, aber macht sich besser, falls es mal später was zu debuggen gibt.)

Das war es schon, jetzt kann der Task ausgeführt werden – z.B. im Terminal im Rootverzeichnis des Theme Projektes eingeben:

npm run rtl

Im Editor sieht das ganze dann so aus:

RTLCSS mit PosctCSS
image-581995

RTLCSS mit PosctCSS im Editor

Wer mag, kann den obigen rtl Task noch mit einer watch Option automatisieren. So dass jedesmal, wenn die original CSS Datei editiert wird, gleich das RTL-Pendant aktualisiert wird.

Setup für die Ergänzungsmethode

Hier ist das Setup fast identisch wie bei der Ergänzungsmethode oben. Einziger Unterschied: für den Task nehmen wir ein anderes PostCSS Plugin: PostCSS-WPRTL

Dieses Plugin konvertiert im ersten Schritt die Regeln wie oben mit RTLCSS und filtert dann zusätzlich in einem zweiten Schritt alle unnötigen – weil ja im original Code vorhanden Styles – raus. Dieser zweite Schritt erspart uns unnötigen Code Ballast!.

Schritt 1. Das Plugin installieren – z.B. im Terminal im Rootverzeichnis des Theme Projektes eingeben:

npm i -g postcss-wprtl

Schritt 2 -4. sind wie oben.

Schritt 5. rtl.json im Editor öffnen und eingeben:

{
  "use": [
   "postcss-wprtl"
  ],
  "input": "./css-src/main-src.css",
  "output": "./schnell/assets/css/rtl.css",
  "map": "file"
}

Die Konfiguration ist ebenfalls wie oben – lediglich bei use ändert sich der Pluginname.

Der Task wird dann ebenfalls wie oben aufgerufen. Das Ergebnis ist allerdings ein wenig anderes als oben:

image-581996

Etwas ist jetzt anders als oben. Finde den Unterschied! ;-)

Nachtrag

Die RTLisierung des CSS ist dank RTLCSS und den Buildtools nicht mehr so aufwendig und sollte zum guten Standard jedes Themes werden. Zum Testen von RTL Themes empfielt sich übrigens das Plugin: RTL Tester. Damit lässt sich das bestehende Theme für eingeloggte Admins prima testen.

 

 

Themes oder Plugins mit Symlink in Vagrant einbinden

Frage: Was ist der Unterschied zwischen guten und schlechten WordPress-Entwicklern?
Antwort: Es gibt keinen. Erstere aber verwenden Vagrant. :-)

Wer Themes oder Plugins entwickelt, möchte sie sicherlich auch in einer Testumgebung ausprobieren. Dann ist eine virtuelle Umgebung mit Vagrant die erste Wahl. Je nach Projekt erstelle ich mir meine Umgebung mit PuPHPet oder VVV.

Um eine saubere Trennung von Vagrant (Testumgebung) und der Entwicklungsumgebung (IDE) zu haben, sollte das Theme (oder Plugin) aus der IDE mittels eines Symlinks in die Testumgebung eingebunden werden. Damit ist das Theme auf der Testseite immer synchron mit der Entwicklung. Jedesmal, wenn am Theme in der IDE editiert wird, ist die Änderung auch gleich in der Testumgebung aktiv.

Einbindung

Leider sind Symlinks in Vagrant nicht ganz trivial einzubeziehen. Dazu muss die Einstellung des Vagrantfiles wie folgt erweitert werden:

Wenn nicht schon vorhanden, erstelle erstmal im Vagrant-Root-Verzeichnis (Dort wo die Datei Vagrantfile liegt.) die Datei: Customfile

Öffne die Datei Customfile mit einem Editor und trage dort die Angaben zum Symlink ein:

# Symlink zu meinem Theme: superduper
config.vm.synced_folder "../Pfad/zur/Entwicklungsumgebung/von/superduper", 
"/srv/www/wordpress-default/wp-content/themes/superduper", 
owner: 'www-data', 
group: 'www-data', 
mount_options: ["dmode=775", "fmode=664"]

Im obigen Snippet ist beispielhaft die Einbindung eines Themes in VVV beschrieben.

Besonderheit: Der erste Pfad (zur IDE) kann relativ oder absolut sein. Der zweite Pfad (in Vagrant) muss immer absolut sein.

Quellen

https://wordpress.stackexchange.com/a/189849
https://www.vagrantup.com/docs/synced-folders/basic_usage.html