Lighthouse的評估值不是調整工具，而是反映架構健康狀況的鏡子

為什麼在同一網站會有差異

如果追求Lighthouse的高評價值，僅僅進行圖片壓縮、腳本延遲載入、布局偏移對策的反覆優化是不夠的。觀察實際專案時，持續維持高分的網站與每次新增新功能後分數下降的網站之間的差異，不在於努力的程度，而在於設計階段的選擇。瀏覽器在載入時處理的工作量越少，網站的分數越穩定。

Lighthouse真正檢測的內容

Lighthouse不是用來判定框架優劣的工具，而是將實際用戶體驗數據化的工具。

• 內容呈現在畫面上的速度
• JavaScript阻塞主線程的程度
• 頁面載入過程中的布局穩定性
• 文件結構的可及性與爬取性

這些指標反映了開發初期的決策如何影響結果。依賴大型客戶端捆綁包的頁面，分數必然較低。而以靜態HTML為基礎的頁面，性能則較容易預測。

JavaScript與Hydration：性能下降的主要元兇

從多個審核專案中可以得知，JavaScript執行是拖累Lighthouse分數的最大因素。這並非程式碼品質問題，而是瀏覽器單線程環境的根本限制。

Hydration過程尤其負擔沉重，所有框架運行時的初始化、依賴圖解析、狀態初始化等任務，都在頁面變得可互動之前完成。為了少量的互動功能，往往需要不成比例的巨大JavaScript捆綁包。

預設以JavaScript為核心的架構，若要維持性能，必須持續進行優化。而將JavaScript明確作為選擇性啟用的架構，則能產生更穩定的結果。

靜態生成帶來的確定性

預先渲染的HTML能消除多個性能變數：

• 無需伺服器端渲染延遲
• 無需客戶端啟動處理
• 瀏覽器收到完整且可預測的HTML

因此，TTFB、LCP、CLS等主要指標會自動改善。靜態生成不保證完美分數，但能大幅降低失敗的可能性。

實例：從個人部落格重構中學到的事

在重構部落格時，我嘗試了幾種標準方法。預設依賴Hydration的React架構較為彈性，但每次新增功能都會讓渲染模式、資料取得、捆綁大小陷入困境。

我決定嘗試不同的思路：以靜態HTML為預設，將JavaScript作為例外。選擇Astro進行實驗，是因為它的預設限制與我想驗證的假設相符。

令人印象深刻的是，較高的初始分數並不重要，隨著時間推移，維持分數所需的努力竟然如此少。新內容的發布不會造成倒退，小型的互動元素也不會引來無關的警告。基線未被侵蝕，這點令人欣慰。

沒有萬用的解決方案

這種方法並非在所有情況下都是最佳選擇。需要認證用戶資料、即時更新、複雜客戶端狀態管理的應用，靜態優先架構就力有未逮。

客戶端渲染框架在需要高度彈性的場景中更具優勢，但相對的，執行時的複雜性也會提高。重要的是架構的選擇會直接反映在Lighthouse指標上。

影響Lighthouse分數穩定性的因素

Lighthouse揭示的不是努力，而是熵。

依賴運行時計算的系統，隨著功能增加，複雜性會逐漸累積。而將處理移到建置階段的系統，則能在預設狀態下抑制這種複雜性。

這個差異解釋了為何某些網站需要不斷進行性能優化，而另一些則能在最少干預下保持穩定。

結論：分數不是追求的目標，而是觀察的指標

高分的Lighthouse分數，並非來自積極的優化努力，而是源自於將瀏覽器在載入時的工作量降到最低的架構。

將性能視為設計的限制而非目標，Lighthouse就不再是追求的指標，而是用來觀察系統健康狀況的工具。關鍵不在於選擇正確的框架，而在於在哪裡容許複雜性。