WordPressからGatsbyJSへ。phpからReactへ。今こそ静的サイトへ。

この数年は、ウェブサイトを丸っと制作する案件が多い。サイトの内容や予算、そして知名度からくる「通りの良さ」から、サイトの基盤は大抵の場合WordPressに落ち着くわけだが、中には「コンテンツを簡単に追加したいけど、WordPressを使うような規模でもないんだよな」というものも多く、もっと柔軟でフットワークの軽いCMSがないものか、漠然と思っていた。

一方、この春から夏にかけて、大規模なWordPressベースのサイトをほぼ一人で設計・開発していた。こちらはカスタムフィールドを使いまくりで、もはやWordPressの必然性あるの？というもの。そんなこんなで、正直もうWordPressはいいやってモードになっている。

MWS積年の課題をどう解決すべきか？

実は2020年の春はMoto’s Web Serverの大規模リニューアルが一大プロジェクトになるはずだった。25年前に生まれたこのサイトは、時代時代で様々な技術を基盤としつつも、根幹は常に「手書きの静的HTML」というスタイルを貫いてきた。そのプリミティブさが功を奏して25年間も続いてきたのだが、正直いろんな綻びがあるのも事実。

• サイト全体がレスポンシブに対応できていない
• HTMLヘッダーやグローバルメニューなどが共通パーツ化できていない
• 忌まわしきテーブルレイアウトがそこら中に残っている
• コンテンツとHTMLがガッツリとこびりついて分離できない
• サイトマップを作れないなどSEOはほぼ皆無

こうした課題を一気に解決するには、CMS、それこそWordPressを導入するのが常套手段だし、実際に導入の意見も出ていた。春に改修がスタートしていたら、多分MWSはWordPress化されたのだろう。しかし降って湧いたコロナ禍において、年初に立てた計画は順当に狂っていった。そして最近よく耳にする「ニューノーマル」という言葉を「決して元には戻れない、新しい標準」と捉えるなら、ここは一つ、常套手段は捨ててみよう。そして何を新しく拾うべきか探ってみよう。その結果として出てきたのが「静的サイトジェネレータ（SSG）」だった。

動的CMSではなく静的なSSGという技術トレンド

思い返せば去年の暮れに友人から「SSGが熱いっすよ」と言われていて、なんとなく頭の隅っこにはあったけど、ずっと隅っこのままだった。それが半年経っていろんなことが巡り巡って中央に出てくることになる（こういう経緯を経たものをタイミングよくキャッチすると、結果として息の長いものになることが自分の経験ではとても多い）。

この数年、SSGはトレンド状態にあるようで、調べてみると様々な種類があった。大抵は、昨今の潮流ともいうべき言語やフロントエンド技術と結びついている。Vue.jsならVuePress、Go言語ならHugo、ReactならGatsbyやNext.jsといった具合で、総じて「WordPressのオルタナティブ（代替）を作ろう」という立脚点から生まれているように思える。

今一度、WordPressがもたらした意義を考えてみると…

• 記事コンテンツや様々な情報をデータベースに登録するための使いやすい仕組みが揃っている
• データベースから情報を取得して、ページに生成する仕組みが揃っている
• 世界中で使われていることから、リソースが充実している

これらはどれも素晴らしいもので、その意義は世界中のサイトの3分の1がWordPressで作られているという事実が証明している。でも技術が進んでいくと、こういう発想も出てくる。

• APIがこんだけ増えて、いろんなところに情報が点在する今となっては、記事コンテンツを一つのデータベースにまとめておくことないよね。
• ページにアクセスされるごとにデータベースから情報を取得して、PHPでレンダリングしてページを生成するのって処理コストが大きいなぁ。
• 世界中で使われているとその分狙われやすく、セキュリティ対策でアップデートの雨あられ。

詰まるところ「CMSとWebサイトをいろんな意味で分離させたい」というニーズが高まっているのが、今の状況とも言える。

さて前述の通り、SSGには様々な種類があり、それぞれいろんな設計思想をもっている。どれをチョイスするかは、その後の使い勝手や技術の習熟にも影響してくるわけで悩みどころだ。

React由来のGatsbyJS。その特徴は？

今回、自分はReactベースのGatsbyJSに着目した。Reactの良さは、Webページの要素をパーツ化して再利用しやすいのと、仮想DOMによってページの表示処理が爆速になるところ。GatsbyJSのサイトに行くと最初に目に飛び込んでくるのが「Fast in every way that matters（速いってことはあらゆる意味で重要だ）」である。

ReactそのものはWebアプリケーション開発に強いものだけど、自分がやりたいことはWebページ制作。そこでGatsbyJSを使えばWebページ制作の範疇でReactを覚えればいいと思ったわけ。かくいうReactの公式サイトもGatsbyJSで作られているというので、技術に対する筋も良さそうだ。

今回はGatsbyの特徴を活かしつつ、以下のようなWeb開発ワークフローを目標にした。

• GatsbyJSは、外部から様々な形式のデータを取得してページを生成することに長けている。そこでサイトの元となるコンテンツは、Markdownファイル、APIから取得したJSON、「コンテンツ置き場」としてだけWordPressを使う。
• GatsbyJSの売り文句である「爆速パフォーマンス」を体感するためにも、WordPressベースのサイトに対して、Google Lighthouseのスコアをアップさせる。
• ネットに公開する本番サーバーはHTMLファイル群を置くだけの場所となるので、ミドルウェアは一切動かさずにセキュリティを高める。
• 生成した静的HTML群の本番サーバーへの適用はGitを使ってコマンド一発で済ませる

一通りのことを理解するまで一ヶ月ほど悪戦苦闘したけど、結果的にはすべてが実現できた。このワンダウォール・ネットのWebサイトはGatsbyJSで生成され、上記のワークフローでもって稼働・更新されている（あなたが今読んでいるページもそう）。ちなみにWordPressを動かすサーバーはもうネットに広く公開する必要がないので、自分の作業用サーバー上にDockerを使ってひっそりと構築してみた。

結果、WPよりも現代的なワークフローになりました

古いHTMLをMarkdownファイルに置き換える

このサイトには古いページも多く、もはやHTMLと一体化してしまっていて原稿だけを抜き出すのは至難の技となっている。しかしそこは諦めず、ファイルメーカーProを使って「Webページにアクセスしては、テキストだけを抜き出してはデータベースに蓄積し、最後に一気にMarkdownファイルへ書き出す」システムを作った。まだ本番投入していないが、これで10年前のブログ記事も最新のページに蘇る目処がついた。

パフォーマンスは10ポイントアップ

パフォーマンスについてはGoogle Lighthouseのスコアで10ポイントほどのアップが達成できた。WordPressに蓄えた画像リソースがまだ最適化できていないので100点満点は取れていないが、パーフェクトへの道筋は見えている。

Gitを使ってコマンド一発でサイト更新

GatsbyJSを使う人たちは技術者が多いので、githubにリポジトリーを立てて静的HTMLソースを管理し、GitHub PagesやNetlifyといったWebホスティングサービスに自動デプロイするところまでが技術パッケージのようだ。自分はAWS Lightsailでサーバーを立て、自前のgitで運用している身なのでその環境に合わせつつ、ターミナルで「publish」と一発コマンドを打つことで、GatsbyJSのビルドプロセスが走り、生成されたファイルをGitにプッシュし、サーバー側ではGit フックを使ってWebサーバーに自動デプロイするというスクリプトを組んだ。

…とここまで、技術的な裏付けを一切書かないまま饒舌になりすぎた。次の記事ではGatsbyJSを実践する中での技術的な苦労話をまとめてみようかなと。