はじめに

こんにちは。ご覧いただきありがとうございます！

KINTO FACTORY（以下 FACTORY）という今お乗りのクルマをアップグレードできるサービスで、フロントエンド開発をしている Nakamoto です。

今回は、FACTORY 開発Gで取り入れた改善DAYや、社内でのフロントエンド勉強会を活用して、ページパフォーマンス（CWV）を改善した事例を紹介させていただきます。

改善DAYとフロントエンド勉強会

改善DAY

FACTORY 開発Gでは、案件開発している最中で気付いた、技術的負債などの「すぐには対応できない（しなくてもよい）タスク」を、忘れないようにとりあえずチケット化しバックログに残しておく運用になっていました。その運用がずっと続いたところ、日々の案件開発になかなか切れ目が無く、それら改善タスクがバックログに積み上がる一方で消化されることがなく、チケット総数が100件を軽く超えるようになっていました。

そこで、スクラムの振り返りなどで、それらの改善タスクをずっと放置しておくのも問題だという声もあがり、週に１日午後の時間を改善タスクの消化のみにあて、そこにはMTGなどを入れない取り組みをチーム全体で始めてみました（Outlook 上で該当時間をブロックし、他部署からの MTG も入れられないように工夫しています）。

今回は、この改善DAYを活用し、ずっとできていなかったページパフォーマンス = CWV（Core Web Vitals）のスコア向上を目指すことにしました。

フロントエンド勉強会

また、社内の有志によるフロントエンド勉強会を週に１度開催しており、過去のイベント発表をみんなで見て感想を共有したり、過去〜最新の Baseline をみんなで確認したりと、参加メンバーで都度議題を決め、フロントエンド界隈の技術交流や、実際の開発プロダクトや開発の実情について共有する場というものがあります。

そんな中、勉強会のアウトプットの一つとして、実際のサービスで活かせることがなにかできないか考えるようになり、私の方から題材の一つとして「FACTORYパフォーマンス改善」を提案しました。
実際に参加メンバーみんなで FACTORY ページを検証する枠を作って頂き、合計２回に渡ってライブ検証することができました。

具体的に取り組んだのは以下になります。

• ブラウザの Lighthouse を使用して現状のスコアを確認（ネットワークや CPU のスロットリングを適宜設定）
• 各スコアの改善提案を確認する
• 分析タグなどページレンダリングに関係のないものをブロックしパフォーマンスの差分を確認
• パフォーマンスタブでより詳細なブラウザの動きを確認する
• キャプチャ画像からレイアウトシフトを確認

これらにより、ブラウザに用意されている検証ツールの使い方や、どのようなところに改善ポイントがあるのか、を明確にすることができました。

スコア改善

ここからは、実際に勉強会で得た知見を活用し、どのようにスコア改善を進めたか紹介していきます。

ページパフォーマンスを図る指標として、Core Web Vitals (CWV) がありますが、それらは下記３つの指標に分類されます。

• Largest Contentful Paint (LCP): ページの主要なコンテンツがどれだけ速く読み込まれるかを測定
• Interaction To Next Paint (INP): ユーザーの操作に対するページの応答性を評価
• Cumulative Layout Shift (CLS): ページの視覚的な安定性を測定

FACTORY はサービスの性質上、商品や車種画像の制約が厳しく（商品・車種の色味などが厳格のため）、静的コンテンツ変更（画像圧縮など）は難しかったため、ページ内のコンテンツ配置の変更だけで改善が見込める CLS にまずは焦点を当てました。

• Google Search Console を参考に、どのページで CLS スコアが悪いのか確認
• SSG により静的ページとして作成し、クライアントでの API アクセス時のロード画面をなくす
• 画像などのコンテンツロード前後で、高さがシフトしている場所などを探す

実際には、CLS スコアの悪いページにて、ブラウザの「パフォーマンス」タブで確認し、画面キャプチャを見ながらレイアウトシフトしている箇所をひとつひとつ潰していきました。

中でも特定に時間を要したのが、TOPページで発生していた CLS です。
以下のように解析ツールで見てみても、どこがレイアウトシフトしているのかパッと見では特定できませんでした。

ただ、該当の画像あたりを確認すると、contain-intrinsic-size をcssで定義していることに気づきました。どうやら、こちらのプロパティは比較的新しいもので、非対応のブラウザでは正しく画像のサイズが設定されずレイアウトシフトの原因になっているようでした。

代わりに、画像のサイズ固定を aspect-ratio へ変更しアスペクト比を設定することで、レイアウトシフトを無くすことできました。

結果

今回は、改善DAYでの取り組みと実際の CWV スコアはどうだったのか、両面から振り返ってみたいと思います。

改善DAYでのチケット消化

以下の図は、改善チケットをまとめたボードのチケット解決数を表したものです。
４月ごろに「改善 DAY」の仕組みを導入しており、グラフ中の赤線が期間中（１ヶ月）に追加したチケット、緑線が完了したチケットを示しております。

4月チケット消化	6月チケット消化

上記はチーム全体の結果になりますが、着実に改善タスクの消費量が増えていることがわかるかと思います。
また、最近は全社的に AI を利用した開発も積極的に取り入れていることもあり、このような改善タスクは「シンプルなタスクな反面、取り掛かるにはコンテキストスイッチなどが発生し人間がやるには腰が重い」作業となり、比較的 AI に任せやすいタスクとも言えます。

そのような面も有り、日々機能追加などの案件の開発も動いている割には、上記のような改善活動にもしっかりコミットできていることが読み取れます。

CWVスコア

それでは、改善活動前後での今回のテーマである、CWV スコアがどのように改善されてきたか振り返ります。

PCスコア

モバイルスコア

上記のグラフは、Google Search Console で確認できる、URL単位でのパフォーマンススコアの移り変わりになります。

PC / モバイル両方とも 良好URLの数 (緑部分) が増え 不良URL (赤部分) が減少 or ０ となり、大多数のページでパフォーマンス改善することができました。
黄色で表されている 改善が必要なURL が多少残っていますが、こちらは今回対応した CLS スコアだけの結果では無さそうですので、今後はそちらの別指標についても改善していきたいと思います。

まとめ

今回は、FACTORY 開発G で導入している改善DAYと、社内で開催しているフロントエンド勉強会を活用し、実際に FACTORY のページスコア（CWV）の向上に取り組んだ事例を紹介させて頂きました。

日々、案件を進めるうえでは、納期などの都合でどうしても技術的な負債の消化を後回しにしてしまいがちですが、今後も改善DAYを活用し、そうした技術的負債が溜まらないようにしていくことや、社内勉強会からは、開発しているプロダクト・サービスは違えど、知見や改善案はそんな中からも発見できるので、それらをうまく活用しながら FACTORY のサービスを日々改善し安定運用していきたいと思います！