Wie WordPress das Web verstopft: Google Fonts, Gutenberg und mehr
Alexander Trust, den 16. Januar 2020
Macnotes nutzt WordPress, noch. Langfristig wollen wir aber für den datengestützten Journalismus eine eigene Plattform nutzen. Bis dahin müssen wir einen Kompromiss finden zwischen der Ahnungslosigkeit und Ignoranz der WordPress-Entwickler und unseren Anforderungen.
WordPress ist ein wenig wie Apple in den letzten Monaten und Jahren. Ein iOS-Update hat da manchmal mehr kaputt gemacht als repariert.
WordPress und Google Fonts
Das fängt bei WordPress damit an, dass das weitverbreitetste CMS der Welt viel unnötigen Ballast lädt, und zwar auch dort, wo er gar nicht notwendig ist.
Wenn man als Administrator gerne nach dem Log-in eine Bearbeitungsleiste angezeigt bekommen möchte, dann ist das ja „mein“ Bier. Doch unverständlich ist, dass die WordPress-Entwickler viel von dem CSS und JS auch dann laden, wenn ganz normale Nutzer die Webseite besuchen.
Ein Beispiel ist der Google Font „Open Sans“. Dummerweise gibt es spontan nur zwei Möglichkeiten: Den Luxus der Admin-Bar deaktivieren, oder ein Plug-in einsetzen. Tatsächlich haben wir uns für das Plug-in „Disable Google Fonts“ entschieden. Denn nach Studium des Quellcodes von Milan Dinić und der Recherche auf Google stellten wir fest, dass die WordPress-Entwickler leider diese zusätzlichen Kilobyte unnötig kompliziert in den Hauptcode von WordPress integriert haben.
Liebe WordPress-Entwickler: Ladet doch einfach die JS-Bibliotheken und CSS-Dateien nur dort, wo sie gebraucht werden. Bitte. Danke.
Das geht übrigens schon viele Jahre so, und schon viele Jahre fällt mir das auf den Wecker. Als jemand, der sich sehr für das Internet interessiert, hab ich natürlich regelmäßig viele Optimierungen vorgenommen. In den letzten Jahren beschäftigte ich mich jedoch kaum mehr mit WordPress aktiv und musste nun zur Übernahme von Macnotes im November feststellen, dass sich in den Jahren nichts geändert hat. Das ist umso erstaunlicher, da ja eine Reihe von WordPress-Entwicklern zusammen mit Google versucht, das Web zu beschleunigen (AMP).
Gutenberg hat nicht nur Fans
Gutenberg, so heißt der neue WordPress-Block-Editor, der durchaus seine Vorteile haben „kann“. Denn die „Blockifizierung“ von Inhalten führt langfristig zu einer besseren Lesbarkeit durch Suchmaschinen. So ist jedenfalls der Plan. Nicht zuletzt gibt es viele Plug-ins die so auch neue Blöcke, z. B. für Inhaltsverzeichnisse und mikroformatierte Listen anbieten.
Es gibt aber auch viele Gegner von Gutenberg, wie mehr als fünf Millionen aktiver Installationen des Plug-ins „Classic Editor“ zeigen.
Doch was gar nicht geht ist, dass Gutenberg CSS im Frontend lädt, selbst wenn man den Editor gar nicht verwendet. Das heißt „jeder“ Leser muss Kilobytes herunterladen, die er nicht will.
In diesem Fall gibt es zumindest eine einfache Lösung. Packt einfach wp_dequeue_style( 'wp-block-library' ); an eine „passende“ Stelle in die Datei functions.php.
Falls Ihr nicht genau wisst, was die richtige Stelle ist, fügt einfach den folgenden Code in die functions.php ein:
add_action('wp_head', 'sn_scripts_and_styles_header', 1);
function sn_scripts_and_styles_header() {
wp_dequeue_style( 'wp-block-library' );
}
Mit den beiden oben beschriebenen kleinen Änderungen haben wir auch dieser Seite im Geschwindigkeitstest von Google wieder ein paar mehr Punkte verdient.
WordPress ist wie Eisberg und Titanic zusammen
Als am 14. April 1912 die Titanic auf Ihrer Jungfernfahrt sank, nahm auch der Eisberg Schaden. WordPress wirkt auf mich und andere Beobachter manchmal wie die Titanic. Noch ist es nicht zu seiner Jungfernfahrt aufgebrochen, doch falls das passiert, könnte ebenfalls der Untergang drohen.
Warum? Weil WordPress ein Moloch ist, dessen Strukturen viel Ignoranz bieten und wenig Raum für Veränderungen.
Stefan Keller und ich programmierten vor Jahren einige Plug-ins und Funktionen in Eigenregie, um mit vielen Daten im Kontext von WordPress arbeiten zu können. Das Ergebnis war: WordPress nutzt eine unnötig komplizierte Schnittstelle zur Kommunikation mit der Datenbank, die zudem an vielen Stellen künstlich begrenzt wird. Das führt im Ergebnis dazu, dass WordPress „unnötig“ langsam ist.
Plug-ins und Plug-in-Entwickler leiden
Das merkt Ihr zum Beispiel bei vielen Import- oder Export-Plug-ins, oder bei solchen die die Bilder auf dem Server bearbeiten wollen. Wenn die Entwickler nämlich auf die WordPress-Bordmittel vertrauen, dann müssen Sie wahlweise Javascript nutzen, um Timeouts zu umgehen, oder ihre Plug-ins funktionieren immer nur mit „kleinen“ Datensätzen. Ein Export der Artikel von Macnotes nach Ghost bspw. ist auf „einfache“ Weise nicht möglich, da das Ghost-Export-Plug-in irgendwann die Segel streicht. Klar können wir das auch mit einem Dump der Datenbank und einem eigenen Import-Script realisieren. Tragisch ist nur, dass WordPress sich so sehr selbst im Weg steht.
WordPress könnte viel schneller
Für unsere Plug-ins haben wir eine Schnittstelle genutzt, die jeder PHP-Entwickler schon kennt: MySQLi oder wahlweise PDO. Beide Wege zur Kommunikation mit der Datenbank sind schneller als WordPress‘ eigene Methodik. Lustig ist, dass WordPress MySQLi auch intern nutzt, aber selbst eine Abstraktionsebene geschrieben hat, mit der WordPress-Entwickler umgehen (sollen). Diese ist nur extrem langsam.
Aus Spaß an der Freude haben wir damals die Aufgaben wiederholt, und zwar einmal mit einem Plug-in, das die WordPress-eigene Schnittstelle nutzt, und einmal mit unserer eigenen. Es ging damals darum Dateien aus einem fremden CMS in ein WordPress zu importieren. Es ging aber in einem anderen Fall darum zehntausende Beiträge zu parsen und Links auszutauschen. Der Geschwindigkeitszuwachs war immens, teilweise um den Faktor 10, 12 oder noch schneller.
Da wir grundsätzlich auch Freunde des Open-Source sind, stellte Stefan Keller die Lösung den WordPress-Entwicklern in Form eines Tickets vor. Er beschrieb den Flaschenhals und präsentierte die Lösung. Das ist nun sechs oder sieben Jahre her. Passiert ist seitdem nichts.
So und nun wünschen wir viel Spaß beim Vermehren der Erkenntnisse.