2. 根據研究結果，一旦系統出現100~200ms的延遲，絕大數人都會確實感到所謂的「延誤」 (lag)。一旦延遲時間超過300ms，在互動上通常就會被當作是「遲鈍」 (sluggish)，而在碰到1000ms以上的阻塞情況下，很多使用者都會在等候回應的時候，開始轉到另一個更迫切的事務上。
3. TCP的最佳化重點是在資料傳遞的準確性，而非即時性。這樣的特性，相對地位瀏覽器網頁效能的最佳化工作帶來挑戰。
4. 「壅塞崩潰」(congestion collapse): 假如任何主機的往返時間超過重新傳送的最大間隔的話，這主機就會一再地把相同資料包的副本發送到網路上。如此一來，整個網路就會出現很大的麻煩問題。
5. Head-of-Line Blocking: 每個TCP封包被放置在網路上的時候，夾帶著一個獨一無二的序號，而該項資料一定會被依序第傳到接收端。假如其中有個封包在送往接收端的路上發生遺失狀況的話，所有後續封包就必須先被保留在接收端的TCP緩衝區，直到遺失的封包被重新傳送，並且到達接收端為止。
6. UDP不提供的服務
6.1 不保證訊息傳遞情況 => 沒有ACK訊號，不做重新傳送，沒有逾時機制。
6.2 不保證傳輸次序 => 無封包序號，不做重新排序處理
6.3 無連線狀態追蹤 => 沒有連線建立或拆卸機制
6.4 無擁塞控制機制 => 無內建客戶端或網路回饋機制
7. Browser Prosessing Pipeline
8. Cookies 是許多應用程式的常見效能瓶頸，許多開發者都會忘記，他們會因此而把明顯的傳輸負擔加諸到每一個請求上。
9. 考慮對低於1~2KB以下的資源進行內聯處理(resource inlining)，因為在這個門檻以下的資源，往往都會產生比該項資源本身還高的HTTP成本。
- 假如檔案都是小的，而且被限定在幾個特定頁面裡的話，考慮內聯處理。
- 假如小的檔案常常會被多個頁面重複使用到的話，就考慮套件打包方式。
- 假如小的檔案擁有較高的更新頻率的話，則將他們個別保存。
- 減少DNS查詢
- 重複使用TCP連線
- 將HTTP重導數量降到最低
- 使用內容傳輸網路(CDN)
- 刪除不必要資源
