Mehrsprachige WordPress-Leistung: 7 Möglichkeiten, eine übersetzte Website schnell zu halten

Fassen Sie diesen Beitrag zusammen mit: 9 Minuten Lesezeit

ChatGPT Ratlosigkeit Grok Google AI

Eine mehrsprachige WordPress-Site bleibt schnell, wenn jede Sprachversion als eigener Satz zwischenspeicherbarer Seiten behandelt wird: Geben Sie jeder Sprache eine separate URL, stellen Sie sicher, dass Ihr Seitencache und Ihr CDN jede einzelne separat speichern, laden Sie Schriftarten nur für die Skripte, die eine Seite verwendet, und wählen Sie eine Übersetzungsmethode, die fertiges, übersetztes HTML liefert, anstatt nach dem Laden der Seite Text auszutauschen. Messen Sie dann Core Web Vitals pro Sprache, da eine schnelle englische Homepage nichts über die japanische aussagt.

Wichtige Erkenntnisse

• Messen Sie jede Sprache separat. Die “guten” Schwellenwerte von Google liegen bei LCP innerhalb von 2,5 s, INP unter 200 ms und CLS unter 0,1, also im 75. Perzentil der Seitenladungen.
• Sprachspezifische URLs (/de/, /fr/) kann wie jede andere Seite zwischengespeichert werden. Die vom Cookie gewählte Sprache kann dies normalerweise nicht.
• Löschen Sie den Seitencache für übersetzte Seiten, wenn sich Übersetzungen ändern, sonst sehen Besucher veralteten Text.
• Teilen Sie Webfonts nach Skript auf mit unicode-range, sodass ein deutscher Besucher keine japanischen Glyphen herunterlädt.
• Vermeiden Sie automatische Sprachweiterleitungen bei jedem Besuch; Jede Weiterleitung ist eine zusätzliche Hin- und Rückfahrt, bevor etwas gerendert wird.

Warum mehrsprachige WordPress-Sites langsamer werden

Durch das Hinzufügen von Sprachen vervielfacht sich die Anzahl der Seiten, ohne dass Sie Ihren Server ändern müssen. Fünf Sprachen auf einer 200-seitigen Site bedeuten etwa 1.000 URLs zum Zwischenspeichern, Crawlen und Aktualisieren. Leistungsprobleme kommen in der Regel von einem von fünf Orten:

1. Cache verfehlt. Übersetzte Seiten werden nicht zwischengespeichert oder unter dem falschen Schlüssel zwischengespeichert.
2. Übersetzungsarbeiten zum gewünschten Zeitpunkt. Übersetzungen werden nachgeschlagen oder generiert, während der Besucher wartet.
3. Clientseitiger Austausch. Die Seite wird in der Originalsprache geladen, dann ersetzt JavaScript den Text, was den endgültigen Inhalt verzögert und das Layout verschieben kann.
4. Schwere Schriftarten. Durch das Hinzufügen von Chinesisch, Japanisch, Koreanisch oder Arabisch werden große Schriftdateien hinzugefügt.
5. Hops umleiten. Eine Spracherkennung, die bei jedem ersten Besuch eine Umleitung vornimmt, fügt eine Hin- und Rückfahrt hinzu.

Jedes hat eine einfache Lösung.

Schritt 1: Messen Sie pro Sprache

Google empfiehlt, gute Core Web Vitals zu erreichen, was seiner Meinung nach “mit dem übereinstimmt, was unsere Kernrankingsysteme belohnen wollen” (Google Search Central). Die Ziele:

Web.dev empfiehlt, diese anhand des 75. Perzentils der Seitenladungen zu beurteilen, aufgeteilt nach Mobilgeräten und Desktops (web.dev).

So messen Sie pro Sprache:

• Führen Sie PageSpeed Insights auf derselben Seite in jeder Sprache aus (/pricing/, /de/pricing/, /ja/pricing/). Unterschiede weisen direkt auf sprachspezifische Probleme wie Schriftarten oder langen Text hin, die zu Layoutverschiebungen führen.
• Öffnen Sie im Core Web Vitals-Bericht der Search Console die Beispiel-URLs in jeder Problemgruppe und notieren Sie, welche Sprachordner angezeigt werden.
• Testen Sie aus den Regionen, die Sie bedienen. Eine in den USA gehostete Site weist für Besucher in Asien unabhängig von der Sprache eine höhere Latenz auf.

Schritt 2: Geben Sie jeder Sprache eine eigene zwischenspeicherbare URL

Das Seiten-Caching ist der größte Einzelgewinn. Im WordPress Advanced Administration-Handbuch heißt es, dass Caching-Plugins Seiten als statische Dateien bereitstellen und “die Leistung für ziemlich statische Seiten um das Hundertfache verbessern können” (WordPress-Entwicklerressourcen).

Das funktioniert nur, wenn jede Sprache eine eigene URL hat. Wenn die Sprache durch ein Cookie oder durch die Einstellungen des Browsers ausgewählt und auf derselben URL bereitgestellt wird, speichert ein Seitencache entweder eine Sprache für alle oder muss umgangen werden. Google bevorzugt auch separate URLs für SEO: Es empfiehlt “unterschiedliche URLs für jede Sprachversion einer Seite, anstatt Cookies oder Browsereinstellungen zu verwenden” (Google Search Central).

Checkliste für Ihr Caching-Plugin:

• Seiten zwischenspeichern unter /de/, /fr/ und so weiter, und prüfen Sie, ob keine in der Ausschlussliste enthalten sind.
• Wenn das Plugin den Cache vorladen kann, fügen Sie die übersetzten URLs ein. Das Vorladen von Ihrer Sitemap ist am einfachsten, wenn diese in der Sitemap aufgeführt sind.
• Variieren Sie den Cache nicht durch ein Sprachcookie, es sei denn, Sie haben keine andere Wahl.
• Löschen Sie die übersetzte URL, wenn sich ihre Übersetzung ändert, nicht nur, wenn der Originalbeitrag bearbeitet wird.

Schritt 3: Übersetztes HTML bereitstellen, nicht Text nach dem Laden austauschen

Wie Ihr Übersetzungstool eine übersetzte Seite erstellt, ist genauso wichtig wie das Caching.

• Serverseitige Übersetzung generiert das übersetzte HTML auf dem Server. Der Besucher erhält die fertige Seite und kann sie in einem Seitencache speichern.
• Clientseitige Übersetzung sendet die Originalseite, dann ruft JavaScript Übersetzungen ab und ersetzt den Text im Browser. Es funktioniert auf jeder Plattform, aber der übersetzte Inhalt kommt später an und länger übersetzter Text kann Elemente verschieben, nachdem sie gemalt wurden, was sich als Layoutverschiebung zeigt.

Bevorzugen Sie bei WordPress eine serverseitige Methode für Ihre Hauptsprachen. Wenn ein clientseitiges Skript Ihre einzige Option auf einem Teil der Site ist, reservieren Sie Platz für wachsenden Text (insbesondere Schaltflächen und Menüs) und testen Sie CLS in jeder Sprache.

Schritt 4: Schriftarten nach Skript aufteilen

Lateinische Schriftarten sind klein; vollständige CJK-Schriftarten (Chinesisch, Japanisch, Koreanisch) können um ein Vielfaches größer sein. Das Laden jedes Skripts auf jeder Seite verschwendet Bandbreite.

Verwenden Sie die @font-face unicode-range Deskriptor. MDN erklärt, dass, wenn eine Seite kein Zeichen im Bereich verwendet, “die Schriftart nicht heruntergeladen wird” und dass der Deskriptor existiert, sodass eine Site “mit vielen Lokalisierungen” separate Schriftressourcen für jedes Skript bereitstellen kann (MDN).

@font-face {
  font-family: 'Brand Sans';
  src: url('/fonts/brand-latin.woff2') format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153;
  font-display: swap;
}
@font-face {
  font-family: 'Brand Sans';
  src: url('/fonts/brand-arabic.woff2') format('woff2');
  unicode-range: U+0600-06FF;
  font-display: swap;
}

Außerdem:

• Hosten Sie WOFF2-Dateien selbst und laden Sie nur die über dem Fold verwendete lateinische (oder Hauptskript-)Datei vor.
• Erwägen Sie die Verwendung einer guten Systemschriftart für Skripte, die Ihre Markenschriftart nicht abdeckt, anstelle einer großen Webschriftart.
• Verwenden font-display: swap Text wird also sofort in einer Fallback-Schriftart angezeigt.

Schritt 5: Halten Sie Bilder und Skripte in jeder Sprache schlank

• Lokalisierte Bilder. Wenn Sie Bilder pro Sprache ersetzen, komprimieren und dimensionieren Sie jede Version wie das Original; Es ist einfach, ein nicht optimiertes 4-MB-Banner für einen Markt hochzuladen.
• Lazy Loading. WordPress fügt hinzu loading="lazy" standardmäßig auf Bilder; stellen Sie sicher, dass Ihr Heldenbild in jeder Sprachvorlage nicht verzögert geladen wird.
• Skripte von Drittanbietern. Marktspezifische Chat-Widgets, Zahlungsabzeichen und Tracker summieren sich. Laden Sie sie nur in den Sprachen oder auf den Seiten, die sie benötigen.

Schritt 6: Vermeiden Sie unnötige Weiterleitungen

Automatische Weiterleitungen basierend auf der Browsersprache fügen vor dem ersten Byte der rechten Seite eine Hin- und Rückfahrt hinzu. Google rät außerdem davon ab, Benutzer auf eine Sprachversion umzuleiten “basierend darauf, was Ihrer Meinung nach die Sprache des Benutzers sein könnte”, da dies verhindern kann, dass Benutzer und Suchmaschinen alle Versionen erreichen (Google Search Central).

Bessere Optionen:

• Lassen Sie die Leute eine Sprache mit einem sichtbaren Umschalter auswählen und intern auf übersetzte URLs verlinken, damit sie in ihrer Sprache bleiben.
• Wenn Sie eine Weiterleitung vornehmen, tun Sie dies nur beim ersten Besuch der Startseite und merken Sie sich die Auswahl.
• Zeigen Sie hreflang und interne Links auf die endgültigen URLs, nicht auf URLs, die umleiten.

Schritt 7: Die Grundlagen auf dem Server richtig machen

Übersetzte Seiten ändern nichts an den Grundlagen. Das WordPress-Handbuch verweist auf Caching, ein CDN für statische Dateien und Server-Tuning als Haupthebel:

• PHP aktuell halten und OPcache aktiviert.
• Fügen Sie einen persistenten Objektcache hinzu (Redis oder Memcached), wenn Ihr Host dies unterstützt, insbesondere für WooCommerce oder Mitgliedschaftsseiten, bei denen das Caching ganzer Seiten eingeschränkt ist.
• Verwenden Sie ein CDN für Bilder, CSS und JS und für ganze Seiten, wenn Ihr Setup dies zulässt, sodass Besucher, die weit von Ihrem Server entfernt sind, diese aus der Nähe erhalten.
• Halten Sie die Plugin-Liste kurz. Jedes aktive Plugin wird bei jeder nicht zwischengespeicherten Anfrage in jeder Sprache ausgeführt.

Wie das WordPress-Plugin ConveyThis passt

Das Plugin ConveyThis übersetzt Seiten auf dem Server und stellt jede Sprache in einem eigenen Unterordner oder einer eigenen Subdomain bereit, sodass übersetzte Seiten wie das Original zwischengespeichert werden können. Es speichert einen lokalen Cache mit Übersetzungen für jede Seite und Sprache, sodass wiederholte Anfragen nicht auf den Übersetzungsdienst warten. Wenn Sie eine Übersetzung ändern, wird der Seitencache in gängigen Caching-Plugins wie WP Rocket, W3 Total Cache, WP Super Cache und WP Fastest Cache gelöscht.

Weitere wissenswerte Einstellungen:

• Seiten oder Abschnitte ausschließen die keine Übersetzung benötigen, wie etwa Kontobereiche, um die Übersetzungsarbeit dort zu belassen, wo sie wichtig ist.
• Die automatische Umleitung durch die Browsersprache ist deaktiviert, es sei denn, Sie aktivieren sie und verwenden die Sprache des Browsers anstelle von IP-Suchen; siehe automatische Umleitung.
• Wörter werden nur gezählt, wenn den Besuchern übersetzte Inhalte angezeigt werden; Bots zählen nicht.

Die WordPress-Integrationsseite umfasst Installation und Einstellungen und Pläne und Preise listet Wort- und Sprachgrenzen pro Plan auf. Informationen zum Übersetzen von Themensaiten selbst finden Sie in unserem Leitfaden zu Übersetzen eines WordPress-Themes.

Häufig gestellte Fragen

Verlangsamt das Hinzufügen von Sprachen eine WordPress-Site?

Das muss es nicht. Jede Sprache fügt Seiten hinzu, nicht Gewichtung pro Seite, solange übersetzte Seiten auf ihren eigenen URLs zwischengespeichert werden und Übersetzungen auf dem Server angewendet werden. Verlangsamungen entstehen normalerweise durch nicht zwischengespeicherte übersetzte Seiten, clientseitigen Texttausch, starke Schriftarten oder Weiterleitungen.

Sollten übersetzte Seiten separat zwischengespeichert werden?

Ja. Jede Sprache sollte ihre eigene URL haben und Ihr Seitencache und CDN sollten jede URL separat speichern. Löschen Sie eine übersetzte Seite, wenn sich ihre Übersetzung ändert.

Wie messe ich die Leistung für jede Sprache?

Führen Sie PageSpeed Insights in jeder Sprache auf derselben Seite aus, vergleichen Sie und prüfen Sie, welche Sprachordner im Core Web Vitals-Bericht der Search Console angezeigt werden. Streben Sie LCP innerhalb von 2,5 Sekunden, INP unter 200 Millisekunden und CLS unter 0,1 an.

Sind Unterverzeichnisse oder Subdomains für eine mehrsprachige Site schneller?

Beides ist nicht von Natur aus schneller. Unterverzeichnisse teilen sich einen Host, Cache und ein CDN-Setup, was einfacher zu verwalten ist; Subdomains können separat gehostet werden, wenn Sie Server benötigen, die näher an einer Region liegen.

Wie verhindere ich, dass große Schriftarten übersetzte Seiten verlangsamen?

Teilen Sie Schriftarten per Skript mit dem Unicode-Bereichsdeskriptor auf, sodass Browser nur Schriftarten für Zeichen herunterladen, die die Seite verwendet, WOFF2 bereitstellen und den Schriftartenanzeigetausch verwenden.

Halten Sie es schnell, während Sie wachsen

Geschwindigkeit und Übersetzungsqualität hängen beide davon ab, wie übersetzte Seiten erstellt werden. Du kannst Erstellen Sie ein ConveyThis-KontoInstallieren Sie das WordPress-Plugin und vergleichen Sie Ihre übersetzten Seiten mit den Originalen.