Kinstaでは、これまで長年にわたり、WordPressの最適化および高速化に関する記事を多数公開してきました。しかし、必要な情報を探す際、その情報量の多さに圧倒されてしまうことがあるかもしれません。そこで、WordPressサイトの高速化を網羅した情報、15年以上の経験と失敗を経て学んだすべての教訓をこの1つのページでまとめてご紹介します。WordPressを使い始めた方にとっても、経験豊富な開発者の方にとっても、きっと有益になるはずです。
現在、43.5%のウェブサイトがWordPressで運営されています。これは素晴らしい事実ですが、同時に、何千種類ものテーマ、プラグイン、技術が共存していることを意味します。WordPressを日常的に使っていると、サイトで何かしらの問題が発生した際、原因がわからない上、どこからトラブルシューティングを始めていいのかもわからず、途方に暮れてしまうこともあるでしょう。
過去に公開した『初心者のためのウェブサイト読み込み速度最適化ガイド』では、パフォーマンスに関する基礎知識、そしてパフォーマンスがどれだけビジネスの成功に影響するかについてご説明しました。今回は、WordPressサイトの速度を改善するために今すぐできること、そして価値の高いリソースも共有していきます。
Kinstaでは、無料の電子書籍『WordPressサイトを高速化する方法』を公開しています。実用的な10のヒントをわかりやすくご紹介ていますので、ぜひダウンロードしてみてください。
静的サイトと動的サイト
WordPressサイトの高速化についてご説明する前に、すべてのWordPressサイトが同じというわけではないということを覚えておいてください。つまり、すべての問題に同じ解決策を講じることはできないということで、多くの人が頭を抱えるのはこのためです。まずは、WordPressサイトを静的か動的かに分けて、それぞれの違いを見ていきましょう。
静的サイト
静的サイトとは、ブログ、小規模なビジネスサイト、情報量の少ないニュースサイト、個人サイト、写真家のポートフォリオサイトなど。サイトのコンテンツがあまり頻繁に変更されない（1日に2、3回程度）というのが「静的」の定義です。Kinstaのウェブサイトの大部分も静的と言えます。
静的サイトの場合、多くのリクエストがサーバー上のキャッシュから超高速で配信されます（キャッシュについては後ほど詳しく触れていきます）。つまり、データベースの呼び出し回数が減り、パフォーマンスの向上に必要なリソースもそれほど消費せずに済みます。
動的サイト
一方、ECサイト（WooCommerceまたはEasy Digital Downloads）、コミュニティサイト、会員制サイト、フォーラムサイト（bbPressまたはBuddyPress）、学習管理システム（LMS）などが動的サイトに当たります。「動的」とは、WordPressサイトのコンテンツが頻繁に変化（数分または1秒ごとのトランザクション）していることを意味します。動的サイトは、サーバーへのすべてのリクエストをキャッシュから配信することができないため、追加のリソースとデータベースクエリが必要になります。
また、動的サイトでは、同時セッション数（訪問者数）が多くなるのが一般的です。情報提供サイトや企業のサイトなど、静的なコンテンツの多いサイトでは、訪問者が必要なものを見つけるまで5～10分ほど（実際の直帰率はもっと高くなります）滞在することが予想されるのに対し、動的なサイトでは、この逆のことが起こります。動的サイトの場合、通常、訪問者は誰か（または何か）と交流するためにサイトを訪れます。例えば、オンラインコースを受講している場合、サイトに何時間も滞在することは珍しくありません。
この後の展開はご想像通りで、同時アクセス数はあっという間に増加します。このように、キャッシュできないコンテンツの問題に加えて、動的サイトは大量の同時訪問者数を抱える傾向にあります。
高性能WordPressホスティング
サーバーは、サイトのすべてのデータを保管してくれる場所。レンタルサーバーを選んで、ホスティングプランを契約すると、すべての画像、コンテンツ、動画ビデオなどが、サーバー会社が持つデータセンターのサーバーに保存されます。そして、サーバー会社が提供するサービスを介して、データへのアクセス、管理、サイト訪問者への配信が簡単に行えるという構図になります。一見すると、非常にシンプルです。
WordPressサーバーには、大きく分けて3つのタイプがあります。それぞれのメリットとデメリットを見ていきましょう。重要なのは、最初から優れたサーバーを選ぶということです。そうでなければ、度々問題に遭遇したり、無駄な時間を過ごしたりする羽目になります。
1. 共用WordPressサーバー
まずは、最も人気のある共用サーバー。業界最大手のBluehostやHostGatorなどのEIG企業（Endurance International Group）だけでなく、Siteground、GoDaddy、Media Temple、OVH、GreenGeeks、InMotion Hostingなどがこれに当たります。コントロールパネルにはcPanelを使用し、利用料は月額3ドル〜25ドルというのが一般的です。
共用サーバーを利用する場合、遅かれ早かれサイト速度の低下を経験することになります。これは、共用サーバーは負荷がかかりやすく、同じサーバーを共有するサイトのパフォーマンスに順番に影響を与えるためです。サイトを正常に動作させるべく、すべてに制限をかけてリソースが統合されるため、サイトの停止や500番台のエラーが頻発し、サイトがダウンすることもあります。実は200人以上のユーザーと同じサーバーを共有している可能性が高く、他のサイトで発生した問題が自分のサイトに飛び火することも。
どう計算しても、経費を差し引けば、月額3ドルの利用料だけではレンタルサーバーにとって何の利益にもなりません。サポートの提供を考えればなおさらで、顧客対応を一度行なった時点で、すでに赤字になってしまいます。サーバーが収益を得る秘密は、アップセルと隠された料金にあります。アップセルは、サイト移行、ドメイン登録、SSL証明書などのサービスが対象です。また、契約時に大幅な割引を提供して、次回の更新時に本来の高額な請求をするというのもよくある手法です。
共用サーバーが、無制限のリソースを謳ったプランを販売しているのを見たことがある人も多いのではないでしょうか。しかし、リソースを無制限に使用できるということは現実的に不可能です。このからくりは、まずリソースを大量に消費している顧客に制限をかけてプランの解約を促し、その顧客が使用していたリソースをその他の顧客に振り分けるというもの。安価なプランでユーザーの気を引いて多くの契約を獲得し、リソースをあまり消費せず、より高価なプランやサービスを購入してくれる顧客を残すために、顧客を篩に掛けるような構造になっています。
共用サーバーのカスタマーサポートは、抱えているサイト数の多さが原因で、質の高いサービスは期待できません。サーバーは、収益を上げるために最低限の経費で運用しなければならず、その結果、顧客に満足いくサービスを提供できないというのが現状です。
格安WordPressサーバーのからくりはこちらでご紹介しています。
2. 仮想専用WordPressサーバー（自分で構築）
2つ目は、VPS（仮想専用サーバー）を利用してサーバー自分で構築するというもの。これは、ブートストラップ型のベンチャー企業や、開発やサーバー管理、WordPressについて知識がある人向けの選択肢です。これに該当する人は、費用削減を常に念頭に置いている傾向にありますが、同時に、ビジネス成功の鍵となるパフォーマンスの重要性も理解しています。セットアップとしては、Digital Ocean、Linode、VultrなどのサードパーティのVPSや、管理を簡易化してくれるServerPilotのようなツールが一般的です。
DigitalOceanの小規模VPSは月額5ドルから、ServerPilotの人気プランは月額10ドルから利用できます。つまり、セットアップ次第では、月額5ドル〜15ドル以上の費用がかかる可能性があります。自分で構築する方法は、費用を節約できる反面、何かが破損した時の対処やパフォーマンスの最適化は、当然自己責任で行うことを意味します。
自分でサーバーを構築するのは素晴らしい選択肢ですが、十分に検討してください。専門知識を持っていない場合、またはただ興味本位で試してみたい場合には、お勧めできません。時は金なり。時間は効率よく使って、ビジネスの成長に専念しましょう。
3. WordPress専用マネージドホスティング
3つ目は、Kinstaが提供しているWordPress専用マネージドホスティング。このタイプは、バックエンドのサーバーに関するすべての作業をサーバー側で処理してくれる上、必要があればいつでもサポートも受けられます。通常は、WordPressに特化して調整されており、ワンクリックで実行できるステージング環境の作成や、自動バックアップなどの機能があります。カスタマーサポート担当者は、WordPressという1つのプラットフォームが専門分野であることから、CMS周りの知識が豊富です。
時間を効率的に活用するのであれば、WordPress専用マネージドホスティングが答えです👍
WordPress専用マネージドホスティングのプランは、サイトの規模や必要な機能に応じて、月額25ドル〜150ドル、もしくは150ドル以上と幅があります。jQuery、Intuit、Plesk、Dyn、Nginx、The White Houseなどの大企業は、WordPressですべてのサイトを運営しています。Kinsta以外にも、人気のあるWordPressホスティングとしては、WP Engine、Flywheel、Pressable、Media Temple、Pressidium、Pagelyなどが挙げられます。
Kinstaは一味違う
KinstaのWordPressホスティングは、一般的なホスティングサービスとは一味違います。従来のホスティングの枠を超え、プラットフォーム全体をGoogle Cloud Platform上に構築。一般的な共用サーバー、VPS、専用インフラとは大きく異なる、超高速WordPressホスティングです。
Google Cloud Platform上のすべてのWordPressサイトは、必要なすべてのソフトウェアリソース（Linux、Nginx、PHP、MySQL）を含む独立したソフトウェアコンテナ内で実行されます。つまり、すべてのサイトが完全に隔離され、自分のサイト同士でさえ共有されることはありません。
各サイトのコンテナは、複数あるGCデータセンターの1つに設置された仮想マシン上で実行され、Google Cloud Platformのプレミアムティアネットワークを利用して、最適化された低レイテンシのデータ転送を実現。各マシンには、最大96CPUと数百GBのRAMが搭載されています。ハードウェアリソース（RAM/CPU）は、Kinstaの仮想マシンによって必要に応じて自動的に各コンテナに割り当てられます。
Google Cloud Platformの汎用仮想マシンを使用している他のサーバーとは異なり、Kinstaでは、サポート対象地域のすべてのお客様にコンピューティング最適化（C2）およびCompute Engine 汎用マシン（C3D）VM仮想マシンを提供しています。Google CloudのC2マシンは、GCPで最も優れたコアあたりのパフォーマンス（3.8GHz）を誇り、最新世代のIntel Xeon CPUを搭載。C3Dマシンシリーズは第4世代のAMD EPYC™プロセッサーを搭載しています。いずれの仮想マシンも科学的モデリングや機械学習など、CPUを多用する状況で使用されますが、高性能なWordPressホスティングにも理想的です。自社で行ったテストでは、WordPressサイトを汎用マシンからC2マシンに移行すると、パフォーマンスが2倍向上し、C2マシンからC3Dマシンに移行すると、さらに応答時間が20%〜50%改善されました。
Review Signalは、毎年WordPressサーバーのパフォーマンスベンチマークを発表していますが、Kinstaは、すべての部門で5年連続、さらにStarterからEnterpriseまで、すべてのホスティングプランで最高スコアを記録しています。
KinstaのLoadStormとBlitzのテスト結果は実質完璧でした。他のテストでも欠陥は見つからず、そのパフォーマンスの高さは言葉を失うほどです。
また、Kinstaでは、階層型のカスタマーサポートは採用しておらず、チーム全体が、高度な専門知識を持つWordPress開発者とLinuxエンジニアで構成されています。またその多くが、サーバー管理、テーマやプラグインの作成、WordPressコアに携わった経験を持ちます。Kinstaを利用すると、WordPressに精通したプロから専門的なサポートを受けることができます。
チャットでご対応するのは、フォーチュン500企業もサポートする担当者。私たちはカスタマーサポートの質に徹底的にこだわり、応募者の1％以下しか採用していません。これ以上ない、最高のサポートを保証します。
移行後にさっそくユーザーサポートのお世話になる機会があったのですが、対応されたエンジニアの技術水準は十分に信頼の置けるものであり、またとても誠実な対応でスムーズに問題解決に至りました。私自身ユーザーサポートを提供する立場でもあるので、このあたりの仕事の質の高さというのはよくわかります。
WordPress専用マネージドホスティングにKinstaを選ぶメリットについては、Kinstaが選ばれる理由をご覧ください。最終的にどのサーバーを選択するかにかかわらず、サイトを可能な限り高速化するには、以下の条件が欠かせません。
PHP 8以上のバージョンをサポート
PHPは、主にウェブ開発で使用されるオープンソースのサーバーサイドスクリプトおよびプログラミング言語。WordPressコアの大部分は、プラグインやテーマと共にPHPで記述されており、WordPressコミュニティにとって非常に重要な言語です。検討しているサーバーが、少なくともPHP 8以上をサポートしているかどうか必ず確認しましょう。
ホスティングサービスでは通常、複数のPHPバージョンがサポートされていますが、最新のPHP 8.3が最もパフォーマンスに優れています。スピードとセキュリティの最大化を考慮し、Kinstaでは常に最新バージョンのPHPを推奨、サポートしています。
PHPバージョンの変更は、MyKinstaでワンクリックで完結します。なお、PHPの代替としてHHVMを提供しているWordPressホスティングにはご注意ください。今日、HHVMはWordPressホスティングに適したソリューションではありません。
Nginxを使用するホスティングサービスを選ぶ
WordPressサーバーは、WordPressサイトを駆動するためにウェブサーバーを使用しています。最も一般的なのは、NginxとApacheです。
Nginxは、スケールアップによるパフォーマンス最適化ルーツ。そのため、Nginxを採用しているサーバーを選ぶことを強くお勧めします。特に静的コンテンツや同時接続数の多い状況において、Nginxはベンチマークテストで他の主要ウェブサーバーよりも優れていることが多いため、KinstaではNginxを使用しています。
Nginxを採用している有名企業には、Autodesk、Atlassian、Intuit、T-Mobile、GitLab、DuckDuckGo、Microsoft、IBM、Google、Adobe、Salesforce、VMWare、Xerox、LinkedIn、Cisco、Meta（Facebook）、Target、Citrix Systems、Twitter、Apple、Intelなどがあります（出典元）。
W3Techsによると、Nginxは全ウェブサイトの34.2%を支えており、最も使用されているウェブサーバーです。Netflix、NASA、WordPress.comのような、大量のリソースを必要とする大手サイトでも使用されています。
NginxとApacheの比較はこちらをご覧ください。
サーバーのネットワークの重要性
あまり知られていませんが、WordPressサーバー選びの決め手となる要素として、そのサーバーが使用しているネットワークを確認することも大切です。ネットワークは、サイトのパフォーマンスやWordPress管理画面の動作に大きな影響を与えることがあります。多くのサーバーでは、この点が考慮されず、経費削減のために最も安価なネットワークを選びがちです。
サーバーを選ぶ際は、以下2つの要素に注目してください。
- どのようなネットワークでデータを送信しているか。データの大半が公共のISPネットワークを経由しているのか、もしくはGoogleやMicrosoftのようなプライベートネットワークを経由しているのか。後者のような大手企業は、低レイテンシと高速化のために構築・最適化されたネットワークを持っています（なんと海底ケーブルまで持っています）。
- ネットワークは冗長化されているか。もし、何かの誤りでケーブルが切断されてしまったら、どのようなことになるかは想像がつくはず。冗長化されていなければ、これは意外にも頻繁に発生してしまう問題です。
2017年にGoogleが発表したスタンダードティアネットワークは、最速ではないものの、比較的安価に利用できます。Kinstaでは、すべてのホスティングプランにプレミアムティアネットワークを使用しています。より高価なネットワークですが、お客様のサイトを超高速で配信することを重視しています。
Googleによれば、プレミアムティアネットワークは、公衆インターネットでの移動時間を短縮することでネットワーク性能の向上を実現しています。パケットは、ユーザーの最寄りでGoogleのネットワークに入って、Googleのバックボーンを移動してからVM（仮想マシン）に到達します。スタンダードティアの場合、送信トラフィックは、Googleのネットワークではなく、公共交通機関（ISP）のネットワークを介して配信されます。
分かりやすく言うと、以下のようになります。
- プレミアムティアは、ほとんどの経路がGoogleのプライベートネットワークを経由し、バウンドが少なくなることによって、パフォーマンスが向上します（したがって高価に）。
- スタンダードティアは、主に公共のネットワークを経由するため、パフォーマンスが低下します（その代わりに安価に）。
これには、実際どの程度の違いがあるのでしょうか。違う大陸に配信するデータの場合、プレミアムティアネットワークは、スタンダードティアよりも約41%高速になります。また、同じ大陸で近隣の地域に配信するデータの場合は、プレミアムティアの方が約8%高速に。ネットワークが読み込み時間全体に占める割合はわずかですが、何事も小さな積み重ねが大きな結果を生み出すものです。
また、冗長性も重要であり、Googleは自社のネットワーク上の2つの拠点間で少なくとも3つの独立した経路（N+2）を使用し、障害の発生しても拠点間のトラフィックが継続して流れる仕組みになっています。
このように、ネットワークの裏側では様々なことが行われています。利用を検討しているサーバーが信頼できるネットワークを使用しているか、経費削減を優先していないかどうか、事前に確認しておきましょう。
HTTP/2のサポートは必須
HTTP/2は、2015年にリリースされたプロトコルであり、サイトの配信を高速化するために設計されました。ブラウザ対応の関係で、HTTPS（SSL）が必要になります。HTTP/2をサポートしていないサーバーは利用しないようにしましょう。ウェブ全体がHTTPSに移行したことで、今日HTTP/2は必要不可欠です。
HTTP/2の優れた多重化と並列化、ハフマン符号を用いたHPACK圧縮、ALPN拡張、サーバープッシュなど、さまざまな機能によってパフォーマンスが向上します。HTTPS上で実行する際、以前は相当なTLSのオーバーヘッドがありましたが、HTTP/2とTLS 1.3のおかげで現在はかなり軽減されています。Kinstaは、すべてのサーバーとCDNでHTTP/2とTLS 1.3をサポートしています。
HTTP/2のもう1つの大きなメリットは、ほとんどのWordPressサイトで、コンカチネーション（文字列やデータ領域を1つに連結する処理）やドメインシャーディング（同時接続数の上限を最大化する手法）などの処理を行わなくていい点です。この最適化はもはや時代遅れです。
訪問者に近いサーバーを選ぶ
WordPressサイトを運営する際に、まずやるべきことの1つは、大多数の訪問者や顧客がどこからアクセスしているのかを把握すること。これが重要になる理由は、サイトを運営する場所が、全体的なネットワーク遅延とTTFBを決定する上で重要な要因になるためです。また、SFTPの速度やWordPressの管理画面の応答性にも関係してきます。
レイテンシ─ネットワーク上のデータ転送にかかる時間や遅延を意味します。言い換えれば、データのパケットがある地点から別の地点に配信されるのにかかる時間です。現在はミリ秒単位で測定されるのが一般的ですが、ネットワークによっては秒単位になることもあります。レイテンシは、数字がゼロに近いほど良いということになります。
レイテンシについての詳しい情報はこちらをご覧ください。
TTFB─Time to first byteの略で、最初の1バイトを受信するまでの時間を意味します。データを受け取るのに時間がかかればかかるほど、ページの表示速度が下がります。そのため、TTFBもレイテンシ同様、ゼロに近いほど良いということになります。
TTFBについての詳しい情報はこちらをご覧ください。
今回は、技術的な説明は省略します。大切なのは、レイテンシとTTFBを最小限に抑えること。これを実現する最も簡単な方法の1つは、訪問者に最も近いサーバーを選ぶことです。ここから、サイトを運営するサーバーの選び方についてのヒントをご紹介します。
ヒント1. Google アナリティクスで訪問者の位置情報を確認する
今すぐに行える簡単なことは、Google アナリティクスで訪問者の位置情報を調べることです。Google アナリティクスから「レポート」＞「ユーザー属性」「ユーザー管理の詳細」で確認することができます。
以下のスクリーンショットの例では、ほとんどのトラフィックが米国から来ていることがわかります。したがって、サイトはアメリカのサーバー選ぶのが最適です。また、データをさらに都市まで絞り込むことも可能で、地元の企業にとっては有用です。しかし、基本的には、米国の場合でいうところのアイオワ州のような、国の中心的な場所のサーバーを選択するのが得策です。
ヒント2. ECデータを確認する
ECストアを運営している場合、買い物客がどこからアクセスしているのかを必ず確認してください。訪問者＝商品を購入してくれるユーザーであり、収益に直結する存在であるため、買い物客の位置情報は当然重要です。基本的には、上記で見たGoogle アナリティクスの分布と一致するはずですが、そうとも限りません。Google アナリティクスでECデータや目標を設定している場合は、そのデータを位置情報と照らし合わせて、詳しい分析を簡単に行うことができます。または、ECプラットフォームのデータベースに保存されている位置情報を確認するのでもOKです。
ヒント3. レイテンシテストを実行する
クラウドサービスごとに、現在地からのレイテンシを測定する便利な無料ツールが多数あります。このツールを使えば、どの地域のサーバーが最適なのかを素早く判断することができます。
- GCP Ping（Kinstaサーバーを含むGoogle Cloud Platformリージョンへのレイテンシを測定）
- CloudPing.info（AWSリージョンへのレイテンシを測定）
- Azure Latency Test（Azureリージョンへのレイテンシを測定）
以下の例では、米国オレゴン州（us-west1）が最速であることがわかります。とは言え、全米に顧客を持つ場合は、西海岸と東海岸両方のユーザーの低レイテンシを保証するため、アイオワ州（us-central1）を選択するのが賢明でしょう。
Kinstaでは、世界各所にある37箇所のデータセンターを利用することができるため、簡単に低レイテンシと短いTTFBの両方を実現することができます。また、ホップ数を減らすのにも役立ちます。
レイテンシとTTFBを改善するその他の方法
訪問者に近いサーバーを選択する以外にも、レイテンシを改善する方法がいくつかあります。
- WordPressサイトのキャッシュを有効化。Kinstaで行ったテストでは、キャッシュを使用するとTTFBが90%も短縮されました。
- コンテンツデリバリネットワーク（CDN）を利用して、世界中のPOPでキャッシュされたアセットを配信。ウェブサーバーの近くにいない訪問者により速くコンテンツを配信するのに役立ちます。
- HTTP/2プロトコルを活用して、並列化によりラウンドトリップタイム（RTT）を最小化。HTTP/2はすべてのKinstaサーバーでサポートされています。
- 外部HTTPリクエストの数を減らす。サーバーの位置によってレイテンシが発生する可能性があります。
- DNSはTTFBに影響を与えるため、DNSルックアップが素早く実行されるサービスを利用。
- プリフェッチとプリレンダリングを使って、ページが読み込まれている裏でタスクを実行。
一挙にご紹介しましたが、ご安心を。後ほど改めてご紹介していきます。
SFTPの速度とWordPress管理画面
サイト運営において、訪問者と顧客の存在は最優先事項になります。しかし、ほとんど語られていないパフォーマンスのもう1つの側面は、サーバーの位置は日々の運営業務にも大きく影響するということです。選択したデータセンターの位置は、SFTPのダウンロードとアップロードの速度（FTPクライアントによるファイル転送）とWordPress管理画面の応答性に影響を与えます。
訪問者にとって最適なサーバーを選ぶということは、サイトの管理にも影響を与える可能性があることも念頭に置いてください。例えば、WordPressのメディアライブラリにファイルをアップロードする作業は、サイトが自分に近いデータセンターで運営されている方が速くなります。
Kinstaのお客様からは、Kinstaを利用してから管理画面の動作が大幅に速くなったという声をよく聞いています。この理由はさまざまですが、37箇所のデータセンターを利用できるのは大きな要素です。したがって、訪問者と自分の両方に適したデータセンターを選んでください。訪問者への配慮を重視するあまり、今後自分もサイト運営に何千時間も費やすことになるという事実を見落としがちです。
無料DNSではなくプレミアムDNSを使用する
DNSとは、ドメインネームシステムの略で、ウェブ上で最も一般的でありながら、誤解の多いコンポーネントの1つです。簡単に言うと、DNSは、ドメインとウェブサーバーを接続することで、インターネット上のトラフィックを誘導する役割を担っています。「kinsta.com」のような人が認識しやすいリクエストを受け取り、「216.58.217.206」のようなコンピュータが認識しやすいサーバーIPアドレスに変換する仕組みです。
DNSには、無料のものと有料（プレミアム）のものがあります。Kinstaのお客様は、Amazon Route 53を経由でプレミアムDNSを利用できます。概して、プレミアムDNSは今の時代に不可欠です。
プレミアムDNSを使用すべき大きな理由の1つは、速度と信頼性。DNSレコードの検索やトラフィックの誘導は、たとえミリ秒単位であっても時間がかかるものです。
一般的に、ドメインレジストラが提供する無料DNSは低速ですが、プレミアムDNSでは、より優れたパフォーマンスを期待できます。私たちが行ったテストでは、無料で利用できるNameCheap DNSは、Amazon Route 53のプレミアムDNSよりも33％遅いことがわかりました。さらに、特にDDoS攻撃を受けている際には、優れたセキュリティと可用性が保証されます。
SolvePerfのようなツールを使用すると、DNSルックアップにかかる時間を測定することができます。また、DNSPerfも全主要DNSサービスの細かなパフォーマンスデータを公開しています。
ドメインレジストラが提供する無料DNSとプレミアムDNSの中間的な存在として、Cloudflare DNSは、無料のサービスでありながらプレミアムDNSの機能を多数搭載しています。さらに、世界中で平均応答時間が20ms以下と、非常に高速なのも魅力です（以下参照）。
Kinstaのプランには、Cloudflare統合機能が付帯しています。主に米国の訪問者を持つ場合、DNS Made Easyも優れた選択肢になります。同社は、過去10年間で最高のDNS稼働率を誇り、評価を受けています。
過去30日間で、DNSPerfは、過去30日間で以下のサービスの稼働率を次のように示しています。
- DNS Made Easy: 99.99%（停止時間は月間4分23.0秒）
- Amazon Route 53: 99.88% （停止時間は月間52分35.7秒）
- Cloudflare: 99.85%（停止時間は月間1時間5分44.6秒）
DNSサーバーのダウンは重要な問題になるのかという疑問に対する答えは、YESでもNOでもあります。というのも、DNSは通常、DNSレコードの生存時間（TTL）を超えるまでは、ISPでキャッシュされるため、サーバーが10分間ダウンしても、基本的に気づくことはありません。ただし、定期的かつ長時間ダウンしている場合、もしくはISPとDNSレコードのTTL値どちらも低い場合は問題です。
WordPressテーマの重要性
新たな機能が搭載された最新のWordPressテーマは、誰もが気になるものです。しかし、その誘惑に負けず、一度立ち止まって検討することをお忘れなく。まずは、無料・有料テーマの違いをご説明しているこちらの記事をご覧ください。パフォーマンスについては、テーマのあらゆる要素がサイト全体の速度に何かしらの影響を与えます。そして、何千もあるテーマの中には、当然質の悪いものも存在しています。
では、どのようなテーマを選べば良いのでしょうか。以下2つの選択肢があります。
- 必要最低限の機能だけが搭載された高速で軽量なテーマを使用する
- 機能豊富なテーマを使用して、不要な機能を無効にする
無効にできる機能は多数あり、例としては、Google Fonts、Font Awesomeアイコン、スライダー、ギャラリー、動画、パララックスなどが挙げられます。使わない機能は、すべて無効にしましょう。とは言え、機能を1つずつ無効化していくのは手間のかかる作業です。また、各機能を無効にする方法を取り上げればキリがありません。そのため、結論として、デフォルトで軽量化されているテーマか、軽量化する機能があるテーマを使用するのがベストです。
以下、優秀なおすすめWordPressテーマをいくつか見ていきましょう。
以下にご紹介するテーマはすべて、WooCommerce、Easy Digital Downloads、WPML、BuddyPress、bbPressと互換性があります。
1. GeneratePress
GeneratePressは、高速かつ軽量（1MB未満zip圧縮）で、速度、SEO、ユーザビリティに配慮して作られたモバイル対応のWordPressテーマです。カナダの開発者であるTom Usborne氏によって構築されました。定期的に更新が行われ、サポートも充実しており、Kinstaチームからも数名このテーマを使用しています。
無料版と有料版があり、WordPressの公式リポジトリでは、無料版は20万以上のインストール、200万以上のダウンロード、850人以上のユーザーから5つ星評価を得ています。
GeneratePressの優れた点は、すべての機能をWordPressデフォルトのカスタマイザーで操作できることです。公開ボタンをクリックする前に、すべての変更を確認することができ、新しいコントロールパネルの操作方法を習得しなくていいのも利点です。
では、速度はどうでしょう。GeneratePressをクリーンインストールし、Pingdomで5回の速度テストを実行して、平均値を出しました。読み込み時間は、305ms、ページサイズはわずか16.8KBでした。このように、テーマがどの程度のパフォーマンスを発揮できるのかを把握するために、ベースラインテストは実行する価値があります。
その後、GeneratePressのサイトライブラリから、構築済みテーマの1つを使って、別のテストを行いました。このテーマには、画像、背景、新たに追加されたセクションなどが含まれています。GeneratePressのメリットは、ページビルダープラグインが不要な構築済みテーマを多数揃えている点。以下の通り、読み込み時間が400ms以下であることがわかります。
実際の本番環境では、Google アナリティクス、Facebookピクセル、Hotjarなどの他のツールも動作しているかもしれませんが、1秒以下に留めることは簡単です。woorkupのGeneratePressの詳しいレビューもぜひご覧ください。
WordPressを最適化・高速化する方法は、後ほどさらにご紹介していきます。
2. OceanWP
OceanWPは、軽量で高い拡張性を持つテーマです。ブログ、ポートフォリオ、企業サイト、WooCommerceストアなど、あらゆるタイプのサイトを、美しくかつプロフェッショナルに見せることができます。開発者はNicolas Lecocq氏。更新頻度もサポートの質も高くお勧めです。
GeneratePressと同様、無料版と有料版があります。WordPressの公式リポジトリでは、無料版は現在、40万以上のインストールを誇り、2,600人以上のユーザーが5つ星評価を残しています。
速度も気になるところ。先ほどと同様、OceanWPをクリーンインストールし、Pingdomで5回の速度テストを実行した上で、平均値をとります。読み込み時間は389ms、ページサイズはわずか230.8KBでした。スクリプトは若干大きめですが、特に問題はないでしょう。
続いて、OceanWPのサイトライブラリから見本テーマの1つを使って別のテストを実行します。このテーマには、画像、背景、新たに追加されたセクションが含まれ、Elementorのページビルダープラグインが必要になります。結果は以下の通り、600ms未満です。
OceanWPの詳しいレビューはこちらをご覧ください。
3. Astra
Astraは、ブログ、個人ポートフォリオ、企業サイト、およびWooCommerceストア向けの高速で美しいテーマで、高度な編集も可能です。非常に軽量（フロントエンドで50KB未満）であり、比類のない速度も魅力です。Brainstorm Forceによって開発され、更新頻度やサポートも申し分ありません。同社が開発した、何年も人気のあるAll In One Schema Rich Snippetsプラグインは、ご存知の方も多いはず。
GeneratePressやOceanWPと同じように、無料版と有料版があります。WordPressの公式リポジトリでは、無料版は現在40万以上のインストール、160万以上のダウンロード、そして2,500人以上から5つ星評価を得ています。
Astraの速度はどうでしょうか。同様にクリーンインストールを行い、Pingdomで5回の速度テストを実行し、平均値を出します。読み込み時間は243ms、ページサイズはわずか26.6KBでした。
次に、Astra Starter kitのサイトライブラリにある見本テーマの1つを使って、別のテストを実行します。このテーマには、画像、背景、新たに追加されたセクションが含まれ、Elementorのページビルダープラグインが必要になります。結果は、700msを下回りました。注意）この見本テーマに含まれる画像は完全に圧縮されてはいるものの、超高解像度のものが使用されています。
テーマ同士の比較を精密に行うことはほぼ不可能であり、ご紹介したテーマの速度の違いは、あまり真に受けないでください。ここでお伝えしたかったのは、この3つのWordPressテーマはどれも、インストール直後であっても、ある程度の編集後であっても、非常に高速であるということです🚀
ページビルダーに関する注意事項
上で触れた通り、OceanWPとAstraは、サイトライブラリのテーマを使用するためにページビルダーが必要になりました。ページビルダープラグインを使用する場合に注意すべき点をいくつかご紹介しておきます。
- 使用するページビルダーによっては、サイトの表示速度が低下することも。これは、コードなしで動作させるために、追加のCSSとJSも読み込む必要があるためです。ページビルダーのインストール前後でそれぞれサイトの速度テストを実行することをお勧めします。
- ページビルダープラグインの選択は慎重に。一度選ぶと、それに従ってサイトをデザインしていくことになるため、更新頻度の高いもの、必要な機能が揃っているものを使用してください。
とは言え、ElementorやBeaver Builderなどのページビルダーは人気があります。基本的には、パフォーマンスを考慮して設計されているため、オーバーヘッドが少し余計にかかる程度で済むのが通例です。ページビルダープラグインは、思い描くものを何でも実現することができるため、機能性とユーザビリティを考慮すれば、導入する価値があると言えます。場合によっては、5つ以上のプラグインをインストールしないと実現できなかったことが、1つのページビルダーで行える可能性があることもあり、高速化につながることも。
ただし、ページビルダーのプラグインが不要である場合は、インストールしないのが得策です。Gutenbergエディターがサイトデザインにどのような影響を与えるのかは、今後数年間注目していきたいところです。
WordPressプラグイン
さて、続いてはプラグインについて見ていきましょう。あまり多くのプラグインをインストールすると、サイトの動作が遅くなるというのは聞いたことがあるのではないでしょうか。確かにその通りなのですが、結論から言うと、使用するプラグインの数は、プラグインの質ほど重要ではありません。
テーマと同じように、プラグインがどのように開発されているか、そしてパフォーマンスを考慮して構築されているかどうかが鍵になります。Kinstaのお客様の中には、30～40のプラグインをインストールしているサイトと運営している方が数多くいますが、どのサイトも依然として1秒未満で読み込みができています。
サイトにカスタムコードを追加するのは楽しいことなのですが、以下のような理由から、必ずしも推奨されることではありません。
- コードは自分で保守管理が必要であり、標準の変化に合わせて更新しなければなりません。これは手間のかかる作業であり、ウェブに詳しい開発者の力を借りるのが賢明。
- ほとんどの場合、品質の高いコードで構築されたプラグインにこれ以上のオーバーヘッド要因は不要。
- WordPressコミュニティの大多数は、開発者レベルの専門知識を持っていないことをお忘れなく。プラグインは、問題を解決してくれるツールです。
ただし、質の悪いプラグインの使用は避けてください。これまで、深刻な問題が生じた事例に度々遭遇しており、Kinstaで使用を禁止しているプラグインも、実際にパフォーマンスの問題を引き起こした前例があるものばかりです。
とはいえ、サードパーティプラグインの豊富さは、WordPressの魅力のひとつ。WordPress.orgだけでも5万9,000以上の無料プラグインが掲載されており、それ以外でも数千以上のプラグインが存在しているため、本当に必要な機能を備えた優秀なプラグインを見つけるのは根気のいる作業です。
したがって、今回はKinstaが実際に使用しているプラグインをご紹介しています。Kinstaチームメンバーの多くは、WordPressプラグインの開発・販売を行っており、WordPressに精通しています。
WordPressプラグインの問題点
WordPressプラグインの大きな問題点は、アンインストール（削除）の作業です。WordPressプラグインやテーマをインストールすると、必ずデータベースにデータが保存されます。厄介なのは、一般的な方法でプラグインを削除すると、データベースにそのプラグインのテーブルと行が残ってしまう点。時間が経つにつれて、このデータが蓄積し、サイト速度を低下させる可能性があります。以下のスクリーンショットの例は、Wordfenceのセキュリティプラグインを削除した後の状態。データベースに24のテーブルが残っています。このテーブルが、wp_optionsテーブルのデータの奥にある場合は、さらに厄介です。
また、データベース以外にも、多くのプラグインが追加のフォルダやファイルを残しています。私たちの経験上、ログのために追加のディレクトリを作成するセキュリティやキャッシュのプラグインでよく見られます。Wordfenceプラグインの場合は、削除後、wp-contentディレクトリにwflogsフォルダが残りました。Wordfenceはほんの一例で、今日のプラグインやテーマの大半はこのような仕組みになっています。
プラグインがこのような仕組みで開発されている理由
では、プラグインをアンインストールして削除する際に、なぜこのような余計なデータも一緒に削除する機能が搭載されていないのでしょうか。これには、いくつか理由があります。
- ユーザーが必要になる設定をそのまま保持するため。プラグインを削除して、後でもう一度使用する場合を考慮して、すべての設定とデータがそのまま残るようになっています（非常に便利な設定ですが、最適な設定とは言えません）。
- パフォーマンスを考慮していない。開発者の中には、テーブルを残しておいてもパフォーマンスに影響は出ないと主張する人もいるでしょう。しかし、10年以上にわたって何百ものプラグインを使用して、何千もの行やテーブルを生成してきたサイトを想像してみてください。データベースへの問い合わせは、WordPressサイトのパフォーマンスに大きな影響を与えますが、開発者が気にかけていなければ、プラグインからこのようなリクエストを大量に送信してしまう恐れがあります。優れたプラグインであれば、関連付けられているテーブルや行にのみクエリを実行するのが一般的ですが、必ずしもそうとは限りません。wp_optionsテーブルの不要な自動ロードデータが残っているのが原因で、長いデータベースクエリがサイトをクロールさせるという事例は実際に起こっています。
- 単なる設計ミス。WordPress公式のプラグインハンドブックによると、経験の少ない開発者は無効化のフックを使用するミスを犯すことがあるようです。
幸い、プラグインを適切にクリーンアップして削除する方法があります。以下の解説記事をご覧ください。
WordPress設定の最適化
続いて、WordPressの設定について。このセクションでは、サイトを高速化するために行える変更をいくつかご紹介していきます。ほとんどがちょっとした変更ですが、どれも効果的です。
Added:
1. WordPressのログインURLを変更する
デフォルトのWordPressサイトのログインURLは、domain.com/wp-admin/。このURLの懸念点は、すべてのボット、ハッカー、スクリプトに知られていることです。このURLを変更することで、ハッキングの標的になりにくくなり、ブルートフォース攻撃から保護し、悪質なボットが消費する帯域幅を減らすことができます。
また、ログインURLの変更は、「429 Too Many Requests」のような一般的なエラーも防ぐことができます。万能な解決策というわけではありませんが、サイトを守り、ページの負荷を軽減するのに役立つちょっとした裏技です。
WordPressのログインURLを変更するには、以下のどちらかのプラグインを使用しましょう。
- WPS Hide Login（無料）
- Perfmatters（有料）─Kinstaメンバーが開発。パフォーマンスの最適化設定あり。
2. プラグインやテーマの更新を無効化または調整する
WordPress管理画面が重くなる原因は、ネットワークやデータセンターの場所、さらにはPHPのバージョンに関係している可能性があります。また、あまり知られていないもう1つの要因として、バックグラウンドで実行されるWordPressの更新をチェックする機能があります。多くのプラグインやテーマをインストールしている場合には、特に悪影響を与えてる可能性があります。
本質的な問題は、WordPressに内蔵されたこの機能が、裏で外部GETリクエストを実行することです（https://third-party-plugin/update-check.php）。これは、定期的に発生することもあれば、頻発することもあり、後者の場合は、これが原因で管理画面の動作が遅くなっている可能性があります。
これは、どちらかというと、この機能の構築方法に問題があり、管理画面の表示速度が遅いことにお悩みの方は、一度試す価値があるかもしれません。対処法は、プラグインやテーマの自動更新を無効化することです。注意）ほとんどの更新は、セキュリティやバグの改良が含まれているため、自分で定期的に更新を行える場合のみ実行してください。
自動更新の無効化は、以下のいずれかのプラグインを使用しましょう。
- Disable All WordPress Updates─設定不要で完全無料。
- Easy Updates Manager─コア版は無料。自動更新を選択して管理可能。
自分でカレンダーにリマインダーを設定するなどして、週に一度プラグインを無効化し、アップデートを確認して、再度有効化するという手順がお勧めです。
3. ピンバックを無効化する
ピンバックとは、他のブログでリンクされた際に自動的に作成されるコメントで、自分のブログの記事にリンクしたときに作成されるものはセルフピンバックと呼ばれます。
ピンバックは、不要なクエリやスパムを生成するため、無効にすることをお勧めします。特にアクセス数の多いサイトの場合、WordPressサイトの呼び出しは、少なければ少ないほど良いことを覚えておいてください。そして言うまでもなく、セルフピンバックは迷惑なだけ。以下の手順で、ピンバックを無効にしましょう。
手順1. 他のブログからのピンバックを無効にする
WordPress管理画面で、「設定」＞「ディスカッション」に進みます。「ディスカッション設定」で、「新しい投稿に対し他のブログからの通知（ピンバック・トラックバック）を受け付ける」のチェックを外してください。
手順2. セルフピンバックを無効にする
セルフピンバックを無効にするには、いくつかの方法があります。無料のNo Self Pingsプラグインを使用するか、Perfmattersのような有料プラグインでも実行できます。
また、WordPressテーマのfunctions.phpファイルに以下のコードを貼り付けて、無効にすることも可能です。注意）テーマのソースコードを編集する場合、正しく行われないとサイトが壊れる可能性があります。無料のCode Snippetsプラグインを使用すれば、テーマに触ることなく、このようなPHPスニペットを簡単に追加できます。
function wpsites_disable_self_pingbacks( &$links ) {
foreach ( $links as $l => $link )
if ( 0 === strpos( $link, get_option( 'home' ) ) )
unset($links[$l]);
}
add_action( 'pre_ping', 'wpsites_disable_self_pingbacks' );4. ブログフィードへの投稿を制限する
ブログフィードをトップページに設定している場合でも、他のページにある場合でも、多数並んだサムネイルがすべて同時に読み込まれる必要はありません。トラフィックの多いブログを運営している場合、トップページは、サイトの中で最も重要なページであるため、高速化しておきたいもの。リクエストやメディアの数が少なければ少ないほど、パフォーマンスが向上します。
これこそが、ページネーションが生まれた理由です（以下図参照）。ページネーションとは、ブログのフィードの最後に表示されるもので、他のページに移動しやすくするために設置されます。文言は、数字や「次へ/前へ」のような表示が一般的です。ほとんどのWordPressのテーマには、専用のページネーションが組み込まれています。
デフォルトの上限は10件に設定されていますが、このデフォルト設定は度々変更されています。現在どのように設定されているか、必ず確認するようにしてください。基本的には、8〜12件程度が理想的です。Kinstaブログでは、12件表示されるようになっています。
この設定は、管理画面から「設定」＞「表示設定」で行えます。「1ページに表示する最大投稿数」を好きな値に変更してください。
キャッシュの重要性
キャッシュはWordPressを高速化する上で重要な概念（かつ簡単な手段）です。キャッシュを賢く利用することが肝となります。キャッシュの活用方法をご紹介する前に、まずキャッシュの仕組みと、その種類を押さえておきましょう。
キャッシュとは
簡単に言うと、WordPressで閲覧するすべてのウェブページが、サーバーへのリクエスト、サーバーによる処理（データベースへの問い合わせを含む）、そしてサーバーからユーザーのブラウザへの最終結果の送信を必要とします。その結果がウェブサイトであり、それを閲覧するのに必要な全てのファイルや要素を組み合わせることで表示されます。
例えば、ヘッダー、画像、メニュー、ブログなどがあります。サーバーはそのすべての要求を処理しなければならず、ユーザーに完全なウェブページを表示するまでにある程度の時間がかかります。
そこで、WordPressのキャッシュプラグインの出番です。キャッシュは、設定に応じて、ディスクまたはRAMにファイルを保存するようサーバーに指示します。これにより、過去に配信したコンテンツを記憶、複製することができます。基本的には、ページ生成に必要な作業が減り、その結果、キャッシュから直接、ウェブページをより速く読み込むことができます。
キャッシュには、他にも以下のようなメリットがあります。
- サーバーの消費リソースを削減：消費リソースが減れば、サイトが高速化され、ひいてはサーバーへの負荷も軽減される。これは、会員制サイトなどの高度な動的サイトで、キャッシュから何を配信するかどうかを判断する際に重要。
- TTFBの改善：Kinstaが自社で行ったテストでは、キャッシュを使用することでTTFBが最大90%減少。
キャッシュの種類
キャッシュの種類については、一般的に2つの異なるアプローチがあります。
1. サーバレベルでのキャッシュ
サーバーレベルでのキャッシュは、手間がかからない選択肢で、WordPressホスティング会社に一任することを意味します。Kinstaでは、以下の4種類のキャッシュを用意しており、すべてがソフトウェアまたはサーバーレベルで自動的に実行されます。
そのため、複雑で分かりにくいキャッシュプラグインから解放され、「使いやすいキャッシュプラグイン」探しに奔走する時間を削減して、事業にせんねんすることができます。
ページキャッシュは、標準的なWordPressですぐに動作するように設定されています。何も設定する必要はありません。WordPressサイトを用意するだけで、ページキャッシュが機能します。
また、WooCommerceやEasy Digital Downloadsなどを使用したECサイト向けに、特別なキャッシュルールを設けています。デフォルトで、カート、マイアカウント、決済ページなど、特定のページはキャッシュから除外されています。woocommerce_items_in_cart、またはedd_items_in_cartCookieが検出されると、自動的にキャッシュをバイパスし、スムーズに決済処理が行われます。
WordPress管理画面のツールバーから、いつでも簡単にキャッシュをクリアすることができます。
MyKinstaでもキャッシュをクリアすることができ、「ツール」画面の「サイトキャッシュ」セクションにある「キャッシュをクリア」をクリックするだけでOKです。
2. プラグインでキャッシュを管理する
ホスティングサービスにキャッシュ機能が無い場合には、サードパーティのWordPressキャッシュプラグインを使用してみてください。おすすめは以下の通り。
- WP Rocket（有料）
- Cache Enabler（無料）
- W3 Total Cache（無料）
その他のおすすめWordPressキャッシュプラグインはこちらでご紹介しています。
また、KinstaはWP Rocketをサポートしています。通常、キャッシュプラグインはKinstaとの互換性の問題から、使用することができませんが、WP Rocket 3.0では、Kinstaサーバーと併用しようとすると、そのページキャッシュ機能が自動で無効になります。
そのため、Kinstaをご利用の場合は、サーバーレベルの高速キャッシュとあわせて、WP Rocketの最適化機能もご利用いただけます。
キャッシュなし vs キャッシュあり
キャッシュはどの程度役に立つのでしょうか？論より証拠です。
Kinstaのサーバーレベルキャッシュを利用してスピードテストを実行してみました。全体的なスピードとTTFBの両方から違いを確認可能です。
キャッシュなし
まず、キャッシュを有効にせずにPingdomで5つのテストを実行し、平均値をとりました。
キャッシュなしのTTFB
キャッシュなしとキャッシュありのTTFBの違いも重要です。PingdomのTTFBは、黄色の「待機中」バーで表されます。ご覧の通り、キャッシュなしのTTFBは192msです。x-kinsta-cache のヘッダが MISS と表示されていることから、キャッシュから提供されていないことがわかります。
キャッシュあり
続いて、サーバーレベルのキャッシュを有効にして、Pingdomで5回のテストを行い、平均をとりました。
サーバーレベルのキャッシュにより、ページ読み込みにかかる時間が33.77%も短縮されています。しかも、有効化以外の作業は一切行っていません。今回テストに使用したサイトはかなり最適化されています。つまり、大規模な、そして最適化が進んでいないサイトではさらに大きな違いが観察できるはずです。
キャッシュありのTTFB
キャッシュ有効時のTTFBを見てみると、35ミリ秒を下回っていることがわかります。x-kinsta-cacheのヘッダがHITしていることから、キャッシュからアセットが配信されていることがわかります。
CDNキャッシュもWordPressサーバーにおけるキャッシュと同様に重要です。CDNについては、以下でさらに掘り下げていきます。
会員制サイトでのキャッシュの扱い
会員制サイトには、通常キャッシュできないコンテンツや継続的に変更される要素が多く含まれています。コミュニティメンバーのログインページ（サイトの規模によっては常にヒットする可能性も）、デジタル製品やコースのチェックアウトページ、ディスカッションボードなどは、一般的にキャッシュできず、問題になります。
さらに、標準的なWordPressサイトでは、管理画面も「ログイン」しているユーザーにはキャッシュされません。著者や管理者が数名程度の小規模なサイトでは問題になりませんが、数千人のメンバーが管理画面にアクセスするような規模では、サーバー上のキャッシュから提供できるものがなくなり、すぐにパフォーマンスの問題が発生します。共用サーバーを利用している場合、このような状況下では機能しなくなるのが通例です。このような事態にも対応してくれる高性能なホスティングが必要になります。
高度に動的なサイトで活用したいオブジェクトキャッシュ
WordPressの会員制サイトでは、一般的なキャッシュの設定だけでは不十分。そこで活躍するのが、オブジェクトキャッシュです。
オブジェクトキャッシュは、データベースへのクエリの結果を保存し、次回そのデータが必要になった際に、データベースへのクエリなしでキャッシュから配信できるようにするものです。これによって、PHPの実行時間が短縮され、データベースへの負荷も軽減されます。この仕組みは、会員制サイトでは不可欠です。WordPressでは、以下の方法でオブジェクトキャッシュを実装することができます。
- W3 Total Cacheなどのサードパーティ製キャッシュプラグイン
- Redis（推奨）
- Memcached
KinstaではRedisをアドオンとして提供しています。会員制サイトでは、永続的なオブジェクトキャッシュをフル活用したいところです。
キャッシュの分析
先ほど、x-kinsta-cacheヘッダーについて触れました。ご利用のホスティングサービスや、キャッシュプラグインによっては、このヘッダー名が異なることがあります。WordPressサイトからリクエストが行われるたびに、このヘッダーにHIT、BYPASS、MISS、EXPIREDの値が表示され、キャッシュがどのように機能しているかを調べることができます。
できるだけ多くのコンテンツをキャッシュから配信するためには、WordPressサイトのキャッシュヒット率を上げることが重要です。Kinstaでは、MyKinstaの分析機能とキャッシュログを確認し、キャッシュをバイパスするGETリクエストや排除可能なPOSTリクエストがあるかどうかを調べることができます。
「キャッシュ推移」セクションでは、各リクエストのステータス（HIT、BYPASS、MISS、EXPIREDのいずれか）が表示され、過去24時間、7日間、30日間でフィルタリングすることも可能です。
「キャッシュ比率」セクションでは、その名の通り、キャッシュ比率を一目で確認できます。キャッシュから提供するリクエストが多ければ多いほど良いとは限りません。例えば、下のWordPressサイトのキャッシュヒット率は96.2%。これは理想的な数値です。
「リクエスト数上位のキャッシュバイパス一覧」セクションでは、どのリクエストがキャッシュから提供されていないかを確認できます。一般的には、cronジョブ、admin-ajaxリクエスト、ECサイトの決済ページ、クエリ文字列、UTMパラメータなどが含まれる可能性があります。
画像最適化は不可欠
画像最適化は、ページ全体の表示速度の高速化に非常に効果的です。これは任意ではなく、必ず実行するようにしてください。
大きな画像は、ユーザー体験とページの表示速度を低下させます。プラグインやスクリプトを使ってファイルサイズを縮小することで、ページの読み込み時間を短縮することができます。一般的には、非可逆圧縮と可逆圧縮の2つの方法が使用されます。
HTTP Archiveによると、画像はウェブページ全体の重量の平均34%を占めています。つまり、最適化がかなり難しい動画の次に、最適化したい要素であり、JavaScript、CSS、Fontsよりも重要です。画像の最適化は非常に簡単にもかかわらず、実は多くのサイトで実践されていません。
画像最適化はウェブ全体で進んではいますが、まだまだ無視できない数字です。サイトに動画コンテンツがない場合は、画像がページの表示速度に影響を与えている1番の原因と言っていいでしょう。
適切なバランス（ファイルサイズと画質）を見つける
画像最適化を行うにあたって、まずは最小のファイルサイズと許容できる品質のバランスを見つけましょう。他の作業にも言えることですが、基本的に最適化の方法は複数あります。一番手っ取り早いのは、WordPressサイトにアップロードする前に画像を圧縮すること。これはAdobe PhotoshopやAffinity Photoや、Google提供のSquooshアプリで実行できます。あるいは、プラグインで自動化することも可能です。
考慮すべき点は、ファイル形式と使用する圧縮方式の2つ。ファイル形式と圧縮方式を適切に組み合わせることで、画像サイズを5倍も縮小することができます。それぞれの画像やファイル形式を試してみて、良いバランスを見つけましょう。
画像に手を加える前に、適切なファイル形式を選択してください。以下のいずれかを使用します。
- PNG：より高画質で、ゆえにファイルサイズが大きくなる。非可逆圧縮も可能だが、基本的には可逆圧縮方式を使用。
- JPEG：非可逆圧縮と可逆圧縮方式を使用。画質とファイルサイズのバランスを取るために画質レベルの調整が可能。
一言で言えば、色の多い画像にはJPEG（またはJPG）、シンプルな画像にはPNGを使用するのがベストプラクティスです。
また、ウェブサイトでは、WEBP画像の使用も検討することをおすすめします。
では、GIFはどうでしょうか。アニメーションGIFは、ユーザーの気を引く楽しい要素ですが、ウェブパフォーマンスは低下します。GIFの多くは1MBを超えるため、SNSやSlackで使用するのが得策です。ブログ記事にどうしても使用したい場合には、アニメーションGIFを圧縮する方法を参考にしてください。
圧縮時の画質とファイルサイズ
画像を圧縮しすぎるとどのようなことが起こるか、例を見てみましょう。1つ目は、高画質を優先して圧縮率をかなり低く押えたもの（ファイルサイズは大きくなる）、2つ目は、圧縮率を大幅に上げて、低画質になったもの（ファイルサイズは小さくなる）です。なお、オリジナルの画像サイズは2.06MBです。
上の1枚目の画像サイズは590KB。これは1枚の写真としてはかなり大きいです。一般的には、ウェブページの総重量を1～2MB以下に抑えるのがベストプラクティスであり、この画像1枚でその4分の1を占めてしまうことになります。2枚目の画質はひどいものですが、68KBまでサイズを抑えることができています。この圧縮率（画質）とファイルサイズのちょうどいいバランスを見つけことが大切です。
圧縮率を中程度にした以下の画像は、ファイルサイズも151KBとまずまずで、高解像度の写真として許容範囲内でしょう。低圧縮の画像と比べると、サイズはほぼ4分の1。パフォーマンスを最適化するためには、ほぼすべての画像を100KB未満に抑えることが推奨されます。
非可逆圧縮と可逆圧縮
圧縮方式は、非可逆圧縮（ロッシー）と可逆圧縮（ロスレス）の2種類があります。
非可逆圧縮では、画像データの一部が削除されるため、劣化（画質の低下やピクセル化）が見られる可能性があります。したがって、画像は慎重に圧縮しなければなりません。画質はもちろん、一度圧縮を行うと元に戻すことはできません。非可逆圧縮の大きなメリット（そして人気の理由）は、ファイルサイズを大幅に縮小することができます。
可逆圧縮の場合は、非可逆圧縮とは異なり、画質が低下することはありません。しかし、通常不要なメタデータ（画像を撮影するデバイスで自動生成されるデータ）削除することでサイズが縮小されるため、ファイルサイズの大幅な縮小が見込めないことが欠点です。つまり、長い目で見ると、ディスク容量を圧迫してしまう可能性があります。
どちらの方式が適しているかは、実際に実験してみるのが一番ですが、ほとんどの場合は、画質をあまり落とさずに70％以上（場合によっては90％以上）圧縮できる、非可逆圧縮方式が推奨されます。ページ内15枚の画像を非可逆圧縮すれば、サイト速度が大幅に改善されることがわかるはずです。
画像圧縮プラグイン
WordPressの画像圧縮プラグインを使用すると、画像圧縮を自動化することができます。おすすめのプラグインは以下の通りです。いずれも可逆および非可逆圧縮対応で、画像を外部で最適化してくれます。
画像圧縮プラグインを選ぶ際に重要な点は、そのサーバー上（つまり外部）で画像が圧縮されるかどうかです。これによって、サイト上での負荷を軽減することができます。上記プラグインはどれも外部で処理が行われます。
ちなみに、KinstaではImagifyプラグインを使用しています。Imagifyでは、WordPressのメディアライブラリに画像をアップロードする際に、画像が自動的に圧縮されるため、一度設定さえ行えば、以後特別な操作は不要です。Normal、Aggressive、Ultraと圧縮率が選択でき、これはこのプラグインを使用していく中で、どの圧縮率が適しているか、感覚的に分かるようになります。
Kinstaでは「Aggressive」モードを採用しており、画像によっては通常60～70％サイズが縮小されます。※Kinstaで使用している画像のほとんどはアイコンやイラストで、JPEGよりもPNGを多用しています。
画像圧縮によって、WordPressサイトがどのくらい高速化されるかどうかは、元の画像のサイズと圧縮後の画像によりけり。Kinstaが自社で行ったスピードテストでは、徹底して画像圧縮を行うことで、ページの読み込み時間が80％以上短縮されることがわかりました。
遅延読み込み
サイトに多くの画像を掲載している場合は、遅延読み込みの導入をおすすめします。レイジーロードとも呼ばれ、視覚的なコンテンツを先に読み込み、スクロールしないと見えない部分のコンテンツのダウンロードとレンダリングを遅らせる最適化の手法です。
WordPressサイトで遅延読み込みを実装する方法はこちらをご覧ください。遅延読み込みは、特に記事の後半に投稿者のアイコン画像が表示されるコメントが多数付随する場合に特に効果的です。Googleも遅延読み込みに関する推奨事項を公表しています。
その他の画像最適化のヒント
最後に、画像最適化に関するその他のヒントもご紹介します。
- カラムやdivの幅に合わせたサイズの画像だけをアップロードするのはもう過去の話。WordPress 4.4以降では、レスポンシブ画像が標準サポートされており、モバイルユーザー向けには小さな画像が自動で表示されます。
- SVG（ベクターファイル形式）も素晴らしい代替手段になり得ます。Kinstaのサイトで使用しているオリジナルイラストはすべてSVGファイル。必ずではありませんが、SVGは一般的にファイルサイズがかなり小さくなります。WordPressサイトでSVGを使用する方法についてはこちらをご覧ください。
- 画像内にテキストを使用する代わりに、アイコンフォントを使用すると、画像を拡大縮小した際の見栄えがよくなり、使用するリソースも抑えることができます。フォントジェネレータを使えば、さらに最適化することも。フォントジェネレータで、アイコンフォントファイルのサイズが削減された例（驚きの97.59%）もご覧ください。
データベースを微調整する
次は、WordPressのデータベースを微調整する方法です。データベースは、徐々に肥大化してくもの。車のように定期的なメンテナンスが必要になります。
特に会員制のサイトでは複雑なクエリが発生し、MySQLデータベースからの情報取得にさらなる遅延が生じるため、大変な事態になる可能性があります。動的なコンテンツや大量のデータの利用が、さらなる複雑化を招くことも。また、ナビゲーションとして検索クエリに大きく依存しているサイトや、WP_Queryを使用しているサイトも要注意です。
そして、多くのユーザーが同時にかつ継続的にデータベースにクエリを送信するケースも同様です。
1. InnoDBストレージエンジンの使用
多くの古いサイトでは、未だデータベースにMyISAMストレージエンジンを使用していますが、InnoDBの方がパフォーマンスと信頼性の両面で優れています。
InnoDBには、MyISAMにはない以下のような機能があります。
- 行レベルのロック機能があり、クエリの処理が高速化される（MyISAMはテーブルレベルのロックのみ）
- 外部キー（RDBMS）と関係制約をサポートする参照整合性
- トランザクション対応によって、コミットやロールバックが可能
- トランザクションログを使用して自動リカバリを行うため、より信頼性が高い
InnoDBとMyISAMのどちらを使用しているかについては、最近立ち上げたWordPressサイトであれば、InnoDBストレージエンジンが採用されている可能性が高いです。古いWordPressサイトであれば、念のために確認しておきましょう。サイトによっては、MyISAMとInnoDBのテーブルが混在していることがあり、統一することで改善が見られるかもしれません。
以下の簡単な手順で確認してみてください。
手順1
phpMyAdminにログインし、MySQLデータベースをクリックします。
手順2
「Type」カラムの検索またはソートから、テーブルで使用されているストレージエンジンの種類を確認することができます。以下の例では、2つのテーブルでMyISAMが使用されていることがわかります。
MyISAMが見つかったら、InnoDBに切り替えることをおすすめします。利用しているホスティング会社に連絡を取り、サポートの範囲かどうかを確認してみてください。ちなみに、Kinstaに乗り換えると、データベーステーブルはすべてInnoDBに変換されます。
MyISAMテーブルを自分でInnoDBに変換することも可能です。詳しくは以下の記事をご覧ください。
2. 固定ページと投稿のリビジョンの削除と制限
WordPressで固定ページや投稿を保存すると、自動でリビジョンと呼ばれるものが作成されます。これは「下書きの保存」と「公開済みの投稿の更新」の両方で発生します。WordPressのリビジョンは、コンテンツを以前の状態に戻したい時に便利な機能です。
しかし、リビジョンはWordPressサイトのパフォーマンスに悪影響を与える可能性があります。大規模なサイトでは、データベース内に（必ずしも必要ではない）数千もの行が一瞬で追加されることも。行数が増えれば増えるほど、データベースのサイズも大きくなり、ストレージ容量を圧迫します。これに対処するためにインデックスが作成されますが、見過ごすことができない事例に度々遭遇してきました。以下、いくつか対処法をご紹介します。
古いリビジョンを削除する
多くの固定ページや投稿があるWordPressサイトをお持ちであれば、古いリビジョンを削除するのが効果的です。この作業はMySQLでも可能ですが、ウェブ上で悪質なコードが出回っていることを考えると、サイトのバックアップの作成とWP-Sweepなどの無料プラグインを使用するのが賢明です。
また、便利なプラグインWP Rocketにも、リビジョンを削除するデータベース最適化機能があります。
WP-CLIを使いこなすことができれば、コマンドという手もあります。
SSHでサーバーにログインし、以下のコマンドを実行すると、データベースにあるリビジョンの数を取得して見ることができます。
wp revisions list
エラーが出る場合は、まず以下のコマンドでwp-revisions-cliパッケージをインストールしてください。
wp package install trepmal/wp-revisions-cli
以下のコマンドを実行して、リビジョンをクリーンアップします。
wp revisions clean
リビジョンを制限する
Kinstaで実践しているのは、投稿や固定ページごとに保存できるリビジョン数を制限すること。10件にするだけでも、特に多くの更新を行う場合、リビジョンの肥大化を防ぐことができます。
リビジョンを制限するには、wp-config.phpファイルを開いて、次のコードを「ABSPATH」の上に貼り付けます。「10」の値は、データベースに保存したいリビジョンの数に変更してください。
define('WP_POST_REVISIONS', 10);
Perfmattersのようなプラグインでリビジョンを制限することも可能です。
リビジョンを無効化する
サイト上のリビジョンを完全に無効にしてしまう手も。この場合は、上記の手順に従ってリビジョンを削除した上で、この機能を無効化してください。こうすることで、データベースから古いリビジョンを完全に削除することができ、今後も追加されることがなくなります。
リビジョンを無効にするには、wp-config.phpファイルを開いて、以下のコードを「ABSPATH」の上に貼り付けてください。
define('WP_POST_REVISIONS', false);
または、Perfmattersでリビジョンを無効化することもできます。
3. wp_optionsテーブルと自動で読み込まれたデータのクリーンアップ
WordPressサイトとデータベースの全体的なパフォーマンスに関して、wp_optionsテーブルの存在は見落とされがち。特に古いサイトや大規模なサイトで、サードパーティのプラグインやテーマによって残されたデータ（自動で読み込まれたデータ）が原因で、サイトのクエリが低下するのは典型的なシナリオです。
wp_optionsテーブルには、WordPressサイトにまつわる以下のようなデータが格納されています。
- サイトURL、トップURL、管理者メールアドレス、デフォルトカテゴリ、1ページあたりの投稿数、タイムフォーマット
- プラグイン、テーマ、ウィジェットの設定
- 一時的にキャッシュされるデータ
このテーブルには、以下のフィールド（カラム）があります。
- option_id
- option_name
- option_value
- autoload（パフォーマンスの観点で注意が必要）
wp_optionsテーブルでも特に注目したいのが、autoload（自動読み込み）フィールド。値は「yes」か「no」のいずれかで、wp_load_alloptions()によって読み込まれるかどうかを決定します。「自動読み込みされる」データとは、WordPressサイトのすべてのページで読み込まれるデータを意味します。特定のスクリプトをサイト全体で読み込まないようにする方法は、先にご紹介しましたが、ここでも同じ考え方が適用されます。autoload属性は、開発者を考慮しデフォルトで「yes」に設定されていますが、すべてのプラグインがすべてのページでデータを読み込む必要性は、限りなくゼロに近いです。
wp_optionsテーブルに自動読み込みされるデータが大量にある状態は、WordPressサイトでよく見られる傾向にあり、以下のような原因が考えられます。
- 「no」に設定されるべきプラグインが自動で読み込まれている（例えばお問い合わせフォーム系プラグインは、通常お問い合わせページだけで機能すれば良い）。
- WordPressサイトから削除したプラグインやテーマのデータが
wp_optionsテーブルにそのまま残り、不要なデータがリクエストごとに参照されてしまっている。 - プラグインやテーマによっては、個別のテーブルを使用するのではなく、
wp_optionsテーブルでのデータ読み込みが設定されている。この手法には賛否両論あり、テーブル数を増やさない方法を好む開発者も。しかしながら、wp_optionsテーブルは何千もの行を保持する設計になっていないことも事実。
では、自動読み込みされるデータ量が「多すぎる」とは、どの程度を意味するのでしょうか。これは状況により異なりますが、基本的には300KB〜1MBに抑えるのが望ましいです。
データ量が3〜5MB近くある場合は、最適化やデータの削除をお勧めします。10MBを超える場合は、今すぐ対処が必要です。必ずしも問題が生じるわけではありませんが、無視できない状態です。
自動で読み込まれるデータのトラブルシューティングおよびクリーンアップ方法はこちらをご覧ください。
4. Transientの削除
オブジェクトキャッシュを使用していない限り、wp_optionsテーブルに一時的なキャッシュデータ（transient）が保存されます。通常、これには有効期限が設定されており、自動で削除されますが、必ずしもそうとは限りません。何千件ものtransientが長期的に保存されているデータベースは多数存在しており、Kinstaのあるお客様のサイトでは、wp_optionsテーブルに69万5,000行以上も生成された、破損したtransientが検出されました。
デフォルトで、transientは自動読み込みされることはありませんが、以下のクエリで、自動読み込みされているtransientがあるかどうかを確認することができます。
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'Transient CleanerやDelete Expired Transientsなどの無料プラグインを使用すると、wp_optionsテーブルから期限切れのtransientだけを削除することができます。ちなみに、WordPress 4.9以降には、期限切れのtransientを管理する機能が搭載されており、サイトでこの機能が実行されていれば問題ありません。
WP Rocketのデータベース最適化機能でもtransientを削除することができます。
5. WordPressセッションの削除
また別の問題として、cronジョブが同期されなかったり、正しく動作しなかったりして、セッションが削除されないことがあります。これにより、データベース内に大量の_wp_session_行が生成される可能性があります。以下のスクリーンショットでは、wp_optionsテーブルに300万を超える行が存在していることがわかります。テーブルのサイズは600MB以上。
このような問題が発生しているかどうかは、以下のクエリを使って確認できます。
SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'
通常、次のコマンドで対象のデータを安全に（cronジョブが実行すべき挙動として）削除することができます。
DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'残った_wp_session_のデータをすべて削除すると、テーブルの行数は1,000行未満になり、サイズは11MBに縮小されました。
また、以下に見られる通り、MySQLで見られていた問題も解決しました。
6. autoloadにインデックスを追加
wp_optionsテーブルの削除だけでは不十分な場合は、インデックスを追加してみる方法も。これによって、検索が効率化されます。10up社がautoloadのレコード数が標準的なwp_optionsテーブルでいくつかのテストを実施し、wp_optionsクエリにインデックスを追加することでどのようにパフォーマンスが向上するかを調査しています。
上のグラフからもわかる通り、インデックスを追加するとパフォーマンスが向上することが明らかになっています。
WP Bulletによる以下の記事も併せてご覧ください。
7. 永続オブジェクトキャッシュにRedisを使用
Redisは、オープンソースのインメモリデータストアです。WordPressサイトでは、WordPressのオブジェクトキャッシュによって生成された値の永続化などに使用され、キャッシュしたオブジェクトをページの読み込み間で再利用することができます。
Redisのような永続オブジェクトキャッシュを使用すると、キャッシュしたオブジェクトが再利用され、MySQLデータベースで同じオブジェクトに対するクエリを何度も実行する必要がなくなります。その結果、サイトのMySQLデータベースの負荷が軽減されるとともに、サイトの応答時間も短縮され、サイトの拡張性とトラフィックの処理能力を改善することができます。
ページキャッシュをうまく利用できない高度な動的サイト（WooCommerceストア、会員制サイト、フォーラム、ディスカッションボード、コメントの投稿が多いブログなど）では、特にこのオブジェクトキャッシュソリューションが効果を発揮します。
Kinstaでは、Redisアドオンを提供しています。ご利用のプランにRedisを追加する方法はこちらをご覧ください。
8. 検索機能にElasticsearchを利用する
Elasticsearchは、オープンソースの全文検索エンジン。データのインデックスを作成し、検索機能を劇的に高速化します。
WordPressサイトでは、WordPressデータベースクエリの高速化に活用可能です。Elasticsearchによって、サイトのデータベースコンテンツのインデックスが構築されます。このインデックスを利用することで、MySQLクエリよりもはるかに高速検索を実行することができます。
開発知識をお持ちの方は、ElasticsearchをWordPressサイトに統合することができます。また、WP_Queryを標準的に使用しているサイトであれば、WordPress.orgで入手可能な10upの無料プラグイン、ElasticPressを使って統合することも。WP_Queryオブジェクトと自動統合され、MySQLではなくElasticsearchでクエリ結果が生成されます。
WP_Queryを多用している以下のようなサイトでは、Elasticsearchの恩恵を受けることができます。
- 検索が主なナビゲーション手段になっているサイト
- サイト管理者が定期的に注文一覧を検索する必要のある、膨大な注文数を抱えるWooCommerceストア
- 投稿数が多く、MySQLクエリが許容できないほど低速なサイト
9. データベースを過剰に使用する不要な機能を無効にする
これは当たり前といえばそうですが、データベースを過剰に使用する不必要なプラグインやテーマの機能を無効にすることで、パフォーマンスが大きく改善されます。
- 人気記事、関連記事を表示するウィジェットやプラグインは、サイト全体に重いクエリを持つ傾向にあり厄介。
- サーバーを使用して画像を圧縮する画像最適化プラグインも要注意。画像を外部で最適化するものを選択することが重要。
例えば、Kinstaブログの記事を最後までスクロールすると、「おすすめの関連記事」セクションがあり、記事ごとに異なる関連記事が表示されます。クエリはほとんどゼロで、サイト全体のパフォーマンスに影響していません。手間はかかりますが、ユーザーに読んでもらいたい記事を自分で選択できるのは、メリットと捉えることができます。
気になる実装方法ですが、Advanced Custom Fieldsプラグインを使って、フィールドをブログの投稿タイプに割り当てています。これにより、関連するコンテンツを検索して一つ一つ割り当てることができます（下図参照）。
また、絶対に必要でない限り、サイトに閲覧数などのカウンターを表示するプラグインには手を出さないことをお勧めします。例えば、フォーラムの投稿でユーザーのアバターの横に「792件の投稿」と表示したり、フォーラムの投稿を一覧表示する際に「閲覧数5,243」などと表示するようなことは避けましょう。コンテンツの量によっては、データベースに大きな負担をかけることになります。カウンターの使用は最小限にとどめ、必要な場合にのみ利用するのが賢明です。
これは、多くのSNSのカウンター（ソーシャルカウンター）にも当てはまります。例えば、以下のサイトでは、人気のあるプラグインであるSocial Warfareからの応答時間が、その下のプラグインよりも30倍も多いことがわかります。キャッシュは有効になっていますが、このプラグインがパフォーマンスの面で明らかに「お荷物」になっています。プラグインを無効化したところ、読み込み時間が瞬時に削減され、WordPress管理画面の応答性も改善しています。
コンテンツデリバリネットワーク（CDN）を利用する
CDN（コンテンツデリバリネットワーク）は、世界中に配置されたサーバー（PoP）のネットワークです。画像、CSS、JavaScript、および動画配信などのWordPressサイトの静的な（そして時に動的な）コンテンツのコピーを保存し、そのデータを効率的に配信してくれます。
まず、CDNをWordPressのサーバーとは混同しないように注意です。この2つはまったく別物です。CDNはホスティングプロバイダーの代わりになるわけでなく、サイト速度を向上させるための追加の手段です。Kinstaのホスティングは非常に高速ですが、CDNを利用することで、さらに高速化することができます。
CDNの仕組み
CDNはどのように機能するのでしょうか。例えば、Kinstaでは、米国、ヨーロッパ、アジア太平洋、または南米などの物理的なデータセンターの中から、好きな場所を選択してサイトを運営します。
例えば、「US Central（アメリカ中部）」を選択すると、サイトデータはアメリカのアイオワ州カウンシルブラフスにある「ホストサーバー」に保存されます。したがって、日本からサイトにアクセスすると、テキサス州ダラスからアクセスした場合と比較して、表示速度が遅くなります。
これは、データがより遠くまで移動しなければならないためです。このようにネットワーク上でデータを転送する際に発生する時間や遅れは、レイテンシと呼ばれ、距離が広がるほどレイテンシは大きくなります。
CDNの種類
CDNには、以下2つの種類があります。
- 従来のプル型CDN
- リバースプロキシ型CDN
従来のプル型CDNは、すべてのコンテンツとメディアのコピーをキャッシュしますが、クライアントからのリクエストは、依然としてホスティングサービスが処理します。KeyCDNとCDN77は、プル型CDNです。
リバースプロキシ型CDNは少し異なり、CDNとして機能しながら、送信されるリクエストを受け取り、クライアントとホスト間で仲介サーバーとして機能します。CloudflareとSucuriは、リバースプロキシ型CDNの代表例です。このような特徴から、DNSはホスティングサーバーではなく、CDNサービスに紐付ける必要があります。
リバースプロキシ型CDNの強みは、中間サーバーとして機能する点にあります。高度なウェブアプリケーションファイアウォールを実装することができ、WordPressサイトやホスティングサービスに悪質なトラフィックが到達するのを阻止することができます。その一方で、従来のプル型CDNと比較すると、パフォーマンスの面でやや負荷が増えるデメリットも。しかし、パフォーマンスとセキュリティ機能を適切に使用することで、このデメリットは克服可能です。
以下は、KinstaのあるクライアントサイトでSucuriを有効化した後に起こった事例です。グラフから分かる通り、悪質なトラフィックの量に劇的な変化が見られます。このようなサービスを利用することで、最終的なホスティング費用の削減につながります。
CDNのスピードテスト
先に、WordPressのキャッシュの大きなメリットについてご説明しましたが、CDNキャッシュも非常に効果的です。CDNは通常、ホスティングサービスよりも多くの物理的サーバーを持っています。これによって、サイト訪問者の近くにすべてのアセット（画像、JS、CSS）をキャッシュし、高速配信することができます。
CDNによってサイトがどれだけ高速化されるか、簡単なテストを行ってみます。
CDNなし
今回のテストウェブサイトは、Kinstaの米国アイオワ州のデータセンターで運営するサイトを使用します。まずは、CDNなしでPingdomで5回のスピードテストを実行し、その平均値をとります。なお、CDNの能力を正確に測定するため、Pingdomのロンドンにあるサーバーでテストを実施します。平均読み込み時間は、1.03秒でした。
CDNあり
続いて、CDNを有効にして、Pingdomで5回のテストを行います。こちらもロンドンのサーバーで実行します。平均読み込み時間は585ミリ秒。CDNを使用することで、ページの表示速度を43.2%短縮することができました。これは大きな改善です。
これほど大きな差が見られた理由は、CDNがロンドンにデータセンターを持っているため。つまり、すべてのアセットがロンドンにキャッシュされ、最小限のレイテンシでコンテンツを配信できる状態ということです。
CDNなしのTTFB
Pingdomの黄色いバーは待ち時間、Time to First Byte（TTFB）を示しています。CDNを使用しない場合の結果は、アセットの平均TTFBは約98ミリ秒。
CDNありのTTFB
CDNを有効にすると、平均TTFBは平均15ミリ秒に改善されました。CDNのキャッシュから直接アセットが配信されることで、平均TTFBが84.69%低減されました。
CDNを有効化する方法
WordPressサイトでCDNを使用する方法は以下の通り。
ステップ1
CDNサービスを選択し、利用を開始します。月単位またはデータ使用量に応じて料金が発生します。通常、費用の見積もりに使える計算機能が用意されています。
- KeyCDNを自分で導入する場合はこちらを参照してください。その他のCDNサービスでも、導入方法が記載されたドキュメントを公開しています。
- Cloudflareのインストール方法はこちら、Sucuriのインストール方法はこちらをご覧ください。
ステップ2
従来のプル型CDNを使用している場合、CDN Enabler、WP Rocket、またはPerfmattersなどの無料のプラグインを利用し、WordPressサイトと統合することができ、アセットが自動でCDNにリンクされます。CDNへのコンテンツ登録作業は一切不要です。リバースプロキシ型CDNの場合は、通常プラグインは必要ありませんが、機能の追加にプラグインが必要になることがあります。
KinstaのCDNを使用する方法
先ほどのCDNのスピードテストでは、明らかな違いが見られました。このテストにはKeyCDNを使用しており、KinstaのCDNはKeyCDNによって提供されています。HTTP/2とIPv6対応で、世界200+箇所にサーバーが設置されており、世界各地にアセットを高速配信することができます。現在は、アメリカ、南アメリカ、ヨーロッパ、アフリカ、アジア、オーストラリアの地域でサービスを提供しています。
Kinstaのホスティングプランには、CDNが無料で付帯しており、簡単2ステップで有効化することができます。
ステップ1
MyKinstaにログイン後、サイトを選択して、左側メニューから「CDN」を選択します。
ステップ2
「CDNを利用する」をクリックすれば完了です。数分後にCDNが自動デプロイされ、アセットが世界中のキャッシュから配信されるようになります。
その他のCDN最適化のヒント
他にも、以下のような方法でCDNを最適化することができます。
- コメントの投稿が多いサイトでは、Gravatarsが
secure.gravatar.comから読み込まれる大量のリクエストを生成している可能性があります。私たちも実践している、CDNからGravatarsを読み込む方法はこちらをご覧ください。 - CDNでのカスタムフォントの提供、あるいはCDN上でGoogle Fontsを使用することができます。ローカルフォントついてはこちらをご覧ください。
- CDNからファビコンが読み込まれているかどうかを確認しましょう。たとえ小さくても、リクエストを最適化することができます。
メディアとメールの負荷を分散する
リクエストが発生するものはすべて、何らかの形でサイトのパフォーマンスに影響を及ぼします。何十万ものファイルや大きなメディアを扱うサイトでは、これを別の場所で管理することが賢明かもしれません。保管場所を変えることは、CDNを経由しての配信とは全く別の話です。CDNでは、元のデータは依然としてご利用中のホスト（Kinstaなどのホスティングサービス）に存在し、CDNにはそのコピーが保存されます。
CDNアセットのキャッシュ有効期限が切れると、CDNからファイルの最新版のコピーを求め、ホストに再びクエリが実行されます。CDNは、長期間にわたってファイルをキャッシュするためのものです。しかし、非常に多くのPoPがあるため、各地域でキャッシュの有効期限が切れると、多くの再取得が行われる可能性があります。
一方でメディアやファイルを別の場所に保存するという選択肢があります。実際には、ホスティングサービスの外に（つまり物理的に別の場所を選択し）データを移動することになります。したがって、ファイルはあなたのサイトから提供されているように見えても、実際にはまったく別の場所にあります。ホスティングサービスへのクエリを減らせるだけでなく、ディスク容量を節約することが第一の理由になります。
Amazon S3でメディアを管理する
人気のソリューションの1つが、Amazon S3です。Amazon S3はストレージソリューションであり、Amazon Web Servicesの多くの製品の一部です。一般的には、追加バックアップが必要なサイトや、大容量ファイル（ダウンロード、ソフトウェア、ビデオ、ゲーム、オーディオファイル、PDFなど）を提供する大規模なサイトに使用されます。Amazonは非常に信頼性の高い実績があり、その巨大なインフラストラクチャのため、低いストレージコストを実現しています。S3の顧客には、Netflix、Airbnb、SmugMug、Nasdaqなどが挙げられます。
価格設定は、WordPressホスティングのそれよりも安くなることはほぼ間違いありません。AWSでのメディア管理は費用削減に効果的で、さらに最初の1年間は無料です（5GBのストレージまで）。また、メディアへのリクエストはAmazonから直接提供されるため、WordPressサイトへの負荷が少なく、読み込み時間短縮が期待できます。
WordPressのメディアをAmazon S3に保存する方法もあわせてご覧ください。また、このようにして外部に保存したメディアの配信にCDNを使用すると、両方の強みをフル活用することができます。
Google Cloud Storageでメディアを管理する
Google Cloud Storageも人気のオフロードソリューションです。巨大なインフラを持つGoogleは、大量のストレージを扱っており、非常に安価に利用できます。Spotify、Vimeo、Coca-Cola、Philips、Evernote、Motorolaなどの大手企業も使用しています。
WordPressサイトのメディアをGoogle Cloud Storageに保存する方法はこちらをご覧ください。
トランザクション/マーケティングメールを別のサーバーから配信する
メールは、サーバーやサーバーリソースに影響を与えます。一部のホスティングサービス、特に共用サーバーでは、これによってアカウントを停止される可能性もあり、メールを大量に送信する場合は問題に。このような懸念を解消するために存在するのが、トランザクションメールサービスです。また、同じ理由で、多くのホスティング会社が標準ポートでのメール配信を許可していません。メールとホスティングは分けることが推奨されます。
ニュースレターや大量のメールを送信する場合は、以下のいずれかのアプローチをお勧めします。
- WordPressサイトとは別にサードパーティのメールマーケティングソフトウェアを使用する
- WordPressサイトにトランザクションメールプロバイダー（HTTP APIまたはSMTP）を併用する
また、サードパーティーのサービスを利用すると、以下のようなメリットがあります。
- メールに特化したサービスのため、より良い配信性を確保できる
- ブラックリストに登録される可能性が低減される
- ホスティング会社によっては、DMARCレコードを設定できないことがある
メールマーケティングツール
マーケティングメールの例としては、ニュースレター、製品・機能の最新情報、セール、イベントの案内、オンボーディングのリマインダーなどが挙げられます。以下のツールがおすすめです。
- MailChimp（KinstaはMailChimpを使用）
- MailerLite
- Drip
トランザクションメールサービス
トランザクションメールの例としては、WooCommerceやEDDでの領収書、アカウント作成や出荷の通知、アプリのエラーメッセージ、パスワードのリセットなど。Kinstaをご利用の場合、高い配信性を確保するため、サードパーティのSMTPプロバイダーを使用することになりますが、送信する量によっては、サードパーティのサービスを利用することをお勧めします。以下のサービスがおすすめです。
- SendGrid（KinstaはSendGridを使用）
- Mailgun（WordPressでMailgunを設定する方法はこちら）
- MessageBird
ボトルネックと遅いプラグインを特定する
このセクションでは、WordPressサイトのパフォーマンスのボトルネックを見つける方法と、対処法を見ていきます。
1. New Relicで遅いプラグインとデータベースクエリを特定する
時間のかかっているデータベースクエリや重いプラグインを特定するのに役立つツールは、いくつか存在しています。Kinstaでは、PHP監視ツールのNew Relicを日常的に使用しており、サイトの詳細なパフォーマンス統計を取得することができます。
Kinstaのお客様は、MyKinstaでNew Relicのライセンスキーを追加することもできます。
ただし、New Relicはサイトパフォーマンスに影響を与えるため、使用する際には注意が必要です（サイトにJavaScriptが追加される）。パフォーマンスのトラブルシューティング時のみ、有効化するようにしてください。
重いプラグインを特定する
WordPressプラグインがサイト速度を低下させている場合、その症状はプラグインが実行するアクティビティによって異なります。大抵は、WordPressサイトのすべてのページの表示速度に影響を与えます。あるサイトでは、重いプラグインが原因で、フロントエンドページで全体的な速度低下が見られました。New Relicで、以下のようにパフォーマンスを分析することができます。
adinjectorプラグインが圧倒的に重たいことが一目でわかります（2番目に遅いプラグインの15倍以上）。
このようなデータを目の当たりにすると、そのプラグインのコードの質が低い、効率的でない、などとすぐに判断したくなりますが、必ずしもそうとは限りません。プラグインの設定ミス、低速なデータベース、外部リソースの反応の遅さなどが原因になっている可能性があります。
反応が遅いプラグインを検出したら、New Relicの他の画面にも目を通して、より詳しい情報を集めましょう。トランザクション、データベース、外部リソースをすべて確認した上で、プラグインを削除することがベストな（または唯一の）方法であるかを判断してください。
データベースの過負荷による全体的な速度の低下
データベースが適切に最適化されていない場合、WordPressサイト全体の速度が低下することがあります。この問題の解決策は、いくつか上でご紹介しましたが、New Relicでは、以下2箇所にデータベースの速度に関する情報が表示されます。
- 「Overview」ページで、MySQLのアクティビティが大量に表示される
- 「Databases」ページで、時間を消費している1つまたは複数のデータベーステーブルが表示される
データベースに問題があるサイトの場合、「Overview」ページは以下のようになります。
どのデータベースのテーブルやクエリが問題を引き起こしているのかを調べるには、「Databases」ページに移動します。
このページでは、最も遅いテーブルとクエリの種類を確認することができます。一覧表示される項目を選択すると、クエリ例を含む詳細情報が表示されます。
この場合は、wp_optionsテーブルの自動読み込みされたデータを意味します。これについては先にご説明した通り。wp_optionsテーブルを簡単に分析すると、約250MBのデータが自動読み込みされていることがわかります。このサイトのデータベースは、明らかにメンテナンスと最適化が必要です。
New Relicでパフォーマンスの問題をデバッグする方法はこちらをご覧ください。
2. 無料のQuery Monitorプラグインを使用する
無料プラグインのQuery Monitorを使用する手もあります。遅いデータベースクエリ、AJAX呼び出し、REST APIリクエストなどを特定し、デバッグすることが可能です。さらに、スクリプトの依存関係や依存性、ページ生成中に発生したWordPressフック、ホスティング環境の詳細、現在のページが満たす条件付きクエリタグなど、詳細なサイト情報も取得できます。
Query Monitorの使用方法はこちらをご覧ください。
3. 本番環境に手を加えずにステージングサイトを利用する
ステージング環境は、サイト管理に必要不可欠な存在。特にパフォーマンスの問題をトラブルシューティングする際には非常に有用になります。Kinstaでは、ワンクリックでステージング環境を作成することができます。利用しているホスティング会社がステージング環境を提供していない場合は、WP Stagingのようなプラグインを使用して作成することができます。ただし、セットアップはやや複雑です。
ステージングサイトを立ち上げたら、まず最初にすべてのプラグインを無効にします。本番サイトに影響することはないため、破損などを心配する必要はなく、スムーズに問題を特定することができます。プラグインをすべて選択したら、「一括操作」のドロップダウンメニューから、「停止」を選択してください。
その後、New RelicやQuery Monitorなどのツールで、応答時間を監視し、変化が生じるかを確認します。この例では、サイトの応答時間がすぐに正常になったため、無効にしたいずれかのプラグインに原因があることがわかります。この後は、プラグインを1つずつ再度有効化しながら、その都度数値を確認し、問題のプラグインを特定します。
問題のあるプラグインを有効化すると、通常以下のように読み込み時間（トランザクション時間）が大幅に遅くなります。
原因とのあるプラグインを特定したら、以下のような対処を行なってください。
- そのプラグインやテーマが最新バージョンでない場合は更新する
- そのプラグインやテーマの開発者に連絡を取り、サポートを依頼する
- 同じ機能を持つ代替プラグインを探す
- PHPのバージョンが問題を引き起こしている可能性があるため、古いバージョンに変更して、プラグインやテーマが正常に動作するかを確認する
また、問題解決には、WordPress開発者の手を借りるのも良いアイデアです。例えば、WP BulletのMike Andreason氏は信頼のおけるプロフェッショナルです。パフォーマンスの最適化を専門とするCodeableの開発者であるAndreason氏は、複雑なインストールが必要なKinstaのクライアントサイトの数々を支援してくれています。
4. エラーログを確認する
エラーログの確認は面倒ですが、プラグインのパフォーマンスの問題に関する数々の情報を入手することができます。Kinstaでは、MyKinstaでエラーログ、キャッシュログ、アクセスログを簡単に閲覧することができます。
また、wp-config.phpファイルにコードを加える方法もあります。まず、SFTPでサイトに接続し、wp-config.phpをダウンロードして、編集できるようにします。なお、このファイルは必ずバックアップしてください。
/* That's all, stop editing! Happy blogging. */と書いてある行を探し、その直前に以下のコードを貼り付けます。
define( 'WP_DEBUG', true );
上記のコードがすでにwp-config.phpファイルに存在しており、「false」に設定されている場合は、「true」に変更するだけでOKです。これでデバッグモードが有効になります。注）WordPress管理画面に警告やエラーがある場合は、それも表示されます。
次に、以下のコードをWP_DEBUG行の直後に貼り付けます。これで、すべてのエラーをファイルに送信するデバッグログが有効化されます。
define( 'WP_DEBUG_LOG', true );
変更を保存したら、ファイルをサーバーに再アップロードします。エラーは、/wp-content/フォルダ内のdebug.logファイルに記録されます。何らかの理由でこのファイルが表示されない場合は、ファイルを作成してください。
5. MyKinstaの分析機能を使用する
Kinstaのお客様であれば、MyKinstaの分析機能を使ってパフォーマンスに関する情報を取得できます。
「パフォーマンス」タブには、PHP+MySQLの平均応答時間、PHPのスループット、AJAX使用状況、平均応答時間上位のPHP+MySQL一覧、最大応答時間上位のアップストリーム一覧が表示されます。
PHP+MySQLの平均応答時間
PHPとMySQLは、WordPressサイトへのアクセス時、ページ上に表示されるデータのコンパイルとクエリに使用されます。このグラフは、キャッシュされていない動的なリクエストに対する、PHPエンジンとMySQLエンジンの平均応答時間を示しています。この応答時間を確認することで、速度低下のトラブルシューティングに役立ちます。
PHPのスループット
スループットは、アプリケーションが処理できる1秒あたりのトランザクション数です。このセクションでは、WordPressサイトのPHPスループット、つまり、PHPアセットが何回リクエストされたかを示しています。
AJAXの使用状況
AJAXは、ポストバックや完全なページ更新を必要とせずに、サーバー/データベースと通信するクライアントサイドスクリプト。WordPressでは、速度テストを行う際に目にしたことがある方もいるはずです。AJAXに関してよくあるのは、プラグインが原因で急増する問題、そしてバックエンドのCPUの問題です。
WordPressサイトのAdmin-AJAXの使用量の高さを診断する方法はこちらをご覧ください。
MyKinstaの分析画面の「AJAX使用状況」セクションでは、特定の期間にAjax使用率が急増していないかどうかを確かめることができ、この手の問題のトラブルシューティングに役立ちます。このグラフは、Ajaxリクエストの数を示し、先ほど上でご紹介した記事を参考に、リクエストの送信元を絞り込みましょう。
平均応答時間上位のPHP+MySQL一覧
PHPとMySQLの上位の平均応答時間が一覧で表示されます。この数値は一度限りの可能性があるため、「最大応答時間上位のアップストリーム一覧」と比較しながら参照することが推奨されます。
最大応答時間上位のアップストリーム一覧
アップストリームは、Nginx（およびアップストリームサーバー）がリクエストを処理し、レスポンスを送信するのにかかる総時間を意味します。時間の単位は秒ですが、ミリ秒で表示されます。
6. サイトがハッキングされている可能性
パフォーマンスのボトルネックがなかなか特定できない場合は、サイトがハッキングされていたり、マルウェアに感染していたり、DDoS攻撃を受けたりしているかもしれません。その場合、サイト速度やWordPress管理画面の応答性にも影響を与えることがあります。心配な方は、以下のような策を講じてください。
- プロキシサーバーやWAF（CloudflareやSucuriなど）を導入する
- 上記サービスで悪質なIPアドレスをブロックする（Kinstaをご利用の場合は、MyKinstaでIPアドレスをブロック可能です）
- ジオブロッキング（位置情報に基づいたトラフィック拒否）を使用する─中にはトラフィックの質が全体的に低い地域があり、攻撃を受けている場合は、一時的または恒久的に国全体をブロックするのが得策かもしれません。
7. エラーコード（HTTPステータスコード）によるトラブルシューティング
HTTPステータスコードは、ウェブサーバーからの短いメモのようなもので、ウェブページの上部に表示されます。これは、ウェブページの一部ではなく、サーバーがページを表示するリクエストを受け取った際、どのような状態になったかを知らせる、サーバーからのメッセージです。このステータスコードは、トラブルシューティングに一役買ってくれる存在です。
ステータスコードには40種類以上ありますが、WordPressユーザーには、以下のメッセージが一般的です。
「429 Too Many Requests」─ある一定の時間内に送信されたリクエスト数が多すぎる場合に発生します（レート制限の超過）。これは、ボットやスクリプトがサイトにアクセスしようとして起こることもあるため、WordPressのログインURLを変更することをおすすめします。
「500 Internal Server Error」─これは単純に「内部サーバーエラー」を意味する一般的なコードで、サーバーで何かしらの問題が発生し、要求されたリソースを提供できない際に発生します。通常、サードパーティのプラグイン、PHPの不具合、またはデータベースへの接続切断が原因です。データベース接続確立エラーの解決方法、「500 Internal Server Error」エラーの解決方法を参考にしてみてください。
「502 Bad Gateway」─あるサーバーが他のサーバーから無効なレスポンスを受け取ったことを意味するエラーコード。クエリやリクエストの処理に時間がかかりすぎ、サーバーによって停止または強制終了され、データベースへの接続が切断されることがあります。「502 Bad Gateway」エラーの解決方法はこちらをご覧ください。
「503 Service Temporarily Unavailable」─サーバーが一時的に利用不可であることを示しており、リクエストを処理できず、過負荷がかかるとサーバーが返すエラーコードです。
「504 Gateway Timeout」─リクエストの処理に関わるサーバーが2つあり、最初のサーバーが2つ目のサーバーの応答待ちでタイムアウトした場合に返されるエラーコード。「504 Gateway Timeout」エラーの解決方法はこちらでご紹介しています。
また、MyKinstaの分析機能を使って、HTTPステータスコードを調べることも。「レスポンス」タブの「レスポンスコードの内訳」では、要求されたリソースに対して提供されたHTTPステータスコードの内訳を確認することができます。
「レスポンス統計データ」では、リダイレクトの総数、エラー、成功率、エラー率が表示されます。小さなエラー率は、すべてのWordPressサイトに見られ、まったく正常な状態です。
500番台エラー、400番台エラー、リダイレクトなど、エラーコード別の内訳レポートも確認できます。
バックエンド最適化のヒント
このセクションでは、WordPressサイトの高速化のため、バックエンドを最適化する方法をご紹介します。バックエンドとは、PHP、HTTPキャッシュヘッダー、GZIP圧縮など、サーバーですべて処理されるものを指します。
1. 軽量な404エラーページを作成する
高度に動的なサイトでは、404エラーが度々発生するもの。予想以上にサイトでエラーが発生している可能性は大いにあります。MyKinstaの分析機能は、以下のように、エラーの発生量を正確に調べることができます。
404エラーの厄介な点は、大量のリソースを消費すること。動的なWordPressサイトでは、重たい404エラーページはできる限り避けたいものです。データベースへの問い合わせを必要最低限にするため、可能であればシンプルで軽量な404エラーページを作成しましょう。もちろん、404エラーはリソースを消費する点だけでなく、ユーザー体験にも悪影響を与えるため、後回しにせず解決してください。
シンプルな404エラーページを作成したら、専用のページキャッシュルールを実装することもお勧めします。Kinstaでは、404エラーページを15分間自動的にキャッシュされます。キャッシュされた404エラーページと同じURLで新たにページが作成すると、ウェブサーバーがそれを検出し、自動的にキャッシュをパージします。WordPressサイトにキャッシュ可能な404エラーページがない場合は、ご利用のホスティング会社に助けを借りて、追加するのが賢明です。
2. ワーカープロセスを増やす
ワーカープロセスとは、ホスティングサービスがリクエストの制限を処理する方法です（共用サーバーが一般的に行うCPUやRAMによる制限とは別物）。
ワーカープロセスは、サイトがある時点で処理できる同時リクエストの数を決定します。簡単に言うと、サイトへのキャッシュされていないリクエストは、ワーカープロセスが処理することになります。例えば、同時に4つのリクエストがあり、サイトのワーカープロセス数が2である場合、4件中2件のリクエストが処理され、残りは最初の2件の処理が終わるまで、キューで待機しなければなりません。
WordPressの会員制サイトにおける最大の問題は、キャッシュされないリクエストにある点というのは先にご説明した通り。リクエストごとに処理を行う必要があるため、ワーカープロセスは非常に重要な存在です。したがって、会員サイトでは、すべてのリクエストが遅延なく正常に処理されるよう、より多くのワーカープロセスが必要になります。
ワーカープロセスを使い切ると、キューは古いリクエストを押し出すようになり、500エラーを引き起こす可能性があります。
3. GZIP圧縮を使用する
GZIPはファイル形式であり、ファイルの圧縮と解凍に使用されるソフトウェアアプリケーション。GZIP圧縮はサーバーサイドで有効化され、HTML、スタイルシート、JavaScriptファイルのサイズをさらに小さくすることができます。
ブラウザがサイトにアクセスすると、サーバーがHTTPヘッダーcontent-encoding: gzipの有無を確認して、GZIP圧縮が有効であるかを確認します。このヘッダーを検出すると、サーバーは圧縮されたファイルを提供します（ヘッダーがない場合は、圧縮されていないファイルを提供）。GZIP圧縮が有効でない場合は、Google PageSpeed InsightsやGTmetrixのような速度測定ツールで警告やエラーが表示されるのが通例です。
GZIP圧縮を使用すると、ウェブページのサイズが縮小され、リソースのダウンロードも大幅に高速化されます。さらにクライアントのデータ使用量も減り、ページの最初のレンダリングまでの時間を短縮することも。この機能は、現在のホスティング業界で極めて標準的ですが、念の為お使いのホスティング会社に確認してみてください。
4. 直リンクを禁止する
直リンクとは、一言で言えば、インターネット上にある画像のURLを自分のサイトにそのまま使用すること。サイトに表示される画像は、参照元から提供されることになります。画像を転用する側にとっては非常に便利ですが、参照元のサイトのリソースを消費することになるため、窃盗行為と見做されます。わかりやすく例えるなら、横に停まっている車からガソリンを無断で抜いて、走り去るようなものです。
直リンクは、ターゲットサーバーのリソースを大量に消費する可能性があります。WordPressの共用サーバーを利用していて、ハフポストが無断で自分のサイトの画像をリンクしたことを想像してみてください。1時間に数百程度だったクエリが、突然数十万のクエリになるかもしれません。最悪の場合、ホスティングアカウントの停止につながります。このような事態を避けるため、このような障害にも対応できる高性能なホスティングを選択し、直リンクを禁止してください。
直リンクを禁止する方法はこちらをご覧ください。
5. リダイレクトを最小限に抑え、サーバーレベルで設定する
リダイレクトが多い場合は、要注意です。301リダイレクト、HTTPからHTTPS、wwwありからwwwなし（その逆も然り）など、シンプルなリダイレクトであれば問題ありません。実際、サイトの特定の領域である程度は必要になります。とは言え、リダイレクトがパフォーマンスに影響を与えないことはありません。リダイレクトを設定する際には、サイトに与える影響を念頭に置くことが重要です。これは固定ページや投稿、画像のリダイレクトなど、あらゆるものに該当します。
リダイレクトのレスポンスヘッダーは、301または302です。
では、リダイレクトはどの程度サイトに影響を与えるのでしょうか。以下、簡単なテストを行ってみます。まず、お問い合わせページ（https://perfmatters.io/contact/）の速度を測定します。読み込み時間は417ミリ秒でした。
次に、URLに変更を加え（http://www.perfmatters.io/contact）、複数のリダイレクトの影響を見るために、再度速度を測定します。すると、同じページでも読み込みに695ミリ秒かかりました。これは66％の増加に相当します。
リダイレクトの設定に無料のWordPressプラグインを使用すると、コードの実行とリソースが必要なwp_redirect関数を利用することになるため、パフォーマンスの問題が発生する可能性があります。また、wp_optionsテーブルにデータを自動読み込みするものもあり、データベースの肥大化を引き起こすプラグインも。したがって、リダイレクトはサーバーレベルで設定するのが望ましいです。Kinstaでは、MyKinstaでリダイレクトルールを追加することができます。
また、MyKinstaの分析画面では、サイトに設定されているリダイレクト（301、302、304）の内訳が表示されます。
WordPressのリダイレクトとパフォーマンスの改善方法についてはこちらでご紹介しています。
6. cronジョブを適切に使用する
cronジョブ（WP-Cron）は、WordPressサイトで繰り返し必要になるタスクをスケジュールするために使用します。しかし、cronジョブは時が経つにつれて、制御不能になり、パフォーマンスの問題を引き起こす可能性があります。無料のWP Crontrolプラグインを使って、サイト上で発生しているcronジョブを確認、処理することができます。
また、WordPressに組み込まれているcronジョブ、WP-Cronでもパフォーマンスの問題が発生することがあります。サイトに十分なワーカープロセスがない場合、リクエストを受けた際、時折cronが起動されますが、ワーカープロセスが必要なため、何も処理することができません。これの解決策としては、WP-Cronを無効にして、システムのcronを使用すること。公式のプラグインハンドブックでもこれが推奨されています。
WP-Cronを無効にするには、以下のコードをwp-config.phpファイルの「That’s all, stop editing! Happy blogging.」の直前に貼り付けます。これは、wp-cron.phpを介して直接呼び出したときでなく、ページ読み込み時に実行されるのを無効にするコードです。
define('DISABLE_WP_CRON', true);
その後、サーバーでwp-cron.phpをスケジュールします。Kinstaのお客様であれば、cronはデフォルトで有効になっており、15分ごとに実行されるようになっています。この頻度を増やしたい場合は、カスタマーサポートまでご連絡ください。SSHに慣れている場合は、コマンドラインでサーバーのcronを管理することも可能です。
7. Cache-ControlヘッダーとExpiresヘッダーを追加する（キャッシュの有効期限を決定）
WordPressサイト上のすべてのスクリプトには、HTTPキャッシュヘッダーが必要です（または推奨）。このヘッダーは、ファイルのキャッシュの有効期限を決定するものです。
これにはまず、利用しているホスティングサービスでcache-controlヘッダーとexpires ヘッダーが正しく設定されていることを確認してください。そうでなければ、速度測定ツールでexpiresヘッダーを追加するか、ブラウザのキャッシュを活用するよう警告が表示されます。
cache-controlヘッダーがクライアントサイドのキャッシュを有効にし、リソースの寿命（提供できる秒数）を設定するのに対し、expiresヘッダーは、リソースの有効期限を指定するために使用します。両方のヘッダーを併用することもできますが、cache-controlの方が新しく、基本的にはこれだけを使用することが推奨されます。
Kinstaでは、すべてのサーバーリクエストに自動的にHTTPキャッシュヘッダーが追加されます。また、CDNを使用していれば、大抵は自動追加されるはずです。
サーバーにこのヘッダーがない場合は、自分で設定しましょう。
NginxでCache-Controlヘッダーを追加する
Nginxでcache-controlヘッダーを追加するには、サーバー設定の場所またはブロックに以下を貼り付けます。
location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
expires 30d;
add_header Cache-Control "public, no-transform";
}NginxでExpiresヘッダーを追加する
Nginxでexpiresヘッダーを追加するには、以下をサーバーブロックに貼り付けます。これは、ファイルの種類によって異なる有効期限を指定する例です。
location ~* \.(jpg|jpeg|gif|png|svg)$ {
expires 365d;
}
location ~* \.(pdf|css|html|js|swf)$ {
expires 2d;
}ApacheでCache-Controlヘッダーを追加する
Apacheでcache-controlヘッダーを追加するには、.htaccessファイルに以下を貼り付けます。コードスニペットは、ファイルの先頭または末尾（「# BEGIN WordPress」の前または「# END WordPress」の後）に追加することができます。
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"
</filesMatch>ApacheでExpiresヘッダを追加する
Apacheでexpiresヘッダーを追加するには、.htaccessファイルに以下を貼り付けます。
## EXPIRES HEADER CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
</IfModule>
## EXPIRES HEADER CACHING ##なお、HTTPキャッシュヘッダーを追加できるのはサーバー上のリソースのみです。サードパーティのリクエストに対し、ブラウザのキャッシュを使用する必要があるのではないかという警告が表示された場合、サードパーティのサーバーを経由したリクエストではないため、どうすることもできません。この一般的な原因としては、Google アナリティクスのスクリプトや、FacebookやTwitterなどのマーケティングピクセルが挙げられます。
Google アナリティクスのスクリプトでこれを修正する場合は、PerfmattersやWP Rocketのようなプラグインを使用し、ローカルまたはCDN（正式サポートはなし）でホストすることができます。
8. Last-ModifiedヘッダーとETagヘッダーを追加する（キャッシュを有効化）
次に、last-modifiedとetagの2つのヘッダーを追加します。
cache-controlとexpiresは、ブラウザが前回のリクエスト時から、ファイルが変更されたかどうかを判断するのに役立ちます（要するにキャッシュの検証）。last-modifiedとetag ヘッダーは、キャッシュを検証し、その長さを設定するもので、オリジンサーバーのレスポンスに必ず含まれます。このヘッダーが適切に設定されていない場合は、「Specify a cache validator」という警告が表示されることがあります。
ヘッダーが見当たらない場合は、毎回リソースに対してリクエストを生成しなければならず、サーバー負荷が増加します。キャッシュヘッダーを活用すれば、それ以降のリクエストをサーバーから読み込む必要がなくなり、帯域幅の消費量を削減し、ユーザー側のパフォーマンスを向上することができます。
Kinstaでは、サーバーリクエストに上記のヘッダーが自動追加されます。CDNを利用している場合も、通常はヘッダーが追加されます。cache-controlとexpiresと同様、外部リソースにこのHTTPヘッダーを設定することはできません。
Last-Modifiedヘッダー
last-modifiedヘッダーは、通常サーバーから自動的に送信されます。一般に自分で追加する必要のないヘッダーのひとつで、ブラウザキャッシュにあるファイルが、前回リクエストされた時点から変更されているかどうかを確認するために送信されます。Pingdomでヘッダーリクエストを見るか、Chromeのデベロッパーツールでlast-modifiedヘッダーの値を確認することができます。
ETagヘッダー
ETagヘッダーもlast-modifiedヘッダーと似ており、ファイルのキャッシュを検証するために使用されます。Apache 2.4以降を使用している場合は、FileETagディレクティブでETagヘッダーが自動追加されます。Nginxでも2016年以降、デフォルトで有効化されています。
Nginxでは、以下のコードを実行して自分でETagヘッダーを設定することができます。
etag on9. Vary: Accept-Encodingヘッダーを追加する
Vary: Accept-Encodingヘッダーは、すべてのオリジンサーバーのレスポンスに必要なもので、クライアントがコンテンツの圧縮バージョンを扱えるかどうかをブラウザに伝えます。これが適切に設定されていない場合は、「Specify a Vary: Accept-Encoding Header」という警告が表示されることがあります。
例えば、GZIP圧縮が有効でない古いブラウザと、有効な最新のブラウザがあるとします。vary: Accept-Encodingヘッダーを設定しないと、ウェブサーバーやCDNが圧縮されていないバージョンをキャッシュし、それを最新ブラウザに配信してしまいます。その結果、WordPressサイトのパフォーマンスが低下する可能性があります。ヘッダーを使用することで、ウェブサーバーや CDNが適切なバージョンを確実に配信することができるようになります。
Kinstaでは、サーバーリクエストに上記のヘッダーが自動追加されます。CDNを利用している場合も、通常はヘッダーが追加されます。また、上で見た他のキャッシュヘッダー同様、外部リソースに設定することはできません。
Vary: Accept-EncodingヘッダーをApacheに追加する
Vary: Accept-EncodingヘッダーをApacheに追加するには、.htaccessファイルに以下を貼り付けます。
<IfModule mod_headers.c>
<FilesMatch ".(js|css|xml|gz|html)$">
Header append Vary: Accept-Encoding
</FilesMatch>
</IfModule>Vary: Accept-EncodingヘッダーをNginxで追加する
Nginxに追加する場合は、以下のコードを設定ファイルに貼り付けてください。Nginxの設定ファイルは、すべて/etc/nginx/ディレクトリに格納されています。主要な設定ファイルは/etc/nginx/nginx.confです。
gzip_vary on10. wp-config.phpでWordPressのメモリ制限を変更する
WordPress Codexに記載されている通り、WordPressのバージョン 2.5では、WP_MEMORY_LIMITでPHPが消費できる最大メモリ容量を指定することができます。この設定は、「Allowed memory size of xxxxxx bytes exhausted（許容メモリサイズ xxxxxx bytesを消費しました）」などのメッセージが表示された場合に必要となる可能性があります。
WordPressは、デフォルトで、PHPに割り当てられるメモリをシングルサイトでは40MB、マルチサイトでは64MBまで増やします。メモリの上限は、./wp-includes/default-constants.phpの32～44行目に定義されています（参照）。
また、ホスティング会社は、サーバー上にPHPのmemory_limitを設定しますが、これはWordPressのメモリ制限とは別物です。Kinstaでは、デフォルトのmemory_limitは256Mに設定されています。メモリ不足のエラーに遭遇したら、WordPressのPHPのメモリ制限を増やしてみてください。
wp-config.php filファイルを開き、「That’s all, stop editing! Happy blogging.」行の直前に以下を貼り付けます。
define( 'WP_MEMORY_LIMIT', '256M' );また、Jan Reilink氏もWordPressのメモリ制限の問題に関する有益な記事を公開しており、使用可能なコードも紹介しています。手動で容量を設定する代わりに、PHPのmemory_limitの値を変更して設定することができます。
define( 'WP_MEMORY_LIMIT', ini_get( 'memory_limit' ) );フロントエンド最適化と外部サービスのヒント
続いて、フロントエンドを最適化し、WordPressサイトを高速化する方法をご紹介します。フロントエンドとは通常、CSS、JavasScript、画像など、クライアント側のブラウザですべて処理されるものを意味します。また、サイトと連携している外部サービスについても調査し、サイト全体の速度にどのような影響を及ぼしているかを確認することもこれに該当します。
フロントエンド最適化に関しては、以下2つの点が最も重要です。
- ページ全体を軽量化する─CSS、JavaScript、画像のサイズは重要で、4MBのウェブサイトは、1MBのウェブサイトよりも読み込みに時間がかかるのが通例。Paul Calvano氏は、ページの重さが速度に与える影響、およびその他の指標も追跡することの重要性について解説しています（記事はこちら）。
- HTTPリクエストと外部サービスを削減する─HTTP/2の登場により、1つのTCPコネクションを使用して複数のリクエストとレスポンスを同時に送信できるようになりました。これはパフォーマンスの改善に効果的ですが、HTTPリクエストを減らすことで、さらなる高速化につながります。これは、それぞれDNSルックアップ、TLS接続、ネットワークレイテンシなどの遅延を引き起こす、外部リクエストと連携サービスの数を減らすことも含まれます。
1. WordPressサイトの速度を測定して基準値を把握
サイトのフロントエンドを最適化するには、まずは速度テストツールを使って基準値を測定しましょう。おすすめの速度テストツールはこちらでご紹介しています。
Pingdomの使用方法やGTmetrixの使用方法も併せてご覧ください。なお、速度を測定する際には、以下の点を念頭に置いてください。
複数のツールを併用せず、1つのツールに絞る
Pingdom、GTmetrix、WebPageTest、PageSpeed Insights、Chromeのデベロッパーツールは、どれも優れたツールですが、色々と併用する必要はありません。それれぞれ独自の測定方法や指標を持っているため、1つのツールを選択し、それに絞ってテスト、最適化を行ってください。Googleも使用ツールは1つに絞ることを推奨しています。
スコアにこだわりすぎない
Google PageSpeed Insightsなどのツールでは、速度やパフォーマンスに独自のスコアが表示されますが、実際のサイト速度や訪問者が実際に体験するパフォーマンスほどは重要でないことをお忘れなく。100点満点にこだわりすぎることは、時間の無駄になりかねません。あくまで目安として捉えてください。外部スクリプトや広告を多く含む大規模なサイトでは、満点を取ることはほぼ不可能ですが、まったく問題ありません。
テストを実施する場所を考慮する
速度テストの実施場所は、非常に重要です。上でご説明した通り、これはすべて選択したデータセンターの場所、TTFB、ネットワークレイテンシ、すべてが関係します。速度の測定は、データセンターに近い場所、そして遠い場所の両方で行ってください。これによって、CDNがどれほどWordPressサイトのパフォーマンスを向上できているかも確認可能です。
キャッシュのため、テストは複数回実行する
「キャッシュの重要性」セクションでもご説明したように、WordPressホスティングやCDNでキャッシュが最近クリアされたか、有効期限が切れている場合、HTTPヘッダーが「MISS」になります。これは、サイトやアセットがキャッシュから配信されていないことを意味します。
サイト全体の速度を正しく測定するには、すべてのページとアセットがキャッシュから読み込まれた状態、つまりキャッシュヘッダーが「HIT」ではなければなりません。キャッシュをHITさせため、テストは複数回実施してください。その後、平均値を確認します。
それでは、WordPressサイトのフロントエンドを最適化する方法をご紹介していきます。
2. レンダリングをブロックするJavaScriptとCSSを削除する
ページの読み込みを妨げるファイルがあると、レンダリングをブロックするJavaScriptやCSSに関する警告が表示されることがあります。特定のJSやCSSは条件付きで表示されることがあり、Above the fold（スクロールせずに閲覧できる画面領域）のコンテンツを表示する必要がありません。async属性やdefer属性を使って、レンダリングブロックを回避することができます。
レンダリングをブロックするリソースを削除する方法について、動画での解説もご用意しています。
レンダリングブロックを引き起こすJavaScriptとCSSを削除するには、以下の作業が必要になります。
クリティカルレンダリングパスからJSを取り除く
JavaScriptをクリティカルレンダリングパスから除外するには、JavaScriptリソースを呼び出すHTML要素scriptに、deferまたはasync属性を追加するのが一般的です。
- async属性：HTML解析の速度を落とさずにリソースのダウンロードをすぐに開始するよう、ブラウザに指示。リソースが利用可能になるとHTMLの解析が一時停止され、リソースを読み込む。
- defer属性：HTML解析が完了するまでリソースのダウンロードを保留するよう、ブラウザに指示。ブラウザがHTML解析を終えると、遅延されたスクリプトをすべてダウンロードし、ドキュメントに表示されている順にレンダリングする。
CSSリソースの配信を最適化する
CSSの配信を最適化するということは、本質的に、レンダリングブロックが発生しない方法が必要になるということです。
- Above the foldコンテンツのレンダリングに必要なスタイルを特定し、HTMLとインラインで配信する
- 必要時だけデバイス上で条件付きでCSSを使用する
- 残りのCSSは非同期に読み込む
上記すべてを実行するのは難しい場合もあり、サイトのスクリプトに応じて微調整が必要になります。以下のプラグインがおすすめです。
詳細は『WordPressのレンダリングを妨げるリソースを除外する方法（CSSとJavaScript）』をご覧ください。
3. WordPressで外部CSSとJavaScriptを結合する
外部CSS結合の警告は、cdn.domain.comのような外部ドメインでCSSファイルをホストしていることから、CDNを使用している際に発生します。この問題は、従来CSSファイルの連結、つまり1回のリクエストで読み込むように結合することで、すぐに解決することができました。
HTTP/2に対応しているプロバイダーでHTTPSを実行している場合は、この警告は以前ほど深刻ではありません。HTTP/2では、1つの接続で複数のCSSファイルを並行して読み込むことができます。現在、86%以上のブラウザがHTTP/2をサポートしています。
とは言え、この最適化にまったく効果が見られないとは限りません。ファイルのサイズと数によっては、WordPressサイトが高速化された事例もあり、試してみる価値は十分あります。
外部CSSとJavaScriptファイルを結合する最も簡単な方法は、無料のAutoptimizeプラグインを使用すること。結合後、「autoptimize_xxxx.css」または「autoptimize_xxxx.js」ファイルが表示され、CDNからの読み込みにも対応しています。また、WP Rocketプラグインでも実行可能です。
WordPressサイトで外部CSSとJavaScriptを結合する方法はこちらをご覧ください。
4. HTML、CSS、JavaScriptを圧縮する
HTML、CSS、JavaScriptのリソースを圧縮することで、ブラウザがダウンロードするデータ量を抑えることができます。圧縮（minify）とは、ソースコードからコメントや空白、改行などの不要な文字を削除すること。このような文字は、開発時には非常に便利ですが、ブラウザがページをレンダリングする際には不要になります。
圧縮されていないHTML
圧縮されていないHTMLのコード例を見てみましょう。
圧縮されたHTML
圧縮されたHTMLコードは、以下のようになります。
無料のAutoptimizeプラグインやWP Rocketを使用すると、簡単にファイルを圧縮することができます。
5. Cookieフリードメインを使用する
画像、JavaScript、CSSなどのコンテンツを配信する際、余計な負荷となるHTTP Cookieを使用するメリットはありません。サーバーが特定のドメインにCookieを設定すると、それ以降のすべてのHTTPリクエストにそのCookieを含まなければなりません。この警告は通常、リクエストの多いサイトで表示されます。
Cookieフリードメインから静的コンテンツを提供する警告への対処方法はこちらをご覧ください。HTTP/2などの比較的新しいプロトコルでは、この警告の重要性が低くなっており、大体は無視しても問題ありません。別の接続を追加するのは、同じ接続ですべてを配信するよりも高額になります。
この警告を解決する簡単な方法としては、Cookieを無視、またCookieを削除し、クライアントがSet-Cookieヘッダーを受け取るのを完全に阻止してくれるCDNサービスを使用すること。例えば、KeyCDNでは、デフォルトで以下2つの機能（Cookieを無視、Cookieを削除）が有効になっています。これによって、静的アセットを別のサブドメインから配信するためにサイトを移動したり、設定したりする手間を省くことができます。
Cloudflareを利用している場合、同社のネットワークを通じて提供されるリソース上のCookieは無効にできません。Cloudflareは、ヘッダーに独自のセキュリティCookieを設定していますが、このCookieは非常に軽量で、パフォーマンスへの影響も最小限です。とは言え、Cloudflareでこの警告を回避する方法はありません。
この警告を解決するもう1つの方法は、別のドメインまたはサブドメインから静的アセットを配信するようにWordPressサイトを再設定することです。
WordPress 4.4では、埋め込み（oEmbed）機能がコアにマージされました。これは、ユーザーがURLを貼り付けるだけで、YouTube動画やツイートなどのリソースをサイトに埋め込むことができ、自動的にビジュアルエディターでライブプレビューを表示する機能です。この更新によって、WordPress自体で埋め込みコードを取得できるように。
この機能は非常に便利で、多くの人が使用していますが、wp-embed.min.jsファイルを読み込むために、WordPressサイトに追加のHTTPリクエストが生成されます。そして、これはサイト全体に読み込まれます。このファイルは1.7KBほどですが、「塵も積もれば山となる」です。時にはコンテンツのダウンロードサイズよりも、リクエスト自体の方が深刻な問題になることも。
このファイルを読み込まないようにする簡単な方法は、いくつかあります。
- 方法1. プラグインで埋め込み機能を無効にする
- 方法2. コードで埋め込み機能を無効にする
- 方法3. JavaScriptをインラインに移す
6. WordPressで絵文字機能を無効にする
WordPress 4.2では、古いブラウザ用に絵文字機能を内蔵していました。この機能の問題は、wp-emoji-release.min.jsファイルを読み込む際、サイトに追加のHTTPリクエストを生成する点。また先ほどの埋め込み機能同様、サイト全体に読み込まれます。ファイルサイズはわずか10.5 KBですが、サイトで絵文字を使用しない場合には無駄になります。
WordPressで絵文字機能を無効にする方法は、以下をご覧ください。
- 方法1. プラグインで絵文字機能を無効にする
- 方法2. コードで絵文字機能を無効にする
7. コメント欄の設定を最適化または無効化する
大量のコメントは、パフォーマンス上の問題を引き起こすことがります。コメントの動作には、以下のリソースが必要になります。
- データベースに問い合わせて、既存のコメントを引き出す
- 新規コメントごとにデータベースエントリを生成
- コメントとコメントのメタデータは、訪問者のブラウザで受信、処理される
- Gravatarのような外部リソースを要求、ダウンロード、および読み込み（DNSルックアップが必要に）
- （多くの場合）コメントシステムを正常に動作させるために、大規模なJavaScriptとjQueryのリソースをダウンロード、処理
今回は、WordPressサイトのコメント欄を最適化する方法を4種類ご紹介します。
選択肢1. コメントを無効にする
もしコメント数があまり多くなく、コメント欄が特段必要でない場合は、コメントを無効にしてしまうことを検討してください。Googleは通常、コメントをページの追加コンテンツとしてクロールするため、SEOにも影響が出る可能性があります。手順は以下をご覧ください。
選択肢2. WordPressのコメントシステムを最適化する
2つ目は、WordPressのコメントシステムを最適化する方法。ネイティブコメントシステムを最適化することです。まずは、最初のページ読み込みで表示されるコメント数を減らしましょう。
- WordPressの管理画面で「設定」＞「ディスカッション」に移動
- 「他のコメント設定」セクションまでスクロール
- 「コメントをXX階層までスレッド（入れ子）形式にする」にあるチェックボックスを選択し、最初の読み込みで表示するコメント数を設定
別の方法として、Kinstaでは、CDNでGravatarを読み込んでいます。
WordPressサイトのコメントが読み込まれる際、デフォルトで一意のGravatarごとにHTTPリクエストが必要になります。そのため、50名のユーザーによるコメントが読み込まれる場合は、すべてのGravatarをダウンロードするめ、50件のHTTPリクエストが必要です。これがページの表示速度に影響を与えることは、容易に想像がつくはず。gravatar.comへの外部DNSルックアップが時々遅くなり、場合によっては、タイムアウトが発生することは言うまでもありません。
KinstaブログのGravatorを見ると、kinsta.com（KinstaのCDNを含む）から読み込まれていることがわかります。CDNからGravatorを読み込む方法はこちらを参照してください。
選択肢3. サードパーティのコメントシステムを使用する
3つ目の方法は、サードパーティのコメントシステムを使用すること。安価でリソース不足が懸念される共用サーバーを利用している場合、サードパーティのコメントシステムを使用すると、コメント数の多いページを高速化できる可能性があります。これは、画像最適化と同じ考えで、負荷が軽減されるため。しかし、Kinstaなどの質の高いホスティングサービスを利用している場合は、サードパーティに切り替えても高速化の効果は見られず、場合によっては遅くなる可能性もあります。
また、コメントシステムは、使用する前に必ず速度テストを行いましょう。Disqusが生成する個別のリクエストを見てみます（以下図参照）。ほとんどのリクエストは非同期に読み込まれていますが、Disqusを使用している場合は、追加の読み込み時間が発生します。
選択肢4. コメントを遅延読み込みする
4つ目の方法は、コメントを遅延読み込み（レイジーロード）して、最初のページレンダリングを高速化すること。以下のプラグインが役に立ちます。
- Lazy Load for Comments（WordPressのコメントシステムを遅延読み込みさせることができる）
- Disqus Conditional Load（Disqusのコメントシステムを利用する場合は、遅延読み込みに必須）
8. WordPressのRSSフィードを無効にする
WordPressのブログ機能を使用していない場合は、RSSフィードを無効にしましょう。これによって、パフォーマンスを劇的に改善されるわけではありませんが、必要ないものは無効にしておけば、心配の種が減ります。
WordPressのRSSフィードを無効にする方法は、以下をご覧ください。
- 方法1. プラグインでRSSフィードを無効化する
- 方法2. コードでRSS フィードを無効にする
9. プリフェッチとプリコネクトを使用する
リソースヒントやprefetchやpreconnectなどのディレクティブは、WordPressサイトを高速化する画期的な方法です。KeyCDNがリソースヒントの概要についてわかりやすく説明しています。
プリフェッチ
DNSプリフェッチは、ユーザーがリンクをクリックする前にドメイン名を解決（バックグラウンドでDNSルックアップを実行）することができ、パフォーマンスが改善されます。設定するには、WordPressサイトのヘッダーにrel=”dns-prefetchタグを追加します。
<link rel="dns-prefetch" href="//domain.com">DNSプリフェッチの一般的な使用事例は、CDNのURL、Google Fonts、Google アナリティクスなど。
<link rel="dns-prefetch" href="//cdn.domain.com/">
<link rel="dns-prefetch" href="//fonts.googleapis.com/">
<link rel="dns-prefetch" href="//www.google-analytics.com">プリフェッチは、最近のほぼすべての主要ブラウザでサポートされています。WordPressのヘッダーにコードを追加する方法はこちらでご紹介しています。
Perfmattersのようなプラグインで、DNSプリフェッチを簡単に実装することも。Perfmattersの「Extras」タブをクリックし、ドメインを追加するだけでOKです。形式は、//domain.tld（1行に1つ）。
プリコネクト
プリコネクトは、HTTPリクエストの前にブラウザが早期に接続をセットアップすることを可能にします。往復の待ち時間を省略することで、サイトが高速化されます。
「プリコネクトは、非常に重要な最適化ツールです。リクエストパスから費用のかかる多くの往復時間を削減し、場合によっては、リクエストの待ち時間を数百から数千ミリ秒短縮することも実現可能です（英語原文の日本語訳）」─lya Grigorik氏（引用元）
設定するには、WordPressサイトのヘッダーにrel=”preconnect “タグを追加します。
<link rel="preconnect" href="//domain.com">例えば、CDNのURLやGoogle Fontsなどに利用可能です。
<link rel="preconnect" href="https://cdn.domain.com"><link rel="preconnect" href="https://fonts.gstatic.com">
また、Safari、IOS Safari、Opera Miniを除くほぼすべての主要なブラウザでサポートされています。WordPressのヘッダーにコードを追加する方法はこちら。
Perfmattersのようなプラグインで、簡単に実装することもできます。Perfmattersの「Extras」タブをクリックし、ドメインを追加するだけでOKです。形式は、scheme://domain.tld （1行に1つ）。
10. 固定ページ・投稿単位でスクリプトを無効にする
WordPressサイトを高速化する別の良い方法は、固定ページや投稿で読み込まれている各リクエストに注目すること。高確率で、サイト全体で読み込まれるはずのないスクリプトが見つかります。
例えば、Kinstaメンバーが開発したPerfmattersプラグイン（有料）には、スクリプトマネージャー機能が組み込まれており、固定ページ・投稿単位、またはサイト全体で、ワンクリックでスクリプト（CSSとJavaScript）を無効にすることができます。
スクリプトマネージャーを使用すれば、以下のような操作を行うことができます。
- 人気プラグインContact Form 7は、すべての固定ページと投稿で読み込まれるため、お問い合わせページのみで有効になるように設定。
- SNS共有プラグインは投稿にだけ読み込まれるように設定（投稿タイプ、あるいはカスタム投稿タイプにのみ読み込むように設定可能）。
- 目次プラグインは、すべての固定ページと投稿で読み込まれるため、読み込みたい場所を指定。
一部のプラグインがこのようにコード化されている理由
プラグイン開発者は、なぜプラグインがページ上で検出されたときにだけスクリプトを読み込まない設定にしないのか、という疑問を抱く方もいるでしょう。これには、やや複雑な理由があります。例えば、Contact Form 7のようなプラグインをインストールしている場合、プラグインにはショートコードがあり、どこにでも配置可能であり、ウィジェットにドロップすることもできます。WordPressでは、スクリプトをデキューする際、投稿や固定ページのメタデータからデータを問い合わせるのとは対照的に、スクリプトからデータを問い合わせるのは非常に困難になります。
要するに、大抵は使い勝手を優先しているというのが理由です。プラグインが壊れる可能性が低ければ、サポートの必要性は必然的に減るものです。今日数多くのプラグインが存在しており、このような問題を回避し、パフォーマンスを考慮したコーディング方法がないことはありませんが、ダウンロード数や利用者数の多さから、使い勝手を優先したプラグインも見られるのが現状です。
スクリプトマネージャーの使用方法
スクリプトマネージャーの使い方を簡単にご紹介します。ツールバーの「Script Manager」をクリックすると、現在のURLで読み込まれているすべてのスクリプト（JavaScriptとCSSファイル）が表示されます。この画面で、以下の設定を行うことができます。
- Status On（デフォルト設定）
- Status Off：完全に無効化（どの投稿タイプで有効にするか、現在のURLとともに選択可能）
- Status Off：現在のURLのみで無効化（トップページで使用する際に有用）
- Status Off：例外（現在のURL、投稿タイプ、アーカイブ）
この画面では、プラグイン名やテーマ名でグループ化されたものが一覧表示されるため、プラグイン全体を簡単に無効化することができます。WordPressのプラグインは、JavaScriptとCSSの両方のファイルを持っているのが通例です。WordPressテーマは10以上のファイルを含んでいることも。
設定を終えたら、画面下にある「Save」をクリックします。その後、速度テストツールでサイトのテストを実施し、スクリプトが固定ページや投稿に読み込まれなくなったかどうかを確認しましょう。なお、まず最初にキャッシュはクリアすること。テストを行い、サイトに視覚的に問題が生じた場合は、スクリプトマネージャーに戻って、再度有効にすることも可能です。
woorkupのスピードテストでは、全体の読み込み時間が20.2％短縮される結果に。トップページでは、HTTPリクエストの数が46から30に減り、ページサイズも506.3KBから451.6KBに縮小されました。
スクリプトを無効にするその他の方法はこちらをご覧ください。
11. 外部サービスのパフォーマンス分析
サイトから外部へ呼び出すものは、基本的にすべて表示速度に影響を与えます。厄介なのは、外部サービスの中でも時折低速になるもの。これが問題の特定を複雑化しています。
サードパーティの外部サービスとは、自分のサーバー外からWordPressサイトと通信するものすべてを指します。代表的なものは、以下の通りです。
- Twitter、Facebook、InstagramなどのSNSプラットフォーム（ウィジェットまたはコンバージョンピクセル）
- Google Adsense、Media.net、BuySellAds、Amazon Associatesなどの広告ネットワーク
- Google アナリティクス、Crazy Egg、Hotjar、AdRollなどのアクセス解析ツールおよびトラッキングスクリプト
- Optimizely、VWO、UnbounceのようなA/Bテストツール
- Disqus、Jetpack、Facebookコメントなど、WordPressのコメントシステム
- VaultPress、Sucuri、CodeGuardなどのバックアップおよびセキュリティツール
- SumoMe、HelloBarなどのSNSツール
- KeyCDN、Amazon CloudFront、CDN77などのCDNサービス
- 外部でホストされるJavaScript
上記のような外部サービスは、パフォーマンスにどの程度の影響を与えているのでしょうか。Kinstaが実施したテストでは、サードパーティのスクリプトがページの読み込み時間を86.08%増加させることがわかりました。
また、GhosteryがAlexaの米国上位500ドメインを測定した結果、外部サービスをまったくブロックしない場合、ウェブサイトは2倍遅くなることがわかりました。つまり、これらのサードパーティのトラッキングスクリプトは、ページの表示速度を低下させる大きな要因の1つと言えます。
特にWordPressサイトでは、サードパーティのAPIを一度呼び出すだけで、サイト全体がタイムアウトする可能性があり、注意が必要です。実際にタイムアウトが発生した事例は多数あります。
New Relicでは、外部サービスを時系列で監視することができます。以下は、twitcount.com、graph.facebook.com、および widgets.pinterest.comに対して行われた外部呼び出しの表示例です。
サイトに新機能やプラグインを実装する際には、必ず読み込まれる外部リソースを確認するようにしましょう。少なければ少ないほど、パフォーマンスへの影響が少なくなります。
常にモバイルファーストを意識した最適化
Googleは、2018年3月26日にモバイルファーストインデックスの展開を開始しました。これまでのGoogleのクロール、インデックス、検索ランキングシステムは、デスクトップ版のウェブサイトを対象としていました。しかし、モバイルファーストインデックスの登場により、インデックスとランキングの決定に、Googlebotがモバイル版のサイトをクロールするように。これによって、モバイルユーザーの検索体験が向上されます。
モバイルファーストを考慮してサイトを最適化する場合、スピードは最も重要な要素の1つ。サイト速度は、ユーザビリティから直帰率、潜在顧客がサイトに再訪するかどうかの決断に至るまで、あらゆる面で重要な鍵を握っています。Google検索や広告のモバイル検索では、スピードが検索順位の要因です。
良好なモバイルユーザー体験を提供できなければ、ほとんどの人がサイトに戻ってきてくれません。Googleページ速度レポートによると、モバイルサイトの平均読み込み時間はなんと7秒。1つのページを読み込むのに、15秒も辛抱強く待つユーザーはほとんどいないでしょう。
ユーザーは当然、より良いものを求めています。同じレポートによれば、モバイルサイト訪問者の53％が、読み込みに3秒以上かかるページから離脱しています。
低速なモバイルユーザー体験は、コンバージョンの機会を奪います。ページの表示速度が数秒遅くなるだけで、ユーザーが離脱する可能性は大幅に高まります。以下、モバイル端末向けにサイトを最適化する際に考慮すべき点をご紹介します。
1. モバイルトラフィックを把握する
まずは、モバイルからのトラフィックがどの程度あるのかを把握することが重要です。Google アナリティクスの「レポート」＞「テクノロジー」＞「ユーザーの環境の詳細」に移動します。この画面で「デバイス カテゴリ」を選択すると、モバイル端末からサイトにどのくらいアクセスがあるかどうかを確認することができます。例えば、以下のサイトでは、全体の74％以上がモバイル端末から来ていることがわかります。
Kinstaのお客様であれば、MyKinstaの分析画面で、モバイルとPCのトラフィックを比較することができます。以下の例では、88％以上のトラフィックがPCから。モバイルトラフィックは、単に想定するだけでなく、常に把握しておくようにしましょう。モバイル化が進んでいるとはいえ、自分のサイトもこれに該当するとは限りません。実際のデータを重視してください。
2. サイトをレスポンシブ対応に
サイトはレスポンシブ対応であることが理想的です。これは、メディアクエリを利用して、モバイルデバイスの画面サイズに合わせて、自動縮小することを意味します。レスポンシブ対応を行なっていない場合は、すでに競合他社に遅れをとっている可能性が高いです。今回この記事でご紹介したWordPressテーマは、すべてレスポンシブ。あらゆるデバイスで美しい外観を表示することができます。
Googleのモバイル フレンドリー テストで、サイトがすべての要件を満たしているかどうか確認することができます。
3. srcset属性が機能しているかを確認する
以前は、画像を拡大縮小してアップロードし、CSSでリサイズさせないことがベストプラクティスでしたが、WordPress 4.4以降は、レスポンシブ画像（CSSで縮小されない画像）のサポートが搭載され、あまり重要でなくなりました。メディアライブラリにアップロードされた画像は、複数のサイズで自動作成されます。画像の利用可能なサイズをsrcset属性に加えると、ブラウザが最も適切なサイズをダウンロードし、他のサイズを無視するようになります。コード例は以下の通り。
しかし、サードパーティの画像プラグインやカスタマイズによって、これが正しく動作しないこともあります。そのため、画像が適切にsrcset属性を取得し、画面サイズごとに異なるバージョンで追加されているかどうかを再確認してください。画像最適化は、今や常に重要です。
4. AMPの利用を検討する
GoogleのAMP（Accelerated Mobile Pages）は、2015年10月に公開されたプロジェクト。既存のウェブ技術だけで構築されたオープンフレームワークのAMP HTMLに依存し、軽量のウェブページを構築することができます。簡単に言うと、現在のウェブページの縮小版を提供する手法です。
AMPについては賛否両論あります。Kinstaでも使用しましたが、結局良い結果を得ることはできませんでした。しかし、AMPが有効かどうかはサイトによって異なり、試す価値ありはあります。また、AMPも継続的に改善されています。
AMPは、以下のプラグインを使って簡単に利用することができます。
AMPのセットアップ方法はこちらをご覧ください。また、必要に応じてAMPを無効にする方法もご紹介しています。
まとめ
長尺となりましたが、今回はWordPressサイトを高速化する方法を一挙にご紹介しました。サイトの高速化は、検索順位の上昇、検索エンジンのクローラビリティの向上、コンバージョン率の向上、ユーザーの滞在時間の増加、そして直帰率の減少につながります。より高速なサイトが好まれるという事実は、取り上げるまでもありません。
この記事で取り上げたヒントが、WordPressサイト高速化のお役に立てれば幸いです。気に入っていただけたら、ぜひSNSプラットフォームやブログ等で共有をお願いします。また、無料の電子書籍『WordPressサイトを高速化する方法』のダウンロードもお忘れなく。
WordPressサイトの高速化について、他にも大切なヒントをご存知ですか？ぜひ以下のコメント欄でお聞かせください。
コメントを残す