Lighthouse分數真正反映的內容：架構選擇如何控制複雜性

Lighthouse並非最佳化工具。在達成這一認知之前，我經歷了長時間的反覆嘗試。

當我觀察那些網站性能穩定的組織與總是忙於應對的組織之間的差異時，我注意到一個事實。保持高分的網站，並非是最積極進行調整的網站，而是那些在瀏覽器載入時本身工作量較少的網站。

本質的測量：複雜性的累積

Lighthouse評估的不是個別的最佳化努力，而是架構的根本選擇。具體來說，它反映以下結果：

• 內容出現在畫面上的速度
• JavaScript佔用主線程的時間
• 頁面載入過程中的佈局變動
• HTML結構與可及性

這些指標是由設計階段的決策所產生的下游效果。尤其是，瀏覽器在執行時必須處理的計算量會直接影響。

依賴大型客戶端捆綁包的頁面，分數自然較低。而以靜態HTML為基礎、僅使用有限JavaScript的頁面，則展現出可預測的性能。

JavaScript執行是最大變動因素的原因

根據實際專案經驗，導致Lighthouse分數下降的最常見原因是JavaScript執行的負擔。這並非程式碼品質問題，而是瀏覽器單一線程環境的根本限制。

框架的運行時初始化、Hydration、依賴解析、狀態管理初始化——這些都在頁面變得互動前消耗時間。

問題在於，即使是小型的互動功能，也會伴隨著不成比例的大型捆綁包。預設以JavaScript為前提的架構，為了維持性能，需持續努力。而將JavaScript作為明確的選擇性啟用架構，則能產生更穩定的結果。

透過靜態輸出降低複雜性

預先生成的HTML，從性能方程式中移除多個變數：

• 不需伺服器端渲染請求延遲
• 不需客戶端初始化啟動
• 瀏覽器收到的HTML是完整且可預測的

因此，TTFB、LCP、CLS等指標自然改善。無需額外進行針對性優化工作，即可達成改善。

靜態生成不保證完美分數，但能大幅縮小失敗範圍。這是一種通過限制來追求穩定性的策略，而非貪婪的最佳化。

實踐中學到的架構影響

在重構個人部落格時，我嘗試了不同於React標準設定的方法。Hydration依賴型架構較為靈活，但每次新增新功能時，都需判斷渲染模式、資料取得與捆綁包大小。

相反，採用以HTML為基礎、將JavaScript作為例外的策略，則帶來明顯變化。不是初期分數的劇烈提升，而是隨著時間推移，性能維持的努力幾乎消失。

新內容發布時也不會降低性能。小型互動元素不會引發意外警告。基線的穩定性較不易被侵蝕。

認識取捨的重要性

必須明確指出，這種方法並非萬用。靜態優先的架構不適用於需要認證用戶資料、實時更新或複雜客戶端狀態管理的應用。

以客戶端渲染為前提的框架，在這些情況下提供更高的彈性，但也伴隨著執行時複雜性的增加。這不是優劣之分，而是取捨，這些取捨直接影響Lighthouse指標。

分數的穩定性與脆弱性的根本

Lighthouse所可視化的不是努力，而是複雜性的熵。

依賴執行時間計算的系統，隨著功能增加，複雜性會逐漸累積。以建置時提前完成工作的系統，則天生限制了這種複雜性。

這個差異導致某些網站需要持續進行性能優化，而另一些則能在最少干預下保持穩定。

總結：性能源自預設限制

高分的Lighthouse分數，幾乎不會來自積極的最佳化努力。反而是源自於最小化瀏覽器在初始載入時所做工作的架構。

工具會變，但根本原則不變。選擇讓性能成為預設限制的設計。如此一來，Lighthouse不再是追求的目標，而是觀察的指標。