異步的概念之所以先在Web 2.0中火起來，是因為在瀏覽器中JavaScriptd在單線程上執行，而且它還和UI渲染共用一個線程。這意味著JavaScript在執行的時候UI渲染和響應是處于停滯狀態的。《高性能JavaScript》一書中曾說過，如果腳本的執行時間超過100毫秒，用戶就會感到頁面卡頓，以為網頁停止響應。而在B/S模型中，網絡速度的限制給網頁的實時體驗造成很大的麻煩。如果網頁臨時需要獲取一個網絡資源，通過同步的方式獲取，那么JavaScript則需要等待資源完全從服務器端獲取后才能繼續執行，這期間UI將停頓，不響應用戶的交互行為。可以想象，這樣的用戶體驗將會多差。而采用異步請求，在下載資源時間，JavaScript和UI的執行都不會處于等待狀態，可以繼續響應用戶的交互行為，給用戶一個鮮活的頁面。 同理，前端通過異步可以消除掉UI阻塞的現象，但是前端獲取資源的速度也取決于后端的響應速度。假如一個資源來自于兩個不同位置的數據的返回，第一個資源需要M毫秒的耗時，第二個需要N毫秒的耗時。如果采用同步的方式，代碼大致如下： ~~~ // 消費時間為 M getData('from_db'); // 消費時間為 N getData('from_remote_api'); ~~~ 但是如果采用異步方式，第一個資源的獲取并不會阻塞第二個資源，也即第二個資源的請求并不依賴第一個資源的結束。如果，我們可以享受到并發的優勢，相關代碼如下： ~~~ getData('from_db',function(){ // 消費時間為M }); getData('from_remote_api',function(){ // 消費時間為N }); ~~~ 對比兩者的時間總消耗，前者為M+N，后者為 max(M,N)。 隨著應用復雜性的增加，情景將會變成M+N+... 和max(M,N,...)，同步于異步的優劣將會凸顯出來。另一方面，隨著網站或應用不斷膨脹，數據將會分布到多臺服務器上，分布式將會是常態。分布也意味著M與N的值會線性增長，這也會放大異步和同步在性能方面的差異。為了讓讀者感知到M和N值具體多昂貴，下表列出了從CPU一級緩存到網絡的數據訪問所需要的開銷：  這就是異步I/O在Node中如此盛行，甚至將其作為主要理念進行設計的原因。I/O是昂貴的，分布式I/O是更昂貴的。 只有后端能快速響應資源，才能讓前端的體驗變好。