【51CTO.com快譯】引言：2018年，加載速度和用戶滿意度仍會(huì)是各個(gè)Web應(yīng)用所要面對(duì)的首要問(wèn)題。緩慢的加載時(shí)間和不佳的互動(dòng)體驗(yàn)都可能將客戶推往他處。本文向你提供15個(gè)ASP.NET性能優(yōu)化的小技巧。

對(duì)于ASP.NET的Web應(yīng)用來(lái)說(shuō)性能一直是非常重要的。各種證據(jù)表明，緩慢的加載時(shí)間和不佳的互動(dòng)體驗(yàn)都可能將客戶推往他處。即使是那些對(duì)于用戶來(lái)說(shuō)別無(wú)選擇的內(nèi)部應(yīng)用，他們的滿意度也是會(huì)與速度掛鉤的。

我們可以用很多種方法來(lái)提高網(wǎng)站的性能。在此，讓我們來(lái)看看其中的十五個(gè)。

1.量化一切

首先要做的***件事是收集應(yīng)用程序的性能基線。有時(shí)候，你的本意是想通過(guò)一些修改來(lái)提高網(wǎng)站的性能，但是實(shí)際上性能卻被降低了。雖然談不上是個(gè)黑盒子，但是對(duì)于性能的調(diào)優(yōu)，確實(shí)會(huì)時(shí)常給我們帶來(lái)意想不到的效果。因此，量化性能需要有一個(gè)全面的對(duì)于服務(wù)器、JavaScript和加載效率的衡量。除了手中的秒表，你還需要有諸如Prefix之類(lèi)的各種性能測(cè)試工具（請(qǐng)參見(jiàn)：https://stackify.com/prefix/）。

Prefix能讓你更關(guān)注于低效的查詢，以及大量的JavaScript文件等方面。量化的數(shù)據(jù)會(huì)告訴你，對(duì)于哪些方面的優(yōu)化能夠真正起到作用。你可以自己生產(chǎn)一張列表，并按照優(yōu)先級(jí)進(jìn)行排序。而那些位于列表底部的，則往往是一些重要程度最小、你幾乎可以忽略的方面。

2.先摘下“低垂的水果”

通常情況下，你應(yīng)該優(yōu)先處理上述清單中影響比較大的部分。很明顯，如果你能盡快地向用戶證明性能影響的“痛點(diǎn)”所在，你就能從精神上和資金上獲得更多的優(yōu)化支持，當(dāng)然這也是你不斷進(jìn)行性能調(diào)優(yōu)的動(dòng)力。比如說(shuō)：全局性的因素（如JavaScript、CSS、及其同類(lèi)的加載）都會(huì)比單個(gè)頁(yè)面的修改產(chǎn)生更大的影響。

本文后面介紹的內(nèi)容，將粗略地以影響程度從大到小來(lái)依次展開(kāi)。當(dāng)然，根據(jù)各個(gè)網(wǎng)站的差異性，你可以有所取舍地根據(jù)自身情況來(lái)予以實(shí)踐。

3.啟用壓縮

HTTP協(xié)議并非是一個(gè)特別有效率的協(xié)議。在默認(rèn)情況下，它不會(huì)對(duì)內(nèi)容進(jìn)行壓縮。雖然有些網(wǎng)絡(luò)資源，比如說(shuō)圖片已經(jīng)被壓縮了，但是像HTML、CSS和JavaScript通常還是以文本的形式在進(jìn)行傳輸。就算是最古老的瀏覽器也能支持通過(guò)gzip的算法來(lái)對(duì)HTTP內(nèi)容進(jìn)行壓縮，而且gzip大約能夠壓縮HTML文件的三分之二。也就是說(shuō)：一個(gè)100KB的文件被壓縮后最終至多只有33KB，這比例是相當(dāng)驚人的！

與之對(duì)應(yīng)的另一個(gè)改良算法是Brotli（請(qǐng)參見(jiàn)：https://en.wikipedia.org/wiki/Brotli）。其效果更佳，而且能夠被當(dāng)前大多數(shù)瀏覽器所支持。

4.減少HTTP請(qǐng)求

實(shí)際上，瀏覽器每打開(kāi)和建立一個(gè)與服務(wù)器的連接，都是要“交稅”的。而這個(gè)稅收就是以TCP/IP連接的開(kāi)銷(xiāo)形式來(lái)體現(xiàn)的。這個(gè)現(xiàn)象在那些具有高延遲、并需要花費(fèi)很長(zhǎng)時(shí)間才能建立新連接的情況下，就顯得尤為突然。基于這個(gè)客觀事實(shí)，為了減少HTTP的請(qǐng)求數(shù)量，瀏覽器應(yīng)該將它們的請(qǐng)求限制在單臺(tái)服務(wù)器上，以實(shí)現(xiàn)***程度的優(yōu)化。

延遲與帶寬

我們?cè)趦?yōu)化網(wǎng)頁(yè)的加載時(shí)，理解延遲和帶寬之間的差別是非常必要的。讓我們想象一下：你有20頭驢，你需要從坐落在班芙的一個(gè)集散點(diǎn)轉(zhuǎn)移到另一個(gè)坐落在大峽谷的集散點(diǎn)。為了讓這些驢子能夠盡快地轉(zhuǎn)移過(guò)去，你需要優(yōu)化兩個(gè)方面：你一次性能夠轉(zhuǎn)移的驢子的數(shù)量，和單次轉(zhuǎn)移驢子所需要的時(shí)間。

帶寬就像是你一次性能夠轉(zhuǎn)移的驢子的數(shù)量。在高帶寬的情況下，你可以一次性將多個(gè)驢子放入家畜車(chē)進(jìn)行轉(zhuǎn)移。而在低帶寬的情況下，你只能將一頭驢子放在你那2001年產(chǎn)的本田思域的單個(gè)座位上進(jìn)行轉(zhuǎn)移。

而延遲則是你從班芙到大峽谷，進(jìn)行單次轉(zhuǎn)移驢子所需要的時(shí)間。高延遲意味著沿途有多次延誤，所以減慢了單次的轉(zhuǎn)移時(shí)間。而低延遲則意味著你通宵達(dá)旦地一路狂奔，不會(huì)在任何旅游景點(diǎn)處停車(chē)觀景。因此在理想情況下，你應(yīng)該一次性轉(zhuǎn)移盡可能多的驢子，而且避免沿途上的任何停頓。

封裝

根據(jù)向服務(wù)器請(qǐng)求的資源類(lèi)型不同，我們可以用幾個(gè)不同的方法來(lái)降低請(qǐng)求的數(shù)量。對(duì)于JavaScript，可用類(lèi)似webpack、gulp或grunt的工具將各個(gè)JavaScript腳本捆綁“串聯(lián)”到一起成為一個(gè)單獨(dú)文件。我們也可以使用相同工具里的不同任務(wù)，來(lái)將CSS文件合并為單一文件。

而對(duì)于圖像則有點(diǎn)復(fù)雜。如果你在網(wǎng)站上使用了許多小的圖像，那么就可以使用CSS Spriting的技術(shù)。比如說(shuō)：我們將所有的圖像合并成單獨(dú)的一個(gè)，然后使用CSS的偏移量將圖像進(jìn)行轉(zhuǎn)換，只顯示我們所需要的單個(gè)子圖像。還有其他的一些工具，能夠簡(jiǎn)化該過(guò)程，不過(guò)它們都需要人工的干預(yù)。而另一種可選的方法則是使用icon font。

5. 基于SSL的HTTP/2

HTTP/2是HTTP的新版本，它進(jìn)行了許多非常有用的優(yōu)化。首先，在上面提到壓縮方面，它進(jìn)行了擴(kuò)展，同時(shí)也包含了各種協(xié)議的包頭。更有趣的是，在與服務(wù)器之間的連接上，它使用一種被稱(chēng)為“管道”的機(jī)制，來(lái)傳輸多個(gè)文件。這就意味著：通過(guò)合并文件來(lái)減少HTTP請(qǐng)求的方式在很大程度上已經(jīng)不必要了，而它的效率則更高。

如今，幾乎每一種瀏覽器都能支持HTTP/2。但頗具諷刺意味的是：在服務(wù)器端的支持上卻有著各種限制。例如：在寫(xiě)數(shù)據(jù)的時(shí)候，Azure的Web應(yīng)用程序就不能支持HTTP/2。

不過(guò)，服務(wù)器現(xiàn)在也能夠?qū)W(wǎng)頁(yè)上的內(nèi)容做出智能的決策，并在它們被請(qǐng)求之前就主動(dòng)向下推送資源。因此，如果索引（主）頁(yè)面上包含一個(gè)JavaScript文件的話，它只有在瀏覽器解析了整個(gè)頁(yè)面之后才會(huì)被發(fā)現(xiàn)；而現(xiàn)在的服務(wù)器完全可以根據(jù)指令，在瀏覽器意識(shí)到它之前，就主動(dòng)將該文件傳輸過(guò)去。

因?yàn)樗兄С諬TTP2的瀏覽器都能夠提供HTTPS的服務(wù)，因此SSL自然也是必需支持的技術(shù)之一。

6.縮減文件尺寸

雖然壓縮對(duì)于減少傳輸線路上的數(shù)據(jù)總量來(lái)說(shuō)是一種很好的手段，但是所有的壓縮算法對(duì)于發(fā)送HTML、CSS和JavaScript來(lái)說(shuō)都是無(wú)損的壓縮方式。這就意味著對(duì)compress(x)的結(jié)果進(jìn)行解壓縮--decompress(x)總能得到x。在理解了這一點(diǎn)的基礎(chǔ)上，我們就可以尋求在尺寸上的進(jìn)一步縮減了。舉例而言，如下的JavaScript：

function doSomething(){  
 
    var size_of_something_to_do = 55;  
 
    for (var counter_of_stuff = 0;  
 
        counter_of_stuff < size_of_something_to_do;  
 
        counter_of_stuff++) {  
 
        size_of_something_to_do--;  
 
    }  
 
} 

它在功能上等同于：

function doSomething(){var a=55;for(var b=0;b<a;b++){a--;}} 

由于變量的作用域是完全私有的，因此空白的占位符就顯得沒(méi)有必要了。這個(gè)過(guò)程被稱(chēng)為縮減。與壓縮技術(shù)類(lèi)似，該技術(shù)也可以被應(yīng)用到CSS、甚至是HTML上。

7.優(yōu)先加載CSS

請(qǐng)務(wù)必優(yōu)先加載你網(wǎng)站上的CSS內(nèi)容，而且***放在頁(yè)面的頭部。

要理解這個(gè)原因，你需要先了解瀏覽器是如何實(shí)現(xiàn)其驚人的瀏覽速度的。在下載頁(yè)面的同時(shí)，瀏覽器會(huì)盡快將其從應(yīng)用程序那里得到的內(nèi)容渲染出來(lái)。通常情況下，由于瀏覽器并不知道頁(yè)面上的哪些內(nèi)容是無(wú)效的，因此它只能像玩猜謎游戲那些做出猜測(cè)。

之后，當(dāng)瀏覽器意識(shí)到其猜測(cè)有誤時(shí)，它不得不拋棄之前所做的一切，重新開(kāi)始渲染。其中導(dǎo)致這些返工的一個(gè)原因就是可能要增加新的樣式表。因此，優(yōu)先加載樣式表，就可以避免對(duì)已經(jīng)渲染的元素進(jìn)行返工。

8.***加載JavaScript

JavaScript則是CSS的另一面，應(yīng)當(dāng)***被加載。這是因?yàn)槲覀兿Ｍ?yè)面能夠被盡可快地渲染出來(lái)，而JavaScript則沒(méi)必要在一開(kāi)始就被渲染。用戶通常會(huì)花些時(shí)間來(lái)閱讀頁(yè)面的內(nèi)容，以決定下一步做什么。那么這個(gè)時(shí)間窗口就被用來(lái)在后臺(tái)加載腳本、和顯示頁(yè)面上的交互效果了。

不過(guò)，這里需要注意的是：如果你的網(wǎng)站上有大量的JavaScript，例如Angular或React之類(lèi)的應(yīng)用，那么你可能會(huì)發(fā)現(xiàn)***加載JavaScript反而不一定是***的方案。你不妨考慮采用只加載JavaScript的必要部分到bootstrap的應(yīng)用中，并且在后臺(tái)加載更多的JavaScript。如果速度對(duì)你來(lái)說(shuō)非常重要的話，你甚至可以考慮所謂的同構(gòu)或是通用的應(yīng)用程序。因?yàn)樵谶@些應(yīng)用中，各個(gè)頁(yè)面在服務(wù)器端被渲染，然后JavaScript應(yīng)用被附加到已渲染的HTML中，并予以接管。這些應(yīng)用程序具有在加載的過(guò)程中無(wú)縫銜接的速度優(yōu)勢(shì)。

9.縮小圖片

在理想狀態(tài)下，你的網(wǎng)站根本不會(huì)包含任何圖片。通常情況，矢量圖片會(huì)比各種真彩圖片要小許多，因此如果使用inline-SVG和CSS的技巧來(lái)為你的網(wǎng)頁(yè)創(chuàng)建矢量圖的話，效率會(huì)非常高。然而事實(shí)上卻不能完全是這樣，因此，你必需進(jìn)行一些縮小圖片的工作。雖然要搞清楚各種正確的編碼設(shè)置著實(shí)不容易，但是我們可以借助像tinypng之類(lèi)的服務(wù)（請(qǐng)參見(jiàn)https://tinypng.com/）來(lái)達(dá)到目標(biāo)。另外，它的logo是一只非常可愛(ài)的熊貓。

當(dāng)然，也有一些JavaScript構(gòu)建工具的其他插件，可以達(dá)到類(lèi)似的優(yōu)化效果，請(qǐng)參見(jiàn)：https://www.npmjs.com/package/gulp-image-optimization。

10.檢查你的查詢

各種對(duì)象關(guān)系映射（object-relational mappers，ORM）已經(jīng)對(duì)開(kāi)發(fā)人員的生產(chǎn)力起到了提升作用，但它們只是提供了優(yōu)化查詢的一個(gè)抽象層。當(dāng)你可能會(huì)有N+1個(gè)選擇錯(cuò)誤、或是從服務(wù)器獲取了太多的數(shù)據(jù)時(shí)，只有通過(guò)Prefix才能夠突顯具體的次數(shù)。你會(huì)驚奇地發(fā)現(xiàn)通過(guò)使用預(yù)先加載、而非延遲加載，以及檢查各種預(yù)測(cè)值，問(wèn)題就會(huì)變得非常容易解決。當(dāng)然，微軟對(duì)于優(yōu)化實(shí)體框架（Entity Framework，EF）的各種SQL調(diào)用，也有一些獨(dú)到的建議，請(qǐng)參見(jiàn)：https://msdn.microsoft.com/en-us/library/hh949853(v=vs.113).aspx。

11.緩存你的頁(yè)面

通常情況下，你網(wǎng)頁(yè)上的數(shù)據(jù)會(huì)隨著時(shí)間的推移而緩慢發(fā)生變化。比如說(shuō)：在Stack Overflow（譯者注：它是一個(gè)技術(shù)問(wèn)答網(wǎng)站。用戶可以在該網(wǎng)站上免費(fèi)創(chuàng)建主頁(yè)、提交問(wèn)題、瀏覽問(wèn)題、索引相關(guān)內(nèi)容。）上的那些熱點(diǎn)問(wèn)題的頁(yè)面會(huì)實(shí)時(shí)地被更新，但是其數(shù)據(jù)的變化并不夠顯著，不至于觸發(fā)對(duì)數(shù)據(jù)庫(kù)的重新查詢。因此我們沒(méi)有必要去調(diào)整數(shù)據(jù)庫(kù)、并對(duì)復(fù)雜的頁(yè)面進(jìn)行重新渲染，而是可以將該網(wǎng)頁(yè)推送到緩存隊(duì)列中，并使用這些數(shù)據(jù)來(lái)響應(yīng)后續(xù)的請(qǐng)求。

如果你碰巧使用著ASP.NET的MVC緩存，那么一個(gè)action的響應(yīng)就應(yīng)該只是簡(jiǎn)單地添加單一的屬性到action中。

[HandleError] public class HomeController : Controller {  
 
    [OutputCache(Duration=10, VaryByParam="none")]  
 
    public ActionResult Index() {  
 
        return View();  
 
    }  
 
} 

如果你所緩存的頁(yè)面全部?jī)?nèi)容并非是你都需要的，那么請(qǐng)繼續(xù)往下看第12個(gè)技巧。

12.僅緩存頁(yè)面的部分內(nèi)容

你可能只想緩存頁(yè)面的一部分內(nèi)容; 這被俗稱(chēng)為甜甜圈孔洞緩存（donut hole caching）。當(dāng)你在同一頁(yè)上，既有用戶特有的數(shù)據(jù)、又有一般的數(shù)據(jù)時(shí)，這會(huì)是一種非常有用的方法。用戶特有數(shù)據(jù)隨著用戶的不同而改變，而頁(yè)面上的其余部分則對(duì)于所有用戶都是相同的。在MVC 5的應(yīng)用中，這是通過(guò)做局部視圖（請(qǐng)參見(jiàn)：https://visualstudiomagazine.com/articles/2017/05/01/doughnut-hole-caching.aspx）來(lái)實(shí)現(xiàn)的，并且在MVC的核心，我們會(huì)用到緩存標(biāo)簽幫手（請(qǐng)參見(jiàn)：https://www.davepaquette.com/archive/2015/06/03/mvc-6-cache-tag-helper.aspx）。

13.內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）

全球各處都有非常多的內(nèi)容交付網(wǎng)絡(luò)，它們可以通過(guò)離你最近的節(jié)點(diǎn)，將內(nèi)容高速地傳遞到你的面前。

14.縮小你的庫(kù)

如果你正在使用像jQuery之類(lèi)的庫(kù)，那么你可以考慮是否真的會(huì)用到它的所有功能，也許你可以去使用一個(gè)更小、更有針對(duì)性的庫(kù)。比如說(shuō)：Zeptojs就是一個(gè)能夠支持jQuery的很多功能、而又更小的庫(kù)。其他像jQuery UI的庫(kù)，也能為構(gòu)建個(gè)性化的包提供刪減過(guò)的功能。如果你正在使用Augular的話，那么你在對(duì)產(chǎn)品進(jìn)行編譯的時(shí)候，就可以像“搖動(dòng)樹(shù)干”一樣，將那些在你的項(xiàng)目中完全用不到的庫(kù)去除掉。可見(jiàn)這種方式在保留同等功能的情況下，能有效減少傳輸中的數(shù)據(jù)載荷。

15.避免客戶端重定向

***的技巧是避免通過(guò)使用客戶端的重定向。重定向勢(shì)必添加了額外的服務(wù)器跳轉(zhuǎn)的開(kāi)銷(xiāo)。而在諸如蜂窩網(wǎng)絡(luò)這樣高延遲的網(wǎng)絡(luò)中則是完全不可取的。相反地，如果使用服務(wù)器端的重定向，則不會(huì)增加跳轉(zhuǎn)的開(kāi)銷(xiāo)。不過(guò)，此法對(duì)于將用戶重定向到SSL版本的頁(yè)面上卻不太有效果。針對(duì)這種情況，HTTP嚴(yán)格傳輸安全（HTTP Strict Transport Security，HSTS，請(qǐng)參見(jiàn)：https://www.troyhunt.com/understanding-http-strict-transport/）和預(yù)加載正好能夠提供幫助。只要你將網(wǎng)站加入預(yù)加載列表中，就會(huì)被自動(dòng)重定向到相應(yīng)的SSL版網(wǎng)頁(yè)上。

我們希望上述這些技巧能夠有助于提高你的網(wǎng)站性能，以及用戶的滿意度。如果你覺(jué)得我們疏漏了任何技巧的話，請(qǐng)留言為我們添磚加瓦。當(dāng)然，你也可以擴(kuò)展性地閱讀一下Matt Watson的《有關(guān)服務(wù)器和客戶端性能的三大Web優(yōu)化技巧》（https://stackify.com/web-performance-optimization/）。

原文標(biāo)題：15 Simple ASP.NET Performance Tuning Tips，作者:  Simon Timms

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】