WordPressを使う以上、セキュリティリスク増加やパフォーマンス低下は避けられません。例えば、誰もがどこからでもログインでき記事を更新できることは便利な反面不正ログインのリスクがあるし、データベースを参照して関連記事や人気記事を自動で表示することはデータベースに負荷がかかりその分表示速度が犠牲になります。
そこでここ数年WordPress界隈を賑わせているのがHeadless CMSという、WordPressをコンテンツ運用で使って、実際のフロント側はReactやVueなどで取得して表示させてしまうという手法。これならWordPressの資産は活かしつつ、自由に表現できるしサイトの一部だけCMS化することも可能だし、セキュリティリスクが軽減できパフォーマンスの低下も心配しなくていいなど、いいことばかりです。ただ導入の敷居は低くないので、導入するかどうかは要検討。
一方、WordPress全体を静的化してしまうShifterというサービスがあります。
WordPressが静的化されて表示されるため、セキュリティのリスクはほぼ無くなって、データベースへのリクエストがなくなり表示スピードが爆速になるというサービス。
そこで今回、Shifterを使って静的化したWordPressサイトと、通常のWordPress（動的）でどのくらい表示速度が変わるのか確認しました。
紹介ページや実際に使っている人のブログを見ているとおすすめする声が多かったんですが、「いやいや、そんなにうまくいかないでしょ？」と思っていました。結論から言うと表示速度めちゃ早いです。ただ、サービスの性質上手放さなくてはならないものもありますので、検討されている方は参考にしてください。
目次
静的化とShifterのメリット
ShifterのメリットとそれによるWordPressの静的化のメリットは以下です。
- WordPress管理画面は使うときだけアクセスし、それ以外は起動していないため、セキュリティの不安がほぼなくなる
- 静的表示のためデータベースのリクエストがなくなりパフォーマンスアップ＝表示速度爆速
- HTMLページのためサーバーがはるかに落ちにくい
- サーバーWPやプラグインのバージョンアップ作業がなくなり運用が楽
なので、向いているサイトとしては
- コーポレートサイト
- 採用サイト
- イベントサイト
- ランディングページ
とかですかね。頻繁に更新するようなメディアサイトだと静的化のための生成に少し時間がかかるので手間です。コメントやサイト内検索も別に考えなくてはなりません。
イベントサイトなんかは終わってしまえばアーカイブのために残しておくようなものなので、逆にWordPressで運用しているとアップデートによるデメリットの方が大きいです。HTMLで静的化してしまった方がはるかに楽ですね。
ランディングページをサイト内でいくつか管理している場合もメリットが大きいと思います。広告配信していて、アクセス取りこぼしなどは避けたいですから、リクエストが増えないHTMLで表示するのはリスク低下になります。
Shifterで静的化したサイトと通常のWordPressサイトの表示速度の検証
検証方法として以下のツールを利用し、トップページを検証しました。実際のウェブサイトに近づけるため、よくあるようなコーポレートサイトのサンプルコンテンツをいれています。
- Lighthouse
- GTMetrix
- Pingdom Website Speed Test
- Developer ToolsによるTTFB
環境:
- Shifter Static
- mixhost
Shiterとの比較サーバーはレンタルサーバーのmixhostです。標準でHTTP/2が有効となっており、安価の割にWordPressが比較的快適に動くサーバーです。
テーマ: Astra
軽くてページビルダーとの相性もいいテーマ、Astraです。執筆時点で毎日5,000〜6,000ダウンロードされていて人気なテーマの一つです。
導入プラグイン:
- Elementor
- Elementor Pro
- Smush Pro
ページビルダーで有名なElementorを入れています。Pro版の機能はデモコンテンツでは使っていませんが、実際のサイトに近づけるため有効にしています。
デモコンテンツのインポートにおいて画像容量が大きすぎたため、画像最適化のためにSmush Proプラグインを導入しました。Shifterは画像圧縮実施後にプラグイン自体を無効としています。（700KB程度の圧縮効果）
※そのほかテーマ側で自動でインストールされるプラグイン有り
デモコンテンツ: Astraテーマによるスターターテンプレートをインポート
コンテンツ量としては充分ですね。それでは検証結果いってみましょう。
Lighthouse
・静的（Shifter）
・通常のWordPress（mixhost）
Lighthouseでの計測は数字上そもそも高スコアということもなく、パフォーマンスのスコアだとShifterの方が8ポイント高い程度と、そこまで大きな違いは見られませんでした。ちなみに記事ベースのデモコンテンツを使うと100点近くなりました。（やはりトップページにコンテンツ詰め込みすぎるのは避けたいと再認識）
GTMetrix
・静的（Shifter）
・通常のWordPress（mixhost）
ページサイズはほぼ変わらないのに、静的が2.5秒に対し動的が5.8秒と読み込み時間に2倍以上の差が出ました。また、静的の方がリクエスト数が多かったです。
Pingdom Website Speed Test
・静的（Shifter）
・通常のWordPress（mixhost）
静的が0.7秒に対し動的が1.9秒と、こちらも読み込み時間が倍以上違う結果に。
Developer ToolsによるTTFB
・静的（Shifter）
・通常のWordPress（mixhost）
最初の1Byteが到着するまでの時間を指す、TTFB( Time To First Byte ) をChromeのDeveloper Tools上から確認しました。静的が12.31ミリ秒なので約0.012秒に対し、動的が857.89ミリ秒なので約0.85秒。静的の方がおおよそ70倍（！）早い計算となります。
GoogleのPageSpeed Insightsでは200ミリ秒以下に抑えろと言っているので、動的のほうはGoogleの指標より4倍も遅いことになります。
サーバーの応答時間は 200 ミリ秒以下に抑える必要があります。
サーバーの応答時間を改善する | PageSpeed Insights | Google Developers
結論
当然なんですが、静的化めっちゃ早い！データベースへのリクエストがなくなるため、体感でも相当早いです。特にTTFBが圧倒的に差が出ているように、ページがすぐに表示されます。WordPressサイト特有のリンクを押したけど画面が切り替わらなくてくるくる回っている現象は全く感じませんでした。
これならページビルダーで作成したもっさりしたページや、重くて使い物にならないWordPressサイトともおさらばできそうです。
Shifterでの静的化のデメリット
セキュリティやパフォーマンスの良いところばかり目に付きますが、当然ながら静的化による失うものがたくさんあります。
データベースへのアクセスが必要なものは導入不可
以下のように、データベースへのアクセスや、DB連携、DBにアクセスして表示するものなどは基本的に不可です。
- 問い合わせ等のフォーム全般
- サイト内検索
- コメント
- ログインといった会員機能
- サイト内での商品購入
- 関連記事 / 人気記事表示
その他Shifter独自の環境により実施不可や影響があること
あまりWordPressサイトの実例として多くはないかと思いますが、マルチサイトは不可。そしてShifterのサービス上、サーバーレスのためPHP等のミドルウェアは自動アップデートされ、WordPressやプラグインも常に最新にアップデートされるようです。なので例えば新しいPHPにテーマやプラグインが対応しておらずエラーが出るといったことはありそうです。
追記： WordPressを都度起動する仕様のため、予約投稿ができません。（たまたまWPが起動していれば可だが、その他問題が起こる可能性アリ）
そのため、予約投稿する方法が公式に紹介されています。
また、SSHやFTPが使えないため直接サーバーにアクセスして何かするということはできないようです。サーバー内で別のシステムとの連携をしているケースなどは導入できませんので、Headless CMSとかが選択肢に上がってくるのでしょうね。
使えないプラグイン
Shifter内で使えないプラグイン、利用すると性能が落ちるプラグインなどがあります。WordPressプラグインは相当数登録されているため全部のプラグインを検証できないようですが、例えば以下のようなプラグインは使えないと考えたほうがよさそうです。
- キャッシュ機能などShifterが有している機能と衝突するもの
- .htaccessにアクセスするもの
- 高負荷がかかるもの（関連記事表示やランキング表示等）
- 更新されていないもの
- PHPを実行するもの
- そのほかShifterと機能が重複するもの
静的化するのかどうかは総合的にみて判断が必要
静的化のメリットはセキュリティやパフォーマンスの観点から非常にメリットが大きいですが、上記のようにデメリットのインパクトも小さくないので、導入には検討が必要です。
- 静的化することで致命的な機能不足がないかどうか（会員機能や商品購入など）
- 得られるものより失うものがないかどうか（DB連携や利用プラグインが不可などないか）
- 運用上問題ないかどうか
特に運用は今までと大きく異なります。ログインURLさえあれば誰でもいつでも更新して反映できていたのが、必要なときにWordPressが起動することになるため、WordPressの管理方法が通常と異なります。記事やページ追加後はHTMLページの生成が必要となるため、Shifter上から静的データを作成します。慣れれば難しいことではないと思いますが、現場の記事執筆者の運用ルールの変更が出てきますね。
これから新規で制作するサイトは要件をShifterに合わせていけばいいですが、すでに稼働中の案件の場合、各要件の洗い出しをして、もしそれが機能上動的でしか再現できないようであれば代替機能が実装可能か、実現可能かといった検証が必要です。
それらを鑑みた上で、静的化のメリットが大きい場合に変更するべきと感じます。今後はコンテンツ管理と表示側はますます分離していき、ウェブ自体のリソースはユーザビリティやSEOを考えると静的化の方向になると個人的には思っているので、致命的なものではなければ今回を機に静的化に変更するというのはアリだと考えています。
コメントを残す