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.
wie besprochen habe ich ein neues Ticket bzgl. der Performance von ...
erstellt.
Die deutsche Seite ist sehr performant, hat bei Pagespeed auch nur gute Werte.
Die englische Version ist wesentlich langsamer.
Die Domain sitename.com ist bei einem amerikanischen Registrar registriert. sitename.com ist unsere USA Seite.
Beide Subdomains werden per A-Record auf unseren deutschen VPS geleitet. Die en.xxx momentan noch per CNAME aber wir wollen es wieder zum A-Record wechseln, da sonst die de.xxx der Canonical Name wäre, aber das unsere Hauptdomain in Deutschland ist.
Ich habe dann auf unserem Server einfach bei en.xxxSubdomain das Dokumentenverzeichnis von de.xxx definiert.
WPML hat bei der Validierung auch keinen Fehler gebracht.
Ich dachte zuerst, womöglich liegt es daran, aber wenn man die URL Struktur der beiden Sprachen auf Verzeichnisse setzt, dann ist die Performance bei der englischen Seite genauso langsam.
Wir haben auch andere Seiten versteckter Link und versteckter Link. Bei beiden ist WPML auch im Einsatz.
sitename.systems ist nicht die schnellste aber hat bei beiden Sprachen grüne Werte bei Pagespeed.
Bei versteckter Link ist es das gleiche und die ist auch richtig schnell bei beiden Sprachen.
Die einzige Seite, die da in der englischen Version Probleme macht ist die versteckter Link.
Da gibt es irgendwie Probleme bei der Erstreaktion des Servers.
Alle Seiten laufen über den gleichen Server und verwenden wp-rocket als Caching Plugin.
Wie ich bereits erwähnt habe, wirst du erstmal den Admin Zugang nutzen müssen um die englischen Inhalte von versteckter Link sehen zu können
Sag einfach bescheid, was du alles von mir benötigst.
bevor Ihr Ticket einem meiner Kollegen zugewiesen wird, erlauben Sie mir bitte, Sie durch einige erste Schritte zur Fehlersuche zu führen.
Via Page Speed lässt sich leider keine aussagekräftige Plugin Performance bewerten. Die Werte können bereits durch ein versuchtes Nachladen eines nicht vorhanden Bild oder einer Schrift eine lange Ladezeit verursachen, welches dann irgendwann ein 404 ausgibt.
Es gab viele PHP Warnung(52) bei WPML weil auf der Seite PHP 8.1 aktiviert war. Hab nun 8.0 aktiviert.
Und es gab einen falschen Pfad zu der db.php bei der en.xxx Subdomain, weil dort bei der PHP Version noch "open_basedir" definiert war.
Die ganze Seite läuft über einen roots bedrock wrapper versteckter Link
Und es werden im Header sowie einpaar Elementor Theme Templates Twig Files geladen.
Timber/Twig verträgt sich glaube nicht so gut mit einem definierten Pfad bei "open_basedir".
Obwohl die Performance inzwischen viel besser ist, sind die pagespeed Ergebnisse bei der englischen Seite im mobilen Bereich weiterhin ganz schlecht.
Irgendetwas scheint da noch nicht richtig zu klappen.
Ich kann gerne anbieten mir das einmal genauer anzusehen.
Ich möchte einen temporären Zugriff (wp-admin und FTP) auf die Website anfordern, um das Problem genauer zu untersuchen.
Die dafür erforderlichen Felder findst Du unterhalb des Kommentarbereichs, wenn Du dich anmelden, um die nächste Antwort zu hinterlassen. Die Informationen, die Du angibst sind privat, was bedeutet, dass nur Du und ich sie sehen und darauf zugreifen können.
WICHTIG
Lege bitte unbedingt eine Sicherungskopie der Website und der Datenbank an, bevor Du uns den Zugriff gewährst.
Wenn Du die Felder "wp-admin / FTP" nicht sehen kannst, werden Ihre Anmeldedaten für Post und Website als "PUBLIC" (Öffentlich) festgelegt. Veröffentliche die Daten NICHT, es sei denn, Du siehst die erforderlichen wp-admin / FTP-Felder.
Ich muss hier ggfls. ein Plugin namens "All In One WP Migration" installieren, um eine Kopie der Website anzulegen, auf welche ich das Problem genauer untersuchen kann.
Ich wäre allerdings auch sehr dankbar, wenn Du zu diesem Zweck selbst eine Staging Site, bzw. Kopie der Website von Deinem Server aus bereitstellen könntest.
Bei Fragen zum Erstellen einer solchen Staging Site kannst Du deinen Hosting Anbieter konsultieren. Achte darauf, dass WPML auf diesem Staging ebenso erneut unter wpml.org registriert werden muss.
Solltest Du dazu nicht in der Lage sein eine solche Kopie der Website zum Testen bereitzustellen, dann lass es mich bitte auf diesem Ticket wissen.
Das private Antwortformular sieht folgendermaßen aus: versteckter Link
Klicke beim nächsten Antworten auf "I still need assistance".
Video: versteckter Link
Beachte bitte, dass wir verpflichtet sind, diese Informationen auf jedem Ticket individuell anzufordern. Wir dürfen nicht auf Zugangsinformationen zugreifen, die nicht speziell auf diesem Ticket im privaten Antwortformular übermittelt wurden.
Die kann vor allem zu Synchronizierungsproblemen zwischen dem professionellen Übersetzungsdienst und WPML führen - aktuell sehe ich einen solchen Fehler unter WPML > Übersetzungsmanagement > Aufträge.
---
Zudem sehe ich das Plugin "Email Encoder - Protect Email Addresses" welches wiederum aktuell nicht empfohlen werden kann, da durch dieses Plugin keine Kommunikation zwischen WordPress, unserem Advanced Translation Editor und dem Translation Management stattfinden kann:
Der Fehler äußert sich unter WPML > Übersetzungsmanagement > Tools.
Ich sehe hier nicht wirklich aktuell ein Performance-Problem - Die deutsche und die englische Homepage laden beide in etwa 3.4-3.6 Sekunden - davon wird alleine knapp 1.0-1.2 Sekunden benötigt, um die Fonts, Stylesheets, Scripte und Medien der Website zu laden.
Kannst Du mir bitte ein exaktes Beispiel zu einer Seiten und Zahlen zu den bestehenden Ladezeiten nennen?
danke für die Info, dass ich die die internen Linkziele über die Einstellungen umsetzen kann.
Das Problem mit dem Plugin "Email Encoder - Protect Email Addresses" ist mir bekannt. Das hast du mir schon mal vor einigen Monaten erzählt inkl. dem workaround.
Ich habe das Plugin auch auf der Hauptinstallation deaktiviert um die automatischen Übersetzungen durchzuführen. Habe den workaround aber noch nicht angewendet. Auf der dev Seite ist das Plugin unter Umständen noch aktiv.
Ich konnte ja schon die Geschwindigkeit auf der en.xxx steigern aber es sind immer noch Unterschiede, das was am meisten stört ist aber der Unterschied bei pagespeed. Der score ist uns immer wichtig.
ich habe (auf Production Site) den API Access wieder aktiviert, aber irgendwie kommt der Fehler immer noch, ich muss morgen auch genauer mal bei den nginx oder apache Einstellungen nachschauen
bei Translation Management -> Tools kommt auch ein Fehler
Ich werde das nochmal auf dem Staging mit Page Speed in verschiedenen Setups testen.
Frage mich wodurch diese 3,460 ms blocking time auf EN enstehen.
Laut Google:
Eliminate render-blocking resources
1.08s
Resources are blocking the first paint of your page. Consider delivering critical JS/CSS inline and deferring all non-critical JS/styles.
WordPress
There are a number of WordPress plugins that can help you inline critical assets or defer less important resources. Beware that optimizations provided by these plugins may break features of your theme or plugins, so you will likely need to make code changes.
WP Rocket
Enable Remove Unused CSS and Load JavaScript deferred in 'WP Rocket' to address this recommendation. These features will respectively optimize the CSS and JavaScript files so that they don't block the rendering of your page.
Auf wpml.org sehe ich diese Probleme auf Mobil nicht: versteckter Link
Ich bitte Dich hierzu um etwas Geduld - werde mich am Mittwoch wieder melden.
ich habe vorhin mal die dev Seite auf Verzeichnisse umgestellt und alle Links aktualisiert.
Danach war Pagespeed bei der englischen version etwas schwächer aber nur minimal.
das Problem scheint irgendwie and der Subdomain Konfiguration zu liegen. Es kann auch gut sein, dass die DNS Einstellungen der zusätzlichen Subdomains noch nicht optimal sind.
Momentan werden wie bereits erwähnt, alle Subdomains per A-Record von unserem USA Registrar auf unseren deutschen Server weitergeleitet.
Bei den englischen Subdomains habe ich das Dokumentenverzeichnis auf das der deutschen Subdomains definiert, damit die auf den gleichen Inhalt zeigen.
Wir haben es auch schon mal über CNAME-Record umgesetzt, aber da bekam dann unsere Haupt Subdomain den Canonical Name.
Das wollen wir natürlich nicht, weil die ja vorallem in der DACH Region ranken soll.
Ich habe jetzt aber nochmal ein Ticket bei unserem Hoster eingereicht, halte dich auf dem Laufenden.
"Wir konnten die Ergebnisse der Tests nachvollziehen, das DNS schließen wir als Ursache ebenfalls aus.
Einen Test über ein physikalisches Mobilgerät konnten wir jedoch nicht vornehmen.
Wir gehen hier nicht von einem generellen Problem mit dem Server aus, da die Performance bei der PC Version im Rahmen der Erwartungen liegt.
Können Sie den verzögerten Aufruf denn auch tatsächlich über ein Mobilgerät reproduzieren?
Im Fehlerprotokoll tauchen Meldungen wie die folgende auf:
Got error 'PHP message:
PHP Warning: Undefined array key "taxonomy" in /plugins/sitepress-multilingual-cms/classes/query-filtering/class-wpml-query-par
ser.php on line 275PHP message: PHP Warning: Undefined array key "taxonomy" in /plugins/sitepress-multilingual-cms/classes/query-filtering/class-wpml-query-par
ser.php on line 275'
Das dort genannten Plugin "sitepress-multilingual-cms" klingt nach einem validen Ansatzpunkt für das Verhalten.
Wir können hier leider wenig Optimierungspotential aufzeigen, da wir keine Services im Bereich Webentwicklung anbieten."
Die Warnung sehe ich jetzt auch wenn ich in das Fehler Protokoll reinschaue. Ist als Apache Fehler gekennzeichnet.
Als die englische Seite noch richtig langsam war, da lief das ganze unter PHP 8.1 , da gab es beim Query Monitor 52 Wrnungen bei WMPL, deswegen habe ich alles auf PHP 8.0 runtergeschaltet, Dadurch lief dann alles flotter. Aber Der Pagespeed Score mobil bleibt so schlecht.
Hab noch eine Info, die vielleicht relevant ist. Jede Seite läuft über ein Theme Template.
Der header hat ein e-addon mit welchem ich ein twig File lade.
Die Above the Fold Produktseiten haben ein weiteres Template mit einem weiteren Twig File. (die haben den schlimmsten pagespeed wert von ca 30-40%)
Die anderen Seiten auch. (haben zwar einen viele schlechteren pagespeedwert, aber noch im orangenem Bereich) es sind insgesamt ein header twig file und 4 weitere twig files, die dann meistens den oberen bereich gestalten.
Bei e-addon ist aber wpml compatibility aktiviert.
Vielleicht muss man etwas aufgrund der Fehlermeldung mit der Taxonomy beachten?
Ich habe auf jeder Seite Eine ACF Taxonomie, die bestimmt welche templates geladen werden.
Die ACF Taxonomien bestimmen welche ACF Feldgruppen auf der jeweiligen Seite angezeigt werden und welches Elementor Theme Template (per condition) auf der Seite angezeigt wird.
Das ganze scheint ja in englisch zu funktionieren nur eben mit der Verzögerung.
Ich hab`s, zumindest einen großen Fehler entdeckt.
Ganz doof, wir haben keine wp-rocket Lizenz mehr gehabt und die eine en.xxx subdomain benötigt eine extra Lizenz:(
Die Seiten wurden alle ungecacht ausgeliefert. Es ist auch wie verhext, die Seiten sind alle richtig schnell de und en auf handy und desktop
trotzdem bringt pagespeed bei den englischen seiten immer noch schlechtere Werte...ich hasse pagespeed..lol
jetzt ist auch klar warum bei der Verzeichnisstruktur alles ok war, da wurde alles gecacht
was mich aber wundert ist, dass die langsamen pagespeedwerte auch bei der dev/staging Seite vorkamen.
bei dev und staging subdomains berechnet wp-rocket keine Lizenz
das ist echt unglaublich, beide sprachen sind jetzt super schnell und jetzt ist bei beiden sprachen der mobile score um die 50%...
davor hatte wenigstens die hauptdomain über 90%
google pagespeed ist echt heftig:(
ich habe gemerkt, dass das jquery da oft ziemlich lange zum laden benötigt
ich muss es mir morgen nochmal genauer anschauen...und die lizenzen checken
aber von der performance her, müssten jetzt beide sprachen über wp-rocket laufen
