原章：One Simple Rule
Safari 團隊逐漸擴大後，產品目標很清楚：Steve Jobs 要一個快的瀏覽器。但「快」如果只是主管一句話，很容易變成每個工程師心中不同的標準。更麻煩的是，效能最佳化也可能變成無止境的局部工程，大家花很多時間優化不重要的地方。
Don Melton 建立了 Page Load Test（PLT），用一組刻意挑選、相當折磨瀏覽器的網頁，反覆測量平均載入時間。它不是要模擬所有真實網站，而是建立一個穩定的共同尺。
團隊逐漸形成一條很簡單的規則：任何程式碼變更都不應讓 PLT 變慢。 如果變慢，就必須理解原因，不能把退步當成正常代價默默留下。
| 故事節點 | 抽象目標 | 具體機制 | 產生的效果 |
|---|---|---|---|
| Steve 要 Safari 很快 | 「快」人人都同意，但難以日常管理 | 建立 PLT | 把感覺轉成可重複比較的數字 |
| 每次程式變更 | 局部功能可能偷偷犧牲整體效能 | 不允許 PLT 無理由退步 | 每個人都對共同速度目標負責 |
| 效能工作 | 容易陷入「任何地方都可以優化」 | 由測試指出真正有影響的地方 | 工藝被集中在會改變使用者體驗的位置 |
| 反覆演練 | 一次達標不等於長期品質 | 每天、每次變更持續量測 | 品質成為習慣而非發表前衝刺 |
最好的規則往往不是最多的規則。Safari 團隊需要的是一個能把許多不同工程決策拉到同一方向的約束，而不是一本厚重的效能手冊。
團隊接受 PLT 不可能代表所有網路情境，但仍把它當作穩定的共同基準。作者把這和 Vince Lombardi 反覆操練 Power Sweep 作比較：不是靠花俏戰術贏，而是把少數關鍵事情練到非常好。
Apple 在公開 Safari 前，Steve 也反覆完整排練 Macworld keynote。對 Ken 而言，這再次說明 craft 與 diligence 的關係：看似自然的高品質，背後其實是重複練習與不斷修正。
Safari 的速度改善不是靠一次英雄式最佳化，而是讓每一輪開發都持續接受同一個測試壓力。這種累積使「快」逐漸變成產品本身的一部分。
模糊的品質要求如果沒有可操作的機制，就很難在幾百個小決定中存活。一條好規則的力量，在於它能把每個人的局部工作都拉向同一個產品目標。