WordPress schneller machen – die Technik hinter nachbelichtet.com

Nachbelichtet läuft nun seit 14 Jahren (!!) mit Wordpress. Zig Themes, Plugins und Wordpress-Performance-Tipps später, habe ich wohl die optimale Einstellung für nachbelichtet gefunden.
Bitte beachte: Dieser Beitrag ist mehr als 3 Jahre alt. Manche Links, Preise, Produkte und Aussagen sind vielleicht nicht mehr aktuell!
Der Autoptimize Cache

Bei einem Theme wie Generatepress ist der Einsatz eines solchen Plugins sehr unproblematisch. Manche Themes zicken aber je nach Einstellung mit zerschossenem Layout und Javascript-Fehlern herum. Hier muss man die optimalen Einstellungen einfach mit dem eigenen Theme austesten. Und dann gehe ich noch einen Performance-Schritt weiter: Mit dem Plugin Async-Javascript, lasse ich JS-Scripte erst nach dem Aufbau der Seite nachladen. Es stammt vom gleichen Programmierer wie Autoptimize und die Kombination aus Autoptimize, Async-Javascript und dem Cache-Enabler hat sich für mich als optimal herausgestellt.

Nicht vergessen sollte man auch, dass man das client-seitige Caching nutzen kann! Dinge wie das Logo der Seite oder Bilder auf der Startseite, CSS und Javascripts können auch im Browser-Cache des Besuchers hinterlegt werden und damit wird der eigene Server gar nicht mehr angefragt. Es ist absolut erstaunlich, wie selten Webseiten das nutzen. Dabei spart es jede Menge Traffic.

NGINX – der Performance-Booster

Mit den oben aufgeführten Plugins erschöpft sich das Optimierungspotential, das man auf diesem Weg erreichen kann. Den richtigen Webhoster vorausgesetzt, gibt es aber einen mächtigen Hebel: NGINX (wird übrigens: „Engine Ex“ ausgesprochen). NGINX ist eigentlich selbst ein eigener schlanker Webserver. Er kann aber auch als sog. Reverse Proxy vor den Apache Webserver arbeiten.

NGINX Logo

Apache ist der am weitesten verbreitete Webserver. Leider ist er aber auch nicht unbedingt ein Performance-Wunder, gerade wenn es um viele gleichzeitige Zugriffe geht. Hat man einen Server mit Apache und NGINX, kann man beide so konfigurieren, dass NGINX alle statischen Inhalte, also Bilder, statische HTML-Seiten, Javascript, CSS etc. direkt ausliefert. Damit der Apache Server gar nicht mehr belastet und die Ladegeschwindigkeit der Seite wird enorm beschleunigt. Der Apache kümmert sich ab da nur noch um dynamische Inhalte.

Aus dem Netz kommt also eine Anfrage an den Server. NGINX sieht in seiner Konfiguration nach, ob er sich um die angeforderten Dateien kümmern soll. Handelt es sich um HTML-Dateien, JPGs, PNGs, JS, CSS etc. übernimmt NGINX und liefert die Dateien aus. Gibt es z. B. keine statische HTML-Version des Beitrags, reicht NGINX an den Apache-Webserver durch, der per PHP und den entsprechenden Datenbank-Queries den HTML-Output erzeugt und über das Caching-Plugin eine statische Seite erzeugt und ablegt. Bilder, JS, CSS etc. werden dann aber gleich wieder von NGINX übernommen. Alle Zugriffe auf die generierte Seite, werden in den nächsten 96 Stunden dann auch komplett von NGINX bedient, denn das ist die Caching-Zeit, die ich in Cache-Enabler vergeben habe.

Nginx Reverse Proxy
Nginx/Apache Reverse Proxy

Ein Reverse-Proxy hat auch einige handfeste Sicherheitsvorteile, denn er verschleiert die tatsächliche Webserver-Infrastruktur!

Da ich mit dem Cache-Enabler aus allen Posts beim ersten Aufruf statische HTML-Seiten generiere, wird auch die eigentliche Seite vom NGINX-Server ausgeliefert. Damit habe ich die Serverlast mit einem Schlag um fast 70% verringert! Viele Seitenbetreiber erschlagen Performance-Probleme bei steigenden Besucherzahlen mit größeren Servern, mehr RAM und CPU-Kernen. Ich neige immer dazu, erst einmal alle Möglichkeiten drumherum auszureizen und zu optimieren, bevor ich dann wirklich aufrüsten muss.

Mit etwa 3000 Besuchern täglich, war mein früherer Hoster, mangels NGINX und reiner Apache-Konfiguration, irgendwann zu lahm. Der Server von PixelX ist zwar von vornherein leistungsfähiger, aber mit diesen Optimierungen kann ich darauf auch die 5-fache Besucherzahl locker bedienen.

Bei PixelX habe ich die Admin-Software Plesk Onyx Web Pro enthalten und hier ist die Konfiguration von NGINX als Reverse-Proxy schnell erledigt. Allerdings ist es nicht ganz trivial, die richtigen Parameter zu finden. So ganz daneben bin ich mit meinen Optimierungen wohl nicht, denn Micha, der Geschäftsführer von PixelX, meinte: „Endlich mal jemand der weiß was er tut …“. Das tut gut 😉

Meine NGINX-Einstellungen sehen so aus:


gzip on; 
gzip_vary on; 
gzip_proxied any; 
gzip_comp_level 2; 
gzip_buffers 16 8k; 
gzip_min_length 256; 
gzip_http_version 1.1; 
gzip_types text/plain text/css application/json application/x-javascript application/javascript text/javascript text/xml application/xml application/xml+rss image/svg+xml; 
location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg)$ { expires 120d; } 
add_header Last-Modified $date_gmt; 
add_header Cache-Control 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=31536000'; 
expires 60d; etag on;

Micha hat mich darauf hingewiesen, dass ein höheres GZIP-Kompressionslevel (gzip_comp_level) nicht unbedingt sinnvoller ist, denn die CPU-Zeit die für eine höhere Kompression notwendig ist, kann den Vorteil der paar Kilobyter weniger ausgelieferten Daten zunichte machen.

Folgende Dateitypen werden direkt durch NGINX bedient:

ac3 avi bmp bz2 css cue dat doc docx dts eot exe flv gif gz htm html ico img iso jpeg jpg js mkv mp3 mp4 mpeg mpg ogg pdf png ppt pptx qt rar rm svg swf tar tgz ttf txt wav woff woff2 xls xlsx zip

Bilder klein halten mit Short Pixel

Mit den ganzen Optimierungen in Form von Plugins und Server-Einstellungen habe ich meine Seite zum fliegen gebracht. Das alles kann aber schnell wieder zunichte gemacht werden, wenn man riesige Bilder in unnötig hoher Auflösung und geringer Kompression ausgeliefert.

Natürlich habe ich meine Blog-Bilder immer recht gut optimiert. Die Kompression für JPEGs habe ich immer so gewählt, dass Darstellungsqualität und Dateigröße in einem guten Verhältnis standen. Ebenso habe ich alle Bilder auf die maximal benötigte Bildgröße reduziert. Mit kostenlosen Bildoptimierungstools wie RIOT kann man das offline ziemlich komfortabel machen, aber es nervt und kostet Zeit.

Eine hervorragende Alternative sind Optimierungsdienste, welche über ein Plugin hochgeladene Bilder automatisch optimieren. Meine Wahl fiel hier auf Short Pixel. Die Qualität der Komprimierung ist hervorragend und die erzielten Dateigrößen sind häufig manuell so gar nicht machbar. Zudem generiert Short Pixel automatisch Versionen im WebP-Format, was von Google bevorzugt wird und noch kleinere Dateigrößen bei gleichzeitig guter Bildqualität liefert.

Melde dich zu meinem Newsletter an!

Du kannst dich jederzeit abmelden und ich verspreche: Kein Spam!


Die mit Sternchen (*) gekennzeichneten Verweise sind sogenannte Provision-Links. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen.Wenn du auf so einen Verweislink klickst und über diesen Link einkaufst, bekomme ich von deinem Einkauf eine Provision. Für dich verändert sich der Preis nicht und du unterstützt damit meine Arbeit. Preisänderungen und Irrtümer vorbehalten.

Ein Kommentar

  1. Hi,

    klingt alles sehr gut. Auch Thema Massenhoster bin ich bei dir.
    Aber das mit Cloudflare, habe ich ganz andere Erfahrungen gemacht.
    Allein das man nur die DNS über Cloudflare routen lässt, bringt 100ms schnellere Auflösung der Domain. Das macht viel aus.
    Viele Nameserver haben 100-150ms. Cloudflare macht das in erstaunlichen 3-4 MS!! 🙂 (Deine 100ms)
    Caching dort, reduziert die Last/Traffic auf dem origin Server, was für dich und bei einem großen Projekt, durchaus attraktiv ist. Cloudflare hat auch mehrere Standorte in Deutschland, daher nicht unrelevant (meiner Meinung nach).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert