網(wǎng)頁(yè)設(shè)計(jì)師和前端開(kāi)發(fā)者看的前端性能優(yōu)化
2024-01-20 分類(lèi)： 網(wǎng)站建設(shè)
基礎(chǔ)知識(shí)
關(guān)于性能，有一些知識(shí)在所有的設(shè)計(jì)師和前端開(kāi)發(fā)者中廣為傳播。例如，盡可能少的請(qǐng)求，優(yōu)化圖片，把樣式表(stylesheets)放在<head>, 把JS放在</body>之前, 最小化(minifying) JS 和 CSS 等等。這些基礎(chǔ)知識(shí)已經(jīng)被用來(lái)加快用戶響應(yīng)了，但還有更多更多需要學(xué)習(xí)。
雖然在我們每天的工作生活中，瀏覽器給我們制造麻煩，使我們頭疼，但請(qǐng)記住，他們也是很聰明的; 它們?yōu)槲覀冏隽撕芏嘈阅軆?yōu)化工作, 所以大量的性能調(diào)優(yōu)知識(shí)不但要知道瀏覽器在哪里給我們做了優(yōu)化，還要知道怎么更好的挖掘它們。大量性能調(diào)優(yōu)訣竅只是理解，利用和操縱瀏覽器已經(jīng)替我們做好的優(yōu)化工作。
頂部的Styles, 底部的scripts
這真的是一條基本規(guī)則，每個(gè)人都能非常容易的在大多數(shù)時(shí)間遵守，但為什么它重要？簡(jiǎn)短的說(shuō)：
CSS 塊渲染, 因此你需要立即處理它（即在文檔的頂部，在你的<head>之中）。 JS 塊下載, 因此你需要最后處理它們，以確保它們沒(méi)有耽誤頁(yè)面中任何其它東西。 CSS塊渲染是因?yàn)闉g覽器總是試圖漸進(jìn)式的渲染頁(yè)面；它們想在元素到達(dá)的時(shí)候順序的渲染它。如果style在距離很遠(yuǎn)的頁(yè)面下部，瀏覽器在獲得它之前沒(méi)有辦法渲染那個(gè)CSS。因?yàn)檫@個(gè)原因，如果瀏覽器在渲染文檔過(guò)程中，改變了之前渲染的東西，它們可以避免style的重繪。瀏覽器在它獲得所有需要的style信息之前不會(huì)渲染頁(yè)面，如果你將style放在文檔底部，你就是在使瀏覽器等待，阻塞了渲染。
所以，只要你將CSS放在頁(yè)面的頂部，那么瀏覽器就可以立刻開(kāi)始渲染。
JavaScript塊下載是由于好幾個(gè)原因（這又是瀏覽器聰明之處），但首先我們需要知道瀏覽器里的資源下載是如何實(shí)際發(fā)生的；簡(jiǎn)單的說(shuō)，瀏覽器會(huì)從一個(gè)單一的域名并行的盡可能多的下載資源。它從越多的域名下載，就能在一瞬間并行的獲得更多的資源。
JavaScript中斷了這個(gè)過(guò)程，阻塞了從任何一個(gè)域名的并行的下載，因?yàn)椋?br />
被調(diào)用的腳本可能改變頁(yè)面，即瀏覽器在繼續(xù)別的事情以前，將不得不處理它。因此為了處理那個(gè)不測(cè)事件，瀏覽器停止了任何其它東西的下載，以便集中精力關(guān)注于它。 腳本正常工作經(jīng)常需要依照一定的順序加載，例如，要在加載一個(gè)插件之前加載jQuery。瀏覽器阻止了JavaScript的并行下載，因此它不會(huì)同時(shí)下載jQuery和你的插件；很顯然如果你同時(shí)并行下載二者，你的插件會(huì)在jQuery之前到達(dá)。 所以，由于瀏覽器在獲取JavaScript的時(shí)候停止了所有其他下載，將你的JavaScript腳本放在文檔中盡可能晚加載的地方是一個(gè)好主意。我相信你們都看到過(guò)頁(yè)面中的空白片段，在那里第三方的JS腳本被花時(shí)間加載，并且它還阻止了頁(yè)面其他資源的獲取和渲染；這就是JavaScript的阻塞在作用了。
但是顯然，現(xiàn)代瀏覽器還是變得聰明了。我將給你一個(gè)Andy Davies寄給我的電子郵件的摘錄，因?yàn)樗忉尩谋任仪宄?br />
現(xiàn)代瀏覽器將并行下載JS，只有在腳本被執(zhí)行的時(shí)候阻塞渲染（顯然腳本必須也被下載了）。腳本下載常常被瀏覽器的預(yù)加載器所完成。當(dāng)瀏覽器頁(yè)面渲染被阻塞，即等待CSS，或JS被執(zhí)行，預(yù)分析器將掃描頁(yè)面剩余部分，尋找它能下載的資源。有些瀏覽器如 Chrome, 將分先后下載資源，例如，如果腳本與圖片同時(shí)在等待下載，它將先下載腳本。
漂亮的內(nèi)容！
所以，要使頁(yè)面被盡可能快的渲染，將styles放在頂部。為了阻止JS的阻塞影響到渲染，將scripts放在底部。
更少的請(qǐng)求
另一個(gè)明顯而基本的性能優(yōu)化方法是少下載。頁(yè)面需要的每一個(gè)資源就是一次額外的HTTP請(qǐng)求；瀏覽器不得不停下來(lái)去獲取每一個(gè)用于渲染頁(yè)面所需的資源。每一次HTTP請(qǐng)求都可能引發(fā)DNS查詢，重定向，404，等等。每一次HTTP請(qǐng)求，無(wú)論為了樣式表，圖片，web字體，JS文件還是其它你能想到的，都可能是一次非常昂貴的操作。盡量減少這些請(qǐng)求是你可以做的最快的優(yōu)化方法中的一種.
再談到瀏覽器和并行；大多數(shù)瀏覽器一次只從每個(gè)引用的域下載一些資源，而JS會(huì)阻塞這些下載。所以，你做的每一個(gè)HTTP請(qǐng)求都應(yīng)該仔細(xì)考慮，而不是隨便隨便做的。
盡可能并行
為了讓瀏覽器能并行的下載更多資源，你可以由不同的域名提供服務(wù)。如果說(shuō)，瀏覽器只能一次從一個(gè)域名獲取兩個(gè)資源，那么由兩個(gè)域名提供服務(wù)意味著它可以一次性獲取四個(gè)資源；三個(gè)域名意味著六個(gè)并行下載。
許多網(wǎng)站有靜態(tài)/資源 域名；你可以發(fā)現(xiàn)， Twitter, 用 si0.twimg.com 來(lái)做靜態(tài)資源：
1 <link rel="stylesheet" type="text/css" media="screen">
Facebook 用fbstatic-a.akamaihd.net：
1 <link rel="stylesheet" >
通過(guò)這些靜態(tài)的資源域名， Twitter與Facebook能提供更多的并行資源服務(wù)；來(lái)自twitter.com和si0.twimg.com的資源可以協(xié)作方式下載。這真的是使你的頁(yè)面上獲得更多并發(fā)下載的簡(jiǎn)單方法，如果再加上實(shí)際的CDN技術(shù)就會(huì)更好，CDN技術(shù)通過(guò)從一個(gè)更加合適的物理位置提供資源服務(wù)的方法來(lái)減少延遲。
這全部都很好，但后面我們將討論在特定環(huán)境下，怎樣從子域名提供服務(wù)卻會(huì)實(shí)際上對(duì)性能有害。
因此，現(xiàn)在有了我們關(guān)于性能的基礎(chǔ)知識(shí)：
將樣式表放在文檔的頂部 將JavaScript放在底部（可能的地方） 盡可能減少HTTP請(qǐng)求 從多個(gè)域名提供資源服務(wù)能增加瀏覽器并行下載的資源數(shù)量。 HTTP 請(qǐng)求與 DNS 查詢
每當(dāng)你從任何域名請(qǐng)求一個(gè)資源，會(huì)發(fā)出一個(gè)帶有相關(guān)頭部，被訪問(wèn)資源的 HTTP請(qǐng)求，并且會(huì)返回一個(gè)響應(yīng)。這是對(duì)該過(guò)程的一個(gè)極端簡(jiǎn)化，但它基本就是事實(shí)上你需要知道的。這是一個(gè)HTTP請(qǐng)求，而且所有涉及的資源都從屬于這個(gè)往返的旅行。當(dāng)提到前端性能，這些請(qǐng)求正是主要的瓶頸所在，因?yàn)槿缥覀冋劦降模瑸g覽器受限于有多少請(qǐng)求可以并行發(fā)生。這也是為什么我們經(jīng)常要使用子域名；以便允許這些請(qǐng)求在數(shù)個(gè)域名上發(fā)生，允許同時(shí)發(fā)生多得多數(shù)量的請(qǐng)求。
然而關(guān)于這還有個(gè)問(wèn)題，DNS查詢。每次（從一個(gè)空緩存）一個(gè)新的域名被引用，HTTP請(qǐng)求會(huì)受制于一個(gè)耗時(shí)的DNS查詢（某個(gè)介于20到120毫秒之間的值），在DNS查詢中，發(fā)出的請(qǐng)求會(huì)查詢資源實(shí)際存在的地點(diǎn)；互聯(lián)網(wǎng)通過(guò)IP地址被綁定在一起，這些地址由DNS管理的主機(jī)名引用。
如果每個(gè)引用的新域名具有DNS查詢的前端代價(jià)，你必須確保這個(gè)代價(jià)確實(shí)是值得的。如果是一個(gè)小網(wǎng)站（例如像CSS魔法），那么由子域名提供資源可能并不值得；相比執(zhí)行多個(gè)域名的DNS查詢并將其并行化來(lái)說(shuō)，從一個(gè)域名非并行的獲取若干資源，瀏覽器可能更快。
如果你或許有一打資源，你可能會(huì)考慮從一個(gè)子域名提供它們的資源服務(wù)；為了更好的并行化那許多資源，額外的DNS查詢可能是值得的。如果說(shuō)你有40個(gè)資源，可能將那些資源切分到兩個(gè)子域名是值得的；為了由總數(shù)為三個(gè)的域名提供你的網(wǎng)站服務(wù)，兩個(gè)額外的DNS查詢會(huì)是值得的。
DNS查詢代價(jià)很高，因此你需要決定什么才是對(duì)你的網(wǎng)站更合適的；承擔(dān)查詢的消耗或者只是由一個(gè)域名提供所有服務(wù)。
很重要的需要記得的是，比方說(shuō)一旦HTML被請(qǐng)求于foo.com，對(duì)那個(gè)主機(jī)的DNS查詢就立即發(fā)生了，所以后續(xù)的任何對(duì)foo.com的請(qǐng)求不再受制于DNS查詢。
DNS 預(yù)取
如果你像我一樣想在網(wǎng)站上有一個(gè)Twitter小程序，還有網(wǎng)站分析，再也許一些網(wǎng)頁(yè)字體，那么你必須要鏈接到一些其它域名，這意味著你將不得不引發(fā)DNS查詢。我的建議通常是，不要還沒(méi)有先適當(dāng)?shù)目紤]性能影響就使用某個(gè)或任何一個(gè)小程序，但對(duì)于你認(rèn)為確實(shí)需要的，下面的將很有用……
因?yàn)檫@些東西都存在于其它域名，比方說(shuō)這就意味著你的網(wǎng)站字體CSS將會(huì)同你自己的CSS并行下載，從某種意義上說(shuō)是一種好處，但是腳本將仍會(huì)阻塞（除非它們是異步的）
事實(shí)上，這里的問(wèn)題是DNS查詢牽涉到了第三方域名。幸運(yùn)的是，有一個(gè)相當(dāng)快又簡(jiǎn)單的辦法來(lái)加速這個(gè)過(guò)程：DNS預(yù)取。
DNS預(yù)取所做的恰恰就是憑證領(lǐng)餐(on the tin)，它不能被簡(jiǎn)單實(shí)現(xiàn)。比方說(shuō)，如果你需要請(qǐng)求來(lái)自widget.foo.com的資源，那么你可以通過(guò)簡(jiǎn)單的在頁(yè)面的<head>里先增加下面這個(gè)來(lái)預(yù)取那個(gè)主機(jī)的DNS：
1 2 3 4 5 <head> ... <link rel="dns-prefetch" > ... </head>
那行簡(jiǎn)單的內(nèi)容將會(huì)告訴支持的瀏覽器去開(kāi)始預(yù)取那個(gè)域名的DNS，這要稍稍早于它實(shí)際需要的時(shí)刻。它意味著DNS查詢過(guò)程，在瀏覽器<script>元素真正請(qǐng)求小程序的時(shí)候就已經(jīng)在進(jìn)行中了。這僅僅給瀏覽器增加了一個(gè)很小的開(kāi)頭。
這種簡(jiǎn)單的鏈接元素（就是我在CSS魔法上用到的）完全后向兼容，而且不會(huì)忽略性能影響。將它看作是性能提升增強(qiáng)吧！
延伸閱讀
通過(guò)預(yù)取加速你的網(wǎng)站 資源預(yù)取
和DNS預(yù)取一樣，也可以順便對(duì)你的站點(diǎn)需要的其它資源進(jìn)行預(yù)取。為了弄清楚我們想要預(yù)取哪些資源， 首先我們需要了解瀏覽器通常會(huì)在什么時(shí)候以什么方式對(duì)資源發(fā)出請(qǐng)求。
CSS中引用的Web字體和圖片表現(xiàn)基本相同；瀏覽器在碰到需要它們的HTML時(shí)開(kāi)始對(duì)它們進(jìn)行下載。就和我在前面提到那樣，瀏覽器非常聰明，這又是一個(gè)例證。想象一下，瀏覽器一看到下面的CSS聲明就開(kāi)始下載其中所引用的圖片：
1 2 3 4 .page--home { background-image:url(home.jpg); } .page--about { background-image:url(about.jpg); } .page--portfolio { background-image:url(portfolio.jpg); } .page--contact { background-image:url(contact.jpg); }
如果瀏覽器不是等碰到需要這些圖片的HTML再下載它們，那么訪問(wèn)主頁(yè)就會(huì)立即下載所有這四個(gè)圖片。這會(huì)造成浪費(fèi)，所以瀏覽器一定會(huì)確保在需要這些圖片時(shí)才會(huì)開(kāi)始下載它們。所以，這里有個(gè)問(wèn)題在于，圖片下載直到很晚才會(huì)開(kāi)始。
如果我們可以完全確認(rèn)某個(gè)CSS圖片肯定會(huì)在每個(gè)頁(yè)面都會(huì)用到的話，我們就可以用個(gè)小把戲讓瀏覽器早早下載好這個(gè)圖片，無(wú)需等到讓瀏覽器碰到需要使用該圖片的HTML才開(kāi)始下載。想做到這一點(diǎn)也非常簡(jiǎn)單，但所用的方法可能會(huì)有點(diǎn)糙，就看你怎么弄了。
比較糙的方法和大多數(shù)笨拙的萬(wàn)全之法類(lèi)似，就是在每個(gè)頁(yè)面放置一個(gè)隱藏的<div>，在該div中使用帶有空的alt屬性的<img>標(biāo)簽。我在CSS Wizardry項(xiàng)目中的精靈中就是這么干的；因?yàn)槲抑?，每個(gè)頁(yè)面都要使用該精靈，所以我就通過(guò)在HTML中對(duì)其進(jìn)行引用對(duì)它進(jìn)行預(yù)取。瀏覽器處理內(nèi)聯(lián)（inline）<img>的方式非常好，瀏覽器會(huì)早早地對(duì)它們進(jìn)行預(yù)取，所以通過(guò)讓瀏覽器將我的精靈作為HTML中的<img>進(jìn)行載入，瀏覽器就可以在使用需要精靈的CSS之前將其下載好。通過(guò)首先在我的HTML中引用該精靈（隱藏起來(lái)的），我就能夠搶先把精靈下載好。
還有第二種方法比較”優(yōu)雅”，但會(huì)讓人有些困惑。它和DNS預(yù)取的例子非常相似
1 <link rel="prefetch" href="sprite.png">
這會(huì)顯式地告訴瀏覽器，馬上開(kāi)始預(yù)取我的精靈圖片，而不要考慮在它處理CSS時(shí)可能會(huì)做的任何決定。
令人感到困惑之處在于有兩篇文章似乎有不同的觀點(diǎn)；基于來(lái)自MDN的這篇文章，貌似這種預(yù)取指令只是示意瀏覽器僅在它空閑時(shí)才有可能會(huì)對(duì)href所指的資源進(jìn)行預(yù)取。然而，與此矛盾的是，來(lái)自Planet Performance的這篇文章貌似在說(shuō)，如果瀏覽器支持rel=”prefetch”的話，它就一定會(huì)預(yù)取href中所指的資源，并沒(méi)有提及是否要在瀏覽器空閑時(shí)才進(jìn)行預(yù)取。我在WebKit的Inpsector中的瀑布圖中所看到的情況是后者說(shuō)得是對(duì)的，但是在打開(kāi)Developer Tools的情況下（薛定諤測(cè)不準(zhǔn)。。。）WebKit的表現(xiàn)及其怪異，我就觀察不到預(yù)取動(dòng)作的情況了，這也就是我說(shuō)，我無(wú)法100%保證我說(shuō)的是對(duì)的。要是誰(shuí)能解釋清楚這方面的情況，我將不勝感激。
我在前面說(shuō)過(guò)，字體和圖片表現(xiàn)非常相似，上面所說(shuō)的規(guī)則同樣也適用于字體文件，但你無(wú)法使用隱藏的<div>載入字體文件（你需要使用預(yù)取link）。
1 <link rel="prefetch" href="webfont.woff">
所以，基本可以這么說(shuō)，我們這里所作的一切，只能算是讓瀏覽器提前下載資源的”小把戲”而已，耍了小把戲之后，在瀏覽器碰到要使用CSS的時(shí)候，其中所引用的資源就早已下載好了（或者至少已經(jīng)在下載中了）。 漂亮極了！
延伸閱讀
采用預(yù)取來(lái)加速你的網(wǎng)站 CSS 與性能
許多建議說(shuō)，如果你在使用資源域名，你應(yīng)該由它們提供所有靜態(tài)資源服務(wù)；包括CSS，JS，圖片等等。
但是在工作中我們發(fā)現(xiàn)一件事，那就是你不應(yīng)該由一個(gè)資源/子域名提供CSS服務(wù)…
還記得先前我們討論CSS塊渲染嗎？瀏覽器想盡可能快的獲得CSS，直到不能更快；CSS位于你的關(guān)鍵路徑。你的關(guān)鍵路徑是用戶頁(yè)面請(qǐng)求與之后實(shí)際看到頁(yè)面之間的必要的旅程。因?yàn)樗枞虽秩?，所以CSS位于關(guān)鍵路徑，而JS和圖片不是。你會(huì)希望在關(guān)鍵路徑上盡可能快的加快這個(gè)旅程，這就意味著不能有DNS查詢。
實(shí)際工作中，我們搭建了一個(gè)網(wǎng)站，在某個(gè)階段性的環(huán)境中它由同一臺(tái)主機(jī)（如foo.com）提供資源服務(wù)，但到了使整個(gè)環(huán)境支持更加繁忙業(yè)務(wù)的時(shí)候，我們開(kāi)始由s1.foo.com與s2.foo.com提供資源服務(wù)。這意味著所有的圖片，JS，CSS，字體等等都來(lái)自于不同的域名，由此便引起了DNS查詢。這里的問(wèn)題在于，由于空的緩存，為了獲得CSS文件而需要執(zhí)行DNS查詢，這實(shí)際上使得關(guān)鍵路徑速度徹底慢下來(lái)。我們的圖片大多數(shù)會(huì)模糊，這暗示著有理論上不應(yīng)該有的延時(shí)；最佳實(shí)踐要求應(yīng)該將資源分布于在子域名上，對(duì)嗎？但不包括CSS。DNS查詢占據(jù)了大量的時(shí)間，進(jìn)而延遲了頁(yè)面的渲染。
因?yàn)橛羞@種渲染阻塞階段，CSS是性能最壞的敵人之一，正如Stoyan Stefanov闡述的那樣 。而且也很有必要注意到瀏覽器在它開(kāi)始渲染頁(yè)面之前將下載所有的CSS。這意味著即使瀏覽器僅僅在屏幕上渲染頁(yè)面，也要請(qǐng)求print.css。任何只是基于一種媒體查詢的樣式表（如<link rel=”stylesheet” media=”screen and (min-device-width: 800px)” href=”desktop.css”>）都將會(huì)被下載，即使并不需要它們。
即便如此，Andy Davies 告知我WebKit實(shí)際上提高了CSS下載的優(yōu)先級(jí)，以便只有渲染頁(yè)面需要的CSS先到達(dá)，而其他的樣式，如print.css盡可能的延遲。漂亮！
知道這些關(guān)于CSS的信息已經(jīng)允許我們做出一些決定，這些決定全部基于CSS阻塞渲染，要全部被請(qǐng)求，以及它位于關(guān)鍵路徑的知識(shí)：
永遠(yuǎn)不要從一個(gè)固定/資源域名提供服務(wù) 因?yàn)檫@會(huì)引起DNS查詢并進(jìn)一步延遲渲染。 先提供服務(wù) 因此瀏覽器可以繼續(xù)忙下去。 合并它 因?yàn)椴还茉鯓訛g覽器會(huì)獲取所有CSS，你最好將所有這些壓縮于一個(gè)HTTP請(qǐng)求。 壓縮并簡(jiǎn)化它 以便瀏覽器需要下載的少一些。 緩存它的一切 以便上述的過(guò)程盡可能少的發(fā)生。 CSS位于關(guān)鍵路徑，因此你需要盡早先解決它，它阻塞渲染就意味著降低了用戶的性能體驗(yàn)。 把CSS移到子域名會(huì)損害性能。
延伸閱讀
CSS與關(guān)鍵路徑 壓縮與簡(jiǎn)化
對(duì)于你的文本資源，有兩個(gè)實(shí)在很簡(jiǎn)單的事情是你能（而且也應(yīng)該）做的；簡(jiǎn)化他們移除任何注釋和空格，并且進(jìn)一步的壓縮它們大小。
如果你想選擇其一，單獨(dú)的壓縮要比單獨(dú)的簡(jiǎn)化更有效。然而，如果可能的話你應(yīng)該兩個(gè)都做。
實(shí)施壓縮經(jīng)常需要一點(diǎn).htaccess詭計(jì)，但如我的好朋友 Nick Payne指出的，.htaccess實(shí)際上從服務(wù)端的觀點(diǎn)來(lái)看不是特別有性能；.htaccess評(píng)估每一個(gè)到達(dá)請(qǐng)求，因此實(shí)際它有很多開(kāi)銷(xiāo)。
這取自 Apache 文檔 ：
你應(yīng)該完全避免使用.htaccess文件，如果你可以直接訪問(wèn)http主服務(wù)器的配置文件的話。 使用.htaccess文件使你的Apache http server慢下來(lái)。任何你能包含進(jìn)一個(gè).htaccess文件的指令最好設(shè)置在一個(gè)字典 塊,因?yàn)樗哂型瑯拥男в貌⑶矣懈玫男阅堋?br />
如果你確實(shí)只是訪問(wèn).htaccess，那么我不會(huì)擔(dān)心；這個(gè)開(kāi)銷(xiāo)的代價(jià)通常無(wú)需關(guān)心。實(shí)際上通過(guò).htaccess來(lái)壓縮實(shí)現(xiàn)起來(lái)很簡(jiǎn)單。而簡(jiǎn)化不是那么容易，除非你有一個(gè)構(gòu)建過(guò)程，或者用一些類(lèi)似代碼工具套件，或者能直接編譯輸出最小化的預(yù)處理器。
有趣的是，我移動(dòng)inuit.css到Sass的主要原因最初是——我可以方便的編譯一個(gè)簡(jiǎn)化的版本。
簡(jiǎn)化（Minification）最主要的部分是簡(jiǎn)單的刪除空格與注釋?zhuān)蝗绻阍诖a中寫(xiě)的注釋像我一樣多，那么你確實(shí)需要縮減你的資源。
像任何壓縮算法一樣，壓縮（Gzip）將任何基于文本的輸入，基于重復(fù)的/可重復(fù)的字符串對(duì)其進(jìn)行壓縮。通過(guò)gzip大多數(shù)代碼壓縮得很好，因?yàn)樗写a都有包含重復(fù)字符串的傾向;例如CSS中一遍又一遍的background-image，標(biāo)簽中一遍又一遍的<strong>…
壓縮真的大量的壓榨掉資源的大小，你應(yīng)該明確的啟用它。為了能有規(guī)范的.htaccess片段，查閱 HTML5 樣板處理資源 。
壓縮內(nèi)容引起大量的節(jié)約。在寫(xiě)操作的時(shí)候，inuit.css 輸入有77k大小。壓縮以后只有5.52k。簡(jiǎn)化與壓縮給我們節(jié)省了93%。而且因?yàn)間zip對(duì)基于文本的資源工作的很好，你甚至可以壓縮可縮放矢量圖形（SVGs）和一些字體格式文件！
優(yōu)化圖像
相比通過(guò)優(yōu)化工具運(yùn)行而言，我對(duì)優(yōu)化圖像的藝術(shù)不是非常的知識(shí)廣博，但通過(guò)圖像自身，后加工來(lái)解決是一個(gè)相當(dāng)有趣的話題。
Spriting (精靈)
如果想要一個(gè)性能優(yōu)異的網(wǎng)站，Sprites（精靈，一種網(wǎng)頁(yè)圖片應(yīng)用處理方式，它允許你將一個(gè)頁(yè)面涉及到的所有零星圖片都包含到一張大圖中去）是幾乎強(qiáng)制性的；在一個(gè)HTTP請(qǐng)求里加載一個(gè)大的圖片，而不是若干個(gè)請(qǐng)求若干個(gè)圖片。但是問(wèn)題在于，不是所有的圖片都可以立即精靈化；可能你有一個(gè)圖標(biāo)，需要將它作為一個(gè)彈性寬度元素的背景圖像，但你顯然不能將其精靈化，因?yàn)閟prites對(duì)非固定尺寸元素不起作用。你通常只要在sprite表中的圖像周?chē)旁S多空格，但這樣在sprite中浪費(fèi)像素它們自己就影響到性能了。
為了解決特定元素的不可精靈化，我們需要一種稱(chēng)為”精靈元素”的東西。這基本是一個(gè)空元素，一般是一個(gè)<i>，它的核心工作就是保持空并且加載一個(gè)背景圖像。
在我創(chuàng)建Sky Bet時(shí)我用過(guò)這些，YouTube用它們, Facebook用它們， Jonathan Snook 有 一篇SMACSS的文章整個(gè)章節(jié)都關(guān)于他們。
基本的前提是，如果因?yàn)橐粋€(gè)元素是流態(tài)的而不能精靈化，那么你在它里面放置一個(gè)空元素解決尺寸的問(wèn)題，然后就可以精靈化了，例如：
1 2 3 4 5 <li> <a href="/profile/"> <i></i> Profile </a> </li>
這里我們不能精靈化<li>或者<a>，所以我們?cè)谀抢镉幸粋€(gè)空的<i>，它替代加載圖標(biāo)。這是關(guān)于性能我最喜歡的事情之一；你正將聰明的技術(shù)整合來(lái)改善頁(yè)面速度，卻仍然在使用傳統(tǒng)的”壞”標(biāo)記。有趣的定西！
延伸閱讀
Sprite還是不要Sprite 視網(wǎng)膜圖像
你不需要將所有都提高到視網(wǎng)膜級(jí)別。在標(biāo)準(zhǔn)分辨率下，同樣的圖像放大2倍將包含四倍數(shù)量的像素。四倍啊。然而這并不意味著需要通過(guò)連接傳輸四倍的文件大小——感謝圖片自身的編碼格式——也就是說(shuō)一旦圖像解壓并在瀏覽器中渲染，有四倍數(shù)量于平常的像素需要存儲(chǔ)于內(nèi)存。
如果停下來(lái)思考一下；視網(wǎng)膜圖像最常（即使不是總是）需要用于給手機(jī)提供一個(gè)保真的UI。手機(jī)內(nèi)存比其他設(shè)備少很多。視網(wǎng)膜效果給內(nèi)存并不很多的設(shè)備提供了消耗內(nèi)存的圖像……反復(fù)全面的考慮一下你是真的需要視網(wǎng)膜圖像，或者還是你可以做出一個(gè)明智的妥協(xié)？
視網(wǎng)膜效果是一種很棒的，清晰的體驗(yàn)，但如果需要5秒鐘時(shí)間下載的話，將不會(huì)有清爽的體驗(yàn)。在大多數(shù)情形速度要?jiǎng)龠^(guò)美感。
為了給每個(gè)人提供足夠好的圖片，你可以很聰明的給所有設(shè)備提供1.5倍的圖像，但就我的觀點(diǎn)——最好的選擇是節(jié)儉的使用視網(wǎng)膜。
如果統(tǒng)計(jì)數(shù)據(jù)表明有足夠富余，你就可以針對(duì)矢量圖形優(yōu)化，或者用字體圖標(biāo)代替位圖。在CSS魔法網(wǎng)站我使用了矢量圖形，這給我?guī)?lái)了如下好處：
分辨率無(wú)關(guān) 可簡(jiǎn)化 可壓縮 在工作中 Matt Allen 給我們做了一種字體圖標(biāo)，可以同主要元素一起使用提供一種準(zhǔn)視網(wǎng)膜的，可伸縮的圖標(biāo)。
你也可以看看怎樣使用類(lèi)似ReSRC.it的服務(wù)，以便基于設(shè)備與上下文加載圖片。
漸進(jìn)的 JPGs
性能的一個(gè)有趣的方面是感知性能；不是非要你的數(shù)字告訴你，而是一個(gè)站點(diǎn)感覺(jué)起來(lái)有多快。
當(dāng)顯示大的JPG圖像時(shí)，可能你對(duì)它的一頓一頓的下載再熟悉不過(guò)；圖像傳輸一百個(gè)像素，停頓，再五十個(gè)，停頓，突然一下子再兩百個(gè)像素，整個(gè)圖像加載完畢。
這是JPG圖像的傳統(tǒng)的工作基準(zhǔn)，真的是一種非?？ǖ捏w驗(yàn)。通過(guò)切換到漸進(jìn)的JPGs，你能使它們以一種更優(yōu)異的流行方式加載；它們首次顯示的是整個(gè)圖像，但像素不是很清晰，然后慢慢的聚焦。這聽(tīng)起來(lái)比前面的方法要糟糕，但它感覺(jué)起來(lái)更快；用戶立即就有東西可看，而且圖像的質(zhì)量逐漸的提高。典型的這些圖像要比它們的基準(zhǔn)副本大一點(diǎn)，但是卻使整個(gè)體驗(yàn)感覺(jué)快了許多。
啟用漸進(jìn)的JPGs，你只要簡(jiǎn)單的在Photoshop中為web與設(shè)備保存圖像時(shí)，檢查一下相關(guān)的復(fù)選項(xiàng)
本文來(lái)源于成都網(wǎng)站建設(shè)公司與成都網(wǎng)站設(shè)計(jì)制作公司-創(chuàng)新互聯(lián)成都公司！
關(guān)于性能，有一些知識(shí)在所有的設(shè)計(jì)師和前端開(kāi)發(fā)者中廣為傳播。例如，盡可能少的請(qǐng)求，優(yōu)化圖片，把樣式表(stylesheets)放在<head>, 把JS放在</body>之前, 最小化(minifying) JS 和 CSS 等等。這些基礎(chǔ)知識(shí)已經(jīng)被用來(lái)加快用戶響應(yīng)了，但還有更多更多需要學(xué)習(xí)。
雖然在我們每天的工作生活中，瀏覽器給我們制造麻煩，使我們頭疼，但請(qǐng)記住，他們也是很聰明的; 它們?yōu)槲覀冏隽撕芏嘈阅軆?yōu)化工作, 所以大量的性能調(diào)優(yōu)知識(shí)不但要知道瀏覽器在哪里給我們做了優(yōu)化，還要知道怎么更好的挖掘它們。大量性能調(diào)優(yōu)訣竅只是理解，利用和操縱瀏覽器已經(jīng)替我們做好的優(yōu)化工作。
頂部的Styles, 底部的scripts
這真的是一條基本規(guī)則，每個(gè)人都能非常容易的在大多數(shù)時(shí)間遵守，但為什么它重要？簡(jiǎn)短的說(shuō)：
CSS 塊渲染, 因此你需要立即處理它（即在文檔的頂部，在你的<head>之中）。 JS 塊下載, 因此你需要最后處理它們，以確保它們沒(méi)有耽誤頁(yè)面中任何其它東西。 CSS塊渲染是因?yàn)闉g覽器總是試圖漸進(jìn)式的渲染頁(yè)面；它們想在元素到達(dá)的時(shí)候順序的渲染它。如果style在距離很遠(yuǎn)的頁(yè)面下部，瀏覽器在獲得它之前沒(méi)有辦法渲染那個(gè)CSS。因?yàn)檫@個(gè)原因，如果瀏覽器在渲染文檔過(guò)程中，改變了之前渲染的東西，它們可以避免style的重繪。瀏覽器在它獲得所有需要的style信息之前不會(huì)渲染頁(yè)面，如果你將style放在文檔底部，你就是在使瀏覽器等待，阻塞了渲染。
所以，只要你將CSS放在頁(yè)面的頂部，那么瀏覽器就可以立刻開(kāi)始渲染。
JavaScript塊下載是由于好幾個(gè)原因（這又是瀏覽器聰明之處），但首先我們需要知道瀏覽器里的資源下載是如何實(shí)際發(fā)生的；簡(jiǎn)單的說(shuō)，瀏覽器會(huì)從一個(gè)單一的域名并行的盡可能多的下載資源。它從越多的域名下載，就能在一瞬間并行的獲得更多的資源。
JavaScript中斷了這個(gè)過(guò)程，阻塞了從任何一個(gè)域名的并行的下載，因?yàn)椋?br />
被調(diào)用的腳本可能改變頁(yè)面，即瀏覽器在繼續(xù)別的事情以前，將不得不處理它。因此為了處理那個(gè)不測(cè)事件，瀏覽器停止了任何其它東西的下載，以便集中精力關(guān)注于它。 腳本正常工作經(jīng)常需要依照一定的順序加載，例如，要在加載一個(gè)插件之前加載jQuery。瀏覽器阻止了JavaScript的并行下載，因此它不會(huì)同時(shí)下載jQuery和你的插件；很顯然如果你同時(shí)并行下載二者，你的插件會(huì)在jQuery之前到達(dá)。 所以，由于瀏覽器在獲取JavaScript的時(shí)候停止了所有其他下載，將你的JavaScript腳本放在文檔中盡可能晚加載的地方是一個(gè)好主意。我相信你們都看到過(guò)頁(yè)面中的空白片段，在那里第三方的JS腳本被花時(shí)間加載，并且它還阻止了頁(yè)面其他資源的獲取和渲染；這就是JavaScript的阻塞在作用了。
但是顯然，現(xiàn)代瀏覽器還是變得聰明了。我將給你一個(gè)Andy Davies寄給我的電子郵件的摘錄，因?yàn)樗忉尩谋任仪宄?br />
現(xiàn)代瀏覽器將并行下載JS，只有在腳本被執(zhí)行的時(shí)候阻塞渲染（顯然腳本必須也被下載了）。腳本下載常常被瀏覽器的預(yù)加載器所完成。當(dāng)瀏覽器頁(yè)面渲染被阻塞，即等待CSS，或JS被執(zhí)行，預(yù)分析器將掃描頁(yè)面剩余部分，尋找它能下載的資源。有些瀏覽器如 Chrome, 將分先后下載資源，例如，如果腳本與圖片同時(shí)在等待下載，它將先下載腳本。
漂亮的內(nèi)容！
所以，要使頁(yè)面被盡可能快的渲染，將styles放在頂部。為了阻止JS的阻塞影響到渲染，將scripts放在底部。
更少的請(qǐng)求
另一個(gè)明顯而基本的性能優(yōu)化方法是少下載。頁(yè)面需要的每一個(gè)資源就是一次額外的HTTP請(qǐng)求；瀏覽器不得不停下來(lái)去獲取每一個(gè)用于渲染頁(yè)面所需的資源。每一次HTTP請(qǐng)求都可能引發(fā)DNS查詢，重定向，404，等等。每一次HTTP請(qǐng)求，無(wú)論為了樣式表，圖片，web字體，JS文件還是其它你能想到的，都可能是一次非常昂貴的操作。盡量減少這些請(qǐng)求是你可以做的最快的優(yōu)化方法中的一種.
再談到瀏覽器和并行；大多數(shù)瀏覽器一次只從每個(gè)引用的域下載一些資源，而JS會(huì)阻塞這些下載。所以，你做的每一個(gè)HTTP請(qǐng)求都應(yīng)該仔細(xì)考慮，而不是隨便隨便做的。
盡可能并行
為了讓瀏覽器能并行的下載更多資源，你可以由不同的域名提供服務(wù)。如果說(shuō)，瀏覽器只能一次從一個(gè)域名獲取兩個(gè)資源，那么由兩個(gè)域名提供服務(wù)意味著它可以一次性獲取四個(gè)資源；三個(gè)域名意味著六個(gè)并行下載。
許多網(wǎng)站有靜態(tài)/資源 域名；你可以發(fā)現(xiàn)， Twitter, 用 si0.twimg.com 來(lái)做靜態(tài)資源：
1 <link rel="stylesheet" type="text/css" media="screen">
Facebook 用fbstatic-a.akamaihd.net：
1 <link rel="stylesheet" >
通過(guò)這些靜態(tài)的資源域名， Twitter與Facebook能提供更多的并行資源服務(wù)；來(lái)自twitter.com和si0.twimg.com的資源可以協(xié)作方式下載。這真的是使你的頁(yè)面上獲得更多并發(fā)下載的簡(jiǎn)單方法，如果再加上實(shí)際的CDN技術(shù)就會(huì)更好，CDN技術(shù)通過(guò)從一個(gè)更加合適的物理位置提供資源服務(wù)的方法來(lái)減少延遲。
這全部都很好，但后面我們將討論在特定環(huán)境下，怎樣從子域名提供服務(wù)卻會(huì)實(shí)際上對(duì)性能有害。
因此，現(xiàn)在有了我們關(guān)于性能的基礎(chǔ)知識(shí)：
將樣式表放在文檔的頂部 將JavaScript放在底部（可能的地方） 盡可能減少HTTP請(qǐng)求 從多個(gè)域名提供資源服務(wù)能增加瀏覽器并行下載的資源數(shù)量。 HTTP 請(qǐng)求與 DNS 查詢
每當(dāng)你從任何域名請(qǐng)求一個(gè)資源，會(huì)發(fā)出一個(gè)帶有相關(guān)頭部，被訪問(wèn)資源的 HTTP請(qǐng)求，并且會(huì)返回一個(gè)響應(yīng)。這是對(duì)該過(guò)程的一個(gè)極端簡(jiǎn)化，但它基本就是事實(shí)上你需要知道的。這是一個(gè)HTTP請(qǐng)求，而且所有涉及的資源都從屬于這個(gè)往返的旅行。當(dāng)提到前端性能，這些請(qǐng)求正是主要的瓶頸所在，因?yàn)槿缥覀冋劦降模瑸g覽器受限于有多少請(qǐng)求可以并行發(fā)生。這也是為什么我們經(jīng)常要使用子域名；以便允許這些請(qǐng)求在數(shù)個(gè)域名上發(fā)生，允許同時(shí)發(fā)生多得多數(shù)量的請(qǐng)求。
然而關(guān)于這還有個(gè)問(wèn)題，DNS查詢。每次（從一個(gè)空緩存）一個(gè)新的域名被引用，HTTP請(qǐng)求會(huì)受制于一個(gè)耗時(shí)的DNS查詢（某個(gè)介于20到120毫秒之間的值），在DNS查詢中，發(fā)出的請(qǐng)求會(huì)查詢資源實(shí)際存在的地點(diǎn)；互聯(lián)網(wǎng)通過(guò)IP地址被綁定在一起，這些地址由DNS管理的主機(jī)名引用。
如果每個(gè)引用的新域名具有DNS查詢的前端代價(jià)，你必須確保這個(gè)代價(jià)確實(shí)是值得的。如果是一個(gè)小網(wǎng)站（例如像CSS魔法），那么由子域名提供資源可能并不值得；相比執(zhí)行多個(gè)域名的DNS查詢并將其并行化來(lái)說(shuō)，從一個(gè)域名非并行的獲取若干資源，瀏覽器可能更快。
如果你或許有一打資源，你可能會(huì)考慮從一個(gè)子域名提供它們的資源服務(wù)；為了更好的并行化那許多資源，額外的DNS查詢可能是值得的。如果說(shuō)你有40個(gè)資源，可能將那些資源切分到兩個(gè)子域名是值得的；為了由總數(shù)為三個(gè)的域名提供你的網(wǎng)站服務(wù)，兩個(gè)額外的DNS查詢會(huì)是值得的。
DNS查詢代價(jià)很高，因此你需要決定什么才是對(duì)你的網(wǎng)站更合適的；承擔(dān)查詢的消耗或者只是由一個(gè)域名提供所有服務(wù)。
很重要的需要記得的是，比方說(shuō)一旦HTML被請(qǐng)求于foo.com，對(duì)那個(gè)主機(jī)的DNS查詢就立即發(fā)生了，所以后續(xù)的任何對(duì)foo.com的請(qǐng)求不再受制于DNS查詢。
DNS 預(yù)取
如果你像我一樣想在網(wǎng)站上有一個(gè)Twitter小程序，還有網(wǎng)站分析，再也許一些網(wǎng)頁(yè)字體，那么你必須要鏈接到一些其它域名，這意味著你將不得不引發(fā)DNS查詢。我的建議通常是，不要還沒(méi)有先適當(dāng)?shù)目紤]性能影響就使用某個(gè)或任何一個(gè)小程序，但對(duì)于你認(rèn)為確實(shí)需要的，下面的將很有用……
因?yàn)檫@些東西都存在于其它域名，比方說(shuō)這就意味著你的網(wǎng)站字體CSS將會(huì)同你自己的CSS并行下載，從某種意義上說(shuō)是一種好處，但是腳本將仍會(huì)阻塞（除非它們是異步的）
事實(shí)上，這里的問(wèn)題是DNS查詢牽涉到了第三方域名。幸運(yùn)的是，有一個(gè)相當(dāng)快又簡(jiǎn)單的辦法來(lái)加速這個(gè)過(guò)程：DNS預(yù)取。
DNS預(yù)取所做的恰恰就是憑證領(lǐng)餐(on the tin)，它不能被簡(jiǎn)單實(shí)現(xiàn)。比方說(shuō)，如果你需要請(qǐng)求來(lái)自widget.foo.com的資源，那么你可以通過(guò)簡(jiǎn)單的在頁(yè)面的<head>里先增加下面這個(gè)來(lái)預(yù)取那個(gè)主機(jī)的DNS：
1 2 3 4 5 <head> ... <link rel="dns-prefetch" > ... </head>
那行簡(jiǎn)單的內(nèi)容將會(huì)告訴支持的瀏覽器去開(kāi)始預(yù)取那個(gè)域名的DNS，這要稍稍早于它實(shí)際需要的時(shí)刻。它意味著DNS查詢過(guò)程，在瀏覽器<script>元素真正請(qǐng)求小程序的時(shí)候就已經(jīng)在進(jìn)行中了。這僅僅給瀏覽器增加了一個(gè)很小的開(kāi)頭。
這種簡(jiǎn)單的鏈接元素（就是我在CSS魔法上用到的）完全后向兼容，而且不會(huì)忽略性能影響。將它看作是性能提升增強(qiáng)吧！
延伸閱讀
通過(guò)預(yù)取加速你的網(wǎng)站 資源預(yù)取
和DNS預(yù)取一樣，也可以順便對(duì)你的站點(diǎn)需要的其它資源進(jìn)行預(yù)取。為了弄清楚我們想要預(yù)取哪些資源， 首先我們需要了解瀏覽器通常會(huì)在什么時(shí)候以什么方式對(duì)資源發(fā)出請(qǐng)求。
CSS中引用的Web字體和圖片表現(xiàn)基本相同；瀏覽器在碰到需要它們的HTML時(shí)開(kāi)始對(duì)它們進(jìn)行下載。就和我在前面提到那樣，瀏覽器非常聰明，這又是一個(gè)例證。想象一下，瀏覽器一看到下面的CSS聲明就開(kāi)始下載其中所引用的圖片：
1 2 3 4 .page--home { background-image:url(home.jpg); } .page--about { background-image:url(about.jpg); } .page--portfolio { background-image:url(portfolio.jpg); } .page--contact { background-image:url(contact.jpg); }
如果瀏覽器不是等碰到需要這些圖片的HTML再下載它們，那么訪問(wèn)主頁(yè)就會(huì)立即下載所有這四個(gè)圖片。這會(huì)造成浪費(fèi)，所以瀏覽器一定會(huì)確保在需要這些圖片時(shí)才會(huì)開(kāi)始下載它們。所以，這里有個(gè)問(wèn)題在于，圖片下載直到很晚才會(huì)開(kāi)始。
如果我們可以完全確認(rèn)某個(gè)CSS圖片肯定會(huì)在每個(gè)頁(yè)面都會(huì)用到的話，我們就可以用個(gè)小把戲讓瀏覽器早早下載好這個(gè)圖片，無(wú)需等到讓瀏覽器碰到需要使用該圖片的HTML才開(kāi)始下載。想做到這一點(diǎn)也非常簡(jiǎn)單，但所用的方法可能會(huì)有點(diǎn)糙，就看你怎么弄了。
比較糙的方法和大多數(shù)笨拙的萬(wàn)全之法類(lèi)似，就是在每個(gè)頁(yè)面放置一個(gè)隱藏的<div>，在該div中使用帶有空的alt屬性的<img>標(biāo)簽。我在CSS Wizardry項(xiàng)目中的精靈中就是這么干的；因?yàn)槲抑?，每個(gè)頁(yè)面都要使用該精靈，所以我就通過(guò)在HTML中對(duì)其進(jìn)行引用對(duì)它進(jìn)行預(yù)取。瀏覽器處理內(nèi)聯(lián)（inline）<img>的方式非常好，瀏覽器會(huì)早早地對(duì)它們進(jìn)行預(yù)取，所以通過(guò)讓瀏覽器將我的精靈作為HTML中的<img>進(jìn)行載入，瀏覽器就可以在使用需要精靈的CSS之前將其下載好。通過(guò)首先在我的HTML中引用該精靈（隱藏起來(lái)的），我就能夠搶先把精靈下載好。
還有第二種方法比較”優(yōu)雅”，但會(huì)讓人有些困惑。它和DNS預(yù)取的例子非常相似
1 <link rel="prefetch" href="sprite.png">
這會(huì)顯式地告訴瀏覽器，馬上開(kāi)始預(yù)取我的精靈圖片，而不要考慮在它處理CSS時(shí)可能會(huì)做的任何決定。
令人感到困惑之處在于有兩篇文章似乎有不同的觀點(diǎn)；基于來(lái)自MDN的這篇文章，貌似這種預(yù)取指令只是示意瀏覽器僅在它空閑時(shí)才有可能會(huì)對(duì)href所指的資源進(jìn)行預(yù)取。然而，與此矛盾的是，來(lái)自Planet Performance的這篇文章貌似在說(shuō)，如果瀏覽器支持rel=”prefetch”的話，它就一定會(huì)預(yù)取href中所指的資源，并沒(méi)有提及是否要在瀏覽器空閑時(shí)才進(jìn)行預(yù)取。我在WebKit的Inpsector中的瀑布圖中所看到的情況是后者說(shuō)得是對(duì)的，但是在打開(kāi)Developer Tools的情況下（薛定諤測(cè)不準(zhǔn)。。。）WebKit的表現(xiàn)及其怪異，我就觀察不到預(yù)取動(dòng)作的情況了，這也就是我說(shuō)，我無(wú)法100%保證我說(shuō)的是對(duì)的。要是誰(shuí)能解釋清楚這方面的情況，我將不勝感激。
我在前面說(shuō)過(guò)，字體和圖片表現(xiàn)非常相似，上面所說(shuō)的規(guī)則同樣也適用于字體文件，但你無(wú)法使用隱藏的<div>載入字體文件（你需要使用預(yù)取link）。
1 <link rel="prefetch" href="webfont.woff">
所以，基本可以這么說(shuō)，我們這里所作的一切，只能算是讓瀏覽器提前下載資源的”小把戲”而已，耍了小把戲之后，在瀏覽器碰到要使用CSS的時(shí)候，其中所引用的資源就早已下載好了（或者至少已經(jīng)在下載中了）。 漂亮極了！
延伸閱讀
采用預(yù)取來(lái)加速你的網(wǎng)站 CSS 與性能
許多建議說(shuō)，如果你在使用資源域名，你應(yīng)該由它們提供所有靜態(tài)資源服務(wù)；包括CSS，JS，圖片等等。
但是在工作中我們發(fā)現(xiàn)一件事，那就是你不應(yīng)該由一個(gè)資源/子域名提供CSS服務(wù)…
還記得先前我們討論CSS塊渲染嗎？瀏覽器想盡可能快的獲得CSS，直到不能更快；CSS位于你的關(guān)鍵路徑。你的關(guān)鍵路徑是用戶頁(yè)面請(qǐng)求與之后實(shí)際看到頁(yè)面之間的必要的旅程。因?yàn)樗枞虽秩?，所以CSS位于關(guān)鍵路徑，而JS和圖片不是。你會(huì)希望在關(guān)鍵路徑上盡可能快的加快這個(gè)旅程，這就意味著不能有DNS查詢。
實(shí)際工作中，我們搭建了一個(gè)網(wǎng)站，在某個(gè)階段性的環(huán)境中它由同一臺(tái)主機(jī)（如foo.com）提供資源服務(wù)，但到了使整個(gè)環(huán)境支持更加繁忙業(yè)務(wù)的時(shí)候，我們開(kāi)始由s1.foo.com與s2.foo.com提供資源服務(wù)。這意味著所有的圖片，JS，CSS，字體等等都來(lái)自于不同的域名，由此便引起了DNS查詢。這里的問(wèn)題在于，由于空的緩存，為了獲得CSS文件而需要執(zhí)行DNS查詢，這實(shí)際上使得關(guān)鍵路徑速度徹底慢下來(lái)。我們的圖片大多數(shù)會(huì)模糊，這暗示著有理論上不應(yīng)該有的延時(shí)；最佳實(shí)踐要求應(yīng)該將資源分布于在子域名上，對(duì)嗎？但不包括CSS。DNS查詢占據(jù)了大量的時(shí)間，進(jìn)而延遲了頁(yè)面的渲染。
因?yàn)橛羞@種渲染阻塞階段，CSS是性能最壞的敵人之一，正如Stoyan Stefanov闡述的那樣 。而且也很有必要注意到瀏覽器在它開(kāi)始渲染頁(yè)面之前將下載所有的CSS。這意味著即使瀏覽器僅僅在屏幕上渲染頁(yè)面，也要請(qǐng)求print.css。任何只是基于一種媒體查詢的樣式表（如<link rel=”stylesheet” media=”screen and (min-device-width: 800px)” href=”desktop.css”>）都將會(huì)被下載，即使并不需要它們。
即便如此，Andy Davies 告知我WebKit實(shí)際上提高了CSS下載的優(yōu)先級(jí)，以便只有渲染頁(yè)面需要的CSS先到達(dá)，而其他的樣式，如print.css盡可能的延遲。漂亮！
知道這些關(guān)于CSS的信息已經(jīng)允許我們做出一些決定，這些決定全部基于CSS阻塞渲染，要全部被請(qǐng)求，以及它位于關(guān)鍵路徑的知識(shí)：
永遠(yuǎn)不要從一個(gè)固定/資源域名提供服務(wù) 因?yàn)檫@會(huì)引起DNS查詢并進(jìn)一步延遲渲染。 先提供服務(wù) 因此瀏覽器可以繼續(xù)忙下去。 合并它 因?yàn)椴还茉鯓訛g覽器會(huì)獲取所有CSS，你最好將所有這些壓縮于一個(gè)HTTP請(qǐng)求。 壓縮并簡(jiǎn)化它 以便瀏覽器需要下載的少一些。 緩存它的一切 以便上述的過(guò)程盡可能少的發(fā)生。 CSS位于關(guān)鍵路徑，因此你需要盡早先解決它，它阻塞渲染就意味著降低了用戶的性能體驗(yàn)。 把CSS移到子域名會(huì)損害性能。
延伸閱讀
CSS與關(guān)鍵路徑 壓縮與簡(jiǎn)化
對(duì)于你的文本資源，有兩個(gè)實(shí)在很簡(jiǎn)單的事情是你能（而且也應(yīng)該）做的；簡(jiǎn)化他們移除任何注釋和空格，并且進(jìn)一步的壓縮它們大小。
如果你想選擇其一，單獨(dú)的壓縮要比單獨(dú)的簡(jiǎn)化更有效。然而，如果可能的話你應(yīng)該兩個(gè)都做。
實(shí)施壓縮經(jīng)常需要一點(diǎn).htaccess詭計(jì)，但如我的好朋友 Nick Payne指出的，.htaccess實(shí)際上從服務(wù)端的觀點(diǎn)來(lái)看不是特別有性能；.htaccess評(píng)估每一個(gè)到達(dá)請(qǐng)求，因此實(shí)際它有很多開(kāi)銷(xiāo)。
這取自 Apache 文檔 ：
你應(yīng)該完全避免使用.htaccess文件，如果你可以直接訪問(wèn)http主服務(wù)器的配置文件的話。 使用.htaccess文件使你的Apache http server慢下來(lái)。任何你能包含進(jìn)一個(gè).htaccess文件的指令最好設(shè)置在一個(gè)字典 塊,因?yàn)樗哂型瑯拥男в貌⑶矣懈玫男阅堋?br />
如果你確實(shí)只是訪問(wèn).htaccess，那么我不會(huì)擔(dān)心；這個(gè)開(kāi)銷(xiāo)的代價(jià)通常無(wú)需關(guān)心。實(shí)際上通過(guò).htaccess來(lái)壓縮實(shí)現(xiàn)起來(lái)很簡(jiǎn)單。而簡(jiǎn)化不是那么容易，除非你有一個(gè)構(gòu)建過(guò)程，或者用一些類(lèi)似代碼工具套件，或者能直接編譯輸出最小化的預(yù)處理器。
有趣的是，我移動(dòng)inuit.css到Sass的主要原因最初是——我可以方便的編譯一個(gè)簡(jiǎn)化的版本。
簡(jiǎn)化（Minification）最主要的部分是簡(jiǎn)單的刪除空格與注釋?zhuān)蝗绻阍诖a中寫(xiě)的注釋像我一樣多，那么你確實(shí)需要縮減你的資源。
像任何壓縮算法一樣，壓縮（Gzip）將任何基于文本的輸入，基于重復(fù)的/可重復(fù)的字符串對(duì)其進(jìn)行壓縮。通過(guò)gzip大多數(shù)代碼壓縮得很好，因?yàn)樗写a都有包含重復(fù)字符串的傾向;例如CSS中一遍又一遍的background-image，標(biāo)簽中一遍又一遍的<strong>…
壓縮真的大量的壓榨掉資源的大小，你應(yīng)該明確的啟用它。為了能有規(guī)范的.htaccess片段，查閱 HTML5 樣板處理資源 。
壓縮內(nèi)容引起大量的節(jié)約。在寫(xiě)操作的時(shí)候，inuit.css 輸入有77k大小。壓縮以后只有5.52k。簡(jiǎn)化與壓縮給我們節(jié)省了93%。而且因?yàn)間zip對(duì)基于文本的資源工作的很好，你甚至可以壓縮可縮放矢量圖形（SVGs）和一些字體格式文件！
優(yōu)化圖像
相比通過(guò)優(yōu)化工具運(yùn)行而言，我對(duì)優(yōu)化圖像的藝術(shù)不是非常的知識(shí)廣博，但通過(guò)圖像自身，后加工來(lái)解決是一個(gè)相當(dāng)有趣的話題。
Spriting (精靈)
如果想要一個(gè)性能優(yōu)異的網(wǎng)站，Sprites（精靈，一種網(wǎng)頁(yè)圖片應(yīng)用處理方式，它允許你將一個(gè)頁(yè)面涉及到的所有零星圖片都包含到一張大圖中去）是幾乎強(qiáng)制性的；在一個(gè)HTTP請(qǐng)求里加載一個(gè)大的圖片，而不是若干個(gè)請(qǐng)求若干個(gè)圖片。但是問(wèn)題在于，不是所有的圖片都可以立即精靈化；可能你有一個(gè)圖標(biāo)，需要將它作為一個(gè)彈性寬度元素的背景圖像，但你顯然不能將其精靈化，因?yàn)閟prites對(duì)非固定尺寸元素不起作用。你通常只要在sprite表中的圖像周?chē)旁S多空格，但這樣在sprite中浪費(fèi)像素它們自己就影響到性能了。
為了解決特定元素的不可精靈化，我們需要一種稱(chēng)為”精靈元素”的東西。這基本是一個(gè)空元素，一般是一個(gè)<i>，它的核心工作就是保持空并且加載一個(gè)背景圖像。
在我創(chuàng)建Sky Bet時(shí)我用過(guò)這些，YouTube用它們, Facebook用它們， Jonathan Snook 有 一篇SMACSS的文章整個(gè)章節(jié)都關(guān)于他們。
基本的前提是，如果因?yàn)橐粋€(gè)元素是流態(tài)的而不能精靈化，那么你在它里面放置一個(gè)空元素解決尺寸的問(wèn)題，然后就可以精靈化了，例如：
1 2 3 4 5 <li> <a href="/profile/"> <i></i> Profile </a> </li>
這里我們不能精靈化<li>或者<a>，所以我們?cè)谀抢镉幸粋€(gè)空的<i>，它替代加載圖標(biāo)。這是關(guān)于性能我最喜歡的事情之一；你正將聰明的技術(shù)整合來(lái)改善頁(yè)面速度，卻仍然在使用傳統(tǒng)的”壞”標(biāo)記。有趣的定西！
延伸閱讀
Sprite還是不要Sprite 視網(wǎng)膜圖像
你不需要將所有都提高到視網(wǎng)膜級(jí)別。在標(biāo)準(zhǔn)分辨率下，同樣的圖像放大2倍將包含四倍數(shù)量的像素。四倍啊。然而這并不意味著需要通過(guò)連接傳輸四倍的文件大小——感謝圖片自身的編碼格式——也就是說(shuō)一旦圖像解壓并在瀏覽器中渲染，有四倍數(shù)量于平常的像素需要存儲(chǔ)于內(nèi)存。
如果停下來(lái)思考一下；視網(wǎng)膜圖像最常（即使不是總是）需要用于給手機(jī)提供一個(gè)保真的UI。手機(jī)內(nèi)存比其他設(shè)備少很多。視網(wǎng)膜效果給內(nèi)存并不很多的設(shè)備提供了消耗內(nèi)存的圖像……反復(fù)全面的考慮一下你是真的需要視網(wǎng)膜圖像，或者還是你可以做出一個(gè)明智的妥協(xié)？
視網(wǎng)膜效果是一種很棒的，清晰的體驗(yàn)，但如果需要5秒鐘時(shí)間下載的話，將不會(huì)有清爽的體驗(yàn)。在大多數(shù)情形速度要?jiǎng)龠^(guò)美感。
為了給每個(gè)人提供足夠好的圖片，你可以很聰明的給所有設(shè)備提供1.5倍的圖像，但就我的觀點(diǎn)——最好的選擇是節(jié)儉的使用視網(wǎng)膜。
如果統(tǒng)計(jì)數(shù)據(jù)表明有足夠富余，你就可以針對(duì)矢量圖形優(yōu)化，或者用字體圖標(biāo)代替位圖。在CSS魔法網(wǎng)站我使用了矢量圖形，這給我?guī)?lái)了如下好處：
分辨率無(wú)關(guān) 可簡(jiǎn)化 可壓縮 在工作中 Matt Allen 給我們做了一種字體圖標(biāo)，可以同主要元素一起使用提供一種準(zhǔn)視網(wǎng)膜的，可伸縮的圖標(biāo)。
你也可以看看怎樣使用類(lèi)似ReSRC.it的服務(wù)，以便基于設(shè)備與上下文加載圖片。
漸進(jìn)的 JPGs
性能的一個(gè)有趣的方面是感知性能；不是非要你的數(shù)字告訴你，而是一個(gè)站點(diǎn)感覺(jué)起來(lái)有多快。
當(dāng)顯示大的JPG圖像時(shí)，可能你對(duì)它的一頓一頓的下載再熟悉不過(guò)；圖像傳輸一百個(gè)像素，停頓，再五十個(gè)，停頓，突然一下子再兩百個(gè)像素，整個(gè)圖像加載完畢。
這是JPG圖像的傳統(tǒng)的工作基準(zhǔn)，真的是一種非?？ǖ捏w驗(yàn)。通過(guò)切換到漸進(jìn)的JPGs，你能使它們以一種更優(yōu)異的流行方式加載；它們首次顯示的是整個(gè)圖像，但像素不是很清晰，然后慢慢的聚焦。這聽(tīng)起來(lái)比前面的方法要糟糕，但它感覺(jué)起來(lái)更快；用戶立即就有東西可看，而且圖像的質(zhì)量逐漸的提高。典型的這些圖像要比它們的基準(zhǔn)副本大一點(diǎn)，但是卻使整個(gè)體驗(yàn)感覺(jué)快了許多。
啟用漸進(jìn)的JPGs，你只要簡(jiǎn)單的在Photoshop中為web與設(shè)備保存圖像時(shí)，檢查一下相關(guān)的復(fù)選項(xiàng)
本文來(lái)源于成都網(wǎng)站建設(shè)公司與成都網(wǎng)站設(shè)計(jì)制作公司-創(chuàng)新互聯(lián)成都公司！
網(wǎng)頁(yè)標(biāo)題：網(wǎng)頁(yè)設(shè)計(jì)師和前端開(kāi)發(fā)者看的前端性能優(yōu)化
標(biāo)題URL：http://www.muchs.cn/news43/314493.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計(jì)公司、網(wǎng)站收錄、品牌網(wǎng)站建設(shè)、自適應(yīng)網(wǎng)站、網(wǎng)頁(yè)設(shè)計(jì)公司、網(wǎng)站設(shè)計(jì)
聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容
- 聘請(qǐng)成都網(wǎng)站建設(shè)設(shè)計(jì)公司制作網(wǎng)站，可以提供什么服務(wù) 2024-01-20
- 成都網(wǎng)站建設(shè)好的公司(成都網(wǎng)站建設(shè)軟件) 2024-01-20
- 通過(guò)互點(diǎn)方式可以提高網(wǎng)站關(guān)鍵詞的排名 2024-01-20
- 了解什么是美國(guó)VPS？您應(yīng)該租用美國(guó)VPS還是越南VPS？ 2024-01-20
- 外貿(mào)網(wǎng)站設(shè)計(jì)大概多少費(fèi)用 2024-01-20
- 移動(dòng)端和PC端的區(qū)別究竟在哪 2024-01-20
- 了解游戲玩家尋找專(zhuān)用服務(wù)器的原因 2024-01-20
- 成都外貿(mào)網(wǎng)站開(kāi)發(fā)多少費(fèi)用 2024-01-20
- 網(wǎng)站制作的鏈接結(jié)構(gòu)對(duì)網(wǎng)站的非常重要 2024-01-20
- 美國(guó)網(wǎng)站服務(wù)器常用的免費(fèi)監(jiān)控工具 2024-01-20
- 網(wǎng)頁(yè)自助建站怎么做好？都要注意什么？ 2024-01-20
- 成都app開(kāi)發(fā)：那些說(shuō)要學(xué)習(xí)Uber的O2O創(chuàng)業(yè)者們?cè)摾潇o一下了！ 2024-01-20
- 做好微信商城制作運(yùn)營(yíng)的重要技巧有哪些 2024-01-20
- 68小說(shuō)網(wǎng)站制作軟件app(東莞模板網(wǎng)站制作軟件) 2024-01-20
- 您了解成都400電話包月業(yè)務(wù)嗎？創(chuàng)新互聯(lián)為您百科??！ 2024-01-20
- 百度快照更新對(duì)網(wǎng)站建設(shè)意味著什么? 2024-01-20
- 七大秘訣幫你設(shè)計(jì)出令人難忘的優(yōu)秀網(wǎng)站 2024-01-20
- 青島網(wǎng)站建設(shè)應(yīng)對(duì)企業(yè)網(wǎng)頁(yè)設(shè)計(jì)的幾個(gè)誤區(qū)？ 2024-01-20
- 移動(dòng)端網(wǎng)站建設(shè)哪些地方重點(diǎn)？(移動(dòng)網(wǎng)站建設(shè)推廣) 2024-01-20