Dieses Thema ist gelöst. Hier finden Sie eine Beschreibung des Problems und der Lösung.
Problem: Sie verwenden WPML auf Ihrer Website und haben festgestellt, dass WPML die längste Ausführungszeit von 1,5 Sekunden aufweist, was 7-mal länger ist als das nächstlangsamste Plugin. Sie möchten wissen, warum WPML so lange braucht und was das Plugin auf der Hauptseite macht. Solution: Die lange Ausführungszeit von WPML ist hauptsächlich auf die Überprüfung und Verarbeitung von mehrsprachigen Inhalten zurückzuführen, auch wenn diese nicht direkt sichtbar sind. WPML prüft, ob Inhalte in anderen Sprachen vorhanden sind oder ob Fallbacks erforderlich sind. Dies geschieht durch Abfragen auf Tabellen wie
icl_translations
und Funktionen wie
wpml_object_id()
. Zur Optimierung Ihrer Website-Leistung mit WPML empfehlen wir: 1) Aktivieren Sie Object Caching (z. B. Redis oder Memcached), um wiederholte WPML-Abfragen effizient zu verarbeiten. 2) Testweise die Option „Adjust IDs for multilingual functionality“ deaktivieren, um zusätzliche Last zu reduzieren. Überprüfen Sie jedoch, ob Ihr Theme danach noch korrekt funktioniert. 3) Die Nutzung eines CDN (z. B. Cloudflare oder BunnyCDN) kann helfen, die Auslieferung von statischen Dateien zu beschleunigen und die Serverlast zu reduzieren.
Diese Lösung könnte aufgrund neuerer Updates oder spezifischer Konfigurationen Ihrer Website irrelevant sein. Wir empfehlen Ihnen, die bekannten Probleme zu überprüfen, die Version der dauerhaften Lösung zu bestätigen und sicherzustellen, dass Sie die neuesten Versionen von Themes und Plugins installiert haben. Sollten weiterhin Probleme auftreten, zögern Sie nicht, ein neues Support-Ticket zu eröffnen. Besuchen Sie unser Support-Forum für weitere Unterstützung.
Dies ist das technische Support-Forum für WPML – das mehrsprachige WordPress-Plugin.
Mitlesen können alle, doch nur WPML-Kunden können hier Fragen veröffentlichen. Das WPML-Team antwortet im Forum an 6 Tagen pro Woche, 22 Stunden am Tag.
Sie können die Ergebnisse direkt hier oder via versteckter Link hochladen und hier den Link teilen. Dann sehen wir exakt, welche Query am meisten dazu beiträgt - und ob es überhaupt die DB ist, welche den Load verursacht.
Bei der Analyse sind einige etwas langsamere WordPress-Queries aufgefallen. Die eigentlichen Performance-Bremsen stammen jedoch hauptsächlich von WP Statistics – insbesondere folgende Abfragen:
sql
Copy
Edit
SELECT `visitor`.`last_counter` AS `date`, COUNT(DISTINCT `visitor`.`ID`) AS `visitors`, ...
-- Dauer: 166,9 ms
sql
Copy
Edit
SELECT `visitor`.`last_counter`, SUM(DISTINCT `pages`.`count`), ...
-- Dauer: 23,5 ms
WPML selbst verursacht zwar viele einzelne Queries, z. B.:
sql
Copy
Edit
SELECT * FROM omp_icl_mo_files_domains
-- Dauer: 1,5 ms
Diese sind jedoch einzeln betrachtet nicht besonders langsam. Allerdings gilt: die Menge an WPML-Abfragen summiert sich und kann so die Gesamtperformance negativ beeinflussen.
Vorschlag für das weitere Vorgehen:
Bitte stellen Sie eine Staging-Umgebung zur Verfügung, die identisch mit der Live-Seite ist. Wir führen dort ein Performance-Profiling durch – einmal im aktuellen Zustand und einmal mit deaktiviertem WPML.
Anschließend vergleichen wir die Ergebnisse und können gezielt Optimierungspotenzial identifizieren. Gerne übernehme ich die Analyse, sobald die Staging-Umgebung bereitsteht.
Mit Default-Theme + andere Plugins alle aktiv (außer RankMath, da sonst Query-AUsgabe mit Fehler):
261 Queries, 294,4ms
Nur WPML aktiv, mit Default-Theme:
128 Queries, 46,1ms
Nur WPML aktiv + Ihr X-Child-Theme
127 Queries, 49,4ms
So ein richtiges Performance-Problem kann ich in diesen Werten jedoch von WPML nicht erkennen.
Und ich würde generell gerne verstehen, warum WPML überhaupt Ressourcen beim Aufruf meiner Seite benötigt?
WPML ist auch im Frontend aktiv, weil es bei jedem Seitenaufruf die aktive Sprache erkennen, Inhalte filtern und sprachabhängige Elemente wie Menüs, Links oder hreflang-Tags korrekt darstellen muss. Dafür greift WPML in zentrale WordPress-Prozesse ein und führt eigene Datenbank-Queries aus – auch wenn automatische Übersetzungen nur im Backend genutzt werden. Ohne diese Mechanismen würde die Seite nicht mehrsprachig funktionieren.
Können Sie es bitte dort ebenso mal isoliert testen?
Nur WPML aktiv, mit Default-Theme:
128 Queries, 46,1ms
Startseite ohne Änderungen:
327 Queries, 364,4ms
Das heißt, 40% der Queries kommen NUR durch WPML. Also ich finde das einen extrem hohen Wert, Du nicht?
Ich habe ja echt viele Plugins auf meiner Seite aktiv, wenn die alle 128 Queries nutzen würden...
>...Inhalte filtern und sprachabhängige Elemente wie Menüs, Links oder hreflang-Tags korrekt darstellen muss.
Das würde ich für die übersetzen Sprachen vielleicht noch verstehen, aber warum auch bei der Default Sprache? Wenn ich WPML deaktiviere, würde mir die Default Sprache ja auch genauso angezeigt werden. Ich verstehe nicht, was WPML hier macht, außer vielleicht den Sprachumschalter anzuzeigen und von mir aus ein hreflang-Tag zu setzen?
Und ich verweise nochmal auf meinen Ursprungs-Beitrag mit der Analyse und dem Screenshot des Code Profiler. Da sieht man schon ein Performance Problem von WPML, oder nicht?
die Anzahl der Datenbankabfragen (Queries) ist in diesem Fall nicht wirklich relevant. Die Gesamt-Ladezeit der DB liegt bei lediglich 46 ms. Der Großteil der Ladezeit entfällt auf andere 3rd-Party-Komponenten.
Zu Code-Profiler:
Der Code Profiler misst die interne PHP-Ausführungszeit. Dabei wird erfasst, wie viel Zeit jede Komponente benötigt, um ihren Anteil beim Generieren der Seite im Backend zu leisten. Es handelt sich hierbei jedoch nicht um reale Ladezeiten für Besucher, sondern um einen rein technischen Snapshot – unter Laborbedingungen, ohne Page Cache, CDN oder Browser-Einflüsse.
In Ihrem Fall zeigt der Profiler, dass WPML mit ca. 1,5 Sekunden die meiste Ausführungszeit beansprucht. Das bedeutet jedoch nicht automatisch, dass WPML für ein spürbares Performanceproblem verantwortlich ist, denn:
- In Live-Systemen wird ein Großteil dieser Prozesse durch Page-Caching (z. B. WP Rocket welces aktiv ist) gar nicht erst ausgeführt.
- Viele WPML-Funktionen profitieren zusätzlich von Object Caching (z. B. Redis), wodurch wiederholte Abfragen nicht erneut verarbeitet werden müssen.
- Die gemessene Zeit wirkt sich nur auf nicht gecachte Seiten aus – etwa beim ersten Aufruf oder für eingeloggte Nutzer.
WPML in der Default-Sprache
Auch auf der Startseite in der Standard-Sprache (z. B. Deutsch) ist WPML aktiv, da es im Hintergrund prüft, ob Inhalte in anderen Sprachen vorliegen oder ob Fallbacks nötig sind (z. B. bei Medien oder Taxonomien haben Sie das aktiv). Dafür nutzt es unter anderem Abfragen auf Tabellen wie icl_translations und Funktionen wie wpml_object_id().
Diese Architektur ist bewusst so aufgebaut: Jede Übersetzung ist technisch ein getrennter Post-ID, verbunden über ein gemeinsames Feld (trid) in der Datenbank. WPML behandelt daher alle Sprachversionen gleich, um konsistente Ergebnisse zu gewährleisten. Auch Plugins wie Yoast SEO oder RankMath greifen im Frontend aktiv ein, obwohl ihre Ergebnisse oft „unsichtbar“ sind (Canonical-URLs, hreflang, Meta-Tags). WPML arbeitet ähnlich – im Hintergrund, aber systemrelevant.
Zur Optimierung:
1) Object Caching aktivieren (z. B. Redis oder Memcached), um wiederholte WPML-Abfragen effizient abzufangen.
2) Die Option „Adjust IDs for multilingual functionality“ testweise deaktivieren – sie kann zusätzliche Last verursachen. Wichtig: Bitte prüfen Sie, ob mit Ihrem Theme danach weiterhin alles funktioniert. In meinem Test löste dies etwa 5 zusätzliche Queries sowie 5ms Ladezeit zusätzlich aus.
3) Die Nutzung eines CDN (z. B. Cloudflare oder BunnyCDN) kann die Auslieferung von statischen Dateien wie JavaScript und CSS entlasten. Das reduziert die Gesamtserverlast, wodurch WPML und andere PHP-Prozesse mehr Ressourcen zur Verfügung haben – indirekt also ebenfalls vorteilhaft für die Performance.
