サービスサイトをGatsby×Wordpress×NetlifyでJamstackなサイトにリニューアル

はじめまして、株式会社カミナシのエンジニア @tomiです。

カミナシは、2020年10月にサービスサイトをフルリニューアルしました。

kaminashi.jp

今回のサイトリニューアルでは、どのような構成で作ったのか、また技術選定で考慮した点をお伝えします。

Jamstackな静的サイト構成

Gatsby.jsとWordpressを使いJAMstack構成で作成しました。

最終的に以下の画像のような構成になりました。

利用した技術を並べると、

• Gatsby.js
• Typescript
• StyledComponents
• GraphQL
• EsLint + Prettier
• Wordpress + Gutenberg
• Netlify

導入事例やセミナー情報など、動的な情報は記事としてWordpressに登録し、Gatsby.js側で記事をGraphQL経由で取得して表示しています。

静的なファイルのビルド・デプロイ・ホスティングはすべてNetlifyにおまかせしており、Wordpressで記事を更新したときとコードを修正したときは、Webhookで自動ビルドするように設定しています。

なぜこの構成・技術にしたのか

①フルリニューアルするならJAMstack

そもそも、リニューアル以前は外注でWordpressで作成されていて、今いるメンバーが仕様を把握していなかったので、改修は考えず再構築することにしました。

また、Wordpressだとどうしても読み込みが遅いのでSEO的に不利なので、Wordpress以外で動かしたいというのは全員一致でした。

サイトの読み込みスピードも早くしてSEOを強くしたいとなると、SSRよりSSGでJAMstack構成が一番でしょう。

JAMstack構成を採用している事例も増えてきて情報もWeb上に溢れているので、特に悩むことなくJAMstackが採用されました。

（個人的に、ただ作成するよりJAMstack構成で作り甲斐があるからという理由が8割くらい占めていたかも🤫）

②SSGとしてGatsby.jsを採用しました

静的サイトジェネレーター（SSG）として検討されたのは、Next.js・Jekyll・Hugo・Gatsby.jsでした。

その中からGatsby.jsを採用した理由は複数あります。

カミナシアプリでもReactが使われていること

魅力的なフレームワークはたくさんあり、ついつい新しい技術に手を出したくなってしまいますが、複数のエンジニアが今後作業するとなると、すでに使っている技術を使った方が開発コストが下がるので、カミナシのアプリでも採用しているReactを使ったNext.jsかGatsby.jsが良いのではと考えました。

TypescriptとStyledComponentsを採用しているのも同様の理由です。

公式またはコミュニティのプラグインが豊富

これがGatsby.jsを採用した一番の理由です。

Gatsbyでは数多くのプラグインが、公式またはコミュニティから配布されています。

公式サイトからプラグインを探せます

Googleタグマネージャの設定やサイトマップ、ウェブフォント、GraphQLなどの機能のカスタマイズ性が高く、開発も活発に行われているのが印象的です。

そして、特に嬉しいのがgatsby-plugin-sharpというプラグインで、ビルド時に画像を表示サイズに合わせて自動で縮小・切り抜いてくれるもので、画像が適切サイズで読み込まれればSEO対策にもなります。

さらに、Wordpress内で作成した記事に対してもこのプラグインが有効で、記事に間違って大きな画像を挿入してしまっても、画像が最適化されるので安心です。

やっぱりSSGといえばGatsby

2019年に仕様したSSGは？というアンケートを見つけました。 Gatsby.jsとNext.jsが僅差ではありますがGatsby.jsが最も使われています。

参照：https://tsh.io/state-of-frontend/#jamstack

Gatsby.jsとNext.jsのGitHubで比較してみると、スター数はSSRでも人気のNext.jsの方が少し多いですが、Used byの数では、Gatsby.jsが2倍近く多くなっていました。（Gatsby.jsが2.5k、Next.jsが1.3k）

今年Next.jsはIncremental Static Regenerationという機能でIncremental SSGにも対応してもしかしたら逆転してしまうかもしれませんが、SSGとしての信頼は現時点ではGatsby.jsの方が上かなということで、Gatsby.jsを採用しました。

③Headless CMSはサイトの仕様を考慮した結果Wordpressに

お知らせのページや導入事例、セミナー情報のページなど、動的に増える部分をCMS上で管理しています。

当初は、microCMSやContentful、Ghost、HubspotCMSなどどれを使うか悩むな〜と思ってましたが、サイトの仕様が固まりそれを実現できるCMSはどれか調査していった結果... Wordpress一択でした。

Wordpress以外のCMSだと実現が難しいことが特に表れているのが、セミナーのページになります。

こちらはセミナーの編集画面の一部で、登壇者の画像・会社・役職・名前・紹介文を複数名可変で登録できるようになっています。

このようなブロックの繰り返しを実現できるようなカスタマイズ性の高いCMSがWordpress以外に見つかりませんでした。

Markdownで表現できるようなブログなどであれば、どのCMSを使うか迷って、料金や制限などをよく見て検討する必要がありますが、今回の仕様を考慮した結果Wordpressになりました。

④ホスティングサービスにはNetlifyを採用

ホスティングに関してはじめは、GatsbyCloudでビルドしてAWSのS3+CloudFrontでホスティングさせる構成で考えていました。

AWSはカミナシアプリでも使っており、サービス管理を一箇所に集めるメリットがありましたが、GatsbyCloudでIncremental Buildsする場合は有料プランにする必要がありました。

調べていくと、Netlifyなら無料プランでIncremental Buildsができそうだったので試したら、驚くほどカンタンでした。

src/static/netlify.tomlファイルを以下のように作成して、

[[plugins]]
  package = "netlify-plugin-gatsby-cache"

NetlifyにGitHubリポジトリを接続するだけで、ビルド・デプロイ・ホスティングをしてくれました。

結果的に、ホスティングサービスにはNetlifyを採用することとなりました。

まとめ

社内の技術・拡張性の高さ・仕様との折り合い・価格面などを踏まえた結果、Gatsby×Wordpress×NetlifyでJamstackなサイトに仕上がりました。

構成・技術に関して今回はお伝えしましたが、作成していく中で多くの躓きがありましたので、それも今度まとめて紹介したいなと思っております。