初歩からの無職

ブログの脱WordPressとJamstack化

  • WordPress
  • Jamstack
  • GatsbyJS
  • Contentful
  • Netlify

このブログをWordPressからJamstack構成にしました。具体的にはフロントエンドはGatsbyJS、バックエンドはContentful、GithubでビルドしてNetlifyでホスティングしているという構成です。まだ細かい部分は作れてないですが、ある程度移行は完了したので移行に関する備忘録として残しておきます。

移行のモチベーション

サーバー代つらたん

移行のモチベーションの大きな部分として、放置気味のブログに対してサーバー代が割りに合わないという不満がありました。移行前はConoHa VPSにWordPressをインストールして運用していました。VPSサーバー代はサーバーサイドの勉強代として自分を納得させていましたが、Kusanagi環境に移行してからは自分で弄ることもほぼほぼなくなり、世の中も何となくサーバーレスイケイケな雰囲気を出しているので、徐々にこのまま払い続ける意味はあるのだろうかという感じに。

現在の構成は0円で運用可能です。それまで利用していたConohaVPSでは学割で1年分を事前購入しており、その残高が切れる12月のタイミングで移行しておこうと思いました。

脱WordPressの機運

WordPressはシェアが最も高いCMSで、個人ブログで使う上でも知見が集積しているのがその最大のメリットでした。テーマやプラグインのエコシステムも充実しており、何か問題に当たったときでもその解決法はほぼネットに転がっているので対処が容易です。

一方、LAMPstackなWordPressは、ローカルの開発環境を整えるのが地味に面倒です。その上、実際には気が向いたときに極稀に触る程度なので、ガッツリ開発環境を整えるほどのモチベーションも沸かず、結局本番環境にSSHして直接弄って済ませていました。

最大の脱WordPressの動機は、WordPressにロックインされた記事データのポータビリティを上げたいというものです。このブログは放置気味なので記事数こそ少ないですが、それでも数年走っているため、プラグイン構成などの変更、エディタも旧来のものとGutenbergのものが混在しており、記事のマークアップもかなり混沌していました。

Jamstackの恩恵

脱WordPressの選択肢としてのJamstackはかなり魅力的に思えました。ユーザーのリクエストに応じてページを動的に生成するWordPressと異なり、プリレンダリングされた静的ページを配信するわけなので、高いパフォーマンスとセキュリティが実現でき、それでいて個人ブログの規模なら上述のように無料で運用が可能です。

Jamstackの特徴としてフロントエンドとコンテンツが分離されており、記事はAPIベースのHeadless CMSで管理することで、ローカル環境でもAPIをコールすることで本番環境と同じようにサイトをビルドできます。このように分離することで、ブログ記事はHeadlessCMSで書くことだけに集中でき、ガワであるフロントエンドのソースコードはGitで管理できるので、よりメンテしやすくなります。それぞれのサービスやフレームワークも比較的自由に選定できるので技術的な面白さもあります。

移行作業

構成

以下の定番構成にしました。

  • Headless CMS: Contentful
  • フロントエンド: GatsbyJS
  • ホスティング: Netlify
  • ビルド&デプロイ: Github Actions

Gatsby+contentfulはStarterが充実しており、netlifyへのデプロイまで含めてドキュメントも充実しています。最初はNetlifyでビルドしながら移行作業をしていたのですが、無料のビルド30分の枠を越えて7ドル課金の罠にハマってしまったので、Github Actionsでビルドするようにしました。フロントに変更を加えたときはGithubにpushした時、Contentfulでコンテンツを更新した場合はWebhookでGithub actionsが走ります。

StarterはContentfulが出しているContentful Gatsby Starter Blogを使用しました。Contentfulのガイドに沿ってnetlifyに実際にホストするところまで簡単にできます。

WordPressからContentfulへの記事の移行

ネットに転がっているWordPressからContentfulのマイグレーションの記事の多くは数記事のテストサイトの移行が多くて手作業がほとんどです。対してこのブログは移行段階でWordPressに150記事ほどありました。手作業でいけんこともない微妙な数です。

contentfulはWordPressからのマイグレーションツールを公開していましたが、現在はサポートを切っています。調べた限りでは、必要な情報をWordPressから引っ張ってManagement APIを使ってContentfulにポストしていけば良さそうです。

しかし仮にContentfulに首尾よく突っ込めるとしても、そもそもの記事データをMarkdown形式に変換しておく必要があります。上述のように数年間の記事データにはWordPressプラグインの独自記法がハードコードされていたり、Gutenbergの導入など様々なHTML形式が入っていることが予想されます。そのため、150記事を当初の目的どおり統一されたMarkdown形式に変換するために下調べをしておくことが必要となります。

ここでぶち当たるのが時間の問題です。ConoHa VPSの残高は12月に切れるのに対し、移行を決意したいのは11月、うまいマイグレーションの方法や格納されているHTMLの味見期間なども含めると残り数週間で作業を完了させる必要がありました。

残り数週間でバラバラな記事データのMarkdownへの変換とContentful Management APIの学習を首尾よく完了させられるか?と腕を組んで考えていたわけですが、その考えてる時間手を動かして150記事を移したほうが早いと覚悟を決めて、泥臭い作業に入りました。

WordPress Rest APIで全記事データを落としてcontentをh2mでmarkdownにとりあえず変換して、あとは手動でおかしいところをチェックしたり、置き換えが必要なものも見つかってくるので別途考えていきます。

基本的にはプレーンなMarkdownに統一していますが、どうしてもフロントを見据えた記述が必要になる箇所も出てくるので都度考えていきます。以下は一例です。

過去の記事と向き合ういい機会とも捉えてたので昔の自分の記事を読みましたが、徐々に病んでいって面白かったです。

ハマったところ

Markdown変換のリンクミス

移行終了段階で[リンク](https://example.com)とすべきところがすべて[リンク](\"https://example.com\")となっていることに後で気づきました。面倒!

Importing and exporting content with the Contentful CLI | Contentfulを参考にContentful CLIで一旦exportして一括変換して再度importして対応しました。

Netlify 7ドルの罠

上にも書きましたが、Netlifyのビルド時間無料枠の30分を過ぎて7ドルの洗礼を受けました。Auto Publishingさえ止めてれば大丈夫だと勘違いしていましたが、裏でしっかりビルドは回っていたのが原因です。

対策としてGithub ActionsでビルドしてNetlifyにデプロイするように変更しました。フロントエンドの変更はリポジトリにpushした時点で、ContentfulからはWebhookでGithub Actionsが走るようにしています。

これらは以下の記事を参考にしました。

tracedSVGでビルドがクラッシュする

Gatsbyのイメージ処理は本当に優秀で、画像をロードするまでの間にプレースホルダー画像としてtracedSVGを生成して表示できるのですが、Netlifyでビルド時にクラッシュするようになりました。これはよく知られた問題で、色々調べたのですが解決法もよくわからなかったので、当面tracedSVGは使用しないことにしました。

移行してみて

無料で高パフォーマンスで良い感じ

とりあえず、当面のランニングコストがゼロになったのでこれからも安心して放置できます。パフォーマンスも向上しました。

initial-lighthouse-result

StarterテーマではLighthouseの評価はデフォルトで90超えでしたが、Google Analyticsなど外部スクリプトなど必要なものを色々入れて若干下がりました。パフォーマンスもグリーンにするためにチューニングの勘所を調べることになりそうです。

他の項目も以下の記事を参考にしました。

GatsbyでGoogle Lighthouseで満点を取るブログを一から作る - Qiita

メンテしやすくなった

Gatsbyはpluginが充実していて簡単に機能を組み込むことができますし、細かい部分は自前でReactコンポーネントを実装することができます。WordPressでは後々のメンテの手間を考えて極力既存のプラグインやテーマで済ませて自分で直接手を入れるのを忌避していたのですが、Reactのコンポーネントベースの設計は非常にわかりやすくて、後からもメンテしやすい気がしています。

GraphQLも必要な情報だけをfetchするので、REST APIのように処理を書く煩雑さもないですし、何よりどんな情報を引っ張ってきているかがわかるので、やはりメンテナンスしやすさにつながっている気がします。

なんというかサイトいじりの楽しさをもう一度思い出させてくれる構成で、ReactやGraphQLなどモダンな技術をお勉強する動機にもなりそうです。(やるとは言ってない)

Starterテーマはおそらく意図的に色々機能が不足しているので、いくつか自分で実装しましたが、足りない部品を作ってはめ込んでいくシンプルさに感動しています。楽しい。コンテンツとガワが完全に分離しているので、一からデザインを作り直すことも可能でワクワクします。

プレーンなMarkdownだけじゃ無理

記事のMarkdown化もしたので、Contentful以外のCMSに移す場合でも格段に記事の移行はしやすくなったはずです。とはいえ、プレーンなMarkdownのみで記事を管理したい!という極端な欲求だと、独自実装や埋め込みをしないといったストイックなレギュレーションが必要になって自分にとってはあまり現実的ではありません。

結局のところ、ある程度フロントエンドでの実装を踏まえた記述を決め打ちして、それに合わせてフロントの方で実装するということが必要です。

とりあえず移行したててまだ不足している機能が多いので、しばらく触って楽しもうと思います。