WPML Performance-Triage – langsamer Admin-Bereich, Timeouts im Übersetzungs-Dashboard, Verzögerungen im Frontend

Bestätigen Sie, wo die Verlangsamung auftritt

• Frontend langsam, Admin-Bereich in Ordnung → wahrscheinlich Konfiguration des Full-Page-Cachings oder ein frontend-lastiges Plugin.
• Admin-Bereich langsam, Frontend in Ordnung → wahrscheinlich Autoload-Bloat in wp_options, ein ressourcenintensives Plugin nur für den Admin-Bereich oder ein zu schwacher Server.
• Speziell das Übersetzungs-Dashboard ist langsam → wahrscheinlich eine große Anzahl von Beiträgen in der Dashboard-Abfrage und nicht genügend PHP-Speicher oder Ausführungszeit.
• Übersetzungsvorgänge langsam → wahrscheinlich Verbindung zu Übersetzungsdiensten; überprüfen Sie das Kommunikationsprotokoll unter WPML > Support (siehe Protokolle, um zu sehen, welches Protokoll welches Symptom beantwortet).

Überprüfen Sie die Serverressourcen

Öffnen Sie WPML > Support. Das Warnungs-Panel oben markiert PHP-Speicher unter den von WPML empfohlenen 256 MB. Websites mit größeren Katalogen benötigen 512 MB oder mehr.

Weitere Symptome in Bezug auf Serverressourcen:

• Langsame Datenbankabfragen. Große Websites mit vielen Übersetzungen profitieren von einem SSD-gestützten Datenbankserver, ausreichendem innodb_buffer_pool_size und Indizes in der Tabelle wp_icl_translations (diese werden von WPML hinzugefügt; manuelle Eingriffe sind selten erforderlich).
• PHP-Ausführungszeit. Wenn max_execution_time unter 60 Sekunden liegt und das Dashboard ein Timeout aufweist, erhöhen Sie den Wert.
• CPU. Shared-Hosting-Pläne haben oft aggressive CPU-Limits; prüfen Sie mit Ihrem Hoster, ob Sie gedrosselt werden.

Object-Cache

WordPress ohne einen Object-Cache lädt viele der Einstellungen von WPML bei jeder Anfrage aus der Datenbank. Fügen Sie Redis oder Memcached als Object-Cache hinzu (die meisten Managed-WordPress-Hoster bieten dies an; falls nicht, aktivieren die Plugins Redis Object Cache oder WP Redis dies).

Die Verbesserung ist in der Regel enorm. Einstellungen, die zuvor Datenbankzugriffe erforderten, werden aus dem Arbeitsspeicher bereitgestellt.

Full-Page-Cache

Ein Full-Page-Cache (WP Rocket, W3 Total Cache, Edge-Cache des Hosting-Anbieters) ist der größte einzelne Performance-Gewinn für die Frontend-Geschwindigkeit.

Wenn Sie bereits einen haben, sich die Seiten aber immer noch langsam anfühlen, überprüfen Sie, ob Ihr Cache die URLs pro Sprache korrekt verarbeitet. Die URL-Struktur von WPML (egal ob Sprache als Verzeichnis, Sprache als Subdomain oder Sprache als Domain) erfordert, dass der Cache nach URL variiert. Die meisten Caches tun dies automatisch, aber es lohnt sich zu überprüfen, ob die französische Version nicht aus dem englischen Cache ausgeliefert wird oder umgekehrt.

In Konflikt stehende oder langsame Plugins

Websites sammeln Plugins an; einige sind gut programmiert und andere nicht. Um ein langsames Plugin zu finden:

1. Installieren Sie Query Monitor (ein Debugging-Plugin).
2. Laden Sie eine langsame Seite neu.
3. Sehen Sie sich Queries by Component an. Das Plugin mit den ressourcenintensivsten Abfragen ist der Verdächtige.

Wenn ein Plugin die Ursache ist, ersetzen Sie es oder deaktivieren Sie die Funktion darin, die die Verlangsamung verursacht.

Übersetzungsdienste sind langsam, nicht die Website

Wenn sich Übersetzungsaufträge langsam anfühlen, die Website selbst aber in Ordnung ist, liegt der Engpass zwischen Ihrer Website und der Übersetzungsinfrastruktur von WPML.

Überprüfen Sie WPML > Support > Kommunikationsprotokoll. Das Protokoll zeigt die Latenz jedes API-Aufrufs. Wenn einzelne Aufrufe viele Sekunden dauern, liegt das Problem an der Konnektivität (Netzwerkpfad, DNS oder die ausgehende Drosselung Ihres Hosting-Anbieters), nicht an der Website. Wenn stattdessen der WPML-eigene Cache der Übeltäter ist, enthalten die sicheren Tools zur Fehlerbehebung die Option Cache in WPML leeren. Wenn die Performance-Untersuchung die Augen des Supports erfordert, verpacken Sie Ihre Erkenntnisse über Debug-Informationen mit dem Support teilen.