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