Multilingual

Verzögerung der Ladezeit durch pll_xdata_check von Polylang

cookie 3216243 1920

Polylang, ein Plugin für mehrsprachige WordPress-Websites, kann so konfiguriert werden, dass jedes Sprache eine eigene (Sub-)Domain bekommt. Verwendet man dazu noch WooCommerce mit Polylang for WooCommerce behält man beim Wechseln der Sprache sogar seinen Warenkorb.

Erstmalig kam ich damit durch die Erweiterung eines bestehenden Projektes in Berührung, das bereits auf Polylang aufgebaut war und noch einen Webshop bekommen sollte. Dafür gab’s ein Upgrade auf Polylang Business Pack.

Doch der Cookie Transfer zwischen den unterschiedlichen Sprach-Adressen der über die Integration der admin-ajax.php erfolgt, kostet richtig und spürbar Ladezeit. Dafür, wie massiv sich das auswirkt fand ich verblüffend wenig Beschwerden und Informationen darüber auf der Suche nach einer Lösung.

Hinzu kam nämlich auch, dass in der Google Search Console beim Test auf Optimierung für Mobilgeräte Seiten nicht vollständig geladen wurden. Die Search Console meldete daraufhin Probleme bei der Nutzerfreundlichkeit für Mobilgeräte, ohne konkrete Angaben dazu machen zu können.

Die Herausgeber von Polylang sagen dazu in etwa (aus dem Englischen übersetzt):

Die Anfrage wird hinzugefügt, um zu prüfen, ob Sie mit anderen Domains verbunden sind. Sie ist Teil unseres SSO-Mechanismus. Sie ist auch Teil des Mechanismus zur Übertragung des Warenkorbs von einer Domain auf die andere, wenn Sie WooCommerce verwenden.
Bisher habe ich keine Möglichkeit gefunden, Cookies von einer Domäne auf die andere zu übertragen, ohne eine zusätzliche Anfrage auszulösen.
Wenn Sie dies jedoch nicht benötigen, können Sie die Funktion deaktivieren, indem Sie die Konstante PLL_COOKIE in Ihrer wp-config.php auf false setzen.

Lieber ein leerer Warenkorb in anderen Sprachen als der gewählten, als dieser Performance-Knick. Keine andere Möglichkeit in der Programmierung von Plugins für WordPress? – Es gibt immer einen anderen Weg, wenn sich der gewählte als nachteilig erweist.

Es war ganz klar, dass die Zeile

define('PLL_COOKIE', false);

in die wp-config.php rein musste.

Das wirkte nicht sofort – gibt ja Caching, also nicht gleich verzagen, vielleicht stattdessen mit einem anderen Browser testen.

Damit wurden aus 700 – 800 Millisekunden für den DOM auf einem performanten Server schließlich 300 – 400 Millisekunden. Wie sich das auf einem durchschnittlichen Shared Hosting Server auswirkt, daran mag ich gar nicht denken. Eine Sekunde länger warten, oder gar 2? – Das kostet sicherlich mehr Kunden als hinzunehmen, dass halt der Warenkorb den einer füllte, nur in der Sprache verfügbar ist, in der er das tat.

Oder geht es noch besser?

Damit die Cookie-Domain ebenfalls in der wp-config.php festzulegen, verhielt sich der Warenkorb wieder sprachenübergreifend homogen.

define('PLL_COOKIE', false); define('COOKIE_DOMAIN', '.hauptdomain.beispiel'); // your main domain define('COOKIEPATH', '/');

Borlabs-Cookie war auch noch im Spiel, den musste ich mit der je Sprache gleichen Domainangabe überzeugen (Automatische Domain- und Pfaderkennung OFF).

Es gab ein paar Testdurchläufe, bis sich sowohl Warenkorb als auch Cookie Consent wieder wie aus je einem Guss verhielten. Für den Performance-Gewinn hat sich der Test-Aufwand auf jeden Fall gelohnt. Auch die Überprüfung auf Mobilfreundlichkeit in der Google Search Console funktioniert nun einwandfrei. Geprüfte Seiten werden nun vollständig geladen.

weiter schmökern

Schreibe einen Kommentar

Bitte Kommentarfunktion nicht für Supportanfragen nutzen. Dem kann hier nicht entsprochen werden.

Deine E-Mail-Adresse wird nicht veröffentlicht.