響應(yīng)式Web設(shè)計性能優(yōu)化目錄\h第1章響應(yīng)式設(shè)計現(xiàn)狀\h1.1響應(yīng)式設(shè)計存在的問題\h競爭分析中的發(fā)現(xiàn)\h反模式\h模式\h我們怎么沒有感覺到\h從最初到響應(yīng)式設(shè)計到現(xiàn)在我們經(jīng)歷了哪些\h為什么不使用“m.”專有站點\h1.2小結(jié)\h第2章初識Web應(yīng)用性能\h2.1性能度量基礎(chǔ)\hHTTP請求數(shù)\h頁面負載\h頁面加載時間\h2.2追蹤Web性能的工具\h2.3Web運行時性能\h每秒幀數(shù)\h內(nèi)存分析\h2.4小結(jié)\h第3章千里之行始于計劃\h3.1滑坡謬誤的一段經(jīng)歷\h3.2項目計劃\h評估和總結(jié)整個任務(wù)\h確定粗略的里程碑與時間表\h衡量成功的關(guān)鍵性能指標（KPI）\h遵守性能SLA\h3.3小結(jié)\h第4章響應(yīng)式服務(wù)端實現(xiàn)\h4.1Web棧\h網(wǎng)絡(luò)棧\h應(yīng)用層\hCharles\h4.2Web應(yīng)用棧\h4.3服務(wù)端響應(yīng)\h檢查UserAgent\h設(shè)備檢測服務(wù)\h4.4緩存的影響\h4.5EdgeSideInclude\h4.6小結(jié)\h第5章響應(yīng)式前端實現(xiàn)\h5.1圖片操作\hSRCSET屬性\hpicture元素\h5.2延遲加載\h設(shè)備檢測庫\h5.3小結(jié)\h第6章持續(xù)測試Web性能\h6.1保持一個穩(wěn)定的過程\h6.2Web響應(yīng)式性能自動測試\hheadlessbrowser自動測試\h6.3持續(xù)集成\hPhantomJS腳本示例\hJenkins\h6.4小結(jié)\h第7章響應(yīng)式設(shè)計框架\h7.1響應(yīng)式設(shè)計框架之現(xiàn)狀\h7.2TwitterBootstrap\h評估\h7.3ZURBFoundation\h7.4Skeleton\h評估\h7.5SemanticUI\h評估\h7.6各種前端框架之間的比較\h7.7Ripple\h7.8小結(jié)第1章響應(yīng)式設(shè)計現(xiàn)狀1.1響應(yīng)式設(shè)計存在的問題我曾與我的一個團隊和產(chǎn)品經(jīng)理參加了一個產(chǎn)品規(guī)劃會議，討論重新設(shè)計我們的視頻區(qū)塊，我們的團隊主管提出了可以讓這個區(qū)塊具備響應(yīng)式體驗的方案。我們勾勒了這樣一張頁面，它會去加載默認的HTML5視頻播放器，不過會根據(jù)用戶所使用的設(shè)備來調(diào)整播放器的大小以及加載不同視頻類型的資源與播放列表。這樣我們的頁面將會非常漂亮，能夠適應(yīng)更多的瀏覽設(shè)備，而且我們的視頻就可以面向以前被拒之門外的各種設(shè)備的觀眾了。這時我們的產(chǎn)品經(jīng)理皺起鼻子說道：“我們的響應(yīng)式首頁出來之后，我就開始覺得我們的響應(yīng)式設(shè)計思想有些問題?！边@讓我甚感詫異。我們的響應(yīng)式首頁問題出在哪里？于是我開始著手做了些研究。產(chǎn)品團隊的印象是頁面加載很緩慢。其實當開發(fā)人員在自己的筆記本電腦上演示時，一切看起來都很棒，然而當他們在真實設(shè)備上向高管們展示時，頁面的加載時間實在太長太長了。我查看了一下主頁在智能手機和電腦渲染瀑布圖。我所看到的就是我在許多其他站點中注意到的一些東西。智能手機端在渲染的時候不僅加載了桌面端全部的資源文件，還加載了額外的CSS與sprite文件。圖1-1表明相對于桌面端，在手機端的渲染增加了兩個額外的HTTP請求，下載量也略微大一些（1.2MBvs952KB）。圖1-1主頁在手機上渲染時的瀑布圖從圖1-1中可以看到，共發(fā)送了134個HTTP請求，總的傳輸量是1.2MB。不過這是智能手機版的，通常情況下應(yīng)該比桌面端的荷載要小?？墒聦嵅⒎侨绱?，如圖1-2所示。圖1-2桌面版主頁渲染時的瀑布圖可以看到桌面版本總荷載是952KB，來自132個HTTP請求。無疑，手機版除裝載所有桌面版同樣的內(nèi)容外，還增加了兩個文件。顯而易見，這加劇了移動體驗中的帶寬問題。這完全與我們創(chuàng)建手機頁面的初衷背道而馳了。無獨有偶，我在我的筆記本上打開瀏覽器，同時查看我iPhone上的HTTPWatch，然后訪問了排名前50的網(wǎng)站，做了一些競爭分析。我發(fā)現(xiàn)這些網(wǎng)站中，有30%的手機版的荷載要高于其對應(yīng)的桌面版——科技公司、銀行、零售商均是如此。除了我自己的研究，許多著名的報告也有相似的結(jié)論。TheSearchAgency（一個全球數(shù)字營銷代理機構(gòu)）分析了零售百強以及財富百強公司的站點，做出了下面的報告?！岸嘀赝妨闶凵獭保╘hhttp://bit.ly/1vqYUPh）。“財富一百強公司”（\hhttp://bit.ly/1r1SDla）。提示

要想訪問這些報告，需要將你的E-mail地址提供給TheSearchAgency，然后TheSearchAgency會將報告發(fā)送給你。在這些結(jié)論中，圖1-3展示出使用了（確切地說是濫用）響應(yīng)式設(shè)計的站點比簡單、普通的桌面站點平均多耗時1.91秒。更讓人詫異的是，它們比手機專用的站點多耗時10.74秒。圖1-3TheSearchAgency對響應(yīng)式站點與手機專用以及桌面專用站點的平均加載時間比較GuyPodjarny——Akamai公司的CTO——在其博客上也發(fā)表過一段文章，詳細描述了他在運行類似測試實驗時的發(fā)現(xiàn)。他比較了多種分辨率下的頁面大小，發(fā)現(xiàn)其間的差別微乎其微。在\hhttp://bit.ly/1tBv6cT上可以找到他的文章。我們都忘記了創(chuàng)建響應(yīng)式體驗的意義了嗎？競爭分析中的發(fā)現(xiàn)我自己在對Alexa排名列表中的頁面測試中也得到了一些有趣的數(shù)據(jù)。其中，我注意到了下面的情況。在美國的熱門網(wǎng)站中，47%仍然使用的是手機專用的“m.”類型的站點?；ㄒ环昼姇r間思考一下這個數(shù)字。這些都是互聯(lián)網(wǎng)上流量最大的站點，可能是各行業(yè)的領(lǐng)頭羊，包括YouTube、eBay以及Target公司，它們都沒有采用響應(yīng)式站點，而是使用了獨立分開的站點。平均來說，這些手機專用的站點的文件要比響應(yīng)式站點小55%。使用“m.”的網(wǎng)站子集平均大小是383KB，而響應(yīng)式站點的平均大小是851KB（見圖1-4）?？梢姟袄硐牒茇S滿，現(xiàn)實很骨感”。圖1-4手機專用站點與響應(yīng)式站點平均文件大小對比（單位：KB）響應(yīng)式站點的荷載有長尾分布的特性，可達到4MB，而“m.”類型的站點的分布范圍都在1MB以內(nèi)。實際上，“m.”類型的站點大都密集分布在0～200KB以及200～400KB的范圍內(nèi)。我做了一個直方圖，來研究下“m.”類型的站點與響應(yīng)式站點中文件大小的分布情況，見圖1-5和圖1-6。圖1-5手機專用的站點文件大小分布（單位：KB）圖1-6響應(yīng)式站點中文件大小的分布（單位：KB）注意每個直方圖中x軸的縮放比例。手機專用站點中有3個離群值接近于1MB；響應(yīng)式站點中，1MB是第二大分組，且尾部一直延續(xù)到4MB。對于響應(yīng)式站點，43%的站點在手機體驗中與桌面體驗中的HTTP請求幾乎相同，或是稍多一些。相比之下，專用站點中只有1.5%在手機體驗中HTTP請求等同或高于其桌面體驗版。圖1-7和圖1-8描繪了這種差異。圖1-7響應(yīng)式站點在桌面和手機體驗中HTTP請求的分組條狀圖圖1-8桌面以及手機專用的“m.”站點體驗中HTTP請求的分組條狀圖在圖1-7中的每個分組里，藍條表示桌面體驗中HTTP請求數(shù)目，黃條表示同一個頁面在手機體驗中的HTTP請求數(shù)。同樣，在圖1-8中的每個分組中，藍條表示桌面體驗中HTTP請求數(shù)目，黃條表示手機體驗中的HTTP請求數(shù)。顯然，我們的響應(yīng)式設(shè)計的實現(xiàn)有問題。并且，提供一個專用體驗的站點存在明顯的優(yōu)勢，至少在HTTP請求數(shù)以及渲染一個頁面需要的總傳輸荷載方面是這樣的（不過也要注意，“m.”類型的站點也有其自身的一系列問題，我們后面會簡短討論）。應(yīng)當注意到，貫穿本書，我的觀點以及重復(fù)提到的主題自始至終都是響應(yīng)式設(shè)計和專用體驗并不是互斥的實現(xiàn)，而是同一理念的多個方面。除了前面的指標，我還注意到我觀察過的那些站點似乎是遵循了一些模式和反模式。反模式我在研究Alexa列表上的每個站點時，發(fā)現(xiàn)它們都存在一些共同的問題以及它們用到的一些反模式。接下來，我們來找出并研究一下這些反模式。為所有設(shè)備加載同樣的內(nèi)容這些站點中，有一些會為手機和桌面渲染加載完全一樣的資源。它們加載同樣的CSS文件，通過媒體查詢給不同的分辨率設(shè)備提供不同的體驗。加載同樣的圖片，通過縮放來解決不同分辨率下的顯示需要。這種錯誤做法的后果會在HTTP擁堵時暴露無遺。在不同的顯示設(shè)備中HTTP請求數(shù)目完全一樣的那些站點極可能就是用了這種做法。當開始考慮更大分辨率的顯示設(shè)備如蘋果的Retina顯示屏以及超高清電視時，這種解決方案就不能很好的擴展顯示。加載額外的資源雖然為所有設(shè)備加載同一組資源忽略了設(shè)備間的本質(zhì)差異，但在手機體驗時加載除了通用資源以外的資源，就完全與我們所熟知的移動體驗相違背了。這些額外的資源一般都是一些CSS以及sprite文件。手機體驗中比桌面包含更多HTTP請求以及更大荷載的站點常會表現(xiàn)出這種行為。正如前面所提到的，我自己的站點正是用了這種反模式。加載雙倍的圖片最大的錯誤是，有些站點會為手機版本加載另外一組圖片，如此一來圖片文件的大小就是桌面版本圖片的兩倍了。這是常規(guī)桌面版圖片之外的內(nèi)容。加載更大的圖片然后再調(diào)整大小是為了讓圖片在小尺寸下顯得更清晰。但這種做法的副作用就是會導(dǎo)致手機版站點的荷載比其桌面版大約要大30%。所有這些問題都有幾個共同的哲學(xué)思想。它們明顯都是著眼于桌面版本，并以此作為基礎(chǔ)，在其上修改或新增元素，而不是從最小版本往上開發(fā)。它們都沒有利用各個平臺的優(yōu)勢，也沒有意識到各個平臺的限制。它們都試圖僅從客戶端來解決問題。模式并不是所有Alexa列表中的站點的做法都是錯的——有些確實體驗很好，為各種設(shè)備與分辨率做了優(yōu)化。我們來看看它們用到的一些設(shè)計模式。加載適合相應(yīng)設(shè)備的資源一些網(wǎng)站針對手機端加載了相比桌面端一半大小的圖片（而不像之前所描述的反模式中加載兩倍桌面端大小的圖片），圖1-9和圖1-10展示了一個例子。圖1-9針對手機端體驗加載了專門為手機端準備的圖片，120×70像素，2KB大?。ń貓D自Chrome開發(fā)工具）可以看到，在圖1-9和圖1-10中所展示的是同樣的圖片，它們的區(qū)別僅僅在于針對不同的客戶端環(huán)境進行了不同程度的縮放。圖1-10針對桌面端體驗加載了專門為桌面端準備的圖片，120×180像素，8.8KB大?。ń貓D自Chrome開發(fā)工具）同樣，有些站點使用了設(shè)備獨有的sprite圖和CSS——并不是在桌面程序的基礎(chǔ)上為其他設(shè)備增加其他資源。這樣需要適當考慮網(wǎng)絡(luò)帶寬限制和傳輸成本。在alexa名單中的大多數(shù)站點都是使用專有“m.”網(wǎng)絡(luò)來完成此功能的。我們同樣也可以建立使用此模式的響應(yīng)式網(wǎng)站，這部分的內(nèi)容會在第4章中出現(xiàn)。從后端提供專有的體驗最好的瀏覽體驗就是對于不同的設(shè)備提供完全不同的專有體驗。有些站點提供了獨立的“m.”網(wǎng)站，另外一些網(wǎng)站展示的是從服務(wù)端傳輸過來的基于設(shè)備獨有布局和功能的頁面。這種解決方案我們稱之為RESS（響應(yīng)式設(shè)計+服務(wù)端組件），但是對于我們常用來為預(yù)定義的分辨率斷點來說，我們真的需要在一個“m.”站點中為每一部分功能傳輸加載適當?shù)膬?nèi)容的同時，合并相同的業(yè)務(wù)邏輯。我們將在第4章討論這種方案的更多細節(jié)。為了更清晰地解釋這個解決方案的架構(gòu)，我們來看看圖1-11所展示的這個架構(gòu)的時序圖。圖1-11后端提供基于設(shè)備的專有體驗的時序圖請注意，這些站點在提供專有體驗的同時，保證了最小的荷載和最大限度的加速。這也就是為什么47%的頂尖站點仍然提供專有的網(wǎng)頁內(nèi)容。前端延遲加載的專有體驗有些站點不僅對圖片進行延遲加載，而且對整個內(nèi)容模塊也進行延遲加載，包括上方和下方的折疊部分。通過這種方式，可以有效地避免為每個斷點加載內(nèi)容，智能地加載那些需要的內(nèi)容，從而適應(yīng)客戶端性能，達到最佳的體驗，但是是否延遲加載的決定權(quán)在客戶端，而不是在服務(wù)端，我們將在第5章詳細討論相關(guān)細節(jié)。圖1-12用時序圖展示了這種方法的細節(jié)。圖1-12從客戶端加載和設(shè)備相匹配的資源我們怎么沒有感覺到本章的前面部分我已經(jīng)描述了我們是怎么向產(chǎn)品經(jīng)理展示我們的響應(yīng)式主頁的。經(jīng)過一個迭代的開發(fā)，我們已經(jīng)可以在我們的筆記本電腦上打開這個頁面了，現(xiàn)在我們的桌面屏幕上可以滿屏展示這個頁面，并且可以自定義我們的瀏覽器窗口大小來適應(yīng)不同的屏幕大小場景。雖然看著我們頁面可以自適應(yīng)屏幕大小是一件非常有趣的事情，但是在其他的設(shè)備上，它表現(xiàn)得一團糟。我們在MacBookPro上，也就是在我們的開發(fā)機上通過公司網(wǎng)絡(luò)展示這個頁面，當然看起來一點問題都沒有。但是我們不能在我們預(yù)定的性能要求底限下工作（例如服務(wù)層協(xié)議或者SLA）。同時，我們甚至不能在非自己的設(shè)備上測試，最重要的是，我們不能違背SLA性能協(xié)議，至少我們不能比現(xiàn)有的主頁性能低，畢竟在我們的性能監(jiān)控平臺上不能報警。在第3章中我們將詳細討論這個問題。從最初到響應(yīng)式設(shè)計到現(xiàn)在我們經(jīng)歷了哪些早在2008年左右，也就是在響應(yīng)式設(shè)計出現(xiàn)之前，我們需要維護兩個URL：和（我們的“m.”站點），在同樣的WebApp中，每一個站點都需要有不同的頁面甚至不同的App來適配。它們可能由不同的團隊負責，在當時，我們的想法很前衛(wèi)，也很罕見，并且已經(jīng)有了手機頁面在使用了。然后，在2011年，BostonGlobe項目重新啟動，響應(yīng)式設(shè)計和漸進增強的想法已經(jīng)成為了每次發(fā)布的博客和頭腦風暴會議的主題了。我們閱讀了關(guān)于如何創(chuàng)建自適應(yīng)用戶設(shè)備的響應(yīng)式頁面的文章。而且我們都被這些概念和想法深深地迷住了。從2000年以來，那些利用相對高度和寬度創(chuàng)建流式布局的的忠實擁

躉，一開始并沒有感覺什么不同，但是當他們看到字體大小和圖片同樣可以被縮放的時候，他們也被這種新的想法深深地吸引了。業(yè)界關(guān)于這方面的探討也如火如荼地開展起來，有很多書出版了，演講會也開展了起來，每個人都開始制作響應(yīng)式網(wǎng)站。我們也開始討論和使用媒體查詢來封裝不同尺寸屏幕的樣式，而且嘗試使用多種方法縮放圖片。當我們在真實項目中運用這些新的想法時，都應(yīng)該從最小的屏幕尺寸開始，并且在打下堅實的基礎(chǔ)后，逐步提高。事實上，我們的老板只想看到最終完整的版本（比如桌面版），這樣，他們就可以向公司領(lǐng)導(dǎo)層邀功了。所以設(shè)計團隊首先開工了，我們所有人都為實現(xiàn)這個版本而努力。但是我們可以巧妙地使用媒體查詢來控制CSS來達到降低視覺體驗的差異，看起來一切都可以解決的，對吧？我們基于CSS和JavaScript來完成桌面版（最多只有幾百KB的大小），然后加載到智能手機和平板電腦上，通過前端的功能我們可以確定客戶端的詳細信息。當一切都完成以后，我們可以向我們的老板展示，我們的老板也會向公司高層匯報，在一切就緒以后，項目就可以發(fā)布上線了。不可避免地，這樣開發(fā)多少會造成代碼的問題，以至于我們不得不花一些時間來進行重構(gòu)。因為我們的CSS是基于桌面版的，是的，我們的所有l(wèi)ink都最終連接到我們的桌面版代碼中。然而，我們不能諱疾忌醫(yī)，我們必須持續(xù)重構(gòu)。因為我們產(chǎn)品的迭代速度非常快，我們需要資源來進行培訓(xùn)。項目已經(jīng)在運行中，但是現(xiàn)在的問題是，我們只關(guān)注前端樣式是不是好看，頁面是不是美觀。媒體查詢和圖片自動縮放看起來很酷，但是，如果只關(guān)注這些表面的東西，我們就會從本質(zhì)上錯過了根據(jù)用戶當前的設(shè)備來進行整體體驗優(yōu)化的機會，這不能被稱作真正的響應(yīng)式。我們不僅僅關(guān)注前端頁面是怎么展現(xiàn)的，我們還把我們所有的判斷邏輯都放置于前端。僅僅依賴于媒體查詢來實現(xiàn)不同設(shè)備上的解決方案，或者通過JavaScript來測試前端，意味著我們向客戶端傳送了額外的文件。這種反模式的方法是我們已經(jīng)察覺到的，如圖1-13所示。圖1-13反模式的時序圖不同設(shè)備之間的差異性，包括處理器能力、電池壽命和內(nèi)存大小都會在我們將注意力集中在前端或者頁面樣式的時候被忽視。在實際項目中，這些都是我們需要在響應(yīng)中應(yīng)該注意的因素。這就是現(xiàn)在網(wǎng)絡(luò)上主要的門戶仍然維護著專有“m.”站點的原因。為什么不使用“m.”專有站點到目前為止，我們都在討論“m.”站點的好處，那你也許要問了，既然它這么好，我們沒有理由不用它啊。這里需要申明的一點是：我并不認同“m.”。它當前的確在人們使用響應(yīng)式設(shè)計的時候帶來顯著的性能提升。但是它同時也有一些缺點。資源開銷早在2000年的時候，當我創(chuàng)建我的第一個“m.”網(wǎng)站的時候，我必須讓一個全新的工程師團隊來開發(fā)和維護它。這主要是因為我們的產(chǎn)品團隊并不想在建立主站的時候，影響移動設(shè)備的體驗，這還因為移動站點是一項極其復(fù)雜和耗費精力的工作，我們不僅需要在主流的iOS和Android設(shè)備上支持它，還需要在其他操作系統(tǒng)的手機上支持它，這些手機都有不同大小的屏幕和特定的屬性。包括對JavaScript甚至JavaScript的基本功能都支持的限制。即使你不會使用一個單獨的團隊來維護，你仍然需要把你主站的相關(guān)工作，也就是“m.”網(wǎng)站，作為一個單獨的項目來持續(xù)維護，事實上，某些功能在某些類型的手機上壓根就不支持。分散的代碼維護一個單獨的網(wǎng)站也就意味著你需要維護一個單獨的WebApp和單獨的一份代碼。保持代碼之間的同步是一個由來已久的問題，當前最主要的解決方法就是個人的自覺性和流程上保證，也就是說，最終它會變得混亂不堪和雜亂無章，當我們的代碼沒有辦法進行同步，我們就失去了對代碼的控制，我們最后很可能看到的是兩個不同的網(wǎng)站，將來我們會花費更多的精力在更新上。分段獨立的URL使用一個單獨的“m.”網(wǎng)站也就意味著你需要創(chuàng)建和維護一個單獨的URL，這和我們將一個資源作為一個統(tǒng)一的管理的整體思想相違背。對網(wǎng)站來說，一個“m.”就是第二個站點，此外，如果這樣的話，我們的“m.”站點的未來將何去何從？它的底線在哪里呢？你會把它放到功能手機里面嗎？或者智能手機？又或者平板電腦？那么平板電腦會遇到什么情況呢？它們都會進入到同一個“m.”站點嗎？或者你能為不同的尺寸和特性分別維護一個單獨的網(wǎng)站？你很快會發(fā)現(xiàn)，這種分割很快就會讓你疲于應(yīng)付、苦不堪言。毫無意義的重定向使用一個完全獨立的URL也就意味著客戶端進入網(wǎng)站的時候需要進行重定向。額外增加一個重定向也就增加了不必要的延遲體驗，因為服務(wù)器需要向客戶端返回302或者304狀態(tài)碼，然后客戶端必須重新向一個新的地址發(fā)送新的請求，就像圖1-14展現(xiàn)的那樣。圖1-14在手機站點上引入HTTP重定向的單獨URL可擴展性帶來的問題到目前為止，我們主要都在討論智能手機和桌面的體驗問題，和平板一起，構(gòu)成我們現(xiàn)在所知道的主要設(shè)備類型。但是工業(yè)的發(fā)展日新月異，在過去的幾年里，我們看到過非常多的新設(shè)備和它們特有的功能，包括網(wǎng)絡(luò)基礎(chǔ)設(shè)施和客戶端的一系列的特色。舉個例子，當蘋果公司發(fā)布了Retina屏幕的時候，我們必須和設(shè)計團隊一起創(chuàng)建獨特的圖片，讓它們在Retina屏上也有不俗的視覺效果。隨著Web開發(fā)在電視指南和App中顯山露水，以及分辨率為4K和8K的超高清電視機的屏幕不斷增大，這一趨勢仍將持續(xù)。另外一個例子就是谷歌眼鏡現(xiàn)在變得越來越普及，所以我們也要考慮我們的站點在眼鏡上的體檢。現(xiàn)在Google提供了一套名叫Mirror的API，從而使得客戶端庫和MirrorAPI可以整合到一起（\hhttp://bit.ly/lrXkSpb）。這些只是一些處于科技前沿的便攜設(shè)備，越來越多的新科技將會涌現(xiàn)。如果我們繼續(xù)把響應(yīng)式設(shè)計看作一個前端的工具的話，那么我們將會發(fā)現(xiàn)頁面臃腫的問題會越來越嚴重，也許我們會看到越來越多的公司將重新回歸到“m.”站點中去。1.2小結(jié)工業(yè)的發(fā)展正在逐步影響響應(yīng)式設(shè)計。在我統(tǒng)計過的站點中，幾乎有一半的站點使用了自己專有的體驗——和我們早在21世紀頭幾年使用的解決方案一樣，而不是提供響應(yīng)式站點。響應(yīng)式設(shè)計并不是一個有缺陷的方法論，只有在它被誤用為一個附加的功能而非首要原則的時候，才會導(dǎo)致一種臃腫的、違反直覺的體驗。同樣，只有當我們將注意力集中到響應(yīng)式的某一個方面，特別是前端特效時，我們才會失去對我們的響應(yīng)式站點性能的敏銳觀察力。然而，性能是響應(yīng)式設(shè)計的一個重要的方面，作為交互的一個重要方面，需要慎重計劃和設(shè)計。當我們在架構(gòu)解決方案時，就要以此為基礎(chǔ)。在本章中，我們已經(jīng)介紹了如何使用一些設(shè)計模式來影響響應(yīng)式的性能。在接下來的章節(jié)中，我們會進一步介紹這些模式，并提出更多的模式。如果我們不做這些功能并且在構(gòu)建我們的響應(yīng)式解決方案中考慮到性能問題，那么，當新的產(chǎn)品和設(shè)備帶來越來越多的新特性后，越來越多的基于特定設(shè)備上的問題都需要解決，這會導(dǎo)致我們需要為每一種設(shè)備創(chuàng)建它獨有的客戶端交互方式。

第2章初識Web應(yīng)用性能2.1性能度量基礎(chǔ)如果你正在閱讀本書，很可能你已經(jīng)熟知性能的含義，或是至少曾經(jīng)圍繞你的Web應(yīng)用做過一些性能相關(guān)的討論。但在繼續(xù)往下看之前，我們來確認下在術(shù)語方面我們的理解是一致的。如若這是你首次聽到Web性能優(yōu)化一詞，趕快去搞一本SteveSouders的HighPerformanceWebSites和EvenFasterWebSites（均由O’Reilly出版）讀一讀。這些都是Web性能的標準，也是所有Web開發(fā)者都應(yīng)掌握的基礎(chǔ)知識。本章并不打算覆蓋性能的每個細節(jié)。從前面提到的SteveSouders的著作開始，已經(jīng)有大量的資料在講這些東西。但是，本章的目標是對性能（Web性能和Web運行時性能）做個概述，包括一些性能度量的工具。這樣一來，后面章節(jié)我們說到這些概念時，就不會再有歧義和混淆了。當提及網(wǎng)站和Web應(yīng)用性能的時候，我們說的要么是Web性能，要么是運行時性能。我們將Web性能定義為，一個終端用戶從請求一段內(nèi)容開始到這段內(nèi)容顯示在用戶設(shè)備上這段時間的度量值。我們將運行時性能定義為，應(yīng)用在運行時對用戶輸入響應(yīng)能力的一個標示。應(yīng)當意識到，針對你的Web應(yīng)用性能進行量化和標準的制定，是應(yīng)用的一個關(guān)鍵方面。Web性能和運行時性能都有一些指標可以進行實證測度和量化。本章中，我們來看一看這些指標，以及可以用來量化這些指標的工具。注意

性能指標是組織機構(gòu)用來定義一次嘗試是成功或是失敗的可量化目標。通常稱作關(guān)鍵性能指標，縮寫為KPI。本章我們將談到的性能指標類型如下所示。定量指標可以通過實驗進行度量的一種目標（如某個東西的數(shù)量）。定性指標不能通過實驗度量的一種目標（如某個東西的質(zhì)量）。先行指標用于預(yù)測結(jié)果。輸入指標用于度量某個過程中消耗的資源。什么是Web性能？想想每次瀏覽網(wǎng)頁的過程。打開瀏覽器，鍵入URL，然后等待網(wǎng)頁加載。從鍵入URL后按下回車鍵（或是從書簽列表中點擊某個書簽，亦或是點擊頁面中的某個鏈接），到頁面渲染，這之間消耗的時間就是所瀏覽頁面的Web性能。若站點運行正常，這個時間甚至不應(yīng)該被人感受到。Web性能的定量指標數(shù)不勝數(shù)。頁面加載時間。頁面文件大小。HTTP請求數(shù)。頁面渲染時間。Web性能的定性指標總結(jié)起來比較簡單：速度感。在看這些指標之前，先來討論下頁面是如何到達瀏覽器并展現(xiàn)給用戶的。當通過瀏覽器請求一個Web頁面，瀏覽器會創(chuàng)建一個線程去處理這個請求，隨后開始遠程dns查找，遠程dns服務(wù)器會將你輸入的URL對應(yīng)的IP地址返回給瀏覽器。接著，瀏覽器通過與遠程Web服務(wù)端的三次握手來建立一個TCP/IP連接。這個握手由瀏覽器與遠程服務(wù)端之間的SYN、SYN-ACK以及ACK消息組成。TCP連接建立之后，瀏覽器通過連接發(fā)送一個HTTPGET請求到Web服務(wù)端。Web服務(wù)端找到請求的資源，然后在HTTP響應(yīng)中將其返回，狀態(tài)200表示響應(yīng)正常。如果服務(wù)端找不到請求的資源或是解析資源的過程中出錯，抑或是資源被重定向，HTTP響應(yīng)狀態(tài)也會反映出這些情況。這個頁面可以找到狀態(tài)碼的完整列表：\hhttp://bit.ly/stat-codes。下面是最常用的狀態(tài)碼。200表示服務(wù)端成功響應(yīng)。301表示永久重定向。302表示臨時重定向。403表示請求被拒絕。404表示服務(wù)端找不到請求的資源。500表示處理請求時出錯。503表示服務(wù)不可用。504表示網(wǎng)關(guān)超時。圖2-1是TCP事務(wù)的時序圖。圖2-1瀏覽器和Web服務(wù)器的協(xié)商過程要時刻記得，加載一個HTML頁面不只需要一次這個過程，瀏覽器還要為頁面鏈接的每個資源發(fā)起一個HTTP請求——所有的圖片、鏈接的CSS和JavaScript文件以及其他類型的外部資源（但是要注意，只要后續(xù)的HTTP請求連接的是相同的源，瀏覽器就可以重用相應(yīng)的TCP連接）。當瀏覽器收到頁面的HTML后，就開始解析并渲染頁面內(nèi)容。瀏覽器用其渲染引擎來解析和渲染內(nèi)容?，F(xiàn)代的瀏覽器架構(gòu)由幾個關(guān)聯(lián)的模塊組成。UI層這一層為瀏覽器繪制界面。有些元素，如地址欄、刷新按鈕以及用戶界面上（UI）的其他元素是瀏覽器自身的。網(wǎng)絡(luò)層該層處理網(wǎng)絡(luò)連接，承擔的職責有建立TCP連接以及處理HTTP的往返過程。網(wǎng)絡(luò)層處理內(nèi)容下載，然后將內(nèi)容傳遞給渲染引擎。渲染引擎渲染引擎負責將內(nèi)容繪制到顯示器上。瀏覽器制造商會將他們的渲染引擎以及JavaScript引擎打上商標并對外授權(quán)。所以，相對流行的渲染引擎你可能已經(jīng)聽說過了。可以說，最流行的渲染引擎是WebKit，Chrome（Blink是它的譯名）、Safari、Opera以及其他一些瀏覽器中都用到了WebKit。當渲染引擎遇到了JavaScript，會將其傳遞給JavaScript解釋器。JavaScript引擎JavaScript引擎會解析并執(zhí)行JavaScript。如同渲染引擎，瀏覽器制造商給他們的JavaScript打上商標進行授權(quán)，很可能你已經(jīng)聽說過它們了。一個流行的JavaScript引擎是Google的V8，Chrome、Chromium中都用到了它，Node.js就是用它作為引擎的。圖2-2展示了這樣的架構(gòu)。圖2-2分成多個模塊組件的現(xiàn)代瀏覽器架構(gòu)設(shè)想這樣一個用例，用戶在瀏覽器地址欄里鍵入一個URL。UI層將這個請求傳遞到網(wǎng)絡(luò)層，網(wǎng)絡(luò)層隨后建立連接，然后下載初始頁面。當含有HTML塊的數(shù)據(jù)包到達，就被傳遞給渲染引擎。渲染引擎將HTML組裝成原始文本，然后對文本中的字符開始進行詞法分析——或解析。這些字符會與一個規(guī)則集相比較——我們在HTML文檔中指定的文檔類型定義（DTD）——然后轉(zhuǎn)換成基于規(guī)則集的符號。DTD規(guī)定了一系列標簽，這些標簽組成了我們將要使用的語言版本。這些標簽就是由一些被分隔成有意義片段的字符組成。這里有個網(wǎng)絡(luò)層是如何處理并返回下列字符串的例子。

<!DOCTYPEhtml><html><head><metacharset="UTF-8"/>

這串字符會被分割成下面這樣有意義的塊。

<!DOCTYPEhtml>

<html>

<head>

<metacharset="UTF-8"/>

渲染引擎拿到這些符號后將它們轉(zhuǎn)換成文檔對象模型（DOM）元素（DOM是頁面元素的內(nèi)存表現(xiàn)形式，也是JavaScript用于訪問頁面元素的API）。DOM元素被布局成一棵渲染樹，渲染引擎會迭代該樹。首次迭代中，渲染引擎會布局好DOM元素的位置；下一次迭代就將這些元素繪制到屏幕上。如果渲染層在解析和符號化過程中發(fā)現(xiàn)了script標簽，就會暫停下來然后評估下接下來要進行的處理。如果script標簽指向一個外部JavaScript文件，解析過程暫停，隨后網(wǎng)絡(luò)層介入，下載JavaScript文件，然后初始化JavaScript引擎解析，執(zhí)行該文件。如果script標簽包含的是內(nèi)嵌的JavaScript，渲染引擎暫停，JavaScript引擎被初始化，內(nèi)嵌的JavaScript會被解析與執(zhí)行。執(zhí)行完成后，之前暫停的渲染過程會恢復(fù)運行。這是一個很重要的細微差別，影響的不僅僅是DOM元素何時對JavaScript可見（我們的代碼可能會嘗試訪問頁面上的一個元素，但該元素可能還沒有被解析和符號化，更不用提渲染了）和性能。例如，我們是想要阻塞頁面的解析直到下載并運行了那一段代碼嗎，或是如果我們先展示內(nèi)容再去加載頁面的代碼，頁面的功能能否正常？圖2-3描繪了這種工作流程。圖2-3瀏覽器中內(nèi)容加載和渲染的工作流程了解網(wǎng)頁內(nèi)容是怎樣傳遞給瀏覽器對于理解Web性能影響因素是至關(guān)重要的。也要注意到，由于瀏覽器的快速更新，瀏覽器廠商可能會時常對這個工作流進行調(diào)整和優(yōu)化。既然我們已經(jīng)了解了內(nèi)容傳遞和展現(xiàn)的架構(gòu)，那來看一看在這個傳遞工作流上下文中的性能指標。HTTP請求數(shù)時刻記住，當瀏覽器獲取HTML頁面時會創(chuàng)建一個HTTP請求，還會創(chuàng)建更多的HTTP請求來獲取頁面中鏈接的每個資源。根據(jù)網(wǎng)絡(luò)延遲情況，每個HTTP請求都會使總的頁面加載時間增加20～200毫秒（如果考慮可以并行加載資源的瀏覽器，這個數(shù)字會有所不同）。如果只是少量的資源，這些額外的加載時間可以忽略不計，但如果是100個或更多的HTTP請求，將會顯著加大總體Web性能的延遲。減少頁面需要的HTTP請求數(shù)才有意義。開發(fā)者有很多辦法可以做到，如將不同的CSS或JavaScript文件合并成單個文件，將常用的圖片合并成單個的稱之為sprite的圖片文件。頁面負載影響Web性能的因素之一是頁面的總文件大小。總負載包括組成該頁面的HTML、CSS以及JavaScript累計的文件大小。還包括所有的圖片、cookie以及其他嵌在頁面中的媒體。頁面加載時間HTTP請求數(shù)以及總的頁面負載本身只是輸入，但Web性能方面需要關(guān)注的真正KPI是頁面加載時間。頁面加載時間是最明顯的性能指標，也是最容易量化的。簡而言之，它是瀏覽器下載并渲染所有頁面內(nèi)容的時間。以前，度量的是從頁面請求到頁面（窗口加載，windowonload）事件之間消耗的時間。最近，由于開發(fā)者越來越喜歡在頁面完成加載之前就提供好的用戶體驗，這樣度量結(jié)束的時間點就會移動，甚至完全改變。特別是，在有一些用例中，window.onload事件觸發(fā)之后，可以動態(tài)加載內(nèi)容——比如，如果內(nèi)容是延遲加載的，就會出現(xiàn)這種情況——并且有一些用例，在window.onload事件觸發(fā)之前頁面就是可用的，看起來也是完整的（如先加載內(nèi)容，然后再加載廣告）。這些用例會降低依靠window.onload事件追蹤特定頁面加載時間的有效性。有一些選擇可以規(guī)避這個難題。WebPageTest的創(chuàng)建和維護者PatMeenan，在WebPageTest中加入了一種度量方式，稱為速度指標（SpeedIndex），其實質(zhì)上是對頁面內(nèi)容渲染快慢計分。有一些開發(fā)團隊創(chuàng)建了自己自定義的事件，來追蹤他們覺得用戶體驗關(guān)鍵頁面的各個部分是何時加載的。無論你選擇何種方式進行追蹤，頁面的加載（即，你的內(nèi)容已經(jīng)準備好接受用戶交互）都是應(yīng)當監(jiān)控的關(guān)鍵性能指標。2.2追蹤Web性能的工具追蹤Web性能最常用和最有用的工具非瀑布圖莫屬了。瀑布圖非常直觀，可以展示構(gòu)成Web頁面的所有資源、加載這些資源所需的所有HTTP事務(wù)，以及每個HTTP請求消耗的時間。所有這些HTTP請求都展示成條狀，一般y軸是資源的名稱或URL。有的時候，資源的大小和資源的HTTP響應(yīng)狀態(tài)也會展示在y軸。x軸，或顯式或隱式地展示出所消耗的時間。瀑布圖中的條形是按請求發(fā)生的順序繪制的（見圖2-4），條形區(qū)塊的長度表示完成事務(wù)耗時的長短。在瀑布圖的底部有時候也會看到總頁面加載時間以及總HTTP請求數(shù)。瀑布圖的妙處之一是，從條形的排列和重疊我們也可以發(fā)現(xiàn)某些資源的加載是不是阻塞了其他資源的加載。圖2-4Firebug生成的瀑布圖現(xiàn)今，有許多不同的工具可以為我們創(chuàng)建瀑布圖。有些瀏覽器提供了內(nèi)置的工具，比如Firefox中的Firebug，或是Chrome的開發(fā)者工具。也有一些免費、托管的解決方案，比如。我們來看幾個這樣的工具。最簡單的生成瀑布圖的方法是用瀏覽器自帶的工具。這類工具有好多種，但在這一點上或多或少都有些類同，至少在生成瀑布圖的方式上是相似的（有些瀏覽器內(nèi)置工具遠比其他一些工具有用，這一點在我們討論Web運行時性能的時候?qū)吹剑irebug是首個廣為采用的瀏覽器內(nèi)置開發(fā)工具。以Firefox插件形式存在，由JoeHewitt初創(chuàng)，F(xiàn)irebug確立了一項標準，不僅僅可以創(chuàng)建瀑布圖來展示用于加載和渲染一個頁面的網(wǎng)絡(luò)活動，還讓開發(fā)者可以通過控制臺運行任意的JavaScript并展示錯誤，以及調(diào)試與單步調(diào)試瀏覽器中的代碼。如果你還不熟悉Firebug，可以訪問\hhttp://mzl.la/1vDXigg進行安裝。點擊“AddtoFirefox”按鈕，然后按照說明操作即可成功安裝這個附加組件。注意

其他瀏覽器也有可用的Firebug，但一般都是簡化版，沒有提供像在Firefox中那樣完整的功能。圖2-5Firebug下載頁要在Firebug中瀏覽瀑布圖，點擊“網(wǎng)絡(luò)”（Net）選項卡。自Firebug出現(xiàn)以來，瀏覽器一直在發(fā)展，到現(xiàn)在，最新發(fā)布的瀏覽器都內(nèi)置了一些工具，至少可以度量性能的某些方面。Chrome有開發(fā)者工具，InternetExplorer也有自己的開發(fā)者工具，Opera有Dragonfly。要訪問Chrome中的開發(fā)者工具，可以點擊Chrome菜單圖標，選擇“工具-開發(fā)者工具”，如圖2-6所示。圖2-6訪問Chrome中的開發(fā)者工具在InternetExplorer中，選擇“工具-開發(fā)人員工具”。甚至在移動設(shè)備中，現(xiàn)在也有原生應(yīng)用HTTPWatch，可以在其中運行一個瀏覽器，然后展示所有被加載資源的瀑布圖。HTTPWatch可在\hhttp://bit.ly/1rY322j里下載。圖2-7和圖2-8可以讓你對運行中的HTTPWatch有個粗略的認識。圖2-7iOS7上HTTPWatch中的資源加載過程圖2-8iOS7上HTTPWatch中的Web性能信息用瀏覽器內(nèi)置的工具進行調(diào)試是非常不錯的，但是如果你想找一些在持續(xù)集成環(huán)境中能用的自動化解決方案，就需要擴大選擇范圍了，包括平臺解決方案或無外設(shè)的解決方案。提示

第6章我們將詳細講解無外設(shè)的測試以及持續(xù)集成。如前面所提到的，WebPageTest()，是處于領(lǐng)先地位的解決方案之一，由PatMeenan創(chuàng)建并持續(xù)維護。WebPageTest是一種托管解決方案，或者開源工具，你可以安裝然后在你的網(wǎng)絡(luò)上作為一個本地副本運行來測試你的防火墻。下載和托管的代碼庫：\hhttp://bit.ly/1wu4Zdd。WebPageTest是一個Web應(yīng)用，它的輸入是一個URL（以及一堆配置參數(shù)），然后對這個URL運行性能測試。我們能配置的WebPageTest參數(shù)的數(shù)量相當多?？梢詮囊唤M全球范圍的地點中選擇一個來運行你的測試。每個地點都有一或多個瀏覽器供測試選擇。還可以指定連接速度以及要運行的測試數(shù)量。WebPageTest提供了有關(guān)站點整體性能的豐富信息，不僅包括瀑布圖，還有展示給定頁面的內(nèi)容分布圖表（負載的百分之多少由圖片組成，多少由JavaScript組成等），模擬頁面加載到終端用戶的體驗截屏，甚至還有CPU使用率，這個在本章后面會詳講。最重要的是，WebPageTest是完全可編程的。它提供了一個API，可以獲取所有這些信息。圖2-9展示了WebPageTest中生成的瀑布圖。圖2-9WebPageTest生成的一個瀑布圖但在看Web性能指標時，要看的理想值是從你自己的用戶那里得到的真實用戶監(jiān)控（RealUserMonitoring，RUM）結(jié)果。要實現(xiàn)這個目標，需要一個完全可編程的解決方案，萬維網(wǎng)聯(lián)盟W3C已經(jīng)制定了一個標準API，可以用來捕獲和報告瀏覽器內(nèi)的性能數(shù)據(jù)。這是通過性能DOM對象（在所有現(xiàn)代瀏覽器中，這是一個屬于window對象的對象）來實現(xiàn)的。2010年末，W3C創(chuàng)建了一個新的工作組，簡稱為Web性能工作組（WebPerformanceWorkinggroup）。據(jù)其網(wǎng)站描述，這個工作組的任務(wù)是提供方法來度量用戶代理特性和API的各方面應(yīng)用性能。從戰(zhàn)略意義上這意味著該工作組開發(fā)了一個API，可以用JavaScript通過這個API獲取關(guān)鍵性能指標。Google的ArvindJain以及來自微軟的JasonWeber擔任這個工作組的主席。可以通過\hhttp://bit.ly/1t87dJ0訪問其首頁。Web性能工作組已經(jīng)創(chuàng)建了一些新的對象和事件，不僅可以用來量化性能指標，還可以用來優(yōu)化性能。下面是對這些對象和接口高層面的概述。性能對象這個對象對外暴露了多個對象，比如Performancenavigation、PerformanceTiming、MemoryInfo，以及可以記錄亞毫米級高精度時間的能力。頁面可見性API這個接口讓開發(fā)者具備檢測指定頁面是處于展現(xiàn)狀態(tài)還是隱藏狀態(tài)的能力，這樣就可以針對如動畫效果或是輪詢操作中的網(wǎng)絡(luò)資源優(yōu)化內(nèi)存利用率。如果你在JavaScript控制臺鍵入window.performance，將會看到返回的Performance類型的對象，這個對象對外暴露了幾個對象和方法。截至本書寫作時，標準對象集有PerformanceTiming類型的window.performance.timing、PerformanceNavigation類型的window.performance.navigation。Chrome還支持MemoryInfo類型的window.performance.memory。我們將在本章稍后的“Web運行時性能”部分討論MemoryInfo。PerformanceTiming對象對監(jiān)控真實用戶指標來說最為有用。圖2-10所示為控制臺中Performance對象和PerformanceTiming對象的一個截屏。圖2-10控制臺中展示的Performance對象及展開的Performance.Timing對象要時刻記得，真實用戶監(jiān)控的目標是獲取真實用戶的實際性能指標，而不是實驗室中人工測試或通過腳本測試獲得的模擬的性能測試指標。RUM的好處在于能獲取和分析基于實際用戶的真實性能。表2-1列出了PerformanceTiming對象的屬性表2-1PerformanceTiming對象的屬性屬性描述navigationStart在導(dǎo)航開始時采集，要么是瀏覽器開始卸載前一個頁面的時刻（如果有的話），要么是瀏覽器開始獲取頁面內(nèi)容的時刻。這將包含unloadEventStart的時間或fetchStart的時間。想要追蹤端到端的時間，通常會從這個時間開始unloadEventStart/unloadEventEnd在瀏覽器開始卸載以及結(jié)束卸載前一個頁面時采集（如果同域下有前一個頁面需要卸載的話）domainLookupStart/domainLookupEnd在瀏覽器開始以及完成所請求內(nèi)容的DNS查找時采集redirectStart/redirectEnd在瀏覽器開始以及完成任一HTTP重定向時采集connectStart/connectEnd在瀏覽器開始以及完成當前頁面到遠程服務(wù)端的TCP連接建立時采集fetchStart在瀏覽器首次開始所請求資源的緩存時采集requestStart在瀏覽器為所請求的資源發(fā)送HTTP請求時采集responseStart/responseEnd在瀏覽器首次獲取到以及完成接收服務(wù)端響應(yīng)時采集domLoading/domComplete當文檔開始以及結(jié)束加載的時候采集domContentLoadedEventEnd/domContentLoadedEventStart當文檔的DOMContentLoaded事件開始以及結(jié)束加載（瀏覽器完成加載所有的內(nèi)容且運行了頁面上所有包含進來的腳本）時采集domInteractive當頁面的document.readyState屬性變?yōu)?interactive'，引起readystatechange事件觸發(fā)時采集loadEventEnd/loadEventStart在load事件被觸發(fā)的時刻之前采集以及l(fā)oad事件觸發(fā)之后立刻采集圖2-11展示了這些事件的發(fā)生順序。圖2-11性能計時事件可以自己寫一個JavaScript庫嵌到頁面中，然后從用戶那里采集真實的RUM。本質(zhì)上是通過JavaScript采集這些事件，再將它們發(fā)送到服務(wù)端，然后你就可以保存和分析這些指標了。我已經(jīng)創(chuàng)建了這樣一個庫\h/tomjbarker/perfLogger，歡迎使用。2.3Web運行時性能正如我們已經(jīng)討論過的，Web性能跟蹤的是內(nèi)容傳遞到用戶的耗時?，F(xiàn)在來看看Web運行時性能，它跟蹤的是用戶與應(yīng)用交互時應(yīng)用的行為。對于傳統(tǒng)的編譯類型應(yīng)用，運行時性能是有關(guān)內(nèi)存管理、垃圾回收以及線程等各個方面的。這是因為編譯類的應(yīng)用運行在內(nèi)核之上，直接使用系統(tǒng)資源。在客戶端運行Web應(yīng)用與運行編譯類應(yīng)用是大不相同的。這是因為Web應(yīng)用運行在沙盒中，或者，說得更具體點，是運行在瀏覽器中。當它們運行的時候，用的是瀏覽器的資源。而瀏覽器是運行在它事先從內(nèi)核中分配的內(nèi)存資源中的。所以，當我們提到Web運行時性能，我們實際上說的是應(yīng)用是怎樣在客戶端的瀏覽器運行，以及讓瀏覽器在虛擬內(nèi)存中其自身的內(nèi)存里執(zhí)行。圖2-12是Web應(yīng)用在常駐內(nèi)存中的瀏覽器內(nèi)存里運行的情況。圖2-12一個Web應(yīng)用運行在常駐內(nèi)存中的瀏覽器預(yù)分配內(nèi)存中下面是我們需要考慮到的影響Web運行時性能的因素。內(nèi)存管理與垃圾回收首先要看的是，我們有沒有因為太多無用的對象以及創(chuàng)建更多對象時卻仍保留這些無用對象而導(dǎo)致瀏覽器的內(nèi)存分配被阻塞。隨著時間推移，我們是否有什么機制限制JavaScript中的對象創(chuàng)建，或應(yīng)用用的越多越久時，內(nèi)存消耗是否也越多？是否存在內(nèi)存泄露？回收無用對象可能會導(dǎo)致瀏覽器在渲染或播放動畫的時候暫停，容易在用戶體驗上出現(xiàn)鋸齒現(xiàn)象。我們可以通過減少創(chuàng)建的對象數(shù)量以及盡可能重用已有對象來將垃圾回收次數(shù)降到最少。布局我們更新DOM的時候是否引發(fā)了頁面重繪？這一般是由于大范圍的樣式變化，需要渲染引擎重新計算頁面元素的大小與位置。高代價的繪制當用戶滾動頁面時，我們有沒有因為繪制一些區(qū)域而加重瀏覽器的負擔？動畫效果或是更新除了位置、縮放、旋轉(zhuǎn)或透明度之外的任意元素屬性，都將引起渲染引擎重繪對應(yīng)元素并消耗時間。位置、縮放、旋轉(zhuǎn)以及透明度是渲染引擎最后配置的元素屬性，所以，更新這些屬性只需極小的開銷。如果我們在寬度、高度、背景或者其他屬性上使用動畫，渲染引擎就需要重新考慮頁面的布局并且重繪那個元素，這就會在渲染和動畫過程中消耗更多的時間。更糟的是，如果我們引起了父元素的重繪，渲染引擎就需要重繪所有的子元素，嚴重影響運行時性能。同步調(diào)用我們會在等待同步調(diào)用返回的時候阻塞用戶的動作嗎？當在操作復(fù)選框或其他方式接受輸入后更新服務(wù)端的狀態(tài)，再等待確認對應(yīng)的更新操作已完成時，就會經(jīng)常發(fā)生這樣的事情。這會讓頁面感覺起來有些卡頓。CPU占用率瀏覽器渲染頁面和執(zhí)行客戶端代碼需要多大負載？我們要查看的Web運行時性能指標是每秒的幀數(shù)和CPU的占用率。每秒幀數(shù)每秒幀數(shù)（FPS）是動畫師、游戲開發(fā)者以及電影攝影師常用的一種度量單位。它是系統(tǒng)重繪屏幕的速率。按照PaulBakaus的博客帖子“TheIllusionofMotion”(\hhttp://bit.ly/1ou97Zn)中的說法，人類感覺動作平滑、逼真的理想幀率是60FPS。也有一個Web應(yīng)用，叫每秒幀數(shù)(\h)，在瀏覽器中以不同的幀率演示動畫效果?？催@個演示，感受下自己的眼睛對同一個動畫在不同幀率下的反應(yīng)，很有意思。FPS還是瀏覽器的一個重要性能指標，因為其反映出了動畫運行以及窗口滾動的平滑程度。滾動時出現(xiàn)鋸齒（卡頓）已經(jīng)是Web性能問題的一個明顯標志。在GoogleChrome中監(jiān)控FPSGoogle在創(chuàng)建瀏覽器內(nèi)置工具追蹤運行時性能方面在當前已是領(lǐng)頭羊。其內(nèi)置開發(fā)工具中已經(jīng)包含了追蹤FPS的能力。點擊Rendering選項卡，然后選中“ShowFPSmeter”復(fù)選框，就可以看到（見圖2-13）。圖2-13在Chrome開發(fā)者工具中啟用FPSmeter在瀏覽器的右上方會出現(xiàn)一個小的時間數(shù)列圖，顯示了當前FPS以及每秒幀數(shù)的趨勢，如圖2-14所示。使用這個工具，可以顯式地追蹤你的頁面在實際使用過程中的執(zhí)行情況。圖2-14Chrome的FPSmeter，位于Web頁面的右上角雖然FPSmeter是很好的追蹤每秒幀數(shù)的工具，但迄今為止，對在幀率方面體驗下降進行調(diào)試的最有用的工具還是Timeline工具，這個也是Chrome開發(fā)者工具中的一員（見圖2-15）。圖2-15Frames模式下的ChromeTimeline工具用Timeline工具，可以追蹤以及分析瀏覽器運行的時候都干了些什么。它提供了3個操作模式：Frames、Events以及Memory。我們來看一下Frames模式。Frames模式這個模式下，Timeline工具展示了Web應(yīng)用的渲染性能。圖2-15是Frames模式的屏幕布局。在Timeline工具中可以看到兩個不同的窗格。頂部窗格展示的是活動模式（位于左手邊），里面包含了一系列代表幀的豎條。底部窗格是Frames視圖，這里展現(xiàn)的是形似瀑布的水平條狀，標示了某個給定動作在幀里耗費的時長。在左邊有對應(yīng)動作的描述。在Frames視圖的最右邊是一個餅圖，展示了在給定幀中最耗時動作的分類。所包含的動作如下所示。LayoutPaintSetupPaintRecalculateStyleTimerFiredCompositeLayers圖2-15展現(xiàn)出運行JavaScript耗去了將近一半的時間，1.02秒中占了525毫秒。使用Timeline工具，在Frames模式下，通過在Frames視圖下找到最長的條，就能輕易地確定對幀率影響最大的動作。內(nèi)存分析內(nèi)存分析是監(jiān)控我們應(yīng)用所用到的內(nèi)存消耗模式的一種方法。這對檢測內(nèi)存泄露與不會銷毀的對象創(chuàng)建非常有用——JavaScript中，當我們用程序為DOM對象指定事件處理器，而后又忘記將事件處理器移除時尤為常見。更進一步，內(nèi)存分析對優(yōu)化內(nèi)存占用也甚為有用。對象的創(chuàng)建、銷毀與重用應(yīng)當是智能的，要時刻注意，不要讓剖析圖中不斷增加的一系列峰值呈上升趨勢。圖2-16描繪的是JavaScript堆。圖2-16JavaScript堆中的對象雖然瀏覽器內(nèi)置的功能遠比之前強大，但這仍是一個需要擴大和規(guī)范化的領(lǐng)域。迄今為止，Google已經(jīng)做了很多，讓開發(fā)者可以用上瀏覽器內(nèi)置的內(nèi)存管理工具。MemoryInfo對象在Chrome已有的內(nèi)存管理工具中，首先我們要看的是MemoryInfo對象，它存在于Performance對象中。圖2-17的截圖中展示了一個控制臺視圖。圖2-17MemoryInfo對象可以像這樣訪問MemoryInfo對象。

>>performance.memory

MemoryInfo{jsHeapSizeLimit:793000000,usedJSHeapSize:

37300000,totalJSHeapSize:56800000}

表2-2展示出了與MemoryInfo相關(guān)的堆屬性。表2-2MemoryInfo對象屬性對象屬性描述jsHeapSizeLimit堆大小的上限usedJSHeapSize堆中當前所有對象使用的內(nèi)存總量totalJSHeapSize堆的總大小，包括沒有被對象使用的空閑空間這些屬性指出了可用和已用的JavaScript堆。堆是解釋器保存在駐留內(nèi)存中的JavaScript對象集合。在堆中，每個對象都是互有關(guān)聯(lián)的節(jié)點，它們是通過諸如原型鏈或組合對象等屬性連接起來的。瀏覽器中運行的JavaScript是通過對象引用來使用堆中對象的。當要銷毀JavaScript中的一個對象，實際要做的就是銷毀那個對象的引用。當解釋器發(fā)現(xiàn)堆中對象不再有對象引用時，垃圾收集器將會從堆中移除這些對象。用MemoryInfo對象，我們可以獲取用戶群與內(nèi)存消耗相關(guān)的RUM數(shù)據(jù)，也可以在實驗室里追蹤這些指標，好在代碼產(chǎn)品化之前發(fā)現(xiàn)潛在的內(nèi)存問題。Timeline工具除了提供Frames模式來調(diào)試Web應(yīng)用幀率之外，Chrome的Timeline工具還有Memory模式（如圖2-18所示），能可視化地觀察隨時間變化的應(yīng)用內(nèi)存使用情況，并且會顯示文檔、DOM節(jié)點以及留在內(nèi)存中的事件監(jiān)聽器的數(shù)量。圖2-18Memory模式下的ChromeTimeline工具頂部窗口展示的是內(nèi)存剖析圖，最底部的窗口展示了文檔、節(jié)點以及監(jiān)聽器的數(shù)量。注意看，藍色陰影區(qū)顯示了內(nèi)存使用率，可視化地展示了堆內(nèi)存使用量。隨著更多對象被創(chuàng)建，內(nèi)存使用率也一直上升；當這些對象被銷毀并被垃圾收集掉后，內(nèi)存使用率就下降了。可以在Mozilla開發(fā)網(wǎng)\hhttp://mzl.la/1r1RzOG找到一篇有關(guān)內(nèi)存管理的很好的文章。Firefox也開始開放內(nèi)存使用數(shù)據(jù)，可以通過“about:memory”頁面看到，F(xiàn)irefox的實現(xiàn)更多的還是通過靜態(tài)信息頁的方式而不是暴露一組API。正因為如此，它無法容易地插入程序中生成經(jīng)驗數(shù)據(jù)，about:memory頁面更像是為Firefox用戶（盡管是高級用戶）設(shè)計的，而不是作為運行時性能管理的開發(fā)者工具集的一部分。要在Firefox中訪問“about:memory”頁面，在瀏覽器的地址欄里鍵入about:memory。圖2-19展示了這個頁面的樣子。圖2-19Firefox的about:memory頁面如圖2-19所示，可以看到以操作系統(tǒng)級別展示的瀏覽器分配的內(nèi)存，以及瀏覽器打開的每個頁面的堆分配情況。2.4小結(jié)本章探討了Web性能以及Web運行時性能。我們關(guān)注了頁面內(nèi)容是怎樣從Web服務(wù)器到瀏覽器的，以及在傳輸與內(nèi)存渲染過程中存在的潛在瓶頸。還關(guān)注了在運行時表示W(wǎng)eb應(yīng)用執(zhí)行情況的性能指標，這是性能的另一個關(guān)鍵點：不僅要看內(nèi)存?zhèn)鬏數(shù)浇K端用戶有多快，還要看傳輸過去后應(yīng)用的可用性。我們使用了一些工具來量化和追蹤兩種類型的性能。最重要的是，我們對本書剩余部分將要著重講到的概念有了共同的認知。當我們談及諸如降低頁面負載以及HTTP請求數(shù)或者避免頁面重繪這些概念時，可以翻回本章再看上下文。第3章我們來看看如何讓響應(yīng)式成為業(yè)務(wù)方法論以及軟件開發(fā)周期的一部分。

第3章千里之行始于計劃3.1滑坡謬誤的一段經(jīng)歷猶記得我第一次啟動一個期望做成響應(yīng)式的項目。團隊里的每個人都參與進來了：產(chǎn)品經(jīng)理、設(shè)計團隊、工程師。我們一起在探索有關(guān)什么是響應(yīng)式這個問題，我們的集體觀念一遍遍地刷新。對于所有的可能性以及能嘗試一些新的東西我們都激動不已。在那之前，我們維護了一個“m.”類型的站點，單獨要一個開發(fā)人員對其更新，以期與主站保持一致。從工程管理上來講，我們一直希望能把這個開發(fā)人員調(diào)回主團隊，并且我們很享受與設(shè)計團隊的合作。我們已經(jīng)投入幾個星期了，但仍然沒有什么東西可以向管理層演示，甚至連能看到的東西都沒有，盡管如此，我們?nèi)匀粸槲覀兡軗碛羞@極好的學(xué)習經(jīng)驗而感到高興。當然，管理層并不滿意，他們需要有一些具體成果，可以向他們的領(lǐng)導(dǎo)團隊以及同事說說。設(shè)計團隊的部分人從工作組中拆分出去做網(wǎng)站桌面版可能的原型，僅是作為一個能說得出口的東西。當然，原型做完展示之后，就通過了，突然就變成了我們要做的最終設(shè)計，并且要在結(jié)束日期前完成。雖然我們知道應(yīng)該先搞一個移動版的展現(xiàn)，然后以此為基礎(chǔ)進行開發(fā)，我們很快就將所有想法推遲，為后續(xù)迭代構(gòu)建出了一個小的視圖，隨后開始關(guān)注最終產(chǎn)品的視圖創(chuàng)建。僅在一年后，我們就開始構(gòu)想站點在其他設(shè)備上可能的體驗，但這個時候主要的桌面版功能已經(jīng)非常豐富了，所以響應(yīng)式項目進展非常緩慢，并且開始變成一個個人“寵物”項目，花費了幾個月來仿制了一個響應(yīng)式站點模型。這時候已經(jīng)太遲了；這個模型的頁面負載幾乎無異于桌面版，在實際設(shè)備上展示時表現(xiàn)得也很差勁。所以站點依然僅支持桌面版。是不是很像你自己上個項目或當前項目的經(jīng)歷？問題都出在哪里？為此我思考了一陣：我應(yīng)該從中吸取什么樣的教訓(xùn)，好在未來的項目上不再翻跟頭？從高的層面看，是我們自己搞死了自己。從團隊內(nèi)部來看，整個項目看起來像是有趣的探索與協(xié)作，摸清對我們來說全新的邊界。從團隊外部來看，看著像是沒有計劃，沒有目標——也的確如此。從長遠看，我們計劃的缺乏，削弱了管理層對團隊的信任，開了干預(yù)團隊的先例，并給我們定了粗略的最終目標。本章，我將概述下怎樣為團隊制定一個計劃，好快速產(chǎn)出可交付產(chǎn)品，以成為領(lǐng)導(dǎo)層的談話要點，而同時仍然能堅持構(gòu)建響應(yīng)式、高性能站點的目標。3.2項目計劃響應(yīng)式項目與任何其他項目沒有任何差別，因為它們都會受益于項目計劃。從程序或項目管理學(xué)來講，有好幾種類型的項目計劃，視方法、組織、商業(yè)部門以及你所問的人（其他因素）而定，但一般來說，項目計劃包含下面幾個步驟。1．評估/總結(jié)整個任務(wù)。2．確定粗略的目標與時間表。3．列出資源和風險。4．列出衡量成功的關(guān)鍵性能指標（KPI）。響應(yīng)式項目唯一的不同在于，能證明各種設(shè)備體驗的需求在上述的每個步驟中都應(yīng)當是明確的。我們來更詳細地看看每個步驟。評估和總結(jié)整個任務(wù)評估整個任務(wù)涉及收集需求以及確定項目的內(nèi)容策略。這可能意味著需要與干系人或產(chǎn)品經(jīng)理進行一次討論，以確定站點的理念與愿景，以及想要實現(xiàn)的用例。這可能也意味著要與他們一起來做大量的用戶測試與競爭分析來確定內(nèi)容策略。評估任務(wù)的有一部分是去回答一定的相關(guān)問題。比如，是否要為10英尺的屏幕提供視覺體驗？或是否準備提供純文本內(nèi)容？正要做的是在為電視產(chǎn)品實現(xiàn)同等的體驗？或是為鎖定的一群用戶實現(xiàn)一個局域網(wǎng)能用的站點？你的項目真的需要響應(yīng)式？若干年前，我做過一個Web應(yīng)用項目，該應(yīng)用旨在協(xié)助施工經(jīng)理識別出顯而易見的風險，譬如沒有被圍網(wǎng)圍起來的污泥。出于這個用例的性質(zhì)，這個項目永遠也不需要一個桌面版，所以，我們做了一個手機版，桌面訪問時就隨它按比例縮放（當時還沒有平板電腦）。這個用例以及整個項目愿景應(yīng)該可以清楚地回答這個問題了：這個項目我的目標視口是什么？這些視口應(yīng)該是你需求的一部分，并且隨著項目計劃中每個步驟的進行，我們還將重新提到它們，但再一次說一下，第一步是為了確認哪些是我們明確的目標。圖3-1是潛在目標視口的幾個代表，以及它們相對大小的差異。圖3-1幾個視口的代表，從智能手機、平板、筆記本到高清電視，其中的差異不僅僅有尺寸，還有方向除了尺寸方面的差異，還需要關(guān)注每個設(shè)備的觀看距離、電池壽命以及網(wǎng)速和可靠性。研究顯示，從用戶面部到智能手機屏幕的平均距離僅為12.6英寸；而筆記本為25英寸，電視為96英寸（見圖3-2）。圖3-2不同設(shè)備的平均觀看距離觀看距離的變化意味著很多地方的不同，包括圖片和字體大小，每個都要請求不同的CSS規(guī)則，還可能為不同的設(shè)備請求不同的圖片。在評估整個任務(wù)規(guī)模時需要考慮到這些。不同設(shè)備間的平均網(wǎng)速差距也甚大。據(jù)Akamai在2013年發(fā)布的報告“StateoftheInternet”(\hhttp://bit.ly/1tDGysM)：在美國，平均寬帶連接速度為11.6Mbit/s，而平均手機連接速度為5.3Mbit/s，見圖3-3。圖3-32013年美國平均連接速度連接速度上的差異凸顯出了一個問題，要多久才能傳遞、渲染內(nèi)容到設(shè)備上。這意味著，你需要相應(yīng)地設(shè)計你的功能集以及運營預(yù)算。建立粗略的目標與時間表莫要空談計劃。在確定了目標視口之后，就應(yīng)該做競爭分析了。用心去調(diào)查有相似功能的內(nèi)部和外部應(yīng)用，并基于競爭分析給出每個設(shè)備上的性能基準。為當前的性能現(xiàn)狀做個水平劃分，然后明智地決定你的應(yīng)用該處在哪個水平上。圖3-4是手機版頁面加載時間一個假設(shè)的競爭分析的結(jié)果。在這個假設(shè)的數(shù)據(jù)集中，我們可以看到，主要的內(nèi)部和外部競爭者都落在500毫秒到1秒的范圍里。這對于我們的應(yīng)用是否是一個可接受的范圍，或者我們是否需要做性能的領(lǐng)頭羊，以500毫秒以內(nèi)作為目標范圍？在這個范圍內(nèi)的站點都有一些什么樣的功能，我們可以減小功能集來達到這么低的頁面加載時間嗎？圖3-4假設(shè)的競爭者頁面加載時間結(jié)果的直方圖在圖3-4中，極端值已經(jīng)高達3.5秒。需要做決定的是你想將自己的應(yīng)用放在這個性能基線的什么位置。這就是你的性能服務(wù)水平協(xié)議。確定一個性能服務(wù)水平協(xié)議服務(wù)水平協(xié)議（SLA）是服務(wù)提供者的一個質(zhì)量保證，通常保證的方面有響應(yīng)時間、可服務(wù)時間以及錯誤率。作為一個網(wǎng)站的所有者，站點就是我們提供的一項服務(wù)，我們有必要向我們的終端用戶以及內(nèi)部干系人提供有關(guān)網(wǎng)站性能的一個SLA。你的性能SLA應(yīng)當明確所表述內(nèi)容以及其度量方式。一個好的性能SLA內(nèi)容可能是像下面這個樣子。在小屏幕上，我們網(wǎng)站的頁面加載時間95%的時候保持在1秒或更低，在大屏上，至多3秒，以上數(shù)據(jù)通過綜合測試得出。一旦確定了性能SLA，這將影響不同版本上所提供的功能以及這些功能的展示形式。你也應(yīng)該將這個SLA寫進文檔，讓團隊和干系人知曉。確定粗略的里程碑與時間表既然已經(jīng)理解了所做產(chǎn)品的需求以及性能層面真正包含的內(nèi)容，就可以開始具體實現(xiàn)了。這就像用戶需求層次樹結(jié)構(gòu)一樣豐富而復(fù)雜，也可以像一張T恤尺碼表一樣高級。但是，所有的設(shè)備/分辨率/特定視口都應(yīng)該明確寫下來，并作為整個時間表的指標，如圖3-5所示。圖3-5一個概略計劃樣本，每種分辨率與目標設(shè)備都設(shè)有里程碑要清楚，圖3-5中所列出的高層面的需求（創(chuàng)建1024×768的視圖，創(chuàng)建2560×1440的視圖）并不能就認為它們是不同的頁面——這只是一個將要完成的指標集（如果你樂意，也可以稱為目標）；對于該如何實現(xiàn)，則沒有體現(xiàn)。注意

RaduChelariu在SmashingMagazine發(fā)表一篇非常好的文章，簡要地列出了一堆設(shè)備的分辨率，參見\hhttp://bit.ly/zqcgUb.還有一點：高層面的用戶需求定義了基礎(chǔ)架構(gòu)的方案以及監(jiān)控我們SLA的過程，既然我們已經(jīng)承諾遵守性能SLA，就應(yīng)當將這些高層面的用戶需求包含進來。讓我們把這些需要保障的點加到已有列表中吧，見圖3-6。圖3-6高層面的需求列表，加入了跟蹤SLA相關(guān)的內(nèi)容列出依賴和風險當我們有了高層面的需求描述，對每個需求都做了時間估算之后，就可以開始列出每個需求的風險與依賴。這些應(yīng)當都是非常簡單且是常識性的東西，但是，你仍然需要將它們列出來以說明完成這個需求需要的措施，并向干系人表明這些措施是已經(jīng)被采用了的。圖3-7是上個例子的延續(xù)，這次列出了依賴與風險。圖3-7整體項目需求計劃中的依賴與風險圖3-7解釋了我們是如何看到這些依賴里包含了設(shè)計或線框圖，環(huán)境的準備，以及定義好的性能SLA。通過明確地列出這些內(nèi)容，我們就能看出哪些需求需要建立在其他需求之上。這也讓我們避開這些需求來創(chuàng)建一個有意義的時間表成為可能。制定時間表既然我們已經(jīng)知道了完成該項任務(wù)將要涉及的步驟，就可以建一個粗略的時間表了。通過為每個任務(wù)使用高層次的T恤尺寸表示法，我們就能對它們進行有意義地分組，并把它們橫放到時間表中。對于這個例子，假定我們是兩周一個迭代。假設(shè)我們熟知我們團隊的開發(fā)速度，就能夠粗略構(gòu)想出每個迭代應(yīng)當做的東西。我們可以將所有的研究與準備工作放到單獨的一個迭代中。然后將若干個需求放到另一個迭代，剩下的放到第三個迭代。通過下面的方法，我們可以看到這個任務(wù)可能至少是一個六周的項目，如圖3-8所示。圖3-8高層面需求的粗略時間安排這里的重點是，這些都是非常粗的時間表。其實，說得文雅點，就是瞎猜或粗略估計的。只要你讓干系人清楚地知道，當有更多信息的時候，這個時間表會經(jīng)常變化，且在有新進展時會及時傳達，這樣你就會做得很好。衡量成功的關(guān)鍵性能指標（KPI）現(xiàn)在我們已經(jīng)對這個任務(wù)做了評估，創(chuàng)建了粗略的時間表，且列出了達成這個時間表的所涉及的依賴。接下來，我們需要確保已經(jīng)清晰地定義了成功的標準。實際上，衡量這個項目成功與否的關(guān)鍵性能指標在我們產(chǎn)品或業(yè)務(wù)團隊找我們完成這個任務(wù)之前就已經(jīng)存在了，但是，我們需要與他們一起確認清楚，首先，這些KPI對整個團隊都是明確的，其次，我們針對這個任務(wù)的解決方案與預(yù)期標準是一致的。如果這時KPI還沒定下來，我們就需要與干系人一起把它確定掉。不然我們怎么知道項目是否成功了，又怎么在迭代中進行優(yōu)化呢？遵守性能SLA現(xiàn)在我們已經(jīng)有了一個要做的事情的計劃，確定了階段目標，達成每個目標時會保持溝通。每個版本我們都有一個性能SLA，現(xiàn)在我們可以開始做事了。但在開發(fā)過程中，務(wù)必遵守我們的性能SLA。需要確保性能測試是持續(xù)集成工作流程的一部分，當背離SLA時，需要警覺。第6章中我們會著重講怎么去做。當評估新的功能時，用你的SLA作為一個討論點。這些新功能是否會影響性能？業(yè)務(wù)規(guī)則中的細微改動是否會為產(chǎn)品帶來更高的性能？3.3小結(jié)本章并沒有打算講如何管理一個項目，而是在于探討一種將響應(yīng)式和性能整合到一個項目計劃中的方式。有了快速響應(yīng)的項目計劃，我們可以向干系人傳達有意義的階段目標，而且不需要犧牲任何一種設(shè)備體驗，因為這原本就是我們最終產(chǎn)品的一個部分。

第4章響應(yīng)式服務(wù)端實現(xiàn)本章討論的核心，也是全書的核心，就是不贊同把響應(yīng)式Web設(shè)計作為一個前端獨有的技術(shù)。因為如果我們這樣認為了，它就會限制我們的思考廣度，我們能做什么？我們可以用什么工具？但是作為Web開發(fā)者，我們必須精益求精，必須有能力把控Web全棧中任何一個細節(jié)。本章將討論我們?nèi)绾位诤蠖藖硭伎既绾胃玫貙崿F(xiàn)響應(yīng)式。4.1Web棧在我們開始本章內(nèi)容之前，我必須先給Web棧一個定義：Web棧是一系列棧的集合。而在討論Web棧之前，讓我們先從網(wǎng)絡(luò)棧開始。網(wǎng)絡(luò)棧網(wǎng)絡(luò)棧是由不同網(wǎng)絡(luò)系統(tǒng)相互通信的一系列協(xié)議的統(tǒng)稱，它由下面一些層構(gòu)成。數(shù)據(jù)鏈路層數(shù)據(jù)鏈路層對應(yīng)的是硬件連接到網(wǎng)絡(luò)的標準方式。對我們而言，通常是以以太網(wǎng)的形式，具體是支持IEEE802.3標準的物理互聯(lián)設(shè)備(\hhttp://bit.ly/ethernet-standards)；或者也可以通過WiFi，具體是支持802.11標準的無線互聯(lián)設(shè)備(\hhttp://bit.ly/1p8UW6P)。網(wǎng)絡(luò)層網(wǎng)絡(luò)層對應(yīng)的是網(wǎng)絡(luò)中不同網(wǎng)絡(luò)節(jié)點之間相互識別和通信的標準，具體是IP協(xié)議或者互聯(lián)網(wǎng)協(xié)議。它是通過IP地址在網(wǎng)絡(luò)中識別網(wǎng)絡(luò)節(jié)點，并且在主機之間通過數(shù)據(jù)包的形式傳遞數(shù)據(jù)。IETFRFC749主要記錄了標準的互聯(lián)網(wǎng)協(xié)議，你可以在\hhttp://bit.ly/11j3ouQ上閱讀到詳細信息。傳輸層傳輸層通常相當于TCP，全稱是TransmissionControlProtocol，也就是傳輸控制協(xié)議。在IETFRFC793(\h/rfc/rfc793.txt)中定義。TCP是用來在主機間建立鏈接的協(xié)議。IP協(xié)議負責將數(shù)據(jù)以數(shù)據(jù)包的方式進行傳輸，而TCP將數(shù)據(jù)包分成多個段，并且為每個段創(chuàng)建含有目標IP地址的header，重新組裝并且對接受到的這些網(wǎng)絡(luò)傳輸數(shù)據(jù)進行校驗。應(yīng)用層應(yīng)用層是這一系列協(xié)議的最上層，它對應(yīng)的是像HTTP這樣的協(xié)議，HTTP也稱為超文本傳輸協(xié)議。HTTP的標準是IETFRFC2616，你也可以在\h/html/rfc2616上看到詳細信息。HTTP是一種Web語言，它主要是由request（請求）/response（響應(yīng)）兩個動作組成。把這些棧組織起來就得到了數(shù)據(jù)在Internet中發(fā)送和接收的整個流程步驟了，如圖4-1所示。圖4-1用戶通過TCP/IP棧發(fā)送一個請求，然后這個請求同樣通過TCP/IP棧和遠端服務(wù)器上的Web應(yīng)用進行通信應(yīng)用層了解所有的底層知識是非常重要的，但是對Web開發(fā)者來說，最主要的也就是我們每天都會面對的，并且可以通過編碼方式控制的一層，就是應(yīng)用層，也就是HTTP協(xié)議。第2章向我們展示了一個HTTP傳輸在TCP的連接中都要經(jīng)歷哪些步驟。一般來說由兩個部分組成：從客戶端發(fā)送一個請求，然后從服務(wù)端返回一個響應(yīng)。很容易理解，對吧？不過深入了解HTTP內(nèi)容對我們的工作大有裨益，現(xiàn)在我們來看看一個請求和一個響應(yīng)的細節(jié)性問題，更深入地探討它們的內(nèi)部機制。HTTP請求一個HTTP請求由兩個部分組成：請求正文和一系列請求header。其中，請求正文包括請求的HTTP方法或者動作，以及請求遠程資源的URI。更簡單來說，它表明了當前要執(zhí)行的動作（獲取文件，發(fā)送文件或者獲取一個文件的信息）以及這個動作在哪執(zhí)行（文件或者資源的地址路徑），下面就是