アクセスのたびに作るか、あらかじめ作っておくか
従来のWordPress（動的構成）は、アクセスがあるたびにWebサーバー上でPHP（Webサイトを動かすプログラムの処理系）が動き、データベースに問い合わせてHTMLページをその都度組み立てて返します。実行環境が常時インターネットに公開されている状態で、ここが脆弱性（セキュリティ上の欠陥）を狙った攻撃の標的になります。
静的移行では、ページのファイルをあらかじめ作り置きしておき、アクセスに対しては生成済みの静的HTMLファイルだけを返します。公開サーバー上でプログラムの実行もデータベースへの接続も起きないため、SQLインジェクションやプラグインのRCE（リモートコード実行）のように、公開側で動くプログラムを狙う攻撃は成立しなくなります。
管理画面からの更新の仕方は変わらない
「静的にすると、管理画面から記事を更新できなくなるのでは」という心配があります。ハイブリッド静的移行では、そこは変わりません。
当方が組む構成では、記事の編集や管理を、アクセス元の制限や認証で保護した非公開のWordPress（管理専用の環境）で行います。更新を保存したタイミングで、公開用の静的HTMLファイルが自動で作られ、公開サーバーやCDNに配置されます。編集する側の手順は、いままでと同じです。
ただし、保存してから公開に反映されるまでには、作り置きの処理の分だけ時間がかかります。かかる時間はページ数と、全体を作り直すか変更分だけかで変わるため、構成を決めるときに実測して示します。この待ち時間が許容できるかどうかは、あとの適用判断に関わります。
移行の前後で何が変わるか
公開側から何がなくなり、何が変わらないかを並べます。移行後に自社の運用のどこが変わるかを見るための表です。
| 見るところ | 従来の動的WordPress | ハイブリッド静的移行後 |
|---|---|---|
| 公開側で動くもの | PHPプログラムとMySQLデータベース | 静的ファイル（HTML・CSS・JavaScript・画像）のみ |
| 公開側の更新作業 | プラグインとテーマの更新に追従し続ける | 更新の対象が公開側から無くなる。管理用のWordPressでは引き続き必要 |
| 表示までの処理 | アクセスのたびにサーバーが組み立てる | 配信元（CDN）が作り置きのファイルをそのまま返す |
| 公開側から狙える攻撃 | 脆弱性を突いた侵入やデータベースの改ざん | 公開側で動くプログラムを狙う攻撃は成立しない。管理用の環境と外部サービスは対象に残る |
自社が適用できるかは、機能ごとに決まる
静的移行の可否は、サイト全体では決まりません。使っている機能を1つずつ見て、そのまま移せるか、別の仕組みに置き換えるか、公開側に残すかを決めます。1つのサイトの中で、この3つが混ざることになります。
| 機能 | 扱い | 確認すること |
|---|---|---|
| 記事・固定ページの表示 | そのまま移せる | なし。事前に作り置きして配信する |
| 問い合わせフォーム | 置き換える | 添付ファイルの受け取り、自動返信の要否、送信内容の保存先 |
| サイト内検索 | 置き換える | 対象のページ数。数が多いと外部の検索サービスが要る |
| 会員向けの非公開ページ | 条件による | 誰にどこまで見せるか。ページ単位の出し分けなら方法があるが、利用者ごとに内容が変わるなら公開側に処理が要る |
| 予約・決済・在庫の表示 | 公開側に残る | その場で結果が変わる処理は事前に作り置きできない。外部サービスに寄せるか、その部分だけ動的に残す |
向かないサイトの条件
次に当てはまる場合、公開側から実行環境を外しきれません。無理に進めても動的な部分が残るため、期待した効果が出ないことがあります。
ただし、当てはまる項目があっても全体を諦める必要はありません。サイトの大半を静的にして、動的な処理が要る部分だけを分けて残す形も取れます。減らせる範囲がどこまでかは、機能の棚卸しをしないと決まりません。
- 利用者ごとに表示内容が変わる：ログイン後のマイページ、購入履歴、在庫や価格の即時反映など。あらかじめ作り置きできないため、その処理は公開側に残る。
- 更新から公開までの時間を秒単位で詰めたい：静的移行では、保存のあとに作り置きの処理が入る。この待ち時間を秒単位まで詰める必要がある用途には合わない。
- 公開側でしか動かせない仕組みに依存している：特定のプラグインが公開側のPHPで動くことを前提にしている場合、代替を探すか、その機能を諦めるかの判断になる。