WordPressからFirebase＋Nuxt.jsのHeadless CMSに完全移行するまでの記録 ①導入・技術選定
Contents
前置き
2019年4月現在、このブログはWordPressで開発・運用していますが、
それに伴って生じている様々な問題を解決するために、脱WordPressすることを決めました。
主な理由は４つ。
①サイトの速度が明らかに遅いため、Lighthouseなどのスコアが上がらないのがSEO・利便性の両面で不利。jQueryやPHP・サーバー応答速度といったボトルネックは、WordPressを使っている限り解消することができない
②NetlifyやFirebaseなどの無料で使えるサービスが充実してきている中、レンタルサーバーを使っているのはコスパも悪い
③今後のことを考えると、記事データはMySQLではなくJSON形式の方がバックアップしやすく安全
④Vue.js、CSSフレームワーク、PWA・AMPなどといった新しい技術とWordPressの相性が致命的に悪すぎる
これに加えて、Gutenburgとかの不要な新機能に付き合いたくないとか、PHPにもう関わりたくないとか、勉強になりそうとか、いろいろあるのですが、
やはり一番の要求はサイトの速度です。
4月に割と大規模な改修を行ったのですが、上記のように軽量っぽいサイトであってもかなり低めのスコアが出てしまいます。
まあ部分的にVue.js＋WP REST APIを使ってしまったのも悪いのですが、ただそれをせずにWordPressにHTML出力をさせると余計なクラスばかり付与されてCSSフレームワークと共存できず……。
REST API部分は読み込み後回しにしているので、上記のように初回ペイントだけはマシな速度なのですが、それでも遅い。
というかそもそも、どのJSをheadで読み込んでどれを後回しにするのかを全て頭で考えるのが無駄な作業すぎるし、プラグインのAutoptimizeを使うとこの依存関係がごちゃごちゃになって表示できなくなり、jQueryやVueやaxiosは他のJSより先に読み込まないといけないのでこのあたりの重いJSファイルにasyncやdeferを付けるとバグるという、何とも本末転倒な感じに。
改修作業をすればするほど不毛な印象を受けてしまい、これを乗り越えるにはWordPressを捨てるしかないと決断しました。
WordPressから移行してどういうサイトにしたいかというと、
①記事をマークダウン形式で投稿し
②JSON形式で保存し
③JavaScriptでレンダリングし
④静的サイトに事前出力したい（できれば）
という構成です。④については後述します。
2020.05追記
このサイトは既にFirebase/Nuxt構成への移行を完了しており、2020年2月よりFirebase Hosting上で運用されています。最終的な結果を読みたい方は、この記事の内容は無視して下の記事をご覧ください。
Nuxt.js＆Firebase で WordPressブログをフルリニューアルしたまとめ
2020年2月に、WordPressブログ（このサイト）をFirebaseでフルリニューアルしました。 現在このサイ... 続きを読む
以下に記載している内容は2019年5月時点の想定で書かれており、この1年で古くなったり実際に実装してみると上手くいかなかったりした内容なども含まれています。あらかじめご了承ください。
理想の実装（JAMstack）
上記の要件でブログを作るのであれば、現時点ではおそらくNuxt.js + Contentful + Netlifyという実装が最適解なのだろうと思います。
爆速を求めて個人ブログをWordpressからGatsbyJS+Contentful+Netlifyに移行した話 | blog.potproject.net
Nuxt.jsとContentfulでモダンなブログを構築してみた – Qiita
NuxtではなくGatbyJS、ContentfulではなくGraphCMS、NetlifyではなくGitHub Pagesなどの違いはありますが、
この手の「Contentfulで更新されるたびに静的サイト生成してNetlifyでホスティングすれば無料で爆速で神」という記事は本当にたくさんあって、
実際タイトル通りの爆速を達成しているサイトもたくさんありますし、新規に立ち上げるブログであれば間違いなく今一番良い方法だと思います。
ちなみに、こういった実装にJAMstackという名前が付いているようです。
Modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.
「クライアントJS、再利用可能なAPI、前もって構築済みのHTML」の組み合わせを指す言葉。格好いいし、格好いい名前がついている技術なのでたぶん流行る。
ただ、その手のサイトの多くが、あくまで技術検証を目的にしていて、記事数がそこまで多くない（サイトの制作時点では10個に満たない）ことを前提にしています。
しかし、このブログは現時点で3700件以上の記事と1500枚以上の画像があるわけで、
例えばContentfulの「レコード5000件まで無料」という、普通であれば絶対に引っかからない制限に引っかかってしまうのです。
また、静的サイト生成に関しても、3700件のページ・カテゴリー・11年分の月別アーカイブを都度再生成するのがどうなのかという問題もあります。
技術選定
フロントエンド：Nuxt.js
私がVue.js・Nuxt.js大好きなのでここは確定。
以前、WP REST API + Nuxt.jsでのサイト製作を試していたのですが、結局WordPressを捨てないとどうしようもないと気づきました。
データベース：Firebase
上述の理由よりContentfulでの記事管理が難しそうなので、
今回はFirebaseのFirestoreに全記事を格納しようと考えています。
Firestoreのデータ制限がどれほどかわかりませんが、料金説明によると1GB（チャットメッセージ2000万件分）までは無料なので大丈夫でしょう。
Firestoreは少しだけ触ったことがありますが、where・orderby・limitといった指定で絞り込みができるというのは、WordPressのget_postsに挙動が似ているので、使いやすいのではないかと思います（参考：Cloud Firestore でのデータの並べ替えと制限）
ちなみにFirebaseの最大のウリであるリアルタイムデータベースについては今回は無視する予定です。たくさんの人が投稿するサービスならともかく、個人のブログがリアルタイムで更新される必要はあんまりないし、最新記事やコメントについてもリロード時に再取得で問題ないでしょう。
Contentfulと比較した場合の最大の欠点は、新規記事を追加するためのエディターを自作しなければならないことにあるような……。
ホスティング：Netlify or GCP
これは迷っています。
JAMstack的な実装で、静的サイト生成を行うのがパフォーマンス的には最速なのでしょうが、
記事を投稿・更新するたびにnuxt generateで4000ページを再構築するというのが、果たして現実的なのかどうかについて疑問が残ります。無料の範囲を超えてしまうのではないかと。
このあたりを、payloadなどの方法でどうにかなるのであれば、Netlifyにホスティングして記事投稿のたびにGitHubにpushすれば良さそうですが、
そうでなければ、GCPのNode.jsで普通にサーバーサイドレンダリングでも良いんじゃないかなとも思っています。
SSRと静的サイト生成を、ほぼ同じコードで開発できるのがNuxt.jsの利点ですから、このあたりは開発の最後に決めようと思っています。
今後の道のり
管理画面
- 記事投稿・編集するためのエディター画面を作成
- Firestoreのデータ設計（記事・コメント・メディアなど）
- Firebase Storageへのファイル（画像）のアップロード
- 管理画面上で画像の削除、カテゴリーの編集など
WordPressからのインポート
WordPressの画像データをFirebase Storageにアップ
WordPressの各データをFirestoreに書き込み
- 投稿
- 固定ページ
- 投稿タイプ
- コメント
- カテゴリー
- タグ
閲覧画面
- Firestoreのデータを呼び出すWordPressの各ページを、URLを変えない形で実装
- ページ送りや検索機能
- コメント機能（コメントのみ非ログイン時に書き込めるよう権限設定）
先は長いです。気が滅入ったという方は、WordPressかContentfulでどうにかできないかを考え直しましょう。私はファーストペンギンとしてとりあえずチャレンジしてみます。
追記
この記事はあくまで予定なので後で書き直す可能性も多々あります。ご了承ください。
質問、指摘、提案、何かあったらコメントお願いします。
あと、最終的に今回やったことをNuxt.jsのプラグイン化してみんなが簡単にWordPressからFirebaseに引っ越しできるようになるのがハッピーな気がするのですが、プラグインを作ったことがないので協力してくださる方がいたらそちらのご連絡もお待ちしています。