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.
Hallo,
ich habe aktuell massive Performance Probleme.
Ich habe eine Staging Seite, die identitsch ist zur Live Seite bis auf WPML, Google Site Kit und Bing URL Submission. D.h. WPML, Google Site Kit und Bing URL Submission sind nur auf der Live Seite aktiv. Google Site Kit und Bing URL Submission hatte ich temporär deaktiviert ==> keine Prformance Verbesserung, d.h. das Problem hat mit WPML zu tun, da es der einzige Unterschied zwischen Staging und Live ist.
Das Live Frontend braucht zum Laden ca. 1,5 mal so lang wie das Staging Frontend, das Backend braucht doppelt so lang!
Bitte um Unterstützung
Schönen Gruß
Thomas
Hallo Marcel,
ich habe mit der Debug Bar das Dashboard meines Backends untersucht. Die mit Abstand langsamste Abfrage stammt vom Real Cookie Banner. Die gleiche Abfrage ist auf meiner Staging Seite, wo WPML nicht installiert ist, mehr als 10 mal schneller.
SELECT
pm.meta_id AS post_version_meta_id,
pm.post_id,
pm.meta_value AS post_template_version,
prid.meta_value AS post_template_identifier,
p.post_title, p.post_type,
templates.version as should
FROM xxxx_postmeta pm
INNER JOIN xxxx_postmeta prid
ON prid.post_id = pm.post_id
INNER JOIN xxxx_posts p
ON p.ID = pm.post_id
INNER JOIN xxxx_rcb_template templates
ON BINARY templates.identifier = BINARY prid.meta_value
AND templates.context = 'de_DE'
AND templates.is_outdated = 0
AND templates.type = (
CASE
WHEN p.post_type = 'rcb-cookie' THEN 'service'
ELSE 'blocker'
END
)
WHERE pm.meta_key = 'presetVersion'
AND pm.meta_value > 0
AND prid.meta_key = 'presetId'
AND p.post_type IN ('rcb-blocker', 'rcb-cookie')
AND templates.version <> pm.meta_value
require_once('wp-admin/admin-header.php'), do_action('admin_notices'), WP_Hook->do_action, WP_Hook->apply_filters, DevOwl\RealCookieBanner\view\UpdateNotice->admin_notices, DevOwl\RealCookieBanner\view\UpdateNotice->needsUpdate
Ich werde dort auch mal nachhaken. Wie gesagt ist dies das Real Cookie Banner, aber nur auf der Live Seite, wo auch WPML installiert ist.
Mit dem o.g. SQL Statement sind wir auf der falschen Fährte, auch wenn es mit über 200ms im Backend Dashboard das mit Abstand langsamste ist.
Es geht um ganz andere Größenordnungen, wobei ich zugeben muss, dass meine Seite - bei einem Massenhoster gehostet - ohnhin nicht die schnellste ist.
Ich habe das Real Cookie Banner temporär deaktiviert, und das Performance Problem bleibt bestehen.
Beispiele (mit Query Monitor gemessen):
1. Frontend Warenkorb
* Staging Seite mit RCB aber ohne WPML: Ladezeit 3,5 bis 4 Sekunden
* Live Seite mit RCB und mit WPML: Ladezeit 6 bis 7 Sekunden
* Live Seite keine Änderung bei temporärer Deaktivierung des Real Cookie Banners!
2. Backend wp-admin/plugins.php
* Staging Seite mit RCB aber ohne WPML: Ladezeit 4 bis 5 Sekunden
* Live Seite mit RCB und mit WPML: Ladezeit 8 Sekunden
* Live Seite keine Änderung bei temporärer Deaktivierung des Real Cookie Banners!
Der Unterschied zwischen Staging Seite (ohne WPML) und Live Seite (mit WPML) sind 3 Sekunden.
Kannst Du Dir bitte meine Installation mal ansehen, was da evtl. faul ist?
interessant wäre der Wert ohne RCB, nur mit WPML ohne weitere Plugins, mit einem Standard Theme. Dann können wir sehen, wie es sich isoliert verhält.
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.
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: versteckter Link
Hallo Marcel,
- wp_installer_settings habe ich gelöscht
- otgs_installer_recommendations_admin_notices ist nicht vorhanden
Die Fehlermeldung für die angeblich fehlende Tabelle icl_strings erscheint weiterhin.
Oder muss ich nochmal alles löschen, deinstallieren und neu installieren?
Schönen Gruß
Thomas
Hallo Marcel,
sie ist nicht selber verschwunden aber ich habe sie geschlossen und sie erscheint nicht mehr.
Gut, nun kann ich testen und gebe Bescheid.
Schönen Gruß
Thomas
Hallo Marcel,
ich habe nun alles so weit vorbereitet, dass Du Dich einloggen und Dir die Sache anschauen kannst. Ich habe ein Standard Theme installiert (twenty twenty-three) und die von mir benötigten WPML Plugins. WPML ist noch nicht mal konfiguriert und nichts ist übersetzt, aber schon zieht es die Performance stark nach unten, insbesondere die String Translation. Verwende zum Performancetest bitte die Seite stage.mb-nosparts.com/warenkorb/
An der Adminleiste oben siehst Du wenn Du eingeloggt bist den Query Monitor, der Dir u.a. die Ladezeit anzeigt.
Schönen Gruß
Thomas
danke für die Infos. Folgende Werte konnte ich aufzeichnen:
leerer Warenkorb, Aufruf der Default-Sprache versteckter Link
4,11s, 317Q
ohne WPML
2.73s, 247Q
Ohne WPML, ohne andere Plugins:
1.15s, 72Q
Nur WPML, ohne andere Plugins:
2.55s, 158Q
WPML mit Default-Theme
2.30s, 102Q
Query Monitor ist bekannt dafür, die Queries leicht zu erhöhen, wenn WPML verwendet wird. Für vergleichbare Werte habe ich es nun auch mit "Debug Bar" getestet:
Isoliert, nur WPML:
ABFRAGEN INSGESAMT: 109
GESAMTE ABFRAGEZEIT: 89,2 ms
Ohne WPML:
ABFRAGEN INSGESAMT: 57
GESAMTE ABFRAGEZEIT: 56.3 ms
Können Sie diese Werte bestätigen? Das mehr Queries geladen werden, ist normal. Die Abfragezeit ist hier jedoch durchaus normal. Wir sprechen hier von Millisekunden. Können Sie dies auf der Staging sonst noch anhand eines anderen Beispiels nachstellen?
Hallo Marcel,
danke für die Untersuchung!
Die reinen DB Abfragezeiten kann ich im Allgemeinen bestätigen. Es gibt vereinzelt längere, insbesondere im Backend, aber das hat dann nicht nur mit WPML zu tun.
Kannst Du mir noch Details zu Deiner Aussage geben: "Query Monitor ist bekannt dafür, die Queries leicht zu erhöhen, wenn WPML verwendet wird."
Query Monitor zeigt den Inhalt aller Queries an, nicht nur die Anzahl und eben auch doppelt ausgeführte, also wenn z.B. mehrere Plugins die gleiche Query initiieren. Wird hier was "hinzugedichtet"?
Ich kann nur sagen dass die angegebene Zeit ziemlich gut der tatsächlichen Ladezeit beim Aufruf einer Seite entspricht.
Die Dauer der Queries (in der Regel unter 100ms) sind ja nur ein Bruchteil. Es kommt noch eine Unmenge an Code der verschiedenen Plugins hinzu, wobei WPML eines der mächtigsten und umfangreichsten ist, bitte nicht im negativen Sinne verstehen. AJAX Calls, REST-API sowie Unmengen an JavaScript aller Plugins kommen noch dazu.
Bei meinen Tests konnte ich nicht immer aber immer wieder HTTP-API Aufrufe im Query Monitor sehen, mit Calls zur GeoLocation, die sehr lange dauerten und Fehler zurücklieferten (siehe Bild im Anhang). Die waren nur zu beobachten, wenn WPML WC Multilingual und Multcurrency installiert ist. Und das, obwohl ich in Woocommerce die GeoLocation - die sich aber eher auf die Steuern bezieht - ausgeschaltet habe und der Modus für mehrere Währungen in Multicurrency auch nicht aktiv ist. Wie kommt es zu diesem Call?
Schönen Gruß
Thomas
