目的
にて紹介したサイトリニューアルについて、サイト側の実装と実態について記録しておきます。
このサイトリニューアルは microCMS 様の事例紹介コンテンツにも掲載いただきましたので、そちらもぜひご覧ください。
Lighthouse 計測結果
トップページの計測結果は以下のようになりました。
※DevTools 内の Lighthouse（Mobile）での 計測 3 回の平均値
Performance : 68
| FCP | LCP | TBT | CLS | SI |
|---|---|---|---|---|
| 1.3s | 8.5s | 130ms | 0.003 | 6.7s |
旧サイトでの計測値が残っていないのが残念ですが Mobile で 10 点代でしたので、かなりの改善になっていると自負しています。
ラボデータだとしても Mobile で 65 点を超えるサイトは多くないはずですので、日本の 5G 環境においてはほぼストレスなく閲覧できるサイトになっていると思います。
トップページだけでなく、オリジン全体で Core Web Vitals におけるすべての指標の Good の割合が上昇しています。こちらはCrUX ダッシュボードのフィールドデータから算出しています。
※ 2021/01（リニューアル前）と 2023/01（リニューアル後）の比較
| LCP | CLS | FID |
|---|---|---|
| +4.31% | +0.76% | +2.12% |
余談
FV（ファーストビュー）の 80%以上をスライダーが占めるページにおいて、LCP で 5s を切るのは難しいのでは（Google の Good 基準 2.5s はもっと無理）と思っていますが、どうなんでしょうか？少なくとも自分が手元で Lighthouse 試したことのあるサイトでは出会ったことがありません。
サイトの技術構成
- コンテンツデータの管理：microCMS
- 過去のメディアデータのホスティング：Firebase Hosting
- サイト自体のホスティング：Vercel
- フロントエンド：Next.js （13 系 Pages Router）
- スタイル管理：TailwindCSS
パフォーマンスを意識した点
- 画像圧縮の徹底
- next/image と microCMS 画像 API
- Vercel でのホスティング
- Firebase Hosting
- next/link
- Intersection Observer
- Component 分割
画像圧縮の徹底
public配下にある画像（SVG 以外）は全て Sqoosh による事前圧縮を徹底しています。ビジュアルやパーツを作ってくれている社内デザインチームにも事前圧縮のカルチャーがかなり浸透してきました。
サイトのコンテンツ更新をされているお客様側でも画像圧縮を意識してくださっている方が増えてきています。この辺りの社内外への啓蒙活動もエンジニアと非エンジニアの境界に立つ自分の仕事だと思っています。
next/image と microCMS 画像 API の利用
next/image のレスポンシブ対応が嬉しい。
Vercel の Image Optimization はお高いので、画像サイズ系は microCMS の画像 API で頑張っています。（miroCMS の画像配信が安いわけではありません）
microCMS の画像 API は imigix の Rendering API を基盤として、サイズや品質など、読み込み時に済ませておきたい画像処理の API をひと通り揃えてくれています。
Vercel でのホスティング
Next.js on Vercel ってそれだけで速いです。何も考えなくても CDN での静的ファイルキャッシュしてくれたり、Next.js のパフォーマンスを最大限引き出しくれます。
ただ Build & Deploy まわりで Queued になってから Build が始まるまでときどき不機嫌になるのが玉に瑕です。Delayed Build Processing みたいなのが月 1 回くらいインシデントになってるイメージ。あとちょっと高いです。Image Optimization が特に。
Firebase Hosting
数多のホスティングサービスがある中で、未だ静的コンテンツの配信においては頂点に君臨している（と信じている） Firebase Hosting。
安いかと言われるとそうでもないですし、実質ストレージっぽく使っているので Cloudflare で良かったかもしれないです。
バージョン管理にお金がかかってしまうので、直近 2 バージョンまでしか保持していません。定期的なバックアップは外付け SSD を複数使用する力技です。
next/link
<Link>にするだけで prefetching してくれる素晴らしい機能。
サイト内遷移であれば<a>を<Link>に変えるだけで恩恵が得られる。
Intersection Observer API
遅延ロードの革命児。next-linkでも使用されている useIntersectionを他ページでも使えるよう加工したコンポーネントを用意して、あらゆる場面で使用しています。
Component 分割
徹底できてるとは言わないですが、再利用できるレベルでは分割しています。Code Splitting の恩恵は受けられてるんじゃないかと思っています。
コンポーネントの数は高々 30 程度なので、/components/ 配下にすべて並んでいます。
よしこ（@yoshiko_pg）さんがどこか（この LT 会の文脈だったかな？）で仰ってた記憶なのですが、ImageやLinkなど Next.js が持っているコンポーネントを使用する際は、自前でラップしておくと良い（例えば、Next.js 12 → 13 の「<Link>の中に<a>をネストする必要がなくなった」みたいな変更があるとき、ちまちま書き換える必要がない）と聞いたことがあるので、意識しています。
サイト運用面での改善
ここも今回のリニューアルで非常に良かったところです。閲覧ユーザーに届くサイトパフォーマンスだけでなく、運用者目線でもリニューアル後にポジティブな声をいただいてます。
microCMS は管理画面の UI が本当にわかりやすいです。このサイトで日々コンテンツ運用されている方は特にウェブに明るいわけではないですが、旧環境（WordPress）のときと比べて以下の点で運用しやすいとお声をいただいてます。
- すべて日本語で構成されている
- アクション後のスナックバー
- 公開状態のカラーやチップ
- フィルター機能
すべて日本語で構成されている
WordPress はバージョンアップで日本語パッチがあたらなかったり、プラグインによっては日本語非対応のものもあったりで、まだまだ英語アレルギーの方にとっては扱いにくいシロモノです。その点、純日本製の CMS はありがたいです。もちろんカスタマーサポートも日本語通じまくりです。
アクション後のスナックバー
公開時や下書き保存時に出てくるスナックバーも優秀で、アクションに対して UI のフィードバックがあるのは嬉しいです。
公開状態のカラーやチップ
公開状態のカラーリングとチップによるステータス表示も見やすくて迷いがなくなります。
フィルター機能
一覧画面から GUI でフィルター機能が使えることは非エンジニアの運用者にとって嬉しいところです。日付での絞り込みやテキスト検索も容易です。
そして何より、これらの 「使いやすい管理画面」を考えなくて良いことが嬉しいです。（私が何をせずとも）どんどんアップデートされていくので素晴らしいです。直近（24 年 2 月現在）で言うと、window.alertっぽかったアラートの UI が独自のものに変わった気がします。
さらなる改善のために取り組んでいること
ページ遷移の体験
ページ遷移の体験がよろしくないので、せめてプログレスバーを表示できるように検討中です。サイトが遅くならないように導入したい。NProgress.jsを検討中。
14 系へのアップデート
まだ App Router に切り替えようとは思ってませんが、キャッシュ周りが整理されたら切り替える可能性が出てくるので、準備だけはしておきたい気持ちです。弊社内の他プロジェクトでは 14 系 App Router で動いているものも出てきていて、Pages Router にはない嬉しさも感じ始めてます。Layouts イイですよね。あと Suspense 使いたい。
定点計測
Google Search Console のページエクスペリエンスレポート以上の計測はできていません。Datadog でパフォーマンスまわりも監視運用している事例を目にする度にかっこいいなぁと思っています。
microCMS への改善要望
たくさん使っているからこそ 「もっと良くなるのに！」 なポイントもありますので、一応記録しておきます。
- 同時ログインの規制
- メディアアップロード時の容量制限
- 並べ替えを手軽に
- 一括操作の強化
同時ログインの規制
同一コンテンツに同時ログインできないようにして欲しいです。これは最も切実。。
microCMS は WordPress よりさらにエンジニア向けのサービスという立ち位置だと思うので、なかなか難しいとは思いますが、期待はしています。
少なくとも、コンテンツ編集画面に着地している状態で、別の環境からそのコンテンツデータが更新されたらアラートは欲しいですね。
メディアアップロード時の容量制限
エンジニアに近いレイヤーでないと、ファイルの容量とページ読み込み速度の関係性はなかなかピンと来ないものなので、そもそも大きすぎるファイルはアップできないように制限をかけられると、運用面で遅くさせない設計にできるので嬉しいです。
並べ替えを手軽に
- 一覧画面でのコンテンツの並べ替え
- API スキーマの並べ替え
をひとつずつのドラッグ操作でしか対応できないのが少し手間です。ページ間でのコンテンツ移動や、肥大化したスキーマの途中に新規フィールドを差し込みたい場合に少しツラい思いをしています。
一括操作の強化
今の削除だけでも嬉しいですが、「下書きに戻す」「予約公開日を設定する」なども一括で操作できると素敵です。
エンジニア募集中
弊社 プラスクラス・スポーツ・インキュベーション株式会社（PSI）では プロスポーツ x Web を軸に数多くの Web コンテンツを制作・開発しています。
本記事のような microCMS x JS フレームワーク による大規模サイトの制作・運用に興味のあるエンジニアさん 是非 @goran_nasaiもしくは@motoi_devまでお声がけください。DM 大歓迎です。
採用サイトも是非ご覧ください。
※エンジニアの募集はオープンになっていないので、上記 X 上の DM もしくはお問い合わせフォームよりご連絡ください m(__)m
Discussion