Lighthouseスコアは最適化チェックリストではなく、アーキテクチャのシグナルです

長い間、私はLighthouseの高スコアは主にチューニングの結果だと思っていました。画像の圧縮、スクリプトの遅延読み込み、レイアウトシフトの修正、テーマの調整、プラグインの入れ替え、そして新しい警告が表示されるたびにこのサイクルを繰り返すことです。

時間が経つにつれて、その仮定は実際に見ているものと一致しなくなりました。

一貫して高スコアを獲得するサイトは、最も最適化に努力したサイトではありませんでした。ブラウザが単純に処理する作業が少ないサイトでした。

その時点で、Lighthouseは最適化ツールではなく、アーキテクチャ選択の診断シグナルのように感じられるようになりました。

Lighthouseが実際に測定するもの

Lighthouseはフレームワークやツールを評価しません。結果を評価します。

意味のあるコンテンツがどれだけ速く表示されるか。

JavaScriptがメインスレッドをどれだけブロックするか。

読み込み中にレイアウトがどれだけ安定しているか。

ドキュメント構造がどれだけアクセスしやすく、クロール可能か。

これらの結果は、スタックのずっと早い段階で行われた決定の下流効果です。特に、実行時にブラウザに延期される計算量を反映しています。

ページが使用可能になるために大規模なクライアントサイドバンドルに依存している場合、低いスコアは驚くことではありません。ページがほとんど静的HTMLで、クライアントサイドロジックが限定的な場合、パフォーマンスははるかに予測可能になります。

主要な変動要因としてのJavaScript

私が実行した監査や取り組んできたプロジェクト全体で、JavaScript実行はLighthouse後退の最も一般的な原因です。

これはコードの品質が低いからではありません。JavaScriptがページ読み込み中にシングルスレッド実行環境を競合するためです。

フレームワークランタイム、ハイドレーションロジック、依存関係グラフ、状態初期化はすべて、ページがインタラクティブになる前に時間を消費します。小さなインタラクティブ機能でさえ、不釣り合いに大きなバンドルを必要とすることがよくあります。

デフォルトでJavaScriptを想定するアーキテクチャは、パフォーマンスを制御下に保つために継続的な努力を必要とします。JavaScriptを明示的なオプトインとして扱うアーキテクチャは、より安定した結果を生み出す傾向があります。

静的出力が不確実性を減らす

事前レンダリングされた出力は、パフォーマンス方程式からいくつかの変数を取り除きます。

リクエスト時にサーバーサイドレンダリングコストがありません。

コンテンツを表示するためにクライアントサイドブートストラップが不要です。

ブラウザは予測可能で完全なHTMLを受け取ります。

Lighthouseの観点から、これはターゲットを絞った最適化作業を必要とせずに、TTFB、LCP、CLSなどのメトリクスを改善します。静的生成は完璧なスコアを保証するものではありませんが、失敗モードの範囲を大幅に狭めます。

ケーススタディ

個人ブログを再構築する前に、デフォルトでハイドレーションに依存するReactベースのセットアップを含む、いくつかの一般的なアプローチを探りました。それらは柔軟で有能でしたが、パフォーマンスには継続的な注意が必要でした。新しい機能のたびに、レンダリングモード、データ取得、バンドルサイズについての疑問が生じました。

好奇心から、静的HTMLを最初に想定し、JavaScriptを例外として扱う別のアプローチを試しました。私はこの実験のためにAstroを選びました。そのデフォルトの制約が、私がテストしたい質問と一致していたからです。

目立ったのは劇的な初期スコアではなく、時間の経過とともにパフォーマンスを維持するために必要な努力がいかに少ないかでした。新しいコンテンツの公開は後退を引き起こしませんでした。小さなインタラクティブ要素は無関係な警告に連鎖しませんでした。ベースラインは単純に侵食されにくかったのです。

私は完璧なLighthouseスコアを持つ個人ブログでこの実験を進めながら、ビルドプロセスとアーキテクチャのトレードオフを別の技術ノートに文書化しました。

トレードオフの重要性

このアプローチが普遍的に優れているわけではありません。

静的ファーストアーキテクチャは、高度に動的でステートフルなアプリケーションには理想的ではありません。認証されたユーザーデータ、リアルタイム更新、または複雑なクライアントサイド状態管理に大きく依存するシナリオを複雑にする可能性があります。

クライアントサイドレンダリングを前提とするフレームワークは、これらの場合により多くの柔軟性を提供しますが、その代償として実行時の複雑性が高くなります。重要なのは、一つのアプローチが優れているということではなく、トレードオフがLighthouseメトリクスに直接反映されるということです。

Lighthouseスコアが安定または脆弱になる理由

Lighthouseが表面化するのは努力ではなく、エントロピーです。

ランタイム計算に依存するシステムは、機能が追加されるにつれて複雑性が蓄積されます。ビルド時により多くの作業を行うシステムは、デフォルトでその複雑性を制約します。

その違いが、一部のサイトが絶え間ないパフォーマンス作業を必要とする一方で、他のサイトが最小限の介入で安定している理由を説明しています。

最後に

高いLighthouseスコアは、積極的な最適化パスの結果であることはめったにありません。それらは通常、最初の読み込み時にブラウザが行わなければならないことを最小限に抑えるアーキテクチャから自然に現れます。

ツールは移り変わりますが、根本的な原則は変わりません。パフォーマンスが目標ではなくデフォルトの制約である場合、Lighthouseは追いかけるものではなく、観察するものになります。

その変化は、適切なフレームワークを選択することよりも、複雑性の存在を許す場所を選択することに関係しています。