パッとしない？Hostinger WEBサイトを複数のコアウェブバイタルに対処しながら、LiteSpeed Cache、QUIC.cloud の CDN を使用して高速化してさらに素晴らしいサイトへ

Hostinger WEBサイトを複数のコアウェブバイタルに対処しながら、LiteSpeed Cache、QUIC.cloud の CDN を使用して高速化してさらに素晴らしいサイトへ

Hostinger のWEBサイトが思ったよりパッとしない?

LiteSpeed Cache をインストールし、QUIC.cloud の CDN で設定を構成することで、遅い Hostinger ウェブサイトを高速化できます。いくつかの Hostinger 設定も役立ちます (PHP 8、Brotli、OPcache、ホットリンク保護、XML-RPC の無効化)。テーマ、プラグイン、画像、フォント、さらにはコア ウェブ バイタルを最適化するなど、一般的な推奨事項もいくつかリストしました。

結局のところ、彼らはホスティング会社を装った詐欺師です。しかし、どうしても使い続けなければならない場合は、Hostinger のホスティングで WordPress サイトを最適化する方法を以下に示します。

1. 遅い TTFB を確認する

ほとんどの速度テスト ツールは、1 つの場所でのみ TTFB を測定します。

TTFB を測定する正しい方法は、SpeedVitals でサイトをテストし (約 3 回)、キャッシュ/CDN が機能していることを確認することです。これにより、世界中の 35 か所で平均 TTFB が測定されます。Pag​​eSpeed Insights を使用すると、TTFB が 600 ミリ秒以上の場合にフラグが付けられますが、<200 ミリ秒が理想的です。

TTFB が遅い場合は、必ずフルページ キャッシュを使用してください (QUIC.cloud にはこの機能があります。または、Cloudflare の APO を使用することもできます)。CDN は TTFB の一部ですが、サーバー (ホスティング) も明らかに他の主要な要因です。

2. DNS を Cloudflare に切り替える

ほとんどのドメイン レジストラ (Hostinger、NameCheap、GoDaddy) の DNS は遅いです。dnsperf.com で非常に優れたパフォーマンスを発揮する Cloudflare の DNS を使用する方がよいでしょう。レイテンシは TTFB の一部であり、TTFB は最大のコンテンツ ペイントの 40% を占めています。つまり、レイテンシが悪いと一連の問題が発生するということです。

Cloudflare の DNS への切り替えは簡単です。無料の Cloudflare アカウントにサインアップし、ウェブサイトを追加して無料プランを選択すると、Cloudflare が 2 つのネームサーバーを割り当てます。これを hPanel で変更します。

Cloudflare ネームサーバーの変更

Hostinger hPanel にログイン(もしくはドメイン管理会社)し、[ドメイン] タブに移動します。Cloudflare から提供された 2 つのネームサーバーをコピーして、ここに貼り付けます。最後に、Cloudflare で [完了、ネームサーバーを確認] をクリックします。

3. LiteSpeed Cache を構成する

Hostinger は LiteSpeed サーバーを使用しているため、優れたレビューのある LiteSpeed Cache プラグインを使用する必要があります。また、サーバーレベルのキャッシュを使用し、コア Web バイタルに対処するための広範な機能を備えているため、他のキャッシュ プラグイン (WP Rocket を含む) と比較して高速です。

LiteSpeed Cache には多くのオプションがあり、最適な設定を使用していることを確認することが重要です。設定するには、完全なチュートリアルを読むことを強くお勧めしますが、以下に、Hostinger の遅い Web サイトを修正するのに役立つ、LiteSpeed Cache 設定で実行できるいくつかの重要な事項を示します。これらはベースラインとして使用する一般的な推奨事項であり、独自の Web サイトに合わせて設定してください。

関連記事：LiteSpeed キャッシュ プラグインを使用して、WordPress を PageSpeed と GTmetrix で 100% 最適化する

4. QUIC.cloud の CDN を設定する

QUIC.cloud の CDN は LiteSpeed で動作するように構築されており、LiteSpeed Cache でページ/画像の最適化に必要です。また、HTML キャッシュも実行します (これにより TTFB が大幅に改善されます)。前述したように、理想的には、70 PoP を使用し、DDos 保護を含む有料 (標準) プランを使用する必要があります。無料の CDN を使用する予定の場合は、Cloudflare を使用する方がよいでしょう。QUIC.cloud は LiteSpeed Cache でアクティブ化できます (手順を参照)。手順は次のとおりです。

• LiteSpeed Cache でドメイン キーをリクエストします。
• CDN 設定で QUIC.cloud を有効にします。
• ドメインを QUIC.cloud にリンクし、ダッシュボードにアクセスします。
• QUIC.cloud の CDN 設定で CDN を有効にします。
• セットアップ方法を選択します (以下は CNAME 用です)。
• QUIC.cloud から CNAME レコードが提供されます。
• Hostinger hPane のゾーン エディターに QUIC.cloud CNAME レコードを貼り付けます。
• 設定で静的キャッシュ + QUIC バックエンドを有効にします。
• DNS が伝播するまで 24 時間待ってから、QUIC.cloud で CDN が機能することを確認します。

5. PHP 8+ を使用する

Hostinger は新しい PHP バージョンのリリースに積極的で、PHP 8 をサポートしています。

1. hPanel にログインし、ホスティング アカウント ダッシュボードを開きます。
2. [詳細] セクションで、[PHP 構成] をクリックします。
3. PHP バージョン (8.0) を選択します。
4. 保存し、サイトにエラーがないか確認します。

6. Brotli + OPcache を有効にする

Brotli はページを圧縮してファイルサイズを小さくします。OPcache は PHP のパフォーマンスと CPU 使用率を向上させます (Hostinger での CPU 使用率を削減できます)。どちらも PHP 拡張機能で有効にできます。

7. ホットリンク保護を有効にする

ホットリンク保護は、画像がまだサーバー上にホストされている間に、他のユーザーが画像をコピーして自分の Web サイトに貼り付けるのを防ぎます (特に高品質の画像がある場合、帯域幅の使用量が削減されます)。Hostinger ダッシュボードで、[その他] → [ホットリンク保護] に移動し、有効にするファイルを選択します。Cloudflare を使用している場合は、ホットリンク保護もあります。

8. XML-RPC を無効にする

XML-RPC は主に JetPack で、またはモバイルからコンテンツを公開するために使用されます。どちらも使用しない場合は、不要なコードが追加されるため、Hostinger ダッシュボード (PHP 拡張機能) で無効にできます。

9. Cron ジョブをスケジュールする

サイト上のいくつかのことは、特定のアクションによってトリガーされます。たとえば、wp-cron はページがロードされる前にジョブを実行し、キャッシュ プラグインで特定のアクションを実行した後にキャッシュ全体が再構築され、キャッシュ プラグインのプリロードによって CPU 使用率が増加する可能性があります。これらを cron ジョブでスケジュールすると、リソースを節約して自動的に実行されないようにすることができます。スクリーンショットは、wp-cron を実際の cron ジョブに置き換える方法を示しています。また、cron ジョブの使用については、キャッシュ プラグインのドキュメントを確認してください。

外部 cron ジョブを設定する前に、まず組み込みの wp-cron を無効にする必要があります。wp-config.php ファイルの「これですべてです。ステップの編集は完了です。ブログを楽しんでください。」の前にコードを追加します。

define('DISABLE_WP_CRON', true);

次に、Hostinger の指示に従います。

次のようになります。

10. 遅いプラグインを避ける

遅いプラグインには 2 種類あります。メモリ使用量を増やすプラグインと、フロントエンドに余分な CSS、JavaScript、フォントを追加してコア ウェブ バイタル スコアにダメージを与えるプラグインです。

したがって、目標によって異なります。Hostinger で CPU の問題が発生し、503 サービス利用不可エラーが発生していますか? または、プラグインによって発生する CSS、JavaScript、フォントに関連するコア ウェブ バイタル項目を改善したいですか (GTmetrix ウォーターフォール チャートで確認できます)?

両方を改善するのは良い考えです。WP Hive Chrome 拡張機能を使用して各プラグインのメモリ使用量と PageSpeed への影響を測定した、一般的な遅いプラグインのリストを見ることができます。

また、Query Monitor などのツールを使用して、速度の遅いプラグインを見つけることもできます。

また、Perfmatters を使用して、読み込む必要のないプラグインを無効にすることをお勧めします:

11. 遅いページ ビルダーを避ける

Elementor、Divi、Fusion Builder (Avada 製) は、サイトに余分な CSS/JavaScript を追加するため、WordPress の速度を低下させることで有名です。明らかに、完全に削除してから、GeneratePress (私が使用しているもの)、Blocky、Kadence、Genesis、または Oxygen Builder に置き換えるのが最善です。

削除したくない場合は、まだできることがいくつかあります。まず、Elementor または Divi のパフォーマンス設定をアクティブ化します。これにより、未使用の CSS、JavaScript が削除され、レンダリングをブロックするリソースが排除されます。また、ヘッダー/フッターを CSS でハード コーディングして、肥大化したページ ビルダー コードに依存しないようにすることもできます。これにより、ページ ビルダーでページを作成できます。

12. 未使用の CSS/JS を削除

Chrome Dev Tools で最後にカバレッジ レポートを確認したのはいつですか?

これは、テーマ、プラグイン、またはサードパーティ コードからのものであることが多い、最大の CSS/JS ファイルを示します。Pag​​eSpeed Insights の複数の項目が CSS/JS に関連しているため、それらを削減/最適化することが重要です。

CSS JavaScript Chrome Dev Tools

ヒント:

• CSS/JS を多用するプラグイン/テーマは避けてください。
• PurifyCSS などの CSS 削除ツールを使用してください。
• Elementor/Divi で CSS/JS 最適化を有効にしてください。
• Perfmatters を使用して、特定のページでプラグインを無効にしてください。
• Gutenberg を使用していない場合は、Gutenberg の CSS を削除してください。
• ヘッダー/フッター/サイドバーを CSS でコーディングしてください (ページ ビルダーは使用しないでください)。
• サードパーティの JavaScript (およびプラグイン) がスクロールせずに読み込まれる場合は、遅延させてください。
• CSS/JavaScript を縮小し、JavaScript を遅延してレンダリングをブロックしないようにします。
• Perfmatters でディスプレイ依存関係を有効にして、jQuery を使用するすべてのプラグインを表示します。
• FlyingPress、LSC、または Perfmatters (WP Rocket ではありません) で「未使用の CSS を削除」を使用します。

13. フォントを最適化する

GTmetrix ウォーターフォール チャートをチェックして、フォントの読み込み時間を確認します。

Web サイトのフォント数を減らすことが最初のステップです。フォントが fonts.gstatic.com などのサードパーティ サイトから取得するのではなく、ローカルでホストされていることを確認します (手動で行うことも、OMGF プラグインを使用して行うこともできます)。また、.ttf ではなく .woff2 形式を使用します。最後に、LiteSpeed Cache で実行できるフォントのプリロードをテストします。Divi と Elementor にもフォントを最適化する設定があります。font-display: swap の使用、CDN からのフォントの提供、システムフォントの使用も試すことができます。

14. Core Web Vitals の改善

遅いホスティングは、LCP の 40% を占める TTFB に影響を与えるため、Core Web Vitals にとって悪影響です。

PageSpeed Insights、Search Console の Core Web Vitals レポート、または SpeedVitals を使用してテストできます (PageSpeed Insights は Chrome UX レポートを使用し、更新に 28 日かかるため)。

Largest Contentful Paint – これは、人々が最も苦労する Core Web Vitals です。LCP の 40% は TTFB であるため、高速サーバーを使用し、フルページ キャッシュを備えた優れた CDN (QUIC.cloud など) を使用していることを確認する必要があります。スクロールせずに見えるコンテンツの最適化も重要です (スクロールせずに見える画像を遅延読み込みから除外してプリロードする)。また、フォントなどの重要なリクエストをプリロードします。CSS/JS の削減、LSC での HTML 要素の遅延レンダリング、画像の最適化も役立ちます。

累積レイアウト シフト – Google のレイアウト シフト デバッガーを使用して、読み込み中に Web サイトのどの要素がシフトするかを調べます。これは通常、フォント、CSS、指定された寸法のない要素 (画像、iframe など)、アニメーション、または動的コンテンツ (広告など) 用のスペースが確保されていないことに関連しています。フォントをローカルでホストしてプリロードし、フォントの CSS に font-display: swap を追加し、キャッシュ プラグインで非同期 CSS を無効にし、重要な CSS を使用し、アニメーションを使用するときに CSS 変換/翻訳プロパティを使用します。これらはすべて CLS の改善に役立ちます。

合計ブロック時間 – ブロック時間は通常、ウェブサイトまたはサードパーティの JavaScript によって発生します。Pag​​eSpeed レポートの「サードパーティ コードの影響を減らす」および「長いメインスレッド タスクを避ける」項目を表示して、どの項目がブロック時間の原因になっているかを確認します。GTmetrix Waterfall を使用することもできます。JavaScript の延期、JavaScript の遅延、アセット アンロード プラグイン内の未使用の JavaScript の削除、可能であればローカルでのファイルのホスティング、結合と非結合のテストを試してください。

結論

Hostinger のウェブサイトが遅いのは、通常、CPU + RAM が低く、DNS が遅く、SATA SSD があり、オブジェクト キャッシュがない安価な共有ホスティングが原因です。支払った金額に見合ったものが得られます。