一直以來，當我們每次提到網站效能時總是想到各種技術術語。例如 DNS 查詢、Gzipping、minifying、far future expires headers、快取、ETags 等等專業詞彙被丟擲後，結果很多非技術的人很難對這個產生興趣。
現在是時候讓我們不僅把效能僅作為技術的最佳實踐，同時還應該作為設計的一方面。
我們都能感受到
經常有人問我是以什麼為生的。每次當我提到我是做移動開發時，他們會立即跟我反映“Facebook 太爛了！”
為什麼會有這麼直接的發自內心的抱怨呢？他們不是對 Facebook 導航條的直觀感覺，也並不執意時間軸設計的優雅性。由於 Facebook 的整個 Clusterfudge 系統所做的一切，導致其手機應用程式慢得跟坨屎一樣。
（伯樂線上注：本文是一篇 2012 年左右的舊文）
現在的網頁變得越來越臃腫。做網頁的“玩具”也越來越多了，這同時也意味著存在著更多潛在的危害。Phil Hawksworth 曾指出了一些荒誕的網站：
如果你的網頁超過 15MB，且不是由BHTML5 編寫的，那這是個愚蠢的網頁。 —— Christian Heilmann
雖然這些網站有可能會被人注意到（儘管有很多網站存在一些爭議），但是大部分訪客永遠都不可能訪問這些網站。如果一個網頁載入超過 5 秒，那麼74%的手機端使用者會選擇關閉這個網頁。這意味著你有5秒鐘的時間讓他們獲得他們想要的東西，不然他們就會選擇離開。
好的效能就是好的設計
好的效能之路，並不是從技術人員或者技術堆疊開始的（儘管我並不是說這些東西不重要）。好的效能是從大家一起參與並使產品快速開發出來開始的。以下這幾點是需要考慮的：
- 專案書中應包括效能設計——工作陳述、專案建議及設計簡介中應該多次明確的提出將效能作為首要目標。“這個專案的目標是開發一個驚豔的、靈活的、閃電般體驗的…”
- 儘快將設計稿放到瀏覽器中體驗效果——把網站設計排版掛在牆上看起來也許還可以(?)，但是以這種方式來衡量在最終實際執行環境中的效果，太不靠譜了。當我們開啟 The Post-PSD Era 這個頁面時，我們可以看出頁面效能以設計為導向遠遠比傳統瀑布流過程要快得多。
- 在實際裝置中做測試——Stephanie Rieger 說過，通過縮小的視窗或者模擬器中來衡量設計效果是不太實際的。在開發階段的早期，就要通過實際裝置進行測試，因為你可以在實際裝置中看到在你的設計中接入的每個元素所產生的真正的效果。
- 團隊協作——開發人員應該在早期專案設計的過程中就參與進來，同時應該指出對於設計模型和排版中潛在的效能問題。重要的是，這個過程不是為了達成一個非對即錯的一致意見，而是為了能夠真正的科學協作。
- 培訓——在設計過程中，許多人並不知道他們的設計決策對效能所產生的後果。要讓他們知道，如果頁面中包含5種字型，對效能是有很大的傷害的。當他們想要在頁面中加入大量大圖時，需要讓他們三思。需要驗證想法的時候，可以在 Codepen上製作一個快速原型，然後坐下來用一個用3G連線的真實裝置做體驗。
終極效能就是尊重。尊重使用者的時間，他們將更有可能帶著良好的體驗離開。良好的效能就是好的設計。是時候這樣做了。