技術・Web 4年前

WordPressからFirebase+Nuxt.jsのHeadless CMSに完全移行するまでの記録 ①導入・技術選定

前置き

 2019年4月現在、このブログはWordPressで開発・運用していますが、  それに伴って生じている様々な問題を解決するために、脱WordPressすることを決めました。  主な理由は4つ。 ①サイトの速度が明らかに遅いため、Lighthouseなどのスコアが上がらないのがSEO・利便性の両面で不利。jQueryやPHP・サーバー応答速度といったボトルネックは、WordPressを使っている限り解消することができない ②NetlifyやFirebaseなどの無料で使えるサービスが充実してきている中、レンタルサーバーを使っているのはコスパも悪い ③今後のことを考えると、記事データはMySQLではなくJSON形式の方がバックアップしやすく安全 ④Vue.js、CSSフレームワーク、PWA・AMPなどといった新しい技術とWordPressの相性が致命的に悪すぎる  これに加えて、Gutenburgとかの不要な新機能に付き合いたくないとか、PHPにもう関わりたくないとか、勉強になりそうとか、いろいろあるのですが、  やはり一番の要求はサイトの速度です。
1555691656937  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上で運用されています。最終的な結果を読みたい方は、この記事の内容は無視して下の記事をご覧ください。  以下に記載している内容は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. JAMstack | JavaScript, APIs, and 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万件分)までは無料なので大丈夫でしょう。 1555770518405  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の利点ですから、このあたりは開発の最後に決めようと思っています。 ...

comment  2
favorite  1