Does adding languages slow down a WordPress site?

It doesn't have to. Each language adds pages, not per-page weight, as long as translated pages are cached on their own URLs and translations are applied on the server. Slowdowns usually come from uncached translated pages, client-side text swapping, heavy fonts or redirects.

Should translated pages be cached separately?

Yes. Each language should have its own URL, and your page cache and CDN should store each URL separately. Purge a translated page when its translation changes.

How do I measure performance for each language?

Run PageSpeed Insights on the same page in each language and compare, and check which language folders appear in Search Console's Core Web Vitals report. Aim for LCP within 2.5 seconds, INP under 200 milliseconds and CLS under 0.1.

Are subdirectories or subdomains faster for a multilingual site?

Neither is inherently faster. Subdirectories share one host, cache and CDN setup, which is simpler to manage; subdomains can be hosted separately if you need servers closer to a region.

How do I stop large fonts slowing down translated pages?

Split fonts by script with the unicode-range descriptor so browsers only download fonts for characters the page uses, serve WOFF2, and use font-display swap.

多言語 WordPress パフォーマンス: 7 つの速度修正

この投稿を次のように要約します: 9分で読めます

チャットGPT

困惑

グロック

Google AI

多言語 WordPress サイトは、すべての言語バージョンが独自のキャッシュ可能なページセットとして扱われる場合でも高速性を維持します。各言語に個別の URL を与え、ページキャッシュと CDN がそれぞれを個別に保存していることを確認し、ページが使用するスクリプトのフォントのみを読み込みます。ページの読み込み後にテキストを交換するのではなく、完成した翻訳済み HTML を配信する翻訳方法を選択します。次に、高速英語のホームページには日本語のホームページについて何も記載されていないため、言語ごとに Core Web Vitals を測定します。

主なポイント

各言語を個別に測定します。Google の “良好な” しきい値は、ページ読み込みの 75 パーセンタイルで、LCP が 2。5 秒以内、INP が 200 ミリ秒未満、CLS が 0。1 未満です。
言語固有のURL(/de/, /fr/) は他のページと同様にキャッシュできます。Cookie が選択した言語は通常、できません。
翻訳が変更されたときに翻訳されたページのページキャッシュをクリアすると、訪問者に古いテキストが表示されます。
スクリプトでウェブフォントを分割する unicode-range、したがって、ドイツ人の訪問者は日本語のグリフをダウンロードしません。
訪問ごとに自動言語リダイレクトを避けてください。各リダイレクトは、何かがレンダリングされる前に追加の往復になります。

多言語WordPressサイトが遅い理由

言語を追加すると、サーバーを変更せずにページ数が増加します。200 ページのサイトに 5 つの言語があるため、キャッシュ、クロール、最新情報の保持に必要な URL は約 1,000 個になります。パフォーマンスの問題は通常、次の 5 つの場所のいずれかから発生します

キャッシュが欠落しています。 翻訳されたページはキャッシュされないか、間違ったキーでキャッシュされます。
リクエスト時に翻訳作業を行います。 翻訳は訪問者が待っている間に検索または生成されます。
クライアント側のスワップ。 ページは元の言語で読み込まれ、JavaScript テキストが置き換えられるため、最終的なコンテンツが遅延し、レイアウトが変更される可能性があります。
重いフォント。 中国語、日本語、韓国語、またはアラビア語を追加すると、大きなフォントファイルが追加されます。
ホップをリダイレクトします。 最初の訪問ごとにリダイレクトする言語検出により、往復が追加されます。

それぞれに簡単な修正があります。

ステップ1:言語ごとに測定する

Googleは、優れたコアWebバイタルを実現することを推奨しており、それは“当社のコアランキングシステムが報いることを目指しているものと一致している”と述べていますGoogle検索セントラル)。ターゲット:

メトリック	対策	良い
最大のコンテンツフルペイント（LCP）	読み込み中	2。5 秒以内
次のペイントへのインタラクション（INP）	応答性	200ミリ秒未満
累積レイアウトシフト（CLS）	視覚的な安定性	0。1未満

Web。devでは、これらをモバイルとデスクトップに分割したページ読み込みの75パーセンタイルで判断することを推奨しています(ウェブ開発).

言語ごとの測定方法:

各言語で同じページでPageSpeed Insightsを実行します(/pricing/, /de/pricing/, /ja/pricing/)。違いは、レイアウトの変更を引き起こすフォントや長いテキストなど、言語固有の問題に直接関係しています。
Search Console の Core Web Vitals レポートで、各問題グループの URL の例を開き、どの言語フォルダーが表示されるかをメモします。
サービスを提供する地域からテストします。米国でホストされているサイトは、言語に関係なく、アジアの訪問者にとって待ち時間が長くなります。

ステップ2: 各言語に独自のキャッシュ可能なURLを与える

ページキャッシュは最大の勝利です。WordPress Advanced Administrationハンドブックによると、キャッシュプラグインはページを静的ファイルとして提供し、“かなり静的なページの場合、パフォーマンスを数百倍向上させることができます” (WordPress 開発者リソース).

これは、各言語に個別の URL がある場合にのみ機能します。言語が Cookie またはブラウザの設定によって選択され、同じ URL で提供される場合、ページキャッシュには 1 つの言語が全員に保存されるか、バイパスする必要があります。Google は SEO にも個別の URL を好みます。Cookie やブラウザ設定を使用するのではなく、ページの言語バージョンごとに異なる URL を推奨します“”Google検索セントラル).

キャッシュプラグインのチェックリスト:

以下のページをキャッシュします /de/, /fr/ などなど、除外リストに何も含まれていないことを確認してください。
プラグインがキャッシュをプリロードできる場合は、翻訳された URL を含めます。サイトマップにリストされている場合、サイトマップからのプリロードが最も簡単です。
他に選択肢がない限り、言語 Cookie によってキャッシュを変更しないでください。
元の投稿が編集されたときだけでなく、翻訳が変更されたときに翻訳された URL を消去します。

ステップ3: ロード後にテキストが入れ替わるのではなく、翻訳されたHTMLを提供する

翻訳ツールが翻訳されたページをどのように作成するかは、キャッシュと同じくらい重要です。

サーバー側翻訳 翻訳された HTML をサーバー上で生成します。訪問者は完成したページを受け取り、ページキャッシュにそれを保存できます。
クライアント側の翻訳 元のページを送信し、JavaScript 翻訳を取得してブラウザ内のテキストを置き換えます。どのプラットフォームでも動作しますが、翻訳されたコンテンツは後で到着し、より長い翻訳テキストは要素がペイントされた後に要素を移動できるため、レイアウトシフトとして表示されます。

WordPress では、主要言語にはサーバー側の方法を優先してください。サイトの一部でクライアント側のスクリプトが唯一のオプションである場合は、成長するテキスト（特にボタンとメニュー）用のスペースを予約し、各言語で CLS をテストしてください。

ステップ4: スクリプトでフォントを分割する

ラテン語フォントは小さいです；完全なCJK（中国語、日本語、韓国語）フォントは何倍も大きくなる可能性があります。すべてのページ上のすべてのスクリプトを読み込むと、帯域幅が無駄になります。

を使う @font-face unicode-range ディスクリプタ。MDNは、ページがその範囲の文字を使用していない場合“フォントがダウンロードされていない場合”、および記述子が存在するため、サイト“多くのローカリゼーションがある”がスクリプトごとに個別のフォントリソースを提供できると説明しています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;
}

また:

WOFF2 ファイルをセルフホストし、折り目の上で使用されるラテン（またはメインスクリプト）ファイルのみをプリロードします。
大きな Web フォントではなく、ブランドフォントがカバーしていないスクリプトに適したシステムフォントを使用することを検討してください。
使用 font-display: swap したがって、テキストはすぐにフォールバックフォントで表示されます。

ステップ5: 画像とスクリプトをあらゆる言語で無駄なく保存する

ローカライズされた画像。 言語ごとに画像を置き換え、各バージョンをオリジナルと同様に圧縮してサイズを調整すると、最適化されていない 4 MB のバナーを 1 つの市場に簡単にアップロードできます。
遅延読み込み。 WordPress 追加 loading="lazy" デフォルトでは画像に表示されます。すべての言語テンプレートで、ヒーローイメージが遅延ロードされていないことを確認してください。
サードパーティのスクリプト。 市場固有のチャットウィジェット、支払いバッジ、トラッカーが合計されます。必要な言語またはページにのみロードします。

ステップ6: 不要なリダイレクトを回避する

ブラウザ言語に基づく自動リダイレクトにより、右ページの最初のバイトの前に往復が追加されます。Googleはまた、ユーザーと検索エンジンがすべてのバージョンに到達するのを妨げる可能性があるため、ユーザーを言語バージョンにリダイレクトしないようアドバイスしています“ユーザーの言語がどのようなものであると思われるかに基づいて”(Google検索セントラル).

より良いオプション:

目に見えるスイッチャーを持つ言語を選択し、翻訳された URL に内部でリンクして、自分の言語を維持できるようにします。
リダイレクトする場合は、ホームページへの最初の訪問時にのみリダイレクトし、選択を覚えておいてください。
リダイレクトする URL ではなく、最終 URL に hreflang と内部リンクをポイントします。

ステップ7: サーバー上で基本を正しく理解する

翻訳されたページは基本を変えるものではありません。WordPress ハンドブックでは、キャッシュ、静的ファイル用の CDN、サーバーチューニングが主な手段であると指摘されています

PHPを最新の状態に保つ そしてopcacheが有効になっています。
永続的なオブジェクトキャッシュを追加する ホストがサポートしている場合、特に WooCommerce またはフルページのキャッシュが制限されているメンバーシップサイトの場合は（Redis または Memcached）。
CDNを使用する 画像、CSS、JS の場合、およびセットアップが許可されている場合はページ全体の場合、サーバーから遠く離れた訪問者が近くから画像を取得します。
プラグインリストは短くしてください。 すべてのアクティブなプラグインは、キャッシュされていないすべてのリクエストに対して、すべての言語で実行されます。

ConveyThis WordPress プラグインの適合方法

ConveyThis プラグインはサーバー上のページを翻訳し、各言語を独自のサブフォルダーまたはサブドメインで提供するため、翻訳されたページを元のページと同様にキャッシュできます。各ページと言語の翻訳のローカルキャッシュを保持するため、リピートリクエストは翻訳サービスを待つことなく、翻訳を変更すると、WP Rocket、W3 Total Cache、WP Super Cache、WP Fastest Cache などの一般的なキャッシュプラグインでページキャッシュがクリアされます。

知っておく価値のあるその他の設定:

ページまたはセクションを除外します重要な場所で翻訳作業を維持するために、アカウント領域などの翻訳は必要ありません。
ブラウザ言語による自動リダイレクトは、有効にしない限りオフになり、IPルックアップではなくブラウザの言語を使用します；参照自動リダイレクト.
単語は翻訳されたコンテンツが訪問者に表示された場合にのみカウントされます；ボットはカウントされません。

の WordPress統合ページインストールや設定をカバーしますプランと価格プランごとの単語と言語の制限をリストします。テーマ文字列自体を翻訳するには、ガイドを参照してください WordPressテーマの翻訳.

よくある質問

言語を追加するとWordPressサイトの速度が低下しますか？

する必要はありません。翻訳されたページが独自の URL にキャッシュされ、サーバー上で翻訳が適用される限り、各言語はページごとの重みではなくページを追加します。通常、速度低下は、キャッシュされていない翻訳ページ、クライアント側のテキスト交換、重いフォント、またはリダイレクトによって発生します。

翻訳されたページは個別にキャッシュする必要がありますか？

はい。各言語には独自の URL が必要であり、ページキャッシュと CDN には各 URL が個別に保存される必要があります。翻訳が変更されたら、翻訳されたページをパージします。

各言語のパフォーマンスを測定するにはどうすればよいですか？

各言語の同じページで PageSpeed Insights を実行して比較し、Search Console の Core Web Vitals レポートにどの言語フォルダーが表示されるかを確認します。LCP は 2。5 秒以内、INP は 200 ミリ秒未満、CLS は 0。1 未満を目指します。

多言語サイトの場合、サブディレクトリとサブドメインのどちらが高速ですか？

どちらも本質的に高速ではありません。サブディレクトリは 1 つのホスト、キャッシュ、CDN セットアップを共有するため、管理が簡単になります。リージョンに近いサーバーが必要な場合は、サブドメインを個別にホストできます。

大きなフォントが翻訳ページの速度を低下させるのを防ぐにはどうすればよいですか？

Unicode 範囲記述子を使用してスクリプトでフォントを分割し、ブラウザがページが使用する文字のフォントのみをダウンロードし、WOFF2 を提供し、フォントとディスプレイのスワップを使用するようにします。

成長するにつれて速く保ちます

スピードと翻訳の品質はどちらも、翻訳されたページの作成方法によって異なります。できる ConveyThis アカウントを作成します、 WordPress プラグインをインストールし、翻訳したページをオリジナルと比較して測定します。