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