Lighthouse分數不是優化的結果，而是反映架構本質的鏡子

Lighthouse的分數高低比較，揭示了令人驚訝的事實。高分網站並不一定是花最多時間進行最佳化的網站，而是採用簡單設計、不讓瀏覽器過度貪婪的網站。

性能指標所反映的內容

Lighthouse測量的並非工具或框架的排名，而是實際的成果：

• 使用者看到有意義內容的速度
• JavaScript佔用主線程的時間
• 在載入階段中佈局的穩定程度
• 文件結構的可存取性與爬取性

這些指標（TTFB、LCP、CLS）是實作階段決策的連鎖反應，尤其直接影響瀏覽器在執行時的計算量。

依賴大型客戶端捆綁包的架構，低分幾乎不可避免。而以靜態HTML為核心、客戶端邏輯最小化的網站，則能實現預測性高且穩定的性能。

JavaScript的貪婪：性能下降的真兇

許多審查專案中都遇到共同問題：JavaScript的執行。

這並非程式碼品質問題，而是根源於瀏覽器單線程的限制。框架運行時、Hydration、依賴解決、狀態初始化——這些都浪費了頁面互動前的時間。

即使是少量的互動功能，也常常需要不成比例的捆綁包大小。預設以JavaScript為核心的架構，為了維持性能需要持續調整。

相反，將JavaScript明確定位為選擇性啟用的架構，往往能產生更穩定的結果。這種哲學差異，明顯反映在Lighthouse分數上。

建置時處理排除不確定性

預渲染的輸出，從性能方程式中移除多個變數：

• 不需在請求時進行伺服器端渲染的成本
• 不需在客戶端啟動時進行引導
• 瀏覽器收到預測完整的HTML

因此，TTFB、LCP、CLS等指標自然改善。雖不能保證完美分數，但大幅降低失敗風險。

實例學習

一個個人部落格的重構專案中，嘗試了多種方案。基於React、預設Hydration的設定較為彈性，但性能需持續關注。每次新增功能，都要重新檢討渲染策略、資料取得方式與捆綁包大小。

相較之下，以靜態HTML為起點、將JavaScript視為例外的方案效果顯著。選擇Astro，是因為其限制設計與我們驗證的假設相符。

令人驚訝的不是初始分數，而是隨時間變化的性能穩定性：

• 新內容發布不會導致分數下降
• 小型互動元素不會引發連鎖警告
• 基線不易退化

在這樣的架構下，Lighthouse分數不再是追求的目標，而是自然的結果。

取捨的現實

這種方法並非萬用。以靜態為中心的架構，不適用於高度動態、狀態豐富的應用。需要認證用戶資料、即時更新、複雜客戶端狀態管理的場景，實作會變得更複雜。

以客戶端渲染為前提的框架，則提供較高的彈性，但代價是執行時的複雜性增加。

重點在於，哪種架構較優並非重點，而是架構選擇會直接影響Lighthouse指標。

分數穩定與下降的原因

Lighthouse揭示的，並非最佳化的成果，而是系統複雜度。

依賴執行時間計算的系統，隨著功能增加，複雜性累積。預先建置的系統，則能在默認狀態下抑制這些複雜性。

這解釋了為何某些網站需要不斷調整性能，而另一些則能在最小干預下保持穩定。

本質的選擇

高分Lighthouse，通常不是由積極優化工具調整的結果，而是由於架構本身最小化瀏覽器初始載入負擔的自然產物。

工具與趨勢會變，但基本原則不變：將性能作為設計限制，而非目標。如此一來，Lighthouse分數不再是追求的指標，而是觀測的數據。

這個轉變，關鍵不在於「用哪個框架」，而在於「在哪裡允許系統複雜性」。