Shifter は WordPress のデータから静的な HTML を生成しホスティングしてくれるサービスです。実際に使ってみてメリット・デメリットが分かってきたので、まとめてみました。
これから導入を検討している方の参考になれば幸いです。
shifter のメリット
ページ表示速度が早い
実際に計測したわけではありませんが、Shifter では静的 HTML を提供するので普通に WordPress を使って MySQL/PHP を動かしたときよりかは表示は早いです。SEO の観点から見てもページ速度は重要なのでこれは大きいですね。
WordPress でエラーになった時やアクセス過多でサイトが落ちない
WordPress 側でなにか合っても、サイト側は事前に生成された HTML を提供するので、WordPress が原因でサイトが落ちるということはありません。これは静的ジェネレーターの強みです。
プラグインや本体のアップデート、アップロードミスなどで真っ白に!となることがあるあるの WordPress ですが、そういったことがないのは安心です。
何かあった時、すぐに前のバージョンに戻せる
Shifter では WordPress で記事を投稿したり、テーマを修正しただけではサイトに反映されません。ここから HTML を生成する「Generate」と呼ばれる作業が必要になります。ここで生成(Generate)した1世代のサイトデータを「Artifact」と呼びます。
この生成した Artifact を Publish(公開)することで初めてサイトに反映されますが、反映した後に何かミスを発見し戻さなくてはならない時、一世代前の Artifact を公開し直すことですぐに戻すことができます。
この切り替えは一瞬で終わるので、このあたりも静的サイトジェネレータの良いところですね。
公開状態以外の Artifact の確認ができる
Generate した Artifact は一覧に表示されていますが、目のアイコンをクリックすることでその時点のデータの確認をすることができます。
Generate したあと Publish する前にミスがないかの確認もできますし、昔のデータを一時的に確認したい!というときにも便利な機能です。
公式サポート対応が早い
Shifter のページに入ると分かりますが、右下のサポートチャットから質問することができます。何度か聞いたことがありますが、返信も早いので今のところは安心です。
セキュリティが高い
エンドユーザーには静的 HTML を提供するので、WordPress やテーマ、プラグインコードの脆弱性などが突かれる心配はなくなります。
shifter のデメリット
shifter ではできないことがある
- PHP での動的処理ができない … エンドユーザーがアクセスするのは生成された HTML ファイルなので、動的処理はできません。
- 使えるプラグインが制限される
- zip ファイルがアップロードできない
多分他にもありますが、自分がやろうとしてできないのか〜と思ったのは上記。
予約投稿機能が使いにくい
Shifter では WordPress の予約投稿を使うことができません。代わりに「Scheduled Publish」という機能があります。これは「 指定の Artifact を特定の日時に Publish にする」というものです。
問題1 :Scheduled Publish の管理
この Scheduled Publish は、
- WordPress 側で予約投稿したい記事を投稿、公開しておく
- Generate
- 即時 Publish せずに、Scheduled Publish で Publish 日時を設定
上記のようなフローになりますが、もしここで「予約した日時の前」にテーマや中身の修正が入った場合、
- 急遽テーマ修正、WordPress に反映
- Generate
- Publish
を行うことになります。
この時 WordPress 側では「Scheduled Publish で公開したかった記事はすでに投稿されている」ため、その記事を非公開にせずに Generate してしまうと、その記事が含まれた Artifact が生成されてしまいます。
複数人で管理している WordPress の場合は Scheduled Publish を使用中の Generate/Publish は注意したほうがよさそうです。
問題2:予約日時を未来に設定できない
WordPress では、公開日を未来に設定すると自動的に予約投稿の扱いになってしまうので、現在日時以前の日時を公開日に設定する必要があります。
ですが、予約投稿したいのであれば未来の日時を設定したいはず(フロント側に表示しない場合はあまり関係ないですが)。
でもそうすると予約投稿状態になり、Generate してもその投稿は Artifact に含まれません。
無理やり未来の日付を設定しつつ公開状態にする方法もありそうなのですが、カスタムフィールドで投稿日表示上書きフィールドのようなものを作るのが手っ取り早いかなと思います。
Shiter と全く同じローカル環境は作れない
Shifter Local と呼ばれる擬似的な Shifter ローカル環境があり、「実際にどのページが Generate されるのかの一覧」を確認することはできますが、実際に Generate した結果をローカルで確認することはできません(そのシステムが Shifter の売りでもあるので当然ですが…)。
また「実際にどのページが Generate されるのかの一覧」には入っているのに、実際に Generate したら生成されなかったページがありました。Shifter に修正内容を反映 -> Generate してからでないと確認できないのでかなり厄介です。
テーマ更新フローの違い
これは Github 等に慣れていればそこまで問題にはならないかもしれません(自分の場合は Github と連携することで、Github のテーマリポジトリをそのままデプロイできるようにしています)。
Shifter の場合は FTP クライアントで直接接続などはできません。Github 連携やプラグインを使用する必要があり、FTP クライアントなどで更新している方は今までのやり方と違うため注意が必要です。
リダイレクトの機能が制限される
apache の .htaccess といったリダイレクト処理はもちろんのこと、PHP によるリダイレクト処理を書くことはできません。
ただ Shifter では Redirection という WordPress プラグインを使うことができるので、リダイレクト自体は可能です。ですが、一部機能が制限されています。2021/8現在、個人的に困ったのは
- 正規表現が使えない
- #anchor のようなアンカーリンクに対してリダイレクトができない(リダイレクトはするものの #anchor/ のように trailing slash が強制的に入るので 404 になる)
の2つでしょうか。正規表現が使えないのは場合によっては結構辛かった…。2つ目のアンカーリンクはあまりないと思いますが、知らないとほぼ確実に 404 にいきます。またこれらはビルド後でないと確認できないので注意が必要です。
あまりにもリダイレクトの量が多い場合、javascript でリダイレクトするのもありなのかな、と思います。
Shifter に向いているサイト/向いていないサイト
以上に挙げたメリット・デメリットから、どんなサイトが Shifter に向いているのかまとめてみました。
Shifter に向いている
- WordPress に複雑なカスタマイズをしていない
- サーバーを管理したくない
- 投稿/テーマ更新頻度が低い
- 予約投稿をほとんどしない
- セキュリティを高めたい