Lighthouse が示す光とは？

Google Lighthouse は Google が開発したオープンソースの自動化ツールで、Web ページの品質向上を支援するために作られました。パフォーマンス、アクセシビリティ、ベストプラクティス、SEO、PWA（Progressive Web App）などの観点から Web サイトを監査し、各項目に 0〜100 のスコアを付けます。これは、ユーザー体験だけでなく検索エンジン評価においてもサイトの状態を把握するための強力な指標です。

Lighthouse スコアが重要な理由：

• ユーザー体験の向上
  　高スコアのサイトは高速でアクセスしやすく、構造が整っているため、ユーザーの離脱率が低下し、エンゲージメントが高まります。
• 検索順位の向上
  　 Lighthouse は Core Web Vitals も評価対象としており、これらは Google の検索順位に直接影響します。スコアが高いほど検索で上位に表示されやすくなります。
• コンバージョンとリテンションの向上
  　信頼性が高く速いサイトはコンバージョン率を上げ、売上やリードの増加、ユーザー満足度の向上に繋がります。
• 信頼性とブランドイメージの向上
  　モダンな Web 開発のベストプラクティスを満たしているサイトは、より信頼できる・プロフェッショナルな印象を与えます。
• 開発上の指針となる
  　 Lighthouse は単に問題を指摘するだけでなく、改善に役立つ具体的な提案を提示してくれます。

高い Lighthouse スコアは、速さ・使いやすさ・見つけやすさを兼ね備えた Web サイトの証であり、訪問者の維持や成果への転換において非常に重要です。Core Web Vitals が Google のランキング要因に組み込まれている今、強力なスコアの獲得は競争上のアドバンテージにもなります。

PageSpeed Insights との違いとは？

Google PageSpeed Insights は、Lighthouse をベースに Google がホスティングしている Web ツールで、実際の使用環境をシミュレーションしたテスト（低速回線やエントリーモバイル端末など）を通じて Web サイトのパフォーマンスを測定します。これにより、現実のユーザー体験に近い結果が得られます。
ローカルで高スコアが出ていても、PageSpeed Insights で測定すると改善の余地が見えるケースもあります。

スコアが低くなる典型的な原因

多くの Web サイトでは、技術的負債やレガシーコード、過剰なリソースが原因で Lighthouse スコアが伸び悩んでいます。代表的な要因には以下のようなものがあります：

• 巨大な JavaScript バンドル：最初の描画や操作開始を遅らせる非最適化スクリプト。
• 未使用コードの多さ：ユーザー体験に貢献しないコードが配信バンドルに含まれている。
• レンダリングブロックリソース：CSS や JavaScript の読み込みがページ表示を妨げる。
• 非圧縮画像：高解像度かつ圧縮されていない画像がページを重くする。
• サーバーの応答遅延：バックエンドやホスティングのレイテンシー。
• アクセシビリティ属性の不足：障害を持つユーザーにとって使いづらい UI。
• SEO 構造の非効率性：メタデータの欠如、見出し階層の不整合、URL の最適化不足。
• レイアウトシフト：読み込み中に要素が予期せず移動し、UX に悪影響を与える。

これらはパフォーマンス低下のみならず、ユーザー満足度や検索可視性の悪化も引き起こします。

Scriptide が直面した課題と取り組み

Scriptide の旧 Web サイトでは、「パフォーマンス」と「ベストプラクティス」の Lighthouse スコアがあまり良くありませんでした。これは検索順位とユーザー体験に直結する問題であり、ビジネスおよびクライアントの成功のためにも、改善は必須事項でした。

古くなった依存ライブラリ

Scriptide のサイトはNext.jsを基盤としており、これは React ベースのモダンなフレームワークです。Next.js は年に一度の頻度でメジャーアップデートが行われており、旧サイトではNext.js 13を使用していましたが、最新はNext.js 15でした。
この 2 年間で蓄積されたパフォーマンス改善の恩恵を得るため、最新バージョンへの移行は重要でした。しかし、依存関係の複雑さから、アップグレードは意外と手間のかかる作業でした。

コードとリソースの最適化

Scriptide の旧サイトはある程度管理が行き届いていましたが、スコアが伸び悩む要因が 3 つありました：

1. サードパーティコードの肥大化
2. 不要なコードの配信
3. リソースの読み込みと利用の非効率性

これらはページのロード時間を延ばし、ユーザー体験に悪影響を及ぼしていました。

対処のために行ったこと：

• webpack-bundle-analyzer や Statoscope を使用して未使用コードを特定・削除 ✅
• スクロール時など、必要なタイミングでのみサードパーティスクリプトを遅延読み込み ✅
• Next.js の画像最適化機能を活用し、レスポンシブかつ圧縮済み画像を配信 ✅

これらの施策によりバンドルサイズが大幅に削減され、Lighthouse スコアも改善しました。

レンダリングブロックの回避

リソースが重いコンポーネントについては、必要になるまでレンダリングを遅延させることで初期ロードの負荷を軽減しました。

具体的には、、ブラウザネイティブのIntersection Observer APIを活用し、レンダリング負荷の高いコンポーネントをすべてカスタムのObservableコンポーネントでラップしました（注: RxJS Observables とは全く関係ありません）。参考までに、以下のコードをご覧ください。

使用例：

また、Next.js の動的インポート機能で重いコンポーネントを遅延読み込み：

Web 構造のセマンティクス見直し

アクセシビリティとベストプラクティスの観点では、次の 2 点を重視しました：

• 見出しの階層構造：h1→h2→h3...という順番は論理的な意味を持ち、DOM 構造上でも守られるべきです。
• コントラストのある配色：視覚に障害のある方にも明確な意味が伝わるよう、適切なコントラスト比を保つことは不可欠です。

構造と配色の見直しで、これらの課題を解消しました。

レイアウトシフト対策

画像サイズの未指定、フォントの遅延描画、動的コンテンツによるずれなどが原因で、ページ読み込み時にレイアウトが崩れる問題が発生していました。

以下を実施：

• すべてのメディア要素に固定サイズを指定 ✅
• フォントをプリロードして未スタイル描画（FOIT）を防止 ✅
• CSS で動的コンポーネントのスペースを確保 ✅

この結果、CLS（Cumulative Layout Shift） スコアが大幅に改善しました。

灯台は進むべき道を示す

改善を段階的に進めたことで、以下のような成果を得られました：

• パフォーマンス：デスクトップで 56〜60 点、モバイルで 40〜44 点だったスコアが、最終的にはデスクトップで 90〜91 点、モバイルで 87〜91 点に到達（デザインは一切変更なし）。Google PageSpeed Insights でご確認いただけます。
• アクセシビリティ：96 点から 100 点に到達。
• ベストプラクティス：75 点から 96 点に改善。
• SEO：元々 100 点を維持。

トップページ以外のページでも、同様のスコア向上を実現できました。

Google Lighthouse 最適化は単なるスコア競争ではありません。 それは、高速で、包括的で、誰にとっても使いやすい Web 体験を提供するという、本質的な価値の実現です。今回の取り組みは、今後の成長にもつながる、より強固な土台作りとなりました。