WordPressの高速化対策

インスタンスという言葉は非常に曖昧なのですが、サーバーサイドエンジニアが使う「インスタンス」とは、クラウド上で稼働している個別の仮想マシンの事を指します（プログラミング言語でのインスタンスとは別の意味で使われます）。
代表的なクラウドサーバーであるAWSの場合、 CPU、メモリ、ストレージ、ネットワークキャパシティーを組み合わせた様々なインスタンスタイプが用意されており、そこから最適なインスタンスタイプを選択します。
データセンター等に格納されている物理サーバーの場合には、費用対効果に優れたスペック構成の物理サーバーを選択することになります。 例えば、CPUに関して言えば、周波数の高いものの方がレスポンスは速くなります。

OSの高速化対策としては、主にページキャッシュをディスクキャッシュ設定（低速なハードディスクに記録されているページのキャッシュを高速なメモリに移す設定）にする対策が一般的です。
しかしながら、当社はあくまでWebアプリケーションを専門とするWeb制作会社ですので、OSに関してはそれほどナレッジが蓄積しているわけではなく、この領域に手を出さざるを得ない場合には後述のKusanagiやKinstaをお薦めしています。

NginxはWebサーバーを動かすソフトウエアで、基本的にApacheよりも高速かつ大量処理が得意です（例外としては、大量の動的コンテンツを扱うサイトの場合等ではApacheの方が優れている場合があります）。
このNginxで、FastCGI Cacheとproxy cacheの利用をすることで高速化できます。
また、Expiresの設定やPHPのコンパイラをPCRE JITへ変更するなど高速化に向けたカスタマイズを実施することになりますが、当社ではApacheからNginxへシフトしたのが2019年と遅めの為、そこまで詳しいわけではありません。

Elasticsearchはオープンソースの全文検索エンジンです。
このElasticsearchを使用することで、MySQL（データベース）へのクエリをスピードアップすることができます。
なお、AWSを利用されている場合には、Amazon Elasticsearch Serviceを利用することで比較的容易にElasticsearch（のフォークとなる独自ディストリビューション）を利用することができます。

WordPressはPHPというプログラミング言語で動いていますが、PHPは基本的にバージョンが新しければ新しいほど高速です。 特にPHP8.0は当社のテストでも非常に速い結果を出していますが、レンタルサーバーでは未だPHP8.0に対応していないケースもありますので、その場合にはひとつ前のPHP7.4にしましょう。

PHPアクセラレータとしては、OPCacheとAPCuが有名です。
OPCacheはPHPコードをコンパイルした中間コード（バイトコード）をメモリへキャッシュする仕組みで、APCuはオブジェクトや変数等のデータをメモリへキャッシュする仕組みです。どちらもキャッシュを利用できるようになるため高速化します。

WordPressのデータベースであるMySQL（MySQLデータベースシステム又はMariaDB）では、データの処理部であるストレージエンジンとしてMyISAMとInnoDBを選択できます。 パフォーマンス・信頼性共にInnoDBの方が優れているのですが、昔（MySQL5.5未満の頃）に実装されたWordPressサイトの場合、MyISAMが使われている可能性がありますので、その場合にはInnoDBに移管します。

InnoDB Buffer Poolは、アクセスの多いデータとインデックスをメモリのキャッシュする機能ですが、その設定を大きめに設定することで高速化に寄与させます。

Query Cacheはデータベースを参照（SELECT）した結果をメモリにキャッシュする仕組みで、次に同一の参照が行われた場合にキャッシュを利用する為高速化します。

前述のように、WordPressにて記事の保存・更新がなされる度に作成されるリビジョンや、必ずしも全てのページで必要がないデータや古いレコードの一時データ、セッションデータ等が保存され続けていたりする場合には、これらのデータを整理（削除）することで高速化できる場合があります。

WordPressにはいくつかの優秀なページキャッシュプラグインがあり、ページキャッシュを導入することで、生成したHTMLそのものをキャッシュできます。
また、ページ全体のキャッシュには適さないWebサイトである場合には、部分キャッシュやオブジェクトキャッシュ（Redis等を使用）の導入を検討します。

前述のように、遅いテーマが使われている場合には、利用しない機能を無効に出来るテーマであればカスタマイズを施していきますが、そういう機能がないテーマの場合にはほぼテーマを作り直す提案をさせていただくことになります。

不要なプラグインは削除します。
遅いプラグインが発見された場合には、同様の機能を有する速いプラグインを探して置き換えるか、PHPなどで直接同一処理を作り込むことで高速化させます。

前述のように、ピンバック機能やテーマ並びにプラグインの自動アップデート機能をONにしておくと、必要性が薄いクエリや外部へのリクエストが発生するため、こういった機能の必要性を検討した上で可能であれば設定を変更します。

CDN（コンテンツデリバリネットワーク）は、WordPressがインストールされているWebサーバーとは別の複数のサーバー（エッジサーバー）にページのキャッシュを保管した上で、ユーザーがリクエストに対してネットワーク面でユーザーに最も近いエッジサーバーからレスポンスをする仕組みです。
これにより、キャッシュによるレスポンスの高速化が実現できるだけでなく、ユーザーに最も近いエッジサーバーより応答するため、レスポンス速度が速くなります。 AWSであればCloudfrontが定番ですが、それ以外にもCloudflareといった有名どころの専用サービスもあります。

AMP（アンプ）とはAccelerated Mobile Pages （アクセラレイティッド・モバイル・ページ）の略で、GoogleやTwitter、WordPressなどが参加しているAMPプロジェクトが構築したモバイルでの表示速度高速化を実現するための仕組みのことをいいます。
HTML STANDARDで制作するレスポンシブWebデザイン対応のWebサイトとは別に、独自のAMP HTML及びAMP JS（JavaScript）によりモバイル用のページを制作しておくと、Googleの高速サーバにキャッシュされ、また高速でレンダリングされることにより、スマートフォンでの閲覧時に高速表示が実現します。
なお、AMPは無料のCDNですが、原則としてモバイルのみのサービスとなります。

WordPressをHeadless CMSとして利用することでレスポンスを高速化できます。 具体的には、WordPressのREST API経由で静的サイトジェネレーター（SSG）で完全な静的ページを生成します。静的サイト化の恩恵として上記CDNとも親和的です。
※詳細は「厳密なリアルタイム性が要求されないWebシステムにおける当社の強み」を参照
これにより、WordPressの管理画面を利用してコンテンツ管理をしつつ、高速化対策、セキュリティ対策、アクセス耐性強化、バックアップ体制の充実、サーバー費用の削減を実現できます。
ただし、この構成は、お問合せフォームについてはGoogleFormやHubspot等の外部サービスを利用する必要がある他、SSGの技術が必要で合ったり、通常であれば動的に実装する処理（例えばサービスや実績の絞り込み・ソート等）をフロントエンド側で処理する必要があるため、若干高度な技術が必要となります。

Shifterは上記WordPressのHeadless CMS化とかなり近い構成を提供しているサービスです。 WordPressのHeadless CMS化を個別に実装するのは技術力と工数が必要になりますが、Shifter Staticであれば割と手軽にWordPressサイトの静的サイト化を実施できます（技術的制約もありますのでその点はShifterにご確認ください）。

WordPress高速化パッケージサービスとしては、KUSANAGI、Kinsta等が有名で、サービス・プラン毎に詳細は異なりますが、基本的にはサーバー・ＯＳ・ミドルウェア・アプリケーション（WordPress）・CDNといった各レイヤーでのWordPress高速化対策が組み合わされた上で、適切に管理・運用できるようにパッケージ化されたサービスになります。

従来の通信プロトコルであるHTTP/1.1は、サーバーへのページのリクエストとサーバーからの送信（レスポンス）を順番に処理する仕組みですが、次世代通信プロトコルHTTP/2 Server Pushを利用すれば、1回のリクエストでHTML,CSS,JavaScriptのレスポンスがサーバーからプッシュされる為レスポンスが速くなります。
このHTTP/2 Server Pushは、SSL通信であること、Webサーバー側でHTTP/2とServer Pushに対応していることが必要です。

画像の圧縮は高速化対策の第一歩です。圧縮には可逆圧縮（ロスレス圧縮）と非可逆圧縮の２種類がありますが、通常は元データを別途保存しておいて圧縮率の高い非可逆圧縮を行うことになります。
この際、PageSpeed Insightsの指摘通りのサイズまで減らすと、人間の目では品質が悪すぎるように感じることがあります。
これは画像の内容にもよりけりですので、納得できるギリギリのラインのバランスを探りつつ画像の圧縮を実施することになります。

WebP（ウェッピー）は、Googleが開発した画像フォーマットで非常に高い圧縮率を誇ります。このWebPのクオリティー80にするだけでファイルサイズを大幅に削減することができます。
一方で、WebPはIEでは表示されないというデメリットを有します。
IEを利用しているユーザーがほぼ居ないWebサイトであれば、画像をWebP形式に変更するだけで高速化を実現できますが、ユーザーの一定割合が未だIEを利用しているような場合には工夫が必要になります。
例えば、管理画面からjpg形式の画像をアップロードすると、自動的にWebP形式の画像も変換・保存されるようにしておき、ユーザーがリクエストを行う際に通常はWebPを読み込むHTMLを送るが、IEの場合にはjpgを読み込むHTMLを送るようにサーバーサイドで処理をする等です。

日本語のWebフォントの利用は、デザイン性や自動翻訳への対応などでWebサイトのUXを高めますが、一方で文字数が多いためファイルサイズが大きく、読み込み時間がかかるいとうデメリットを有します。
この場合、使用しないフォントデータを削除（サブセット化）することで、日本語Webフォントデータを軽量化できます。

CSS・JavaScriptについては、不要であったり重複しているコードを削除することは当然として、ショートハンドの使用、ライブラリの改良等、コーディングスキルによるファイルサイズの最適化対策が可能です。
また、HTML・CSS・JavaScriptの軽量化・圧縮については、必要のないコメントや空白、改行を削除することでデータ量の削減を行うMinify化も行われます。
更に、HTML・CSS・JavaScriptをgzipに圧縮しておくことで通信速度を高速化させます。
なお、Minify化はメンテナンスがやりにくくなるなどのデメリットにありますし、通信速度の高速化が進んでいる現在では、それほど効果的な対策では無くなってきていると当社では考えております。

前述のように、CSSはレンダリングをブロックするリソースですので、ファーストビューに関連するCSSをHTMLに直接記載（インライン化）し、それ以外のCSSを遅延読み込みさせることで表示速度を高速化します。
ただし、インライン化はHTMLの量を増やしてしまう上に、キャッシュの使用が出来なくなるというデメリットもあるため、全てのページで実施するのではなくファーストビューに関連する部分に限定していきます。

JavaScriptもレンダリングをブロックするリソースですが、deferとasyncという属性をscriptタグに上手く追加することで、JavaScriptをバックグラウンドでダウンロードさせながらパーサーを稼働させることができます（非同期読み込み）。

オフスクリーン画像の遅延読み込みとは、その名の通り、画面に表示されていない画像の読み込みを画像がスクロールによって表示エリアに入るタイミングまで遅延させる技術です。
これにより、ユーザーが操作可能になるまでの時間を短縮することができます。
Lazy Loadが有名ですが、正規の画像を表示させるまで画質の低い画像を表示しておくプログレッシブ画像を選択するケースもあります。