5/21（月）のWe Are JavaScripters!でWordPressのフロントエンドにGatsbyを採用した話をしてきました。

前回のRoppongi.js#2でGatsby + Netlifyの爆速開発をLTしてきたのですが、その続編の話になります。

> スライドスライド

https://speakerdeck.com/mottox2/wordpress-gatsby

> モチベーションモチベーション

内製出来る体制がありフロントエンドエンジニアがWordPressを担当していると前提の元でのお話です。
エンジニアの工数が割けない状態であればWordPress単体で使い続けるのがいいと思います。

簡単に言うとWordPressはCMSとして想定された使い方以外をされると非常にしんどい と思っています。
単純なブログならWordPressは非常にマッチしていると思うのですが、サービスのランディングページやコーポレートサイトなど、更新系のページ（ニュースやブログ）だけでは収まりません。おそらくトップページやサービスの価格ページ、経営者の声やアクセスページなども存在すると思います。
WordPressには「固定ページ」という機能もあり、そういったページを管理出来るのですが、WordPress上で編集する必要があるためちゃんとやろうとするとしんどさが残ります。また、昨今の雰囲気であればGitなどのバージョン管理システム上で管理したいでしょう。npmのライブラリを使えたら便利です。

そういったしんどさから抜け出すために、WordPressは記事編集とAPIによる記事の出力に特化してもらうと話が楽になっていきます。

> JSフレームワーク上で開発するJSフレームワーク上で開発する

WordPressにはREST APIが用意されているため、APIを叩けば記事は取得出来ます。そうなるとViewをどういった方法で開発していくかを考えることになります。

サービス開発でも使われるReact, Vueのスタックに合わせていくのがよいでしょう。
しかし、ログインを伴わないWebサイトはSEOの都合を考える必要があります。つまりSSR（サーバーサイドレンダリング）が要件に入ってくるでしょう。
SSRを実装することはそんな大変ではありませんが、サービスLPやコーポレートサイトのようなサイトのために独自設計するのはコスパが悪いし、引き継ぐ時も大変になってきます。なので、SSRに対応したフレームワークを利用するのが現実的な選択になっていきます。

ここで出てくる選択肢というのは、ほぼ2択だと思っていてReactベースで実装されている静的サイトジェネレーターのGatsbyか、VueベースのフルスタックWebフレームワークのNuxt.jsです。

※ 最近、WebフロントエンドエンジニアでjQueryを使ったことがない方に合ったことがあるので、jQueryの経験がないWebフロントエンドエンジニアは増えていくと思われます。

> なぜGatsbyを選択したのかなぜGatsbyを選択したのか

単純に会社でRailsのWebpackerでReactが動いていたという点が大きいのですが、Nuxtより書き方が揺れないという点を評価しています。

Nuxt.jsは非常に便利で、今自分が新規事業をやるとしたら十分選択肢に入ってくるものだと思います。
自分がサーバーサイドを書くときはRuby on Railsを好む理由である、実装する時に書き方を迷わないのが大きな利点だと感じています。フロントエンドにレールを敷いてくれそうなフレームワークだとは思っています。
ただ、今回のスコープである、サービスのLP、コーポレートサイトに関しては少しスコープが広すぎると感じました。

一方Gatsbyは静的サイトに特化していることもあり機能と拡張性は劣ってい
ます。
以下のスクショはGatsbyの公式サイトで紹介されている図なのですが、Data SourceはGraphQLを使ってViewに取得するという設計になっています。
何が嬉しいかというと、データの取得ロジックとViewが明確に分けられる点です。
明確に分けられるので、データの取得ロジックは基本的にPlugin経由で取得するのが主流になっており、取得したデータを使ってViewを開発することだけ気にすればサイトが出来上がる、というフレームワークになっています。
Viewを開発するだけでいいので、基本的に書き方が統一されます。Reactを使った人なら苦もなく読めます。

そういった判断から、WordPressのフロントエンドにGatsbyを選択しました。

ただ、記事数が多い・更新頻度が多いという状況だと毎回のビルドがネックになりNuxt（というか動的サイト）の優位性が勝つことになると思います。
次にGatsby化を予定しているサイトは900記事弱・更新頻度は2日に1記事程度ですが、ビルドは3分弱なのでGatsbyを使える判断をしています。

「10000記事のサイトでビルドが長すぎる」みたいなIssueをGatsbyのリポジトリで見かけましたが、そういったサイトであれば動的サイトにした方がいいでしょうｗ

> 導入のメリット導入のメリット

ざっくりまとめると以下のようなメリットがありました。

• 単純に開発が楽 - 今まではdocker-composeで頑張ってた - もう yarn dev でOK。
• 高速化が楽 - Gatsbyがblazing-fastなので早い。 - 移行の際にいらないコードを消せた。jQueryも消し去ることが出来ました。
• デプロイ方法に悩まなくなった - 静的サイトなので簡単デプロイ
• WordPressのセキュリティに対する不安も弱くなった - 静的サイトだからWordPressが外に露出させる必要がない

> 移行してみて移行してみて

開発環境、高速化、デプロイ方法、セキュリティなど今まで考えなければいけなかったポイントが減って非常に楽です。
開発環境もいい感じにリロードしてくれたり、eslint, prettierが動いてくれるので雑に書いても整形してくれるあたりは普段のサービス開発に追いついた気がします。
これでページの修正や追加があっても、重い気分になることなくマークアップに集中出来ます！

またGatsbyをやっていると、フレームワークはどのように高速化をしているのかについても知ることができ、他のサービスにも活かせる知識になります。早速別の会社で触っているRailsアプリケーションを高速化していきたいと思います。

ここまでいいことしか言っていませんが、もちろん懸念点もあって、静的サイトの生成速度は記事数が増えるにつれて当然遅くなっていきます。
デプロイ速度と読み込み速度のトレードオフの問題が生まれてきます。手元で計測したところ1000記事程度でBuildが2分半ちょっと、DeployがNetlify環境で約10分に達します。
許容出来なくなったタイミングで静的サイトから動的サイトへの変更を考えねばならないので、もしそうなった場合の検討も必要だと感じています。

ただ、記事数が少ないうちはほぼ何も考えずに導入できるのはGatsbyのいいところなので、Gatsbyが使われるべきサイトにはしっかり導入して、そうでない場合はその状況にあったものをしっかり提案出来るようにしていきたいところです。（コーポレートサイト・サービスサイトであればGatsbyで良さそうという見解です）

また、分離が進むとWordPressの必要性が薄くなっていきます。新規のサイトであれば別のCMSを提案したいので、このあたりのツールも探っていきたいところです。
個人的には、esa.ioやkibe.la、Qiita:Teamなど普段使っているツールから更新出来るのがいいかと思っています。

何度もしつこいですが、このサイトはesa.ioの投稿をそのままブログ記事として扱っています。本当に便利です。

WeJSの運営の皆様、LTの機会を頂きありがとうございました！
他の方のLTも楽しく聞かせていただきました。

---

実際にGatsbyを試してみたいという方は公式サイトを見て、Gatsby.js Tutorial | GatsbyJSを行いましょう。
また、WordPressをGatsbyで使いたい場合は gatsby new project_name https://github.com/ericwindmill/gatsby-starter-wordpress を実行して、gatsby-config.jsの設定を書き換えることで始めることが出来ます。