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