Jeder deutschsprachige WordPress-Anwender kennt vermutlich diese kurze PHP-Zeile:

define ('WPLANG', 'de_DE');

Mit dieser einen Zeile wird WordPress deutschsprachig – und jeder Seitenaufruf rund 44 Prozent langsamer.

Im Folgenden zeige ich, warum dieser Performance-Einbruch eintritt und welche Möglichkeiten existieren, dem entgegenzuwirken.

Warum kann WordPress Deutsch?

WordPress verwendet im gesamten Code englische Originaltexte. Zur Lokalisierung der Software in anderen Sprachen muss WordPress Übersetzungen aus zusätzlichen Dateien im verbreiteten PO-Format einlesen. Die deutschsprachige Lokalisierung von WordPress 3.1.x enthält fast 3.200 Textschnippsel für den WordPress-Kern und 87 Übersetzungen für das Theme “TwentyTen”. Je nach Konfiguration kommen dann noch lokalisierte Texte der aktiven Plugins dazu.

Was kostet Zeit?

Ziemlich früh bei jedem Request wird innerhalb von wp-settings.php die Funktion load_default_textdomain() aufgerufen.

Über ein paar weitere Aufrufebenen erreicht WordPress dann import_from_reader(), die tausende kurzer Textschnippsel aus der Sprachdatei des WP-Cores einliest. Wenig später ruft das Theme “TwentyTen” über den Wrapper load_theme_textdomain() ein zweites Mal import_from_reader() auf, um die Übersetzungen der Theme-Texte zu laden.

Die lokalisierten Texte werden für jeden Aufruf der öffentlichen Website, bei jeder Aktion im Backend, bei jedem AJAX-Request und bei der Generierung der XML-Feeds geladen. load_default_textdomain() verbraucht nach meinen Messungen etwa 30 bis über 50 Prozent der gesamten Zeit, die für die Bearbeitung eines Requests nötig ist.

Zusammengefasst heißt das: Ein deutschsprachiges Blog ist für menschliche Besucher, Googlebot und Administratoren wesentlich langsamer als das exakt gleiche Blog auf einem englischen WordPress.

Messmethode

Zur Auswertung der Laufzeit-Unterschiede zwischen der deutsch- und der englischsprachigen Variante habe ich eine lokale WordPress-Installation mit Xdebug vermessen und die so gewonnenen Profiling-Daten für folgende drei Requestrouten mit webgrind visualisiert:

  1. Darstellung von zehn einfachen Posts auf der Blog-Homepage mit dem Standardtheme “TwentyTen”
  2. Aufruf der Dashboard-Übersicht im Backend
  3. Darstellung des RSS-Feeds

Der Testaufbau bestand aus:

  • WordPress 3.2-bleeding r17633
  • Theme “TwentyTen” 1.1
  • Keine aktiven Plugins
  • Lokaler Webserver ohne Last
  • Apache 2.2.9
  • PHP 5.2.6
  • MySQL 5.0.67
  • Xdebug 2.1.1
  • webgrind 1.1
  • Windows 7 SP1

Messergebnisse

Die Zeit, die WordPress benötigt, um einen einzelnen Request zu erfüllen, variiert je nach Route (Frontend, Backend, RSS). In jedem Fall verschlechtert der Wechsel auf die deutsche Sprachdatei die Geschwindigkeit um zweistellige Prozentsätze.

Für die Darstellung der Frontpage mit zehn Blogbeiträgen benötigt die deutsche Fassung fast doppelt so lange wie das englische Pendant, das Backend wird um etwa ein Drittel gebremst und die RSS-Feeds werden über 60% langsamer erzeugt.

Der Webgrind-Report liefert die Laufzeiten jeder einzelnen Funktion, die WordPress zur Generierung der Frontpage aufruft. Sehr schön sieht man hier, dass MO->make_entry() für jedes einzelne Textschnippsel ein Mal aufgerufen wird. 3.273 übersetzte Texte werden in 618 ms geladen.

Webgrind-Analyse der Laufzeiten für das WP-Frontend in Deutsch

Man erkennt deutlich, dass gerade die Lokalisierungsfunktionen aus der POMO-Bibliothek den Löwenanteil der Zeit verbrauchen.

Mit MO->import_from_reader, MO->make_entry, Translation_Entry->key und POMO_REader->substr sind vier der fünf zeitaufwändigsten Funktionen bei jedem Seitenaufruf für die deutsche Übersetzung nötig. Es gilt ein annähernd linearer Zusammenhang: Je mehr übersetzte Texte, desto höher der Zeitbedarf.

Der selbe Ablauf in der englischsprachigen Variante sieht zum Vergleich so aus:

Webgrind-Analyse der Laufzeiten für das WP-Frontend in Englisch

Ein ähnliches Verhältnis ergibt sich auch für das Backend1 und Feeds2.

Die Messung eines Profiling-Durchlaufs auf meinem Testsystem ergab diese in weiteren Durchläufen recht gut reproduzierbaren Laufzeiten:

Route Laufzeit [en] Laufzeit [de] Relative Leistung [de]
Frontend 2343 ms 4327 ms 56%
Backend 3003 ms 4283 ms 70%
RSS-Feed 1129 ms 2952 ms 38%

Diese Zahlen sollte man auf jeden Fall mit ein wenig kritischer Distanz werten: Ich habe Messungen auf einem einzigen System durchgeführt und auf einem zweiten Rechner auf Plausibilität geprüft. Ergebnisse mit Webspace auf anderen Betriebssystemen oder Dateisystemen können abweichen, und ich würde sehr gerne Zahlen von Apple- oder Linux-Systemen zum Vergleich sehen. Trotzdem glaube ich, dass das Lokalisierungspackage in WordPress einen merklichen Anteil an der Performance einer WordPress-Site hat.

In der grafischen Darstellung wird deutlich, wie eklatant der Leistungseinbruch der deutschen Fassung ausfällt:

Leistungsvergleich [en] vs. [de]

Verbesserungspotential

Was kann man tun, um diesen Klotz am Bein los zu werden? Leider habe ich dazu keine ideale Lösung, sondern nur ein paar Denkansätze:

Ein Frontend-Cache ist immer nützlich und hilft auch hier. Die negativen Auswirkungen der Lokalisierung im Backend lindert ein Cache aber nicht.

Eine weitere Möglichkeit wäre, auf die deutsche Sprachdatei komplett zu verzichten. Im Backend findet man sich eventuell auch auf Englisch zurecht, und für das Frontend setzt man einfach ein Theme ein, dass auch ohne Lokalisierung Deutsch spricht.

Drittens könne man einen Vorteil aus der Tatsache ziehen, dass der Leistungseinbruch mit der Zahl der übersetzten Texte zusammenhängt, und eine auf das Wesentliche verkürzte deutsche Sprachdatei einsetzen. Ein radikaler Löschkreuzzug in der Sprachdatei, dem ein paar hundert Hilfetexte oder unbenutzte Texte für WP-Multisite zum Opfer fallen, ist mit Hilfe von Poedit nicht schwierig. Die Ladezeit sinkt mit jedem entfernten Eintrag in der Sprachdatei um etwa 0,3 Promille.

Weitere Verbesserungen erfordern, dass seitens der WordPress-Programmierer an der Optimierung der POMO-Bibliothek selbst gearbeitet wird und zum Beispiel persistente Caches für die translation entries genutzt werden. Das Trac-Ticket dafür gibt es schon

Fußnoten

1 Profilingdaten für das Backend in Englisch und Deutsch.

2 Profilingdaten für den RSS-Feed in Englisch und Deutsch.

13. April 2011, 22:32 − Abgelegt in

Kommentare

Danke für die ausführlichen Erklärungen. Dass ein Blog durch die Übersetzung langsamer wird, war klar. Aber dass der Unterschied so groß ist, überrascht mich doch. Die Möglichkeit die Übersetzung im Frontend auszuschalten wäre ja schon ein Vorteil.

— Tom · 14. April 2011, 10:04 · #

Interessante, ziemlich erschreckende Ergebnisse. Würde das gerne mal an einem Live-Projekt und mit aktivierten Plugins ausprobieren, da dort der Effekt nicht so stark ausfallen dürfte – wenn man davon ausgeht, dass die Plugins ihren ordentlichen Teil zur Ladezeit beitragen. Kann ich eine deutsche Installation ohne großen Aufwand zu einer englischen “downgraden”?

Jan · 14. April 2011, 10:41 · #

Jan, das ist ganz einfach. Kommentiere einfach in der Datei wp-config.php die eine Zeile aus, die WPLANG definiert:

#define ('WPLANG', 'de_DE');

Damit wird WordPress wieder zum native speaker.

— Robert · 14. April 2011, 10:48 · #

Robert, danke, hätte dann doch auch nochmal oben schauen können… nächstes Mal dann ;-)

Habs gerade bei dem Blog probiert, das ich hier auch verlinkt habe – und dabei mit Firebug die Ladegeschwindigkeit des Startseiten-Requests (also exkl. Bilder, JS, …) vorher und nachher beobachtet. Ergebnis: Vorher und nachher rund 1.7s, Gewinn höchstens 100ms. Hab ich einen Punkt übersehen? Die Datumsausgabe war nach der Umstellung englisch, scheint also geklappt zu haben. Caching-Plugins sind nicht vorhanden.

— Jan · 14. April 2011, 12:08 · #

Sehr aufschlussreich das Ganze, danke.

Damit mal eindrücklich dargestellt, was man eh schon irgendwie wusste/ahnte.
(Zusätzlich zu der Tatsache dass die Sprachdatei je nach Server auch noch einige MB PHP-Arbeitsspeicher frisst.)

jottlieb [WordPress Deutschland] · 14. April 2011, 12:29 · #

Sehr interessante Ermittlung!

Das hat mich vor allem – sozusagen im Nachhinein – interessiert, da ich seit geraumer Zeit wegen der enormen Problemen mit dem zur Verfügung stehenden PHP-Ausführungsspeicher (seit ca. WP 2.8x) ganz auf die deutsche Sprachdatei verzichte. Mit dieser waren seinerzeit meine beiden Blogs kaum noch betreib- und administrierbar.

Es gibt also nicht nur das hier ermittelte Zeitverhalten, sondern auch einen enormen Ressourcenverbrauch durch die deutsche Sprachdatei.

Tatsächlich muss ich in meinen Frontends lediglich dafür sorgen, dass die Monatsnamen auf deutsch ausgegeben werden, was ich einfach durch manuelle Eindeutschung in der entsprechenden Kerndatei erledige. Bei Updates aktualisiere ich das dann eben per Copy&Paste des betreffenden Programmblocks.

Mit dem englischsprachigen Backend habe ich zum Glück keine Probleme.

Boris · 14. April 2011, 15:03 · #

Man das Ergebnis ist erschreckend.
Ich nutze zum Glück ein Cache Plugin. Werde die nächsten Tage versuchen auf Englisch umzustellen, weil mich der lahme Adminberreich doch sehr nervt. Und hoffe, dass man im offiziellen Bereich nichts anmerken wird, weil im Adminberreich ist Englisch ja nicht schlimm.

— Patrick Hausmann · 14. April 2011, 21:04 · #

Hallo,

die verwendete PHP 5.2.6 ist veraltet. Des weiteren ist PHP 5.3 schneller.

Die PHP Entwickler haben PHP von einem veralteten, Flex-basierten Lexer auf re2c umgestellt. Die aktuelle PHP 5.3 wurde dadurch um bis zu 30 Prozent schneller.

Re2c kommt bei PHP bereits seit geraumer Zeit z.B. zur Serialisierung zum Einsatz. Mit PHP 5.3 löst re2c nun auch den bisher verwendeten Flex-basierten Lexer ab, wovon sich die PHP-Entwickler eine höhere Geschwindigkeit versprechen.

Benchmarks der aktuellen PHP 5.3 mit PHP 5.2, die Dmitry Stogov vor Monaten veröffentlichte, zeigen: PHP 5.3 bis zu 30 Prozent schneller als sein Vorgänger.

Wenn man auf Geschwindigkeit keit aus, warum verwendet man dann eine Ente beim “testen”?

Ralf Dreiundzwanzig · 15. April 2011, 07:46 · #

Ralf,

die Mindestanforderung für WordPress 3.2 ist PHP 5.2.4.

85 Prozent der WordPressen laufen mit PHP 5.2, sechs Prozent mit PHP 5.3, sagt die Statistik von gestern.

Ich halte es daher für sinnvoll, nicht die jüngste, sondern eine unter WordPress-Anwendern weit verbreitete Umgebung vulgo “Ente” zu testen.

Robert · 15. April 2011, 09:07 · #

Die Geschwindigkeit ist nicht das Problem sondern der Speicherhunger mit aktivierter dt. Sprachdatei – gibt es – ausser das DE auszuschalten – keine Lösung hierzu?

Hody · 15. April 2011, 22:59 · #

Ehrlich gesagt geht der Test aufgrund der falschen Plattform etwas nach hinten los. Auf Produktivsystemen ist heutzutage i.d.R. ein Unix-basiertes Betriebssystem (z.B. Linux oder FreeBSD) im Einsatz.

cu, w0lf.

fwolf · 18. April 2011, 04:03 · #

Das sind jetzt aber wirklich deutliche Unterschiede und erklärt nun auch die Performance von 2 Blogs von mir (gleicher Inhalt in Deutsch und Englisch). Danke für deine Mühe!

Andreas · 19. April 2011, 15:36 · #

Ja, das ist mir auch vermehrt aufgefallen. Trotzdem einmal vielen Dank für die ausführliche Erläuterung, warum das so ist, und wie man dem entgegen wirken kann. Für mich sind im SEO Bereich Ladezeiten durchaus wichtig.

— Baffy Scorpion · 19. April 2011, 16:17 · #

Vielen Dank für die detaillierte Ausführung. Da ich momentan generell auf das Cachen verzichte, habe ich WordPress jetzt erstmal komplett auf Englisch umgestellt. Es ist schon ein enormer Unterscheid, den man auch deutlich spüren kann.

Tom · 19. April 2011, 17:16 · #

Bin grade auf Euren Blog gestoßen durch die Vorträge auf der WordCamp 2011 in Köln, wo wir auch zu Hause sind.

Ich denke, dass die Ladezeiten auf abhängig sind vom WebHosting-Provider und deren Einstellungen. So denke ich, dass die Ladezeiten wesentlich geringer ausfallen könnten. Nichts desto trotz, sollte daran gearbeitet werden. Spätestens mit Multisite wird das ganze ja dann wieder sehr spannend und wertvoller.

— Conni · 25. September 2011, 00:35 · #

@Hody: Das garstige ist ja auch, daß gerade große Hoster in Deutschland teilweise drastisch den zur Verfügung stehenden Speicher beschränken. Teils soweit, daß sogar ein automatischen Update unmöglich ist! Ich persönlich habe keine schlechten Erfahrungen mit soliden Hostern in den USA gemacht, trotz der Entfernung bessere Performance, weil die Server nicht so mit Kunden vollgestopft werden.

— Tatjana · 6. Februar 2012, 10:19 · #

Ich hab für unseren Verein eine Multiuser-Umgebung aufgebaut und nur wenige Plugins aktiviert. Trotzdem gibt es schon beim Upload von Bildern und Switch von HTML zu Visuell beim Verfassen von Beiträgen massive Probleme. Die Abschaltung der deutschen Sprachdatei ist leider keine Alternative, da Vereinsmitlieder kein englisches Backend wünschen. Bleibt wohl nur ein Wechsel zu einem anderen Hoster? Schade, dass der Speicherhunger immer größer wird!

Bernhard vom TV Ebern · 26. April 2012, 20:59 · #

Kommentarfunktion für diesen Artikel geschlossen.