2022年1月に自社のコーポレートサイトをリニューアルしました。
リニューアルに際して技術スタックも新しくしていこうということで、Jamstackというアーキテクチャー（ソフトウェア設計思想）で実装し、非常に高速なコーポレートサイトにアップデートしました。

 

ページ遷移に全くストレスがなく、かなり高速に遷移できるようになっているかと思います。（お手元にスマートフォンがある方は是非スマホでも当サイトにアクセスしてみてください）

 

今回のブログでは、このように高速なサイトを実現する、Jamstackについて紹介したいと思います。
最近では国内でもコーポレートサイトやメディアサイトにJamstackが採用されてきています。

 

例えば、株式会社メディアジーンの有名なWebメディアである、Business Insider Japanやギズモード・ジャパンなども、Jamstackで実装されているのではないかと思います。

JamstackをGoogleトレンドで検索したところ、2017年あたりから徐々に盛り上がってきていました。

 

このように、従来のコーポレートサイトやメディアサイトがWordPress一択だった時代から、技術がアップデートされてきていますので、Jamstackが流行り始めた背景やメリット/デメリットなどを解説したいと思います。

 

従来のサイトの課題

サイト表示速度が遅いことで起こる機会損失

今回のサイトリニューアルの最も大きな目的は表示速度の向上でした。
Webサイトの表示速度が遅いことで起こる機会損失は以下大きく2点あります。

ユーザビリティの低下

表示速度が遅いことで起こる悪影響として最も大きいのがユーザビリティの低下でしょう。
最近は多くのユーザーがスマホでサイトにアクセスするとともに、速いWebサイトに慣れているユーザーが多いため、内容に興味があったとしても表示速度が遅いと簡単に離脱（ページの表示をやめる・別のサイトを探す）してしまいます。

表示速度の低下はユーザーにストレスを与えるだけでなく、離脱率や回遊率、リピート率などあらゆる指標に悪影響を与え、大きな機会損失に繋がります。

SEOの低下

表示速度はSEOにも大きく影響します。

2021年、GoogleはWebサイトの検索ランキングを決定するための要素として、Core Web Vitalsと呼ばれる3つの指標を組み込みました。
その中のLCP（Largest Contentful Paint）とFID（First Input Delay）は表示速度や応答速度が特に大きく関係する指標です。

このように、表示速度の遅いサイトは検索ランキングの上位に表示されにくくなっていることがGoogleによって明言されており、ユーザーとの接点を多く作るという意味でも表示速度が重要になってきています。

Jamstackとは？

解説が前後してしまいましたが”Jamstack”とは、「高速かつ安全で高い拡張性を持ったWebサイト・Webアプリを構築できるように設計されたアーキテクチャ（設計思想）」です。

 

アーキテクチャーなので、”Jamstack”自体はプログラミング言語やフレームワークというものではなく、”Javascript”・”API”・”Markup”の頭文字から付けられた、システム構成の呼称となります。
従来のWordPressなどのCMSの管理画面はそのままに、ブラウザに表示されるクライアントサイドだけを静的ページで生成し、高速に配信するという考え方が一般的です。

従来のWebサイトの技術構成とJamstackの技術構成との比較

Webサイト制作において現在最も一般的であるCMS（WordPressなど）の構成と、Jamstackの構成を解説します。

従来のCMSを使ったWebサイトのアクセスフロー

従来の構成では、ユーザーからサイトへアクセスするたびにサーバーからDBにアクセスし、HTMLをクライアントサイドに返却しています。

Jamstackで構築したWebサイトのアクセスフロー

一方、Jamstackではユーザーからのアクセスの際、あらかじめ作成しておいたHTMLを返却するだけで、CMSへのアクセスは行いません。
従来のCMSを使ったWebサイトと比較して、Jamstackの場合はデータ取得の行程がないことが分かります。

 

ユーザーがサイトにアクセスする前に、ビルドと呼ばれるデータを取得してHTMLを生成しておく処理（青色の矢印）が行われているためです。
これにより、高速なサイト表示を実現しています。

Jamstack化による管理者（サイト運営者）への影響は？

図中のグレーの矢印が管理者によるコンテンツ更新作業の流れです。
従来のCMSを使ったWebサイトとJamstack構成のWebサイトで全く違いはありません。
管理者（運営者）サイドとしては、Jamstackに移行したとしても特にコンテンツ更新作業が複雑化しないため、従来通りの運営が可能です。

Jamstack化のメリットとデメリット

一般的なCMS（WordPressなど）のシステム構成と比較したときのJamstackの主なメリットとデメリットを紹介します。

メリット

1. 高速なページ表示が可能
2. セキュリティリスクが低い
3. 大量アクセスに強い

 

1. 高速なページ表示が可能

Jamstack構成のサイトでは、サイトビルド時に全てのWebサイトのページを静的なページとして作成するため、通常のサイトに比べサイト表示するためのローディングがなく高速でサイト表示が行えるのが大きなメリットです。

2. セキュリティリスクが低い

Jamstackサイトでは閲覧時に静的ファイルを返すのみであるため、Webサーバーとの通信が発生しません。
そのため閲覧者からは記事やユーザーの情報を扱うWebサーバーの特定が困難であり攻撃を受けるリスクが低いのもメリットです。

3. 大量アクセスに強い

WordPressのような動的サイトではアクセス毎にWebサーバーにリクエストを送り通信を行う必要がありますが、Jamstack化されたサイトではそのような処理は発生せず、事前に用意された静的ファイルを返却するのみであるため、大量アクセスによる負荷がほとんどありません。

デメリット

1. 動的要素を扱えない
2. ビルドに時間がかかる
3. 開発・変更に専門的なスキルが必要

 

1. 動的要素を扱えない

動的要素とは、ページにアクセスしたタイミングやユーザーに応じて変動するような要素のことです。
例えば、Twitterのように高頻度で更新されるコンテンツをリアルタイムで反映するのは特殊な実装が必要となります。
しかし、静的要素がメインであるような一部のページのみJamstack化することも可能で、最近では周辺技術の発展によって、動的要素も扱えるように進化してきています。

2. ビルド（静的ページ生成）に時間がかかる

サイトの更新を反映させるためには全ページのビルドを行う必要があり、ページ数が多いほどこの時間は長くなります。
しかし、この問題についても定期的に自動更新を行ったり、一部の更新があったページのみ再度ビルドを行うような技術が発展しており、時間短縮が進んでいます。

3. 開発・変更に専門的なスキルが必要

Jamstackサイトの開発やサイトデザインの変更には、HTMLやCSSだけでなく、JavaScriptやAPI等に関する専門的な知識が求められます。
（記事の投稿や更新等はWordPress等のCMSを扱うことができれば問題ありません)

どんなサイトがJamStackに向いてるのか？

先に述べたように、Jamstackでは事前にデータを取得し静的ページを生成するというフローであるため、全てのWebサイト・WebアプリがJamstackに向いている訳ではありません。
Jamstackに向いているWebサイト・Webアプリの特徴としては以下のような項目が挙げられます。

• 静的な要素がメインである
• コンテンツの更新頻度が比較的少ない
• データの更新がリアルタイムに反映される必要がない

具体的には、ブログやコーポレートサイト、メディアサイトなどが向いていると言えます。

逆に、TwitterやInstagramのような動的な要素がメインで、コンテンツの更新頻度が高くデータの更新がリアルタイムに反映される必要があるようなWebサイト・Webアプリは基本的にはあまり向いていないでしょう。
※ ISR(Incrimental Static Regeneration)などの機能を使えば実現可能な場合もあります。

クランチタイマーのコーポレートサイトの技術スタック

クランチタイマーでは、フロントエンドをNext.js、バックエンドをWordpress、データ取得方法（API）にGraphQLを使用しています。
もともとリニューアル前からWordPressで構築していたため、今回のリニューアルでは主にフロントエンド（クライアントサイド）の開発を行いました。
従来のサイトのデータをそのままに、WordPressなどCMSのコンテンツがそのままの形で活かせるのもJamstackのメリットだと思います。

フロントエンドの技術

フロントエンド側では、なるべくリアルタイムのデータをユーザーに表示するために、SSG(静的サイトジェネレーション) + Pre fetch + ISR (Increment Static Regeneration) + client side fetching(useSWR)の構成をとっています。
SSG + Pre fetchでは、初めのサイトデプロイ(ビルド時)にWordpress側からデータを取得してき、全ての静的ページを作成します。
静的ページなのでサイト表示は非常に早くなります。

しかし、管理者が新しいブログなどを投稿した際データはWordpress側では存在するが、サイト側では反映されずユーザーには見えない、という状態になってしまいます。
その問題を解決するのが、ISR(Increment Static Regeneration)とclient side fetching(useSWR)です。

ISRでは、Next.js側で設定した間隔でサイトを自動で再ビルドすることができ(厳密には少し異なりますが)、管理者が新しいブログを追加したとしても、いづれはサイトに反映されユーザーに見てもらうことができます。
それでも、ISRだけでは自動ビルドが行われる前に訪れたユーザーに対しては最新のデータを届けることができません。

そこで、client side fetching(useSWR)の出番です。client side fetchingでは、ユーザーがサイトを表示したタイミングで、wordpressnにデータを取得してき、最新のデータをサイトに表示することができます。
これらの技術を集約しクランチタイマーのコーポレイトサイトは、なるべく最新のデータを、サイトのちらつきを抑えユーザーに提供するようにしております。

バックエンドの技術

バックエンドではWordpressを使用しており、これまでのWordpressのプラグインを使用し「お問い合わせページ」、「SEO」対策なども行なっています。
また、ブログ投稿もこれまでとは変化はないので、エンジニアでない方でも簡単にデータの投稿、編集が可能です。

終わりに

今回は自社のコーポレートサイトの技術の紹介でした。
技術的な内容だけでなく、見た目（ユーザビリティ）も大きくアップデートできたので非常に効果のあるリニューアルだったと思います。
サイトスピードにお悩みのサイトをお持ちの方がいらっしゃれば、是非当社にご相談ください！

 

Freepik – jp.freepik.com