控制瀏覽器的負荷是Lighthouse分數的本質意義

為何即使積極改善 Lighthouse 分數，仍無法達到預期效果？許多開發者反覆進行圖片壓縮、腳本延遲載入、布局偏移對策、插件優化。然而，觀察那些持續維持高分數的網站時，會發現一些模式。那不是激烈調整的結果，而是因為這些網站在瀏覽器執行時所需處理的計算量本身就較少。

換句話說，Lighthouse 不僅僅是個優化工具，更是一個信號，顯示架構設計是否真正做出了有意義的選擇。

瀏覽器實際測量的內容

Lighthouse 評估的不是特定框架，而是由這些框架產生的結果。具體來說，它測量以下幾項：

• 內容變得可視的速度
• JavaScript 阻塞主線程的程度
• 載入過程中的布局穩定性
• 文件結構的可及性

這些指標都在架構設計階段就已決定，尤其是與執行時交由瀏覽器處理的計算量直接相關。

如果頁面運作需要大量的客戶端捆綁（bundle），低分數是理所當然的。反之，若以靜態 HTML 為基礎，將客戶端處理降到最低，性能就會變得可預測。

JavaScript 執行是最大變動因素

根據過去的審查經驗，導致 Lighthouse 分數下降的最常見原因是 JavaScript 的執行。這不是程式碼品質的問題，而是因為 JavaScript 在單線程環境中排他性執行的根本限制。

框架的運行時、Hydration、依賴解析、初始狀態設定——這些都在頁面變得互動前消耗時間。即使是較小的互動功能，也常常需要不成比例的巨大捆綁。

在這裡，做出明智的判斷非常重要。以 JavaScript 為預設的架構，維持性能需要持續努力。而將 JavaScript 明確視為選擇性加入的架構，則較容易獲得穩定的結果。

靜態輸出帶來的可預測性

預渲染的輸出，從性能方程式中排除多個不確定因素：

• 無需承擔請求時的伺服器端渲染成本
• 無需客戶端啟動（bootstrap）
• 瀏覽器收到的是完整且可預測的 HTML

從 Lighthouse 的角度來看，僅靠這樣的結構，即使沒有特別的優化，也能改善 TTFB、LCP、CLS 等指標。雖不能保證完美分數，但能大幅降低失敗的風險。

實作驗證範例

在重構個人部落格時，我比較了多種方案，包括依賴 React Hydration 的設置。這些方案都具有彈性與功能性，但維持性能始終需留意。每次新增功能，都得判斷渲染模式、資料取得與捆綁大小。

我也嘗試以優先使用靜態 HTML、將 JavaScript 視為例外的方式。選擇 Astro，是因為它的預設限制與我想驗證的假設相符。

令人驚訝的是，並非初始分數，而是後續維持的便利性。新增內容不會導致分數倒退，小型互動元素也不會引發意料之外的警告，基線因此較不易被侵蝕。在實驗中，我成功保持了理想的 Lighthouse 分數，並將建置流程的取捨另行記錄。

選擇方案的取捨

理解這種模式並非萬用的很重要。

靜態優先架構不適用於高度動態、狀態豐富的應用。例如需要認證用戶資料、即時更新、複雜客戶端狀態管理的情境，實作會變得複雜。

在這些情況下，以客戶端渲染為前提的框架提供彈性，但也帶來執行時的複雜性。重點在於，哪個方案較為適合，並且所選架構能以有意義的方式，直接反映在 Lighthouse 指標上。

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

Lighthouse 揭示的不是努力的結果，而是熵（entropy）。

依賴執行時間計算的系統，隨著功能增加，複雜性會逐漸累積。預先在建置階段進行計算的系統，則能將這些複雜性控制在較低水準。

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

本質意義

高分的 Lighthouse 分數很少是積極優化的成果。反而，是由於架構本身在初期就已經最小化瀏覽器在載入時所需執行的工作量。

工具會變，但根本原理不變。當性能不再是追求的目標，而是架構設計的初始限制時，Lighthouse 的角色也會從「達成目標」轉變為「觀察現狀的指標」。

這個轉變的起點，不在於選擇正確的框架，而在於有意識地限制那些允許貪婪累積複雜性的空間。