[Geschlossen] Website wird durch WPML drastisch verlangsamt – Ergebnisse des Code Profilers (WPML 4.7.6)
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.
Hintergrund des Themas:
Ich versuche, die Lade- und Reaktionszeiten meiner Website zu verbessern, die durch WPML drastisch verlangsamt werden. Ich habe Diagramme und CSV-Dateien der Profiling-Ergebnisse sowie Debug-Infos aus 'WPML → Support → Troubleshooting → Debugging Info' angehängt. Die Seite, auf der das Problem zu sehen ist: versteckter Link.
Die Symptome:
WPML Multilingual CMS 4.7.6 benötigt ca. 20–21 Sek. der Gesamt-Ausführungszeit, WPML String Translation weitere ~4 Sek. TTFB ist über 5 Sek. bei jeder ungecachten Anfrage, und die Gesamtseiten-Ladezeit beträgt ~30 Sek., wobei 70 % durch WPML Multilingual CMS und ~13 % durch WPML String Translation verursacht werden. Die Produktion ist betroffen, die Staging-Umgebung nicht.
Fragen:
Warum verlangsamt WPML meine Website so drastisch?
Wie kann ich die Ladezeiten und TTFB verbessern?
Weitere bereits geprüfte Punkte (alle ohne Verbesserung):
Standard-Theme-Test: Website mit Hello Elementor und Twenty Twenty-Four geladen → gleich langsame Antwortzeiten.
Plugin-Konflikte ausgeschlossen:
Alle Plugins bis auf WooCommerce, ACF und WPML-Suite deaktiviert → Performance unverändert.
Danach nur WPML Multilingual CMS + WooCommerce aktiv → TTFB immer noch > 5 s.
Caching geleert: Server-Cache, Objekt-Cache (Redis) und alle Browser-Caches gelöscht.
bevor Ihr Ticket einem meiner Kollegen zugewiesen wird, erlauben Sie mir bitte, Sie durch einige erste Schritte zur Fehlersuche zu führen.
AM besten stellen Sie die Debug Info und die Profiling-Ergebnisse über einen Share wie z.B.: WeTransfer bereit oder Sie laden diese Dateien auf Ihrem Server hoch und teilen den Link hier.
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.
SELECT COLLATION_NAME
FROM information_schema.columns
WHERE TABLE_SCHEMA = 'wp_medic_db3' AND TABLE_NAME = 'wp_icl_strings' AND COLUMN_NAME = 'context'
Vielen Dank fürs Teilen. Ich würde mir das gerne direkt auf Ihrer Seite ansehen. Dazu bräuchte ich bitte temporären Zugriff (WP-Admin und FTP) auf Ihre Seite, vorzugsweise zu einer Test/Staging Seite, an der das Problem nach Möglichkeit repliziert wurde.
Die dafür benötigten Felder finden Sie unterhalb des Kommentarbereichs. Die Informationen, die Sie eingeben, sind privat, d.h. nur Sie und ich können sie sehen und haben Zugriff darauf.
Vielleicht muss ich Ihre Website lokal replizieren. Dazu muss ich vorübergehend ein Plugin namens "Duplicator" oder "All in One WP Migration" auf Ihrer Website installieren. Dadurch kann ich eine Kopie Ihrer Website und Ihrer Inhalte erstellen. Sobald das Problem behoben ist, werde ich die lokale Website löschen. Lassen Sie mich wissen, ob dies für Sie in Ordnung ist.
WICHTIG
Bitte erstellen Sie eine Sicherungskopie der Site-Dateien und der Datenbank, bevor Sie uns Zugang gewähren.
- Wenn Sie die wp-admin/FTP-Felder nicht sehen, bedeutet dies, dass Ihre Post- und Website-Login-Daten ÖFFENTLICH gemacht werden. Posten Sie Ihre Website-Details NICHT, wenn Sie die erforderlichen wp-admin/FTP-Felder nicht sehen. Wenn Sie das nicht tun, bitten Sie mich, die private Box zu aktivieren. Die private Box sieht wie folgt aus:
Vielen Dank, dass Sie den Zugang geteilt haben. Ich hole gerade eine zweite Meinung bei meinen Kollegen ein und werde mich bei Ihnen melden, sobald ich eine Rückmeldung erhalte oder weitere Informationen von Ihnen benötige.
Hallo,
vielen Dank für die Rückmeldung. Gerne stellen wir Ihnen die benötigten Details zur Verfügung:
1. Betroffene Seiten / Inhalte
Das Performance-Problem betrifft insbesondere alle Seiten (Pages) – auch im ungecachten Zustand. Die Ladezeit bis zur ersten sichtbaren Anzeige (First Contentful Paint) liegt bei 8–12 Sekunden, was deutlich zu hoch ist.
Beispielhafte betroffene URLs:
versteckter Link versteckter Link
und alle anderne Seite
2. Konkrete Tests und Beobachtungen
RankMath und WPML scheinen in Wechselwirkung zu stehen.
Wenn RankMath aktiv ist und WPML deaktiviert, gibt es keine Performance-Einbrüche.
Wenn jedoch beide aktiv sind, treten signifikante Ladezeitprobleme auf.
Wir konnten durch gezieltes Debugging und Ausschlussverfahren WPML als mitverantwortlich identifizieren, auch wenn die grundsätzliche Langsamkeit von WPML bekannt ist.
Zusätzlich haben wir RankMath kontaktiert, da sich bei Verwendung des "Detective.me"-Plugins (SEO-Alternative zu RankMath) ein Geschwindigkeitsvorteil von ca. 30 % ergibt – bei gleicher Seitenstruktur und gleicher WPML-Konfiguration.
Es wurde kein Unterschied zwischen gecachten und ungecachten Seiteninhalten festgestellt – die Verzögerung tritt in beiden Fällen auf.
Inzwischen haben wir den Einflussbereich weiter isolieren können, indem wir einzelne Plugin-Kombinationen getestet und Caching sowie Skriptladeverhalten überprüft haben.
3. Erwünschte Tests
Bitte prüfen Sie insbesondere den folgenden Workflow:
WordPress-Installation mit aktiviertem RankMath UND WPML, auf mehrsprachigen Seiten, insbesondere im Frontend-Ladeprozess einzelner Seiten.
Dabei beobachten Sie bitte die Time-to-First-Byte (TTFB), First Contentful Paint (FCP) und Gesamtladezeit.
Falls benötigt, können wir temporäre Zugangsdaten oder eine Stage-Umgebung zur Verfügung stellen.
vielen Dank für Ihre Geduld. Ich habe eine Rückmeldung vom Second-Tier-Support erhalten:
„Die Performance mit einem Plugin zu testen, ist keine verlässliche Methode zur Leistungsbewertung, da die Ergebnisse wahrscheinlich durch bestimmte Funktionen beeinflusst werden und selten auf die wahre Ursache hinweisen. Es kann zwar den Anschein erwecken, dass WPML die Ladezeit verursacht, aber in der Regel liegt das Problem in einer Funktion oder einem Code, der WPML zu dieser Ladezeit zwingt.“
Nachdem wir eine Kopie Ihrer Website mit den Entwicklern geteilt haben, konnten sie keine konsistenten Performance-Ergebnisse feststellen. Bitte sehen Sie sich dazu das Bild an, auf dem Elementor aufgeführt ist.
Die Einstellung „CSS Print Method“ in Elementor – auf „Externe Datei“ gesetzt – scheint die Performance lokal deutlich zu verbessern. Auch hierzu finden Sie einen Hinweis im Screenshot.
vielen Dank für deine Nachricht und das Teilen des Feedbacks vom Second-Tier-Support.
Wir haben die empfohlene Änderung – die Einstellung der CSS Print Method auf „externe Datei“ – gestern Abend testweise umgesetzt. Leider hat sich direkt nach der Umstellung sowohl der PageSpeed verschlechtert als auch ein markanter Einbruch in den Sales-Zahlen im Vergleich zum Vortag gezeigt. Aus diesem Grund haben wir die Einstellung vorerst wieder zurückgesetzt.
Zur Einordnung: Wir hatten die „externe Datei“-Option damals deaktiviert, da es wiederholt zu Problemen mit dem Caching und den WPML-Übersetzungen kam – insbesondere in Kombination mit dem früher eingesetzten W3 Total Cache.
Unabhängig davon haben wir das Verhalten der Seite auch intern mit unseren eigenen Server- und Performance-Spezialisten analysiert. Dabei konnten wir WPML als ursächlichen Trigger für die verlängerten Ladezeiten identifizieren. Natürlich kann ein externes Tool nicht immer die tiefste Ursachenanalyse liefern – aber:
In dem Moment, in dem wir WPML deaktivieren und der Shop schlagartig um bis zu 80 % schneller lädt, ist es aus unserer Sicht eindeutig, dass WPML die zentrale Ursache ist. Diese starke Korrelation lässt sich kaum anders interpretieren, insbesondere da keine anderen Änderungen vorgenommen wurden.
Wir möchten euch daher bitten, diese Hinweise ernst zu nehmen und uns bei der Ursachenforschung aktiv zu unterstützen. Wir sind gerne bereit, weitere technische Details, Screencaptures oder Debugging-Daten zur Verfügung zu stellen, um gemeinsam eine nachhaltige Lösung zu erarbeiten.
Leistungsprobleme sind in der Tat oft komplex – das verstehe ich gut. Zu den von Ihnen genannten Punkten:
1. „Dabei konnten wir WPML als ursächlichen Trigger für die verlängerten Ladezeiten identifizieren.“
2. „In dem Moment, in dem wir WPML deaktivieren und der Shop schlagartig um bis zu 80 % schneller lädt, ist es aus unserer Sicht eindeutig, dass WPML die zentrale Ursache ist.“
Haben Sie dazu einen Bericht, Screenshot oder eine andere Art von Vergleich, die das belegt? So hätte ich stärkere Argumente, um das Problem an unser 2nd-Tier-Team weiterzuleiten.
Das Thema '[Geschlossen] Website wird durch WPML drastisch verlangsamt – Ergebnisse des Code Profilers (WPML 4.7.6)' ist für neue Antworten geschlossen.
