目次
React ECサイトのパフォーマンスを測る指標
パフォーマンス改善に取り組むにあたり、まずは現状を把握することが不可欠です。ここではGoogleが提供する無料ツール「Page Speed Insights」を使います。
Page Speed Insightsは、Webサイトのパフォーマンスを数値で可視化してくれる非常に便利なツールです。
ブラウザのコンソールなどで計測した値や、ユーザーが「体感的に悪くない」と感じる速度とは異なり、より厳密な環境下での計測値として算出されます。これにより、普段気づきにくいボトルネックを客観的に特定できます。
ここからは、パフォーマンスを測る主要な3つの指標について簡単に解説します。
LCP(Largest Contentful Paint)
LCPはページの読み込み開始から、ビューポート内で最も大きなコンテンツ要素(画像やテキストブロックなど)が描画されるまでの時間を測る指標です。
ECサイトでは、ファーストビューで表示されるメンビジュアルや商品画像がこれに該当することが多く、「コンテンツが表示された」と感じるまでの時間と関係しています。FCP(First Contentful Paint)
FCPはページ読み込み開始から、画面に何かしらのコンテンツ(テキストや画像など)が初めて描画されるまでの時間です。
ユーザーが「ページが反応している」と感じる最初の瞬間を捉えます。FCPが遅いとユーザーは白い画面を長時間見せられることになり、ストレスを感じさせてしまいます。TBT(Total Blocking Time)
TBTは、FCPからLCPまでの間にメインスレッドがブロックされて、ユーザーの操作に応答できなくなる合計時間を測る指標です。
TBTが長いと、ユーザーに「ページが固まっている」と感じさせてしまい、UXの悪化につながります
【実績公開】React ECサイトのパフォーマンスを改善した3つの方法
実際にパフォーマンス改善に取り組んだ際の具体的な施策をご紹介します。 これらの施策を実行した結果、Page Speed Insightsのモバイルスコアは26点 → 57点に改善しました。
※ Page Speed Insightsのパフォーマンス診断は、試行するタイミングで評価が大きく変わるため、本記事に記載の評価点数は複数回の診断を試行した際の平均的な値を採用しております。
※ Page Speed Insightsの診断は、リアルタイムで行いますが、実際の評価は「実際のユーザー環境で評価する」の結果が採用されます。なお、本サイトにおける「実際のユーザー環境で評価する」は以下の通りとなっており、診断は実際の評価より点数が低く評価される傾向にあります。
① LCPを改善する
スライダー画像を遅延読み込みしない
ECサイトのトップページにはスライダーが配置されていることが多いです。しかし、このスライダーの画像が原因でLCPが悪化しているケースがあります。
通常、imgタグのloading属性はデフォルトで`lazy`(遅延読み込み)になっています。これが画面内に表示されるまでの画像の読み込みを遅らせることで、初期表示を早くする効果があります。
しかし、ファーストビューに表示されるスライダー画像も遅延読み込みの対象にしてしまうと、表示が遅れてLCPが悪化してしまうようです。遅延読み込みをさせないために、スライダー画像のloading属性には`eager`を設定しましょう。
画像の軽量化次世代フォーマット(WebPなど)への変換
LCP悪化の大きな原因の一つに「重い画像」があります。特に高解像度の商品画像はファイルサイズが大きくなりがちです。
ECサイトにおいて画像はコンテンツの大部分を占めるので、画像の軽量化はパフォーマンス改善の基本中の基本といえます。
Next.jsを使用している場合、next/imageコンポーネントを使えば、アップロードされた画像を自動的に最適化・変換してくれるため非常に便利です。
2つの改善により、LCPが17.9秒短くなりました。
② FCPを改善する
next/font/googleでGoogle Fontsを最適化する
多くのWebサイトでは、デザイン性を高めるためにGoogle Fontsを使用しています。しかし、Google Fontsの読み込みが遅いと、フォントが適用されるまでの間、デフォルトのフォントが表示されてしまい、FCPの悪化につながることがあります。
Next.jsを使用している場合next/font/googleを使用することで、Google FontsのCSSとフォントファイルがビルド時に自動的にダウンロードされ、パフォーマンスが最適化されます。
これにより、フォントの読み込みによるFCPの遅延を防ぎ、常に最適な状態で表示できるようになります。
この改善により、FCPが11.9秒短くなりました。
③ TBTを改善する
TBTは、JavaScriptの実行に時間がかかり、ユーザー操作を受け付けない時間の合計を指します。SPAでは初回に大量のJavaScriptを読み込むため、このTBTが悪化する傾向にあります。
特に、Next.jsなどが採用するプリフェッチの仕組みは、リンク先のページを事前に読み込んで高速な画面遷移を実現する反面、意図しないタイミングで大量のJavaScriptやデータを取得し、メインスレッドに負荷をかけてしまうことがあります。
こうした背景を踏まえ、以下の改善策を実施しました。
容量の重いライブラリを削除する
アプリケーションの規模が大きくなると、知らず知らずのうちに多くのライブラリが追加され、バンドルサイズが肥大化することがあります。バンドルサイズが大きいと、ブラウザがJavaScriptを実行するのに時間がかかり、TBTが悪化してしまいます。
プロジェクト内で使用しているライブラリを見直し、必要ないものは削除しましょう。
その際、「webpack-bundle-analyzer」というツールが役立ちます。
このツールを使えば、どのライブラリがどれだけの要領を占めているかを視覚的に確認できます。
削除しても問題ないライブラリや、他の方法で代替できる場合は、削除することでバンドルサイズを大幅に削減することができます。
繰り返しAPI取得している箇所をリファクタリング
Reactのコンポーネント設計によっては、不必要なAPIリクエストが繰り返し発生していることがあります。
例1)親・子コンポーネントで同じデータを二重に取得している
親コンポーネントが商品データを取得し、それを子コンポーネントにPropsとして渡す設計が一般的ですが、意図せず子コンポーネントが同じデータを個別にAPIから取得してしまうケースです。
例2)特定のUI操作(モーダル開閉など)のたびに、不必要にAPIを再フェッチしている
モーダルを開くたびに商品詳細情報をAPIから取得するなど、すでに取得済みのデータを再度フェッチしてしまうケースです。これは状態管理ライブラリやデータフェッチライブラリ(例:SWR)を導入し、クライアントサイドでデータをキャッシュすることで解決できます。
このような箇所を特定し、リファクタリングすることでリクエスト回数を減らし、サーバーへの負荷を軽減することができます。
2つの改善により、TBTが550ms 短くなりました。
【実践】改善アクションチェックリスト
ここまで紹介した改善策を、実際に実行するための具体的なステップをまとめました。ECサイトのパフォーマンス改善を始めてみましょう。
① Page Speed Insightsで現状を把握する
ECサイトのトップページや主要な商品ページの、現状のパフォーマンススコアを計測します。Page Speed Insightsはスコアを出すだけでなく、「改善できる項目」として具体的な指摘やヒントも提示してくれます。
※「実際のユーザーの環境で評価する」の指標が問題なければ、診断の点数は過度に気にする必要はありません。
② 改善が必要な項目を特定し、優先順位をつける
計測結果をもとに、どの指標がボトルネックになっているかを特定します。LCPが特に低い場合は画像の最適化をするなど、改善が必要な項目に優先順位をつけます。
③ 改善策を適用し、再度計測して効果を確認する
優先順位に従って改善策を一つずつ適用し、再度Page Speed Insightsで計測を行います。改善策を適用するたびに計測を繰り返すことで、どの施策がどれだけの効果があったのかを明確に把握できます。
まとめ
本記事ではReact ECサイトのパフォーマンス改善について、Page Speed Insightsを指標とした具体的な施策をご紹介しました。
これらの改善策は、ユーザー体験の向上はもちろんのこと、SEO対策や売上にも直結する重要な取り組みです。ECサイトのパフォーマンスに課題を感じている方は、ぜひ本記事で紹介した内容を参考に、改善アクションを起こしてみてはいかがでしょうか。
当社「REGOLITH EC」では、こうしたパフォーマンス改善に柔軟に対応し、拡張性の高いBtoBコマースシステムを提供しています。構築やリニューアルをご検討の際は、ぜひお気軽にご相談ください。