Deshalb ist Performance bei uns kein Thema, das wir irgendwann am Ende eines Projekts «noch schnell» angehen. Es ist ein integraler Bestandteil unserer gesamten Infrastruktur.

WordPress ist das mit Abstand meistgenutzte CMS der Welt. Gleichzeitig hat es den Ruf, langsam zu sein. Dieser Ruf ist nicht unbegründet – aber er ist auch nicht unausweichlich. Eine gut konfigurierte WordPress-Installation auf einer soliden Infrastruktur ist schnell, stabil und skalierbar. Genau das ist unser Ziel.

Dabei setzen wir nur auf wenige Plugins von Drittherstellern. Ein Set das miteinander funktioniert und sich nicht gegenseitig in Datenbank-Abfrage Schleifen verlangsamt. Yoast SEO darf nicht fehlen und ein WooCommerce baut man nicht über Nacht selbst. Doch seit über 10 Jahren erweitern wir unser eigenes Framework Plugin und programmieren viele Funktionen unserer Kundenwebsites selbst.

In Zeiten von KI-Unterstützter Programmierung kommt uns das sehr entgegen. Nicht nur ist die Software durch „Optimieren auf das Minimum“ sehr performant, wir können mit diesem Ansatz auch genau die Wünsche erfüllen die unsere Kunden haben – und das in sehr kurzer Entwicklungszeit.

Jede dynamische Website stellt ständig Anfragen an eine Datenbank: Welche Seiten gibt es? Was steht auf dieser Seite? Welche Beiträge sollen angezeigt werden? Wie schnell diese Anfragen beantwortet werden, hat einen direkten Einfluss auf die Ladezeit.

Wir betreiben unsere Datenbanken als MariaDB Galera Cluster – das bedeutet, mehrere Datenbankserver arbeiten synchron zusammen. Fällt einer aus, übernehmen die anderen nahtlos. Kein Datenverlust, keine Downtime. Gleichzeitig verteilt der Cluster eingehende Leseanfragen auf mehrere Knoten, was unter Last erheblich zur Stabilität beiträgt.

Dazu kommt ein grosszügig bemessener Datenbank-Cache: Häufig abgefragte Daten werden direkt im Arbeitsspeicher vorgehalten, sodass dieselbe Anfrage nicht jedes Mal von der Festplatte gelesen werden muss. 99% der Anfragen werden aus dem Cache bedient.

Zwischen WordPress und der Datenbank schalten wir Redis als sogenannten Object Cache. Redis ist ein In-Memory-Datenspeicher – er hält berechnete Ergebnisse direkt im RAM vor.

Konkret bedeutet das: Wenn WordPress das erste Mal eine komplexe Datenbankabfrage ausführt (z.B. «gib mir die letzten 10 Blogbeiträge mit ihren Kategorien und Autoren»), wird das Ergebnis in Redis gespeichert. Bei der nächsten identischen Anfrage muss WordPress gar nicht erst zur Datenbank – Redis antwortet in Bruchteilen einer Millisekunde.

Das entlastet die Datenbank erheblich und beschleunigt die Seitenauslieferung spürbar, insbesondere bei Seiten mit vielen dynamischen Elementen.

Auch wenn Redis und der Datenbankcluster schon vieles beschleunigen, entsteht bei jedem Seitenaufruf noch Arbeit für PHP und WordPress.

Unser Full Site Caching geht einen Schritt weiter: Es speichert die fertig gerenderte HTML-Seite direkt zwischen. Kommt eine Anfrage für eine bereits erzeugte Seite rein, wird sie ausgeliefert, ohne dass WordPress überhaupt gestartet wird. Der Server liefert statischen HTML-Code aus – so schnell wie es eben geht. Die reine Server Ladezeit beträgt so mit Übertragung zu dir noch 10 – 50 Millisekunden.

Ein gutes Setup bringt wenig, wenn niemand bemerkt, wenn es schlechter wird. Deshalb überwachen wir kontinuierlich:

In unserer Statistik sehen wir welche Anfragen am längsten dauerten – indes wissen wir von jeder Seite, wie schnell sie erzeugt wurde. Bei über drei Millionen Seiten die unser Cluster täglich ausliefert ist das zentral. Eine kleine Veränderung kann in der Masse fatale Folgen haben.

Technologie entwickelt sich weiter, Traffic-Muster verändern sich, neue WordPress-Plugins können plötzlich unerwartete Datenbankabfragen erzeugen. Deshalb ist Performance-Optimierung kein einmaliges Projekt, sondern ein fortlaufender Prozess.

Wir analysieren regelmässig:

Einmal im Monat nehme ich mir ausserdem Zeit, die „langsamsten“ Seiten zu analysieren und deren Ladezeit zu verbessern soweit es noch möglich ist.

Immer öfter erhalten Nutzerinnen und Nutzer Antworten direkt von KI-gestützten Systemen wie ChatGPT, Siri, Gemini oder Alexa, Claude und wie sie alle heissen. Diese Antworten stammen häufig aus öffentlich zugänglichen Inhalten von genau den Websites, die Unternehmen sorgfältig pflegen. Doch was bedeutet das für Websites und Onlineshops? Und wie kann man sich als Unternehmen darauf vorbereiten?

Wenn eine KI eine Produktfrage beantwortet, zum Beispiel „Welches E-Bike ist für den Stadtverkehr geeignet?“, dann geschieht das auf Basis öffentlich verfügbarer Inhalte. Die Informationen dafür stammen meist direkt von Websites, die gut strukturiert, sauber geschrieben und suchmaschinenfreundlich aufgebaut sind.

Anders gesagt: Inhalte auf deiner Website werden nicht nur für Menschen, sondern zunehmend auch für Maschinen erstellt. Und genau diese Maschinen entscheiden, welche Information dem Menschen am Ende angezeigt oder vorgelesen wird – oft ohne dass dieser überhaupt noch die Website besucht.

Diese Entwicklung ist eine Herausforderung und eine Chance. Denn wer seine Inhalte jetzt gut strukturiert und für Maschinen lesbar aufbereitet, kann sich in einer Welt der KI-basierten Antworten einen entscheidenden Vorteil sichern. Zwei Dinge sind dabei besonders wichtig:

Wir setzen bei allen Websites und Onlineshops unserer Kunden bwährte SEO Plugins. Das Plugin hilft durch seine Analyse den Text besonders gut lesbar zu machen. Für Menschen und moderne Sprachmodelle / KI. Es kümmert sich aber auch automatisch um viele technische Details:

Wir arbeiten aktuell an einer NLWeb-Schnittstelle (Natural Language Web), die es allen unseren Kunden ermöglicht, ihre Inhalte noch besser für KI-Systeme nutzbar zu machen. Ziel ist es, Inhalte so bereitzustellen, dass moderne Sprachmodelle noch effizienter darauf zugreifen können: Sei es für Produktempfehlungen, FAQs oder sogar automatisierte Bestellprozesse.

So kann zum Beispiel eine KI bald nicht nur erklären, warum dein Produkt eine gute Wahl ist, sondern es auch direkt für den Kunden in deinem Onlineshop bestellen. Und das ohne, dass der Kunde deinen Onlineshop jemals gesehen hat.

Auch wenn der klassische Website-Besuch nie ganz verschwinden wird: Die Rolle der Website verändert sich. Von einem Ort, den Menschen besuchen, wird sie immer mehr zu einer Wissensquelle für Maschinen. Wer jetzt in saubere Struktur, gute Inhalte und eine KI-freundliche Aufbereitung investiert, ist der Konkurrenz einen Schritt voraus oder wird früher oder später abgehängt.

Wir helfen unseren Kunden, diesen Wandel nicht nur zu verstehen, sondern aktiv mitzugestalten. Denn am Ende gilt: Nur wer für Maschinen lesbar ist, wird auch in Zukunft sichtbar sein.

Rauszufinden, was an den Standard Suchfunktionen von WordPress nicht gut ist, fällt nicht schwer. Was wir angehen müssen ist:

Nach Analyse der verwendeten Suchbegriffe sehen wir Tippfehler als eines der akuten Probleme. Ganz oft gibt es Buchstabendreher, die mit minimaler Intelligenz in der Software korrigiert werden können. Um das zu ermöglichen, müssen wir eine Liste mit korrekten Wörtern haben: Ich habe also einen Index erstellt, der alle Wörter in der gesamten Datenbank enthält, sowie einige Zusatzinformationen wie die Anzahl der Zeichen, die Wortart (sofern möglich) und wie oft das Wort vorkommt.

Mittels einer Kombination der PHP-Funktionen similar_text() und levenshtein() habe ich dann eine Funktion gebaut, die aufgrund des Indexes mögliche Korrekturvorschläge liefert. Durch similar_text() ist es sogar möglich, diese nach „Grad der Übereinstimmung“ zu sortieren. Zu einfachen Buchstabendrehern, aber teilweise auch bei gröberen Schreibfehlern, kann ich so mit grosser Wahrscheinlichkeit das oder die Wörter finden, die der Besucher tippen wollte.

Wörter, die wir in der Datenbank nicht kennen, kann ich so jedoch nicht korrigieren. Doch das ist fürs Erste nicht schlimm, denn ein nicht bekanntes Wort würde in der Suche sowieso zu keinem Ergebnis führen.

Hierbei handelt es sich eher um ein Komfort-Feature, doch es ist nicht unwichtig. Manchmal versucht man, etwas zu finden, weiss aber nicht genau, wonach man suchen muss. Da wir Suchanfragen aufzeichnen und auch deren Ergebnisse kennen, kann ich nun beim Tippen des Suchbegriffs bereits Vergleiche anstellen mit vormals erfolgreichen Suchanfragen. Hierbei habe ich priorisiert, dass gleich beginnende Zeichenketten zuerst erscheinen, danach solche, die mittels similar_text() hinzugefügt werden. Gibt man nun „Tell“ ein, zeige ich die relevantesten Suchanfragen an, wie „Teller Dessert“, „Teller rot“ oder eben auch „Suppenteller“.

Diese Funktion planen wir im weiteren Verlauf der Optimierungen noch weiter zu verbessern. Je mehr Informationen wir hier aufzeichnen können, desto mehr lernen wir und schliesslich auch die Software, wie und wonach die Leute suchen.

Zugegeben, vor diesem Projekt war mir gar nicht klar, was ein Volltextindex in einer SQL-Datenbank eigentlich genau ist. Es ist nicht das gleiche wie ein Index – ich dachte einfach, dass es genau das ist: ein Index für eine Spalte mit Text, also dem Datentyp CHAR, VARCHAR oder TEXT. Ähnlich, aber nicht ganz.

Ein wesentlicher Punkt ist, dass man einen Volltextindex über mehrere Spalten erstellen kann. Das kann, sofern man genau das will, erübrigen, dass man über mehrere Felder mit OR und LIKE sucht, was gerade bei mehr als einem Wort in einem Suchbegriff schnell schwierig wird. Und genau deshalb funktioniert auch die WordPress-Suche mit einem Begriff ganz okay, aber bei mehreren Worten wird’s schon schwierig. Einen Volltextindex hat WordPress weder auf der „posts“- noch auf der „postmeta“-Tabelle.

Im ersten Schritt wollte ich einfach einen Volltextindex über die Titel-, Exzerpt- und Content-Felder erstellen. Doch ich hatte noch ein paar weitere Ideen, um den Index zu füllen. Auch Informationen aus den Kategorien, Schlagworten oder – bei Produkten – deren gesamten Eigenschaften müssen in den Index. Teilweise auch Metadaten, die sonst schwer oder gar nicht auffindbar wären. Und wir leben ja im Zeitalter der KI – warum also nicht auch noch eine oder zwei Spalten von einer KI erzeugen lassen?

All das habe ich getan, in einer eigenen Tabelle, die speziell als Suchindex dient. Besonders eingehen möchte ich auf Letzteres: Mit der ChatGPT-API übergeben wir einen Prompt mit den Informationen zu unserem Inhalt – dies kann ein Beitrag, ein Produkt oder irgendein kundenspezifischer Datentyp sein. Diese Informationen und den vorhandenen Text gebe ich automatisch ChatGPT, um daraus weitere Informationen zu erzeugen.

Ich muss nun selbst definieren, ob ich einen Volltextindex über alle Spalten erstelle oder mehrere Spalten in verschiedene Indizes aufteile. Ich weiss, dass ich mit MATCH und AGAINST in SQL meinen Index (oder mehrere) mittels OR abfragen kann. Wenn ich die Indizes trenne, habe ich die Möglichkeit, einem Index in der Sortierung nach Relevanz mehr Gewicht zu geben.

Im ersten Schritt hatten wir pro Spalte einen eigenen Volltextindex. Das führte zu einem langen Statement mit vielen OR-Bedingungen und einer entsprechend längeren Relevanzberechnung – diese übernimmt MariaDB (wahrscheinlich auch MySQL und jedes andere Datenbanksystem) automatisch bei der Nutzung eines Volltextindex. Die Berechnung fällt je nach Modus unterschiedlich aus, abhängig davon, ob der „Natural Language“- oder der „Boolean“-Mode verwendet wird. Auch hier musste ich zunächst einige Tests durchführen.

Derzeit habe ich es auf zwei Volltextindizes beschränkt: Einen für die eigenen Inhaltsfelder und einen für die von der KI hinzugefügten Inhalte. Je nach Anzahl der Suchwörter und deren Länge wechsle ich im SQL-Statement automatisch zwischen den beiden Modi, da jeder je nach Suchbegriff seine eigenen Vor- und Nachteile hat.

Wie man es aus Onlineshops kennt, kommen sowohl auf Kategorieseiten als auch auf Suchergebnisseiten Filter zum Einsatz, um die Ergebnisse weiter einzuschränken. Ich experimentiere derzeit damit, einzelne Suchwörter aus der Anfrage bei (fast) eindeutigen Ergebnissen automatisch einem passenden Suchfilter zuzuordnen und diesen direkt zu aktivieren.

Gibt jemand beispielsweise „Fussball Übungen Torhüter“ ein, selektieren wir automatisch die Kategorie „Fussball“ sowie die Inhaltsart „Übung“ und durchsuchen die gesamte Datenbank nach Inhalten, in denen eines bis alle dieser drei Wörter vorkommen – sinnvoll nach Relevanz sortiert. In Onlineshops führt dies oft dazu, dass ein allgemeinerer Suchbegriff direkt auf eine Farbe und/oder ein Material eingeschränkt wird. So erkennt der Nutzer sofort, dass er den Filter anpassen und nach weiteren Eigenschaften einschränken kann. Eine voreingestellte Farbe wie „Rot“ kann dann beispielsweise entfernt und durch „Violett“ ersetzt oder ergänzt werden.

Ich plane, dieses Konzept auch für Suchbegriffe mit Zahlen einzuführen – das ist allerdings ein eigenes kleines Projekt. Eine Suche nach „Trinkglas 1,5 – 3 dl“ soll künftig nicht mehr zu „Keine Resultate“ führen sondern Trinkgläser finden mit genau diesem Bereich an Fassungsvermögen. Die kontinuierliche Verbesserung der Suchfunktion steht bei mir regelmässig auf dem Plan, damit die Kunden unserer Kunden genau das finden, wonach sie suchen.