一：web前端頁面優(yōu)化：
1.web頁面的具體是什么？前身？
web前端頁面作為呈現(xiàn)給用戶看的頁面，也就是瀏覽器可以解析出資源的通過一定程序而出現(xiàn)的頁面，對于可以開發(fā)人員，很好懂：就是**HTML（Hyper Text Markup Language【超文本標(biāo)記語言】）+CSS（Cascading Style Sheets【表現(xiàn)HTML（標(biāo)準(zhǔn)通用標(biāo)記語言的一個應(yīng)用）或XML（標(biāo)準(zhǔn)通用標(biāo)記語言的一個子集）等文件樣式的計算機(jī)語言】）+JS（javascript【一種由Netscape的LiveScript發(fā)展而來的腳本語言,主要目的是為了解決服務(wù)器終端語言遺留的速度問題】）**。
Web前端作為開發(fā)團(tuán)隊中不可或缺的一部分，需要按照相關(guān)規(guī)定進(jìn)行合理編寫（一部分不良習(xí)慣可能給自己和他人造成不必要的麻煩）。不同公司不同團(tuán)隊具有不同的規(guī)范和文檔
A.**基本原則**
符合web標(biāo)準(zhǔn)（UTF-8，HTML5），語義化html（HTML5新增要求，減少div和span等無特定語義的標(biāo)簽使用），結(jié)構(gòu)表現(xiàn)行為分離（HTML-CSS-JS代碼分離，不同行為代碼高內(nèi)聚低耦合），兼容性優(yōu)良（早期版本瀏覽器兼容，移動端和PC端設(shè)備兼容）.頁面性能方面（減少請求次數(shù)，例如使用精靈圖和sass語法），代碼要求簡潔明了有序，盡可能的減小服務(wù)器負(fù)載，保證最快的解析速度（減小repaint和reflow）
B.**文件命名規(guī)范**
1、**html，css，js，lib，images文件均存放至項目的目錄中**。如果使用相關(guān)前端框架，根據(jù)框架的文件格式進(jìn)行合理布局。
2、所有文件夾及文件使用英文命名（避免使用中文路徑）。
3、**html文件**：入口文件使用index.html。如果有對應(yīng)的設(shè)計組設(shè)計原稿，需要將對應(yīng)的設(shè)計稿和html文件命名一致并合理存放。
4、**css文件命名**：后綴.css。通用initial.css，初始化base.css，首頁index.css，其他頁面按照對應(yīng)的html命名。
5、**Js文件命名**：英文命名，后綴.js.通用common.js，初始化base.js。 其他頁面按照對應(yīng)的html命名。
C.**HTML規(guī)范**
1、**文檔類型聲明及編碼：統(tǒng)一為html5聲明類型**。書寫時利用IDE實現(xiàn)層次分明的縮進(jìn)（默認(rèn)縮進(jìn)4空格）。
2、**非特殊情況下CSS文件放在body部分<meta>標(biāo)簽后**。非特殊情況下大部分JS文件放在<body>標(biāo)簽尾部（如果需要界面未加載前執(zhí)行的代碼可以放在head標(biāo)簽后）避免行內(nèi)JS和CSS代碼。
3、**所有編碼需要遵循h(huán)tml（XML）標(biāo)準(zhǔn)**，標(biāo)簽&屬性&屬性命名必須由小寫字母及下劃線數(shù)字組成，且所有標(biāo)簽必須閉合，包括br()，hr()等。屬性值用雙引號。
4、**引入JS庫文件，文件名須包含庫名稱及版本號及是否為壓縮版**，比如jquery-1.4.1.min.js。引入插件，文件名格式為庫名稱+插件名稱，比如jQuery.bootstrap.js。
5、**書寫頁面過程中，請考慮向后擴(kuò)展性**。class&id參見css書寫規(guī)范.
6、**需要為html元素添加自定義屬性**的時候，首先要考慮下有沒有默認(rèn)的已有的合適標(biāo)簽去設(shè)置，如果沒有，可以使用須以"data-"為前綴來添加自定義屬性，避免使用"data："等其他命名方式。
7、**語義化html**，如標(biāo)題根據(jù)重要性用h*(同一頁面只能有一個h1)，段落標(biāo)記用p，列表用ul，內(nèi)聯(lián)元素中不可嵌套塊級元素。
8、**盡可能減少div多層級嵌套**。
9、**書寫鏈接地址時，必須避免重定向，**例如：href="http：//myVue.com/"，即須在URL地址后面加上“/”；
10、**在頁面中盡量避免使用style屬性**，即style="…"。
11、**必須為含有描述性表單元素**(input，textarea)添加label，如姓名：須寫成：姓名：
12、**能以背景形式呈現(xiàn)的圖片，盡量寫入css樣式中**。
13、**重要圖片必須加上alt屬性**。給重要的元素和截斷的元素加上title。
14、**給區(qū)塊代碼及重要功能(比如循環(huán))加上注釋**，方便后臺添加功能。
15、**特殊符號使用**：盡可能使用代碼替代：比如<(<)&>(>)&空格()&?(?)等等。
D.**CSS規(guī)范**
1、**編碼規(guī)范為utf-8。**
2、**協(xié)作開發(fā)及分工**：i會根據(jù)各個模塊，同時根據(jù)頁面相似程序，事先寫**體框架文件，分配給前端人員實現(xiàn)內(nèi)部結(jié)構(gòu)&表現(xiàn)&行為。共用css文件base.css由i書寫，協(xié)作開發(fā)過程中，每個頁面請務(wù)必都要引入，此文件包含reset及頭部底部樣式，此文件不可隨意修改。
3、**class與id的使用**：id是唯一的并是父級的，class是可以重復(fù)的并是子級的，所以id僅使用在大的模塊上，class可用在重復(fù)使用率高及子級中。id原則上都是由我分發(fā)框架文件時命名的，為JS預(yù)留鉤子的除外。
4、**為JS預(yù)留鉤子的命名**，請以js_起始，比如：js_hide，js_show。
5、**class與id命名**：大的框架命名比如header/footer/wrapper/left/right之類的在2中由i統(tǒng)一命名.其他樣式名稱由小寫英文&數(shù)字&來組合命名，如i_comment，fontred，width200。避免使用中文拼音，盡量使用簡易的單詞組合?？傊?，命名要語義化，簡明化
6、**規(guī)避class與id命名**(此條重要，若有不明白請及時與i溝通)：a）通過從屬寫法規(guī)避，示例見d。b）取父級元素id/class命名部分命名，示例見d。c）重復(fù)使用率高的命名，請以自己代號加下劃線起始，比如i_clear。d）a，b兩條，適用于在2中已建好框架的頁面，如，要在2中已建好框架的頁面代碼中加入新的div元素，按a命名法則：...，樣式寫法：#mainnav.firstnav{.......}按b命名法則：...，樣式寫法：.main_firstnav{.......}
7、**css屬性書寫順序**，建議遵循：布局定位屬性-->自身屬性-->文本屬性-->其他屬性.此條可根據(jù)自身習(xí)慣書寫，但盡量保證同類屬性寫在一起.屬性列舉：布局定位屬性主要包括：display&list-style&position（相應(yīng)的top，right，bottom，left）＆float&clear＆visibility＆overflow；
**
**自身屬性主要包括：****width&height&margin&padding&border&background。
**文本屬性主要包括**：color&font&text-decoration&text-align&vertical-align&white-space&
其他&content。
8、**書寫代碼前，提高樣式重復(fù)使用率。**
9、**充分利用html自身屬性及樣式繼承原理減少代碼量**，例如：
即可實現(xiàn)日期居右顯示
10、**樣式表中中文字體名**，請務(wù)必轉(zhuǎn)碼成unicode碼，以避免編碼錯誤時亂碼。
11、**背景圖片請盡可能使用精靈圖技術(shù)**，減小http請求，考慮到多人協(xié)作開發(fā)，精靈圖按模塊制作。
12、**使用table標(biāo)簽時**(盡量避免使用table標(biāo)簽)，請不要用width/height/cellspacing/cellpadding等table屬性直接定義表現(xiàn)，應(yīng)盡可能的利用table自身私有屬性分離結(jié)構(gòu)與表現(xiàn)，如thead，tr，th，td，tbody，tfoot，colgroup，scope。(cellspaing及cellpadding的css控制方法：table{border：0。margin：0。border-collapse：collapse。}tableth，tabletd{padding：0。}，base.css文件中我會初始化表格樣式)
13、**杜絕使用兼容ie8。**
14、**用png圖片做圖片時，要求圖片格式為png-8格式**，若png-8實在影響圖片質(zhì)量或其中有半透明效果，請為ie6單獨定義背景：_background：none。_filter：progid：DXImageTransform.Microsoft.AlphaImageLoader(sizingMethod=crop，src=’img/bg.png’)。
15、**避免兼容性屬性的使用**，比如text-shadow||css3的相關(guān)屬性。
16、**減少使用影響性能的屬性，**比如position：absolute||float。
17、**必須為大區(qū)塊樣式添加注釋，小區(qū)塊適量注釋。**
18、**代碼縮進(jìn)與格式**：建議單行書寫，可根據(jù)自身習(xí)慣，后期優(yōu)化會統(tǒng)一處理。
E. **JS書寫規(guī)范**
1、**文件編碼統(tǒng)一為utf-8，**書寫過程過，每行代碼結(jié)束必須有分號。原則上所有功能均根據(jù)XXX項目需求原生開發(fā)，以避免網(wǎng)上down下來的代碼造成的代碼污染(沉冗代碼||與現(xiàn)有代碼沖突||...)。
2、**庫引入**：原則上僅引入jQuery庫，若需引入第三方庫，須與團(tuán)隊其他人員討論決定。
3、**變量命名**：駝峰式命名.原生JS變量要求是純英文字母，首字母須小寫，如myVue。jQuery變量要求首字符為'_'，其他與原生JS規(guī)則相同，如：_myVue。另，要求變量集中聲明，避免全局變量.
4、**類命名**：首字母大寫，駝峰式命名.如MyVue。
5、**函數(shù)命名**：首字母小寫駝峰式命名.如myVue()。
6、**命名語義化**，盡可能利用英文單詞或其縮寫。
7、**盡量避免使用存在兼容性及消耗資源的方法或?qū)傩?*，比如eval_r()&innerText。
8、**后期優(yōu)化中，JS非注釋類中文字符須轉(zhuǎn)換成unicode編碼使用，以避免編碼錯誤時亂碼顯示。**
9、**代碼結(jié)構(gòu)明了，加適量注釋.提高函數(shù)重用率。**
10、**注重與html分離，減小reflow，注重瀏覽器性能**.
F.**圖片規(guī)范**
1、**所有頁面元素類圖片均放入img文件夾**，測試用圖片放于demo文件夾。
2、**圖片格式gif/png/jpg。提倡使用webp文件格式**，使用軟件進(jìn)行圖片壓縮。
3、**命名全部用小寫英文字母||數(shù)字||_的組合，**其中不得包含漢字||空格||特殊字符；盡量用易懂的詞匯，便于團(tuán)隊其他成員理解。另，命名分頭尾兩部分，用下劃線隔開，比如ad_left01.gif||btn_submit.gif。
4、**在保證視覺效果的情況下選擇最小的圖片格式與圖片質(zhì)量，以減少加載時間**。
5、**盡量避免使用半透明的png圖片**(若使用，請參考css規(guī)范相關(guān)說明)。
6、**運用css精靈圖技術(shù)集中小的背景圖或圖標(biāo)**，減小頁面http請求，但注意，請務(wù)必在對應(yīng)的精靈圖psd源圖中劃參考線，并保存至img目錄下
G.**測試規(guī)范**
開發(fā)及測試工具約定建議使用Aptana-Sublime-Vim-WebStrom，亦可根據(jù)自己喜好選擇，但須遵循如下原則：
1、**不可利用IDE的視圖模式'畫'代碼。**
2、**不可利用IDE生成相關(guān)功能代碼。**
3、**編碼必須格式化，比如縮進(jìn)**。測試工具：前期開發(fā)僅測試FireFox&IE6&IE7&IE8，后期優(yōu)化時加入Opera&Chrome&Safari。建議測試順序：FireFox-->IE-->Opera-->Chrome-->Safari。
2.**為什么要做性能優(yōu)化？**
網(wǎng)站前端的用戶體驗決定了用戶是否想要去使用網(wǎng)站的功能，而網(wǎng)站的功能決定了用戶是否會一票否決前端體驗。 不僅僅如此，如果前端優(yōu)化得好，他不僅可以為企業(yè)節(jié)約成本，他還能給用戶帶來更多的用戶，因為增強(qiáng)的用戶體驗?？偨Y(jié)成三點就是：
(1)、**加快頁面展示和運行速度**
(2)、**節(jié)約服務(wù)器帶寬流量**
(3)、**減少服務(wù)器壓力**
**3.Web頁面的性能**
我們每天都會瀏覽很多的Web頁面，使用很多基于Web的應(yīng)用。這些站點看起來既不一樣，用途也都各有不同，有在線視頻，Social Media，新聞，郵件客戶端，在線存儲，甚至圖形編輯，地理信息系統(tǒng)等等。雖然有著各種各樣的不同，但是相同的是，他們背后的工作原理都是一樣的：
**用戶輸入網(wǎng)址**
**瀏覽器加載HTML/CSS/JS，圖片資源等**
**
**瀏覽器將結(jié)果繪制成圖形****
**用戶通過鼠標(biāo)，鍵盤等與頁面交互**
**寬帶網(wǎng)速**
**DNS服務(wù)器的響應(yīng)速度**
**服務(wù)器的處理能力**
**
**數(shù)據(jù)庫性能****
**路由轉(zhuǎn)發(fā)**
**瀏覽器處理能力**
早在**2006年，雅虎就發(fā)布了提升站點性能的指南，Google也發(fā)布了類似的指南。而且有很多工具可以和瀏覽器一起工作，對你的Web頁面的加載速度進(jìn)行評估：分析頁面中資源的數(shù)量，傳輸是否采用了壓縮，JS、CSS是否進(jìn)行了精簡，有沒有合理的使用緩存等等**。
**4.什么時候做性能優(yōu)化最合適？**
一般來說，遵循避免過早優(yōu)化的原則，因為網(wǎng)站再發(fā)過程中的成本相對來說還是比較高的，web開發(fā)工程師、ui、產(chǎn)品、運維、后臺服務(wù)等等，所以第一我們要保證基本功能完成，再考慮優(yōu)化。第二在沒有找到性能瓶頸之前，不要優(yōu)化
**5.哪方面需要做性能優(yōu)化？**
在這之前，我們先分析一個頁面從發(fā)起請求到展示到用戶大概流程
（1）、**DNS 查詢**
（2）、**發(fā)送 HTTP 請求**
（3）、**等待服務(wù)器響應(yīng)**
（4）、**下載服務(wù)器響應(yīng)內(nèi)容**
（5）、**解析 HTML、CSS、JS**
（6）、**渲染 HTML、CSS、JS 和圖片**
（7）、**響應(yīng)用戶事件**
了解了這幾個過程，大家應(yīng)該知道如何優(yōu)化了吧，對！就是對癥下藥。
***6.優(yōu)化的35條軍規(guī)*：**
**1.盡量減少HTTP請求數(shù)：**
性能黃金法則：只有10%-20%的最終用戶相應(yīng)時間花在接收請求的HTML文檔上,剩下的80%-90%時間花在HTML文檔所引用的所有組件（圖片,script,css，flash等等）進(jìn)行的http請求上，減少組件數(shù)必然能夠減少頁面提交的HTTP請求數(shù)。這是讓頁面更快的關(guān)鍵。
減少頁面組件數(shù)的一種方式是簡化頁面設(shè)計。但有沒有一種方法可以在構(gòu)建復(fù)雜的頁面同時加快響應(yīng)時間呢？嗯，確實有魚和熊掌兼得的辦法。
**合并文件**是通過把所有腳本放在一個文件中的方式來減少請求數(shù)的，當(dāng)然，也可以合并所有的CSS。如果各個頁面的腳本和樣式不一樣的話，合并文件就是一項比較麻煩的工作了，但把這個作為站點發(fā)布過程的一部分確實可以提高響應(yīng)時間。
**
**CSS Sprites****是減少圖片請求數(shù)量的首選方式。把背景圖片都整合到一張圖片中，然后用CSS的background-image和background-position屬性來定位要顯示的部分。
**圖像映射**可以把多張圖片合并成單張圖片，總大小是一樣的，但減少了請求數(shù)并加速了頁面加載。圖片映射只有在圖像在頁面中連續(xù)的時候才有用，比如導(dǎo)航條。給image map設(shè)置坐標(biāo)的過程既無聊又容易出錯，用image map來做導(dǎo)航也不容易，所以不推薦用這種方式。
**行內(nèi)圖片**（Base64編碼）用data: URL模式來把圖片嵌入頁面。這樣會增加HTML文件的大小，把行內(nèi)圖片放在（緩存的）樣式表中是個好辦法，而且成功避免了頁面變“重”。但目前主流瀏覽器并不能很好地支持行內(nèi)圖片。
**緩存的力量是強(qiáng)大的**，恰當(dāng)?shù)木彺嬖O(shè)置可以大大的減少 HTTP請求。假設(shè)某網(wǎng)站首頁，當(dāng)瀏覽器沒有緩存的時候訪問一共會發(fā)出 78個請求，共 600多 K數(shù)據(jù)，而當(dāng)?shù)诙卧L問即瀏覽器已緩存之后訪問則僅有 10個請求，共 20多 K數(shù)據(jù)。 (這里需要說明的是，如果直接 F5刷新頁面的話效果是不一樣的，這種情況下請求數(shù)還是一樣，不過被緩存資源的請求服務(wù)器是 304響應(yīng)，只有 Header沒有Body ，可以節(jié)省帶寬 )
怎樣才算合理設(shè)置 ?原則很簡單，能緩存越多越好，能緩存越久越好。例如，很少變化的圖片資源可以直接通過 HTTP Header中的Expires設(shè)置一個很長的過期頭 ;變化不頻繁而又可能會變的資源可以使用 Last-Modifed來做請求驗證。盡可能的讓資源能夠在緩存中待得更久。關(guān)于 HTTP緩存的具體設(shè)置和原理此處就不再詳述了。
減少頁面的HTTP請求數(shù)是個起點，這是提升站點首次訪問速度的重要指導(dǎo)原則。
**2.減少DNS查找**
域名系統(tǒng)建立了主機(jī)名和IP地址間的映射，就像電話簿上人名和號碼的映射一樣。當(dāng)你在瀏覽器輸入www.yahoo.com的時候，瀏覽器就會聯(lián)系DNS解析器返回服務(wù)器的IP地址。DNS是有成本的，它需要20到120毫秒去查找給定主機(jī)名的IP地址。在DNS查找完成之前，瀏覽器無法從主機(jī)名下載任何東西。
DNS查找被緩存起來更高效，由用戶的ISP（網(wǎng)絡(luò)服務(wù)提供商）或者本地網(wǎng)絡(luò)存在一個特殊的緩存服務(wù)器上，但還可以緩存在個人用戶的計算機(jī)上。DNS信息被保存在操作系統(tǒng)的DNS cache(微軟Windows上的”DNS客戶端服務(wù)”)里。大多數(shù)瀏覽器有獨立于操作系統(tǒng)的自己的cache。只要瀏覽器在自己的cache里還保留著這條記錄，它就不會向操作系統(tǒng)查詢DNS。
IE默認(rèn)緩存DNS查找30分鐘，寫在DnsCacheTimeout注冊表設(shè)置中。Firefox緩存1分鐘，可以用network.dnsCacheExpiration配置項設(shè)置。(Fasterfox把緩存時間改成了1小時 P.S. Fasterfox是FF的一個提速插件)
如果客戶端的DNS cache是空的（包括瀏覽器的和操作系統(tǒng)的），DNS查找數(shù)等于頁面上不同的主機(jī)名數(shù)，包括頁面URL，圖片，腳本文件，樣式表，F(xiàn)lash對象等等組件中的主機(jī)名，減少不同的主機(jī)名就可以減少DNS查找。
減少不同主機(jī)名的數(shù)量同時也減少了頁面能夠并行下載的組件數(shù)量，避免DNS查找削減了響應(yīng)時間，而減少并行下載數(shù)量卻增加了響應(yīng)時間。我的原則是把組件分散在2到4個主機(jī)名下，這是同時減少DNS查找和允許高并發(fā)下載的折中方案。
**技巧1 – 使用快速DNS提供程序--->DNS提供商的速度**
**技巧2 – 更改TTL值以利用DNS緩存**
由于DNS緩存，你不必?fù)?dān)心在每一個頁面加載發(fā)生查找。這實際上是第一次請求。DNS緩存的工作方式與緩存WordPress站點的方式類似。DNS從緩存中提供，直到它到期。DNS高速緩存的長度取決于他們所謂的生存時間（TTL）值。TTL越高，瀏覽器執(zhí)行另一次DNS查找的可能性就越小。
**技巧3 – 減少域名（主機(jī)名）**
減少您網(wǎng)站上DNS查詢的最簡單方法是簡單地擺脫查詢不同主機(jī)名的請求。 請記住，使用DNS查找不是關(guān)于請求的數(shù)量，而是關(guān)于不同域的數(shù)量。通過像Pingdom這樣的工具運行你的WordPress站點，并確定每個請求是否真的有必要。由于DNS是一個主機(jī)名到IP的映射，你可能想知道為什么人們不只是指向一個IP呢？這是因為IP地址可以頻繁更改，而主機(jī)名不會.
**提示4 – 使用更快的DNS使用替代服務(wù)**
**技巧5 – 在CDN上移動和托管資源**
減少DNS查詢的最簡單方法之一是將盡可能多的資源移動到您的CDN提供商。如果您通過Pingdom運行您的網(wǎng)站，則可以按域查看請求的總數(shù),93.8％的請求是到CDN URL的。向主機(jī)發(fā)送一個請求，向Google Analytics發(fā)送一個請求。通過將盡可能多的資源移動到CDN，這減少了涉及的DNS查找次數(shù)，因此減少了加載時間。
**3.避免重定向**
重定向用301和302狀態(tài)碼，下面是一個有301狀態(tài)碼的HTTP頭：
瀏覽器會自動跳轉(zhuǎn)到Location域指明的URL。重定向需要的所有信息都在HTTP頭部，而響應(yīng)體一般是空的。其實額外的HTTP頭，比如Expires和Cache-Control也表示重定向。除此之外還有別的跳轉(zhuǎn)方式：refresh元標(biāo)簽和JavaScript，但如果你必須得做重定向，最好用標(biāo)準(zhǔn)的3xxHTTP狀態(tài)碼，主要是為了讓返回按鈕能正常使用。
牢記重定向會拖慢用戶體驗，在用戶和HTML文檔之間插入重定向會延遲頁面上的所有東西，頁面無法渲染，組件也無法開始下載，直到HTML文檔被送達(dá)瀏覽器。
有一種常見的極其浪費資源的重定向，而且web開發(fā)人員一般都意識不到這一點，就是URL尾部缺少一個斜線的時候。例如，跳轉(zhuǎn)到http://astrology.yahoo.com/astrology會返回一個重定向到http://astrology.yahoo.com/astrology/的301響應(yīng)（注意添在尾部的斜線）。在Apache中可以用Alias，mod_rewrite或者DirectorySlash指令來取消不必要的重定向。
重定向最常見的用途是把舊站點連接到新的站點，還可以連接同一站點的不同部分，針對用戶的不同情況（瀏覽器類型，用戶帳號類型等等）做一些處理。用重定向來連接兩個網(wǎng)站是最簡單的，只需要少量的額外代碼。雖然在這些時候使用重定向減少了開發(fā)人員的開發(fā)復(fù)雜度，但降低了用戶體驗。一種替代方案是用Alias和mod_rewrite，前提是兩個代碼路徑都在相同的服務(wù)器上。如果是因為域名變化而使用了重定向，就可以創(chuàng)建一條CNAME（創(chuàng)建一個指向另一個域名的DNS記錄作為別名）結(jié)合Alias或者mod_rewrite指令。
**4.讓Ajax可緩存**
Ajax的一個好處是可以給用戶提供即時反饋，因為它能夠從后臺服務(wù)器異步請求信息。然而，用了Ajax就無法保證用戶在等待異步JavaScript和XML響應(yīng)返回期間不會非常無聊。在很多應(yīng)用程序中，用戶能夠一直等待取決于如何使用Ajax。例如，在基于web的電子郵件客戶端中，用戶為了尋找符合他們搜索標(biāo)準(zhǔn)的郵件消息，將會保持對Ajax請求返回結(jié)果的關(guān)注。重要的是，要記得“異步”并不意味著“即時”。
要提高性能，優(yōu)化這些Ajax響應(yīng)至關(guān)重要。最重要的提高Ajax性能的方法就是讓響應(yīng)變得可緩存，就像在添上Expires或者Cache-Control HTTP頭中討論的一樣。下面適用于Ajax的其它規(guī)則：
**Gzip組件：**
Gzip是目前最流行和最有效的壓縮方法，由GNU開發(fā)然后標(biāo)準(zhǔn)化為RFC 1952。其他壓縮方式有deflate等，但主流瀏覽器大部分都支持gzip，但有的不支持deflate，所以gzip是壓縮方法的首選。
服務(wù)器會基于文件類型來選擇gzip的壓縮對象，大部分的網(wǎng)站壓縮html文檔，css，js文件，或者xml、json格式的返回結(jié)果。圖片和pdf格式的文件一般不會壓縮，因為它們已經(jīng)被壓縮了。嘗試壓縮這些文件不僅浪費cpu資源，反而有可能會增加壓縮文件的大小。
gzip是有代價的，在服務(wù)器端進(jìn)行壓縮要付出額外的cpu資源，同樣的在客戶端解壓也需要消耗cpu資源。權(quán)衡利弊要綜合考慮響應(yīng)的大小，帶寬以及客戶端和服務(wù)器之間的距離等因素。一般來說gzip可以降低響應(yīng)大小的約70%左右，還是挺可觀的
**減少DNS查找**：（參見上面2）
**壓縮JavaScript**：
avaScript的壓縮不是為了保護(hù)代碼而壓縮，而是壓縮后的js代碼文件可以小一倍甚至多倍，從而使這個js代碼快速的下載到客戶端，特別js文件較大時速度效果非常明顯
**避免重定向**:(參見上面3)
**配置ETags**:
以前瀏覽器緩存的就會失效。
**什么是ETag**？
實體標(biāo)簽(EntityTag)是唯一標(biāo)識了一個組件的一個特定版本的字符串，是web服務(wù)器用于確認(rèn)緩存組件的有效性的一種機(jī)制，通?？梢允褂媒M件的某些屬性來構(gòu)造它。
條件GET請求
如果組件過期了，瀏覽器在重用它之前必須首先檢查它是否有效。瀏覽器將發(fā)送一個條件GET請求到服務(wù)器，服務(wù)器判斷緩存還有效，則發(fā)送一個304響應(yīng)，告訴瀏覽器可以重用緩存組件。
那么服務(wù)器是根據(jù)什么判斷緩存是否還有效呢?有兩種方式：
ETag（實體標(biāo)簽）；
最新修改日期；
最新修改日期
原始服務(wù)器通過Last-Modified響應(yīng)頭來返回組件的最新修改日期。
我們一起看看例子，一個Web 2.0的電子郵件客戶端用了Ajax來下載用戶的通訊錄，以便實現(xiàn)自動完成功能。如果用戶從上一次使用之后再沒有修改過她的通訊錄，而且Ajax響應(yīng)是可緩存的，有尚未過期的Expires或者Cache-Control HTTP頭，那么之前的通訊錄就可以從緩存中讀出。必須通知瀏覽器，應(yīng)該繼續(xù)使用之前緩存的通訊錄響應(yīng)，還是去請求一個新的?？梢酝ㄟ^給通訊錄的Ajax URL里添加一個表明用戶通訊錄最后修改時間的時間戳來實現(xiàn)，例如&t=1190241612。如果通訊錄從上一次下載之后再沒有被修改過，時間戳不變，通訊錄就將從瀏覽器緩存中直接讀出，從而避免一次額外的HTTP往返消耗。如果用戶已經(jīng)修改了通訊錄，時間戳也可以確保新的URL不會匹配緩存的響應(yīng)，瀏覽器將請求新的通訊錄條目。
即使Ajax響應(yīng)是動態(tài)創(chuàng)建的，而且可能只適用于單用戶，它們也可以被緩存，而這樣會讓你的Web 2.0應(yīng)用更快。
***5.延遲加載組件***
可以湊近看看頁面并問自己：什么才是一開始渲染頁面所必須的？其余內(nèi)容都可以等會兒。
JavaScript是分隔onload事件之前和之后的一個理想選擇。例如，如果有JavaScript代碼和支持拖放以及動畫的庫，這些都可以先等會兒，因為拖放元素是在頁面最初渲染之后的。其它可以延遲加載的部分包括隱藏內(nèi)容（在某個交互動作之后才出現(xiàn)的內(nèi)容）和折疊的圖片。
工具可幫你減輕工作量：YUI Image Loader可以延遲加載折疊的圖片，還有YUI Get utility是一種引入JS和CSS的簡單方法。Yahoo!主頁就是一個例子，可以打開Firebug的網(wǎng)絡(luò)面板仔細(xì)看看。
最好讓性能目標(biāo)符合其它web開發(fā)最佳實踐，比如“漸進(jìn)增強(qiáng)”。如果客戶端支持JavaScript，可以提高用戶體驗，但必須確保頁面在不支持JavaScript時也能正常工作。所以，在確定頁面運行正常之后，可以用一些延遲加載腳本增強(qiáng)它，以支持一些拖放和動畫之類的華麗效果。
**6.預(yù)加載組件**
預(yù)加載可能看起來和延遲加載是相反的，但它其實有不同的目標(biāo)。通過預(yù)加載組件可以充分利用瀏覽器空閑的時間來請求將來會用到的組件（圖片，樣式和腳本）。用戶訪問下一頁的時候，大部分組件都已經(jīng)在緩存里了，所以在用戶看來頁面會加載得更快。
實際應(yīng)用中有以下幾種預(yù)加載的類型：
無條件預(yù)加載——盡快開始加載，獲取一些額外的組件。google.com就是一個sprite圖片預(yù)加載的好例子，這個sprite圖片并不是google.com主頁需要的，而是搜索結(jié)果頁面上的內(nèi)容。
條件性預(yù)加載——根據(jù)用戶操作猜測用戶將要跳轉(zhuǎn)到哪里并據(jù)此預(yù)加載。在search.yahoo.com的輸入框里鍵入內(nèi)容后，可以看到那些額外組件是怎樣請求加載的。
提前預(yù)加載——在推出新設(shè)計之前預(yù)加載。經(jīng)常在重新設(shè)計之后會聽到：“這個新網(wǎng)站不錯，但比以前更慢了”，一部分原因是用戶訪問先前的頁面都是有舊緩存的，但新的卻是一種空緩存狀態(tài)下的體驗?？梢酝ㄟ^在將要推出新設(shè)計之前預(yù)加載一些組件來減輕這種負(fù)面影響，老站可以利用瀏覽器空閑的時間來請求那些新站需要的圖片和腳本。
***7.減少DOM元素的數(shù)量***
一個復(fù)雜的頁面意味著要下載更多的字節(jié)，而且用JavaScript訪問DOM也會更慢。舉個例子，想要添加一個事件處理器的時候，循環(huán)遍歷頁面上的500個DOM元素和5000個DOM元素是有區(qū)別的。
大量的DOM元素是一種征兆——頁面上有些內(nèi)容無關(guān)的標(biāo)記需要清理。正在用嵌套表格來布局嗎？還是為了修復(fù)布局問題而添了一堆的<div>s？或許應(yīng)該用更好的語義化標(biāo)記。
YUI CSS utilities對布局有很大幫助：grids.css針對整體布局，fonts.css和reset.css可以用來去除瀏覽器的默認(rèn)格式。這是個開始清理和思考標(biāo)記的好機(jī)會，例如只在語義上有意義的時候使用<div>，而不是因為它能夠渲染一個新行。
**8.跨域分離組件**
分離組件可以最大化并行下載，但要確保只用不超過2-4個域，因為存在DNS查找的代價。例如，可以把HTML和動態(tài)內(nèi)容部署在www.example.org，而把靜態(tài)組件分離到static1.example.org和static2.example.org
**9.盡量少用iframe**
用iframe可以把一個HTML文檔插入到父文檔里，重要的是明白iframe是如何工作的并高效地使用它。
iframe的優(yōu)點：
引入緩慢的第三方內(nèi)容，比如標(biāo)志和廣告
安全沙箱
并行下載腳本
iframe的缺點：
代價高昂，即使是空白的iframe
阻塞頁面加載
非語義
**10.杜絕404**
HTTP請求代價高昂，完全沒有必要用一個HTTP請求去獲取一個無用的響應(yīng)（比如404 Not Found），只會拖慢用戶體驗而沒有任何好處。
有些站點用的是有幫助的404——“你的意思是xxx？”，這樣做有利于用戶體驗，，但也浪費了服務(wù)器資源（比如數(shù)據(jù)庫等等）。最糟糕的是鏈接到的外部JavaScript有錯誤而且結(jié)果是404。首先，這種下載將阻塞并行下載。其次，瀏覽器會試圖解析404響應(yīng)體，因為它是JavaScript代碼，需要找出其中可用的部分。
**CSS部分**
**11.避免使用CSS表達(dá)式**
用CSS表達(dá)式動態(tài)設(shè)置CSS屬性，是一種強(qiáng)大又危險的方式。從IE5開始支持，但從IE8起就不推薦使用了。
**12.選擇<link>舍棄@import**
前面提到了一個最佳實踐：為了實現(xiàn)逐步渲染，CSS應(yīng)該放在頂部。
在IE中用@import與在底部用<link>效果一樣，所以最好不要用它。
**13.避免使用濾鏡**
IE專有的AlphaImageLoader濾鏡可以用來修復(fù)IE7之前的版本中半透明PNG圖片的問題。在圖片加載過程中，這個濾鏡會阻塞渲染，卡住瀏覽器，還會增加內(nèi)存消耗而且是被應(yīng)用到每個元素的，而不是每個圖片，所以會存在一大堆問題。
最好的方法是干脆不要用AlphaImageLoader，而優(yōu)雅地降級到用在IE中支持性很好的PNG8圖片來代替。如果非要用AlphaImageLoader，應(yīng)該用下劃線hack：_filter來避免影響IE7及更高版本的用戶。
**14.把樣式表放在頂部**
在Yahoo!研究性能的時候，我們發(fā)現(xiàn)把樣式表放到文檔的HEAD部分能讓頁面看起來加載地更快。這是因為把樣式表放在head里能讓頁面逐步渲染。
關(guān)注性能的前端工程師想讓頁面逐步渲染。也就是說，我們想讓瀏覽器盡快顯示已有內(nèi)容，這在頁面上有一大堆內(nèi)容或者用戶網(wǎng)速很慢時顯得尤為重要。給用戶顯示反饋（比如進(jìn)度指標(biāo)）的重要性已經(jīng)被廣泛研究過，并且被記錄下來了。在我們的例子中，HTML頁面就是進(jìn)度指標(biāo)！當(dāng)瀏覽器逐漸加載頁面頭部，導(dǎo)航條，頂部logo等等內(nèi)容的時候，這些都被正在等待頁面加載的用戶當(dāng)作反饋，能夠提高整體用戶體驗。
**js部分：**
**15.去除重復(fù)腳本**
頁面含有重復(fù)的腳本文件會影響性能，這可能和你想象的不一樣。在對美國前10大web站點的評審中，發(fā)現(xiàn)只有2個站點含有重復(fù)腳本。兩個主要原因增加了在單一頁面中出現(xiàn)重復(fù)腳本的幾率：團(tuán)隊大小和腳本數(shù)量。在這種情況下，重復(fù)腳本會創(chuàng)建不必要的HTTP請求，執(zhí)行無用的JavaScript代碼，而影響頁面性能。
IE會產(chǎn)生不必要的HTTP請求，而Firefox不會。在IE中，如果一個不可緩存的外部腳本被頁面引入了兩次，它會在頁面加載時產(chǎn)生兩個HTTP請求。即使腳本是可緩存的，在用戶重新加載頁面時也會產(chǎn)生額外的HTTP請求。
除了產(chǎn)生沒有意義的HTTP請求之外，多次對腳本求值也會浪費時間。因為無論腳本是否可緩存，在Firefox和IE中都會執(zhí)行冗余的JavaScript代碼。
避免不小心把相同腳本引入兩次的一種方法就是在模版系統(tǒng)中實現(xiàn)腳本管理模塊。典型的腳本引入方法就是在HTML頁面中用SCRIPT標(biāo)簽：
1
<script type="text/javascript" src="menu_1.0.17.js"></script>
**16.盡量減少DOM訪問**
用JavaScript訪問DOM元素是很慢的，所以，為了讓頁面反應(yīng)更迅速，應(yīng)該：
緩存已訪問過的元素的索引
先“離線”更新節(jié)點，再把它們添到DOM樹上
避免用JavaScript修復(fù)布局問題
**17.用智能的事件處理器**
有時候感覺頁面反映不夠靈敏，是因為有太多頻繁執(zhí)行的事件處理器被添加到了DOM樹的不同元素上，這就是推薦使用事件委托的原因。如果一個div里面有10個按鈕，應(yīng)該只給div容器添加一個事件處理器，而不是給每個按鈕都添加一個。事件能夠冒泡，所以可以捕獲事件并得知哪個按鈕是事件源。
**18.把腳本放在底部**
腳本會阻塞并行下載，HTTP/1.1官方文檔建議瀏覽器每個主機(jī)名下并行下載的組件數(shù)不要超過兩個，如果圖片來自多個主機(jī)名，并行下載的數(shù)量就可以超過兩個。如果腳本正在下載，瀏覽器就不開始任何其它下載任務(wù)，即使是在不同主機(jī)名下的。
有時候，并不容易把腳本移動到底部。舉個例子，如果腳本是用document.write插入到頁面內(nèi)容中的，就沒辦法再往下移了。還可能存在作用域問題，在多數(shù)情況下，這些問題都是可以解決的。
一個常見的建議是用推遲（deferred）腳本，有DEFER屬性的腳本意味著不能含有document.write，并且提示瀏覽器告訴他們可以繼續(xù)渲染。不幸的是，F(xiàn)irefox不支持DEFER屬性。在IE中，腳本可能被推遲，但不盡如人意。如果腳本可以推遲，我們就可以把它放到頁面底部，頁面就可以更快地載入。
**javascript css 部分**
**19.把JavaScript和CSS放到外面**
很多性能原則都是關(guān)于如何管理外部組件的，然而，在這些顧慮出現(xiàn)之前你應(yīng)該問一個更基礎(chǔ)的問題：應(yīng)該把JavaScript和CSS放到外部文件中還是直接寫在頁面里？
實際上，用外部文件可以讓頁面更快，因為JavaScript和CSS文件會被緩存在瀏覽器。HTML文檔中的行內(nèi)JavaScript和CSS在每次請求該HTML文檔的時候都會重新下載。這樣做減少了所需的HTTP請求數(shù)，但增加了HTML文檔的大小。另一方面，如果JavaScript和CSS在外部文件中，并且已經(jīng)被瀏覽器緩存起來了，那么我們就成功地把HTML文檔變小了，而且還沒有增加HTTP請求數(shù)。
**20.壓縮JavaScript和CSS**
壓縮具體來說就是從代碼中去除不必要的字符以減少大小，從而提升加載速度。代碼最小化就是去掉所有注釋和不必要的空白字符（空格，換行和tab）。在JavaScript中這樣做能夠提高響應(yīng)性能，因為要下載的文件變小了。兩個最常用的JavaScript代碼壓縮工具是JSMin和YUI Compressor，YUI compressor還可以壓縮CSS。
混淆是一種可選的源碼優(yōu)化措施，要比壓縮更復(fù)雜，所以混淆過程也更容易產(chǎn)生bug。在對美國前十的網(wǎng)站調(diào)查中，壓縮可以縮小21%，而混淆能縮小25%。雖然混淆的縮小程度更高，但比壓縮風(fēng)險更大。
除了壓縮外部腳本和樣式，行內(nèi)的<script>和<style>塊也可以壓縮。即使啟用了gzip模塊，先進(jìn)行壓縮也能夠縮小5%或者更多的大小。JavaScript和CSS的用處越來越多，所以壓縮代碼會有不錯的效果。
**
**圖片****
**21.優(yōu)化圖片**
嘗試把GIF格式轉(zhuǎn)換成PNG格式，看看是否節(jié)省空間。在所有的PNG圖片上運行pngcrush（或者其它PNG優(yōu)化工具）
**22.優(yōu)化CSS Sprite**
在Sprite圖片中橫向排列一般都比縱向排列的最終文件小
組合Sprite圖片中的相似顏色可以保持低色數(shù)，最理想的是256色以下PNG8格式
“對移動端友好”，不要在Sprite圖片中留下太大的空隙。雖然不會在很大程度上影響圖片文件的大小，但這樣做可以節(jié)省用戶代理把圖片解壓成像素映射時消耗的內(nèi)存。100×100的圖片是1萬個像素，而1000×1000的圖片就是100萬個像素了。
2**3.不要用HTML縮放圖片**
不要因為在HTML中可以設(shè)置寬高而使用本不需要的大圖。如果需要
(https://img-blog.csdnimg.cn/20190308212131620.png)
那么圖片本身（mycat.jpg）應(yīng)該是100x100px的，而不是去縮小500x500px的圖片。
**24.用小的可緩存的favicon.ico（P.S. 收藏夾圖標(biāo)）**
favicon.ico是放在服務(wù)器根目錄的圖片，它會帶來一堆麻煩，因為即便你不管它，瀏覽器也會自動請求它，所以最好不要給一個404 Not Found響應(yīng)。而且只要在同一個服務(wù)器上，每次請求它時都會發(fā)送cookie，此外這個圖片還會干擾下載順序，例如在IE中，當(dāng)你在onload中請求額外組件時，將會先下載favicon。
所以為了緩解favicon.ico的缺點，應(yīng)該確保：
足夠小，最好在1K以下
設(shè)置合適的有效期HTTP頭（以后如果想換的話就不能重命名了），把有效期設(shè)置為幾個月后一般比較安全，可以通過檢查當(dāng)前favicon.ico的最后修改日期來確保變更能讓瀏覽器知道。
**cookie**
**25.給Cookie減肥**
使用cookie的原因有很多，比如授權(quán)和個性化。HTTP頭中cookie信息在web服務(wù)器和瀏覽器之間交換。重要的是保證cookie盡可能的小，以最小化對用戶響應(yīng)時間的影響。
清除不必要的cookie
保證cookie盡可能小，以最小化對用戶響應(yīng)時間的影響
注意給cookie設(shè)置合適的域級別，以免影響其它子域
設(shè)置合適的有效期，更早的有效期或者none可以更快的刪除cookie，提高用戶響應(yīng)時間
**26.把組件放在不含cookie的域下**
當(dāng)瀏覽器發(fā)送對靜態(tài)圖像的請求時，cookie也會一起發(fā)送，而服務(wù)器根本不需要這些cookie。所以它們只會造成沒有意義的網(wǎng)絡(luò)通信量，應(yīng)該確保對靜態(tài)組件的請求不含cookie?？梢詣?chuàng)建一個子域，把所有的靜態(tài)組件都部署在那兒。
如果域名是www.example.org，可以把靜態(tài)組件部署到static.example.org。然而，如果已經(jīng)在頂級域example.org或者www.example.org設(shè)置了cookie，那么所有對static.example.org的請求都會含有這些cookie。這時候可以再買一個新域名，把所有的靜態(tài)組件部署上去，并保持這個新域名不含cookie。Yahoo!用的是yimg.com，YouTube是ytimg.com，Amazon是images-amazon.com等等。
把靜態(tài)組件部署在不含cookie的域下還有一個好處是有些代理可能會拒絕緩存帶cookie的組件。有一點需要注意：如果不知道應(yīng)該用example.org還是www.example.org作為主頁，可以考慮一下cookie的影響。省略www的話，就只能把cookie寫到*.example.org，所以因為性能原因最好用www子域，并且把cookie寫到這個子域下。
**移動端 **
**27.保證所有組件都小于25K**
這個限制是因為iPhone不能緩存大于25K的組件，注意這里指的是未壓縮的大小。這就是為什么縮減內(nèi)容本身也很重要，因為單純的gzip可能不夠。
**28.把組件打包到一個復(fù)合文檔里**
把各個組件打包成一個像有附件的電子郵件一樣的復(fù)合文檔里，可以用一個HTTP請求獲取多個組件（記住一點：HTTP請求是代價高昂的）。用這種方式的時候，要先檢查用戶代理是否支持（iPhone就不支持）。
**服務(wù)器**
**29.Gzip組件**
前端工程師可以想辦法明顯地縮短通過網(wǎng)絡(luò)傳輸HTTP請求和響應(yīng)的時間。毫無疑問，終端用戶的帶寬速度，網(wǎng)絡(luò)服務(wù)商，對等交換點的距離等等，都是開發(fā)團(tuán)隊所無法控制的。但還有別的能夠影響響應(yīng)時間的因素，壓縮可以通過減少HTTP響應(yīng)的大小來縮短響應(yīng)時間。
從HTTP/1.1開始，web客戶端就有了支持壓縮的Accept-Encoding HTTP請求頭。
Accept-Encoding: gzip, deflate
如果web服務(wù)器看到這個請求頭，它就會用客戶端列出的一種方式來壓縮響應(yīng)。web服務(wù)器通過Content-Encoding相應(yīng)頭來通知客戶端。
Content-Encoding: gzip
盡可能多地用gzip壓縮能夠給頁面減肥，這也是提升用戶體驗最簡單的方法。
**30.避免圖片src屬性為空**
Image with empty string src屬性是空字符串的圖片很常見，主要以兩種形式出現(xiàn)：
(https://img-blog.csdnimg.cn/20190308211950109.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDQ2NTU4NA==,size_16,color_FFFFFF,t_70)
這兩種形式都會引起相同的問題：瀏覽器會向服務(wù)器發(fā)送另一個請求。
**31.配置ETags**
實體標(biāo)簽（ETags），是服務(wù)器和瀏覽器用來決定瀏覽器緩存中組件與源服務(wù)器中的組件是否匹配的一種機(jī)制（“實體”也就是組件：圖片，腳本，樣式表等等）。添加ETags可以提供一種實體驗證機(jī)制，比最后修改日期更加靈活。一個ETag是一個字符串，作為一個組件某一具體版本的唯一標(biāo)識符。唯一的格式約束是字符串必須用引號括起來，源服務(wù)器用相應(yīng)頭中的ETag來指定組件的ETag：
HTTP/1.1 200 OK
? ? ? Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
? ? ? ETag: "10c24bc-4ab-457e1c1f"
? ? ? Content-Length: 12195
然后，如果瀏覽器必須驗證一個組件，它用If-None-Match請求頭來把ETag傳回源服務(wù)器。如果ETags匹配成功，會返回一個304狀態(tài)碼，這樣就減少了12195個字節(jié)的響應(yīng)體。
GET /i/yahoo.gif HTTP/1.1
? ? ? Host: us.yimg.com
? ? ? If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
? ? ? If-None-Match: "10c24bc-4ab-457e1c1f"
? ? ? HTTP/1.1 304 Not Modified
**32.對Ajax用GET請求**
Yahoo!郵箱團(tuán)隊發(fā)現(xiàn)使用XMLHttpRequest時，瀏覽器的POST請求是通過一個兩步的過程來實現(xiàn)的：先發(fā)送HTTP頭，在發(fā)送數(shù)據(jù)。所以最好用GET請求，它只需要發(fā)送一個TCP報文（除非cookie特別多）。IE的URL長度最大值是2K，所以如果要發(fā)送的數(shù)據(jù)超過2K就無法使用GET了。
POST請求的一個有趣的副作用是實際上沒有發(fā)送任何數(shù)據(jù)，就像GET請求一樣。正如HTTP說明文檔中描述的，GET請求是用來檢索信息的。所以它的語義只是用GET請求來請求數(shù)據(jù)，而不是用來發(fā)送需要存儲到服務(wù)器的數(shù)據(jù)。
**33.盡早清空緩沖區(qū)**
當(dāng)用戶請求一個頁面時，服務(wù)器需要用大約200到500毫秒來組裝HTML頁面，在這期間，瀏覽器閑等著數(shù)據(jù)到達(dá)。PHP中有一個flush()函數(shù)，允許給瀏覽器發(fā)送一部分已經(jīng)準(zhǔn)備完畢的HTML響應(yīng)，以便瀏覽器可以在后臺準(zhǔn)備剩余部分的同時開始獲取組件，好處主要體現(xiàn)在很忙的后臺或者很“輕”的前端頁面上（P.S. 也就是說，響應(yīng)時耗主要在后臺方面時最能體現(xiàn)優(yōu)勢）。
較理想的清空緩沖區(qū)的位置是HEAD后面，因為HTML的HEAD部分通常更容易生成，并且允許引入任何CSS和JavaScript文件，這樣就可以讓瀏覽器在后臺還在處理的時候就開始并行獲取組件。
例如：
... <!-- css, js -->
? ? </head>
? ? <?php flush(); ?>
? ? <body>
? ? ? ... <!-- content -->
**34.使用CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）**
用戶與服務(wù)器的物理距離對響應(yīng)時間也有影響。把內(nèi)容部署在多個地理位置分散的服務(wù)器上能讓用戶更快地載入頁面。但具體要怎么做呢？
實現(xiàn)內(nèi)容在地理位置上分散的第一步是：不要嘗試去重新設(shè)計你的web應(yīng)用程序來適應(yīng)分布式結(jié)構(gòu)。這取決于應(yīng)用程序，改變結(jié)構(gòu)可能包括一些讓人望而生畏的任務(wù)，比如同步會話狀態(tài)和跨服務(wù)器復(fù)制數(shù)據(jù)庫事務(wù)（翻譯可能不準(zhǔn)確）?？s短用戶和內(nèi)容之間距離的提議可能被推遲，或者根本不可能通過，就是因為這個難題。
記住終端用戶80%到90%的響應(yīng)時間都花在下載頁面組件上了：圖片，樣式，腳本，F(xiàn)lash等等，這是業(yè)績黃金法則。最好先分散靜態(tài)內(nèi)容，而不是一開始就重新設(shè)計應(yīng)用程序結(jié)構(gòu)。這不僅能夠大大減少響應(yīng)時間，還更容易表現(xiàn)出CDN的功勞。
內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）是一組分散在不同地理位置的web服務(wù)器，用來給用戶更高效地發(fā)送內(nèi)容。典型地，選擇用來發(fā)送內(nèi)容的服務(wù)器是基于網(wǎng)絡(luò)距離的衡量標(biāo)準(zhǔn)的。例如：選跳數(shù)（hop）最少的或者響應(yīng)時間最快的服務(wù)器。
**35.添上Expires或者Cache-Control HTTP頭**
這條規(guī)則有兩個方面：
對于靜態(tài)組件：通過設(shè)置一個遙遠(yuǎn)的將來時間作為Expires來實現(xiàn)永不失效
多余動態(tài)組件：用合適的Cache-ControlHTTP頭來讓瀏覽器進(jìn)行條件性的請求
網(wǎng)頁設(shè)計越來越豐富，這意味著頁面里有更多的腳本，圖片和Flash。站點的新訪客可能還是不得不提交幾個HTTP請求，但通過使用有效期能讓組件變得可緩存，這避免了在接下來的瀏覽過程中不必要的HTTP請求。有效期HTTP頭通常被用在圖片上，但它們應(yīng)該用在所有組件上，包括腳本、樣式和Flash組件。
瀏覽器（和代理）用緩存來減少HTTP請求的數(shù)目和大小，讓頁面能夠更快加載。web服務(wù)器通過有效期HTTP響應(yīng)頭來告訴客戶端，頁面的各個組件應(yīng)該被緩存多久。用一個遙遠(yuǎn)的將來時間做有效期，告訴瀏覽器這個響應(yīng)在2010年4月15日前不會改變。
Expires: Thu, 15 Apr 2010 20:00:00 GMT
如果你用的是Apache服務(wù)器，用ExpiresDefault指令來設(shè)置相對于當(dāng)前日期的有效期。下面的例子設(shè)置了從請求時間起10年的有效期：
ExpiresDefault "access plus 10 years"
