In den vergangenen Wochen habe ich an meinem Blog ziemlich viel herumgeschraubt. Der sichtbarste Schritt war sicher der Wechsel auf das WordPress-Theme Twenty Twenty-Five. Daneben gab es aber noch eine zweite Baustelle, die man beim bloßen Anschauen kaum bemerkt: Ich wollte das Blog etwas „beschleunigen“.

Wobei „beschleunigen“ vielleicht gar nicht das richtige Wort ist.

Entstehung des Textes
Dieser Artikel entstand mit Unterstützung einer Künstlichen Intelligenz. Ich habe die Arbeiten an der Performance meines Blogs mit Unterstützung von ChatGPT durchgeführt und daher auch bei der Zusammenstellung auf diese „Erinnerungen“ der KI zurückgegriffen. Generelles zu meiner KI Nutzung kannst du in meiner Kreativitätserklärung nachlesen.

Mein eigentliches Problem war, dass es zeitweise zu 429- und 504-Fehlern kam. Für ein persönliches Blog, auf dem nun wirklich nicht tausende Menschen gleichzeitig lesen, fand ich das zumindest verwunderlich.

Also begann ich mich zu fragen: Was macht WordPress bei einem Seitenaufruf eigentlich alles – und was davon brauche ich wirklich?

Nicht noch ein Optimierungsplugin

Die naheliegende Antwort bei WordPress lautet ja oft: Installiere ein Plugin.

Für Caching eines, für Bilder eines, für die Datenbank eines, für JavaScript eines und am Ende vielleicht noch eines, das die anderen Optimierungsplugins optimiert.

Ich wollte diesmal eher in die andere Richtung gehen.

Die Frage war nicht: Was kann ich noch installieren?

Sondern: Was kann weg?

WordPress soll nicht jede Seite immer wieder neu zusammensetzen

Eine wichtige Ausnahme von dieser Weglassstrategie gibt es allerdings: Cache Enabler.

Das Plugin sorgt vereinfacht gesagt dafür, dass WordPress eine bereits erzeugte Seite nicht bei jedem Aufruf wieder komplett neu zusammenbauen muss.

Normalerweise bedeutet ein Seitenaufruf unter anderem: PHP wird ausgeführt, WordPress startet, Plugins werden abgearbeitet, Daten aus der Datenbank werden geholt und daraus entsteht schließlich HTML.

Bei einem persönlichen Blog ist das für viele Seiten eigentlich unnötige Arbeit. Ein veröffentlichter Artikel sieht beim nächsten Aufruf meist genauso aus wie beim vorherigen.

Der Cache kann deshalb eine fertige HTML-Version ausliefern.

Das dürfte unter all meinen Änderungen eine der Maßnahmen sein, die sich am unmittelbarsten auf die Serverlast auswirkt.

Plugin für Plugin durchgehen

Danach habe ich mir angesehen, was sich im Laufe der letzten Zeit wieder bei meinen WordPress-Plugins angesammelt hatte.

Dabei ging es nicht darum, auf möglichst wenige Plugins zu kommen. Ein Plugin, das ich brauche, darf selbstverständlich bleiben.

Aber jedes Plugin sollte zumindest die Frage beantworten können:

Warum bist du eigentlich hier?

Einige konnten das nicht mehr besonders überzeugend.

So habe ich etwa WP Accessibility entfernt. Nicht, weil Barrierefreiheit plötzlich unwichtig wäre – ganz im Gegenteil. Mit Twenty Twenty-Five übernimmt das Theme aber bereits vieles, wofür ich früher zusätzliche Unterstützung gebraucht habe. Und was noch nicht funktioniert, möchte ich sukzessive über das Theme beheben.

Auch Simple Lightbox benötigte ich nicht mehr. Vergrößerte Versionen von Bildern per Klick schafft das Theme auch so. Lightbox bot noch etwas mehr an Bedienungskomfort, aber bei den paar Fotos auf meinem Blog ist das auch ein Overkill.

Und auch ein eigenes Open-Graph-Plugin war – soweit ich sehen konnte – nicht mehr notwendig, weil die wichtigen Funktionen ein anderes Plugin mit übernehmen kann.

Das klingt jeweils nach Kleinigkeiten. Aber mehrere Kleinigkeiten ergeben irgendwann eben auch etwas.

Eine Weiterleitung braucht nicht unbedingt WordPress

Ein besonders schönes Beispiel ist für mich das Plugin Redirection.

Mein Blog ist alt. Entsprechend gibt es auch einige sehr alte URLs aus früheren Blogsystemen und früheren URL-Strukturen. Manche davon möchte ich weiterhin auf die heutigen Artikel weiterleiten.

Dafür braucht es aber nicht unbedingt WordPress.

Die wenigen noch notwendigen Regeln habe ich direkt in die .htaccess übernommen. Der Webserver kann damit eine alte Adresse auf die neue umleiten, noch bevor WordPress überhaupt gestartet wird.

Das macht die Startseite natürlich nicht plötzlich rasend schnell.

Aber es entspricht ziemlich gut der neuen Grundidee:

Wenn eine Aufgabe einfach erledigt werden kann, soll dafür nicht der gesamte WordPress-Apparat anlaufen.

Die Schriftzeichen bleiben lokal

Ein weiteres Plugin, das ich längere Zeit bewusst eingesetzt hatte, war OMGF.

Mir ist wichtig, dass mein Blog keine Google Fonts direkt von Google nachlädt. Deshalb hatte ich die verwendeten Schriftarten lokal eingebunden.

Nach dem Umstieg auf Twenty Twenty-Five stellte sich heraus: Das brauche ich inzwischen gar nicht mehr über ein zusätzliches Plugin zu lösen.

Meine derzeit verwendete Schrift Atkinson Hyperlegible Next wird lokal als WOFF2-Datei ausgeliefert.

Also konnte auch OMGF deaktiviert werden.

Das war ursprünglich vor allem eine Datenschutzfrage. Aber es passt gut zum restlichen Umbau: weniger externe Abhängigkeiten, weniger Umwege und wieder ein Plugin weniger.

Hat Twenty Twenty-Five das Blog schneller gemacht?

Das kann ich nicht seriös behaupten.

Ich habe das frühere Theme Apex und Twenty Twenty-Five nicht in einem Testlauf gegeneinander antreten lassen und anschließend Diagramme mit Ladezeiten erstellt.

Der Theme-Wechsel hatte für mich vor allem andere Gründe: mehr Gestaltungsmöglichkeiten mit dem Block-Editor.

Trotzdem hat er bei der Performance indirekt geholfen.

Mit dem neuen Theme konnte ich einiges vereinfachen und Funktionen entfernen, für die ich früher zusätzliche Lösungen benötigt habe.

Und auch bei der Gestaltung selbst ist einiges schlichter geworden.

Weniger Elemente müssen eben auch weniger erzeugt, geladen und dargestellt werden.

Aber ActivityPub und Webmentions bleiben

Nun könnte man natürlich konsequent werden und alles entfernen, was irgendwie zusätzliche Arbeit verursacht.

ActivityPub? Weg.

Webmentions? Weg.

Die Anbindung für Mastodon-Apps? Weg.

Kontaktformular? Weg.

Dann wäre mein Blog wahrscheinlich tatsächlich noch etwas genügsamer.

Es wäre aber auch nicht mehr mein Blog.

ActivityPub, Webmentions und die Verbindung mit dem Fediverse sind Funktionen, die ich bewusst haben möchte. Sie gehören für mich inzwischen zu einem Blog im offenen Web.

Performance ist für mich deshalb kein Selbstzweck.

Ich möchte nicht das schnellstmögliche WordPress betreiben. Ich möchte ein Blog betreiben, das die Dinge kann, die mir wichtig sind, ohne unnötigen Ballast mitzuschleppen.

Und hat es etwas gebracht?

Seit diesen Arbeiten sind mir jedenfalls keine der vorher auffälligen Performance-Probleme mehr begegnet.

Das ist natürlich kein wissenschaftlicher Beweis. Ich lese nicht rund um die Uhr mein Blog. Vielleicht belasten Instanzen-Abfragen aus dem Fediverse mein Blog nur temporär.

Ich betreibe mein Blog auf Shared Hosting. Was dort gerade sonst noch auf einem Server passiert, kann ich nicht beurteilen. Und ich kann auch nicht sagen, welche meiner Änderungen wie viele Millisekunden eingespart hat.

Vielleicht war eine Änderung entscheidend. Vielleicht war es die Summe vieler kleiner Dinge. Vielleicht hatte ein Teil der damaligen Probleme auch gar nichts mit meiner WordPress-Installation zu tun.

Trotzdem gefällt mir das Ergebnis.

Vor allem gefällt mir aber der Weg dorthin.

Denn mein wichtigstes WordPress-Performance-Werkzeug war diesmal nicht irgendein neuer Beschleuniger.

Es war die Frage:

Brauche ich das eigentlich noch?