Browser-Sprache erkennen und Weiterleitung via mod_rewrite statt qTranslate-X

WordPress und seine Ladezeit sind wahrlich ein Dauerbrenner. Wenn Sie das Plugin qTranslate-X ohne kompatibles Caching-Plugin nutzen, sollten Sie nachfolgenden Tipp zur Optimierung beherzigen. Beschleunigen Sie Ihre WordPress-Website mit wenigen Zeilen um mehr als das 10fache!

Was ist qTranslate-X?

qTranslate-X ist ein kostenloses WordPress-Plugin, das die Ver├Âffentlichung von Inhalten in verschiedenen Sprachen unterst├╝tzt.

Einsatzszenario f├╝r qTranslate-X

Ein sinnvolles Einsatzszenario liegt dann vor, wenn wirklich jede Seite Ihrer Website in mindestens einer zweiten Sprache vorliegt. Anders ausgedrückt: Sie betreiben keine separate englische und deutsche Website, sondern eine einzige mit einem Umschalter für die Sprachauswahl.

Dabei stellt┬áqTranslate-X verschiedene Funktionen f├╝r die Theme-Entwicklung bereit. Auf diese Weise k├Ânnen geringf├╝gige strukturelle Unterschiede ber├╝cksichtigt werden, also z.B. bestimmte Seiten doch nur in einer Sprache ver├Âffentlicht werden.

Dasselbe gilt auch f├╝r inhaltliche Unterschiede, die nichts mit Seiten, Beitragen etc. zu tun haben. Enth├Ąlt Ihr Logo beispielsweise einen sprachspezifischen Schriftzug, k├Ânnen Sie ├╝ber das Theme unterschiedliche Logos in Abh├Ąngigkeit von der Sprache einblenden.

qTranslate-X in der Praxis

Die Theme-Entwicklung bzw. -Auswahl ist zwar die Basis f├╝r Ihren Blog, Onlineshop oder welche Art von Website auch immer. In der Praxis werden Sie jedoch weniger in den Dateien, sondern im WordPress-Backend arbeiten. Das betrifft insbesondere das Schreiben von Blog-Beitr├Ągen, Ver├Âffentlichen und Bearbeiten von Seiten, Produkten etc.

Ungewohnt, aber funktional

qTranslate-X stellt Ihnen bei ein- und mehrzeiligen Texteingabefeldern einen Schalter zur Auswahl der Sprache bereit. Mit dessen Hilfe geben Sie beispielsweise Titel und Text Ihres Beitrags, Produktbeschreibungen etc. in allen aktivierten Sprachen an. Trotz ungewohnter Optik funktioniert das erstaunlich gut. Zus├Ątzliche Plugins sorgen au├čerdem f├╝r ein reibungsfreies Zusammenspiel mit z.B. WooCommerce. Durch das Einhaken in die nativen WordPress-Funktionen zur sprachabh├Ąngigen Textausgabe (z.B. _(), _e() etc.) besteht aber ohnehin nur geringes Konfliktpotenzial.

Problem: Spracherkennung in WordPress

Mit WordPress generierte Websites sind dann am schnellsten, wenn WordPress-Dateien f├╝r die Ausgabe nicht zum Einsatz kommen. Auf diese Weise funktionieren die allermeisten der unz├Ąhligen Caching-Plugins und zwar sehr erfolgreich.

So teilt der Browser dem Server die gew├╝nschte Sprache mit

Beinahe jede Software bzw. jedes CMS mit Unterst├╝tzung f├╝r Mehrsprachigkeit bietet die Option, die Sprache des Nutzers automatisch zu erkennen. Hierf├╝r liest es die vom Browser gesendeten Informationen aus und liefert Webseiten in der gew├╝nschten Sprache – entweder als Antwort auf den ersten Request oder nach einer automatischen Weiterleitung.

Unn├Âtig: Auch mod_rewrite kann die Accept-Language-Angaben im HTTP-Request auslesen.

Auch┬áqTranslate-X bietet eine solche Option zur automatischen Spracherkennung. Sie k├Ânnen Sie im WordPress-Backend unter Einstellungen > Sprachen > Allgemeine Einstellungen aktivieren. Ihr Name lautet Browser-Sprache automatisch erkennen und entsprechend umleiten. Die Weiterleitung funktioniert so treffsicher wie eine automatische Erkennung eben funktionieren kann.

Das Problem ist auch keineswegs die Erkennung oder die Weiterleitung selbst. Das Problem ist, dass WordPress ausgef├╝hrt wird. Das sollte im Idealfall gar nicht sein, aber unter keinen Umst├Ąnden sollte WordPress gleich doppelt zum Einsatz kommen, um ein einziges Dokument auszuliefern. Denn:

  1. Nutzer fordert Dokument an.
  2. WordPress l├Ądt seine Kerndateien etc., dann die Plugins.
  3. qTranslate-X stellt fest, dass keine Sprache gew├Ąhlt ist, f├╝hrt Spracherkennung durch und antwortet mit Weiterleitung.
  4. Nutzer wird weitergeleitet.
  5. WordPress l├Ądt seine Kerndateien u.s.w. bis zum Senden des Dokuments in der automatisch erkannten Sprache.

L├Âsung: Spracherkennung ohne WordPress

Man braucht kein PHP, um die Header des HTTP-Requests auszulesen und die Browser-Sprache zu erkennen. Das Apache-Modul mod_rewrite kann das ebenso und direkt die HTTP-Weiterleitung initiieren, bevor PHP ├╝berhaupt zur Ausf├╝hrung kommt.

Erforderlich sind hierf├╝r nur wenige Zeilen in der .htaccess-Datei. Gehen wir davon aus, dass Sie unter Einstellungen > Sprachen > Allgemeine Einstellungen bei┬áURL Ver├Ąnderungsmodus diese Option┬ágew├Ąhlt haben:

Deutsch, englisch & franz├Âsisch aktiviert

Pre-Path-Modus – Pfad voransetzen (Standardmodus), f├╝gt das Sprachk├╝rzel (/de/) vorne an die URL. Suchmaschinenfreundlich.

Nehmen wir au├čerdem an, dass Sie deutsch (de), englisch (en) und franz├Âsisch (fr) als Sprache aktiviert haben. Weitere Voraussetzung ist, dass WordPress in keinem Unterverzeichnis Ihrer Domain installiert ist. Dann sehen die in die .htaccess-Datei einzuf├╝genden Zeilen wie folgt aus:

# Spracherkennung und Weiterleitung
RewriteCond %{HTTP:Accept-Language} ^de.*$ [NC]
RewriteRule ^$ /de/ [L,R=302]
RewriteCond %{HTTP:Accept-Language} ^en.*$ [NC]
RewriteRule ^$ /en/ [L,R=302]
RewriteCond %{HTTP:Accept-Language} ^fr.*$ [NC]
RewriteRule ^$ /fr/ [L,R=302]

Das bedeutet, dass bei Aufruf der Startseite von z.B. ihredomain.com anhand der Browser-Sprache eine Weiterleitung nach z.B. ihredomain.com/de/ erfolgt. Der HTTP-Statuscode 302 entspricht dabei dem, den auch das Plugin senden w├╝rde.

Sagenhafte 1.700% mehr Performance

Einschr├Ąnkungen

Vorweg gleich die Einschr├Ąnkungen: Die Steigerung der Performance bezieht sich lediglich auf den ersten der nach wie vor zwei durchgef├╝hrten Requests. In der Praxis bekommt der Nutzer die gew├╝nschte Seite nicht wirklich 17x schneller, sondern „nur“ fast doppelt so schnell zu Gesicht. Denn der zweite Request bleibt von der Anpassung v├Âllig unber├╝hrt.

Und nicht nur der zweite Request: Ist die Sprache erst einmal erkannt und der Nutzer surft im entsprechenden Verzeichnis bzw. mit Language-Parameter, hat die Optimierung keinen Effekt mehr. Nichtsdestotrotz: Der erste Eindruck z├Ąhlt und die Bounce rate sollte es Ihnen mit R├╝ckgang danken.

Vorher-Nachher-Vergleich

Webserver-Leistung vor der Optimierung

Requests per second: 1.20 [#/sec] (mean)
Time per request: 835.326 [ms] (mean)

Webserver-Leistung nach der Optimierung

Requests per second: 21.61 [#/sec] (mean)
Time per request: 46.274 [ms] (mean)

├ťbertragbarkeit auf andere Software

Nicht jede Software bzw. jedes CMS steht mit Performance so auf Kriegsfu├č wie WordPress. Das Prinzip ist aber durchaus auf andere mehrsprachige Websites mit automatischer Spracherkennung ├╝bertragbar.

Wenn Ihnen die Ladezeit Ihrer multilingualen Webpr├Ąsenz am Herzen liegt, sollten Sie die Erkennung der Browser-Sprache nicht der Anwendung, sondern einer h├Âheren Instanz ├╝berlassen. Beispielsweise hatte ich in einem fr├╝heren Blog-Beitrag gezeigt, wie Sie das virtuelle┬áSprachverzeichnis der Shopsoftware Gambio ┬ávia .htaccess ansteuern.

Die Steigerung der Performance ist dabei zwar nicht ganz so beeindruckend wie bei WordPress. Daf├╝r haben wir ja schlie├člich das Caching-Modul f├╝r Gambio GX3 & GX4. Aber gerade im E-Commerce kommt es auf jeden Sekundenbruchteil an, um mit Amazon und Ebay mithalten zu k├Ânnen.

»«

Schreiben Sie einen Kommentar