WordPressの最適化またはスピードアップについてのチュートリアルを長年にわたって発行してきました。しかし、必要な情報をまとめて見つけるのは難しい場合もあるでしょう。そのため今日は、WordPressのターボチャージについて知っているすべての情報と、15年以上に渡る経験と実績を一つのガイドにまとめます。WordPressを使い始めたばかりの方であろうか、経験の長い開発者であるかにかかわらず、この記事はお役に立つものであると考えています。

Webの37.6%以上がWordPressを使用しています。これは素晴らしいことである一方、何千ものテーマ、プラグイン、そして技術が共存しなければなりません。WordPressの一般のユーザーにとっては、ウェブサイトが壊れたときに、何をどう処理すればいいかわからない為、これこそは難しいことです。

ページのスピードアップに関する以前のガイドでは、パフォーマンスの基本と、それがビジネスの成功への影響を説明しました。今日、WordPressウェブサイトを改善するために今でも実施できる手順について説明します。または、便利なリソースも共有します。

WordPressウェブサイトの種類:静的または動的

最適化に取り組む前に、まずWordPressウェブサイトがそれぞれ違うことを理解しておく必要があります。課題の処理方法もそれぞれである為、ユーザーの多くがその処理方法に悩んでいます。当社ではまず該当のWordPressウェブサイトが静的であるか動的であるか判断します。さて、これら2種類のウェブサイトの違いを調べてみましょう。

基本的に静的なウェブサイト

静的ウェブサイトは例えば、ブログ、中小企業のウェブサイト、小規模のニュースサイト、個人用ウェブサイト、写真サイトなどです。静的とは、データがあまり頻繁に変更されないことを指します。(例えば一日に数回)Kinstaのウェブサイトさえ静的なウェブサイトです。

リクエストの多くはサーバーのキャッシュから恐ろしく早く配達できる為、これは非常に重要なことです。キャッシングについては、後程詳しく説明します。簡単に言えば、データベースの呼び出しが少なくなり、Googleのパフォーマンスを達成するために必要なリソースが少なくなります。

非常に動的なウェブサイト

その一方で、非常に動的なウェブサイトがあります。電子商取引サイト(WooCommerce、Easy Digital Downloads)、コミュニティ、メンバーシップ、フォーラム(bbPress、BuddyPress)、または学習管理システム(LMS)などのことです。動的とは、データが頻繁に変更されることを指します。(数分ごとに、あるいは数秒ごとにサーバートランザクションが行われています。)つまり、サーバーへのリクエストの中にはキャッシュから配達できないものもあり、追加のサーバーリソースとデータベースクエリが必要になります。

これらのウェブサイトには、同時訪問者とそのセッションが多いです。静的なウェブサイトである情報サイトまたは企業のWordPressウェブサイトでは、訪問者が必要な内容を見つけるまでにかかる5〜10分ぐらいしか滞在しません。(通常は直帰率はさらに高く、5~10分はかなり高い数値です。)動的なウェブサイトは逆です。訪問者は対話するためにウェブサイトにアクセスし、例えばオンラインコースなら何時間も滞在するのも珍しいことではありません。

分かりやすい問題ですよね。WordPressホストの同時訪問者の数が多く、「キャッシュ不可能なコンテンツ」も多いです。

You can't treat all WordPress sites the same when it comes to performance. Static and highly dynamic sites are two very different beasts! 🦖Click to Tweet

高性能のWordPressホスティング会社を選択する

WordPressホスティング会社は、ウェブサイトのデータを保存している会社です。プランに登録すると、お客様のすべての画像、コンテンツ、ビデオなどはホスティング会社のデータセンターにあるサーバーに保存されます。WordPressホスティング会社を使用すると、データがアクセスしやすく、管理しやすく、訪問者へルーティングしやすくなります。シンプルそうですね。実は、もう少し難しいです。

Web上にはWordPressホスティング会社が3種類あります。3種類ともメリットとデメリットがありますので、お紹介します。最初から適切なものを選択しないと、課題が次々と発生してしまいます。

1. 共有WordPressホスティング

WordPressホスティングの最も人気のある方法は「共有ホスティング」というものです。例えば、本産業最大のホスティング会社の中にはBluehost やHostGatorといったEIGグループの会社、その他にはSiteground、GoDaddy、InMotion Hostingが共有ホスティング会社です。この会社は通常cPanelを採用し、月額料金は3~5ドルです。

共有ホスティングプランを利用するお客様は遅さを感じるようになります。それは何故でしょうか。共有ホスティング会社はサーバーを実能力以上に使ってしまう傾向があり、あなたのウェブサイトもその影響を受ける場合があるからです。これらの会社は赤字にならないようにリソースを制限する為、ウェブサイトの一時停止または頻繁に発する500エラーも珍しくありません。さらに悪いことに、ウェブサイトのダウンタイムも多いです。したがって、あなたがそれを知らないにもかかわらず、あなたのウェブサイトは200人以上の他の人と同じサーバーの上にあるかもしれません。 他のウェブサイトに発生してしまう性能上の問題があなたのウェブサイトに影響を与える可能性があります。

共有WordPressホスティング

いくら考えても、月当たりの3ドルは、全ての費用を引いた後にホスティング会社の収益を生み出していません。特にサポートも考慮すれば、サポートチケットが一件発生しても赤字になります。従って、こういった会社が収益を生み出す為にはアップセリングまたは隠れた料金を使っています。これらのアップセルには、マイグレーション、ドメイン登録、SSL証明書などが含まれます。もう1つのよくある戦略は、契約割引です。しかし、更新日には本当の金額の請求書が来ます。

ほとんどのホスティング会社は「無限のリソース」プランというものを提供しています。 あなたはおそらく見たことがあります。 ただし、無限のリソースというものはこの世の中に存在していません。ホスティング会社は実際に行うのは、多くのリソースを使ってしまうお客様を制限することです。怒っているお客様が解約して、多くのリソースを使用しないお客様のためのスペースが設けられます。 最終的には、ホスティング会社が安いプランを推進し、お客様が多くのリソースを使わずにアップセルを購入することを望む悪質なサイクルができます。

共有ホスティングはお客様が多くてもサポート担当者が足りない為、顧客サービスは質が低い場合があります。共有ホスティング会社は利益を得るためにコストダウンに取り組まないといけない為、お客様の満足度が低いことも珍しくありません。

When it comes to shared hosting, you usually get what you pay for. 😒Click to Tweet

安価なWordPressホスティングの背後にある衝撃的な真実についての当社のCFOによる詳細記事を是非ご確認ください。

 

2. DIY VPS WordPressホスティング

WordPressホスティングの2種類目はDIY  VPS(「Do it yourself on a virtual private server.」和訳:仮想プライベートサーバーのDIY)です。DIYを選択するのは主にブートストラップのスタートアップまたは開発、サーバー管理またはWordPressの経験者です。彼らはDIY群です。彼らも通常、お金を節約しようとしていますが、性能への関心を持ち、ビジネスの成功の為の性能の重要性を認識しています。一般的なセットアップには、Digital Ocean、Linode、Vultr VPSの使用 とより簡単に管理できる為の、例えばServerPilotのようなツールが含まれています。

DigitalOceanの小規模なVPSは月当たり5ドルから始まり、ServerPilotの人気のあるプランは月当たりに10ドルから始まります。あなたの設定に応じて、5~15ドルまたはそれ以上の月額が発生する可能性があります。DIYのアプローチは間違いなくコストを削減する場合がありますが、何かが壊れた場合には責任を負わないといけませんし、サーバーの最適化もご自分で行わないといけません。

DIYのアプローチは素晴らしいかもしれませんが、気を付けなければ恨みを買うこともあります。興味でこのアプローチを選んではいけません。あなたの時間は金になりますので、あなたのビジネスを成長させるために費やすべきです。

3. マネージドWordPressホスティング

ホスティングの3種類目はKinstaも提供しているマネージドWordPressホスティングというものです。マネージドホスティング会社は、バックエンドサーバー関係の仕事をすべて実施し、必要なときにサポートを提供しています。WordPressと連携するように微調整されており、ワンクリックステージング環境および自動バックアップなどの機能を提供する場合が多いです。サポートチームはプラットフォームに焦点を当てており、CMSに詳しく、知識が広いです。

時間を節約したい方は、マネージドWordPressホスティングを選択すればよいでしょう。👍

マネージドWordPressホスティングのプランは、ウェブサイトの規模にもよるもので、月額は25ドル~150ドルくらいです。例えば、 jQuery、Plesk、Dyn、NGINXなどの大企業とホワイトハウスさえWordPressを使ってウェブサイトをホストしています。あなたもご存じまたはご利用かもしれないマネージドWordPressホスティング会社は例えばWP EngineFlywheel、Pressable、Media Temple、Pressidium、Pagelyがあります。

Kinstaのアプローチが違う

KinstaはマネージドWordPressホスティングをさらに改善してきました。当社ホスティングプラットフォームは従来のホスティングカテゴリのいずれにも該当しません。われわれのインフラストラクチャ全体はGoogle Cloud Platform上に構築され、従来の共有、VPS、専用インフラストラクチャとは一線を画します。

当社のプラットホームのすべてのWordPressウェブサイトがその稼働に必要なソフトウェア(Linux、Nginx、PHP、MySQL)のある、隔離されている専用コンテナに保管されます。つまり、各ウェブサイトの稼働に必要なソフトウェアは100%プライベートで、お客様自身のウェブサイト間も共有されません。

Kinstaのアーキテクチャ

Kinstaのアーキテクチャ

 

各サイトコンテナは、Google Cloudの数多くのデータセンターのどちらかの仮想マシン上で動作しています。各マシンは最大96個のCPUと数百GBのRAMがあり、ハードウェアリソース(RAM / CPU)が必要になったときに、仮想マシンにより各サイトコンテナに自動的に割り当てられます。(自動スケーリングという便利な機能です。)

Review Signalは毎年、WordPressのホスティングパフォーマンスベンチマークを発表しています。Kinstaは5年連続ですべてのティアにわたり最高の企業になったことを誇りに思っています。そして、いくつかのプランだけではなく、StarterからEnterpriseのすべてのプランです。🤘

KinstaのLoadStorm試験もBlitz試験も基本的には完璧でした。その他の試験でも何も問題ありませんでした。彼らの性能をうまく表現できるような言葉がなかなか見つけにくいです。
Kevin Ohashi
Kevin Ohashi
ReviewSignalの創業者兼務WPコンサルタント

当社の顧客サポート担当者はレベル1とレベル2の2つのレベルに分かれていません。サポートチームが完全にWordPress開発者とLinuxホスティングエンジニアで構造されており、中には自サーバー管理、テーマやプラグイン作成、コア貢献の経験者が大勢います。つまり、WordPressを積極的に使用・開発する専門家にお困りごとの相談ができます。

Kinstaのすべてのお客様は、大企業およびフォーチュン500をサポートしている同じチームメンバーとチャットできます。当社に応募する候補者から実際に雇うのは1%未満です。当社の顧客サポートよりいいものはどこにもありません。

WP Engineでは細かい問題だと簡単に解決できました。ただし、もっと複雑な問題の場合はやり取りが長くて解決に至るまで時間がかかります。最高級のWordPressウェブサイトを運営し緊急対応の必要な案件があると、これは本当に問題です。1つしか選べないのであれば、僕の意見ではKinstaの方がいいです。彼らは約束以上のものを提供しています。ウェブサイトの速度減、ダウンタイム、質のいいサポートがもらえるかとう心配が必要ありません。
Harsh Agrawal
Harsh Agrawal
ShoutMeLoudの受賞歴のあるブロガー

マネージドWordPressホスティング会社としてKinstaを選ぶ理由・Kinstaが他のサービスと違う理由についてはこちらをご参照ください。ホスティングプロバイダを選択する際に、ウェブサイトのできるだけ早いスピードを確保するための下記の機能があるかを是非ご確認ください。

最高のパフォーマンスのため、PHP 7以上を使用する

PHPは、主にWeb開発に使用されるオープンソースでサーバー側のスクリプトおよびプログラミング言語です。 WordPressのコアソフトウェアの大部分も、プラグインとテーマもPHPで書かれており、PHPはWordPressコミュニティにとって非常に重要な言語です。ご利用のWordPressホスティング会社では少なくともPHP 7以上が利用可能になっていることを必ずご確認ください。

各ホスティング会社で利用可能になっているPHPのバージョンがそれぞれ違います。パフォーマンスがもっとお改善されるバージョンはもちろん最新のPHP 7.3です。

実は当社の最新のPHPベンチマークによれば、PHP 7.3とPHP 5.6を比較すると、1秒毎に処理できるリクエスト(トランザクション)の数は3倍になっています!PHP 7.3はまた、PHP 7.2よりも平均9%高速です。これはWordPressの管理ダッシュボードの反応時間にも影響を与えます。

WordPress 5.0のPHPベンチマーク

WordPress 5.0のPHPベンチマーク

スピードアップとセキュリティ向上の為、Kinstaでは常に最新版のPHPが利用可能になります。PHPのバージョン間の切り替えはワンクリックでできます。

PHPのバージョン間の切り替え

PHPバージョン間の切り替え

最後に、PHPに代替品としてHHVMを提供しているWordPressホスティング会社に気をつけてください。HHVMはWordPressホスティングに適したソリューションではなくなりました

NGINXを採用しているホスティング会社を選択する

舞台裏では、すべてのWordPressホスティング会社はWordPressウェブサイトを稼働するためのウェブサーバーを採用します。最も一般的な選択肢はNGINXとApacheです。

NGINXは規模を考慮したパフォーマンス最適化ができる為、NGINXを採用するホスティング会社を強くお勧めします。NGINXは、ベンチマーク試験で特に静的コンテンツや同時リクエストが多い状況では、他の一般的なウェブサーバーよりもパフォーマンスが優れていることが多い為、KinstaがNGINXを採用しています。

Nginx

有名な会社でNGINXを採用しているのは例えば、Autodesk、Atlassian、Intuit、T-Mobile、GitLab、DuckDuckGo、Microsoft、IBM、Google、Adobe、Salesforce、VMWare、Xerox、LinkedIn、Cisco、Facebook、Target、Citrix Systems、Twitter、Apple、Intel等があります。(出典

W3Techsによると、Apacheはすべてのウェブサイトの45.9%で使用されるため、間違いなく最も人気きのある選択肢です。ただし、トラフィックの最も多いウェブサイト(トップ10,000)だけを見ると、NGINXがそれらの64.2%を占めています。Netflix、NASA、さらにはWordPress.comなどの最もリソースの必要なウェブサイトがNGINXを使用しています。

詳細については当社のウェブサーバー対戦記事をご参照ください:NGINX対Apache

ホスティング会社のネットワークが重要

WordPressホスティング会社を選択するとき、その会社が使用しているネットワークを調べる方が少ないかもしれませんが、調べる価値があります。ネットワークはウェブサイトのパフォーマンスにも、WordPressダッシュボードの速さにも大きな影響を与える場合があります。コストダウンの為安いネットワークを使用し、上記の事実を教えてくれないホスティング会社が多いです。

尋ねるべき質問は例えば次があります:

  • どのネットワークを介してデータを送信していますか? その大部分は、公衆ISPネットワークですか、それともGoogleやMicrosoftなどのプライベートインフラストラクチャですか? 上記の大手会社は、低レイテンシとスピードに最適化されたネットワークと、会社専用の海底インターネットケーブルさえ持っています!
  • 使用しているネットワークは冗長ですか? ケーブルが誤って切断された場合はどうなりますか?驚くほどよく発生することなんです!

2017年にGoogleは遅くて安い標準ティアネットワークの導入を発表しました。Kinstaでは、すべてのホスティングプランを対象にプレミアムティアネットワークを採用しています。Kinstaとしては追加の費用になりますが、お客様に超高速なスピードを確保することができます。

Kinsta uses Google Cloud Platform's premium tier network. Because your websites deserve the best. ⚡Click to Tweet

Googleによると、プレミアムティアネットワークは、公衆インターネット上での移動時間を短縮することにより、ネットワークパフォーマンスを向上させます。パケットは、できる限りユーザの近くにある場所でGoogleのネットワークに入り(又は出る)、Googleの基幹回線で送信され、仮想マシンに入ります。スタンダードティアなら、Googleのネットワークではなく、公衆送信(ISP)ネットワークを介してGCPからインターネットへのトラフィックを配信します。

Google Cloud Platformのプレミアムティアネットワーク

Google Cloud Platformのプレミアムティアネットワーク (画像の出典:Google

分かりやすく言い換えますと:

  • プレミアムティアのパケットなら、Googleのネットワーク上に過ごす時間が長く、ネットワークをあまり出入りしない為、パフォーマンスは向上します。(一方、費用はかかります。)
  • スタンダードティアのパケットなら、Googleのネットワーク上に過ごす時間が短く、公衆ネットワークで送信されるため、パフォーマンスが低いです。(一方、やすいです。)

上記の影響度といえば、大陸間のデータ送信の場合にプレミアムティアネットワークはスタンダードティアネットワークより平均して約41%速いです。近くのリージョン(大陸内)のデータ送信なら、プレミアムティアは約8%速いです。ネットワーキングは合計読み込み時間の一部しか占めていませんが、1ミリ秒1ミリ秒が重要な意味を持っています。

For data traveling across continents, Google Cloud's premium tier network is on average 41% faster! 💥Click to Tweet

冗長性も重要である為、Googleは、Googleのネットワーク上のどの2カ所間でも少なくとも3つの独立したパス(N+2冗長)を使用し、混乱が発生した場合でもトラフィックが止まらないことを確保します。

ご覧の通り、ネットワーキングなら舞台裏が重要です。ご利用のWordPressホスティング会社が評判の良い会社で、コストダウンのために安いネットワークを採用する会社でないことをご確認ください。

HTTP/2はマスト

HTTP/2は2015年にリリースされたウェブプロトコルで、ウェブサイトの配信をスピードアップするために設計されました。HTTP/2では、ブラウザサポートのためHTTPS(SSL)が必要です。ご利用のWordPressホスティング会社がHTTP/2をサポートしていない場合は、新しいプロバイダを探した方がよいでしょう。Web全体がHTTPSに移行する今日では、HTTP/2は単純にあればいいものではなく、マストです。

HTTP/2によるパフォーマンスの向上は、多重化、並列性、ハフマン符号化によるHPACK圧縮、ALPN拡張子、サーバープッシュなどサポートによるものです。以前はHTTPS上で動作するようになったときにTLSのオーバーヘッドが結構ありましたが、TLS 1.2とTLS 1.3のおかげで現在かなり減ってきました。KinstaのすべてのサーバーもCDNもHTTP/2とTLS 1.3 対応です。

HTTP/2のもう1つの大きなメリットは、連結(ファイルの結合)またはドメインシャーディングの心配がないことです。これらは時代遅れの最適化になりました。

訪問者の近くにあるサーバーを選択する

WordPressウェブサイトをホスティングするときに最初にすべきことの1つは、訪問者またはお客様のいる場所を特定することです。これは何故重要であるかといえば、ウェブサイトをホスティングしている場所がネットワーク待ち時間とTTFBへの影響を与えるからです。または、SFTP速度もWordPress管理ダッシュボードも影響を受けます。

ネットワーク待ち時間:データのネットワークを介したの送信に必要な時間と遅延のことです。言い換えると、データのパケットがある地点から別の地点に移動する時間です。今日ではミリ秒単位で測定されますが、ネットワークによっては数秒かかる場合もあります。ゼロに近いほど良い値です。

当社のネットワーク待ち時間についての詳細記事をご参照ください。

TTFB: 「最初の1バイトが到着するまでの時間」(Time To First Byte)を指します。簡単に言えば、TTFBはブラウザがサーバーからのデータの最初のバイトを受け取るまでにかかる時間のことです。そのデータを受け取るまでに時間がかかるほど、ページを表示するのにかかる時間が長くなります。これもゼロに近いほど良い値です。

当社のTTFBについての詳細記事をご参照ください。

本記事では技術的な詳細については説明しません。簡単に言えば、ネットワークの待ち時間とTTFBをできるだけ減らせばいいです。そして、これらを減らせる最も簡単な方法の1つは訪問者のいる場所に近いサーバを選択することです。以下の工夫を使用することにより、最も適切なロケーションを抽出できます。

工夫1:Google Analyticsで訪問者のいる場所を特定する

最初にできることは、Google Analyticsでウェブサイト利用者の利用場所を確認することです。[ユーザー]→[地域]→[地域]にアクセスしてください。

下記のこの例では、トラフィックの90%以上がアメリカ合衆国からのトラフィックです。したがって、WordPressウェブサイトもアメリカ合衆国にあるサーバーに配置すればよいでしょう。市区町村レベルまで絞り込むこともでき、地元の会社ならこれは特に便利です。しかし、通常は米国のアイオワ州などの中心的な場所をお勧めします。

Google Analyticsの地域レポート

Google Analyticsの地域レポート

工夫2:電子商取引データを確認する

電子商取引サイトを運営している方は、お客様の住んでいる地域も是非確認してください。お客様は収入を生み出す訪問者である為、最も重要な訪問者です。通常は上記のトラフィックと一致するはずですが、必ずしもそうではありません。Google Analyticsに電子商取引の目的設定がある方は、その情報を上記の地域の情報と比較し、詳細な情報を得た上での決断ができます。または、ご利用の電子商取引プラットフォームのデータベースの情報を確認することもできます。

工夫3:簡単な待ち時間テストを実施する

各クラウドプロバイダーが現在地からの待ち時間を確認できるの便利で無料のツールを用意しています。ウェブサイト用の最も適切な地域を素早く特定できます。

  • GCP Ping(Kinstaサーバーを含むGoogle Cloud Platformのリージョンへの待ち時間の確認)
  • CloudPing.info(Amazon Web Servicesのリージョンへの待ち時間の確認)
  • Azure Latency Test(Azureのリージョンへの待ち時間の確認)

以下の例では、現在地からはアメリカのオレゴン州(us-west1)が最も速いです。一方、米国中のお客様のいる方は、西海岸と東海岸の両方からの訪問者の待ち時間を短くするために、米国のアイオワ州(us-central1)を選択すればよいでしょう。

Google Cloud Platformの待ち時間を確認する

Google Cloud Platformの待ち時間を確認する

Kinstaでは、世界中の24カ所のデータセンタが利用可能になっています。待ち時間もTTFBも低い場所は選択しやすいです!ネットワークホップの数さえ減ります。

Google Cloudデーターセンタのロケーション

Google Cloudデーターセンタのロケーション

待ち時間とTTFBを減らすその他の手段

サーバーの場所以外にも待ち時間を減らす手段があります。

  • WordPressウェブサイトでキャッシングを採用します。当社の試験では、キャッシングによりTTFBがなんと90%改善されました!
  • コンテンツ配信ネットワーク(CDN)を利用し、世界中のPOPからキャッシュされたアセットを配信します。これにより、ホストサーバーの近くにいない訪問者のネットワーク待ち時間が減ります。
  • HTTP/2プロトコルを利用して、並列化のおかげでラウンドトリップの回数を減らします。HTTP/2はすべてのKinstaサーバーで有効になっています。
  • 外部HTTPリクエストはサーバーの場所による独自の待ち時間がある為、数を減らします。
  • DNSはTTFBに影響を与えるため、検索時間が短いプレミアムDNSプロバイダを使用します。
  • ページが読み込まれる間、舞台裏でタスクを実行するためにプリフェッチとプリレンダリングを利用します。

ご心配なく、上記の推進事項の内容を後程ご説明します。

SFTPがWordPress管理ダッシュボードをスピードアップする

訪問者とお客様を常に最優先しましょう。ただし、あまり話題になっていませんが、パフォーマンス改善が日々の仕事にも影響を与えます。選択したデータセンターの場所は、SFTPのダウンロードとアップロードの速度(FTPクライアントでファイルを転送する速度)とWordPress管理ダッシュボードの応答性に影響を与えます。

つまり、訪問者にとって最適な場所を選択する一方で、ウェブサイト管理への影響も考慮してください。WordPressのメディアライブラリへのファイルのアップロードなどの仕事は、ウェブサイトがご自分の近くにあるデータセンターでホスティングされるほど速くなります。

Kinstaに移行してから管理ダッシュボードの速度が驚くほど速くなったというお客様のご意見をよくいただきます。速度に影響を与える要因は多数ありますが、24ヵ所のデータセンターを持つことは間違いなくインパクトが大きいです。訪問者にもご自分にも適切なロケーションをご選択ください。結局のところ、ウェブサイトの作成に何千時間も費やすのはあなた自身でしょう。

プレミアムDNSは無料のDNSより優れている

DNSとはDomain Name System(ドメイン名システム)の略で、ドメイン名を実際のWebサーバーと合わせることによりインターネット上のトラフィックを応援するものです。例えば、kinsta.comのようなドメイン名など人間にとって分かりやすいリクエストを216.3.128.12などのコンピュータにとって分かりやすいサーバーのIPアドレスに変換します。

DNSの概要

DNSの概要

無料のDNSもプレミアムDNSもあります。Kinstaのすべてのお客様には、Amazon Route 53を介してのプレミアムDNSをご利用いただけます。一般的に、プレミアムDNSは現在の世界においては不可欠だと考えております。

プレミアムDNSを選択する重要な理由はまず、スピードと信頼性です。DNSレコードを検索し、トラフィックをリダイレクトするのに、ほんの数ミリ秒であっても、時間がかかります。

通常だと、ドメイン名登録機関から取得する無料のDNSは比較的に遅い一方、プレミアムDNSはパフォーマンスが優れています。たとえば、当社の試験では、無料のNameCheapのDNSがAmazon Route 53のプレミアムDNSより33%遅いことがわかりました。さらに、プレミアムDNSは、特にDDoS攻撃を受けている時に、セキュリティと利用可能度が高いです。

SolveDNSのスピードテストなどのツールを使用することによりDNS検索時間を確認できます。DNSPerfもトップDNSプロバイダーのパフォーマンスデータを提供してくれます。

ドメイン登録機関の無料のDNSとプレミアムDNSの間妥協点として、プレミアムDNSのメリットを多く提供する無料サービスであるCloudflare DNSがあります。世界中の平均応答時間は20ミリ秒未満で、驚くほど速いサービスです。(下記を参照)

Cloudflareの無料DNSのスピードテスト

Cloudflareの無料DNSのスピードテスト

ただし、Cloudflareには他社のプロバイダと比較するとダウンタイムが多いというデメリットもあります。主に米国の訪問者のいる方は、もう一社のプレミアムDNSプロバイダーであるDNS Made Easyも検討する価値があります。この会社は過去10年間で最高のDNS稼働時間の会社として有名です。

下記、各プロバイダーの過去30日間のDNSPerfよる稼働時間のデータを示しています:

DNSプロバイダのダウンタイムはそれほど重要でしょうか? 実は、重要な場合も、あまり重要でない場合もあります。DNSは通常、DNSレコードのTime to Live(TTL、生存時間)の値を使用してISPにキャッシュされます。したがって、DNSプロバイダが10分間停止しても、誰も気付かないでしょう。しかし、プロバイダが頻繁に長期間のダウンタイムがある場合、またはISPとDNSレコードの両方が非常に低いTTL値を使用している場合には、ダウンタイムは重要です。

WordPressテーマも影響を与える

誰もが最新のWordPressテーマが好きですが、採用する前に必ず気を付けてください。まず、当社の無料のテーマと有料のテーマの違いについての記事をご確認ください。パフォーマンスなら、テーマに表示されるすべての要素がウェブサイトのスピードに影響を与えます。そして残念なことに、何千ものテーマの中にいいものもあれば悪いものもあります。

Your WordPress theme matters for performance. Choose the right one from the start. 💪Click to Tweet

どのテーマを選択すればいいでしょうか?次の2つの選択肢のいずれかをお勧めします:

  • 必要な機能だけで構築されている軽量のWordPressテーマ
  • 機能が多いが、未使用の機能を無効にすることが可能なWordPressテーマ

例えば、Googleフォント、Font Awesomeのアイコン、スライダー、ギャラリー、ビデオ、パララックススクリプトなどが未使用の場合に無効にすることができるはずの機能です。事後に手動で微調整しようとするのは本当に難しいです。逆に、最初から軽量であるテーマまたは、選択肢を提供するテーマを選択しましょう。

下記は、いくつかのお勧めできるWordPressテーマです。是非、ご心配なくお試しください!😉

下記のテーマはすべてWooCommerce、Easy Digital Downloads、WPML、BuddyPress、およびbbPressとの互換性があります。以下の設定を使用して、各テーマのスピードテストも実行しました:

  • Kinstaでホスティングし、WordPress 4.9.8を使用
  • PHP 7.3とSSL(HTTPS)
  • Kinsta CDN
  • Imagifyを使用し、画像の自動圧縮を実施

GeneratePress

GeneratePressは、スピード、SEOと使いやすさを念頭に置いて構築された、高速で軽量(1MB未満のzipファイル)のモバイル最適化されたWordPressテーマです。カナダの開発者であるTom Usborneにより作成され、積極的に更新され、サポートも優れています。Kinstaチームのメンバーでさえ、独自のプロジェクトにGeneratePressを使用している人がいます。

無料版とプレミアム版があります。WordPressレポジトリを確認すると、無料版には現在10万以上のアクティブインストールと160万以上のダウンロードがあり、評価は5つ星のうち5つです。(700名以上が5つ星を付けています)。

GeneratePress

GeneratePress

GeneratePressのメリットの1つは、すべてのオプションがWordPress自体のカスタマイザを使用することです。つまり、公開ボタンを押す前に、変更が表示され確認できます。それに、新しいテーマコントロールパネルの使い方を勉強せずに済みます。

さて、どれくらい速いでしょうか? GeneratePressを新しくインストールし、Pingdomスピードテストを5件実行して平均を取りました。合計ページサイズはわずか16.8 KBで、合計読み込み時間は305ミリ秒でした。該当のテーマの生のパフォーマンスを確認するためのベースラインテストを行うのはいつも便利です。

新しくインストールしたGeneratePressのスピードテスト

新しくインストールしたGeneratePressのスピードテスト

その後、GeneratePressのサイトライブラリからの作成済みのテーマの1つを使用してテストをもう一連行いました。作成済みのテーマには画像、背景、新しいセクションなどが含まれています。GeneratePressの利点の1つは、ページビルダープラグインを必要としない、作成済みのテーマがいくつかあることです。このテストの結果も400ミリ秒未満でした。

GeneratePressのフルサイトのスピードテスト

GeneratePressのフルサイトのスピードテスト

もちろん、実際の環境では、Google Analytics、Facebookのリマーケティングピクセル、Hotjarなども実行中でしょう。ただし、それでも1秒未満の目標を簡単に達成できるはずです。woorkupのGeneratePressについての詳細なレビューも是非ご確認ください。

下記でWordPressを最適化しスピードアップする方法をもっとご紹介します。

OceanWP

OceanWPテーマは、軽量で非常に拡張性が高く、ブログ、ポートフォリオ、ビジネスウェブサイト、WooCommerceストアなど、どの種類のウェブサイトも美しくてプロフェッショナルなデザインで作成できるテーマです。Nicolas Lecocqにより作成され、積極的に更新され、サポートも優れています。

GeneratePressと同様に、無料版とプレミアム版の両方があります。WordPressレポジトリを確認すると、無料版には現在40万以上のアクティブインストールがあり、評価は5つ星のうち5つです。(2,600名以上が5つ星を付けています。)

OceanWP

OceanWPテーマ

さて、どれくらい速いでしょうか? OceanWPを新しくインストールし、Pingdomスピードテストを5件実行して平均を取りました。合計ページサイズはわずか230.8 KBで、合計読み込み時間は389ミリ秒でした。スクリプトはOceanWPの方が少し大きくなっていますが、心配すべきほどのものではありません。

新しくインストールしたOceanWPのスピードテスト

新しくインストールしたOceanWPのスピードテスト

その後、OceanWPのサイトライブラリからのデモテーマの1つを使用してテストをもう一連行いました。作成済みのテーマには画像、背景、新しいセクションと必須のElementorページビルダープラグインが含まれています。このテストの結果も600ミリ秒未満でした。

OceanWPのフルサイトのスピードテスト

OceanWPのフルサイトのスピードテスト

当社のブログでのOceanWPの詳細なレビューも是非ご確認ください。

Astra

Astraは、高速で完全にカスタマイズ可能で美しくて、ブログ、個人のポートフォリオ、ビジネスウェブサイト、およびWooCommerceストアなどに適切なテーマです。非常に軽量(フロントエンドで50 KB未満)であり、比類のないスピードを持っています。Brainstorm Forceのチームにより作成され、積極的に更新され、サポートは優れています。このチームは人気のあるAll In One Schema Rich Snippetsプラグインの作成者でもあり、あなたもおそらく彼らのことをご存じでしょう。

GeneratePressやOceanWPと同様に、無料版とプレミアム版の両方があります。WordPressレポジトリを確認すると、無料版には現在40万以上のアクティブインストールと160万以上のダウンロードがあり、評価は5つ星のうち5つです。(2500名以上が5つ星を付けています。)

Astra WordPress theme

WordPressテーマAstra

さて、どれくらい速いでしょうか? Astraを新しくインストールし、Pingdomスピードテストを5件実行して平均を取りました。合計ページサイズはわずか26.6 KBで、合計読み込み時間は243ミリ秒でした。

新しくインストールしたAstraのスピードテスト

新しくインストールしたAstraのスピードテスト

その後、Astraスターターキットのサイトライブラリからのデモテーマの1つを使用してテストをもう一連行いました。作成済みのテーマには画像、背景、新しいセクションと必須のElementorページビルダープラグインが含まれています。このテストの結果も700ミリ秒未満でした。注:このデモの画像は完全に圧縮されていますが、最初から非常に高解像度の画像を使用ました。

Astraのフルサイトのスピードテスト

Astraのフルサイトのスピードテスト

なお、完全に正確な並列比較を実行することは無理である為、ご注意ください。上記の試験結果で示そうとしている重要なことはあくまでもこれらのWordPressテーマのいずれも、標準設定のままでもフルデモのままでも、驚くほど速いことです!🚀

ページビルダーの注意事項

お気づきのとおり、OceanWPとAstraはどちらもサイトライブラリのテーマを使用するにはページビルダーが必要です。ページビルダープラグインを使用する際の注意事項は下記のとおりです。

  • ウェブサイトの読み込み時間を増やすページビルダーもあります。理由はコードなしでも問題なく動作するために追加のCSSとJSを読み込む必要があることです。ページビルダーをインストールする前後に必ずWordPressウェブサイトのスピードテストを行いましょう。
  • ページビルダーをインストールするとおそらく長く使用するでしょう。そのため、定期的に更新されるかつ必要なものがすべて揃っているものを選択しましょう。

そうは言っても、Elementor及びBeaver Builderなどのページビルダーが好きです。両方はパフォーマンスを念頭に置いて開発されているものです。これらのプラグインを使用すると、ご希望の内容を何でも構築できるため、検討する価値が必ずあります。それに、これらを使用しない場合には同じ機能の為に5つ以上のプラグインも使用すべき場合がある為、この観点では速いです。

ただし、ページビルダープラグインが不要な方は、インストールしない方がいいです。または、今後の新しいGutenbergエディタのサイトデザインに果たす役割も興味深いでしょう。

WordPressプラグインの数を減らす

それでは、WordPressプラグインについても一言。WordPressウェブサイトのスピードが落ちる恐れがある為、あまりにも多くのプラグインをインストールしない方がいいと言われたことあるかもしれません。これは事実ですが、数は最も重要な要素ではありません。プラグインの数は、プラグインの品質ほど重要ではありません。 😜

テーマと同様に、そのプラグインはパフォーマンスを念頭に置いて開発されたかは重要です。Kinstaのお客様で30~40のプラグインがあっても、ウェブサイトが1秒未満で読み込まれるお客様が大勢います。

ウェブサイトにコードを追加するのは楽しいことですが、次の理由で必ずしも実用的ではありません:

  1. 自分でコードをメンテナンスし、標準が変わるときにその更新従う必要があります。誰もが忙しいで、標準を最もよく知っている開発者にその仕事を任せば良いではないでしょうか。
  2. 適切にコーディングされたプラグインには無駄な部分はありません。
  3. WordPressコミュニティには、開発者のように技術に詳しい方が少ないです。プラグインは問題解決に役立つソリューションです。

もちろん、そうは言っても、触らない方がいいプラグインもあります。Kinstaとしては最悪のプラグインのいくつかを経験しました。全部ではないが、Kinstaで禁止されているプラグインの多くは直接にパフォーマンスの異常を引き起こします。

WordPressプラグインの負荷テストを行い、WordPressウェブサイトの通常にキャッシュされていないバックエンドのパフォーマンスを確認することについてのFrancescoによる興味深い記事を是非ご確認ください。ウェブサイトの悪いプラグインを見つけ出す方法については以下で説明します。

ただし、WordPressの最も広く好まれている特徴の1つは、サードパーティ製プラグインの大規模なライブラリでしょう。しかし、WordPress.orgだけに56,000以上の無料のプラグインがあり、別のウェブサイトにも数多くあります。必要とするプラグインが極めて見つけにくい場合があります。では、どうすればいいでしょうかね。まず、当社の最高のWordPressプラグインの手作りのリストを是非ご確認ください。

本記事では当社のスタッフも日常的に使用するもののみをご紹介します。もちろん、Kinstaのウェブサイトにも皆様と同様にWordPressプラグインを使用しています。それに、Kinstaのチームメンバーの多くは、プラグイン開発または販売に取り組んでいます。

WordPressプラグインの課題

WordPressプラグインの大きな課題は、アンインストールです。WordPressのプラグインやテーマをインストールすると、データはデータベースに保存されます。そこでの課題は、標準の手順でプラグインを削除するときにデータベースにテーブル及び行などが残ってしまうことです。時間が経つにつれ、これは大量のデータになり、ウェブサイトのスピードが遅くなる場合さえあります。下記の例では、Wordfenceセキュリティプラグインをアンインストールしましたが、データベースにはテーブルが24点残っていました(下記参照)。wp_optionsテーブルのデータの背後にあるならば、さらに問題です。

WordFenceのテーブル

WordFenceのテーブル

多くのプラグインは、データベース以外にもフォルダ及びファイルを残します。経験から言うと、ロギング用に追加のディレクトリを作成するセキュリティプラグインまたはキャッシングプラグインでよくあることです。たとえば、Wordfenceプラグインが削除された後は、wp-contentディレクトリに 「wflogs」フォルダが残りました。もちろん、Wordfenceだけの話ではありません。市場のプラグインとテーマの多くは同じ概要です。

WordFenceのログ

WordFenceのログ

なぜ開発者はこのようなことをするのだろうか?

それでは、開発者はなぜプラグインをアンインストールまたは削除するときの自己掃除オプションを付けないのしょうか?実は、付けますが、あまり明確にしていないものです。その理由は:

  1. ユーザーの設定を保持したいのです。WordPressプラグインを削除しても、後でもう一度インストールするときに、すべての設定とデータはそのまま残ります。非常に便利ですが、あまり効率的ではありません。
  2. パフォーマンスを気にしません。テーブルを残すことはパフォーマンスを影響しないという開発者もいます。しかし、10年にわたり数千の行またはテーブルを生成した何百ものプラグインを使用したウェブサイトを想像してみてください。データベースのクエリはWordPressウェブサイトのパフォーマンスに大きな影響を与えます。そして、開発者が十分に注意していないとプラグインはリクエストを数多く生成することがあります。上手に書かれたプラグインなら結び付けられているテーブルや行のみをクエリしますが、そうとは限りません。Kinstaでは、wp_optionsテーブルに不要な自動読み込みデータが残っていたために長いデータベースクエリが発生しウェブサイトが破壊したことを経験したことがあります。
  3. 開発者は間違えました。WordPressプラグインハンドブックにさえ、「経験の浅い開発者は、誤ってこの目的のために非アクティブ化を使用することがある。」とも述べています。

もちろん、プラグインを正しく削除する方法もあります。👏下記のチュートリアルをご参照ください。

最適なWordPress設定

次に最適なWordPress設定に進みましょう。WordPressウェブサイトのスピードアップのための改善事項をご紹介します。下記の改善事項の多くは非常に微妙な変更ですが、一歩一歩と改善が出来るものです!

WordPressのログインURLを変更する

デフォルトでは、WordPressウェブサイトのログインURLはdomain.com/wp-adminです。ただし、すべてのボット、ハッカー、スクリプトなどもこれをよく知っています。URLを変更することで、ブルートフォース攻撃から自分を守ることができます。

WordPressのログインURLを変更すると、「429 リクエストが多すぎる」などのよく発生するエラーも予防できます。もちろん完全な解決策のにはなりませんが、便利な工夫です。

WordPressのログインURLを変更するには、次のプラグインのどちらかを使用することをお勧めします:

  • WPS Hide Login(無料)
  • Perfmatters (プレミアムが、その他のパフォーマンス最適化機能もあり。Kinstaのチームメンバーにより開発。)
PerfmattersにてWordPressログインURLを変更する

PerfmattersにてWordPressログインURLを変更する

プラグインとテーマの自動更新機能を無効にするまたは微調整する

WordPress管理ダッシュボードが遅いという課題の理由は、ネットワーク、データセンターの場所、さらにPHPのバージョンの場合もあります。しかし、あまり知られていないもう1つの要因は、バックグラウンドで実行されるWordPressの自動更新機能です。WordPressプラグイン及びテーマを数多く持っていることが悪影響を及ぼす一例です。この課題についてはWeFosterの素晴らしいブログ記事を是非ご確認ください。(彼らは「Third Party Plugin Update Check Syndrome」(TPPUCS、和訳:サードパーティ製プラグインの自動更新シンドローム)という言い方を付けています。)

問題なのは、WordPressの組み込みの自動更新機能が外部のGETリクエストをすることです。(https://third-party-plugin/update-check.php)これは定期的な場合も頻繁な場合もあります。頻繁に起こる場合には、管理ダッシュボードが遅くなるでしょう。

これはWordPressの自動更新機能の構造による問題です。WordPress管理者ダッシュボードの読み込み時間が遅いことに苦しんでいる方は、試してみる価値があるでしょう。対策は自動更新機能を無効にすることです。注:アップデートを手動で確認する予定がある場合にのみ行ってください。アップデートの多くにはセキュリティ改善及びバグ修正が含まれています。

更新機能を無効にするには、次のプラグインのどちらかをお勧めします:

  • Disable All WordPress Updates:完全に無料で、設定機能はありません。文字通りWordPressのすべてのアップデートを無効にします。
  • Easy Updates Manager:実行するとしないアップデートを選択できる機能があります。コアバージョンは無料です。

カレンダーのリマインダーを設定し、週に一度プラグインを無効にし、アップデートがあるかを確認し、更新後に再びプラグインを有効にすることはやりやすいことでしょう。

ピンバックを無効にする

ピンバックとは、他のブログであなたのウェブサイトを指すリンクが現れるときに作成される自動化されたコメントのことです。ブログ内に自分の記事をリンクしたときに作成される自己ピンバックもあります。

無駄なクエリが生成されスパムの数が増えるだけで、これらを無効にすることをお勧めします。特にトラフィックの多いウェブサイトはそうですが、WordPressサイトのコール回数は少ないほどいいです。それに、自己ピンバックは迷惑に違いありません。ピンバックを無効にするには、以下の手順に従ってください。

ステップ1他のブログからのピンバックを無効にする

WordPressダッシュボードで、「設定」→「ディスカッション」にアクセスします。「ディスカッション設定」で、「他のブログからの通知(ピンバック・トラックバック)を受け付ける」のチェックボックスをオフにします。

WordPressにてピンバックを無効にする

WordPressにてピンバックを無効にする

ステップ2:自己ピンバックを無効にする

自己ピンバックを無効にするには、無料のNo Self Pingsプラグイン及び、Perfmattersなどのプレミアムプラグインを使用することができます。

Perfmattersを使用し自己ピンバックを無効にする

Perfmattersを使用し自己ピンバックを無効にする

あるいは、ご利用のWordPressテーマのfunctions.phpファイルに次のコードを追加することによりも自己ピンバックを無効にすることができます。なお、WordPressテーマのソースを誤って編集するとウェブサイトが壊れる恐れがありますので、ご注意ください。ヒントですが、無料の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' );

ブログフィードの投稿数を制限する

ブログフィードはホームページであるか、個別のページであるかにかかわらず、サムネイルが50個も同時に読み込まれるのはよくありません。トラフィックの多いブログの方にとっては、ホームページはウェブサイトの最も重要なページであり、速く読み込まれる必要があります。リクエストとメディアの数が少ないほど、パフォーマンスは向上します。

これはページネーションが発明された理由です(下記参照)。ページネーションはブログフィードの最後に表示されるもので、クリックすると次のページにアクセスできます。通常は数字ですが、「次へ/前へ」と表示される場合もあります。ご利用のWordPressテーマにはすでにカスタムのページネーションが組み込まれているでしょう。

ページネーション

ページネーション

デフォルトではWordPressはWordPressの新規インストールの制限を10件に設定していますが、このデフォルト設定は数え切れないほど何度も変更されてきました。したがって、ご利用の値をご確認ください。当社の推進は8~12件の投稿です。Kinstaのブログのホームページでは12件を使用しています。

設定はWordPress管理ダッシュボードの「設定」→「表示設定」にあります。アクセスした後に、「1ページに表示する最大投稿数」の値を変更します。

WordPressのブログフィードの投稿数を制限する

WordPressのブログフィードの投稿数を制限する

キャッシュは重要である理由について

キャッシングは明らかにWordPressをスピードアップする最も重要で最も実施しやすい方法の一つです!しかし、キャッシングの使い方を説明する前に、まずキャッシングの概要とその種類を理解しておきましょう。

キャッシングとは?

要するに、WordPressウェブサイトの各ウェブページを訪問するには、サーバーへのリクエスト、そのリクエストのサーバーによる処理(データベースクエリなどを含む)と、処理後の結果がサーバーによりユーザーのブラウザへ送信されることが必要です。結果は外観を特定するファイルと要素を含むウェブサイトのことだす。

たとえば、ヘッダー、画像、メニュー、ブログがあるとします。サーバーはこれらすべての要求を処理する必要があるため、ウェブページ全体が読み込まれるまでには時間がかかります。

それがWordPressのキャッシングプラグインが登場するところです。キャッシングは、ファイルを構成に応じてディスクまたはRAMに保存するようにサーバーに指示します。したがって、過去に配信したのと同じコンテンツを記憶し複製することができます。基本的には、ページビューを生成するのに必要な作業量を減らします。その結果、ウェブページはキャッシュから直接に読み込まれると、はるかに速くなります。

その他のメリットは例えば:

  • サーバーのリソース使用量が減ります:リソース使用量が少ないとウェブサイトが速くなるため、スピードにつながるメリットです。それに、サーバーへの負担も少なくなります。メンバーシップサイトなどの非常に動的なサイトの場合には、またはキャッシュから配信できるものとできないものを特定する場合には、非常に重要です。
  • TTFBが低くなります: キャッシングはTTFBを下げる最もしやすい方法の一つです。実は、当社の試験ではキャッシングは通常にTTFBを最大90%減らします。

キャッシングの種類

キャッシングは、一般的に使用されるアプローチが2種類あります。

  1. サーバーレベルでのキャッシング
  2. プラグインでのキャッシング

1. サーバーレベルでのキャッシング

サーバーレベルでのキャッシングは、エンドユーザーにとっては、最もしやすいアプローチの一つです。この場合にはキャッシングをWordPressホスティング会社に任せます。Kinstaでは、ソフトウェアレベルまたはサーバーレベルで自動的に行われる次の4種類のキャッシュを利用しております。

つまり、複雑で使用し難いキャッシングプラグインを使わずにすみます。「2020年の最高のキャッシングプラグイン」を検索せずに、より重要な仕事集中することができます。👏

ページキャッシュは、標準のWordPressで何も設定しなくてもすぐに機能するように設定されています。触らなくても結構です!WordPressウェブサイトを起動するだけで、ページキャッシュが始まります。

WooCommerce及びEasy Digital Downloadsなどの電子商取引サイトを対象にもキャッシュルールをご用意しております。デフォルトでは、カート、マイアカウント、チェックアウトなど、キャッシュされるべきではない特定のページはキャッシュから除外されます。woocommerce_items_in_cartクッキーまたはedd_items_in_cartクッキーが検出されると、ユーザーはキャッシュを自動的にバイパスすることにより、スムーズなチェックアウトプロセスを保証しております。

管理ツールバーを使用することによりWordPressウェブサイトのキャッシュをいつでもクリアできます。

キャッシュをクリアするWordPress管理者ツールバー

キャッシュをクリアするWordPress管理者ツールバー

MyKinstaダッシュボードにも統合されている為、「ツール」をクリックし、「キャッシュをクリア」をクリックするだけです。

WordPressウェブサイトのキャッシュをクリアする

WordPressウェブサイトのキャッシュをクリアする

2. プラグインでのキャッシング

ホスティング会社がキャッシュを提供していない場合は、サードパーティ製のWordPressキャッシングプラグインを使用することができます。経験からいうと、次のいずれかをお勧めします。

  1. WP Rocket(プレミアム)
  2. Cache Enabler(無料)
  3. W3 Total Cache(無料)

詳細については、当社のWordPressキャッシングプラグインについての記事をご参照ください。

KinstaではWP Rocketを完全にサポートしています! 当社の内蔵キャッシュと競合するため、通常はキャッシングプラグインを許可しません。ただし、WP Rocket 3.0以降をKinstaのサーバーで実行している場合には、そのページキャッシュ機能は自動的に無効にされます。

これにより、Kinstaのお客様には当社の高速なサーバーレベルキャッシングをご利用いただける一方、WP Rocketが提供する素晴らしい最適化機能もご利用いただけます。

キャッシングがあった方がいいかない方がいいか?

キャッシュはどの程度の影響があるのでしょうか。

体的な速度とTTFBの両方への影響を確認できる為にKinstaのサーバーレベルのキャッシュで複数の試験を行いました。、

キャッシング無し

まずキャッシュを無効にし、Pingdomで5つの試験を実行し、その平均をとりました。

キャッシュなしでのスピードテスト

キャッシュなしでのスピードテスト

キャッシング無しでのTTFB

キャッシュの有無によるTTFBの違いに注意することも重要です。Pingdomの帯グラフの黄色い「待機」という帯はTTFBのことです。ご覧のとおり、キャッシュ無しでのTTFBは192ミリ秒です。x-kinsta-cacheヘッダーにMISSが表示されているため、キャッシュから配信されていないことがわかります。

キャッシング無しでのTTFB

キャッシング無しでのTTFB

キャッシングあり

次に、サーバーレベルでのキャッシュを無効にし、Pingdomで5つの試験を実行し、その平均をとりました。

キャッシングでのスピードテストt

キャッシングでのスピードテスト

ご覧のとおり、サーバーレベルのキャッシュにより、ページの読み込み時間が33.77%改善されました!特別な作業は全く必要ありませんでした。試験の対象になったウェブサイトはかなり最適化されていたものであるため、最適化されていない大規模サイトのならさらに大きな改善が見られるでしょう。

キャッシングでのTTFB

キャッシングを有効にすると、TTFBは35ミリ秒未満であることがわかります。x-kinsta-cacheヘッダーにHITが表示されているため、キャッシュから配信されていることがわかります。

キャッシングでのTTFB

キャッシングでのTTFB

WordPressホスティング会社が提供するキャッシングと同様にCDNキャッシングも非常に重要です。CDNについては、後ほど詳しく説明します。

WordPress caching can easily decrease your page load times by over 33%! ⚡ Check out the results.Click to Tweet

メンバーシップサイトでのキャッシングに関する課題

メンバーシップサイトには、絶えず変化するキャッシュ不可能なコンテンツまたはページが多数あります。メンバーのログインページ(サイトの規模によってはよく読み込まれる可能性があります)、デジタル商品やコースのチェックアウトページ、フォーラムなどは、一般的にキャッシュできないため、問題点です。

しかし、それだけではありません。標準のWordPressウェブサイトでは、ログインしたユーザーに対してもWordPressダッシュボードはキャッシュされません。作成者や管理者が数人しかいない場合はこれで問題ありませんが、ダッシュボードを使用しているメンバーが何千人もいる場合には、一人もサーバー上のキャッシュから配信できないため、すぐにパフォーマンスの問題が発生します。つまり、処理には力強いアーキテクチャが必要です。共有ホスティング会社なら、通常その期待に応えることが出来ません。

非常に動的なサイトのオブジェクトキャッシング

WordPressのメンバーシップサイトなら、完全に活用できない為一般的なキャッシング設定は不十分です。そこで、オブジェクトキャッシングが登場します

オブジェクトキャッシュはデータベースクエリの結果を保存し、次回その特定のデータが要求されるとデータベースにクエリを実行せずにキャッシュから配信できます。これによりPHPの実行時間が短縮され、データベースの負荷が減ります。メンバーシップサイトなら非常に重要なことです! WordPressでオブジェクトキャッシュを実装する方法は次のとおりです。

  1. W3 Total Cacheなどのサードパーティ製キャッシングソリューション
  2. Redis(推進)
  3. Memcached

KinstaはアドオンとしてのRedisを提供していおり、メンバーシップサイトのお客様に永続的なオブジェクトキャッシングを最大限に活用いただけます。

キャッシングを分析する

上記のx-kinsta-cacheヘッダーを覚えていますか? ホスティング会社またはキャッシングソリューションによっては、ヘッダーの名前が多少異なる場合があります。WordPressウェブサイトからリクエストが出されるたびに、そのヘッダーにはHIT、BYPASS、MISS、EXPIREDなどの値があります。これにより、キャッシュのパフォーマンスを確認できます。

ウェブサイトのできるだけ大半をキャッシュから配信する必要がある為、WordPressウェブサイトのキャッシュヒット率を上げることは重要です。Kinstaでは、MyKinsta分析ツールのデータKinstaキャッシュログを分析し、キャッシュ可能なGETリクエストをBYPASSしているキャッシュがあるかまたは排除可能なPOSTリクエストがあるか特定できます。

キャッシュコンポーネントスタック(下記参照)を使用すると、HIT、BYPASS、MISS、またはEXPIREDなどのリクエストの状態を確認できます。過去24時間、7日、または30日でデータをフィルタリングできます。

Kinstaのキャッシュコンポーネントスタック

Kinstaのキャッシュコンポーネントスタック

キャッシュコンポーネントのグラフではキャッシュ率が確認できます。キャッシュから配信するほど良いです。以下の例で示すように、例のWordPressウェブサイトのキャッシュヒット率は96.2%で、とてもいい結果です!

Kinstaのキャッシュコンポーネントのグラフ

Kinstaのキャッシュコンポーネントのグラフ

キャッシュバイパスのトップリストでは、キャッシュから配信されていないリクエストが確認できます。通常、CRONジョブ、admin-ajaxリクエスト、電子商取引チェックアウトページ、クエリ文字列、UTMパラメータなどがあります。

WordPressのキャッシュバイパスのトップリスト

WordPressのキャッシュバイパスのトップリスト

画像の最適化はマスト

画像の最適化も合計読み込み時間に大きな影響を与えるが実施しやすい工夫です。実はは、これはプラスではなく、マストです!

大きな画像はウェブページのスピードを落とし、ユーザーエクスペリエンスが悪化します。画像の最適化とは、プラグインまたはスクリプトを使用しファイルサイズを圧縮することによりページの読み込み時間を改善することです。圧縮は非可逆圧縮と可逆圧縮の2種類があります。

HTTP Archiveによると、2019年8月の時点で、画像はウェブページの全体的なページの重さの平均34%を占めています。したがって、最適化するのがはるかにしにくいビデオの次に、最適化を始めるべきところはやはり画像です! JavaScript、CSS、Fontsよりも重要です。皮肉なことに、画像最適化は最もしやすい仕事の一つである一方、ウェブサイト所有者の多くはこれを見逃しています。

1ページあたりの平均バイト数(KB)

1ページあたりの平均バイト数(KB)

2017年12月に、画像は全体的なページの重さの54%も占めていました。Web全体で、画像の最適化が進んでいるようです!しかし、34%は無視できない数字です。ウェブサイト上にビデオコンテンツのない方は一番苦しんでいるのは明らかに画像でしょう。

Images make up on average 34% of a web page's overall weight. 😮 Optimize them!Click to Tweet

バランスを見つける(ファイルサイズと画質)

画像を書式設定する主な目的は、最小ファイルサイズと納得できる画質のバランスを見つけることです。これらの最適化を実行する方法は複数あります。最も一般的な方法の一つは、WordPressにアップロードする前に画像を圧縮することです。圧縮はAdobe PhotoshopやAffinity Photoなどのツール、またはGoogleの新規オンラインアプリSquooshを使用することによりできます。ただし、プラグインを使用して自動的に実行することもできる為、後程詳しくご説明します。

考慮すべき2つの主な項目は、ファイル形式と使用する圧縮種類です。ファイル形式と圧縮種類の正しい組み合わせを選択することにより、画像のサイズを最大5倍まで減らすことができます。最も効果的なものを探し出すには、各組み合わせを試してみる必要があります。

画像の修正を始める前に、最適なファイルタイプを選択しましょう。使用可能なファイルタイプはいくつかあります:

  • PNG: 高画質の画像を生成しますが、ファイルサイズも大きくなります。可逆圧縮の画像形式として作成されましたが、非可逆な場合もあります。
  • JPEG非可逆圧縮も可逆圧縮も使用しています。画質とファイルサイズのバランスがとれるように画質レベルを調整できます。

カラフルな画像にはJPEG(またはJPG)を使用し、シンプルな画像にはPNGを使用することは理想的です。

GIFはどうでしょうか? アニメーションGIFは楽しいですが、ウェブパフォーマンスを低下させます。GIFの多くは1 MB以上もする為、ソーシャルメディア及びSlackのみで使用した方が良いでしょう。どうしてもブログの記事でGIFを使用したい方は、アニメーションGIFの圧縮方法をご確認ください。

圧縮の画質とサイズ

以下は画像を圧縮しすぎた場合の例です。1つ目の画像は非常に低い圧縮率を使用しているため、最高の画質が得られますが、ファイルサイズは大きくなります。2つ目は、非常に高い圧縮率を使用しているため、非常に低画質の画像になりますがファイルサイズは小さくなります。 注:元の画像は2.06 MBです。

低圧縮(高画質)のJPG:590 KB

低圧縮(高画質)のJPG:590 KB

高圧縮(低画質)のJPG:68 KB

高圧縮(低画質)のJPG:68 KB

ご覧のとおり、上記の最初の画像は590 KBです。一枚の写真だけには大きすぎます!一般的には、ウェブページの全体的なページの重さは1~2 MB未満であることが最適です。590 KBはその4分の1もします。2番目の画像は醜いですが、サイズは68 KBのみです。 圧縮率(画質)とファイルサイズの中庸を選択すればよいでしょう。

そこで、画像を中程度の圧縮率で再び圧縮しました。ご覧の通り、画質はきれいで、ファイルサイズは高解像度の写真なら納得できる151 KBです。元の写真の低圧縮版より約4倍軽いです。Kinstaでは最高のパフォーマンスを得るために、画像をできるだけ100 KB未満にしてみます。

中圧縮(高画質)のJPG:151 KB

中圧縮(高画質)のJPG:151 KB

非可逆圧縮と可逆圧縮

圧縮は、非可逆圧縮と可逆圧縮の2種類があります。

非可逆圧縮では、画像のデータの一部が削除されます。したがって、画質が低下する場合があり(画質の低下、またはピクセル化)、画像をどこまで圧縮するか注意しなければなりません。画質が悪化するためだけでなく、画像を一旦圧縮すると元に戻すことはできないためです。もちろん、人気である非可逆圧縮の大きな利点の一つは、ファイルサイズをかなり削減できることです

非可逆圧縮の比較

非可逆圧縮の比較

非可逆圧縮とは異なり、可逆圧縮はは画像の画質を悪化させません。何故そのようなことは可能かというと、圧縮の際に主に不要なメタデータ(画像を撮った装置により自動的に生成されたデータ)が削除されるからです。この方法の最大のデメリットは、ファイルサイズが大幅に縮小されないことです。言い換えれば、時間が経つにつれディスクの使用量が増えます。

両方の方法を実施してみて、自分にとってどちらが最も効果的かを見つける必要があるでしょう。ただし、ユーザーの大多数には、画質があまり悪化しないがサイズが70%も(場合によっては90%も)減る非可逆圧縮をお勧めします。ぺージ1枚に画像が15枚もあると、ウェブサイトの読み込み時間が大幅に改善されます!

画像圧縮プラグイン

上記のプロセスを完全に自動化できる素晴らしいWordPress画像圧縮プラグインが複数あります!当社のお勧めのプラグインは下記のとおりです。

  • Imagify(非可逆圧縮と可逆圧縮:外部画像最適化)
  • WP Smush(非可逆圧縮と可逆圧縮:外部画像最適化)
  • Optimole(非可逆圧縮と可逆圧縮:外部画像最適化)
  • EWWW Cloud (非可逆圧縮と可逆圧縮:外部画像最適化)
  • ShortPixel(非可逆圧縮と可逆圧縮:外部画像最適化)

画像最適化プラグインを選択するする最も重要なポイントは、圧縮と最適化をプラグインのサーバー上で外部で行うことです。これにより、ウェブサイトの負荷が軽減されます。上記のものはすべて外部サーバーを使用しています。

KinstaのウェブサイトではImagifyプラグインを使用しております。画像がWordPressのメディアライブラリにアップロードされる際に自動的に圧縮される為、心配する必要はありません。時間の経過とともに、画像圧縮の適切なレベルを理解できるようになります。 圧縮種類はノーマル、アグレッシブ、そしてウルトラの3種類があります。

Kinstaではアグレッシブモードを使用しており、画像にもよるが約60〜70%の節約になります。注:当社の画像はほとんど写真ではなくアイコンまたはイラストである為、JPEGよりもPNGを使用しております。

 

画像の圧縮による節約

画像の圧縮による節約

画像圧縮を使用することによりウェブサイトのスピードがどこまで改善するかは、画像の元のサイズと圧縮後の状態により異なります。ただし、当社が行ったスピードテストでは、高品質の画像圧縮ソリューションのおかげでページの読み込み時間が80%以上短縮される場合があることがわかりました。

遅延読み込み

画像の多い場合は、遅延読み込みを検討する価値があります。遅延読み込みは、表示されるコンテンツのみを読み込み、残りのコンテンツのダウンロードとレンダリングを遅らせる最適化手法です。

WordPressで遅延読み込み採用する方法についてはこちらのガイドをご参照ください。コメントのGravatarアイコンの多いブログの投稿なら、特に重要です。または、Googleも遅延読み込みの公式勧告を発表したばかりです。

画像最適化のその他の工夫

以下は画像最適化のその他の便利な工夫です。

  • 列またはDIVの幅だけに合わせたサイズの画像をアップロードする時代は終わりました。レスポンシブな画像はWordPress(バージョン4.4以降)では基本設定のままで利用可能で、モバイルのユーザーには自動的にサイズを減らした画像が表示されます。
  • SVGも画像を保存する便利な方法です。Kinstaのウェブサイトの手描きのイラストはすべてSVG(ベクトル)です。SVGは通常ファイルサイズが小さくなりますが、必ずしもそうとは限りません。WordPressウェブサイトでSVGを使用する方法についてのチュートリアルも是非ご確認ください。
  • 画像内にテキストを配置する代わりにアイコンフォントを使用しましょう。アイコンフォントの方はスケーリングしても見た目がきれいで、スペースの使用量も少ないです。フォントジェネレータを使用することにより、さらに最適化することができます。フォントジェネレータを使用し、アイコンフォントファイルのサイズを97.59%減らした実績をご参照ください。

データベースの微調整

次はWordPressデータベースを微調整する工夫についてです。自動車も時間が経つにつれ劣化する同様にデータベースもメンテナンスする必要があります。

特に、クエリが多く生成されるためMySQLデータベースから情報を取得する際の待ち時間が長くなるメンバーシップサイトは、注意が必要です。理由は、これらのサイトには動的なコンテンツとデータが多いこと、またはナビゲーション用に数多くの検索クエリまたはWP_Queryが使用されることでしょう。

言うまでもありませんが、データベースに対して継続的にクエリを実行している同時ユーザーも多数います。

InnoDB MySQLストレージエンジンを使用する

古いウェブサイトの多くではデータベースにまだMyISAMストレージエンジンが使用されています。近年、InnoDBの方はパフォーマンスもいいし、信頼性も高いです。

InnoDB is like synthetic oil, whereas MyISAM is settling for regular. ⛽Click to Tweet

MyISAMと比較したInnoDBのメリットは以下の通りです。

  • InnoDBには行レベルのロックがあり、MyISAMにはテーブルレベルのロックしかありません。これにより、クエリの処理速度が向上します。
  • InnoDBには外部キー(RDBMS)とリレーションシップの制約のサポートを含む、参照の整合性といものがあり、MyISAMにはありません(DMBS)。
  • InnoDBはトランザクションをサポートしています。つまり、コミットしてロールバックすることができます。MyISAMはトランザクションをサポートしません。
  • InnoDBは自動回復のためにトランザクションログを使用している為、信頼性が高いです。MyISAMはトランザクションログを使用しません。

ご利用のストレージエンジンはInnoDBであるかMyISAMであるか悩んでいる方は、新しいWordPressウェブサイトをお持ちの場合にはInnoDB MySQLストレージエンジンの可能性が高いです。しかし、古いWordPressウェブサイトをお持ちの場合には、確認する価値があるでしょう。MyISAMとInnoDBのテーブルを混在したウェブサイトもあります。その場合は統一するだけで改善が見られます。

確認するには以下のステップに従ってください。

ステップ1

phpMyAdminにログインしてMySQLデータベースをクリックします。

phpMyAdminのデータベース

phpMyAdminのデータベース

ステップ2

簡単に検索するか、「種類」の列で並べ替えると、テーブルが使用しているストレージエンジンの種類を確認できます。以下のでは、2つのテーブルがまだMyISAMを使用していることがわかります。

MyISAMのデータベーステーブル

MyISAMのデータベーステーブル

見つけものをInnoDBに移動します。この作業をできればホスティング会社に依頼した方がベストです。Kinstaでは、すべてのお客様のデータベーステーブルがマイグレーションチームにより自動的にInnoDBに変換されます。

しかし、以下のチュートリアルに従ってMyISAMテーブルをInnoDBに手動で変換することもできます。

固定ページおよび投稿のリビジョンを削除または制限する

WordPressで固定ページおよび投稿を保存するたびに、リビジョンというものが作成されます。下書きのものでも、公開済みのものでもそうです。リビジョンは過去のコンテンツ内容に戻したいという時に便利です。

WordPressのリビジョン

WordPressのリビジョン

ただし、リビジョンはWordPressウェブサイトのパフォーマンスを低下させる場合もあります。大規模なサイトでは、リビジョンはデータベース内の何千行にもなり、中には不要なものもあるでしょう。行数が多いほど、データベースのサイズが大きくなり、ストレージスペースが消費されます。インデックスが発明されたのはこのためですが、それでもこの課題にWordPressウェブサイトが苦しんでいることがあります。処理方法はいくつかあります。

1. 古いリビジョンを削除する

固定ページと投稿の多い古いWordPressウェブサイトをお持ちの場合は、そろそろクリーンアップして古いリビジョンを削除する時間でしょう。MySQLでも実施できますが、ウェブ上には悪いコードスニペットが多い為、まずウェブサイトのバックアップを取って、WP-Sweepなどの無料のプラグインを使用することを勧めます。

当社のスタッフの大好きにWP Rocketプラグインにもリビジョンを削除するデータベース最適化機能があります。

WP Rocketデータベース最適化

WP Rocketデータベース最適化

WP-CLIが詳しい方は、以下の便利なコマンドも使用できます。

データベースにあるリビジョンの数を把握するには、SSH経由でご利用のサーバーにログインし、次のコマンドを実行します。

wp revisions list

WP-CLIにてのリビジョンの数

WP-CLIにてのリビジョンの数

エラーが発生した場合は、まず以下のコマンドを使用し、wp-revisions-cliパッケージをインストールする必要があります:

wp package install trepmal/wp-revisions-cli

その後、次のコマンドを実行してリビジョンを削除できます:

wp revisions clean

2. リビジョンの数を制限する

Kinstaでも実施しているもう1つのアプローチは、投稿または固定ページ毎に保存できるリビジョンの数を制限することです。特に、記事を頻繁に更新している場合には、その値を10などに設定することによりリビジョンが手に負えなくなりません。

リビジョン数を制限するには、wp-config.phpファイルに次のコードを追加します。以下のコードは ‘ABSPATH’の上に挿入する必要があります。そうしないと機能しません。データベースに保存しておきたいリビジョン数に合わせて数値を変更しても構いません。

define('WP_POST_REVISIONS', 10);

wp-config.phpにて投稿のリビジョン数を制限する

wp-config.phpにて投稿のリビジョン数を制限する

または、Perfmattersなどのプラグインを利用し、リビジョンの数を制限することもできます。

Perfmattersプラグインで投稿のリビジョン数を制限する

Perfmattersプラグインで投稿のリビジョン数を制限する

3. リビジョン機能を無効にする

最後になりますが、ウェブサイトのリビジョン機能を完全に無効にすることもできます。この対策を実施する方は、まず1項の手順に従いリビジョンを削除した上でリビジョン機能を無効にしてください。そうするとデータベースには古いリビジョンが残らず、新しいものは追加されません。

リビジョン機能を無効にするには、wp-config.phpファイルに次のコードを追加します。以下のコードは ‘ABSPATH’の上に挿入する必要があります。そうしないと機能しません。

define('WP_POST_REVISIONS', false);

wp-config.phpにて投稿のリビジョン機能を無効にする

wp-config.phpにて投稿のリビジョン機能を無効にする

または、Perfmattersなどのプラグインを利用し、リビジョン機能を無効にすることもできます。

Perfmattersプラグインで投稿のリビジョン機能を無効にする

Perfmattersプラグインで投稿のリビジョン機能を無効にする

wp_optionsテーブルと自動読み込みデータを整理する

WordPressとデータベースの総合パフォーマンスなら、wp_optionsテーブルは見落とされがちです。特に大規模のウェブサイトでは、サードパーティ製プラグイン及びテーマにより残された自動読み込みデータのせいでクエリ時間が遅くなることがあります。当社のチームがこの異常を経験するのはほぼ毎日のことです!

wp_optionsテーブルには、WordPressウェブサイトのあらゆるデータがあります。例えば:

  • サイトURL、ホームURL、管理者メールアドレス、デフォルトのカテゴリ、ページごとの投稿数、時間の形式など
  • プラグイン、テーマ、ウィジェットの設定
  • 一時的にキャッシュされたデータ
WordPressデータベースにてのwp_optionsテーブル

WordPressデータベースにてのwp_optionsテーブル

このテーブルには、以下の項目(列)があります:

  • option_id
  • option_name
  • option_value
  • autoload(パフォーマンスの観点ではここはポイントです。)
自動読み込みデータ

自動読み込みデータ

wp_optionsテーブルについて理解しておくべき重要なポイントの一つは、autoload (動読み込み)列です。これには、yesまたはnoの値(フラグ)があり、 wp_load_alloptions() 関数にそのデータが読み込まれるかを制御します。自動読み込みデータは、WordPressウェブサイトの各ページに読み込まれているデータのことです。考え方は、特定のスクリプトがウェブサイト全体に読み込まれないようにする手順と同様です。autoload属性は、開発者向けに「yes」の基本設定になっていますが、各プラグインが各ページにそのデータ全体を読み込む必要はありません。

WordPressウェブサイトが遭遇する可能性がある問題は、wp_optionsテーブルに大量の自動読み込みデータがあるときに、WordPressウェブサイトの異常が発生する場合があります。一般的な理由は以下の通りです。

  • あるプラグインが「no」に設定すべきなのに、データが自動読み込みされています。お問い合わせプラグインがその分かりやすい例でしょう。本当に各ページでデータを読み込むべきでしょうか。それともお問い合わせのページのみで十分でしょうか。
  • あるプラグインまたはテーマは既にWordPressウェブサイトから削除されましたが、関連のオプションはまだwp_optionsテーブルに残っており、リクエスト毎に不要な自動読み込みデータに対するクエリが実行されています。
  • プラグインまたはテーマの開発者は、独自のテーブルを利用するのではなく、wp_optionsテーブルにデータが読み込まれます。開発者には追加のテーブルを作成しないプラグインがいいと言っている人もいる為、議論を双方の立場から見ることができるでしょう。一方、wp_optionsテーブルは数千行を処理するために設計されたものではありません。

自動読み込みデータはどれほどあれば多すぎるでしょうか。もちろん場合にもよりますが、300 KB~1 MBの程度は理想的です。3〜5 MBの範囲に近づくと、最適化したり自動読み込みのデータから除外したりできるものがあるでしょう。そして10 MB以上の場合には、すぐに対処する必要があります。必ずしも問題が発生することに限りませんが、手始めに実施してみましょう。

重要な課題である為、自動読み込みデータのトラブルシューティング手順についての個別のチュートリアルをご用意しております。ご確認ください。

When was the last time you cleaned up your wp_options table? Ya... we thought so. 😉 Get on it!Click to Tweet

一時データを削除する

オブジェクトキャッシュを採用していない限り、WordPressは一時レコードをwp_optionsテーブルに保存します。これらには有効期限が設定され、時間が経つにつれ消えるはずでが、必ずしもそうとは限りません。何千もの古い一時レコードがあるデータベースをいくつか見たことがあります。あるウェブサイトで、wp_optionsテーブルに695,000行以上を生成した破損した一時的なレコードがありました。恐ろしい!

wp_optionsテーブルの破壊した一時データ

wp_optionsテーブルの破壊した一時データ

一時データはデフォルトで自動読み込みされない為、ご注意ください。以下のようなクエリを実行し、自動読み込みの一時データがあるかどうかを確認します。

SELECT * 
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'

上記より安全で安全な方法は、wp_optionsテーブルから期限切れの一時データのみを削除するTransient CleanerDelete Expired Transientsなどの無料のプラグインを利用することです。一方、WordPressでは4.9で追加された新機能があり、その機能は期限切れの一時データを処理してくれる様です。皆様のウェブサイトでも自動的に行われているはずです。

WP Rocketにも、データベース最適化オプションの中に一時データを削除する機能もあります。

 WP Rocketで一時データを削除する

WP Rocketで一時データを削除する

WordPressセッションを削除する

cronジョブがシンクロしなくなり、きちんと機能しない為、セッションは適切に削除されないこともよく発生する課題の一つです。データベースに大量の_wp_session_行があることもあります。以下の例のウェブサイトのwp_optionsテーブルに300万行以上が表示されており、テーブルのサイズは600 MB以上もしました。

wp_optionsテーブルに数百万行がある事例

wp_optionsテーブルに数百万行がある事例

以下のようなクエリを実行し、この課題が発生しているかどうかを確認します。

SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'
wp_sessionの行

wp_sessionの行

これらは、ほとんどの場合だと、次のコマンドを実行し安全に削除できます。(本当はcronジョブがこれらを削除するはずでした。)

DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

不要の_wp_session_行を削除した後、テーブルには1,000行未満が残り、サイズは11 MBになりした。

削除後のWPセッション

削除後のWPセッション

該当ウェブサイトのMySQLのばらつきも改善されました。

MySQのWebトランザクション

MySQLのWebトランザクション

自動読み込みにインデクスを追加する

wp_optionsテーブルをクリーンアップするだけでは不十分な場合には、自動読み込み欄に「インデックス」を追加しましょう。インデクスを追加することにより自動読み込み欄がより効率的に検索されるようになります。10upのチームは、典型的な数の自動読み込みレコードを使用し、wp_optionsクエリに自動読み込みインデックスを追加するとパフォーマンスが改善することを示すためのwp_optionsテーブルの複数の試験を行いました。

wp_optionsクエリ時間

wp_optionsクエリ時間(画像出典:10up

以下のWP Bulletによる記事も必ずご確認ください。

WordPressの永続オブジェクトキャッシュにRedisを使用する

Redisはオープンソースのインメモリデータ構造ストアです。WordPressなら、Redisを使用しWordPressの独自のオブジェクトキャッシュにより生成された値を永続的に保存し、キャッシュされたオブジェクトをページ読み込み間に再利用できます。

Redisなどの永続オブジェクトキャッシュを使用すると、MySQLデータベースに同じオブジェクトに対して2回クエリを実行せずに、キャッシュされたオブジェクトを再利用できます。その結果、RedisはウェブサイトのMySQLデータベースの負荷を軽減し、ウェブサイトの応答時間を短縮し、トラフィックの変更に合わせてスケーリングできるようにします。

Redis

ページキャッシングを使用できない非常に動的なウェブサイト(WooCommerce、メンバーシップサイト、フォーラム、非常に多くのコメントのあるブログなど)なら、Redisなどの永続的なオブジェクトキャッシングを検討する価値があります。

Kinstaのお客様には、Redisアドオンをご利用いただけます。ホスティングプランにRedisを追加する方法についてはこちらをご参照ください。

Elasticsearchを使用しWordPress検索をスピードアップする

Elasticsearchはオープンソースの全文検索エンジンです。データの索引付けと検索を驚くほど速いスピードで行うために設計されたものです。

WordPressなら、Elasticsearchを使用しWordPressデータベースへのクエリをスピードアップすることができます。概要は、ウェブサイトのデータベースのコンテンツのインデックスを構築し、MySQLクエリが同じ検索を実行することができないほど速くElasticsearchでそのインデックスを検索することです。

Elasticsearch

時間とスキルのある非常に知識の豊富なWordPressとElasticsearchの開発者によっては、ElasticsearchはWordPressウェブサイトと統合することができます。ウェブサイトのWP_Queryが比較的標準である場合には、WordPress.orgから入手可能な10upによる無料のWordPressプラグインElasticPressをインストールすることによりもElasticsearch を統合できます。このプラグインはWP_Queryのオブジェクトと自動的に統合してMySQLではなくElasticsearchを使用してクエリ結果を生成します。

WP_Queryを多用するどのウェブサイトではElasticsearchが役に立ちます。役に立つ場合は例えば:

  • ナビゲーションの主要な手段は検索であるウェブサイト
  • サイト管理者が頻繁に注文のリストを検索する、注文の多いWooCommerceウェブサイト
  • 記事が多いためMySQLクエリの結果が納得できないほど遅いウェブサイト

Kinstaのお客様には、Redisと同様にElasticsearchアドオンもご利用いただけます。ホスティングプランにElasticsearchを追加する方法についてはこちらをご参照ください。

データベースを多用する不要な機能を無効にする

当たり前のことかもしれませんが、プラグインやデータの重要度の低いがデータベースを多用する機能を無効にすると、違いが出ます。

  • 人気のある投稿または関連投稿のウィジェットまたはプラグインは最悪です。ウェブサイト全体の重いクエリを使用しています。
  • あなたのサーバーを使用し画像を圧縮する画像最適化プラグイン。外部で画像を最適化するプラグインにしましょう。

Kinstaのブログにアクセスし各投稿の最後までスクロールダウンすると、「厳選された関連記事」があります。これらは当社のスタッフによって手動で選択され、投稿に貼り付けられます。これにより、クエリがほとんどなくなり、ウェブサイト全体のパフォーマンスが低下することはありません。確かに手間がかかりますが、表示される記事が管理できる為自動的に表示されるより効率良いでしょう。

WordPressの関連投稿

WordPressの関連投稿

上記ができるには、KinstaがAdvanced Custom Fieldsプラグインを使用し、手動でこれらのフィールドをブログの投稿タイプに割り当てました。これにより、関連するコンテンツを検索しブログの投稿に指定することができます(下記参照)。

関連投稿を指定する

関連投稿を指定する

絶対必要でない限り、ビュー数または投稿数のカウンターをウェブサイトに追加するプラグインを使用しない方がいいです。たとえば、フォーラム投稿内のユーザーのアバターの横にある「792投稿」または、フォーラム投稿の一覧の「5,243ビュー」などは避けてましょう。議論が長くなると、これらのカウンターはデータベースに大きな負担をかけます。原則として、カウンターの使用をできる限り避けましょう。

ソーシャルメディアのカウンターもそうです。たとえば、下記の例のウェブサイトでは、人気のあるSocial Warfareプラグインの応答時間が、その下の次のプラグインの30倍もします。キャッシングは有効になっていますが、このプラグインは明らかにパフォーマンスへの悪影響です。プラグインを無効にした後に読み込み時間とWordPress管理ダッシュボードの応答性が大幅に改善されました。

Social Warfareの読み込み時間

Social Warfareの読み込み時間

コンテンツ配達ネットワーク(CDN)を使用する

CDNは、単にコンテンツ配信ネットワークの略です。コンテンツ配信ネットワークは、画像、CSS、JavaScript、ビデオストリームなど、WordPressウェブサイトの静的な(時には動的な)コンテンツをホストするための世界中のサーバー(POPともいう)ネットワークです。

まず、全く違う目的のものなので、CDNをWordPressホスティング会社と混同しない方がいいです。CDNはホスティング会社の代替サービスではなく、ウェブサイトのスピードを向上させる追加のサービスです。最初から急速なKinstaであっても、CDNのご利用によりさらにスピードがさらに改善できます。

CDNの概要

CDNの考え方は何でしょうか。 たとえば、Kinstaでウェブサイトをホスティングする場合は、米国中部、ヨーロッパ、南米、アジアなどのデータセンターの場所を選択します。

たとえば、米国中央を選択するとします。その場合には、ウェブサイトが物理的にアイオワ州カウンシルブラフスの「ホストサーバー」に配置されていることになります。その場合ヨーロッパからのお客様がウェブサイトを訪れると、読み込み時間は例えばテキサス州のダラスのお客様の読み込み時間より長くなります。なぜでしょうか。

それは、データの移動距離が長くなるからです。これはレイテンシ(待ち時間)と言います。レイテンシとは、ネットワーク上でのデータの送信にかかる時間およびその遅延のことです。距離が遠いほど、レイテンシは長くなります。

CDNの種類

コンテンツ配達ネットワークは2種類があります。

  1. 通常のプル型CDN
  2. リバースプロキシCDN

通常のプル型DNは、コンテンツとメディアを完全にコピーしキャッシュしますが、クライアントからのリクエストが直接にホスティング会社行われます。例えばKeyCDNCDN77は通常のCDNです。

リバースプロキシCDNは少し違います。CDNとして働いていますが、入ってくるリクエストを傍受し、クライアントとホスティング会社の間の仲介サーバーの機能を果たします。例えばCloudflareSucuri はリバースプロキシCDNです。これは、DNSをホスティング会社ではなく直接これらのプロバイダを指すように設定する理由です。

リバースプロキシCDNの利点は、仲介サーバーとして機能するため、強力なウェブアプリケーションファイアウォールを提供し、悪質なトラフィックがWordPressウェブサイトとホスティング会社にアクセスすることを予防することです。欠点は、パフォーマンスの観点で通常のプル型CDNと比較すると少しオーバーヘッドがあることですが、パフォーマンス機能とセキュリティ機能が多いため、この欠点を無視できる意見もあります。

以下の例は、当社のお客様のウェブサイトでSucuriを有効にした前後の状態です。悪意のトラフィックが急激に減ったことが分かります。結論ですが、リバースプロキシサービスはホスティング費用を節約するのに便利です。

Sucuriを有効にした前後の状態

Sucuriを有効にした前後の状態

CDNのスピードテスト

WordPressキャッシングの利点については、前述しましたが、CDNキャッシングも非常に強力です。その理由はCDNにはホスティング会社よりもはるかに多くのサーバーロケーションがあることです。つまり、アセット(画像、JS、CSS)を訪問者のいる場所の近くにキャッシュし、超高速で配達することができます。

それでは、試験でも実施し、CDNのウェブサイトのスピードへの影響度を確認しましょう。

CDN無し

試験したウェブサイトはKinstaでホストされており、サーバーは物理的には米国のアイオワ州のデータセンターにあります。最初にPingdomのスピードテストを5件実施し、平均をとりました。(CDNは有効にしていない)注:CDNの真の力をお見せできる為、Pingdomのヨーロッパ ・イギリス・ロンドンのロケーションを使用しました。合計読み込み時間は1.03秒でした。

CDN無しでのスピードテスト

CDN無しでのスピードテスト

CDNあり

次に、CDNを有効にしPingdomで再び試験を5件実施しました。ヨーロッパ・イギリス・ロンドンのロケーションからの合計読み込み時間は585ミリ秒でした。つまり、CDNを使用することで、ページの読み込み時間を43.2%短縮することができました!すごいですね。

上記の劇的な改善の理由は、CDNにはロンドンにデータセンターがあり、すべてのアセットがそのロケーションにキャッシュされ、最小限の待ち時間で配達できることです。

CDN無しでのTTFB

Pingdomの帯グラフの黄色い帯は待機時間で、「最初の1バイトが到着するまでの時間」(TTFB)のことです。CDNを使用しないときの平均TTFBは約98ミリ秒でした。

CDN無しでのTTFB

CDN無しでのTTFB

CDNでのTTFB

CDNを有効にすると、アセットの平均TTFBは約15ミリ秒に短縮しました。つまり、CDNを使用することで、平均TTFBは84.69%改善しました。主な理由は、アセットがCDNのキャッシュから配達されていることです。

CDNでのTTFB

CDNでのTTFB

A CDN decreased our page load times by 43.2%! Check out why you should be using one. 🚀Click to Tweet

CDNを有効にする手順について

WordPressウェブサイトでCDNを有効にするのは難しいことではなく、とても実施しやすいことです!次の手順に従ってください。

ステップ1

CDNプロバイダを選択し、契約します。月料金の会社もデータ使用量をベースにした料金の会社もあります。ほとんどのプロバイダには料金計算ツールもあります。

ステップ2

通常のプル型CDNをご利用の方は、CDN EnablerWP RocketまたはPerfmattersなどの無料プラグインを使用することによりCDNをWordPressウェブサイトと統合できます。これらのプラグインは自動的にアセットをCDNにリンクします。つまり、コンテンツをCDNに入れる作業は一切なく、手間のかからない方法です!リバースプロキシCDNの方は、通常プラグインが必要ではありませんが、追加機能を有効にする必要がある場合があります。

Perfmattersを使用しWordPressでCDNを有効にする

Perfmattersを使用しWordPressでCDNを有効にする

Kinsta CDNを有効にする手順について

上記のCDNスピードテストの結果は印象的であったでしょうか。その試験ではKeyCDNを採用しました!そして、Kinsta CDNも同じく、34カ所以上のロケーションのあるHTTP/2とIPv6が有効になったコンテンツ配信ネットワークであるKeyCDNを採用しています。現在の配達リージョンはアメリカ、南アメリカ、ヨーロッパ、アフリカ、アジア、そしてオーストラリアです。

KinstaのCDNネットワーク

KinstaのCDNネットワーク

Kinstaのお客様には、各ホスティングプランを対象に無料のCDNバンドウィズをご用意しております。2つのステップの実施しやすい手順でKinsta CDNを有効にしましょう

ステップ1

まず、MyKinstaダッシュボードにログインします。該当のウェブサイトをクリックし、Kinsta CDNタブをクリックします。

Kinsta CDN

Kinsta CDN

ステップ2

次に「Kinsta CDNを有効にする」をクリックします。数分後、CDNが自動的に機能し始め、アセットは世界中のキャッシュから配信されます。以上です。😄

Kinsta CDNを有効にする

Kinsta CDNを有効にする

CDNのさらなる最適化

その他の検討する価値のあるCDNの最適化は例えば下記があります。

  • コメントが多ければ、gravatarにより生成されるリクエスが多いことがあります。gravatarはsecure.gravatar.comから読み込まれます。CDNから読み込まれるよう設定する方法については、こちらのチュートリアルをご確認ください。Kinstaのウェブサイトでこれを行っています。 👍
  • カスタムウェブフォントもGoogleフォントもCDN上にホストすることができます。ローカルフォントについての詳細なチュートリアルをご確認ください。
  • faviconをCDNから読み込まれるようにしましょう。たとえ影響度が低くても、すべてのリクエストは重要です。

メディアと電子メールを必要に応じてオフロードする

リクエストを生成するものはすべて、ウェブサイトのパフォーマンスに影響を与えます。何十万ものファイル及び大規模メディアのウェブサイトなら、これらを完全にオフロードした方が良いでしょう。オフロードは、CDNとは異なります。CDNを使用すると、元のデータはホスティング会社から消えずに残り、CDNにはその複数のコピーがあるだけです。

CDNアセットのキャッシュが期限切れになると、ホスティング会社のファイルの最新版を再クエリします。CDNは長期間ファイルをキャッシュすることを目的としていますが、POPが非常に多いため、再クエリがよく起こる場合があります。

メディアやファイルをオフロードすると、ホスティング会社から元のファイルを別の場所に移動します。したがって、ファイルはウェブサイト上にあるように見えますが、実は完全に別の場所にあります。そうすると、ホスティング会社クエリ数を減らすことに加えて、ディスクスペースも節約できます。

Amazon S3へのメディアをオフロードする

最も人気のあるオフロードソリューションの一つはAmazon S3です。Amazon S3はストレージソリューションであり、Amazon Web Servicesの多くの商品の一つです。追加のバックアップを必要とするまたは大きなファイル(ダウンロード、ソフトウェア、ビデオ、ゲーム、オーディオファイル、PDFファイルなど)を提供している大規模なウェブサイトに使用されるのは一般的です。Amazonは非常に信頼性が高いという実績があり、大規模なインフラストラクチャが用意されている為ストレージコストも極めて低いです。S3の顧客には例えばNetflix、Airbnb、SmugMug、Nasdaqなどがあります。

バルクストレージのサービスだある為、料金はWordPressホスティング会社よりも安いでしょう。AWSにメディアをオフロードすることは、経費を節約する素晴らしい方法であり、最初の1年間は無料です(最大5 GBのストレージ)。また、メディアへのリクエストはAmazonから配達されるため、WordPressウェブサイトの負荷が軽減され、読み込み時間が短縮されます。

WordPressメディアをAmazon S3にオフロードする手順については当社の詳細なチュートリアルをご確認ください。オフロードしたメディアでもCDNを使用することが可能で、両方の長所を生かすことができます。

Google Cloud Storageにメディアをオフロードする

Google Cloud Storageも人気のあるオフロードソリューションです。KinstaはGoogle Cloud Platformを基盤としている為、Googleの技術とインフラストラクチャーを特に尊敬しております。Googleはインフラストラクチャが大規模で、外レージはバルクストレージを提供している為、料金は極めて安いです。Googleのお客様は例えばSpotify、Vimeo、Coca-Cola、Philips、Evernote、Motorolaなどです。

Google Cloud Storage

WordPressメディアをGoogle Cloud Storageにオフロードする手順については当社の詳細なチュートリアルをご確認ください。

トランザクションメールとマーケティングメールをオフロードする

意識していない方が多いですが、電子メールもサーバーとサーバーのリソースに影響を与えます。電子メールを悪用すると、アカウントを一時停止するホスティング会社(特に共有ホスティング会社)さえあります。大量のメールを送信しようとしている方にはこれは特に問題です。この理由で、サードパーティのトランザクション電子メールプロバイダーが生まれ、多くのホスティング会社が標準ポートでの電子メール配信を完全にブロックしています。ご利用のホスティング会社を電子メール配信に使用することを当社も一切お勧めしません。

ニュースレターや大量の電子メールを送信している方には、以下の手段のぢちらかをお勧めします:

  • WordPressの一分でないサードパーティのプロ向け電子メールマーケティングソフトウェアを使用すること
  • WordPressと組み合わせてトランザクション電子メールサービスプロバイダ(HTTP、APIまたはSMTP)を使用すること

サードパーティのサービスを使用することのその他の利点は次のとおりです:

  • 電子メールの配信性が改善されます。メールプロバイダーが得意な作業をそのプロバイダーに任せましょう。
  • バックリストされる可能性がへります。
  • DMARCレコードが設定できないホスティング会社もあります。

電子メールマーケティングツール

マーケティング用の電子メールは例えば、ニュースレター、新規商品および品機機能のお知らせ、キャンペーン、イベントへの招待、オンボーディングのリマインダーなどです。

トランザクション電子メールサービス

トランザクション電子メールは例えば、WooCommerceまたはEDDからの購入の領収書、アカウント作成のお知らせ、出荷のお知らせ、アプリのエラーメッセージ、パスワードのリセットなどです。Kinstaは高い配信性を保証するためにサードパーティのSMTPプロバイダを使用しています。ただし、ボリュームにもよりますが、この作業をオフサイトに移動させるようにお勧めします。お勧めできるトランザクションメールサービスは以下のとおりです。

ボトルネックと遅いプラグインの特定

次に、WordPressウェブサイトのボトルネックをの特定及び処理方法についてご説明します。

遅いプラグインとデータベースクエリを特定するにNew Relicを使う

遅いデータベースクエリとプラグインを正確に特定するのに役立つ、優れたツールが市場上にいくつかあります。KinstaはNew Relicを採用しています。New Relicは、ウェブサイトの詳細なパフォーマンス分析データが取得できるPHP監視ツールです。

Kinstaのお客様はMyKinstaダッシュボードを使用し、ご自分のNew Relicライセンスキーを追加することさえできます。

New Relicトラッキング

New Relicトラッキング

ただし、New RelicはウェブサイトにJavaScriptを追加する為、パフォーマンスに影響を与えます。十分に注意をしてNew Relicをご利用ください。パフォーマンスのトラブルシューティングが必要な場合に有効にし、完了後には再び無効にすることをお勧めします。

遅いプラグインを特定する

WordPressのあるプラグインのせいでウェブサイト全体のスピードが落ちるときの異常現象はプラグインの用途により異なりますが、遅いプラグインはWordPressウェブサイトのすべてのページに影響を与える場合が多いです。例えば、下記の画像に表示されているウェブサイトの場合には、ウェブサイトのすべてのフロントエンドページのスピードが落ちました。New Relicのウェブサイトのプラグインのパフォーマンスについてのレポートは次のとおりです。

New RelicのWordPressプラグインについてのタブ

遅いプラグイン

データを見ると、adinjectorプラグインが次に遅いプラグインの15倍以上の時間を消費していることがすぐわかります。

このようなデータが表示された場合には、プラグインのコーディングが不適切であるか効率が悪いかと判断し、プラグインをすぐに無効にしたくなります。場合により、そうした方がいいですが、 にそうとは限りません。プラグインの設定ミス、遅いデータベース、応答の遅い外部リソースなどにより、プラグインが消費する時間が長くなる場合があります。

したがって、応答の遅いプラグインが表示されるときに、New Relicのその他の画面も確認し、追加の情報を取得した方が良いでしょう。プラグインを無効にする前に、トランザクション、データベース、および外部リソースをすべて確認しましょう。

データベースの負担が多い為、ウェブサイト全体のスピードが落ちる

最適化されていないデータベースはWordPressウェブサイト全体のスピードに悪影響を与えます。処理方法については、上記に述べました。このデータベース関連の速度の低下は、New Relicでは次の2つの場所に表示されす:

  • まず、概要画面では、MySQLアクティビティの量が多すぎます。
  • 次に、「データベース」タブでは、1つ以上のデータベーステーブルに時間がかかりすぎます。

概要画面から始めますが、データベースが苦戦しているウェブサイトは次のようになります:

New Relicの概要画面を見ると、データベースの速度低下がすぐに特定できます

ウェブトランザクション時間

異常が発生しているデータベーステーブルまたはクエリを特定するには、「データベース」タブにアクセスします。

New Relicのデータベースタブをみると、遅いデータベーステーブルとクエリを正確に特定できます。

MySQL一覧

「データベース」タブには、最も時間のかかるテーブルとクエリの種類が表示されます。リストの項目を一つ選択すると、サンプルクエリなどの詳細情報が確認できます。

遅いクエリの詳細情報を確認することにより、データベースのどこを探せばいいか分かります。

遅いクエリ – wp_optionsテーブル

上記に例では、wp_optionsテーブルの自動読み込みデータで異常が発生していることが分かります。なお、これは上記ご説明したことがあります。wp_optionsテーブルを簡単に分析すると、約250 MBのデータもこのテーブルから自動読み込みされていることが確認できました。このウェブサイトは間違いなくデータベースのメンテナンスと最適化が必要でしょう。

New Relicを使用しWordPressウェブサイトのパフォーマンス異常のデバッグを実施することについては、当社の詳細なチュートリアルをご参照ください。

無料のQuery Monitorプラグインを使用する

無料のWordPressプラグインQuery Monitorも利用できます。遅いデータベースクエリ、AJAXの呼び出し、REST APIリクエストなどの特定とデバッグの機能があります。さらに、このプラグインは、スクリプトの依存関係、ページ生成中に発生したWordPressフック、ホスティング環境の詳細、現在のページが満たす条件付きクエリタグなどのウェブサイトの詳細情報も報告します。

」WordPressのすべてのクエリ

Query MonitorプラグインにてのWordPressのクエリ

このプラグインはJohn Blackbourn により開発されました。彼は現在Human Madeの開発者であり、 以前はWordPress.com VIPで働きました。つまり、WordPressに非常に詳しい人です。Query Monitorは、2013年にWordPressのプラグインディレクトリに追加され、現在10,000以上のアクティブなインストールがあります。開発プラグインの割りに素晴らしいことです。プラグインが5つ星のうち5と評価され、開発者の間で明らかに人気があります。

Query Monitorの使用方法については、当社のチュートリアルをご参照ください。

本番サイトを触らずステージングサイトを採用する

ステージング環境がなければ、どうすればいいか分かりません。パフォーマンス課題を処理する際に不可欠なものです。幸いなことにKinstaではワンクリックステージング環境が利用可能になっております。ご利用のWordPressホスティング会社がステージング環境を提供していない場合には、WP Stagingなどのプラグインを使用することもできますが、それほど使用しやすくありません。

WordPressのステージング環境

WordPressのステージング環境

ステージング環境が立ち上がった後、すべてのプラグインを無効にします。ウェブサイトのコピーである為、本番サイトを破壊する恐れはありません。異常を絞り込む最もしやすい方法の一つです。単にプラグインにアクセスし、すべてを選択し、一括オプションの「無効にする」オプションを選択します。

WordPressのすべてのプラグインを無効にする

WordPressのすべてのプラグインを無効にする

これを実行した後、New RelicまたはQuery Monitorで応答時間を監視し、結果を確認できます。以下のこの例では、応答時間がすぐに通常に戻ったため、異常原因はプラグインの一つであることがわかりました。次に、原因が見つかるまでプラグインを一つずつ再度有効にします。

通常の応答時間

通常の応答時間

異常の原因となっていたプラグインを有効にしたときの例を示します。読み込み時間(ウェブトランザクション時間)がすぐに上がりました。

再びの長い応答時間

再びの長い応答時間

スピード低下の原因となっているプラグインが特定できた後は、どうすればいいでしょうか?次をお勧めします:

  1. ご利用のプラグインとテーマは最新バージョンでないと、更新してください。
  2. 該当のプラグイン及びテーマの開発者にお問い合わせください。
  3. 同じ用途の代替プラグインを探してみてください。
  4. PHPのご利用のバージョンが異常の原因である場合もあります。PHPエンジンをより低いバージョンに切り替え、該当のプラグイン及びテーマは正常に機能しているか確認してください。

または、WordPress開発者を採用し異常を処理してもらうこともできます。パフォーマンス異常なら、WP BulletのMike Andreasonをお勧めします。彼は、パフォーマンスの最適化を専門とする、フルタイムのCodeableの開発者です。Kinstaの多くのお客様のウェブサイトを次の段階に進める作業をサポートしたことがあります。

WP Bullet使用前・使用後

WP Bullet使用前・使用後

エラーロブを確認する

エラーログを確認する作業は確かに楽しくありませんが、WordPressプラグイン関連のパフォーマンス課題が明らかになります。Kinstaのお客様は、MyKinstaダッシュボードを使用することによりエラーログ、キャッシュログ、アクセスログなどを簡単に確認できます。

MyKinstaにてのエラーログ

MyKinstaにてのエラーログ

wp-config.phpファイルにコードを追加することによりもエラーログを有効にすることができます。まず、SFTP経由でウェブサイトにアクセスします。次にwp-config.phpファイルを編集できるようにダウンロードします。注:最初にこのファイルのバックアップを必ず作成してください。

wp-config.phpファイルをダウンロードする

wp-config.phpファイルをダウンロードする

/* That's all, stop editing! Happy blogging. */を探し、その直前に次を追加します(下記を参照):

define( 'WP_DEBUG', true );
WP_DEBUG

WP_DEBUG

wp-config.phpファイルに既に上記のコードが存在しているが、「false」に設定されている場合には、単に 「true」に変更してください。これでデバッグモードが有効になります。注:存在している場合には、WordPress管理画面にも警告またはエラーが表示されます。

次に、WP_DEBUG行の直後に次のコードを追加することにより、デバッグログがすべてのエラーをあるファイルに送信するようにします(下記を参照):

define( 'WP_DEBUG_LOG', true );
WP_DEBUG_LOG

WP_DEBUG_LOG

変更を保存し、ファイルをサーバーに再アップロードします。エラーは/wp-content/フォルダにあるdebug.logファイルに記録されます。何らかの理由でこのファイルが表示されない場合には、ご自分で作成できます。

MyKinstaの分析機能を使用する

Kinstaのお客様には、MyKinstaの分析ツールの内蔵のパフォーマンス関連情報もご利用いただけます。

パフォーマンス監視セクションでは、PHP+MySQLの平均応答時間、PHPのスループット、AJAXの使用状況、平均アップストリーム時間のトップリストと最大アップストリーム時間のトップリストが確認できます。

PHP+MySQLの平均応答時間

ご自分のWordPressウェブサイトにアクセスする度に、ページのデータをコンパイルしクエリするにはPHPとMySQLが使用されます。このグラフは、キャッシュされていない動的リクエストに対するPHPエンジンとMySQLエンジンの平均応答時間を示しています。この応答時間を理解することにより速度低下の処理ができる場合があります。

パフォーマンス:PHP+MySQLの平均応答時間

パフォーマンス:PHP+MySQLの平均応答時間

PHPのスループット

スループットとは、アプリケーションが処理できる1秒あたりのトランザクション数を指します。このレポートでは、WordPressウェブサイトのPHPのスループットが表示されます。つまり、PHPアセットがリクエストされた回数が記載されます。

パフォーマンス:PHPのスループット

パフォーマンス:PHPのスループット

AJAXの使用状況

AJAXは、ポストバック及びページ全体の更新を必要とせずに、サーバー及びデータベースとの通信を実施するクライアントサイドのスクリプトです。WordPressなら、スピードテストでよく見かける内容です。AJAX関連のよくある異常は、プラグインのせいでAJAXの使用が急上昇することとバックエンドのCPUの異常です。

管理画面:AJAX使用状況

管理画面:AJAX使用状況

Admin-AJAXの使用状況の診断については、当社の詳細な記事をご参照ください。

MyKinstaの分析機能のAJAX使用状況レポートは、特定の期間中に特定のAJAXの使用の急増が発生しているかどうかを確認できるため、特に便利です。このグラフはadmin-ajaxリクエストの数を示しています。次に上記で述べた投稿の工夫を実施し、発生原因を絞り込むことができます。

AJAX使用状況

AJAX使用状況

PHP+MySQLの平均応答時間のトップリスト

このリストは、PHPとMySQLの平均応答時間のトップリストを示しています。これらの数値は1回限りのピークである可能性がある為、このリストを「最大アップストリーム時間のトップリスト」と比較することをお勧めします。

ダウンタイムまたはWordPressの異常に悩んでいますか。Kinstaは時間を節約するために設計されたホスティングソリューションです!当社のフィーチャーをご確認ください。
PHP+MySQLの平均応答時間のトップリスト

PHP+MySQLの平均応答時間のトップリスト

最大アップストリーム時間のトップリスト

アップストリーム時間とは、NGINX(およびアップストリームサーバー)がリクエストを処理して応答を送信するまでにかかる時間のことです。この時間はミリ秒単位の分解能で秒単位で測定されます。NGINXの測定についてはこちらをご参照ください。

最大アップストリーム時間のトップリスト

最大アップストリーム時間のトップリスト

ウェブサイトがハッキングされている恐れがある

パフォーマンスの異常が特定できない場合には、ウェブサイトがハッキングされている、マルウェアに感染している、またはDDoS攻撃を受けている可能性が非常に高いです。これはウェブサイトのスピードとWordPress管理ダッシュボードの反応性にさえ影響を与える場合があります。このような場合は、次をお勧めします:

  1. Cloudflare及びSucuriなどのプロキシサーバーとWAFを採用します。
  2. 上記のサービスを使用して不正なIPアドレスをブロックします。Kinstaのお客様はMyKinstaダッシュボードからもIPアドレスをブロックすることができます。
  3. ジオブロッキングも実装できます。極めて悪質のトラフィックを生成する国もあります。攻撃を受けている場合には、一時的または恒久的にその国全体をブロックする必要があるかもしれません。

エラーコード(HTTPステータスコード)を使用したトラブルシューティング

HTTPステータスコードとは、ウェブページの上部に貼り付けられるウェブサーバーからの短いメモのようなものです。ウェブページの一分ではなく、ページを表示するリクエストがサーバーにより受信されたときの状況を知らせる、サーバーからのメッセージです。課題を処理する際に不可欠なものです!

40以上のステータスコードもありますが、以下はWordPressユーザーがよく悩んでいるものについて述べます。

429: 「要求が多すぎる」 。ユーザーが短時間に大量の要求を送信送してきたときにサーバーにより生成されます(レート制限)。ボット及びスクリプトがウェブサイトにアクセスしようとしている時に起こる場合があります。この場合には、WordPressのログインURLを変更するようにお勧めします。

429: 「要求が多すぎる」

429: 「要求が多すぎる」

500: 「サーバーにエラーが発生したため、リクエストを完了できませんでした。」 一般的なコードで、単に「サーバ内部エラー」を意味します。サーバ内部にエラーが発生したせいで、リクエストしたリソースが配達されていません。このコードは、サードパーティ製のプラグイン、PHP不良、データベースへの接続が切断されたことにより生成されます。データベース接続を確立する際のエラー処理方法 とWordPressウェブサイトの「500 Internal Server Error」の解決方法 についての当社のチュートリアルをご参照ください。

データベース接続を確立する際のエラー

データベース接続を確立する際のエラー

502:「不正なゲートウェイ」 このエラーコードは、あるサーバーが別のサーバーから無効な応答を受け取ったときに表示されます。クエリ及びリクエストには時間がかかり過ぎるため、サーバーによりキャンセルされ、データベースへの接続が切れる場合があります。WordPressウェブサイトの「502 Bad Gateway Error」の解決方法については、当社の詳細なチュートリアルをご参照ください。

ブラウザーの502不正なゲートウェイエラー

ブラウザーの502不正なゲートウェイエラー

503: 「サーバーは現在このリクエストを処理することができません。 リクエストは現在完了できません。このコードは、サーバーが過負荷で、追加のリクエストが処理できない時に返されます。

504: 「ゲートウェイとして機能しているサーバーが、他のサーバーからの応答を待ってタイムアウトしました。」サーバーが2つあり、その一つは相手側のサーバーからの応答を待っている間にタイムアウトしているときにこのコードが返されます。504エラーの処理方法についてはこちらをご参照ください。

ブラウザーの504ゲートウェイタイムアウトエラー

ブラウザーの504ゲートウェイタイムアウトエラー

MyKinstaの分析ツールでもHTTPコードについて詳しく調べることができます。レスポンスコードの内訳レポートには、リクエストされたリソースに配達されたHTTPステータスコードの一覧が表示されます。

レスポンスコードの内訳

レスポンスコードの内訳

応答の分析データレポートには、発生したリダイレクトの総数、エラー、成功率、およびエラー率が表示されます。どのWordPressウェブサイトにも、低くてもエラー率があります。これは完全に正常です。

応答の分析データ

応答の分析データ

500エラー、400エラー、リダイレクトなどのすべてのエラーコード類には内訳のレポートがあります。

500エラーコードの内訳

500エラーコードの内訳

バックエンド最適化に関する推奨事項

それでは、バックエンドを最適化することによりWordPressをスピードアップする方法について説明します。バックエンドは、PHP、HTTPキャッシュヘッダー、GZIP圧縮など、完全にサーバに処理されるものを指します。

404ページを軽くする

非常に動的なウェブサイトでは、404エラーが良く発生することがわかりました。あなたのウェブサイトでも思っている以上発生しているかもしれません!当社のMyKinsta分析ツールを使用すると、正確な数を確認することができます(下記参照)。

404エラー

404エラー

本エラーが特に悪い理由の一つは、404ページの多くが非常にリソースを消費するものであることです。非常に動的なWordPressウェブサイトでは、重い404ページを避けましょう。可能な限りデータベースへのクエリを回避する 単純な404テンプレートを作成してください。もちろん、時間をちゃんとかけて、404エラーを処理した方が良いでしょう。本エラーはリソースを多用するだけではなく、ユーザーエクスペリエンスにも悪いです。

PHPワーカーの数を増加する

PHPワーカーは今まで聞いたことのない用語かもしれませんが、Kinstaを含め、PHPワーカーをベースにリクエストを制限するホスティング会社が多いです。(共有ホスティング会社は通常CPU及びRAMをベースに制限しています。)

特定の時間にウェブサイトが同時に処理できるリクエストの数がPHPワーカーによります。簡単に言うと、ウェブサイトへのキャッシュされていないリクエストはすべてPHPワーカーにより処理されます。たとえば、ウェブサイトへのリクエストが同時に4つもされているが、ウェブサイトにPHPワーカーが2つしかない場合には、それらのリクエストのうち2つは処理され、残りの2つは最初の2つが完了するまで待ち行列に入ります。

WordPressのメンバーシップサイトの最大の課題の一つが、キャッシュされていないリクエストであることを上記に説明しましたね。PHPワーカーがそのリクエストを処理しているため、非常に重要なものです。これらのウェブサイトでは、すべてのリクエストが遅滞なく処理され、正常に完了することを確保するために追加のPHPワーカーが必要になる場合が多いです。

PHPワーカーをよく使用しきると、待ち行列が古いリクエストをキャンセルし始める為、500エラーが発生する可能性があります。Kinstaの各ホスティングプランには、事前定義された数のPHPワーカーが含まれています。ウェブサイトに適切なPHPワーカーの数の推定に自身のない方は、是非当社の営業チームまたはサポートチームとチャットしてください。

GZIP圧縮を採用する

GZIPはファイルの圧縮と解凍に使用されるソフトウェアアプリケーションとその圧縮データのファイルフォーマットです。GZIP圧縮はサーバー側で有効にされるもので、HTML、スタイルシート、およびJavaScriptファイルのサイズをさらに縮小します。

ウェブブラウザがウェブサイトにアクセスするときに、content-encoding:gzip HTTPヘッダーが存在するかを確認することにより、ウェブサーバーでGZIPが有効になっているかを確認します。ヘッダーが検出された場合にはファイルの圧縮版が配達され、検出できなかった場合には非圧縮版が配達されます。GZIPを有効にしていない場合は、Google PageSpeed InsightsGTmetrixなどのスピードテストツールで警告及びエラーが発生する場合があります。

Content-encoding HTTP header for GZIP

content-encoding: gzip

GZIP圧縮を有効にすることによりウェブページのサイズが減り、リソースをダウンロードする時間とクライアントのデータ使用量が低下し、レンダリングの開始時間が改善されます。これは現在のほとんどのホスティング会社ではかなり標準的なことになっていますが、そうしていない会社もあるかもしれません。

ホットリンク予防を有効にする

ホットリンクの概念は簡単です。インターネットで画像を見つけ、自分のウェブサイトでその画像のURLを直接使用することはホットリンクです。該当の画像はあなたのウェブサイトに表示されますが、元のウェブサイトから配信されます。これはホットリンクの作成者にとって非常に便利ですが、実はホットリンクされたウェブサイトのリソースを使用しているため盗難になります。たとえてみると、隣人の車から吸い出したガソリンを自分の車に給油して使用してしまうことのようです。

Hotlinking is like driving away with gas you siphoned off from your neighbor's car.Click to Tweet

ホットリンクはターゲットサーバーのリソースを大幅に消費することがあります。例えば、共有のWordPressホスティング会社を利用しているウェブサイトの画像をHuffington Postが突然リンクしてしまうことを想像してみてください。ウェブサイトの時間当たりのクエリの数が数百から数十万に増加するでしょう。これにより、ホスティングアカウントが停止されることもあります。従って、(上記のような異常を処理できる)パフォーマンスの高いホスティング会社を利用するだけでなく、ホットリンク保護も有効にし、上記を予防しましょう。

ホットリンク予防については、当社のチュートリアルをご参照ください。

リダイレクトを最小限に抑えてサーバーレベルで追加する

リダイレクトが多すぎることは決して気を付けないといけないことです。301リダイレクト、HTTPからHTTPSへのリダイレクト、またはwwwから非wwwへのリダイレクトはOKです。むしろ、必要であるときもあります。ただし、それぞれのリダイレクトがウェブサイトのパフォーマンスへの悪影響を与えます。リダイレクトを複数使用すると、ウェブサイトのパフォーマンスへの影響を把握したうえで使用するようにしましょう。固定ページおよび投稿のリダイレクト、イメージのリダイレクトなどすべてのリダイレクトはそうです。

リダイレクトは、Pingdomでは応答ヘッダーのステータスの301または302とともに青い点として表示されます。

リダイレクトを最小限に抑える:301

リダイレクトを最小限に抑える:301

何件のリダイレクトはウェブサイトを影響するレベルでしょうか。少しのテストをしましょう。まず、https://perfmatters.io/contact/の問い合わせページでスピードテスト を行います。  以下に示すように、良い込み時間は417ミリ秒です。

リダイレクトのないウェブサイトのスピードテスト

リダイレクトのないウェブサイトのスピードテスト

その後、URLを少し変更し、別のスピードテストを行い、複数のリダイレクトの影響を確認します。http://www.perfmatters.io/contact.ご覧のとおり、同じページの読み込み時間は695ミリ秒もかかります。66%の増加です。恐ろしい!

リダイレクトが複数あるウェブサイトのスピードテスト

リダイレクトが複数あるウェブサイトのスピードテスト

無料のWordPressプラグインを使用してリダイレクトを設定すると、そのリダイレクトはwp_redirect関数を使用するためパフォーマンス上の課題が発生することがよくあります。また、wp_optionsテーブルに自動読み込みデータを追加し、データベースの肥大化を促進するものもあります。サーバレベルで追加すべきです。KinstaではMyKinstaのリダイレクトルールツールを使用することによりこれができます。

301リダイレクトを追加する

301リダイレクトを追加する

それに、MyKinstaの分析ツールでは、ウェブサイトのすべてのリダイレクトの数と内訳も確認できます。301、302、および304の総数を参照してください。

リダイレクトの内訳

リダイレクトの内訳

WordPressリダイレクトとより速いパフォーマンスのためのベストプラクティスについての当社の詳細記事も是非ご確認ください。

Cronジョブを暴走させないようにする

CRONジョブ(WP-Cron)はWordPressウェブサイトの繰り返しタスクをスケジュールするのに使用されます。ただし、時間が経つにつれ、これらは制御不能になり、パフォーマンス異常を引き起こす場合があります。無料のWP Controlプラグイン を使用することにより、ウェブサイトのすべてのCronジョブが確認できます。

また、WordPressの内蔵のCron処理ツール(WP-Cron)関係でもパフォーマンスの課題が発生することも見たことがあります。ウェブサイトにPHPワーカーが足りない場合には、リクエストが入り、WordPressが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を無効にする

WP-Cronを無効にする

次に、サーバーからwp-cron.phpをスケジュールする必要があります。Kinstaでは、システムcronは有効になっており、デフォルトで15分毎に実行されます。頻度を増やすには、当社のサポートチームまでお問い合わせください。SSHに詳しい方は、 コマンドラインからもcronの管理ができます

Cache-ControlとExpiresヘッダーを追加する(キャッシュの長さを指定する)

WordPressウェブサイトのすべてのスクリプトに、HTTPキャッシュヘッダーが添付されているはずです。キャッシュヘッダーは、ファイルのキャッシュの期限が切れる時点を指定します。この問題を処理するには、WordPressホスティング会社のcache-controlヘッダーとexpiresヘッダーの設定が適切かを確認します。そうでない場合は、スピードテストツールでexpiresヘッダーを追加する必要がある警告、または「ブラウザのキャッシュを利用する」警告が表示されます。

Cache-Controlヘッダーがクライアント側のキャッシュをオンにしリソースの最大経過時間を設定している一方、Expiresヘッダーはリソースの有効期限を指定するものです。  両方のヘッダーを同時に使用することはできますが、必ずしも両方を追加する必要はありません。 cache-controlの方は新しくて、推奨されるものです。

Kinstaは、すべてのサーバーリクエストに自動的にHTTPキャッシュヘッダーを追加します。CDNをご利用の場合には、これらのヘッダーが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ヘッダーを追加するには、サーバーブロックに次のコードを追加します。この例では、ファイルの種類に基づいて異なる有効期限を指定する方法を確認できます。

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"		
}

ApacheでExpiresヘッダーを追加する

Apacheではexpiresヘッダーを追加するには、.htaccessファイルに次のコードを追加します。

## EXPIRES HEADER CACHING ##		
		
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"		
		
## EXPIRES HEADER CACHING ##

HTTPキャッシュヘッダーを追加できるのはサーバー上のリソースのみであることにご注意ください。サードパーティのリクエストでブラウザのキャッシュを利用する必要があるかもしれないという警告が表示された場合には、そのサードパーティのサーバーのリクエストにアクセスできないため、どうしようもありません。この現象はGoogle Analyticsのスクリプトと、Facebook及びTwitterなどのマーケティングピクセルではよく発生します。

Google Analyticsのスクリプトの場合には、Perfmatters及びWP Rocketなどのプラグインを使用してローカルにあるいはご利用のCDNにホストするという処理方法はありますが、これは公式にサポートされていません。

Last-ModifiedヘッダーとETagヘッダーを追加する(キャッシュ検証)

次に、last-modifiedetagの2つのヘッダーのセットも必要になります。

cache-controlexpiresヘッダーは、あるファイルは前回のリクエスト以降に変更されているかをブラウザーが判断できるためのものです。(つまり、キャッシュを検証するものです。)last-modifiedetagヘッダーはキャッシュを検証し、その長さを指定しているため、すべてのオリジンサーバーの応答に含める必要があります。これらが正しく設定されていない場合には、「キャッシュバリデータを指定する」必要があるという警告が表示されることがあります。

Last-ModifiedヘッダーとETagヘッダー

Last-ModifiedヘッダーとETagヘッダー

ヘッダーがない場合は、毎回リソースに対する新しいリクエストが生成されるため、サーバーの負荷が高くなります。キャッシュヘッダを利用することにより、2回目以降のリクエストがサーバから読み込まれなくなり、バンドウィズが節約され、ユーザのためのパフォーマンスが向上されます。

Kinstaは、すべてのサーバーリクエストに自動的に上記のキャッシュヘッダーを追加します。CDNをご利用の場合には、これらのヘッダーがCDNプロバイダーによりも追加されるはずです。cache-controlexpiresと同様に、これらのHTTPヘッダーを外部リソースに手動で設定することはできません。

Last-Modifiedヘッダー

last-modifiedヘッダーは原則、サーバーから自動的に送信されます。通常は手動で追加する必要はありません。ブラウザのキャッシュ内のファイルが前回のリクエスト以降に変更されているかを確認するために送信されるものです。Pingdomのヘッダーリクエストまたは、ChromeのDevToolsを使用することによりLast-Modifiedヘッダーの値を確認できます。

ETag Header

ETagヘッダーはLast-Modifiedヘッダーと非常によく似ています。これもファイルのキャッシュを検証するためのものです。Apache 2.4以降をご利用の場合には、ETagヘッダーはFileETagディレクティブを使用して自動的に追加されています。そしてNGINXに関しては、ETagヘッダは2016年以来デフォルトで有効になっています。

次のコードを使用することにより、NginxでETagヘッダーを手動で有効にすることができます。

etag on

Vary: Accept-Encodingヘッダーを追加する

クライアントがコンテンツの圧縮版を処理できるかをブラウザに伝える為、すべてのオリジンサーバの応答にvary: Accept-Encodingヘッダーを含める必要があります。これらが正しく設定されていない場合には、「Vary: Accept-Encodingヘッダーを指定する」必要があるという警告が表示されることがあります。

たとえば、 gzip圧縮のない古いブラウザとgzip圧縮のある新しいブラウザがあるとします。vary: Accept-Encodingヘッダーをご利用のない場合に、Webサーバー及びCDNが非圧縮版をキャッシュし、誤って新しい方のブラウザに配達する場合があり、WordPressウェブサイトのパフォーマンスが低下します。本ヘッダーを使用することにより、Webサーバ及びCDNが適切なバージョンを配達することを保証できます。

HTTPヘッダーvary: Accept-Encoding

HTTPヘッダーvary: Accept-Encoding

Kinstaは、すべてのサーバーリクエストに自動的に上記のキャッシュヘッダーを追加します。CDNをご利用の場合には、これらのヘッダーがCDNプロバイダーによりも追加されるはずです。上記で説明した他のキャッシュヘッダーと同様に、本ヘッダーも外部リソースに手動で設定することはできません。

ApacheでVary: Accept-Encodingヘッダーを追加する

Apacheではvary: Accept-Encodingヘッダーを追加するには、.htaccessファイルに次のコードを追加します。

  <FilesMatch ".(js|css|xml|gz|html)$">		
    Header append Vary: Accept-Encoding		
  		

NginxでVary: Accept-Encodingヘッダーを追加する

Apacheではvary: Accept-Encodingヘッダーを追加するには、設定ファイルに次のコードを追加します。Nginxのすべての設定ファイルは/etc/nginx/ディレクトリにあります。プライマリー設定ファイルは/etc/nginx/nginx.confです。

gzip_vary on

wp-config.phpでWordPressのメモリ上限を変更する

WordPress Codexで説明されているように、Version 2.5から、WP_MEMORY_LIMITオプションを使用してPHPが消費するメモリの最大値を設定できます。メッセージ「Allowed memory size of xxxxxx bytes exhausted」などが表示される場合に必要となる設定です。

デフォルトでは、WordPressはPHPのメモリを40MB、マルチサイトでは64MB まで増やそうとします。/wp-includes/default-constants.phpの32~44行にこのコードがあります。(出典

なお、ホスティング会社によるサーバー上のPHPmemory_limitもあります。  この2つは異なります。Kinstaのmemory_limitのデフォルト設定は256Mです。メモリ不足エラーが発生するとWordPressのPHPが使用するメモリの上限を上げてみることができます。

wp-config.php fileファイルの「That’s all, stop editing! Happy blogging.」行の直前に次のコードを追加します。

define( 'WP_MEMORY_LIMIT', '256M' );

WordPressのメモリ上限の課題についてはJan Reilinkの素晴らしい記事も是非ご確認ください。彼はコードのもう一つの使い方も教えてくれます。手動で設定するのではなく、PHPのmemory_limitの値に設定することができます。

define( 'WP_MEMORY_LIMIT', ini_get( 'memory_limit' ) );

フロントエンド最適化と外部サービスに関する推進事項

それでは、フロントエンドを最適化することによりWordPressをスピードアップする方法について説明します。フフロントエンドは、CSS、JavasScript、画像など、完全にクライエント側のブラウザーに処理されるものを指します。または、ウェブサイトに読み込まれている外部サービスの分析とそのサービスの合計読み込み時間に与える影響も含まれます。

フロントエンド最適化なら、次の2つの重要な目標があります:

  • Webページ全体のサイズを縮小すること。CSS、JavaScript、画像などのサイズが重要です。4MBのウェブサイトは、1MBのウェブサイトより読み込み速度がはるかに遅くなります。一方、ページの重さが読み込み時間に与える影響 と、これだけに集中しない方がいいというトピックについてのPaul Calvanoによる素晴らしい記事も是非ご参照ください。
  • HTTPリクエストと外部サービスの数を減らすこと。/strong>With HTTP 2では、単一のTCP接続を使用することにより複数のリクエストと応答を同時に送信できるようになりました。パフォーマンスの観点で素晴らしい改善ですが、HTTPリクエストの数を減らすことにより、WordPressウェブサイトのさらなるスピードアップができます。これには、外部リクエストとサービスの数を減らすことも含まれます。それぞれは、DNSルックアップTLS接続、およびネットワーク遅延などさらなる遅延を引き起こします。

ベースラインを定義するためにWordPressウェブサイトのスピードテストを実施する

ウェブサイトのフロントエンドを最適化しようとするときに、まずベースラインを定義した方が良いでしょう。そのため、スピードテストを実施しましょう。スピードテストができる方法は多数あります。15個の素晴らしいウェブサイトスピードテストツールについての当社の記事を是非ご参照ください。

Pingdomのウェブサイトスピードテスト

Pingdomのウェブサイトスピードテスト

Pingdomの使用方法GTmetrixの使用方法については詳細なチュートリアルをご用意しております。スピードテストの注意事項:

1. ツールを一つ選択し、途中で変えない

僕らはPingdom、GTmetrix、WebPageTest、PageSpeed Insights、そしてChrome DevToolsが好きです。ただし、ずっと同じものを使用する限り、どのスピードテストツールを使用しても構いません。スピードの測定方法と定量化方法は各ツールで異なるため、一つを選び、試験かつ最適化の途中で必ず変えないようにしましょう。Googleさえ一つを選択するように勧めているようです。

The speed test tool you choose doesn't matter as much as picking one and sticking with it throughout all of your tests.Click to Tweet

2. 満点にこだわらない

Google PageSpeed Insights などのツールには、スピード及びパフォーマンスの点数が出ます。ただし、点数はウェブサイトのスピードまたはユーザーが感じるパフォーマンスと同じくらい重要ではないことを覚えておきましょう。点数は、パフォーマンスを把握するものに過ぎません。満点の100点または「A」の取得にこだわるのは時間の無駄になります。外部のスクリプトまたは広告の多い大規模なウェブサイトでなら、満点を取ることは決してできませんが、これはまったく問題ありません。

3. 試験を実施するロケーションも重要

スピードテストの際に選択するロケーションは結構な影響を与えます。前記したとおり、選択するデータセンターの場所は極めて重要です。TTFB、ネットワークレイテンシなどが関連してきます。そのため、データセンターに近いロケーションからもと遠いロケーションからもウェブサイトを試験しましょう。そうすると、CDNのWordPressウェブサイトへの影響も確認できます。

4. キャッシュを考量し、試験を複数回実施する

上記のキャッシュについてのセクションでご説明したように、WordPressホスティング会社またはCDNのキャッシュが最近クリアされた場合または期限切れになっ場合には、HTTPヘッダーに「MISS」になります。つまり、ウェブサイト及びアセットはキャッシュから配達されていません。

HTTPヘッダーMISS

HTTPヘッダーMISS

ウェブサイト全体のスピードを正しく把握するには、すべてのデータがキャッシュから読み込まれ、初期ページおよびすべてのアセットが「HIT」であるはずです。このため、スピードテストを複数回実行する必要がある場合もあります。その場合は平均をとります。

HTTPヘッダーHIT

HTTPヘッダーHIT

それでは、WordPressウェブサイトでできるフロントエンドの最適化について説明します。

「クエリ文字列を削除せよ」

「クエリ文字列を削除せよ」警告もスピードテストツールでよく発生する推奨事項の一つです。その内容は何でしょうか?SSファイルとJavaScriptファイルのURLの最後には、通常https://domain.com/file.min.css?ver=4.5.3などのファイルバージョンがあります。ただし、クエリ文字列をキャッシングできないサーバーとプロキシサーバーがありますので、削除することによりキャッシングが改善できます。

そこで、Perfmattersなどのワンクリックでクエリ文字列を削除できるプレミアムプラグインをご利用できます。または、テーマのfunctions.phpファイルに次のコードを手動で追加することもできます。コードを追加するより安全な方法は、Code Snippetsなどの無料のプラグインを利用することです。これで、テーマを直接触らなくても構いません。

function remove_query_strings() {		
 	 	 if(!is_admin()) {
 	 	 add_filter('script_loader_src', 'remove_query_strings_split', 15);
 	 	 add_filter('style_loader_src', 'remove_query_strings_split', 15);
 	 	 }
 	 	}
 	 	function remove_query_strings_split($src){
 	 	 $output = preg_split("/(&ver|\?ver)/", $src);
 	 	 return $output[0];
 	 	}
 	 	add_action('init', 'remove_query_strings')

クエリ文字列があり

クエリ文字列を読み込むスクリプトの例は下記のとおりです。

クエリ文字列があり

クエリ文字列があり

クエリ文字列がない

クエリ文字列が削除されたスクリプトの例は下記のとおりです。

クエリ文字列がない

クエリ文字列がない

ただし、ウェブサイトのクエリ文字列を削除する前に、まずクエリ文字列が使用されている理由を理解することが重要です。ファイルのバージョン管理は、WordPressの開発者がキャッシュの問題を回避するた方法の一つです。

たとえば、更新の際にstyle.css?ver=4.6から?ver=4.7に変更すると、それはまったく新しいURLとして認識され、キャッシュされません。クエリ文字列を削除してプラグインを更新すると、キャッシュされたバージョンが引き続き配信される場合があります。場合により、キャッシュされたリソースの期限が切れるか、キャッシュが完全にフラッシュされるまで、ウェブサイトの外観が壊れる可能性があります。

また、クエリ文字列をキャッシュできるCDNもあります。Kinsta CDN は、キャッシュできるし、デフォルトで行っている設定になっていますつまり、Kinstaのお客様なら、クエリ文字列は既にキャッシュされています。

当社の静的リソースからクエリ文字列を削除する方法についての詳細なチュートリアルも是非ご確認ください。

レンダリングをブロックしているJavaScriptとCSSを排除する

ページができるだけ速読み込まれることを邪魔するファイルがある場合には、レンダリングをブロックしているJavaScriptとCSSの警告が表示されることがあります。条件付きの特定のJSとCSSもある為、重要なのコンテンツを表示しなくてもかまいません。レンダリングをブロックしているものにならない為にasync属性とdefer属性を使用します。

レンダリングをブロックしているリソースをは排除する

レンダリングをブロックしているリソースをは排除する

レンダリングをブロックしているJavaScriptとCSSを排除するには次に従ってください。

クリティカルレンダリングパスからJSを削除する

JavaScriptをクリティカルレンダリングパスから削除するには、JavaScriptリソースを呼び出すためにスクリプトのHTML要素にdefer属性またはasync属性を追加します。

  • async属性は、HTMLをパースせずににすぐにリソースのダウンロードを開始するようブラウザに指示します。リソースが利用可能になると、HTMLパースが一時停止され、リソースが読み込まれます。
  • defer属性は、HTMLパースが完了するまでリソースのダウンロードを延期するようブラウザに指示します。ブラウザがHTMLの方を完了した後に、延期されたすべてのスクリプトを、文章に表示されている順序でダウンロードしてレンダリングします。

CSSリソースの配信を最適化する

CSSの配信を最適化するには、レンダリングをブロックしないようにする方法を考える必要がります。

  • 重要なコンテンツをレンダリングするために必要なスタイルを識別し、HTMLとインラインで配信します
  • CSSを必要な場合にのみ、条件付きでデバイスで使用します。
  • 残りのCSSを非同期で読み込みます。

上記をすべて実施するのは難しくて、ウェブサイトに読み込まれるスクリプトにより調整が間違いなく必要です。下記はそのために便利なWordPressプラグインです。

詳細については、レンダリングをブロックしているJavaScriptとCSSを排除するについての当社の記事をご参照ください。

WordPressで外部CSSとJavaScriptを結合する

外部CSS結合の警告が表示されるのは、cdn.domain.comなどの外部ドメインでCSSファイルをホストしているため、CDNを使用しているときに発生します。これまでの処理方法は、CSSファイルを連結または結合し、単一のリクエストで読み込まれるようにすることでした。

ただし、HTTP/2をサポートするプロバイダでHTTPSをご利用の場合には、この警告は以前ほど重要ではありません。HTTP/2では、単一の接続を介して複数のCSSファイルを同時に読み込むことができます。ブラウザーの86%以上がHTTP/2をサポートしています

しかし、必ずしもこの最適化対策が不要であるとは限りません。WordPressウェブサイトをさらにスピードアップできる場合も見たことがあります。ファイルのサイズと数によるため、必ず自分のウェブサイトで試験した方が良いでしょう。

外部のCSSファイルとJavaScriptファイルを結合しやすい方法は無料のAutoptimizeプラグインを使用することです。結合後に、「”autoptimize_xxxxx.css」または「autoptimize_xxxxx.js」ファイルができます。CDNからの読み込みもサポートされます。無料のWP Rocketプラグインも利用できます。

結合したCSSとJavascriptファイル

結合したCSSとJavascriptファイル

WordPressで外部CSSとJavaScriptを結合することについては当社の詳細なチュートリアルをご確認ください。

HTML、CSS、JavaScriptの縮小を実施する

HTML、CSS、およびJavaScriptのリソースの縮小により、ブラウザーがダウンロードするデータの量を減らすことができます。縮小は、コメントや空白などの不要な文字をソースコードから削除するプロセスです。これらの文字は開発において非常に便利であるが、ブラウザーがページをレンダリングする際には完全に不要です。

縮小されていないHTML

これは縮小されていないHTMLコードの例です。

縮小されていないHTMLコード

縮小されていないHTMLコード

縮小されているHTML

これは縮小されているHTMLコードの例です。

縮小されているHTMLコード

縮小されているHTMLコード

無料のAutoptimizeプラグインまたはWP Rocketを使用することによりファイルを簡単に縮小できます。

原則として、画像、JavaScript、CSSなどのコンテンツを配達している際に、オーバーヘッドが生じるため、HTTPクッキーも付ける理由は一切ありません。サーバーがあるドメインに対しクッキーを設定すると、そのドメインに対するすべてのHTTPリクエストにそのクッキーが含まれているはずです。この警告は、リクエスト数の多いウェブサイトでよく見られます。

クッキーフリードメインから静的コンテンツを配信する警告の処理方法については、当社の詳細記事をご参照ください。HTTP/2 などの新しいプロトコルではこの警告が以前ほど重要ではないため、無視してかまいません。新しい接続のコストは、すべてのデータを同じ接続を介してストリーミングするより高いです。

この警告の最も簡単な処理方法の一つは、クッキーを無視したり、クライアントがSet-Cookie応答ヘッダーを受信できないようにするクッキーを削除したりできるCDNプロバイダを使用することです。KeyCDNは、この機能を提供しているCDNプロバイダの一つです。ご覧の通り、デフォルトでは次の2つのオプションが有効になっています。これは、ウェブサイトを移行したり、別のサブドメインから静的アセットを配信するように設定したりせずにできる、簡単な方法です。

CDNがクッキーを削除する

CDNがクッキーを削除する

Cloudflareをご利用の場合には、Cloudflareのネットワークを介して配信されているリソースのクッキーを無効にすることはできません。CloudFlareは独自のセキュリティクッキーをヘッダーに含めます。繰り返しますが、これらのクッキーは非常に小さく、パフォーマンスへの影響はごくわずかです。ただし、CloudFlareをご利用の場合には、この警告を回避する方法はありません。

警告を回避する二つ目の方法は、新しいドメインまたはサブドメインから静的アセットを配信するようにWordPressウェブサイトを再設定することです。

WordPressの埋め込みを無効にする

WordPress 4.4をがリリースされたときに、oEmbed機能をコアにマージしました。これにより、URLを貼り付けるだけでYouTubeの動画、ツイートなどのリソースをウェブサイトに埋め込むことができます。URLは自動的に埋め込みに変換され、ビジュアルエディタでライブプレビューも表示されます。このアップデートにより、WordPress自体がoEmbedプロバイダーになりました

この機能は多くの人にとって便利で、有効のままにしても構いません。ただし、この機能は、WordPressウェブサイトでwp-embed.min.jsファイルを読み込むための追加のHTTPリクエストも生成します。そしてこれはウェブサイト全体に負荷をかけます。このファイルは1.7 KBしかありませんが、このようなファイルが時間が経つにつれて重なります。リクエスト自体がコンテンツのダウンロードサイズよりも大きい場合があります。

wp-embed.min.jsファイル

wp-embed.min.jsファイル

このファイルの読み込みを簡単に無効にすることができます。下記は3つのオプションがあります。

WordPressの絵文字を無効にする

埋め込みと同様に、WordPress 4.2では、古いブラウザーを対象に絵文字のサポートがコアに追加されました。ただし、この機能は、WordPressウェブサイトでwp-emoji-release.min.jsファイルを読み込むための追加のHTTPリクエストも生成します。そしてこれはウェブサイト全体に負荷をかけます。このファイルは10.5 KBしかありませんが、ウェブサイトで絵文字を使用していないなら完全に無駄です。

wp-emoji-release.min.js

wp-emoji-release.min.js

WordPressで絵文字を無効にする方法はいくつかあります。プラグイン及びコードを使用してもできます。

WordPressのコメント機能のスピードアップ及び無効化

ウェブサイトのコメントセクションは忙しいと、パフォーマンスの課題が発生する場合があります。コメントを機能させるためのリソースを考慮しましょう。

  • 既存のコメントを表示するためにデータベースのクエリが実行されます。
  • 新しいコメントごとにデータベースエントリが作成されます。
  • コメントとコメントのメタデータは、訪問者のブラウザに受信かつ処理されます。
  • Gravatarなどの外部リソースがリクエスト、ダウンロード、または読み込みされます(個別のDNSルックアップが必要です)。
  • コメントシステムが想定どおりに機能するには、重いJavaScriptおよびjQueryリソースをダウンロードして処理する必要がある場合も多いです。

WordPressのコメントをスピードアップできるオプションは4つもかあります。

オプション1:コメント機能を無効にする

ウェブサイトのコメントの数が少なくて、あまり価値を加えていないものであればコメント機能を完全に無効にした方が良いでしょう。Googleはコメントもページのコンテンツとしてクロールするため、コメントはSEOに影響を与える場合がありますので、ご注意ください。質の高いコメントのみを承認してください。コメント機能を無効にする次の3つの方法をご参照ください。

オプション2:WordPress独自のコメント機能を最適化にする

2番目のオプションは、WordPress独自のコメント機能を最適化することです。最初のページの読み込みで読み込まれるコメントの数を減らすことはその最適化ができる方法の一つです。

  1. WordPress管理ダッシュボードで「設定」→「ディスカッション」の順にアクセスします。
  2. 「他のコメント設定」を探します。
  3. 「1ページあたり○○件のコメントを含む複数ページに分割し、」のチェックボックスを選択し、最初のページの読み込みで表示したいコメントの数を入力します。
コメントを複数のページに分割する

コメントを複数のページに分割する

CDNでGravatarをホストる方法もあります。これはKinstaのアプローチです。

デフォルトでは、WordPressのコメントが読み込まれる際に、各Gravatarが別途のHTTPリクエストを必要とします。そのため、ページに50名の方のコメントがある場合には、その方全員のGravatarをダウンロードするには50件のHTTPリクエストが必要になります。ご想像のとおり、これはページのスピードに結構な影響を与えます。それに、gravatar.comへの外部DNSルックアップが遅くなることがあり、場合によってはタイムアウトになることもあります。

KinstaのブログのGravatarを確認すると、Kinsta.comから読み込まれていることがわかります。(当社のCDNを含めます。)GravatarをCDNから読み込まれるよう設定する方法については、こちらの記事をご確認ください。

GravatarをローカルまたはCDNでホストする

GravatarをローカルまたはCDNでホストする

オプション3:サードパーティのコメントシステムを使用する

3つ目のオプションは、サードパーティのコメントシステムを使用することです。ウェブサイトが安価でリソース不足の共有サーバーでホストされている場合は、サードパーティのコメントシステムを使用することにより、コメントの多いページの読み込み速度が改善されます。画像の最適化と同様に、負担をオフロードします。一方、Kinstaなどの高品質のウェブホスティング会社をご利用の場合には、サードパーティに切り替えても改善が見られるどころか、ウェブサイトの読み込み速度が低下することがあります。

Disqusの外部リクエスト

Disqusの外部リクエスト

お試しのサードパーティのコメントシステムを必ずスピードテストで確認するようにしてください。Disqusが生成する個別のリクエストの数をご覧ください。(以下参照)リクエストの大半は非同期的に読み込まれますが、Disqusを使用することにより読み込み時間が必ず長くなりますので、ご注意ください。

オプション4:コメントの遅延読み込を実装する

4番目のオプションは、コメントが最初のページレンダリングへの影響を与えないように、コメントの遅延読み込みを実装することです。確認する価値のあるプラグインは例えば:

  • Lazy Load for Comments:このプラグインを使用すると、WordPress独自のシステムからコメントを遅延読み込みできます。
  • Disqus Conditional Load:Disqusコメントシステムをご利用の場合には、このコメントを遅延読み込みするプラグインはマストです。

WordPressのRSSフィードを無効にする

ウェブサイトでWordPressのブログ機能をご利用でない場合には、WordPressのRSSフィードを無効にすることができます。パフォーマンスへの影響度が少ないが、正しい方向への一歩です。そして、懸念も減ります。

WordPressでRSSフィードを無効にするには、次の2つの方法があります:

プリフェッチとプリコネクトを使用する

プリフェッチプリコネクトなどのリソースヒント及びディレクティブは舞台裏でWordPressをスピードアップする素晴らしい手段です。KeyCDNは リソースヒントの概要について素晴らしい記事を用意しています。

プリフェッチ

DNSプリフェッチを使用すると、ユーザーがリンクをクリックする前にドメイン名を解決(バックグラウンドでDNSルックアップを実行)することにより、パフォーマンスが改善されます。使用するには、WordPressウェブサイトのヘッダーにrel=”dns-prefetch”タグを追加します。

<link rel="dns-prefetch" href="//domain.com">

DNSプリフェッチを使用するよくある目的は、CDN URL、Googleフォント、Google Analyticsなどです。

 <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」タブをクリックし、ドメインを追加するだけです。フォーマット://domain.tld (one per line)

プリフェッチ

プリフェッチ

プリコネクト

プリコネクトを使用すると、ブラウザーはHTTPリクエストがされた前に早期接続ができるため、ラウンドトリップレイテンシがなくなり、ユーザーの時間を節約できます。

プリコネクトは最適化ツールボックスの重要なツールです。リクエストパスから費用のかかるラウンドトリップの多くを排除し、場合により、リクエスト待ち時間を数百~数千ミリ秒も減らすことができます。– lya Grigorik (出典)

使用するには、WordPressウェブサイトのヘッダーにrel=”preconnect”タグを追加します。

<link rel="preconnect" href="//domain.com">

利用可能な目的は例えば、CDN、URLまたはGoogleフォントなどです。

 <link rel="preconnect" href="https://cdn.domain.com">
 <link rel="preconnect" href="https://fonts.gstatic.com">

プリコネクトは、Internet Explorer、Safari、IOS SafariとOpera Miniを除き、ほとんどの現代的なブラウザではサポートされています。WordPressヘッダーにコードを追加する方法については、当社のチュートリアルをご参照ください。

あるいは、Perfmattersなどのプラグインを使用することによりも、プリコネクトを簡単に実装できます。Perfmattersプラグインの「Extras」タブをクリックし、ドメインを追加するだけです。フォーマット://domain.tld (one per line)

プリコネクト

プリコネクト

固定ページ及び投稿ごとにスクリプトを無効にする

WordPressをスピードアップするためのもう一つの非常に強力な手段は各固定ページ及び投稿に読み込まれている各リクエストを確認することです。ウェブサイト全体に読み込まれているが、そうでないはずのスクリプトが出る可能性が高いです。

Perfmattersなどの「スクリプトマネージャ」機能を内蔵したプレミアムプラグインを使用することができます。これにより、固定ページ及び投稿ごとにも、ウェブサイト全体を対象にもワンクリックでスクリプト(CSSおよびJavaScript)を無効にすることができます。繰り返しますが、このプラグインはKinstaのチームのメンバーの一人により開発されました。

使用用途の例をいくつか挙げます。

  • 人気のContact Form 7プラグインは、すべての固定ページと投稿に読み込まれます。そこで、ウェブサイト全体を対象に無効にし、お問い合わせのページのみで有効にすることができます。
  • ソーシャルメディアのシェアプラグインは投稿にのみ読み込まれるべきです。そこで、ウェブサイト全体を対象に無効にし、カスタムの種類を含め特定の投稿の種類のみを対象に有効にすることができます。
  • Table of contents plugin (TOC)プラグインは、すべての固定ページと投稿に読み込まれます。スクリプトマネージャを使用すると、読み込まれる場所を指定できます。

何故このようにコード化されているプラグインは存在しているのだろうか?

ページ上でプラグインが検出されたときに限りそのスクリプトが読み込まれるようにしないプラグインの開発者が何故いるのでしょうか。答えは複雑です。たとえば、Contact Form 7のようなプラグインは、どこにでもプラグインを配置できるショートコードもあります。これにはウィジェットにドロップすることも含まれています。WordPressでは、スクリプトからデータをクエリするのは、投稿または固定ページのメタデータからデータをクエリするより、スクリプトをデキューするのがはるかに難しいです。

したがって、ユーザビリティは理由である場合が多いです。プラグインが壊れる可能性が少ないほど、サポートチケットの数が少ないです。一方、この課題を超えて、パフォーマンスを念頭に置いてコードする方法は実はあります。残念なことに、ダウンロードとユーザーが圧倒的に多いため、ユーザビリティを優先してコードする場合が多いです。

スクリプトマネージャの紹介

スクリプトマネージャについて少し説明します。ツールバーでスクリプトマネージャをクリックすると、そのURLに読み込まれているすべてのスクリプト(JavaScriptファイルとCSSファイルの両方)が表示されます。そこで、オプションは二つあります:

  1. ステータスがオン(デフォルト設定)
  2. ステータスがオフ:ウェブサイト全体を対象に無効にする(その後、現在のURLを含め、どの投稿の種類を対象に有効にするか指定できます)
  3. ステータスがオフ:現在のURLでのみ無効にする(これはホームページなら特に便利です)
  4. ステータスがオフ: 例外(現在のURL、投稿の種類、またはアーカイブ)
Perfmattersのスクリプトマネージャ

Perfmattersのスクリプトマネージャ

中身はプラグイン名ごとまたはテーマ名ごとにまとめられていますしたがって、プラグイン全体を一括で無効にするのは非常にしやすいです。WordPressプラグインは通常、JavaScriptファイルもCSSファイルもあります。WordPressテーマにはファイルが10個以上もある場合があります。

設定変更を選択した後には、必ず下部にある「保存」ボタンをクリックしてください。次に、ウェブサイトスピードツールで試験し、スクリプトが固定ページや投稿に読み込まれなくなったことを確認できます。その前にキャッシュをクリアすることを見逃さないでください。万が一、外観問題が発生した場合には、設定でスクリプトを再度有効にして通常の状態に戻すことができます。

woorkupによるスピードテストでは、合計読み込み時間を20.2%短縮できました。彼らはホームページだけでHTTPリクエストの数を46から30に減らすことができました。ページサイズも506.3KBから451.6KBに縮小しました。

スクリプトを無効にするその他の手段については、WordPressプラグインを読み込まれないようにする手段についての当社の記事をご参照ください。

サードパーティパフォーマンスを分析する

ウェブサイトから外部への呼び出しのすべては読み込み時間を影響します。さらに悪いことに、その中には断続的に発生し、異常の原因が特定しにくいものもあります。

サードパーティの外部サービスは、サーバの外部からWordPressウェブサイトとの通信を行うものです。そのよくある例は例えば:

  • Twitter、Facebook、Instagramなどのソーシャルメディアプラットフォーム(ウィジェットまたはコンバージョンピクセル)
  • Google Adsense、Media.net、BuySellAds、Amazon Associatesなどのサードパーティ広告ネットワーク
  • Google Analytics、Crazy Egg、Hotjar、AdRollなどのウェブサイト分析スクリプトとトラッキングスクリプト
  • Optimizely、VWO、UnbounceなどのA/Bテストツール
  • Disqus、Jetpack、FacebookのコメントなどのWordPressのコメントシステム
  • VaultPress、Sucuri、CodeGuardなどのバックアップおよび セキュリティツール
  • SumoMe、HelloBarなどのソーシャルシェアツール
  • KeyCDN、Amazon CloudFront、CDN77、StackPathなどのCDNネットワーク
  • 外部ホストのJavascript

上記のサードパーティのトラッカーのパフォーマンスへの影響度はどれほどでしょうか?当社のケーススタディでは、サードパーティのスクリプトによりページ読み込み時間が86.08%も増加したことがわかりました。

GhosteryはAlexaを使用し、米国の上位500ドメインを測定し、驚くべき結果をもたらしました。一方、僕らは驚きませんでした。トラッカーがまったくブロックされていないと、ウェブサイトは2倍遅くなりました。つまり、サードパーティのトラッキングスクリプトは、ページの読み込み速度が遅くなる主な原因の一つです。

トラッカーでの読み込み時間

トラッカーでの読み込み時間(画像ソース:Ghostery)

十分にご注意ください。悪いサードパーティAPI呼び出しがたった1件発生すると、ウェブサイト全体がタイムアウトしてしまう場合があります。確かにあり得ない話ですが、本当はよくある現象です。数え切れないほどの回数で発生します。

New Relicは、外部サービスを長期にわたって監視できる優れた手段です。以下の例では、twitcount.com、graph.facebook.com、およびwidgets.pinterest.comへの外部呼び出しが行われているのがわかります。

ソーシャルメディア外部サービスの応答時間

ソーシャルメディア外部サービスの応答時間

ウェブサイトに新しい機能及びプラグインを追加するときにその機能及びプラグインから読み込まれる外部リソースを調査することは非常に重要です。少ないほどいいです!

モバイルファーストを念頭に置いて最適化する

Googleは2018年3月26日にモバイル ファーストインデックスを発表しました。以前は、Googleのクロール、インデックス作成、及びランキングシステムではウェブサイトのデスクトップ版が使用されていました。モバイル ファーストインデックスでは、Googlebotがインデックス作成と検索結果のランキングにWordPressウェブサイトのモバイル版を使用するようになります。これにより、モバイルユーザーの検索エクスペリエンスが向上します。

モバイルを優先するようにウェブサイトを最適化する際に、スピードが最も注目すべき要素の一つになります。スピードは、ユーザビリティと直帰率をはじめ、お客様が次回もウェブサイトにアクセスしてくれるかを決定するもので、重要な役割を果たしています。スピードは、モバイル向けのGoogle検索とGoogle広告のランディングページの要素になりました。

モバイルでの体験が悪いと、ユーザーの大半は二度と戻らないようにします。Googleの最新のページスピードレポートによると、2018年にモバイルウェブサイトの読み込みにかかる平均時間は15秒でした。あなたならそこまで待ちますか?多分、待ちませんね。

ユーザーはもっと良いサービスを期待しているでしょう。同じページスピードレポートによると、モバイルサイトの訪問者の53%が読み込みに3秒以上がかかるとそのサイトを放っておきます

モバイルエクスペリエンスが遅いと、コンバージョン率が低下するのではなく、見込み客のコンバージョンのチャンスさえなくなります。ページの読み込み時間がほんの数秒だけ増加するにつれ、直帰率が指数関数的に成長しています。 モバイル向けに最適化する際に次を考慮してください。

モバイルによるトラフィックを確認する

優先順位が少し変わる可能性があるため、モバイルトによるラフィックの量を確認することは重要です。Google Analyticsの「ユーザー」→「モバイル」→「概要」で、ウェブサイトにアクセスするモバイル装置の数を確認できます。ご覧の通り、例のウェブサイトのトラフィックの67%以上がモバイルからのトラフィックです。多すですね!

Google Analyticsにてのモバイルによるトラフィック

Google Analyticsにてのモバイルによるトラフィック

Kinstaのお客様は、MyKinstaの分析機能を使用してモバイルによるトラフィックとデスクトップによるトラフィックを比較することもできます。 ご覧の通り、例のウェブサイトのトラフィックの88%以上がデスクトップからのトラフィックです。そのため、推定するはなく、必ず確認するのは重要です。 いくらモバイルの方が重要だと言われていても、あなたのウェブサイトもそうとは限りません。データを確認してください。

モバイルvsデスクトップ:MyKinstaの分析機能

モバイルvsデスクトップ:MyKinstaの分析機能

ウェブサイトはレスポンシブであることを確認する

2019年にこそ、ウェブサイトがレスポンシブであることは大切です!レスポンシブであることは、コンテンツをモバイル装置用に自動的に縮小するメディアクエリを採用することです。まだ採用していない方は、おそらく競争から取り残されています。 本記事で前述したWordPressテーマはすべて完全にレスポンシブであり、どの装置でも見栄えがします。

Googleのモバイルフレンドリーツールを使用して、ウェブサイトがすべての要件を満たしているか確認できます。

モバイルフレンドリー試験

モバイルフレンドリー試験

srcsetが正常に機能しているかダブルチェックする

以前は、画像をスケーリングでアップロードし、CSSによるサイズ変更をしないことが非常に重要でした。 ただし、WordPress 4.4では(CSSで縮小されない)レスポンシブな画像がサポートされるようになった為、これは以前ほど重要ではなくなりました。 WordPressは自動的にメディアライブラリにアップロードされた各画像に対していくつかのサイズの画像を生成します。
利用可能なサイズがすべてsrcset属性にあり、ブラウザーは最も適切なサイズのみをダウンロードし、それ以外を無視できるようになりました。下記はコードの例です。

WordPressのsrcset

WordPressのsrcset

なお、サードパーティ製の画像プラグインとカスタム設定のせいで、これが正常に機能していないことがよくあります。そのため、画面サイズに合わせた画像サイズのsrcset属性が正しく追加されていることを再確認することが重要です。画像の最適化は極めて重要になりました。

Google AMPも役に立つかもしれない

Google AMP(Accelerated Mobile Pages Project、和訳:高速モバイルページプロジェクト)は、2015年10月に立ち上がりました。このプロジェクトは、ウェブサイトが軽量のウェブページを構築できる既存のWeb技術をベースにした新しいオープンフレームワークであるAMP HTMLに基づいています。簡単に言えば、現在のウェブページの軽いバージョンを配信できる手段です。

当社のメンバーはGoogle AMPに対して愛憎の入り交じった感情を抱いています。コミュニティの多くもそうです。当社の試験で良い結果は出ませんでしたが、全然でないわけではありません。ウェブサイトはそれぞれ異なり、Google AMPも継続的に改善されています。

次のプラグインのいずれかを使用することにより、WordPressウェブサイトでGoogle AMPをすぐに使い始められます。

Google AMPの設定ついては、当社のチュートリアルをご参照ください。必要に応じて、Google AMPを無効にする方法もご参照ください。簡単に無効にすることのできるものではありませんので、ご注意ください。

まとめ

ご覧の通り、当社のスタッフはWordPressのスピードアップに夢中です。ウェブサイトが速いと、検索結果のランキング、検索エンジンでのクロール性とコンバージョン率が改善され、訪問者がウェブサイトで過ごす時間が増加され、直帰率が減少されます。誰もが速いウェブサイトを訪れるのが好きであることは言うまでもありません!

本スピードアップガイドの中身の一分でもWordPressウェブサイトに適用できる参考になるものであれば幸いです。もしそうなら、必ずシェアしてください。

見落としているものはありますか?あれば、教えてください。WordPressのスピードアップのいい工夫をご存じでしたら、是非コメントを書いて教えてください。


この記事が面白いと思った方は、KinstaのWordPressホスティングプラットフォームも大好きでしょう。ウェブサイトをスピードアップし、当社のベテランのWordPressチームからの24時間365日のサポートを是非ご利用ください。Google Cloudを使用したインフラストラクチャは、自動スケーリング、パフォーマンス、およびセキュリティに重点を置いています。Kinstaの魅力をご案内させてください。当社のプランをご確認ください。