[Geschlossen] Seite langsam durch WPML String Translation
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.
Sun
Mon
Tue
Wed
Thu
Fri
Sat
-
9:00 – 13:00
9:00 – 13:00
9:00 – 13:00
9:00 – 13:00
9:00 – 13:00
-
-
14:00 – 18:00
14:00 – 18:00
14:00 – 18:00
14:00 – 18:00
14:00 – 18:00
-
Zeitzone des Supporters: Europe/Madrid (GMT+02:00)
Wir haben WPML und den String translator am laufen, aktuell sind alle Sprachen ausgeschaltet, aber diese sollen in Zukunft wieder aktiviert werden.
Nun haben wir das problem, dass das Plugin WPML String Translation die CPU von unserem Server auf 100% hoch treibt.
Dadurch sind die ladezeiten der Seite extrem hoch, die wartezeit beträgt daher 6 Sekunden.
Wir haben schon Caching Plugins und Cache Warmup plugins in verwendung, das hilft nur minimal.
Wenn wir WPML String Translation deactivieren ist alles gut, dann ist die Seite auch schneller. Wir benötigen das Plugin aber.
Ich bin auch schon mehrere Foren einträge durch gegangen und habe versucht den Tipp hier zu vollziehen.
Downgrade auf 6.2.2 und auch der versuch die Strings zu löschen hat nicht funktioniert, da diese option nicht zur verfügung steht. Siehe screenshot. (Getestet in einer Staging umgebung)
Ich habe auch noch einen Screenshot vom Speed geteilt.
Die Website ist: versteckter Link
Bitte um Feedback und hilfe dies zu beheben.
Trotz Caching Plugin brauchen die Seiten über 3 Sekunden zum laden, das ist einfach zu viel.
Ohne Caching (als Admin) sind es 6-9 Sekunden.
zuerst können Sie das WP_MEMORY_LIMIT auf mind. 256MB erhöhen.
Fügen Sie diesen Code in Ihre wp-config.php ein, um den WP-Speicher zu erhöhen:
define('WP_MEMORY_LIMIT', '256M');
Fügen Sie ihn kurz vor "That's all, stop editing! Happy blogging."
Weitere Informationen finden Sie hier: https://wpml.org/home/minimum-requirements/
Hinweis: WPML benötigt ein WP-Speicherlimit von mindestens 128MB alleine. Dies bedeutet mit einem Standard-Theme und ohne weitere installierten Plugins.
Sie haben zwar 1024MB PHP-Speicher, WP darf davon aktuell jedoch per Default nur 40MB verwenden. Sie sehen den aktuellen Verbrauch Ihrer Seite unter WPML -> Support.
Bitte erhöhen Sie dies zuerst und prüfen Sie dann, ob danach die Performance noch bei einzelnen Tasks zu gering bemerkbar ist. Aber damit werden Sie bereits eine enorme Steigerung spüren. Bei den meisten WP Hostern ist dieser Wert bereits bei 256 oder 512MB vorkonfiguriert.
ich habe das speicherlimit nachdem ich den Post gemacht habe, auf 1024M hochgeschraubt.
Ist mir dann selber auch aufgefallen, dass es noch auf 40M stand.
Leider hat das keine abhilfe geschaffen.
Performence ist immer noch genau so.
Es gibt auch noch kein Update für das Theme für php8.
Daher bin ich noch gezwungen auf php7 zu bleiben.
danke für die Info. Also die Queries sehen hier noch mal nicht schlecht aus. Das höchste war 13 Millisekunden. In Sekunden selbst sah ich keine Einträge.
1. Haben die String Labels bereinigt
2. die WPML version ist jetzt auf 4.6.8
3. Haben wir auch mal angepasst.
Leider hat das keine leistungssteigerung gebracht.
Wir haben auf einem anderen Server tests durchgeführt mit einem Clon der seite, dort ist die geschwindigkeit mit Cache Plugins bei 4-5 Sekunden.
Wenn wir dann WPML Deaktivieren sind wir bei 1-2 Sekunden pro seitenwechsel und die Seite baut sich schon etwas vorher auf.
Wenn Ihr mir eure Statische-IP sagen könnt, dann kann ich euch für den Testserver auch mit Admin bereich freischalten. Dann könnt ihr auch den Vergleich mal sehen.
Zudem haben wir ein weiteres Problem mit den String Translations. Wir haben im Backend die ganzen Übersetzungen für die WooCommerce-Strings gemacht, jedoch werden die Übersetzungen nur angezeigt, wenn der Haken "Look for strings while pages are rendered" im Backend bei den String-Translations gesetzt ist. Sobald wir diese wieder deaktivieren, werden die Übersetzungen nicht mehr gezeigt. Bspw. bei den Strings im Bild im Anhang, jeweils wenn der Haken gesetzt bzw. nicht gesetzt ist. Wie löst man das?
Auf der lokalen Kopie kann ich Redis Cache leider nicht anwenden, weshalb ich das Plugin entfernt habe. Ich sehe die Probleme allerdings auch ohne das Plugin.
Vorweg:
Hier waren aktuell 11 Updates verfügbar, darunter WPML und WCML. Bitte immer zuerst alle Plugins aktualisieren und prüfen ob das Problem bestehen bleibt, bevor ein Support Ticket eröffnet wird.
Einige diese Plugins sind zudem Premium Plugins, zu welchen ich hier aktuell kein Update durchführen kann. Zudem war auch WordPress nicht aktualisiert. Ich habe somit zunächst alle möglichen Updates durchgeführt und dann erneut getestet.
Als erstes wollte ich damit beginnen die Website alleine mit WPML auf einem Standardtheme zu testen, um festzustellen, ob das Problem bestehen bleibt. Ich sehe in diesem Fall allerdings in beiden Sprachen die gleiche Ladezeit von etwa 3 Sekunden.
Aktiviere ich nun wieder alle Plugins und verwende das Flozen Parent Theme sehe ich zwar höhere Ladezeiten, aber diese sind in beiden Sprachen weiterhin identisch.
Eine Localhost kann hier im Grunde nicht als Refernz verwendet werden, da diese immer langsamer ist, bzw. hier zum Beispiel können bestimmte Medien wie das Logo nicht geladen werden und alleine deshalb kommt es bereits zu einer längeren Ladezeit.
Was hier allerdings eindeutig ist, sind die folgenden Fehler, die auftauchen, wenn ich allke Plugins wieder aktiviert habe:
Fatal error: Uncaught Exception: Cache Warmer: Unknown option name: -last-handled-version-update in D:\Work\Local Sites\hzc\app\public\wp-content\plugins\cache-warmer\src\class-options.php:146 Stack trace: #0 D:\Work\Local Sites\hzc\app\public\wp-content\plugins\cache-warmer\src\class-options.php(164): Cache_Warmer\Options->validation_option('-last-handled-v...') #1 D:\Work\Local Sites\hzc\app\public\wp-content\plugins\cache-warmer\cache-warmer.php(274): Cache_Warmer\Options->get('-last-handled-v...') #2 D:\Work\Local Sites\hzc\app\public\wp-content\plugins\cache-warmer\cache-warmer.php(97): Cache_Warmer\Cache_Warmer->handle_version_update() #3 D:\Work\Local Sites\hzc\app\public\wp-includes\class-wp-hook.php(324): Cache_Warmer\Cache_Warmer->Cache_Warmer\{closure}('') #4 D:\Work\Local Sites\hzc\app\public\wp-includes\class-wp-hook.php(348): WP_Hook->apply_filters(NULL, Array) #5 D:\Work\Local Sites\hzc\app\public\wp-includes\plugin.php(517): WP_Hook->do_action(Array) #6 D:\Work\Local Sites\hzc\app\public\wp-settings.php(506): do_action('plugins_loaded') #7 D:\Work\Local Sites\hzc\app\public\wp-config.php(119): require_once('D:\\Work\\Local S...') #8 D:\Work\Local Sites\hzc\app\public\wp-load.php(50): require_once('D:\\Work\\Local S...') #9 D:\Work\Local Sites\hzc\app\public\wp-blog-header.php(13): require_once('D:\\Work\\Local S...') #10 D:\Work\Local Sites\hzc\app\public\index.php(17): require('D:\\Work\\Local S...') #11 {main} thrown in D:\Work\Local Sites\hzc\app\public\wp-content\plugins\cache-warmer\src\class-options.php on line 146
Notice: Die Funktion is_embed wurde fehlerhaft aufgerufen. Bedingte Abfragen (Conditional Tags) funktionieren nicht, wenn die Beitrags-Abfrage (query_posts) noch nicht durchgeführt wurde. Sie geben dann immer 'false' zurück. Weitere Informationen: Debugging in WordPress (engl.). (Diese Meldung wurde in Version 3.1.0 hinzugefügt.) in D:\Work\Local Sites\hzc\app\public\wp-includes\functions.php on line 6031
Notice: Die Funktion is_search wurde fehlerhaft aufgerufen. Bedingte Abfragen (Conditional Tags) funktionieren nicht, wenn die Beitrags-Abfrage (query_posts) noch nicht durchgeführt wurde. Sie geben dann immer 'false' zurück. Weitere Informationen: Debugging in WordPress (engl.). (Diese Meldung wurde in Version 3.1.0 hinzugefügt.) in D:\Work\Local Sites\hzc\app\public\wp-includes\functions.php on line 6031
Diese Fehler treten nur dann auf, wenn das "Cache Warmer" Plugin aktiviert ist.
Momentan macht es hier keinen Sinn weiter per Localhost zu testen, da ich aktuell ohne die Cache Plugins auf Deutsch eine Ladezeit von mehr als 8 Sekunden und auf Englisch von etwas weniger als 8 Sekunden habe.
Das sich diese mindert, wenn ich String Translation deaktiviere, kann ich hier nicht bestätigen.
Ich bitte Dich eine Staging Site anzulegen, auf welcher Du WordPress und alle Plugins aktualisierst, dann bitte dort WPML registrierst und mir Zugriff erteilst.
Danke für das überprüfen, meine Werte liegen bei WPML aus:
Beendet: 7,71 s
DOMContentLoaded: 3,87 s
load: 4,52 s
WPML AN:
Beendet: 11,41 s
DOMContentLoaded: 5,05 s
load: 6,68 s
--
das ist schon ein großer unterschied.
Die ladezeit ist aktuell nicht so gut bei der Seite, aber mit WPML ist es noch krasser.
Aber anscheinend kann man da dann wenig machen, wie es sich aktuell anhört?
Dadurch das auf der Startseite im Staging der Header-Slider nicht geladen wird, warum auch immer, ist diese natürlich schneller als aufm Live. Daher kann man da den vergleich nicht genau ziehen.
Die unterseiten sind aber gleich schnell.
Das Thema „[Geschlossen] Seite langsam durch WPML String Translation“ ist für neue Antworten geschlossen.
Cookie-Zustimmung verwalten
Wir verwenden Cookies, um unsere Website und Dienste zu optimieren. Ihre Zustimmung erlaubt es uns, Daten wie das Durchsuchen der Website zu verarbeiten. Wenn Sie nicht zustimmen, können einige Funktionen beeinträchtigt werden.
Funktionell
Immer aktiv
Erforderlich für den Betrieb und die korrekte Kommunikation auf unserer Website.
Präferenzen
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistiken
Wir verwenden diese, um die Statistiken unserer Website zu analysieren. Die gesammelten Informationen sind völlig anonym. Der technische Speicher oder Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Einhaltung durch Ihren Internetdienstanbieter oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen in der Regel nicht dazu verwendet werden, Sie zu identifizieren.
Marketing
Diese Cookies verfolgen Ihr Surfverhalten, um für Sie relevante Werbung anzuzeigen.
