出現性能問題不可怕，可怕的是沒有目標，用戶只是說「我希望它非常快」，或者說「和以前一樣快」，在這種情況下，我們就需要把制定性能衡量標準放在首位了，原因有兩個：
（1）性能衡量標準是技術與業務之間的契約
「非常快」是一個直觀性的描述，它不具有衡量的可能性，對技術人員來說，一個請求在2秒鐘之內響應就可以認為是「非常快」了，但對業務人員來說，「非常快」指的是在0.5秒內看到結果——看，出現偏差了。如果我們不解決這種偏差，就有可能出現當技術人員認為優化結束的時候，而業務人員還認為系統很慢，仍然需要提高繼續性能，於是拒不簽收驗收文檔，這就產生商務麻煩了。
（2）性能衡量標誌是技術優化的目標
性能優化是無底線的，性能優化得越厲害帶來的副作用也就明顯，例如代碼的可讀性差，可擴展性降低等，比如一個乘法計算，我們一般是這樣寫代碼的：
int i=100*16；
如果我們為了提升系統性能，使用左移的方式來計算，代碼如下：
int i=100＜＜4；
性能確實提高了，但是也帶來了副作用，比如代碼的可讀性降低了很多，要想讓其他人員看明白這個左移是何意，就需要加上註釋說「把100擴大16倍」，這在項目開發中是非常不合適的。因此為了讓我們的代碼保持優雅，減少「壞味道」的產生，就需要定義一個優化目標：優化到什麼地步才算結束。
明白了性能標準的重要性，就需要在優化前就制定好它，一個好的性能衡量標準應該包括以下KPI（Key Performance Indicators）：
核心業務的響應時間。一個新聞網站的核心業務就是新聞瀏覽，它的衡量標準就是打開一個新聞的時間；一個郵件系統的核心業務就是郵件發送和接收速度；一個管理型系統的核心就是流程提交，這也就是它的衡量標準。
重要業務的響應時間。重要業務是指在系統中佔據前沿地位的業務，但是不會涉及業務數據的功能，例如一個業務系統需要登錄後才能操作核心業務，這個登錄交易就是它的重要交易，比如郵件系統的登錄。
當然，性能衡量標準必須在一定的環境下，比如網絡、操作系統、硬件設備等確定的情況下才會有意義，並且還需要限定並發數、資源數（如10萬數據和1000萬的數據響應時間肯定不同）等，當然很多時候我們並沒有必要白紙黑字地簽署一份協約，我們編寫性能衡量標準更多地是為了確定一個目標，並盡快達到業務要求而已。