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 „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. Aber gerade im E-Commerce kommt es auf jeden Sekundenbruchteil an, um mit Amazon und Ebay mithalten zu können.

«

Schreiben Sie einen Kommentar