11年資深技術(shù)開(kāi)發(fā)經(jīng)驗(yàn)專業(yè)提供
無(wú)錫網(wǎng)站建設(shè)
，微信小程序開(kāi)發(fā)
創(chuàng)新不是改變世界，而是不再重復(fù)昨天
發(fā)布日期：2015-06-25 閱讀：2580次
1 減少HTTP請(qǐng)求數(shù)量 (Minimize HTTP Requests)
tag:content
80%的用戶響應(yīng)時(shí)間被花費(fèi)在前端，而這其中的絕大多數(shù)時(shí)間是用于下載頁(yè)面中的圖片、樣式表、腳本以及Flash這些組件。減少這些組件的數(shù)量就可以減少展示頁(yè)面所需的請(qǐng)求數(shù)，而這是提高網(wǎng)頁(yè)響應(yīng)速度的關(guān)鍵。
樸素的頁(yè)面設(shè)計(jì)當(dāng)然是減少組件的一種途徑，但有沒(méi)有能兼顧豐富的頁(yè)面內(nèi)容和快速的響應(yīng)速度的方法呢？下面就是一些不錯(cuò)的技巧，能在提供豐富的頁(yè)面展現(xiàn)的同時(shí)，減少Http請(qǐng)求數(shù)量：
合并文件，通過(guò)把所有腳本置于一個(gè)腳本文件里或者把所有樣式表放于一個(gè)樣式表文件中，從而減少Http請(qǐng)求的數(shù)量。當(dāng)不同頁(yè)面需要應(yīng)用不同的腳本或樣式時(shí)，合并這些文件會(huì)是一個(gè)很大的挑戰(zhàn)，不過(guò)在發(fā)布網(wǎng)站時(shí)進(jìn)行這種合并，將是提高網(wǎng)站響應(yīng)速度的重要一步。
CSS Sprites是減少圖片請(qǐng)求的就選方案。把所有的背景圖片合并到一張圖中，使用CSS的background-image 和background-position 屬性去控制展現(xiàn)恰當(dāng)?shù)膱D片區(qū)域。
Image maps把多張圖片組合成為一張圖片。圖片的總大小是不變的，但減少Http請(qǐng)求數(shù)會(huì)提高頁(yè)面的響應(yīng)速度。Image maps只能用于圖片在網(wǎng)頁(yè)中相鄰的情況，比如導(dǎo)航條。制定image maps中的圖片坐標(biāo)是個(gè)很麻煩的過(guò)程，而且容易出錯(cuò)。同時(shí)給導(dǎo)航使用image maps也并不易讀，所以并不推薦使用。
內(nèi)聯(lián)圖片使用data: URL scheme 把圖片數(shù)據(jù)嵌入頁(yè)面，但這會(huì)增加Html文檔的大小。把內(nèi)聯(lián)圖片合并到你被緩存的的樣式表中是一個(gè)能既減少HTTP請(qǐng)求數(shù)又不會(huì)增加頁(yè)面大小的方法。但目前并不是所有的主流瀏覽器都支持內(nèi)聯(lián)圖片。
減少頁(yè)面的Http請(qǐng)求數(shù)量是一步，而且對(duì)于提高用戶初次訪問(wèn)體驗(yàn)是較重要的一步。正如在 Tenni Theurer的blog中的Browser Cache Usage - Exposed!里描述的，每天，有 40%-60%的訪客并沒(méi)有你的網(wǎng)站的緩存文件。提高這些初次訪客的訪問(wèn)速度是提高用戶體驗(yàn)的關(guān)鍵。
2 使用內(nèi)容分布式網(wǎng)絡(luò) (Use a Content Delivery Network)
tag:server
用戶連接你的網(wǎng)站服務(wù)器的速度影響響應(yīng)的快慢。把你的網(wǎng)站布置在多臺(tái)分布于不同地域的服務(wù)器上，會(huì)讓用戶覺(jué)得你的頁(yè)面加載速度更快。那么我們應(yīng)該從哪里開(kāi)始呢？
不要一開(kāi)始就把重新設(shè)計(jì)你的網(wǎng)站使其能夠適應(yīng)分布式結(jié)構(gòu)作為實(shí)現(xiàn)網(wǎng)站地域分布的一步。根據(jù)你的網(wǎng)站的復(fù)雜程度不同，更新網(wǎng)站結(jié)構(gòu)的過(guò)程也許會(huì)包含諸如同步會(huì)話狀態(tài)、在服務(wù)器間復(fù)制數(shù)據(jù)庫(kù)等一系列復(fù)雜的步驟。這樣你提高用戶訪問(wèn)速度的目的反而會(huì)被更新網(wǎng)站架構(gòu)的工作耽誤。
記住，用戶80-90%的訪問(wèn)時(shí)間被花費(fèi)在下載頁(yè)面中的圖片、樣式表、腳本、Flash這些組件上。這是網(wǎng)站展示的黃金法則。那么與其重新設(shè)計(jì)網(wǎng)站的結(jié)構(gòu)，不如先實(shí)現(xiàn)這些靜態(tài)組件的分布。這不僅僅可以大幅減少響應(yīng)時(shí)間，而且由于內(nèi)容分布式網(wǎng)絡(luò)（content delivery networks）的存在，這將是個(gè)很簡(jiǎn)單的工作。
內(nèi)容分布式網(wǎng)絡(luò)（CDN）是一系列分布在不同地域的服務(wù)器的集合，能夠更有效的給用戶發(fā)送信息。它會(huì)根據(jù)一種衡量網(wǎng)域距離的方法，選取為某個(gè)用戶發(fā)送數(shù)據(jù)的服務(wù)器。比如，到達(dá)用戶較少跳或者較快相應(yīng)速度的服務(wù)器會(huì)被選中。
一些大型Internet公司擁有他們自己的CDN，但使用公用的CDN服務(wù)提供商更為劃算，比如 Akamai Technologies, Mirror Image Internet, 或者Limelight Networks。對(duì)于剛起步的公司和個(gè)人網(wǎng)站來(lái)說(shuō)，CDN服務(wù)的花費(fèi)也許會(huì)偏高。但當(dāng)你的目標(biāo)用戶越來(lái)越多而且趨于國(guó)際化，用CDN來(lái)降低響應(yīng)時(shí)間就很必要了。在Yahoo!，把靜態(tài)的內(nèi)容從自己的網(wǎng)絡(luò)服務(wù)器移到CDN提高了用戶20%甚至更多的訪問(wèn)速度。轉(zhuǎn)向CDN會(huì)是一個(gè)只需要相對(duì)簡(jiǎn)單的代碼更新的工作，而且那將會(huì)顯著的提高你的網(wǎng)站訪問(wèn)速度。
3 給頭部添加一個(gè)失效期或者Cache-Control (Add an Expires or a Cache-Control Header)
tag:server
這條法則包含兩方面：
網(wǎng)頁(yè)設(shè)計(jì)越來(lái)越豐富，頁(yè)面里包含了越來(lái)越多的腳本、樣式表、圖片和Flash。頁(yè)面的初次訪問(wèn)者也許會(huì)發(fā)送多個(gè)HTTP請(qǐng)求，但通過(guò)給頭部添加失效期，你可以使那些組件被緩存。這會(huì)避免下次瀏覽頁(yè)面時(shí)的不必要的HTTP請(qǐng)求。給圖片文件的頭部設(shè)置失效時(shí)間更為常用，但包括腳本文件、樣式表和 Flash之類的所有組件的頭部都應(yīng)該被設(shè)置失效時(shí)間。
瀏覽器（還有代理服務(wù)器）使用緩存以減少HTTP請(qǐng)求的數(shù)量和大小，提高網(wǎng)頁(yè)的加載速度。服務(wù)器在HTTP相應(yīng)中通過(guò)頭部中的過(guò)期時(shí)間告知客戶端一個(gè)組件可以被緩存多久。下面是一個(gè)far future的過(guò)期頭部，告訴瀏覽器這個(gè)響應(yīng)直到2010年4月15日才會(huì)過(guò)期：
Expires: Thu, 15 Apr 2010 20:00:00 GMT
如果你使用的是Apache服務(wù)器，使用ExpiresDefault 指令會(huì)設(shè)置一個(gè)相對(duì)于當(dāng)前時(shí)間的過(guò)期時(shí)間。這里有一個(gè)通過(guò)ExpiresDefault 指令把過(guò)期時(shí)間設(shè)為請(qǐng)求時(shí)間之后10年的例子：
ExpiresDefault "access plus 10 years"
記住，如果你使用了far future過(guò)期頭部，你必須在組件更新時(shí)更換它的名字。在Yahoo!我們通常在建設(shè)網(wǎng)站的過(guò)程中執(zhí)行這樣的步驟：組件的名字里包含了它的版本，比如：yahoo_2.0.6.js。
使用一個(gè)far future過(guò)期頭部只會(huì)在用戶已經(jīng)訪問(wèn)你的網(wǎng)站之后起作用。它不會(huì)影響一個(gè)沒(méi)有緩存的初次訪問(wèn)者的HTTP請(qǐng)求數(shù)量。所以這一切的效果取決于多少用戶訪問(wèn)頁(yè)面時(shí)有一份預(yù)緩存（一份"預(yù)緩存"中已經(jīng)包含了頁(yè)面的所有組件）。我們對(duì)此在Yahoo！做過(guò)測(cè)試，發(fā)現(xiàn)擁有預(yù)緩存的用戶在 75-85%。給頭部添加far future失效期，可以增加瀏覽器緩存的組件數(shù)量并重復(fù)用于隨后的頁(yè)面瀏覽而不需要通過(guò)用戶的網(wǎng)絡(luò)發(fā)送哪怕一個(gè)字節(jié)。
4 Gzip壓縮組件(Gzip Components)
tag:server
前臺(tái)工程師的決策能夠顯著的減少在網(wǎng)絡(luò)上傳輸 HTTP請(qǐng)求和響應(yīng)花費(fèi)的時(shí)間。確實(shí)，終端用戶的帶寬速度、Internet服務(wù)提供商和連接交換機(jī)的服務(wù)器這些因素都是開(kāi)發(fā)小組所不能控制的。但還有一些其它因素會(huì)影響響應(yīng)的時(shí)間，比如壓縮文件，就會(huì)減少HTTP響應(yīng)的大小從而減少響應(yīng)的時(shí)間。
從HTTP/1.1開(kāi)始，Web客戶端就被設(shè)定為支持HTTP請(qǐng)求的頭部中Accept-Encoding指定的壓縮格式：
Accept-Encoding: gzip, deflate
當(dāng)服務(wù)器檢測(cè)到請(qǐng)求頭部中的這一代嗎，它就會(huì)使用客戶端提供的方法列表中的一個(gè)來(lái)壓縮響應(yīng)內(nèi)容。而服務(wù)器通過(guò)響應(yīng)頭部中的Content- Encoding來(lái)告知客戶端它所使用的壓縮方式：
Content-Encoding: gzip
Gzip是當(dāng)前較常用也是較有效的壓縮方式，GNU項(xiàng)目開(kāi)發(fā)了這一方法并且符合RFC 1952標(biāo)準(zhǔn)。另外一種你可能見(jiàn)過(guò)的壓縮格式是deflate，但它沒(méi)有那么有效和常用。
使用gzip壓縮通常會(huì)減少70%的響應(yīng)大小。當(dāng)前瀏覽器中大約90%的Internet通訊傳輸聲明支持gzip。如果你使用Apache服務(wù)器，配置gzip的模塊取決于服務(wù)器的版本：Apache 1.3 使用mod_gzip ，而Apache 2.x 使用mod_deflate。
瀏覽器和代理會(huì)有一些已知的問(wèn)題，可能導(dǎo)致瀏覽器的預(yù)期內(nèi)容和獲得的實(shí)際壓縮內(nèi)容不匹配。幸運(yùn)的是，這種情況隨著舊瀏覽器的使用者減少而減少。 Apache的模塊可以通過(guò)自動(dòng)添加適當(dāng)?shù)淖兓憫?yīng)文件頭來(lái)解決這些問(wèn)題。
服務(wù)器會(huì)根據(jù)文件類型選擇gzip壓縮的內(nèi)容，但一般情況下，服務(wù)器選擇壓縮的內(nèi)容會(huì)過(guò)于局限。大部分網(wǎng)站會(huì)壓縮它們的Html文檔，而壓縮腳本和樣式表也是值得一做的，但很多網(wǎng)站并沒(méi)有這樣做，事實(shí)上，壓縮在包括 XML和JSON在內(nèi)的任何文本響應(yīng)都是值得的。圖片和PDF文件不應(yīng)該被gzip壓縮，因?yàn)樗鼈円呀?jīng)是被壓縮了的文件，gzip它們不僅浪費(fèi)CPU甚至還有增大文件大小的可能。
Gzip盡可能多的文件類型是減少頁(yè)面大小從而提高用戶體驗(yàn)的一個(gè)簡(jiǎn)單的方法。
5 把樣式表放在前面(Put Stylesheets at the Top)
tag:css
在研究Yahoo！的性能時(shí)，我們發(fā)現(xiàn)把樣式表挪到文檔的頭部可以讓頁(yè)面的加載顯得更快。因?yàn)榘褬邮奖矸旁陬^部可以讓頁(yè)面逐步呈現(xiàn)。
關(guān)心網(wǎng)站性能的前臺(tái)工程師通常希望頁(yè)面能夠逐步加載；即，我們希望瀏覽器能夠把已經(jīng)獲得的內(nèi)容盡快展現(xiàn)。這對(duì)于內(nèi)容很多的頁(yè)面以及網(wǎng)絡(luò)連接較慢的用戶尤為重要。給予用戶視覺(jué)上的反饋（比如進(jìn)度提示）的重要性，已經(jīng)經(jīng)過(guò)了很詳盡的論證。而對(duì)于我們來(lái)說(shuō)，Html 頁(yè)面本身就可以作為進(jìn)度提示！當(dāng)瀏覽器逐步加載頁(yè)面時(shí)，頭部、導(dǎo)航條、頂部的logo等等這些都可以作為對(duì)正在等待頁(yè)面的用戶的可視的反饋。而這會(huì)從整體上提高用戶體驗(yàn)。
把樣式表放在文檔的較后，會(huì)導(dǎo)致包括IE在內(nèi)的大部分瀏覽器不進(jìn)行逐步呈現(xiàn)。瀏覽器為了避免當(dāng)樣式改變時(shí)重繪元素而中止呈現(xiàn)。用戶會(huì)十分無(wú)聊的看到一個(gè)空白的頁(yè)面。
Html規(guī)范明確規(guī)定樣式表應(yīng)該被包含在頁(yè)面的HEAD中：“和A不同，LINK只能在文檔的HEAD部位出現(xiàn)，但它可以出現(xiàn)多次。”空白的屏幕或者由于沒(méi)有應(yīng)用樣式而引起的內(nèi)容的閃現(xiàn)都不值得去嘗試。較好的方法是遵循HTML規(guī)范，把樣式表放在文檔的HEAD部位。
6 把腳本放在較后(Put Scripts at the Bottom)
tag:javascript
腳本可能會(huì)堵塞并發(fā)的下載。HTTP/1.1規(guī)范建議瀏覽器在每個(gè)域名下只進(jìn)行兩個(gè)并發(fā)下載。如果你把圖片放在多個(gè)域名下，可以實(shí)現(xiàn)多于兩個(gè)的并發(fā)下載。當(dāng)腳本被下載時(shí)，即使使用不同的域名。瀏覽器也不會(huì)進(jìn)行任何其它的下載。
有些情況下把腳本放到底部并不太容易。比如，腳本使用了[removed] 來(lái)添加部分頁(yè)面中的內(nèi)容，就不能放到頁(yè)面中更后面的位置。還可能有作用域的問(wèn)題。很多情況下，還有一些變通的方法。
通常的建議是使用延遲腳本。DEFER屬性表明腳本不包含[removed]，而且提示瀏覽器繼續(xù)展現(xiàn)。不幸的是，F(xiàn)irefox不支持DEFER屬性。IE中，腳本可以被延遲，但并不如你期望的那么久。如果一個(gè)腳本可以被延遲，那么它也可以被放在頁(yè)面的底部。這會(huì)讓你的頁(yè)面加載的更快。
7 不使用CSS表達(dá)式 (Avoid CSS Expressions)
tag:css
CSS表達(dá)式是一種有力的（同時(shí)也很危險(xiǎn)的）動(dòng)態(tài)設(shè)置CSS屬性的方法。從IE5開(kāi)始支持CSS表達(dá)式。比如，使用CSS表達(dá)式可以實(shí)現(xiàn)背景顏色每小時(shí)變換的效果。
background-color: expression_r( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );
如上所示，表達(dá)式方法采用了 Javascript的表達(dá)。CSS屬性則被設(shè)為Javascript表達(dá)式的結(jié)果。其它的瀏覽器會(huì)忽略CSS表達(dá)式，所以對(duì)于設(shè)置專屬I(mǎi)E的屬性以便在不同瀏覽器間能有一致的體驗(yàn)是有用的。、
而CSS表達(dá)式的問(wèn)題是它比大多數(shù)人期望的執(zhí)行次數(shù)更頻繁。表達(dá)式不僅僅在頁(yè)面展現(xiàn)和重新設(shè)置大小的時(shí)候執(zhí)行，在頁(yè)面滾動(dòng)，甚至用戶在頁(yè)面上挪動(dòng)鼠標(biāo)時(shí)都會(huì)執(zhí)行。給CSS表達(dá)式添加一個(gè)計(jì)數(shù)器可以跟蹤C(jī)SS在什么時(shí)候和怎樣執(zhí)行。在頁(yè)面上移動(dòng)鼠標(biāo)可以輕易的產(chǎn)生一萬(wàn)次以上的執(zhí)行。
使用一次性的表達(dá)式是減少CSS表達(dá)式的執(zhí)行次數(shù)的一個(gè)方法，當(dāng)表達(dá)式一次執(zhí)行時(shí)，CSS表達(dá)式會(huì)被一個(gè)確定的值代替。如果在頁(yè)面生命周期中，樣式屬性必須動(dòng)態(tài)的設(shè)定，使用事件處理替代CSS表達(dá)式是一個(gè)可選的方法。如果必須使用CSS表達(dá)式，要記得它們會(huì)執(zhí)行上千次并影響頁(yè)面的性能。
8 使用外部的JavaScript和CSS (Make JavaScript and CSS External)
tag:javascript,css
很多性能規(guī)則都是解決怎樣處理獨(dú)立的組件的問(wèn)題的。但是，考慮這些之前，你應(yīng)該先考慮一個(gè)更基本的問(wèn)題：JavaScript和CSS應(yīng)該被放于外部的文件，還是內(nèi)聯(lián)在頁(yè)面里？
在實(shí)際應(yīng)用中使用外部的文件往往產(chǎn)生更快的頁(yè)面，因?yàn)闉g覽器會(huì)緩存JavaScript和CSS文件。而內(nèi)聯(lián)在頁(yè)面里的JavaScript和CSS會(huì)在每次請(qǐng)求頁(yè)面時(shí)下載。這會(huì)減少所需的HTTP請(qǐng)求數(shù)，但增大HTML文檔的體積。而另一方面，如果放在外部文件里的JavaScript和CSS被瀏覽器緩存，則既不用增加HTTP請(qǐng)求的數(shù)量，HTML文檔的體積也會(huì)減少。
關(guān)鍵的問(wèn)題是，外部的JavaScript和CSS的組件被緩存的頻率和HTML文檔被請(qǐng)求的次數(shù)相關(guān)。雖然很難去量化，但可以被用很多指標(biāo)衡量。如果你的網(wǎng)站的用戶在每個(gè)會(huì)話中瀏覽了很多網(wǎng)頁(yè)而且很多頁(yè)面重用了相同的JavaSctipt和樣式表，緩存外部文件是有很大潛在的好處的。
很多網(wǎng)站都符合這樣的指標(biāo)。對(duì)于這些網(wǎng)站來(lái)說(shuō)，較好的解決方案是把JavaScript和CSS發(fā)布為單獨(dú)的文件。 的例外，對(duì)于主頁(yè)，內(nèi)聯(lián)的文件更好一些，例如 Yahoo!'s front page 和 My Yahoo!。主頁(yè)在每個(gè)會(huì)話中只有很少瀏覽（也許只有一次），你會(huì)發(fā)現(xiàn)內(nèi)聯(lián)的 JavaScript和CSS會(huì)讓終端用戶的響應(yīng)更快。
對(duì)于有很多頁(yè)面瀏覽量的首頁(yè)來(lái)說(shuō)，有很多能平衡內(nèi)聯(lián)文件所提供的HTTP請(qǐng)求減少的效果與外部文件緩存獲得的好處的技巧。一種這樣的技巧就是把JavaScript和CSS內(nèi)聯(lián)在說(shuō)夜里，但在頁(yè)面完成加載時(shí)動(dòng)態(tài)下載外部文件。隨后的頁(yè)面會(huì)調(diào)用瀏覽器中已經(jīng)緩存的外部文件。
9 減少DNS的查詢 (Reduce DNS Lookups)
tag:content
正如電話簿使人名和他們的電話號(hào)碼相對(duì)應(yīng)，域名系統(tǒng)（DNS）能夠使域名和IP地址相對(duì)應(yīng)。當(dāng)你在瀏覽器中鍵入http://www.yahoo.com，瀏覽器鏈接的DNS解析器會(huì)返回服務(wù)器的 IP地址。域名解析會(huì)耗費(fèi)一些時(shí)間，DNS查找給定域名的IP地址一般會(huì)耗費(fèi)20-120毫秒。在DNS查找結(jié)束前，瀏覽器不會(huì)從目標(biāo)域名那里下載任何東西。
DNS查詢會(huì)被緩存以便優(yōu)化性能。會(huì)有一個(gè)專門(mén)的緩存服務(wù)器進(jìn)行緩存，用戶的ISP或者本地網(wǎng)絡(luò)會(huì)維護(hù)它，但獨(dú)立用戶的電腦里也會(huì)有緩存。DNS信息存在于操作系統(tǒng)的DNS緩存里（微軟Windows操作系統(tǒng)里的“DNS客戶服務(wù)”）。大部分瀏覽器有它們自己的緩存，與操作系統(tǒng)的緩存相獨(dú)立。當(dāng)瀏覽器在自己的緩存里保存了DNS的記錄，它不會(huì)向操作系統(tǒng)發(fā)出請(qǐng)求記錄的要求。
IE默認(rèn)緩存DNS查詢30分鐘，在注冊(cè)表的DnsCacheTimeout的鍵值中設(shè)定。Firefox則緩存DNS查詢一分鐘，在配置network.dnsCacheExpiration 中設(shè)定。（Fasterfox 將它變?yōu)橐恍r(shí)。）
當(dāng)客戶端的DNS緩存被清空（包括瀏覽器和操作系統(tǒng)的緩存），DNS查詢的數(shù)量等同于網(wǎng)頁(yè)中單獨(dú)的域名的數(shù)量。包括頁(yè)面中的鏈接，圖片，腳本文件，樣式表，F(xiàn)lash對(duì)象等。減少不同域名的數(shù)量則會(huì)減少DNS查詢的數(shù)量。
減少不同域名的數(shù)量可能減少頁(yè)面并行的下載數(shù)量。減少 DNS查詢縮短了響應(yīng)時(shí)間，但減少了并行下載數(shù)也許會(huì)增加響應(yīng)時(shí)間。我的建議是將組件分布在兩到四個(gè)域名之間。這能很好的折中減少DNS查詢提高的速度和維持較高水平的并行下載的效果。
10 縮小JavaScript和CSS (Minify JavaScript and CSS)
tag:javascript,css
縮小是指從代碼中刪除不必要的字母，減少文件體積從而提高加載速度。縮減代碼時(shí)需要移除所有的注釋，以及不需要的空白（空格，新行和tab）。這樣處理JavaScript之后，會(huì)由于下載文件的體積被減少而提高響應(yīng)的性能。兩個(gè)常用的縮減JavaScript代碼的工具是JSMin 和YUI Compressor。YUI compressor也可以壓縮CSS。
代碼混淆是另一個(gè)可用于源代碼的優(yōu)化方案。它比壓縮更為復(fù)雜，而且在混淆的過(guò)程中更容易產(chǎn)生 Bug?？v觀U.S.的前十大網(wǎng)站，壓縮獲得了21%的體積減小而代碼混淆達(dá)到了25%。雖然代碼混淆的壓縮程度更高，但壓縮JavaScript的風(fēng)險(xiǎn)更小。
不僅僅要壓縮外部的腳本和樣式表，內(nèi)斂的<script>和<style>部分也可以而且應(yīng)當(dāng)被壓縮。即使你gzip了你的腳本和樣式，壓縮它們?nèi)匀荒軠p少5%以上的體積。隨著JavaScript和CSS的應(yīng)用和體積的增加，壓縮你的代碼獲得的收益也會(huì)越來(lái)越多。
11 避免重定向 (Avoid Redirects)
tag:content
重定向結(jié)束于 301或302狀態(tài)碼。這里有一個(gè)301響應(yīng)的HTTP頭的例子：
瀏覽器會(huì)自動(dòng)把用戶轉(zhuǎn)向Location域中指明的Url地址。HTTP頭里包含了重定向所需的所有信息。響應(yīng)的主體一般是空的。301或者302響應(yīng)都不會(huì)被實(shí)際緩存，除非添加額外的頭部，比如 Expires或者Cache- Control指明了它應(yīng)該被緩存。meta refresh標(biāo)簽和JavaScript也可以將用戶重定向到不同的URL，但如果你必須執(zhí)行重定向，較好的方法是使用標(biāo)準(zhǔn)的3XX HTTP狀態(tài)代碼，以便使后退按鈕工作正常。
需要謹(jǐn)記的是，重定向降低了用戶體驗(yàn)。在用戶和HTML文檔之間插入的重定向延誤了頁(yè)面的呈現(xiàn)和組件下載，因?yàn)樗鼈兌疾豢赡茉讷@得HTML文檔之前開(kāi)始。
一種較浪費(fèi)性能的重定向頻繁發(fā)生而網(wǎng)絡(luò)開(kāi)發(fā)者們卻往往沒(méi)有意識(shí)到，那就是當(dāng)?shù)刂分袘?yīng)當(dāng)有一個(gè)左斜線（/）卻沒(méi)有的時(shí)候。比如，訪問(wèn)http://astrology.yahoo.com/astrology會(huì)導(dǎo)致一個(gè)301效應(yīng)并重定向到http://astrology.yahoo.com/astrology/（注意這里加了一個(gè)左斜線）。在Apache中，這可以使用mod_rewrite,或者在Apache事件處理中使用DirectorySlash指令來(lái)修補(bǔ)。
使用重定向的另一個(gè)常見(jiàn)場(chǎng)景是連接舊網(wǎng)站和新網(wǎng)站。還包括連接網(wǎng)站的不同部分，或者在不同情況下（比如依據(jù)瀏覽器的類型，用戶的類型等）重定向用戶。使用重定向來(lái)連接兩個(gè)網(wǎng)站很簡(jiǎn)單而且需要很少的額外代碼。雖然在這些情況下使用重定向減少了開(kāi)發(fā)者的麻煩，但卻降低了用戶體驗(yàn)。如果兩部分在同一個(gè)服務(wù)器上，可以使用Alias 和rewrite來(lái)替代重定向。如果域名變更引起了重定向，可以創(chuàng)建一個(gè)CNAME（一種可以創(chuàng)建一個(gè)別名使一個(gè)域名指向另一個(gè)的DNS記錄）結(jié)合 Alias 或者mod_rewrite來(lái)替代重定向。
12 移除重復(fù)的腳本 (Remove Duplicate Scripts)
tag:javascript
在同一個(gè)頁(yè)面中包含兩個(gè)相同的腳本文件降低了性能。這并不如你想象的那么罕見(jiàn)。在對(duì)美國(guó)十大網(wǎng)站中的檢查中，發(fā)現(xiàn)它們中的兩個(gè)包含了重復(fù)的腳本。有兩個(gè)主要因素增加了一個(gè)頁(yè)面包含兩個(gè)相同腳本的幾率——團(tuán)隊(duì)的大小和腳本的數(shù)量。當(dāng)腳本被重復(fù)包含時(shí)，由于增加了不必要的HTTP請(qǐng)求和JavaScript的執(zhí)行，影響了性能。
不必要的HTTP請(qǐng)求在IE中存在，而Firefox終沒(méi)有。在IE中，如果一個(gè)外部腳本被包含了兩次而且沒(méi)有被緩存，在頁(yè)面加載的過(guò)程中會(huì)產(chǎn)生兩次HTTP請(qǐng)求。即使腳本被緩存了，當(dāng)用戶重載頁(yè)面時(shí)，多余的HTTP請(qǐng)求也會(huì)發(fā)生。
產(chǎn)生多余的HTTP請(qǐng)求的同時(shí)，多次執(zhí)行腳本也會(huì)浪費(fèi)時(shí)間。在Firefox和IE中，無(wú)論是否被緩存，腳本都會(huì)被重復(fù)執(zhí)行。
避免腳本被意外加載兩次的一個(gè)方法是在你的模板系統(tǒng)中執(zhí)行一個(gè)腳本管理模塊。通常的方式是在HTML頁(yè)面中使用SCRIPT標(biāo)簽來(lái)添加一個(gè)腳本：
<script type="text/javascript" src="menu_1.0.17.js"></script>
HP 中，可以選擇創(chuàng)建一個(gè)叫做insertScript的方法：
<?php insertScript("menu.js") ?>
這個(gè)函數(shù)不僅僅能防止腳本被重復(fù)加載多次，還可以解決腳本的其他問(wèn)題，比如獨(dú)立性檢測(cè)以及為腳本添加版本號(hào)碼以應(yīng)對(duì)far future Expires頭部。
13 設(shè)定ETags (Configure ETags)
tag:server
實(shí)體標(biāo)簽（ETags）是服務(wù)器和瀏覽器用于確定瀏覽器中緩存的組件和服務(wù)器中的是否對(duì)應(yīng)的一種機(jī)制。（"entity"是組件的另一種說(shuō)法：圖片、腳本、樣式表等等）添加 ETags用于辨別組件提供了比單純利用“較后修改時(shí)間”更為靈活的機(jī)制。ETag是一個(gè) 標(biāo)識(shí)組件的特定版本的字符串。它的 格式規(guī)范是字符串必須被引號(hào)引用。來(lái)源服務(wù)器使用ETag響應(yīng)頭來(lái)設(shè)定一個(gè)組件的ETag：
當(dāng)瀏覽器晚些時(shí)候需要檢測(cè)一個(gè)組件時(shí)，它使用If-None-Match 頭部把ETag傳回來(lái)源服務(wù)器。如果ETag匹配了，會(huì)返回一個(gè)304狀態(tài)碼，在這個(gè)例子里它會(huì)減少12195個(gè)字節(jié)的響應(yīng)：
ETag的問(wèn)題是它們往往在網(wǎng)站的一個(gè)服務(wù)器中被設(shè)為 的，當(dāng)瀏覽器從一個(gè)服務(wù)器得到了組件并在稍后試圖到另一個(gè)服務(wù)器驗(yàn)證時(shí)，ETag會(huì)不匹配，而這在使用多個(gè)服務(wù)器來(lái)處理請(qǐng)求的網(wǎng)站中是很常見(jiàn)的。默認(rèn)情況下，Apache和IIS在ETag中嵌入的數(shù)據(jù)戲劇性的減少了應(yīng)用多臺(tái)服務(wù)器的網(wǎng)站的ETag驗(yàn)證成功幾率。
Apache1.3和2.新版本的ETag格式是inode-size- timestamp。雖然一個(gè)給定的文件在多臺(tái)服務(wù)器中處于同一個(gè)目錄，而且有同樣的大小，權(quán)限，時(shí)間戳，但它的inode在不同服務(wù)器中是不同的。
IIS5.0和6.0有同樣的問(wèn)題。IIS中ETag的格式是Filetimestamp:ChangeNumber。 ChangeNumber用來(lái)跟蹤IIS配置的改變次數(shù)。一個(gè)網(wǎng)站的所有IIS不可能有相同的ChangeNumber。
這導(dǎo)致的結(jié)果是，Apache和IIS對(duì)完全相同的組件產(chǎn)生的ETag在不同服務(wù)器間不能匹配。如果ETags不匹配，用戶不會(huì)得到小而快的304響應(yīng)，而是一個(gè)普通的200響應(yīng)和組件的所有數(shù)據(jù)。如果你把你的網(wǎng)站放在了一個(gè)服務(wù)器里，這不會(huì)是一個(gè)問(wèn)題。但如果你的網(wǎng)站有多臺(tái)服務(wù)器，而且你使用了Apache和IIS 默認(rèn)的ETag配置，你的用戶會(huì)訪問(wèn)頁(yè)面的速度會(huì)變慢，你的服務(wù)器加載的程度更高，消耗了更大的帶寬，代理服務(wù)器不能有效的緩存你的內(nèi)容。即使你的組件有一個(gè)ar future Expires頭部，當(dāng)用戶重載或者刷新頁(yè)面時(shí)，依然會(huì)發(fā)送一個(gè)GET請(qǐng)求。
如果你不打算利用ETags提供的靈活的驗(yàn)證模式，你較好把ETag統(tǒng)統(tǒng)移除。Last-Modified頭部的驗(yàn)證方式給予組件的時(shí)間戳。移除ETag 同時(shí)減少響應(yīng)和隨后的請(qǐng)求中的HTTP頭部大小。這篇微軟的支持文檔描述了怎樣在IIS中移除 ETags。在Apache中，你只要在Apache配置文件中添加如下一行：
14 讓Ajax可以緩存 (Make Ajax Cacheable)
tag:content
Ajax 的好處之一是它能給用戶提供瞬間的響應(yīng)，因?yàn)樗鼜姆?wù)端異步請(qǐng)求數(shù)據(jù)。但Ajax不能保證用戶在等候那些異步的JavaScript和XML響應(yīng)返回時(shí)什么都不做。在應(yīng)用程序中，用戶是否繼續(xù)等待取決于Ajax怎樣應(yīng)用。比如，在一個(gè)基于Web的Email客戶端用戶會(huì)等候Ajax返回他們所搜索的郵件信息。記住異步并不代表“即刻”。
為了提高性能，優(yōu)化Ajax響應(yīng)很重要。提高Ajax性能較重要的方式是使響應(yīng)緩存，正如“添加一個(gè)過(guò)期期限和緩存控制頭”這一節(jié)討論的。這些原則同樣適用于Ajax。
我們看一個(gè)例子。一個(gè)Web2，0的郵件客戶端可能會(huì)用Ajax自動(dòng)下載用戶地址簿。如果用戶從上次使用郵件網(wǎng)站以來(lái)沒(méi)有修改她的地址簿，那么如果Ajax響應(yīng)使用了長(zhǎng)期失效時(shí)間或者緩存控制頭部，地址簿就可以從緩存中讀取出來(lái)。瀏覽器必須被告知“使用之前的緩存地址簿”而不是“請(qǐng)求一個(gè)新的地址簿”?？梢栽诘刂凡続jax的URL中添加一個(gè)標(biāo)識(shí)用戶較后一次修改地址簿的時(shí)間戳，比如，&t=1190241612。如果地址簿從較后一次下載后沒(méi)有被更改，時(shí)間戳將相同而地址簿將會(huì)從瀏覽器的緩存中得到來(lái)替代額外的HTTP傳輸。如果用戶更改了她的地址簿，時(shí)間戳?xí)ＷC新的URL不會(huì)和緩存中的匹配，而且瀏覽器會(huì)請(qǐng)求會(huì)請(qǐng)求更新的地址簿記錄。
即使你的Ajax響應(yīng)時(shí)動(dòng)態(tài)創(chuàng)建的，而且只適用于一個(gè)用戶，它們依然會(huì)被緩存。這樣做會(huì)讓你的Web2.0應(yīng)用程序更快。
15 更早的刷新緩沖區(qū) (Flush the Buffer Early)
tag:server
當(dāng)用戶請(qǐng)求一個(gè)頁(yè)面，服務(wù)端會(huì)花費(fèi)200至500毫秒的時(shí)間組合HTML頁(yè)面。在這期間，瀏覽器會(huì)靜靜等待數(shù)據(jù)到來(lái)。PHP中有flush（）函數(shù)，它允許你向?yàn)g覽器發(fā)送部分就緒的HTML響應(yīng)，這樣瀏覽器可以在服務(wù)器處理余下的HTML頁(yè)面時(shí)去獲取組件。這樣的好處主要在忙碌的后臺(tái)和輕松的前臺(tái)間可以看到。
在HEAD后面是放置刷新操作的好地方，因?yàn)轭^部的HTML代碼更容易產(chǎn)生，而且可以讓你放置任何CSS和JavaScript文件，以便瀏覽器在后臺(tái)工作依然進(jìn)行時(shí)并行開(kāi)始獲取組件。
例子：
... <!-- css, js -->
</head>
<?php flush(); ?>
<body>
... <!-- content -->
Yahoo! search先行研究并且進(jìn)行了真人測(cè)試證明了使用這項(xiàng)技術(shù)的好處。
16 在Ajax請(qǐng)求中使用GET方法 (Use GET for AJAX Requests)
tag:server
Yahoo! Mail 團(tuán)隊(duì)發(fā)現(xiàn)進(jìn)行XMLHttpRequest的時(shí)候，POST方法在瀏覽器中分兩步執(zhí)行：先發(fā)送頭部，然后發(fā)送數(shù)據(jù)。所以較好使用只發(fā)送一個(gè)TCP包（除非你有很多的cookie）的GET方法。IE中URL的較大長(zhǎng)度是2000，所以如果你發(fā)送超過(guò) 2000的數(shù)據(jù)就不能使用GET方法。
一個(gè)有趣的現(xiàn)象是，POST方法并不像GET那樣實(shí)際發(fā)送數(shù)據(jù)（而Get則名副其實(shí)）?；?HTTP規(guī)范，GET方法意味著取回?cái)?shù)據(jù)，所以當(dāng)你只是請(qǐng)求數(shù)據(jù)時(shí)使用GET方法更為有意義（從語(yǔ)義上來(lái)說(shuō)），而在發(fā)送需要儲(chǔ)存在服務(wù)器端的數(shù)據(jù)時(shí)則相反使用POST。
17 后加載組件 (Post-load Components)
tag:content
你可以仔細(xì)端詳下你的頁(yè)面然后自問(wèn)：“什么是在頁(yè)面初始化時(shí)必須的？”那么其余的內(nèi)容和組件可以放在后面。
JavaScript是理想的用來(lái)分割onload事件之前和之后的選擇。例如你有執(zhí)行拖放、下拉和動(dòng)畫(huà)的JavaScript代碼和菜單，它們可以稍后加載，因?yàn)橛脩粼诔跏汲尸F(xiàn)之后才會(huì)在頁(yè)面上拖動(dòng)元素。其他的可以被后加載的地方包括隱藏的內(nèi)容（當(dāng)用戶做某項(xiàng)操作才會(huì)展現(xiàn)的內(nèi)容）和被折疊的圖片。
可以幫助你的工具有： YUI Image Loader能幫助你延緩加載折疊的圖片，而且YUI Get utility 能夠很簡(jiǎn)單的包裝運(yùn)行中的JS和CSS。比如，打開(kāi)Firebug的網(wǎng)絡(luò)選項(xiàng)卡去查看Yahoo! Home Page。
當(dāng)性能指標(biāo)和其它網(wǎng)站開(kāi)發(fā)的好的實(shí)踐一致時(shí)是不錯(cuò)的。漸進(jìn)增強(qiáng)的觀念告訴我們當(dāng)支持JavaScript時(shí)，會(huì)提高用戶體驗(yàn)，但你必須確保在沒(méi)有JavaScript時(shí)頁(yè)面也能工作。所以當(dāng)你確保頁(yè)面工作正常時(shí)，你會(huì)通過(guò)延后加載的那些更花哨的腳本比如拖放和動(dòng)畫(huà)，來(lái)增強(qiáng)你的頁(yè)面。
18 預(yù)先加載組件 (Preload Components)
tag:content
預(yù)加載看起來(lái)和后加載原則是個(gè)矛盾，但它其實(shí)是為了另外一個(gè)目的。預(yù)加載組件讓你可以利用瀏覽器的空閑時(shí)間來(lái)加載之后需要的組件（比如圖片，樣式表和腳本）。這樣當(dāng)用戶瀏覽下一個(gè)頁(yè)面的時(shí)候，大部分組件都已經(jīng)在緩存里了而頁(yè)面會(huì)加載的更快。
有幾種預(yù)加載的類型：
19 減小DOM元素的數(shù)量 (Reduce the Number of DOM Elements)
tag:content
復(fù)雜的頁(yè)面意味著更多的字節(jié)需要被下載而且也意味著在JavaScript中遍歷DOM更慢。比如你在頁(yè)面中添加一個(gè)事件，讓它在500或者 5000個(gè)DOM元素中循環(huán)，它們的效率是不同的。
更多的DOM元素表明有些標(biāo)簽需要被改良而并不一定需要移除實(shí)際內(nèi)容。你是否為了布局而使用繁瑣的網(wǎng)一樣的表格？你是否只是為了彌補(bǔ)一些布局的問(wèn)題而使用了更多的div標(biāo)簽？也許還有更好和更符合語(yǔ)義的標(biāo)簽可以使用。
DOM 元素的數(shù)量很好檢測(cè)，只要在Firebug的控制臺(tái)里輸入：
document.getElementsByTagName_r('*').length
那么多少DOM元素算多呢？查看下類似的使用較好的標(biāo)簽的頁(yè)面。比如Yahoo! Home Page是一個(gè)很豐富的頁(yè)面但只有700以下的DOM元素（HTML 標(biāo)簽）。
20 分域部署部件：Split Components Across Domains
tag：內(nèi)容
將部件分割能使你獲得較大的并行下載效率。但你同時(shí)需要注意不使用多于2~4個(gè)域名，以避免DNS查詢導(dǎo)致的問(wèn)題。例如，你可以將HTML內(nèi)容和動(dòng)態(tài)的組建放于 www.example.org域名下，將靜態(tài)組件分別放于static1.example.org和static2.example.org之下。
查看Tenni Theurer和Patty Chi的"Maximizing Parallel Downloads in the Carpool Lane"獲取更多關(guān)于并行下載的信息。
21 減少I(mǎi)frame的數(shù)量 Minimize the Number of iframes
tag：內(nèi)容
Iframes 能夠使HTML文檔被插入進(jìn)父級(jí)文檔中。首先需要明確iframe的工作方式，才能有效的利用這一形式。
<iframe> 的優(yōu)點(diǎn)：
<iframe> 的缺點(diǎn)：
22 避免404錯(cuò)誤 No 404s
tag：內(nèi)容
一個(gè)獲得沒(méi)用的404響應(yīng)的HTTP請(qǐng)求對(duì)于寶貴的HTTP請(qǐng)求資源來(lái)說(shuō)是完全不必要的，而且這樣還會(huì)減慢用戶的體驗(yàn)。
有的網(wǎng)站提供了有幫助的404錯(cuò)誤信息，比如"你是否在尋找……？"，這樣雖然能提高用戶體驗(yàn)，但同樣浪費(fèi)了服務(wù)端資源（比如數(shù)據(jù)庫(kù)）。尤其不妙的是在請(qǐng)求一個(gè)外部的Javascript腳本文件失敗時(shí)獲得的一個(gè)404錯(cuò)誤，因?yàn)檫@樣不但會(huì)堵塞并行的下載，而且瀏覽器會(huì)嘗試分析404響應(yīng)的內(nèi)容，來(lái)辨識(shí)它是否是有用的Javascript代碼。
23 減少Cookie的大小 Reduce Cookie Size
tag：cookie
有多種理由讓我們應(yīng)用HTTP cookie，比如身份驗(yàn)證，或者個(gè)性化設(shè)置。Cookie中的信息在服務(wù)端和瀏覽器間被放在HTTP頭中交換。盡量減少cookie的體積對(duì)減少用戶獲得響應(yīng)的時(shí)間十分重要。
查看Tenni Theurer和Patty Chi的"When the Cookie Crumbles"獲取更多信息。
24 為部件使用沒(méi)有cookie的域名 Use Cookie-free Domains for Components
tag：cookie
當(dāng)瀏覽其請(qǐng)求一個(gè)靜態(tài)圖片并一同發(fā)送cookie時(shí)，服務(wù)器并不需要這些cookie。這樣只是毫無(wú)益處的創(chuàng)建了多余的網(wǎng)絡(luò)流量。應(yīng)當(dāng)保證靜態(tài)的部件在請(qǐng)求時(shí)沒(méi)有攜帶cookie，所以需要把你的靜態(tài)部件放在另一個(gè)子域名下。
如果你的域名是www.example.org，你可以將你的靜態(tài)部件放在static.example.org中。如果你把cookie設(shè)置在知名域名example.org上而不是 www.example.org，那么所有發(fā)送至static.example.org的請(qǐng)求會(huì)包括那些cookie。在這種情況下，你可以買(mǎi)一個(gè)全新的沒(méi)有cookie的域名來(lái)放置你的靜態(tài)部件。Yahoo！使用了yimg.com，YouTube試用了ytimg.com，Amazon使用的是 images-amazon.com。
將靜態(tài)部件放于沒(méi)有cookie的域名下的另一個(gè)好處是一些代理服務(wù)器會(huì)拒絕緩存有cookie 的部件。于此相關(guān)的一點(diǎn)是，如果你懷疑你應(yīng)該為你的首頁(yè)使用example.org還是www.example.org，考慮cookie的贏下。省略 www會(huì)讓你不得不把cookie寫(xiě)到*.example.org下，所以考慮性能，較好使用www.子域名，然后把cookie寫(xiě)到這個(gè)子域名下。
25 減少DOM的讀取 Minimize DOM Access
tag：javascript
利用Javascript讀取 DOM元素很慢，所以為了獲得響應(yīng)更快的頁(yè)面，你應(yīng)該：
26 開(kāi)發(fā)靈巧的事件處理程序 Develop Smart Event Handlers
tag：javascript
如果有太多的事件處理邏輯部署在DOM樹(shù)的不同元素上，它們的頻繁執(zhí)行會(huì)拖慢頁(yè)面的響應(yīng)速度。而使用事件委托是一個(gè)好的解決方法。如果在一個(gè)Div中有10個(gè)按鈕，與其在每個(gè)按鈕上都放一個(gè)事件處理程序，步入只在Div上放一個(gè)事件處理程序。事件會(huì)冒泡上溯，這樣你就會(huì)捕獲這一事件，并找出是哪個(gè)按鈕發(fā)起的它。
同樣，你并不需要等待onload事件來(lái)啟動(dòng)一些操作DOM樹(shù)的程序。你只需要保證你需要操作的元素可用就可以了。你不需要等待所有的圖片下載完畢，你應(yīng)當(dāng)使用DOMContentLoaded事件來(lái)替代onload事件，當(dāng)然，目前并不是所有瀏覽器都支持這一事件，你可以使用YUI Event組件，其中包含了一個(gè)onAvailable函數(shù)。
查看Julien Lecomte的"High Performance Ajax Applications"獲取更多信息。
27 選擇<link>而不是@import Choose <link> over @import
tag：css
前面提到把CSS應(yīng)當(dāng)放在較頂端來(lái)提供預(yù)顯。在IE中，放在頁(yè)面底部的@import和<link>效果是一樣的，所以較好不要用它。
28 不使用過(guò)濾器 Avoid Filters
tag：css
IE專有的AlphaImageLoader過(guò)濾器是為了解決半透明真色PNG圖片在IE7之前的版本中顯示的問(wèn)題。這個(gè)過(guò)濾器會(huì)在圖片下載時(shí)堵塞住展示。而且它會(huì)消耗內(nèi)存并影響每個(gè)元素而不僅僅是每張圖片，所以這個(gè)過(guò)濾器的問(wèn)題很多。
所以較好在IE中完全不使用AlphaImageLoader過(guò)濾器，而使用漸淡的 PNG8圖片。如果你明確需要AlphaImageLoader，請(qǐng)使用hack _filter，從而不影響到你的IE7+的用戶。
29 優(yōu)化圖片 Optimize Images
tag：images
當(dāng)設(shè)計(jì)師制作好網(wǎng)站的圖片后，還有些事情應(yīng)該是你在把這些圖片上傳到服務(wù)器之前做的。
30 優(yōu)化CSS精靈 Optimize CSS Sprites
tag：images
31 不要在HTML中縮放圖片 Don't Scale Images in HTML
tag：images
不要使用大小超過(guò)需要的圖片，即使你能夠在HTML中設(shè)置它的屬性。如果你需要
<img width="100" height="100" src="mycat.jpg" alt="My Cat" />
那么就使用恰好100*100px的圖片，而不是使用縮放后的500*500的圖片。
32 使用小的可緩存的Favicon.ico Make favicon.ico Small and Cacheable
tag：images
favicon.icon是放在服務(wù)器根目錄的一個(gè)圖片，它是個(gè)麻煩卻不得不處理，因?yàn)榧词鼓悴魂P(guān)心，瀏覽器依然會(huì)請(qǐng)求這張圖片，所以較好不要提供一個(gè)404的錯(cuò)誤。而且由于它是在同一服務(wù)器下的，Cookie也會(huì)隨著每次請(qǐng)求一并發(fā)送。這張圖片同樣干擾下載隊(duì)列，比如在IE中，當(dāng)你在onload 事件中請(qǐng)求額外的組件時(shí)，favicon會(huì)在這些額外組件之前下載。
所以為了減少favicon.ico的不利影響，我們應(yīng)當(dāng)：
Imagemagick 能夠幫助你創(chuàng)建小圖片。
33 保證組件大小小于25K Keep Components under 25K
tag：mobile
這一限制是因?yàn)閕Pone不會(huì)緩存大于25K的組件，注意這里指的是未壓縮前的大小。這就是為什么縮小大小很重要，因?yàn)閱螁蝕zip并不足夠。
查看Wayne Shea和Tenni Theurer的"Performance Research, Part 5: iPhone Cacheability - Making it Stick"獲取更多信息。
34 把組件打包進(jìn)多部分文檔中 Pack Components into a Multipart Document
tag：mobile
把組件打包進(jìn)多部分文檔類似一封包含有附件的郵件，它能讓你通過(guò)一個(gè)HTTP請(qǐng)求獲取多個(gè)組件（記住HTTP請(qǐng)求是很昂貴的）。當(dāng)你使用這一技術(shù)，請(qǐng)先檢查客戶端是否支持它(iPone不支持)。
說(shuō)起今年網(wǎng)站是否需要改版這個(gè)話題，就要從互聯(lián)網(wǎng)的誕生到互聯(lián)網(wǎng)高速發(fā)展的今天，目前有成熟的網(wǎng)站開(kāi)發(fā)技術(shù)、網(wǎng)站設(shè)計(jì)也是日新月異。有了這些技術(shù)的前提，今天我們來(lái)說(shuō)說(shuō)公司網(wǎng)站有沒(méi)有必要進(jìn)行改版？
隨著短視頻及直播的影響，流量迅速轉(zhuǎn)移到某些移動(dòng)平臺(tái)，還來(lái)不及轉(zhuǎn)型又沒(méi)有穩(wěn)定流量來(lái)源的無(wú)錫網(wǎng)站設(shè)計(jì)公司活得那叫一言難盡。網(wǎng)站搭建的市場(chǎng)雖然急劇萎縮，卻也還有一定的市場(chǎng)需求，網(wǎng)站制作的價(jià)格也是良莠不齊。有很多客戶就納悶了，同樣一個(gè)網(wǎng)站設(shè)計(jì)，為什么做網(wǎng)站公司報(bào)出來(lái)的價(jià)格相差那么大呢？下面就來(lái)說(shuō)說(shuō)，無(wú)錫網(wǎng)站建設(shè)價(jià)格的評(píng)估依據(jù)有哪些？
在做網(wǎng)站建設(shè)業(yè)務(wù)時(shí)候，通常前期企業(yè)客戶會(huì)要求網(wǎng)絡(luò)公司或者技術(shù)人員給出一個(gè)網(wǎng)站建設(shè)的方案。其實(shí)即使客戶不要求，作為做網(wǎng)站建設(shè)策劃的人員在建立網(wǎng)站前也應(yīng)該出一個(gè)這樣的策劃方案，這樣能讓自己的思路更清晰一些。
現(xiàn)如今互聯(lián)網(wǎng)中的用戶量是比較大的，企業(yè)網(wǎng)站可以通過(guò)互聯(lián)網(wǎng)將自己宣傳推廣出去，在用戶想通過(guò)搜索想要的產(chǎn)品、服務(wù)以及想要全面了解你的企業(yè)，那么你的企業(yè)官網(wǎng)就能起到流量承載的作用。
營(yíng)銷(xiāo)型網(wǎng)站建設(shè)如何進(jìn)行？近幾年有很多企業(yè)開(kāi)始建設(shè)企業(yè)網(wǎng)站用于商品宣傳和營(yíng)銷(xiāo)，營(yíng)銷(xiāo)型網(wǎng)站主要是以營(yíng)銷(xiāo)為目的的，能夠幫助企業(yè)提示轉(zhuǎn)化率，從而起到好的市場(chǎng)營(yíng)銷(xiāo)效果。建設(shè)營(yíng)銷(xiāo)型網(wǎng)站也是有一定的方法和規(guī)則的，需要根據(jù)企業(yè)的產(chǎn)品、服務(wù)、優(yōu)勢(shì)等特點(diǎn)進(jìn)行市場(chǎng)的定位。
在互聯(lián)網(wǎng)發(fā)展的環(huán)境中，企業(yè)在不斷的變化，創(chuàng)新也就成為企業(yè)必不可少的方式，那么在企業(yè)網(wǎng)站設(shè)計(jì)發(fā)展的新趨勢(shì)又有哪些呢？在建設(shè)網(wǎng)站效果達(dá)到好的效果呢？
版權(quán)所有 ? 2011-2024 無(wú)錫迅誠(chéng)信息科技有限公司 備案號(hào)：蘇ICP備11038949號(hào)-2 
蘇公網(wǎng)安備 32020602000833號(hào)
專業(yè)團(tuán)隊(duì)為您提供無(wú)錫網(wǎng)站建設(shè),無(wú)錫網(wǎng)站制作,無(wú)錫品牌網(wǎng)站設(shè)計(jì),無(wú)錫響應(yīng)式網(wǎng)站制作,無(wú)錫微信小程序開(kāi)發(fā)等服務(wù),無(wú)錫建網(wǎng)站就找迅誠(chéng)科技！ 網(wǎng)站地圖 | 地圖XML
網(wǎng)站建設(shè)中網(wǎng)站布局的技巧
扁平化網(wǎng)站建設(shè)之顏色搭配
返回
