WordPressのページ速度最適化の究極のガイド

このガイドに従って、WordPressサイトを大幅に高速化するためのすべてのテクニックを学びます。 WordPressでページの読み込み時間を短縮することがビジネスに役立つ最も重要な理由は次のとおりです。ユーザーはウェブサイトを放棄せず、そこでより多くの時間とお金を費やし、検索エンジンは検索結果でウェブサイトをより適切にランク付けします。 準備？

イントロ

インターネットユーザーは、ページの読み込み時間に関してはあまり忍耐力がありません。 リンクをクリックするか、URLを入力して、2、2、3秒待ってください。それだけです。 Googleの統計によると、ユーザーの50％は、モバイルサイトが2秒で読み込まれることを期待しており、53％のユーザーは、3秒より長く読み込まれると、ページを放棄する可能性があります。 モバイルデバイスでのホームページの平均読み込み時間が19秒（3Gネットワ​​ークで）であることを考えると、これは非常に短い期間です。 コンピューターでの読み込み時間は速く、平均読み込み時間は5秒ですが、それでも長すぎます。

デスクトップWebサイトのベンチマークを参照として使用することは、もはや言い訳にはなりません。 今日のほとんどのWebサイトでは、トラフィックの大部分はモバイルデバイスからのものです。 この記事では、WordPressサイトのページ速度を最適化するための最新の手法を詳しく見ていきます。 このガイドに従うと、WordPressサイトを高速化し、モバイルとデスクトップの読み込み時間を大幅に短縮できるため、はるかにユーザーフレンドリーになります。

WordPressサイトをお持ちでない場合は、まだガイドを閉じないでください。 このステップバイステップガイドで説明されている速度最適化手法のほとんどは、あらゆるタイプのWebサイトに適用できます。

オンラインeコマースストアであろうとオンライン/オフラインサービスを販売していようと、サイトが現金化を念頭に置いて構築されている場合、潜在的な顧客を逃すことは決して良いことではありません。 あなたは基本的にテーブルにお金を残しています。 ページ速度を改善すると、収益にプラスの影響があります。 おもしろい事実：オバマの募金キャンペーンは、サイトの最適化とページの読み込み時間を5秒から2秒に短縮することで、寄付のコンバージョンを14％増加させました。

ウェブサイトの所有者または開発者として、私たちは訪問者に最高の体験をしてもらいたいと思っています。 私たちは素晴らしい機能を備えた見栄えの良いサイトを作成しますが、通常、高速なWebサイトの重要性を忘れています。 高速なウェブサイトは訪問者との信頼を築き、訪問者が私たちのページに長く滞在する可能性を高め、したがって彼らはより多くを費やす可能性があります。 一方、私たちのウェブサイトが遅い場合、訪問者はただあきらめるかもしれません、そして彼らは私たちの素晴らしいウェブサイトを見ることさえありません、私たちの同様に素晴らしいオファーで。

上記の理由が十分に説得力がなかった場合は、もう1つあります。 グーグルと他の検索エンジン（SE）は、ウェブサイトが遅いと検索エンジンのランキングが下がり、訪問者がさらに少なくなることを明らかにしました。 つまり、高速なWebサイトがあるということは、Googleがあなたをもっと好きになることを意味し、これによってSEのランキングが大幅に変わる可能性があります。

もちろん、読み込み時間は、訪問者のインターネット速度、訪問者の場所、Webサイトの「重い」または肥大化など、いくつかの理由で異なります。 訪問者のインターネット速度について私たちにできることは何もありませんが、他の側面に気を配り、すべての人の体験を向上させることができます。 このガイドでは、WordPress Webサイトの速度を最適化して、高速で無駄のないものにする方法を見ていきます。

目次

• 財団
  • WordPressホスティング
    • 共有ホスティング
    • マネージドホスティング
    • VPSまたは専用サーバー
  • WordPressテーマ
  • WordPressプラグイン
• WordPressページ速度の最適化手順
  • ページスピードツール
    • Google PageSpeed Insights
    • GTMetrix
    • PingdomWebサイト速度テスト
    • Webページテスト
  • 画像の最適化
    • 画像最適化のためのミニガイド
    • GooglePageSpeed最適化画像
    • その他の画像の改善
    • ケーススタディの改善
  • ブラウザのキャッシュ
  • リソースの圧縮（GzipまたはDeflate）
  • 不要なJSまたはCSSファイルを削除します
  • スクロールオーバーコンテンツでのJavaScriptとCSSのレンダリングブロック
  • サーバーサイドキャッシング
    • WP Rocket（サーバー側キャッシングプラグイン）
  • コンテンツ配信ネットワーク
    • Cloudflare
• 最終結果
• 結論

財団

あなたのウェブサイトをできるだけ速くするために、私たちはそれを良い基盤の上に構築しなければなりません。 家を建てるのと同じように、流砂の上に家を建てたくはなく、最初から問題があります。 しっかりとした土台の上に作りたいので、問題なく長持ちします。 チェックする3つの主なものは次のとおりです。

• ホスティング
• WordPressテーマ
• WordPressプラグイン

WordPressホスティング

ホスティングはWordPressWebサイトの基盤であるため、すでにホスティングを使用している場合でも見逃してはならない重要なコンポーネントです。 より良いホスティングプロバイダーに切り替えると、WordPressの読み込み時間が最大数秒短縮されます。

適切なウェブホストを選択することは重要であり、ホスティングの価格に基づいて決定するべきではありません。 通常、低価格ではパフォーマンスが低下しますが、これは避けたいことです。 利用可能なホスティングオプションを見て、違いを説明しましょう。

共有ホスティング

これは安価であるため、最も普及しているホスティングソリューションです。 しかし、前述したように、低価格ではパフォーマンスが低下します。 共有ホスティングでは、1つの物理サーバー上に数千のアカウントがあります。つまり、サーバーリソースは、これらのホスティングアカウントによって作成されたすべてのWebサイト間で共有されます。

大きなピザを想像してみてください（うーん？…）、共有ホスティングの各Webサイトは非常に小さなピースを取得します。 しかし、あなたのサイトには多くの訪問者がいるので、もっとピザが必要です！ まだお腹が空いていますが、ピザはもうありません:(他のウェブサイトもお腹が空いているので…

ピザのほんの一部を手に入れるだけでは十分ではない場合、潜在的なセキュリティリスクにより、共有ホスティングのケースはさらに悪化する可能性があります。 共有ホスティングで感染したWebサイトは、サーバー全体の速度とパフォーマンスの問題を引き起こし、WordPressサイトも危険にさらす可能性があります。

共有ホスティングのサーバー構成は非常に限られており、好みに合わせて構成するための十分なスペースがありません。 サーバーは特定の、通常は非常に一般的な設定に事前構成されており、WordPressを問題なく実行できるはずです。 後で、メモリ不足の形で、または制限されたPHP設定の形で、プラグインが正しく機能する必要があるという問題が発生します。

私はビジネスのウェブサイトに共有ホスティングを本当にお勧めすることはできませんが、そうしなければならないのであれば、それは非常にトラフィックの少ないサイトに最も適していると言わざるを得ません。

マネージドホスティング

これは共有ホスティングからの大きなアップグレードです。あなたのウェブサイトはより大きなピザを手に入れるからです（ピザのスライス全体です）が、それ以上の費用がかかります。

マネージドホスティング上のサーバーは人口が少なく、サイトのサーバーリソースが増えることになります。 これらのサーバーは通常、WordPressを可能な限りスムーズに実行するように最適化されており、より多くのメモリ、処理能力、およびキャッシュシステムが導入されています。

これらのマネージドホスティングサーバーのハードウェアとソフトウェアのインストールと構成は、ホスティング会社によって行われます（したがって「マネージド」という言葉が使われます）。 バックアップ、ロードバランサー、ディザスタリカバリ、セキュリティチェック/予防などの他のサービスも、ホスティング会社の提供に応じて、マネージドホスティングの一部にすることができます。

マネージドWordPressホスティングは、トラフィックの少ないWebサイトから中程度のWebサイトに推奨されます。

VPSまたは専用サーバー

ピザの例えに固執すると、VPS（仮想プライベートサーバー）ではピザのスライスがいくつか得られますが、ピザ全体ではなく、専用サーバーではピザ全体が得られます。

つまり、専用サーバーを使用すると、サーバー全体とそのすべてのリソースを制御でき、VPSを使用すると、物理サーバーマシンを他のサーバーと共有しているため、サーバーの一部を取得できます。 WordPressのページ速度の最適化に関しては、VPSまたは専用サーバーのいずれかでWordPressをセットアップするときに、サーバー側の制限はありません。 あなたはあなたのウェブサイトに利用できるリソースの量を正確に知っており、あなたはそれをあなたの好みに合わせて設定することができます。 標準のホスティングプロバイダーが最先端の機能をサポートする前に、最先端の機能を実装できます（サーバーソフトウェアテクノロジーよりも数年遅れる可能性があります）。

これらのオプションはどちらも、より優れた制御とリソースを提供しますが、価格が高くなり、長期的にセットアップして維持するためにより多くのスキルが必要になります。 VPS /専用サーバーも管理できるので、サーバーの第一人者でなくても使用できます。 トラフィック量の多いWebサイトに適しています。

どのホスティングを選択するかわからない場合は、マネージドWordPressホスティングオプションをお勧めします。このオプションは、必要に応じて拡張（サーバーからより多くのリソースを割り当てる）もできるはずです。

すべてのまともなホスティングが今までに提供している無料のウェブサイトの最適化は、PHPバージョンを7.xにアップグレードすることです。 WordPressサイトが5.6より古いなどの7未満のPHPで実行されている場合は、ホスティングサポートに連絡して、最新の安定バージョンに更新するように依頼してください。 新しいホスティングを探している場合は、PHPバージョン7.xを使用している場合は、サポートに問い合わせることができます。 それらはすべて確実な「はい」で応答する必要がありますが、PHP 7.xを使用するオプションがない場合は、それらから離れることをお勧めします。 PHP 7は、以前のバージョンと比較して、速度とパフォーマンスの点で大幅に改善されており、非常に簡単に切り替えることができるので、それを利用してください。

良いホスティングの選択は、将来の多くの苦痛を救うでしょう、そしてあなたが問題に遭遇した場合、良いカスタマーサポートがあなたを助けることができるはずです、それで私はまた良いサポートを提供するホストを選ぶことを心に留めます。 利用できる簡単なトリックの1つは、購入前の質問をして、応答時間、態度、プロ意識のレベルを監視することです。

WordPressテーマ

私たちのサイトにWordPressテーマを選択するときは、常にテーマのデザインから始めます。それで問題ありません。 私たちのサイトを素晴らしいものにしたいので、最初に好きなテーマをいくつか選択する必要があります。訪問者が最初に目にするのは素晴らしいデザインです。 2つ目は、おそらくテーマの機能です。 テーマまたはテーマ推奨プラグインは、必要な機能を提供しますか？ もしそうなら、素晴らしいです！ 私たちはビジネスをしています！ ほとんどの場合、テーマの読み込み速度を確認することを忘れています。

テーマのデモページの読み込み時間をテストすると、テーマの速度が最適化されているかどうかがすぐにわかります。 使用するページスピードツールとその使用方法については、以下のセクションで確認しますが、今のところ、購入する前に、テーマ検証のこの追加手順についてお知らせしたいと思います。 もちろん、デモページの読み込み時間はおそらく改善される可能性があるため、完全なスコアを取得しなくても心配しないでください。コンテンツが非常に少ない場合を除いて、WordPressテーマが完全な100％スコアを取得することはありません。そのデモページで。 経験則として、赤い数字にないテーマを探す必要があります（ページ速度ツールでスコア50以下）。

それは、テーマのデザインと機能性とテーマの速度のバランスが取れていることです。 たとえば、テキストが少し含まれている空のWordPressテーマは非常に高速に読み込まれますが、多くのマルチメディアコンテンツを備えた、多くの機能（ほとんどは必要ない場合があります）を備えた肥大化したテーマの読み込みははるかに遅くなります。 優れたパフォーマンスの高いWordPressテーマを選択するときは、そのスイートスポットを見つけることが目標です。

WordPressプラグイン

よく出てくる質問は、「プラグインが多すぎるのか」というものです。 WordPressプラグインの数では問題ありませんが、コードの品質とプラグインがシステムに与える影響には問題があります。 50以上のアクティブなプラグインを持つことができ、各プラグインは小さな特定の機能（適切なコードを使用）を処理し、サイトは正常に実行されます。 一方、5つのアクティブなプラグインがあり、そのうちの1つがシステムを詰まらせて、WordPressの速度を低下させている可能性があります。

各プラグインのコードを確認することは良い考えですが、「誰もそのための時間を持っていない」ことに加えて、そうするためには十分なプログラミング知識が必要になります。 その道を進む場合、注意すべきことは、多くの外部リソースをキューに入れ、多くのHTTPリクエストを作成し、不要な（最適化されていない）データベースクエリを作成するなど（基本的にWordPress Webサイトの速度を低下させるものすべて）です。その背後にある適切な理由なしに）。

私がお勧めするのは、必要だと思う各プラグインをインストールしてアクティブ化しないことです。

最初に考えてみてください。あなたのサイトには本当にこの追加機能が必要ですか？ たとえば、ボタンのショートコードが必要な場合は、テーマのドキュメントを確認してください。テーマにショートコードが含まれている可能性があり、単一のボタンのショートコードを使用するためだけにショートコードバンドルプラグイン全体をインストールしてアクティブ化する必要はありません。 これは簡単な例ですが、新しいプラグインをインストールしてアクティブ化する前に、よく考えてください。 未確認のプラグインはそれぞれ、サイトを重くして遅くする可能性があります。さらに、プラグインのコーディングが不十分であるか、メンテナンスされていない場合、セキュリティ違反につながる可能性があります。

最後に、プラグインを選択するときに活用できる素晴らしいことの1つは、WordPressのグローバルシェアが大きく、その結果、コミュニティが巨大になることです。 コーディングの知識が不足しているため、経験則として、アクティブなインストールが多く、平均評価スコアが高く、肯定的なレビューが多い人気のプラグインを使用することをお勧めします。 仲間のWordPressersを使用すると、選択が非常に簡単になります。

WordPressページ速度の最適化手順

最適化を始める前に、いくつか言及したいと思います。

まず、WordPressサイトのバックアップを作成する必要があります。これは、WordPressプラグインを使用して作成する方法のガイドです。 転ばぬ先の杖！

次に、ガイドで使用するページ速度ツールで100/100スコアを期待しないように警告します。 100/100のスコアを追いかけるのは良い考えではなく、一部のサイトでは不可能ですらあります。 それはすべてあなたのサイトが表示しているコンテンツの種類に依存します。 サイトにほんの少しのテキストと画像しかない場合、確かに、完璧なスコアは完全に可能です。 ただし、ページが長く、マルチメディアコンテンツが多く、Googleマップなどのサードパーティ製アプリが統合されている場合は、100スコアが表示されないため、それを追求するべきではありません。

100/100で行くのはなぜ良い考えではないのですか？ ページ速度ツールの指示に従い、すべてを最適化すると、サイトが正しく機能しない可能性があります。 すべてのブロックしているJSまたはCSSファイルをフッターに移動すると、CSSの点滅が表示されます（スタイルが設定されていないコンテンツが最初に表示され、CSSが読み込まれると、サイトが所定の位置に「点滅」します）、JSコードでも同じことが起こります。 、JSコードがロードされた後にDOM要素を変更します。

やみくもに指示に従い、WordPressサイトを最適化して読み込み時間を改善し続けると、完璧なスコアを取得するために、サイトが破損する可能性があります。 完璧なページ速度スコアは単なる数値であり、訪問者がサイトを壊してしまった場合でも、実際には問題にはなりません。 ページ速度とユーザーエクスペリエンスのバランスを探る必要があります。

WordPressページ速度の最適化のデモンストレーションでは、共有ホスティングアカウントと医療用WordPressテーマ（テーマ推奨プラグインを使用）を使用します。 ええ、ええ、私は基本的に共有ホスティングを使用しないと言ったことを知っていますが、それが何を可能にし、どのような制限があるかを見ていきます。さらに、これは単なるページ速度最適化テストであり、実際のビジネスワードプレスのウェブサイトではありません

最新バージョンのWordPress、MedicPressテーマ、すべてのテーマ推奨プラグインをインストールし、デモコンテンツをインポートしました。 これがテストサイトの出発点です。

ページスピードツール

ページ速度の最適化は難しい場合がありますが、ありがたいことに、Webサイトの速度を向上させるために、私たちの生活を楽にし、何をすべきかをアドバイスするオンラインツールがあります。

WordPressの速度を最適化するための最初のルールは、次のとおりです。常に測定してください。

各最適化ステップの後に、以下のセクションで確認するツール（または少なくとも1つのツール）を実行し、改善点を追跡します。 このようにして、どのタスクが最大の改善をもたらすかを知ることができます。 また、実際の平均読み込み時間を確認するには、テストを複数回実行する必要があります。

ページの読み込みは、ホスティングサーバーの場所によって異なります。 たとえば、サーバーが北米にあり、訪問者がヨーロッパからの場合、カナダの訪問者よりもページの読み込みが遅くなります。 この問題はCDN（Content Delivery Network）で修正できますが、これについては記事の後半で説明します。 今のところ、この問題は世界中の訪問者とページ速度最適化ツールに存在することを指摘したいと思います。 一部のツールでは、さまざまな場所からテストを実行できるため、ロード時間にどのように影響するかを確認できます。

ここで取り上げるページ速度ツールは次のとおりです。

• Google PageSpeed Insights
• GTmetrix
• PingdomWebサイト速度テスト
• WebPageTest

他のツールもありますが、これらは最も人気のあるツールであり、私たちはそれらに固執します。

Google PageSpeed Insights

このツールのタイトルからわかるように、これはGoogleの製品です。 スコア（デスクトップとモバイルに分割）とページの読み込み時間を改善するための便利な手順の横に、Googleがウェブサイトで見たいものについて結論を出すこともできます。 検索エンジンの結果で上位にランク付けするために、Webサイトで最適化する必要があるもの。

最適化されていない画像またはリソースファイル（JSまたはCSS）がある場合は、最適化された対応物を含むzipファイルが生成され、サーバー上で置き換えることができます。 かなりきちんとしていますよね？ 画像とコードの最適化については後で説明しますが、GooglePageSpeedがそれを支援できることを知っておいてください。

Google PageSpeed Insightsには、他のツールのように多くの詳細情報はありませんが、ページ速度の最適化のすべての重要な側面をカバーする良い出発点です。 それはあなたのサイトを最も改善するステップをリストします。

テストサイトのURLを使用してこのツールを実行したところ、デスクトップで71、モバイルで67のスコアが得られたため、改善の余地があります。 可能な最適化の提案のリストは次のとおりです。

• 圧縮を有効にする（gzipまたはdeflateでリソースを圧縮する）、
• 画像を最適化し、
• サーバーの応答時間を短縮し、
• フォールド上のコンテンツでレンダリングをブロックするJavaScriptとCSSを排除します。
• JavaScriptを縮小します。

GTmetrix

このツールは、最適化されているものと最適化されていないものに関するより詳細な情報を提供します。 各最適化の詳細が一覧表示され、0〜100のスケールで評価されます。 リストは重要度順に並べられているため、タスクを上から下にたどり、スコアが100％でないタスクを最適化すると、WordPressサイトをできるだけ早くスピードアップするための良い道を歩むことができます。

GTmetrixは、PageSpeedおよびYSlowテストツールを使用して、ページのスコアを生成し、改善が必要なタスクを表示します。 このツールの優れた機能は、ウォーターフォールレポートでもあります。これは、サイトの読み込み方法をグラフィカルに表し、ボトルネックをより迅速に特定できます。 下の画像では、私の遅い共有ホスティングが最初の情報で応答するのに1.13秒かかったことがわかります。 それは長すぎますが、私たちはそれを改善することができます。

また、世界中の7つの異なる場所からページをテストすることもできます。これは、テストするのに便利で重要なことでもあります。これについては、この記事の後半で説明します。

テストサイトでGTmetrixツール（場所：カナダ、バンクーバー）を実行したところ、PageSpeedスコアが77、YSlowスコアが71でした。このツールを使用すると、次の有用な情報も得られます。

• フルロード時間：3.1秒、
• 総ページサイズ：803KB
• リクエスト：54

GTmetrixツールが一番好きです。1か所で多くの関連情報を入手できるからです。 このガイドでは、主にGTmetrixツールを使用して最適化の進捗状況を測定します。

PingdomWebサイト速度テスト

Pingdomは、最適化情報を少し異なる方法で表示する別のツールです。 GTmetrixツールと同じ基本的な要約データを取得します（YSlowスコアなし）。 Pingdomを使用すると、4つの異なる場所でページ速度をテストするオプションがあります。 結果は場所ごとにすべて異なります。これは、サーバーの場所が重要であることを示していますが、それも改善することができます（CDNについては、この記事の後半で説明します）。 Pingdomテストはより迅速に完了するため、Pingdomツールを使用して利用可能な4つの場所でページの読み込み時間をテストします。

Pingdomは、コンテンツサイズやリクエスト数など、コンテンツタイプまたはドメインでフィルタリングされた興味深いテーブルも表示し、ウォーターフォールレポートもあります。

WebPageTest

WebPageTestツールには、以前のツールよりもさらに多くの構成オプションがあります。 選択できる場所が増え、インターネット速度を選択でき、いくつかのブラウザオプションを有効/無効にしたり、特定のデバイスをテストしたりできます。

これは優れたツールであり、実行ごとに詳細なウォーターフォールレポートを表示し（デフォルトでは3回実行しますが、設定で変更できます）、これらの速度最適化係数ごとにAからFのグレードを表示します。

• 最初のバイト時間（応答時間）、
• キープアライブを有効にし、
• 圧縮転送（gzip）、
• 画像を圧縮し、
• 静的コンテンツをキャッシュし、
• CDNの効果的な使用。

すべての結果タブをチェックすることで、詳細に入ることができます。ここには、多くの有用な情報があります。 詳細なレポートが必要な場合、またはサイトで利用可能な場所をテストする必要がある場合は、このツールを使用します。それ以外の場合は、GTmetrixにもっと簡潔な情報があると思います。

このツールをテストサイトで実行しました。 以下のスクリーンショットで結果を確認できます。

より人気のあるページ速度ツールを調べ、最初のページ速度テストを行ったので、ついにWordPressサイトの最適化を開始する準備が整いました。 参考までに、これらは、速度最適化の進捗状況を測定するために使用するページ速度ツールからの開始点の結果です。

• Google PageSpeed Insights
  • モバイル：67
  • デスクトップ：71
• GTmetrix
  • PageSpeed：77
  • YSlow：71

画像の最適化

これはおそらくサイトのパフォーマンスで最も無視されている側面であると同時に、サイトの速度を最大に向上させる可能性があります。 WordPressサイトにアップロードする前に画像を最適化することを考えたことがない場合、これはWordPressの読み込み時間を最適化するための優れた最初のステップです。

ウェブサイトの小さな場所で使用されている、最適化されていない大きな画像をアップロードすることは、大きな「ノーノー」です。 例：サイトに600 x 400ピクセル以下の画像スロットがあり、1920 x 1080ピクセルの画像（またはそれ以上）をアップロードします。 今、あなたはこの間違いを数回繰り返すとあなたのサイトは非常に遅くなります。

最初に行うことは、画像のサイズを適切なサイズに変更することです。 この例では、画像スロットが600 x 400ピクセルより大きくなることはないため、画像のサイズをそのサイズに変更する必要があります。

「それで、仕事は終わりましたよね？」 いいえ。 画像をさらに改善することができます。 品質を損なうことなく画像を最適化（圧縮）するツールはたくさんあります（私たちの目はこれらのツールでは品質の低下を検出できません）。 これにより、画像ファイルのサイズも大幅に縮小され、読み込みが速くなります。

画像圧縮は手動またはWordPressプラグインで行うことができます。 同僚のマルコが画像最適化の驚異的なガイドを書いたので、彼の記事から得た知識を使用して、画像を最適化するために使用できる手法について簡単に説明します。

画像最適化のためのミニガイド

適切な画像形式を選択してください–オンラインで使用する最も一般的な画像形式はJPEGとPNGです。 正しい画像形式を選択することで、画像ファイルのサイズを大幅に節約できます（Markoは彼の記事で45％節約しました）。 次を使用する必要があります。

• 写真、グラデーションのある画像、数百万色の画像の.jpg形式。
• 制限された色（ロゴ）の画像と透明度のある画像の.png形式。

画像のサイズを変更する–前述のように、WordPressサイトにアップロードする前に、必ず画像のサイズを変更する必要があります。 まず、画像を使用するスペースの大きさを確認し、それに応じてサイズを変更します。 GIMPやPhotoshopなどの画像操作プログラムを使用して画像のサイズを変更できます。

画像を圧縮する–これは、オンライン画像圧縮ツールまたはWordPressプラグインを使用して実行できます。

オンライン圧縮ツール：MarkoはOptimillaオンラインツールを推奨しています。 画像をOptimillaアプリにアップロードし、プロセスが完了したら、最適化された画像をダウンロードして、WordPressサイトにアップロードするだけです。 これは少し退屈に聞こえるので、もちろん、このプロセスを簡素化できるWordPressプラグインがあります。

WP画像圧縮プラグイン：ここでも、Markoは最も人気のある画像圧縮プラグインをテストし、勝者を宣言しました：ShortPixelImageOptimizer。 プラグインをインストールした後、プラグインを使用するためにAPIキーをリクエストする必要があります（非常に簡単なプロセス）。 プラグインのデフォルト設定は素晴らしいので、何も設定する必要はありません。[メディア]-> [バルクShortPixel ]に移動し、[最適化を開始]ボタンをクリックするだけです。 新しくアップロードされた画像も最適化されます。 注：このプラグインの無料バージョンでは、月に100枚の画像の最適化しかできません。さらに必要な場合は、有料プランに切り替える必要があります。 お客様に最高のツールを利用してもらいたいので、ShortPixelと提携し、 ProteusClubメンバーもShortPixelWordPressプラグインで1,000クレジットを無料で利用できるようになりました。

最後に、WordPressでの画像の最適化に関する記事全体を読むことをお勧めすることはできません。

GooglePageSpeed最適化画像

これは、WordPressサイトの既存の画像を最適化するための代替方法です。 上記の手順（画像最適化のミニガイド）を実行した場合は、おそらくすでに画像が最適化されているため、GooglePageSpeedには画像がありません。 よくできた！ 情報提供のためにこのセクションを読むことができます

Google PageSpeedツールの紹介で、Googleはサイトで使用できる最適化されたファイルを含むzipファイルを生成することを説明しました。 このリンクをクリックすると、zipファイルをダウンロードできます。

このzipファイルには、最適化された画像を含むimageというフォルダーがあります。 FTPまたはホスティングファイルアップローダーを介してアップロードできます。 正しいアップロードフォルダ（…/ wp-content / uploads /…）の画像を置き換え/上書きします。 その後、WordPressサイトでこれらの画像の小さいバージョン（サムネイル）も生成する必要があります。 RegenerateThumbnailsプラグインを使用してこれを行うことができます。

その他の画像の改善

このセクションでは、画像に関するいくつかのさらなる改善点を見ていきます。これを利用して、パフォーマンスをさらに向上させることができます。

遅延読み込み画像

遅延読み込みは、画像を非同期で読み込む手法です。 折り畳み上にない画像は、ページの読み込み時に読み込まれません（必要になった後、または必要な場合にのみ読み込まれます）。 つまり、ページの上部に表示される画像が読み込まれ、ページの読み込み後またはユーザーがページを下にスクロールするときに（オンデマンドで）他の画像（表示されない）が読み込まれます。 多くの画像を含む長いページがある場合は、この手法を使用すると、最初のページの読み込み時間を大幅に節約できます。

遅延読み込みは、カスタムコードまたはWPプラグインを使用して実装できます。 後でWPRocketキャッシングプラグインを使用し、遅延読み込み機能も備えています。

画像のホットリンク

ホットリンクとは何ですか？ 別のサーバーでホストされている画像を表示しています。 たとえば、非常に人気のある投稿があり、その投稿に素敵な画像がある場合です。 訪問者（泥棒）は、画像のソースURLをコピーして、自分のサイトで使用する場合があります。 つまり、画像はサーバーから要求され、提供されます。 泥棒に100を掛けると、サーバーが応答する必要のある外部要求が数千になり、サーバーの速度が低下する可能性があります。

これは直接的なページ速度の最適化ではなく、サーバーの最適化です。 .htaccessファイルのコードを使用して、ホットリンクの問題を解決できます。 さらに一歩進んで（少し邪悪になります）、盗まれた画像を別の画像に置き換えることができますが、あまり良くない画像かもしれません:)。 これは、.htaccessファイルでも実行できます。 サーバーで.htaccessファイルを開き、このコードを追加します。 your-website.comを自分のドメインに置き換え、 google.comを他のドメインに置き換えて、画像へのアクセスを許可し、http：//replacing-stolen-image-url-goes-here.jpgを置き換えます。盗まれた画像に対して表示したい画像のURLを使用します。

 RewriteEngine on RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?your-website.com [NC] RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?google.com [NC] RewriteRule \.(jpg|jpeg|png|gif)$ http://replacing-stolen-image-url-goes-here.jpg [NC,R,L]

盗まれた画像をカスタム画像に置き換えたくない場合は、このコードを使用してください。 これにより、Webサイトの画像が無効になります。

 RewriteEngine on RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?your-website.com [NC] RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?google.com [NC] RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]

ケーススタディの改善

画像を最適化した後、これまでのテストサイトでの進捗状況を見てみましょう。 ご存知のように、テストサイトとして使用している医療テーマのデモデータをインポートしました。 これらのデモ画像は正しいファイル形式を使用しており、すでに正しいサイズになっているため、これらの2つの手順をスキップできます。 新しい画像をアップロードする場合は、スキップしません。

そこで、ShortPixelプラグインをインストールし、バルクオプティマイザーを実行しました。 プラグインは38％の平均画像最適化を報告しました。 それは素晴らしいことです！

私はPageSpeedInsightsツールを実行しましたが、一部の画像はさらに圧縮できるとGoogleが指摘したので、私は自分のアドバイスに従い、Googleが用意した画像を使用して、FTP経由でサーバーにアップロードしました。

画像を並べ替えた後、ページ速度ツールの結果は次のようになりました。

• Google PageSpeed Insights
  • モバイル：72
  • デスクトップ：77
• GTmetrix
  • PageSpeed：81
  • YSlow：71

デモデータで使用されている画像はすでにかなり最適化されているため、大きな改善ではありませんが、それでも目標に一歩近づいています。 サイトに最適化されていない画像がある場合、この画像最適化手順により、スコアが大幅に増加し、ページの読み込み時間が短縮されます。

ブラウザのキャッシュ

ユーザーがブラウザを介してサイトにアクセスする場合、訪問者にサイトを表示するには、サーバーからすべてのリソース（HTML、画像、JS、CSSなど）をダウンロードする必要があります。 同じユーザーがサイトの別のページにアクセスした場合、通常、CSSファイルとJSファイルは同じままですが、適切なサーバー構成が設定されていない場合、ブラウザーはサーバーからそれらを再度ダウンロードする可能性があります。

静的リソース（JS、CSS、およびその他のファイル）をブラウザーのキャッシュに保存できるように、サーバーに適切なキャッシュヘッダーと有効期限を設定する必要があります。 これにより、リピーターやサイトの複数のページを閲覧する訪問者のパフォーマンスが大幅に向上します。

通常、ホスティングサーバーにはすでに構成されています。 If the page speed optimization tools report that you are missing the “Leverage browser caching” optimization or something like that, then it's best to contact your hosting company and let them know that you want to set-up browser caching for your site. They will be able to sort that out for you or at least point you to the right direction on how to do that yourself.

If you want to do things yourself, then you have to know that these browser caching settings vary, depending on the server type your hosting company is using. A good starting point for Apache servers is the .htaccess file of the HTML5 Boilerplate project (check out the “Expires headers” section). An nginx configuration is available as well.

My shared hosting account has browser caching already configured, so there is nothing for us to do on our test site.

Resource Compression (Gzip or Deflate)

Files sent from your server (HTML, JS, CSS, …) to your visitors can be compressed, so that they can be transferred faster, which improves your page speed. This can be done by enabling Gzip or Deflate compression on your server.

You can contact your hosting support and ask them, if they can enable resource compression for your site or you can configure it yourself, but be sure you know which server type your hosting is using. We can again look at the HTML5 Boilerplate project for some tips, they have default server configs for each of the major server types. For example, my hosting is using Apache server, so I found this compression config. I've copied the content of this config, I've located the .htaccess file for my WordPress site via the FTP (it's in the root of your WP installation) and I copied it at the end of the file.

I've re-run the page speed tools, after I've enabled the resource compression for my WordPress site and here are the results:

• Google PageSpeed Insights
  • Mobile: 83
  • Desktop: 90
• GTmetrix
  • PageSpeed: 96
  • YSlow: 82

As you can see, we've improved our scores by a fair amount and all we did, was enable the resource compression, which did not take a lot of time. By compressing resources, we change the total page size from 803KB to 476KB, which is awesome! We made another step towards an optimized site, so let's continue.

Remove unneeded JS or CSS files

If you are using plugins, which include JS or CSS files on all your pages and you actually are not using the plugin features on those pages, then it's best to remove them. This can be done with custom code in your child theme, but I would recommend that you use a plugin for that. It's much easier!

The plugin that will help us do that is WP Asset CleanUp. After you install and activate this plugin, go and edit your home page. Home pages are usually the “heavier” pages, so we will look at it for our example, but you can do that for other pages as well.

Under the page content editor, you will see a section called WP Asset CleanUp . This section will list all CSS and JS files that are included on your front page. Now, your job is to find out, which of these files are not needed on your WordPress front page.

For example, in our test site, we are using the Contact Form 7 plugin, but we are only using the contact form on our “Contact Us” page, so we can safely remove (unload) its CSS and JS files from our home page. I can do the same with WooCommerce assets, since we are not using them on our home page as well. You should look at each asset in the list and check, if you can unload it. Watch out for the files with the red exclamation icon, you should probably never unload these, since they are core WordPress files and they are needed for the site to work properly. This is how my home page Assets CleanUp settings looks like:

I was able to safely remove 11 assets, which will save 11 resource requests when a page loads and that will improve the page speed.

Re-run of page speed test tools showed, that Google PageSpeed Insights score did not change (because it also did not list this as a recommended optimization), but the GTmetrix score did improve:

• Google PageSpeed Insights
  • Mobile: 83
  • Desktop: 90
• GTmetrix
  • PageSpeed: 97
  • YSlow: 86

Our site also loads faster, it now needs 2.7 seconds to load the whole site (in the beginning it took 3.1 seconds). We are improving the WordPress site speed slowly but surely. Bear in mind, I'm using one of our WordPress themes for the test, which are built from the ground up to be performing out of the box. If you're using some other WordPress theme, where the author didn't put any efforts to optimize it for speed, your improved loading speed results will most probably be much greater at this point.

With removing unneeded JS and CSS files from our home page, we improved our scores, load time, number of request and the total page size as well. よくできた！

Render-blocking JavaScript and CSS in above-the-fold content

One of the optimizations that Google PageSpeed Insights suggests is also: “Eliminate render-blocking JavaScript and CSS in above-the-fold content”. これはトリッキーなものです。 Remember when I said, that it's not good to chase a perfect score in the page speed tools? This is one of the reasons for that.

If we look at our example, the Google tool suggests that the Page Builder front-flex.css should be deferred or loaded asynchronously. We are using the Page Builder by SiteOrigin plugin for building content in our pages. So, if this file is responsible for making our layout of the page look good, then I might not respect Google suggestion and simply ignore it.

“But why would you disrespect Google? How dare you!” Well, this is only a tool and it gives you suggestions on what to do, but it does not know, if implementing some of these changes will break your site or ruin good user experience (UX) for your visitors. For example, if the tools had suggested that we load the style.css file with all the theme styles asynchronously, then it would have created the FOUC: Flash of unstyled content:

This is a bad UX, so I would ignore the suggestion from the tool and keep a good UX instead of improving our score. After all, Google is also using other factors it can gather from your website to rank it in the search results and user experience is one of them. When optimizing the website for speed, don't follow the recommendations blindly and forget about all the other aspects and goals your WordPress website has.

If the files that the tool suggests to be loaded asynchronously are valid candidates and they don't break anything, then of course we can implement that change. The best way is to just try to asynchronously load each suggested file and see, if the page still loads ok. Don't forget to reload the page without browser cache, so that a fresh copy of the page loads. You can do that by hard refreshing your site.

We will look at how to load files asynchronously in the WP Rocket plugin section below. There are other standalone plugins that offer this functionality, but since the WP Rocket has it build in, we don't need to pollute our WP installation with more plugins.

Server Side Caching

We've already talked about browser cache, but now we also have to take care of the server side cache. To understand server side caching we have to know the basics of how WordPress works, so let's look at that first.

When a visitor opens a WordPress page, the following things happen (basic explanation):

1. Server receives a page request.
2. WordPress PHP code begins to execute.
3. WordPress access the database to get the information it needs to build the requested page.
4. WordPress produces the HTML.
5. Server responds with the HTML for the browser to display it to the visitor.

These 5 steps have to be repeated for each page view, for each visitor. That's a lot of repetitive work for content that stays the same for each visitor (if your site is displaying mostly static content, which majority of websites is).

Server side caching eliminates pretty much all the server's hard work. It removes the need for repeating steps 2,3 and 4. So, when we enable server side caching, the process of a page request looks like this:

1. Server receives a page request.
2. Server retrieves the page HTML from the cache (if a cached version is available).
3. Server responds with the HTML for the browser to display it to the visitor.

As you can see, the hard work of running the WordPress code and accessing the database is bypassed, which means that the page loading time should be much faster.

If we look at the Google PageSpeed Insights tool suggestions, we will spot the “Reduce server response time” task. The tool says that our server responded in 0.98 seconds, which is not good. The slow shared hosting I'm using is definitely to blame for some chunk of that 1 second response time, but we'll be able to shorten it with server side caching.

Each page cache is usually saved with an expiration time of 24 hours, but that setting can be changed. This means that instead of thousands of page requests running the whole WordPress HTML building process, it will only be run once a day, to generate that cached page and the server will serve that cached page to other visitors. So, not only the page will be quicker, but the server will also have to do less work.

If you are updating a page in WordPress and an old cached version of the page is still available on your server, then you would have to clear that cache manually (usually with the click of a button) or some tools would do that for you automatically.

Some hosting companies already have a server side caching in place for their users, but this feature is usually available for managed WordPress hosting packages. So, before you follow instructions below, on how to setup server side caching, you should make sure that your server is not doing that for you already.

We will look at how to setup the WP Rocket plugin to enable server side caching and other features that it has (like lazy loading images, loading assets asynchronously, minification of JS and CSS files and much more). WP Rocket is a premium (paid) plugin, but I believe it's worth the investment. If you don't agree with me, that's fine WP Super Cache is a good free alternative, but it does not have the same extra features as WP Rocket and it's a little bit more cumbersome to setup.

WP Rocket (server side caching plugin)

As soon as we install and activate the WP Rocket plugin it will have some basic features enabled out of the box:

• Caching of all the pages for quick viewing.
• Decrease bandwidth usage with our GZIP compression.
• Management of the headers (expires, etags…).

The WP Rocket plugin default settings are a good starting point.

I've run the page speed tools a couple of times, so that they picked up the cached version of the site and these are the new results:

• Google page speed insights
  • Mobile: 91
  • Desktop: 97
• GTmetrix
  • PageSpeed: 97
  • YSlow: 87

The Google PageSpeed Insights tool no longer displays the “Reduce server response time” optimization suggestion, because we reduced it from 1 second to 121ms, that's a 88% improvement in server response time, just by activating the WP Rocket plugin! With this improvement, our fully loaded time is now 1.9 seconds, but we are not stopping here

WPRocketプラグインが提供する設定を見てみましょう。 WP Rocketの上部のWP管理メニューバーには、便利なショートカットメニューがあります。 そこから、設定ページにアクセスしたり、キャッシュをクリアしたり、このプラグインに関するその他の有用な情報にアクセスしたりできます。

続行してさまざまなWPRocket設定を試す前に、変更を加えるたびに、シークレット/プライベートブラウザタブでサイトを確認する必要があることをお伝えしておきます。 WordPressサイトにログインしている場合、キャッシュされたバージョンのサイトは表示されません。 シークレットブラウザのタブではログインせず、キャッシュされたバージョンのサイトが表示されるため、正常に機能しているかどうかを確認できます。

また、使用しているテーマやプラグインによっては、各WP Rocket設定を有効にすると、WordPressの速度に異なる結果や悪影響が生じる可能性があるため、すべてのWPRocket設定を有効にするだけでは不十分です。 それぞれの設定を試して、ページ速度ツールで測定し、違いを確認する必要があります。 ご覧のとおり、一部のテクニックではページ速度が向上しないため、使用しません。

キャッシュの消去

WP Rocketプラグインをアクティブ化するとすぐにサーバー側のキャッシュが機能し始めるので、それをクリアする方法を見てみましょう。 WP Rocketショートカットメニューのメニュー項目[キャッシュのクリア]をクリックすると、手動でキャッシュをクリアできます。 プラグインは、カスタマイザー設定を更新したり、ウィジェット、カテゴリーを変更/更新したりするときに、キャッシュを自動的にクリアします。また、ページを更新すると、キャッシュを部分的にクリアします。 自動キャッシュクリアがいつ発生するかについての詳細は、このWPロケットの質問を参照してください。

キャッシュの寿命は、WPロケット設定の「基本」タブで設定できます。 これを1日に設定することをお勧めします。

キャッシュのプリロード

WP Rocketの優れた機能は、「プリロードキャッシュ」です。これは、ホームページとリンク先のページのキャッシュをプリロードするため、ユーザーは常にキャッシュされたバージョンのページを取得できます。 ページ速度ツールを実行する前にこの機能を使用でき、キャッシュされたバージョンの結果を取得するためにツールを複数回実行する必要はありません。

プリロードキャッシュ設定には、[プリロード]タブの設定ページからアクセスできます。 「ボットのプリロード」オプションを探してください。そこに手動オプションと自動オプションがあります。 自動ボットオプションを有効にすると、ページを更新または作成するたびに、またはキャッシュの有効期限が切れた場合に、プリロードキャッシュが実行されます。 このオプションはサーバーのパフォーマンスに影響を与える可能性があるため、有効にする場合はパフォーマンスログに注意してください。 多数の投稿/ページを更新および作成していて、共有ホスティングを使用している場合は、このオプションを有効にしないことをお勧めします。 代わりに手動ボットオプションのみを有効にする必要があります。これにより、「キャッシュのプリロード」というタイトルの別のWP Rocketショートカットメニュー項目が作成され、クリックした場合にのみキャッシュがプリロードされます（投稿とページの編集が完了した後）。

[プリロード]設定タブには、サイトマップからキャッシュをプリロードするための設定もあります。サイトマップを定義すると、サイトマップのURLを使用してそれらのページのキャッシュをプリロードします。

LazyLoad

この記事の画像最適化のセクションで遅延読み込み画像についてはすでに説明しましたが、WP Rocketがインストールされたので、実際にこの機能を有効にすることができます。 WPロケット設定の[基本]タブに移動し、画像のLazyLoadを有効にします。動画やiframeを使用している場合は、それも有効にできます。

この機能を有効にした後は、常にサイトをチェックして、画像がどのように読み込まれるかを確認する必要があります。 LazyLoadはサイトのレイアウトを壊したり、画像の読み込み方法が気に入らない（コンテンツのジャンプ）可能性があるため、常にページを確認してください。 この機能は、折りたたまれていない画像がたくさんある場合に非常に便利で、元のページの読み込み時に画像リクエストの数を減らすのに役立ちます。 テストサイトでは、画像が5つしかありません。そのため、5つの画像リクエストを保存し、ページの読み込み時間は1.7秒に短縮されましたが、ページ速度ツールのスコアは同じままでした。 これは、ツールが提案しない特定のタスクでページ速度を向上させることができるという良い指標です。

ファイルの縮小

まだ改善できるGTMetrixの提案のいくつかは、HTML、CSS、およびJSファイルを縮小することです。 WordPressテーマと推奨プラグインの大部分はすでにJS / CSSファイルの縮小バージョンを使用しており、サーバーでGzipが有効になっているため、このWPロケットの最適化によってテストサイトに大きな改善はもたらされませんが、あなたのケースは違う。 WPロケット設定の「静的ファイル」タブに移動し、「ファイルの縮小」オプションの下にある3つのオプションすべてをチェックします。 設定を保存し、シークレット/プライベートタブでウェブサイトを確認してください。そうすれば、これらのオプションがサイトにもたらす可能性のある問題を探すことができます。 私のテストWordPressサイトでは、CSSミニファイによってページビルダーのフレックスボックスcssファイルのエンキューが壊れたため、CSSミニファイファイルオプションを無効にする必要がありました。 HTMLとJSのオプションは問題なく機能しました。

私はWPRocketサポートに問題が何であるかを尋ねました、そして彼らは私のサイトでこの問題をデバッグするのに十分素晴らしかったです。 この問題は、共有ホスティングで使用されているVarnishキャッシュが原因で発生しました。 彼らは私のホスティングサーバーのVarnish構成を変更することを提案しました。 ホスティングサポートに連絡しましたが、疑わしいと思いますが、共有ホスティングのVarnish構成を変更することはできませんが、VPSホスティングパッケージにアップグレードすれば変更できます。 ご覧のとおり、共有ホスティングを使用することはお勧めできません

CSSまたはJSの縮小に問題があった場合は、問題の原因となったファイルURLを除外されたJSまたはCSSファイルのボックスに追加できます。 問題の原因となっているファイルを見つけるのは難しいかもしれませんが、通常、どの機能が壊れていて、どのプラグインがその機能の原因であるかがわかっているので、ページのソースコードを確認し、そのプラグインによって含まれているファイルを調べます。 プラグインに複数のJSまたはCSSファイルがある場合は、それらを除外リストに追加して、問題が解決するかどうかを確認できます。

JSファイルとCSSファイルを組み合わせる

GTmetrixツールの[YSlow]タブは、「HTTPリクエストを少なくする」ように指示しています。 WordPressは9つの外部JSスクリプトを使用しており、それらを1つに結合する必要があり、ページは4つの外部CSSファイルを使用しており、それらも1つのファイルに結合する必要があると書かれています。 覚えているかと思いますが、この記事の「不要なJSまたはCSSファイルの削除」セクションで不要なJSおよびCSSファイルをすでに削除しています。

すべてのJSファイルとCSSファイルを1つのファイルにまとめることはお勧めできません。これは、ブラウザーが6つの小さなファイルを1〜2の大きなファイルよりも高速に並行してダウンロードできるためです。 もう1つの理由は、一部のファイルがHTMLドキュメントの先頭に含まれ、その他のファイルがドキュメントの末尾に含まれているため、少なくとも2つのファイルに分割する必要があるためです。

ファイルをWPRocketと結合するには、プラグイン設定の[静的ファイル]タブに移動し、[ファイルの結合]の下のオプションを有効にします。 いつものように、シークレット/プライベートブラウザタブでサイトを確認して、問題がないか確認します。

この例では、前述の共有ホスティングVarnish構成の問題が原因で、WP Rocketで再び問題が発生したため、JS結合ファイルオプションを無効にする必要がありました。

繰り返しになりますが、CSSまたはJSの連結で問題が発生した場合は、上記の縮小手順と同様に、問題の原因となったファイルURLを除外されたJSまたはCSSファイルのボックスに追加できます。

静的リソースからクエリ文字列を削除する

一部のプロキシサーバーはクエリ文字列を使用してリソースをキャッシュしないため、GTMetrixでは静的リソースからクエリ文字列を削除することをお勧めします。

静的リソース（通常はJSまたはCSSファイル）のクエリ文字列はURL属性であり、そのファイルのバージョンをマークします。 次のようになります： ？ver = 2.5.8そしてURLの最後に追加されます： http ：//domain.com/css/front-flex.css？ver = 2.5.8

これらのクエリ文字列は、WPRocketを使用して簡単に削除できます。 プラグイン設定の[静的ファイル]タブに移動し、[クエリ文字列の削除]オプションを有効にします。

このオプションを有効にした後、GTmetrix PageSpeedスコアは98に変更されましたが、ページの読み込み時間は変更されませんでした。

レンダリングをブロックするCSS / JS

残っている唯一のGooglePageSpeed Insightsツールの提案は、「フォールド上のコンテンツでレンダリングをブロックするJavaScriptとCSSを排除する」です。 これは、上記の折り畳みコンテンツのページの読み込みをブロックするJSまたはCSSファイルがいくつかあることを意味します。 ツールが私たちに望んでいることは、これらのブロッキングリソースを延期または非同期的にロードすることです。

もう一度、WPRocketプラグインが助けになります。 [静的ファイル]タブに移動し、レンダリングをブロックするCSS / JSオプションを探します。 そこで、この問題を解決できるJSおよびCSSオプションを有効にできます。 JSオプションを有効にすると、セーフモード（推奨）オプションが表示されます。 このセーフモードでは、ページの先頭にjQueryライブラリ（WPのデフォルトのエンキューライブラリ）が読み込まれ、ブロックファイルとして残りますが、ページにインラインjQueryコードがあるページは破損しません。 jQueryはまだヘッドにロードされているため、PageSpeedツールはレンダリングをブロックするJSファイルがあることを訴えています。

したがって、テストサイトのセーフモードを無効にすると、Google PageSpeedツールは、モバイルで100、デスクトップで100という完璧なスコアを提供します。 素晴らしいですよね？ あまり！ 私たちのウェブサイトはまだ正常に機能していますが、ウェブサイトがどのように読み込まれるかを見てみましょう。

スタイルなしコンテンツのフラッシュ（FOUC）は、WPロケット設定のクリティカルパスCSSオプション（レンダリングをブロックするCSS / JSオプションのすぐ下）を利用することで修正できます。 理論は、ページの折り畳み上の部分に必要なCSSコードを追加して、スタイルが設定されていないテキストのこのフラッシュ効果がページの読み込み時に表示されないようにすることができるというものです。 これは思ったより難しいです。 この重要なCSSを生成することになっているツールがありますが、私はそれらであまり成功しませんでした。

クリティカルパスCSSコードを生成するには：

1. サイトでWPRocketプラグインを無効にします。
2. クリティカルパスCSSジェネレータツールに移動します。
3. サイトのURLを入力して実行します。
4. クリティカルパスCSSコードをコピーします。
5. WPRocketプラグインをアクティブにします。
6. CSSコードをWPロケット設定の「クリティカルパスCSS」ボックスに貼り付けます。
7. 重要なCSSコードに相対URLパスがあるかどうかを確認し、それらを絶対パスに変更します。

WordPressテストサイトの読み込みは次のようになります。

それは良いですが、私はまだそれが好きではありません。 ええ、100/100のGoogle PageSpeedスコアは素晴らしいですが、このレンダリングブロックCSS / JSオプションを有効にしたため、合計読み込み時間が遅くなり、さらに2つのリクエストがあります。 私にとっての主な問題は、依然としてページの読み込みのユーザーエクスペリエンスであるため、このWPロケットオプションを無効にしました。

WP Rocketは、サイトを高速化するためのすべての機能を備えているため、WordPressWebサイトの各所有者が使用する必要のあるプラグインです。 プラグインをアクティブ化するだけで、大きな後押しが得られます。 各テーマとプラグインは独自の問題をミックスにもたらす可能性があるため、他の機能はすべてのWebサイトでテストする必要があります。

最適化の手順はもうすぐ終わりです。 残っているのは、WebサイトのアセットにCDNを使用することだけです。

コンテンツ配信ネットワーク（CDN）

この記事ですでに数回言及しましたが、ページの読み込み時間はサーバーの場所と訪問者の場所によって異なります。 たとえば、テストに使用している共有ホスティングサーバーは、テキサス州オースティン（米国）にあり、この記事のPingdomページ速度ツールセクションの冒頭で4か所をテストしました。 結果は次のとおりです。

• テキサス州ダラス（米国）= 1.65s
• カリフォルニア州サンノゼ（米国）= 2.53s
• スウェーデン、ストックホルム（EU）= 3.06s
• メルボルン（オーストラリア）= 5.38s

この記事に記載されているすべての手順でサイトを最適化したので、読み込み時間は次のようになります。

• テキサス州ダラス（米国）= 0.63s
• カリフォルニア州サンノゼ（米国）= 0.76s
• スウェーデン、ストックホルム（EU）= 1.21s
• メルボルン（オーストラリア）= 2.24秒

CDNを使用するようにサイトを設定するときに、これらの時間を使用してWordPressの読み込み時間を比較します。

これらの時間は非常に異なっていることがわかります。 これは、データがダラスの訪問者よりも、サーバーの場所からオーストラリアの訪問者までの距離が長くなる必要があるためです。 これは、CDNがこれらの読み込み時間を短縮するのに役立つ場所です。

CDNは、サーバープロキシとそのデータセンターの地理的に分散したネットワークです。 彼らの主な目標は、訪問者に最も近いサーバーから訪問者にサイトコンテンツを配布することです。 これは、ウェブサイトの静的コンテンツ（画像、JS、CSSなど）が世界中に分散しているサーバーによって提供されることを意味し、サイトの読み込みが速くなります。

WordPress CDNの利用には、次のような多くの利点があります。

• 待ち時間の短縮。これは、距離が移動しなければならない時間や遅延です。
• 最初のバイトまでの時間を短縮します（TTFB）。これは、サーバーからデータの最初のバイトを受信する前にブラウザーが待機する必要がある時間の測定値です。
• キャッシュからコンテンツを提供して、ページの読み込み時間を短縮し、ホスティング（オリジン）サーバーへの負担を軽減します。
• 多重化、並列処理、サーバープッシュ、およびHPACK圧縮を利用するために、安全な接続を介してHTTP / 2を利用します。
• GZIPまたはBrotliを使用してデータを圧縮し、HTML、スタイルシート、およびJavaScriptファイルを小さくします。

最近のCDNは、特にセキュリティ部門で他の多くの機能を提供しています。 これらは通常、DDoS保護、ボットの検出/防止などを提供します。

Cloudflareと呼ばれる最も人気のあるCDNの1つを見ていきます。 彼らは無料のパッケージを提供しており、これにはグローバルCDNの使用が含まれており、それが私たちに必要なものです。

Cloudflare

まずcloudflare.comにアクセスして、新しい無料アカウントにサインアップします。 アカウントを作成したら、静的コンテンツ（アセット）を提供するために、CloudflareにWebサイトを設定する必要があります。

新しいCloudflareアカウントにログインすると、DNSレコードを自動的に取得するために、Webサイト（ドメイン）を追加するように求められます。

ドメインを入力し、「スキャンの開始」をクリックします。 サブドメイン（ speed.gregorcapuder.com ）を使用していますが、ルートドメイン（ gregorcapuder.com ）のみを入力する必要がありました。 スキャン部分は完了するのに約1分かかりました。その間に、何が起こっているのかを説明する短いビデオを見ることができます。 スキャンが完了したら、「続行」ボタンをクリックできます。

次のステップでは、Cloudflareがドメインに対して見つけることができたすべてのDNSレコードを確認します。 ここで、欠落している可能性のあるレコードを追加する必要があるため、リストを調べて、欠落しているものがないかどうかを確認します。 この例では、速度サブドメインが欠落しているため、リストに追加しました。 名前の入力に「speed」（サブドメインの名前）を入力し、 IPv4アドレスにメインドメイン（gregorcapuder.com）と同じIPアドレスを入力して、「AddRecord」をクリックしました。 下のスクリーンショットでわかるように、メインドメインとスピードサブドメイン（クラウドの後ろに矢印が付いたオレンジ色のクラウドでマークされています）に対してCloudflareを有効にしました。 これは、これら2つのWebサイトでは、トラフィックがCloudflareによって処理および保護されることを意味します。

DNSレコードが完成したら、次のステップに進むことができます。ここで、「無料のWebサイト」プランを選択して続行します。

ウェブサイトでCloudflareを有効にする最後のステップは、ドメインレジストラのダッシュボード（ドメインを購入した場所）にログインし、ドメインのネームサーバーを変更することです。 新しいネームサーバーが有効になるまでに最大48時間かかると言われていますが、私の場合は1時間で更新されました。 当面の間、ウェブサイトのダウンタイムは発生しませんので、ご安心ください。

サイトのネームサーバーが更新されると、CloudflareWebサイトのステータスが「アクティブ」に変わります。

ダッシュボードのすべてのCloudflare設定をデフォルトのままにしましたが、変更したのはセキュリティレベルだけでした。 [ファイアウォール]タブに移動し、[セキュリティレベル]を[低]に調整します。 これは、攻撃者が誤って検出されたときに、訪問者に「チャレンジページ」を表示させたくないためです。

これで、Cloudflare側をセットアップしたので、WPRocketプラグインでCloudflare設定も有効にする必要があります。

WordPress管理ダッシュボードにログインし、WPRocketプラグイン設定に移動します。 「CDN」タブに移動し、「 Cloudflare設定の表示」タブを有効にして設定を保存します。 これにより、WPロケット設定に新しい「Cloudflare」タブが表示されます。これを開く必要があります。 そこで、Cloudflareアカウントのメールアドレスとドメインを入力し、CloudflareグローバルAPIキーをコピーして貼り付ける必要があります。 グローバルAPIキーを取得するには、Cloudflareダッシュボード（[概要]タブ）に移動し、[APIキーを取得]リンクをクリックします。 この新しいページに「APIキー」セクションが表示されます。「グローバルAPIキー」行の「APIキーの表示」ボタンをクリックする必要があります。 グローバルAPIキーをWPRocket設定に貼り付けたら、WPRocketで[最適設定]オプションを有効にすることもお勧めします。 設定を保存し、[Cloudflareキャッシュをクリア]ボタンをクリックして、すべてが正常に機能していることを確認します。

これでCDNが構成されたので、さまざまな場所からの読み込み時間を再度テストして、改善点を確認できます（Pingdomテスト）。

• テキサス州ダラス（米国）= 0.54s
• カリフォルニア州サンノゼ（米国）= 0.70s
• スウェーデン、ストックホルム（EU）= 0.91s
• メルボルン（オーストラリア）= 1.16s

予想通り、ヨーロッパとオーストラリアの読み込み時間は最も改善されました。 そして、すべての読み込み時間は約1秒以下です。 それは素晴らしい読み込み時間です！

サイトをテストするときは、1つの場所でページ速度ツールを1回実行するだけでテストしないでください。 あなたはそれを数回テストする必要があります。 特定の場所でツールを最初に実行するときは、キャッシュされたファイルを最初に最も近いCloudflareサーバーに保存する必要があります。その後の各テストでは、キャッシュされたバージョンの実際の読み込み時間が表示されます。 特定の場所からページが読み込まれる速度の平均を取得するために、3〜5回テストすることをお勧めします。

最終結果

最終的なページ速度ツールのスコアは次のとおりです。

• GooglePageSpeedインサイト
  • モバイル：91
  • デスクトップ：97

• GTmetrix
  • PageSpeed：98
  • YSlow：91

スクリーンショットは次のとおりです。

最適化の前後のGTmetrixデータを比較してみましょう。

あらゆる点でWebisteのパフォーマンスを向上させました。 Webサイトの読み込みが速く、ユーザーにサイトを表示するためのリクエストが少なくて済み、帯域幅が少なくて済み、世界中の訪問者の読み込みが速くなります。 同時に、ウェブサイトのすべての機能とスタイルを当初と同じように維持しました。 素晴らしい！

最後に、完了した個々の最適化ステップごとに、結果の見栄えの良い視覚的表現を用意しました。

結論

この究極のWordPressページ速度最適化ガイドでは、Webサイトのパフォーマンスを大幅に向上させるために実行できるより重要な手順について説明しました。 この記事のアドバイスに従うと、サイトが無駄なく高速になり、ページの読み込み時間が改善され、ユーザーエクスペリエンスが向上します。 これらの改善により、より多くのお金がもたらされ、サーバーコストを節約できる可能性があるため、誰にとってもメリットがあります。

スピードがすべてではなく、ウェブサイトのパズルのもう1つのピースであると言って、この記事を締めくくりたいと思います。 私たちは人間、潜在的なクライアントのためのウェブサイトを構築しているので、常にそれを念頭に置いてください。 コンテンツ、マルチメディア、デザイン、ユーザーエクスペリエンス、ページ速度のバランスをとってください。 ページ速度とページ速度ツールのスコアに夢中にならないでください。 訪問者のエクスペリエンスを向上させる限り、目標は達成されます。

ページの読み込み時間を大幅に改善できると思われるウェブサイトの最適化手順を見逃しましたか？ 以下のコメントで教えてください！

私たちの記事が役に立ち、その手順を実行した場合は、以下のコメントで、どのような改善を達成したかをお知らせください。