• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

株式会社ハイファイブクリエイト

東京都を拠点にWebサイト制作やシステム構築、WordPress保守管理やウェブコンサルティングを提供。

  • SERVICE
  • ABOUT
  • WORKS
  • BLOG
  • NEWS
  • CONTACT
ホーム / ブログ / WordPress / 静的化したWordPressは本当に早くなるのか?表示速度やパフォーマンスの検証と比較

静的化したWordPressは本当に早くなるのか?表示速度やパフォーマンスの検証と比較

池田祐太郎 | 2022年5月6日 更新 | 2020年6月20日 公開 コメントを書く

WordPressを使う以上、セキュリティリスク増加やパフォーマンス低下は避けられません。例えば、誰もがどこからでもログインでき記事を更新できることは便利な反面不正ログインのリスクがあるし、データベースを参照して関連記事や人気記事を自動で表示することはデータベースに負荷がかかりその分表示速度が犠牲になります。

そこでここ数年WordPress界隈を賑わせているのがHeadless CMSという、WordPressをコンテンツ運用で使って、実際のフロント側はReactやVueなどで取得して表示させてしまうという手法。これならWordPressの資産は活かしつつ、自由に表現できるしサイトの一部だけCMS化することも可能だし、セキュリティリスクが軽減できパフォーマンスの低下も心配しなくていいなど、いいことばかりです。ただ導入の敷居は低くないので、導入するかどうかは要検討。

一方、WordPress全体を静的化してしまうShifterというサービスがあります。

WordPressが静的化されて表示されるため、セキュリティのリスクはほぼ無くなって、データベースへのリクエストがなくなり表示スピードが爆速になるというサービス。

そこで今回、Shifterを使って静的化したWordPressサイトと、通常のWordPress(動的)でどのくらい表示速度が変わるのか確認しました。
紹介ページや実際に使っている人のブログを見ているとおすすめする声が多かったんですが、「いやいや、そんなにうまくいかないでしょ?」と思っていました。結論から言うと表示速度めちゃ早いです。ただ、サービスの性質上手放さなくてはならないものもありますので、検討されている方は参考にしてください。

目次

  • 1 静的化とShifterのメリット
  • 2 Shifterで静的化したサイトと通常のWordPressサイトの表示速度の検証
    • 2.1 Lighthouse
    • 2.2 GTMetrix
    • 2.3 Pingdom Website Speed Test
    • 2.4 Developer ToolsによるTTFB
    • 2.5 結論
  • 3 Shifterでの静的化のデメリット
    • 3.1 データベースへのアクセスが必要なものは導入不可
    • 3.2 その他Shifter独自の環境により実施不可や影響があること
    • 3.3 使えないプラグイン
  • 4 静的化するのかどうかは総合的にみて判断が必要

静的化とShifterのメリット

ShifterのメリットとそれによるWordPressの静的化のメリットは以下です。

  • WordPress管理画面は使うときだけアクセスし、それ以外は起動していないため、セキュリティの不安がほぼなくなる
  • 静的表示のためデータベースのリクエストがなくなりパフォーマンスアップ=表示速度爆速
  • HTMLページのためサーバーがはるかに落ちにくい
  • サーバーWPやプラグインのバージョンアップ作業がなくなり運用が楽

なので、向いているサイトとしては

  • コーポレートサイト
  • 採用サイト
  • イベントサイト
  • ランディングページ

とかですかね。頻繁に更新するようなメディアサイトだと静的化のための生成に少し時間がかかるので手間です。コメントやサイト内検索も別に考えなくてはなりません。

イベントサイトなんかは終わってしまえばアーカイブのために残しておくようなものなので、逆にWordPressで運用しているとアップデートによるデメリットの方が大きいです。HTMLで静的化してしまった方がはるかに楽ですね。

ランディングページをサイト内でいくつか管理している場合もメリットが大きいと思います。広告配信していて、アクセス取りこぼしなどは避けたいですから、リクエストが増えないHTMLで表示するのはリスク低下になります。

Shifterで静的化したサイトと通常のWordPressサイトの表示速度の検証

検証方法として以下のツールを利用し、トップページを検証しました。実際のウェブサイトに近づけるため、よくあるようなコーポレートサイトのサンプルコンテンツをいれています。

  • Lighthouse
  • GTMetrix
  • Pingdom Website Speed Test
  • Developer ToolsによるTTFB

環境:

  1. Shifter Static
  2. 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を考えると静的化の方向になると個人的には思っているので、致命的なものではなければ今回を機に静的化に変更するというのはアリだと考えています。

メールコンサルティング
WordPress保守管理サービス

Filed Under: WordPress 関連タグ:Webサイト高速化

池田祐太郎

WordPressの導入を10年以上にわたって手掛けており、主に小〜中規模のコーポレートサイト・ECサイト・ブランドサイト等の企画・開発・保守・コンサルティングなどを行ってきました。2012年にハイファイブクリエイトを創業し、現在はWordPressの保守やコンサルティング、ディレクションや開発業務などを担当しています。 プロフィール詳細

Reader Interactions

コメントを残す コメントをキャンセル

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

I agree to these terms.

この記事と関連する記事

WordPressのパフォーマンスチームがパフォーマンス改善プラグインをリリース
2022年3月9日
タグ: Webサイト高速化, プラグイン
カテゴリー: WordPress
KUSANAGIの技術を取り入れた最新Xserverに移行後のパフォーマンス比較結果
2022年2月25日
タグ: Webサイト高速化, サーバー
カテゴリー: WordPress
Xserver 新サーバー移行時は注意。発生したエラーと対応方法
2022年2月17日
タグ: Webサイト高速化, サーバー
カテゴリー: WordPress

人気記事

  1. git pull してもエラーが出てファイルが反映されないときの対処法
  2. 同一サーバー上に構築するWordPressのテスト環境の作り方
  3. WordPressの固定ページでタグやカテゴリーを使いたいときはカスタム投稿タイプを検討する
  4. サイト制作の要件定義書に普段書いている内容(ダウンロード可)
  5. WordPress において PHP 8.1 に更新していいかどうか検証
  6. [便利]困難な判断を10秒で AI が客観的に導き出すツールを試してみた

最初のサイドバー

WordPress保守管理サポート

Search

最近の投稿

  • [便利]困難な判断を10秒で AI が客観的に導き出すツールを試してみた
  • WordPress のクロスサイト・スクリプティング被害にあった事例を共有します
  • メール作業の生産性を向上させる最低限覚えておくべき Gmail のショートカットキー
  • タブ固定とタブ一発アクセスのショートカットキーの組み合わせでブラウザ作業の生産性を向上
  • メールフォームプラグイン MW WP Form を使いながら WP Rocket を使う場合にエラー回避する設定

カテゴリー

  • CSS初心者
  • HTML初心者
  • TIPS
  • WooCommerce
  • WordPress
  • エステサロン
  • お知らせ
  • キュレーション
  • サイトマップ
  • システム会社
  • デベロッパーツール入門
  • ブログ
  • ホームページ制作
  • ホームページ制作無料講座
  • メール
  • モバイル
  • 仕事のこと
  • 制作実績
  • 整体院
  • 美容院
  • 雑感

タグ

Android BtoC CMS css elementor git google workspace Gutenberg HTML iPhone jQuery Mac MAMP php SEO SNS ssh SSL Sublime Text Webサイト高速化 Windows WordPress WordPressカスタマイズ WordPressテーマ WordPress構築調査 WPRocket アクセス解析 アプリ クラウド クラウドソーシング サイト引っ越し サブスクリプション サーバー ショートカットキー スマホサイト スマートフォン ツール ブログ プラグイン マーケティング リニューアル 保守管理 改ざん 最適化 集客するサイト構築

アーカイブ

CONTACT

お問い合わせはこちら

Footer

  • PRIVACY POLICY
  • 情報セキュリティ基本方針
  • 特定商取引法に基づく表示
  • 転載/引用

© 2023 high five create All rights reserved.