Performance Budget
效能預算
效能預算是在開始工作前，先為檔案大小、時間或使用體驗訂出上限，讓設計和程式選擇有清楚限制。
另一個例子
如果 JavaScript 超過 170 KB，或行動版 LCP 超過約定的實驗室門檻，合併請求就不能通過。檢查會看程式檔、圖片和 CI 結果；只說網站「要快」但沒有數字和檢查點，不算預算。
主要部分
- 01量測指標
- 02門檻
- 03執行 gate
什麼時候用
工作開始前先同意可量測的上限，並在清楚的檢查點執行時，可以使用這個詞。
什麼時候不要用
如果還不了解裝置、網路、網址和商業需求，就不要隨意設定門檻。
程式裡的名稱
metric ≤ threshold at release gate 上線前要檢查
檢查環境與預先準備的測試資料。定義看得到的預期結果、失敗與邊界案例。也要定義隔離方式、固定輸入、查錯資訊與清理流程。設定執行時間預算、負責人與不穩定測試的處理規則。
預期成果：用 效能預算 (Performance Budget) 收集可重複驗證這項行為或品質風險的證據。 使用者情境：如果 JavaScript 超過 170 KB，或行動版 LCP 超過約定的實驗室門檻，合併請求就不能通過。檢查會看程式檔、圖片和 CI 結果；只說網站「要快」但沒有數字和檢查點，不算預算。 驗證方式：效能預算 (Performance Budget)。 適用理由：工作開始前先同意可量測的上限，並在清楚的檢查點執行時，可以使用這個詞。 不應使用的情況：如果還不了解裝置、網路、網址和商業需求，就不要隨意設定門檻。 測試要求：說明要測的系統與環境。定義預先準備的測試資料（Fixture）、其他輸入，以及看得到的預期結果。加入預期失敗、邊界案例、容許值、隔離方式與清理流程。 測試維護：讓失敗原因容易查找，並控制隨機或會改變的輸入。指定負責人。測試速度與維護成本要符合發布前檢查的需要。 驗收條件：已知缺陷存在時測試會失敗，修正後通過。測試能在目標環境重複執行，提供可採取行動的證據，且不洩漏或改動無關資料。 證據與限制（證據邊界）：沒有一份官方標準能管到全部內容。不同團隊、平台或框架的用法可能不同。 待確認：發布前必過的檢查、環境、測試資料、容許值、執行時間預算、負責人，以及不穩定測試的處理規則。
檢查這份需求
請 AI 程式助手檢查目前如何使用 效能預算 (Performance Budget)。 定義：效能預算是在開始工作前，先為檔案大小、時間或使用體驗訂出上限，讓設計和程式選擇有清楚限制。 正式環境檢查：檢查環境與預先準備的測試資料。定義看得到的預期結果、失敗與邊界案例。也要定義隔離方式、固定輸入、查錯資訊與清理流程。設定執行時間預算、負責人與不穩定測試的處理規則。 修改程式前，先列出看到的證據、缺口、嚴重程度，以及最小且安全的修正。