Mit der Zeit wird die Website immer langsamer


Wenn wir Websites in der Wartung betreuen, die wir nicht selbst entwickelt haben, kommt so manche Blüte zum Vorschein.

Das Plugin DSGVO All in one for WP verspricht eine umfassende Lösung für die DSGVO-Absicherung einer Website – bei näherer Betrachtung sehen wir aber weniger ein umfassendes Konzept, sondern eine Sammlung unterstützter Plugins, die irgendwie DSGVO-konform gemacht werden – wer Alternativen nutzen möchte, hat schnell ein Problem. Oder auch wer mehr als 5 eigene Tracking-Scripte einbauen möchte – manche Grenzen wirken beliebig.

Aber wer mit dem Featureset zufrieden ist, für den sollte das Plugin ja eine saubere technische Umsetzung der DSGVO-Anforderungen ermöglichen.

Dazu gehört auch, dass die Reaktionen auf das Cookie-Banner gelogged werden sollten, damit beispielsweise Zustimmungen zum Tracking auch nachträglich noch nachvollziehbar sind – Usercentrics hält hierzu genauso Logs vor.

Es geht jedoch um die Art und Weise, wie DSGVO All in one for WP die Logs speichert.

wp_options ist keine Müllkippe

Daten richtig speichern

Logs haben es an sich, dass sie gerne ein Eigenleben entwickeln – sie fangen sehr klein an – und können monströse Größen annehmen.

Bei unserem Kunden wurde die Größe der wp_options-Tabelle innerhalb von etwa einem halben Jahr um über 450% aufgebläht – von ca. 4,18 MB zu 23,80 MB.

Aufgefallen war uns das, weil ein Import der wp_options-Tabelle über PHPmyAdmin, Plesk und verschiedene SQL-Dump-Scripts fehlschlug – Grund war eine einzelne Insert-Query für ein Feld, das knapp 20 Megabyte Textdaten enthielt – der MySQL-Server brach einfach ab.

Doch nicht nur die Wartung wird so erschwert – auch die Website-Performance nimmt spürbar ab – mit der Zeit immer mehr. WordPress-Options werden standardmäßig bei jedem Seitenaufruf geladen.

Bei jedem Seitenaufruf wird damit die Abfrage gestartet und die Ladedauer der Seite unnötig erhöht.

Best Practice wäre, die Logs in einer eigenen Tabelle zu speichern.

Refactoring & Pair-Programming

Funktioniert doch – reicht nicht

Es geht in diesem Artikel nicht darum, das Plugin eines Entwicklerkollegen zu bashen – die Basisversion ist kostenlos und jeder hat die Möglichkeit Feedback zu äußern, genauso ist dem Plugin Review Team von WordPress das Problem nicht aufgefallen – das Problem tritt erst auf, wenn eine Website länger im Einsatz ist oder viele Besucher hat.

Vielmehr ist das Beispiel exemplarisch dafür, wie architektonische Fehler in der Entwicklung entstehen können und niemandem fallen sie auf.

Ein regelmäßiges Refactoring, Code Reviews von Dritten oder Pair Programming können solche Problemstellen gut adressieren – bis hin zu automatisiertem Testing. All das ist aufwändig, kostet Zeit und Geld.

Auch unsere Software ist davor nicht gefeit und wir alle müssen uns eingestehen, dass es keine perfekte Software geben kann. Dennoch sind solche Fehler natürlich vermeidbar und über kurz oder lang kann eine ausufernde Log-Datei eine Website ganz abschießen.

Bei von uns in der Vergangenheit überprüften DSGVO-Plugins zieht sich jedoch ein roter Faden durch: die rechtliche Exzellenz sticht häufig die technische Exzellenz.

Umso wichtiger ist daher eine technische Prüfung der genutzten oder gewünschten Pluginlösungen für den konkreten Zweck.

Unsere Empfehlung wäre ohnehin grundsätzlich: Kein Cookie Konsens erforderlich, also der Verzicht auf Cookie Banner.