摘要：譯文地址譯唯快不破應(yīng)用的個(gè)優(yōu)化步驟前端的逆襲知乎專(zhuān)欄原文地址時(shí)過(guò)境遷，應(yīng)用比以往任何時(shí)候都更具交互性。使用負(fù)載均衡方案我們?cè)谥坝懻摼彺娴臅r(shí)候簡(jiǎn)要提到了內(nèi)容分發(fā)網(wǎng)絡(luò)。換句話(huà)說(shuō)，元素的串形訪問(wèn)會(huì)削弱負(fù)載均衡器以最佳形式

歡迎關(guān)注知乎專(zhuān)欄 —— 前端的逆襲
歡迎關(guān)注我的博客，知乎，GitHub。

譯文地址：【譯】唯快不破：Web 應(yīng)用的 13 個(gè)優(yōu)化步驟 - 前端的逆襲 - 知乎專(zhuān)欄
原文地址：12 Steps to a Faster Web App -- Auth0

時(shí)過(guò)境遷，Web 應(yīng)用比以往任何時(shí)候都更具交互性。搞定性能可以幫助你極大地改善終端用戶(hù)的體驗(yàn)。閱讀以下的技巧并學(xué)以致用，看看哪些可以用來(lái)改善延遲，渲染時(shí)間以及整體性能吧！

優(yōu)化 Web 應(yīng)用是一項(xiàng)費(fèi)勁的工作。Web 應(yīng)用不僅處于客戶(hù)端和服務(wù)器端的兩部分組件當(dāng)中，通常來(lái)說(shuō)也是由多種多樣的技術(shù)棧構(gòu)建而成：數(shù)據(jù)庫(kù)，后端組件（一般也是搭建在不同技術(shù)架構(gòu)之上的），以及前端（HTML + JavaScript + CSS + 轉(zhuǎn)化器）。運(yùn)行時(shí)也是變化多端的：iOS，Android，Chrome，F(xiàn)irefox，Edge。如果你曾經(jīng)工作在一個(gè)不同的單一龐大的平臺(tái)之上，通常情況下性能優(yōu)化只針對(duì)于單一目標(biāo)（甚至只是目標(biāo)的單一版本而已），但是現(xiàn)在的話(huà)你就可能會(huì)意識(shí)到任務(wù)復(fù)雜度要遠(yuǎn)超于此。這就對(duì)了。但這兒也有一些通用的優(yōu)化指南可以大大優(yōu)化一個(gè)應(yīng)用。我們將會(huì)在接下來(lái)的章節(jié)中探討這些指南的內(nèi)容。

一份 Bing 的研究表明，頁(yè)面加載時(shí)間每增加 10ms，網(wǎng)站的年收入就會(huì)減少 25 萬(wàn)美元。 —— Rob Trace 和 David Walp，微軟高級(jí)程序經(jīng)理

優(yōu)化最難的地方就是如何在開(kāi)發(fā)生命周期中最適當(dāng)?shù)臅r(shí)候去做優(yōu)化。Donald Knuth 有一句名言：_「過(guò)早優(yōu)化乃萬(wàn)惡之源」_。這句話(huà)背后的原因非常簡(jiǎn)單：因?yàn)橐徊恍⌒木蜁?huì)浪費(fèi)時(shí)間去優(yōu)化某個(gè) 1% 的地方，但是結(jié)果卻并不會(huì)對(duì)性能造成什么重大影響。與此同時(shí)，一些優(yōu)化還妨礙了可讀性或者是可維護(hù)性，甚至還會(huì)引入新的 Bug。換句話(huà)說(shuō)，優(yōu)化不應(yīng)當(dāng)被認(rèn)為是「意味著得到應(yīng)用程序的最佳性能」，而是「探索優(yōu)化應(yīng)用的_正確的方式_，并得到_最大的效益_」。再換句話(huà)說(shuō)，盲目的優(yōu)化可能會(huì)導(dǎo)致效率的丟失，而收益卻很小。在你應(yīng)用以下技巧的時(shí)候請(qǐng)將此銘記在心。你最好的朋友就是分析工具：找到你可以進(jìn)行通過(guò)優(yōu)化獲得最大程度改善的性能點(diǎn)，而不用損害應(yīng)用開(kāi)發(fā)的進(jìn)程或者可維護(hù)性。

程序員們浪費(fèi)了大量時(shí)間來(lái)思考，或者說(shuō)是擔(dān)憂(yōu)，他們的程序中非關(guān)鍵部分的運(yùn)行速度。并且他們對(duì)于性能的這些嘗試，實(shí)際上卻對(duì)代碼的調(diào)試和維護(hù)有著非常消極的影響。我們應(yīng)當(dāng)忘記那些不重要的性能影響，在 97% 的時(shí)間里都可以這么說(shuō)：過(guò)早優(yōu)化乃萬(wàn)惡之源。當(dāng)然我們也不應(yīng)當(dāng)在那關(guān)鍵的 3% 上放棄我們的機(jī)會(huì)?！?Donald Knuth

JavaScript 應(yīng)用是以源碼形式進(jìn)行分發(fā)的，而源碼解析的效率是要比字節(jié)碼低的。對(duì)于一小段腳本來(lái)說(shuō)，區(qū)別可以忽略不計(jì)。但是對(duì)于更大型的應(yīng)用，腳本的大小會(huì)對(duì)應(yīng)用啟動(dòng)時(shí)間有著負(fù)面的影響。事實(shí)上，寄期望于使用 WebAssembly 而獲得最大程度的改善，其中之一就是可以得到更快的啟動(dòng)時(shí)間。

另一方面，模塊打包則用于將不同腳本打包在一起并放進(jìn)同一文件。更少的 HTTP 請(qǐng)求和單個(gè)文件解析都可以減少加載時(shí)間。通常情況下，多帶帶一種工具就可以處理打包和壓縮。Webpack 就是其中之一。

示例代碼：

function insert(i) {
    document.write("Sample " + i);
}

for(var i = 0; i < 30; ++i) {
    insert(i);
}

結(jié)果如下：

!function(r){function t(o){if(e[o])return e[o].exports;var n=e[o]={exports:{},id:o,loaded:!1};return r[o].call(n.exports,n,n.exports,t),n.loaded=!0,n.exports}var e={};return t.m=r,t.c=e,t.p="",t(0)}([function(r,t){function e(r){document.write("Sample "+r)}for(var o=0;30>o;++o)e(o)}]);
//# sourceMappingURL=bundle.min.js.map

你也可以使用 Webpack 打包 CSS 文件以及合并圖片。這些特性都可以有助于改善啟動(dòng)時(shí)間。研究一下 Webpack 文檔來(lái)做些測(cè)試吧！

資源（特別是圖片）的按需加載或者說(shuō)_惰性加載_，可以有助于你的 Web 應(yīng)用在整體上獲得更好的性能。對(duì)于使用大量圖片的頁(yè)面來(lái)說(shuō)惰性加載有著顯著的三個(gè)好處：

減少向服務(wù)器發(fā)出的并發(fā)請(qǐng)求數(shù)量（這就使得頁(yè)面的其他部分獲得更快的加載時(shí)間）

減少瀏覽器的內(nèi)存使用率（更少的圖片，更少的內(nèi)存）

減少服務(wù)器端的負(fù)載

大體上的理念就是只在必要的時(shí)候才去加載圖片或資源（如視頻），比如在第一次被顯示的時(shí)候，或者是在將要顯示的時(shí)候?qū)ζ溥M(jìn)行加載。由于這種方式跟你建站的方式密切相關(guān)，惰性加載的解決方案通常需要借助其他庫(kù)的插件或者擴(kuò)展來(lái)實(shí)現(xiàn)。舉個(gè)例子，react-lazy-load 就是一個(gè)用于處理 React 惰性加載圖片的插件：

const MyComponent = () => (
  

    Scroll to load images.
    

    
      
    
    (...)

一個(gè)非常好的實(shí)踐范例就像 Goggle Images 的搜索工具一樣。點(diǎn)擊前面的鏈接并且滑動(dòng)頁(yè)面滾動(dòng)條就可以看到效果了。

如果你正在使用 React，Ember，Angular 或者其他 DOM 操作庫(kù)，使用 array-ids（或者 Angular 1.x 中的 track-by 特性）非常有助于實(shí)現(xiàn)高性能，對(duì)于動(dòng)態(tài)網(wǎng)頁(yè)尤其如此。我們已經(jīng)在上一篇程序衡量標(biāo)準(zhǔn)的文章中看到這個(gè)特性的效果了： More Benchmarks: Virtual DOM vs Angular 1 & 2 vs Mithril.js vs cito.js vs The Rest (Updated and Improved!)。

此特性背后的主要概念就是盡可能多地重用已有的節(jié)點(diǎn)。Array ids 使得 DOM 操作引擎可以「知道」在什么時(shí)候某個(gè)節(jié)點(diǎn)可以被映射到數(shù)組當(dāng)中的某個(gè)元素。沒(méi)有 array-ids 或者 track-by 的話(huà)，大部分庫(kù)都會(huì)進(jìn)行重新排序而摧毀已有的節(jié)點(diǎn)并重新創(chuàng)建新的。這就非常損耗性能了。

Caches 是用于存儲(chǔ)那些被頻繁存取的靜態(tài)數(shù)據(jù)的組件，便于隨后對(duì)于這個(gè)數(shù)據(jù)的請(qǐng)求可以更快地被響應(yīng)，或者說(shuō)請(qǐng)求方式更加高效。由于 Web 應(yīng)用是由很多可拆卸的部件組合而成，緩存就可以存在于架構(gòu)中的很多部分。舉例來(lái)說(shuō)，緩存可以被放在動(dòng)態(tài)內(nèi)容服務(wù)器和客戶(hù)端之間，就可以避免公共請(qǐng)求以減少服務(wù)器的負(fù)載，與此同時(shí)改善響應(yīng)時(shí)間。其他緩存可能被放置在代碼里，以?xún)?yōu)化某些用于腳本存取的通用模式，還有些緩存可能被放置在數(shù)據(jù)庫(kù)或者是長(zhǎng)運(yùn)行進(jìn)程之前。

簡(jiǎn)而言之，在 Web 應(yīng)用中使用緩存是一種改善響應(yīng)時(shí)間和減少 CPU 使用的絕佳方式。難點(diǎn)就在于搞清楚哪里才是在架構(gòu)中存放緩存的地方。再一次，答案就是性能分析：常見(jiàn)的瓶頸在哪里？數(shù)據(jù)或者結(jié)果可緩存嗎？他們都太容易失效嗎？這都是一些棘手的問(wèn)題，需要從原理上來(lái)一點(diǎn)一點(diǎn)回答。

緩存的使用在 Web 環(huán)境中富有創(chuàng)造性。比如，basket.js 就是一個(gè)使用_Local Storage_ 來(lái)緩存應(yīng)用腳本的庫(kù)。所以你的 Web 應(yīng)用在第二次運(yùn)行腳本的時(shí)候就可以幾乎瞬間加載了。

如今一個(gè)廣受歡迎的緩存服務(wù)就是亞馬遜的 CloudFront。CloudFront 就跟通常的內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）用途一樣，可以被設(shè)置作為動(dòng)態(tài)內(nèi)容的緩存。

越來(lái)越多的瀏覽器都開(kāi)始支持 HTTP/2。這可能聽(tīng)起來(lái)沒(méi)有必要，但是 HTTP/2 為同一服務(wù)器的并發(fā)連接問(wèn)題帶來(lái)了很多好處。換句話(huà)說(shuō)，如果有很多小型資源需要加載（如果你打包過(guò)的話(huà)就沒(méi)有必要了），在延遲和性能方面 HTTP/2 秒殺 HTTP/1。試試 Akamai 的 HTTP/2 demo，可以在最新的瀏覽器中看到區(qū)別。

性能分析是優(yōu)化任何應(yīng)用程序時(shí)的重要一步。就像介紹中所提到的那樣，盲目嘗試優(yōu)化應(yīng)用經(jīng)常會(huì)導(dǎo)致效率的浪費(fèi)，微不足道的收益和更差的可維護(hù)性。執(zhí)行性能分析是識(shí)別你的應(yīng)用問(wèn)題所在的一個(gè)重要步驟。

對(duì)于 Web 應(yīng)用來(lái)說(shuō)，延遲時(shí)間是最大的抱怨之一，所以你需要確保數(shù)據(jù)的加載和顯示都盡可能得快。Chrome 提供了非常棒的性能分析工具。特別是 Chrome Dev Tools 中的時(shí)間線和網(wǎng)絡(luò)視圖都對(duì)于定位延遲問(wèn)題有著很大的幫助：

時(shí)間線視圖可以幫忙找到運(yùn)行時(shí)間較長(zhǎng)的操作。

網(wǎng)絡(luò)視圖可以幫助識(shí)別出額外的由緩慢請(qǐng)求導(dǎo)致的延遲或?qū)τ谀骋欢它c(diǎn)的串行訪問(wèn)。

正確分析的話(huà)，內(nèi)存則是另一塊可能獲得收益的部分。如果你正在運(yùn)行著一個(gè)擁有很多虛擬元素的頁(yè)面（龐大的動(dòng)態(tài)表格）或者可交互式的元素（比如游戲），內(nèi)存優(yōu)化可以獲得更少的卡頓和更高的幀率。從我們最近的文章 4 Types of Memory Leaks in JavaScript and How to Get Rid Of Them 中，對(duì)于如何使用 Chrome 的開(kāi)發(fā)工具有著進(jìn)一步的深度理解。

CPU 性能分析也可以在 Chrome Dev Tools 中找到?？纯催@篇來(lái)自 Google 官方文檔中的文章 Profiling JavaScript Performance。

找到性能損耗的中心可以讓你有效率地達(dá)到優(yōu)化的目標(biāo)。

對(duì)后端的性能分析會(huì)更加困難。通常情況下，確認(rèn)一個(gè)耗費(fèi)較多時(shí)間的請(qǐng)求可以讓你明確應(yīng)該優(yōu)先分析哪一個(gè)服務(wù)。對(duì)于后端的分析工具來(lái)說(shuō)，則取決于所構(gòu)建的技術(shù)棧。

在大多數(shù)情況下，選擇一個(gè)更優(yōu)的算法，比圍繞著小成本中心所實(shí)現(xiàn)的具體優(yōu)化策略能夠獲得更大的收益。在某種程度上，CPU 和內(nèi)存分析應(yīng)該可以幫你找到大的性能瓶頸。當(dāng)這些瓶頸跟編碼問(wèn)題并不相關(guān)時(shí)，則是時(shí)候考慮考慮不同的算法了。

我們?cè)谥坝懻摼彺娴臅r(shí)候簡(jiǎn)要提到了內(nèi)容分發(fā)網(wǎng)絡(luò)（CDNs）。把負(fù)載分配到不同的服務(wù)器（甚至于不同的地理區(qū)域）可以給你的用戶(hù)提供更好的延遲時(shí)間，但是這條路還很漫長(zhǎng)，特別是在處理很多的并發(fā)連接的時(shí)候。

負(fù)載均衡就跟使用某個(gè) round-robin（循環(huán)）解決方案一樣簡(jiǎn)單，可以基于一個(gè) nginx 反向代理 ，或者基于一個(gè)成熟的分布式網(wǎng)絡(luò)，比如 Cloudflare 或者 Amazon CloudFront。

以上的圖來(lái)自于 Citrix。 為了使負(fù)載均衡真正有效，動(dòng)態(tài)內(nèi)容和靜態(tài)內(nèi)容都應(yīng)該被拆分成易于并發(fā)訪問(wèn)的。換句話(huà)說(shuō)，元素的串形訪問(wèn)會(huì)削弱負(fù)載均衡器以最佳形式進(jìn)行分流的能力。與此同時(shí)，對(duì)于資源的并發(fā)訪問(wèn)可以改善啟動(dòng)時(shí)間。

雖然負(fù)載均衡可能會(huì)很復(fù)雜。對(duì)最終一致性算法不友好的數(shù)據(jù)模型，或者緩存都會(huì)讓事情更加困難。幸運(yùn)的是，大多數(shù)應(yīng)用對(duì)于已簡(jiǎn)化的數(shù)據(jù)集都只需要保證高層次的一致性即可。如果你的應(yīng)用程序沒(méi)有這樣設(shè)計(jì)的話(huà)，就有必要重構(gòu)一下了。

改善 Web 應(yīng)用程序觀感的方式之一，就是減少啟動(dòng)時(shí)間或者減少首頁(yè)渲染時(shí)間。這對(duì)于新興的單頁(yè)面應(yīng)用尤為重要，其需要在客戶(hù)端執(zhí)行大量任務(wù)。在客戶(hù)端做更多事情通常就意味著，在第一次渲染被執(zhí)行之前就需要下載更多的信息。同構(gòu) JavaScript 可以解決這個(gè)問(wèn)題：自從 JavaScript 可以同時(shí)運(yùn)行在客戶(hù)端和服務(wù)器端，這就讓在服務(wù)器端來(lái)執(zhí)行頁(yè)面的首次渲染成為可能，先把已渲染的頁(yè)面發(fā)送出去然后再由客戶(hù)端的腳本接管。這限制了所使用的后端（必須使用支持該特性的 JavaScript 框架），但卻能獲得更好的用戶(hù)體驗(yàn)。舉例來(lái)說(shuō)，React 就很適合于做這個(gè)，就像以下代碼所示：

var React = require("react/addons");
var ReactApp = React.createFactory(require("../components/ReactApp").ReactApp);

module.exports = function(app) {

    app.get("/", function(req, res){
        // React.renderToString takes your component
        // and generates the markup
        var reactHtml = React.renderToString(ReactApp({}));
        // Output html rendered by react
        // console.log(myAppHtml);
        res.render("index.ejs", {reactOutput: reactHtml});
    });

};

Meteor.js 對(duì)于客戶(hù)端和服務(wù)器端的 JavaScript 混用有著非常棒的支持。

if (Meteor.isClient) {
  Template.hello.greeting = function () {
    return "Welcome to myapp.";
  };

  Template.hello.events({
    "click input": function () {
      // template data, if any, is available in "this"
      if (typeof console !== "undefined")
        console.log("You pressed the button");
    }
  });
}

if (Meteor.isServer) {
  Meteor.startup(function () {
    // code to run on server at startup
  });
}

但是，為了支持服務(wù)器端渲染，需要像 meteor-ssr 這樣的插件。

謝謝 gabrielpoca 在評(píng)論中指出這一點(diǎn)。如果你有復(fù)雜的或者中等大小的應(yīng)用需要支持同構(gòu)部署，試試這個(gè)，你可能會(huì)感到驚訝的。

如果你需要解決數(shù)據(jù)庫(kù)查詢(xún)耗費(fèi)大量時(shí)間的問(wèn)題（分析你的應(yīng)用看看是否是這種情況?。?，是時(shí)候找出加速數(shù)據(jù)庫(kù)的方法了。每個(gè)數(shù)據(jù)庫(kù)和數(shù)據(jù)模型都有自己的權(quán)衡。數(shù)據(jù)庫(kù)優(yōu)化在每一方面都是一個(gè)主題：數(shù)據(jù)模型，數(shù)據(jù)庫(kù)類(lèi)型，具體實(shí)現(xiàn)方案，等等。提速可能不是那么的簡(jiǎn)單。但是這兒有個(gè)建議，可能可以對(duì)某些數(shù)據(jù)庫(kù)有所幫助：索引。索引是一個(gè)過(guò)程，即數(shù)據(jù)庫(kù)所創(chuàng)建的快速訪問(wèn)數(shù)據(jù)結(jié)構(gòu)，從內(nèi)部映射到鍵（在關(guān)系數(shù)據(jù)庫(kù)中的列），可以提高檢索相關(guān)數(shù)據(jù)的速度。大多數(shù)現(xiàn)代數(shù)據(jù)庫(kù)都支持索引。索引并不是文檔型數(shù)據(jù)庫(kù)（比如 MongoDB）所獨(dú)有的，也包括關(guān)系型數(shù)據(jù)庫(kù)（比如PostgreSQL）。

為了使用索引來(lái)優(yōu)化你的查詢(xún)，你將需要研究一下應(yīng)用程序的訪問(wèn)模式：什么是最常見(jiàn)的查詢(xún)，在哪個(gè)鍵或列中執(zhí)行搜索，等等。

JavaScript 軟件技術(shù)棧一如既往的復(fù)雜。而改善語(yǔ)言本身的需求則又增加了復(fù)雜度。不幸地是，JavaScript 作為目標(biāo)平臺(tái)又會(huì)被用戶(hù)的運(yùn)行時(shí)所限制。盡管很多改進(jìn)已經(jīng)以 ECMAScript 2015（2016正在進(jìn)行）的形式實(shí)現(xiàn)了，但是通常情況下，對(duì)客戶(hù)端代碼來(lái)說(shuō)又不可能依賴(lài)于這個(gè)版本。這種趨勢(shì)促使了一系列的_轉(zhuǎn)譯器_：用于處理 ECMAScript 2015 代碼的工具和只使用 ECMAScript 5 結(jié)構(gòu)實(shí)現(xiàn)其中所缺失的特性。與此同時(shí)，模塊綁定和壓縮處理也已經(jīng)被集成到這個(gè)生產(chǎn)過(guò)程中，被稱(chēng)為_(kāi)為發(fā)布而構(gòu)建_的代碼版本。這些工具可以轉(zhuǎn)化代碼，并且能夠以有限的方式影響到最終代碼的性能。Google 開(kāi)發(fā)者 Paul Irish 花了一些時(shí)間來(lái)尋找這些轉(zhuǎn)譯方案會(huì)如何影響性能和最終代碼的大小。盡管大多數(shù)情況下收益會(huì)很小，但也值得在正式采用某個(gè)工具棧之前看看這些數(shù)據(jù)。對(duì)于大型應(yīng)用程序來(lái)說(shuō)，這種區(qū)別可能會(huì)影響重大。

JavaScript 和 CSS 資源都會(huì)阻塞頁(yè)面的渲染。通過(guò)采取某些的規(guī)則，你可以保證你的腳本和 CSS 被盡可能快速地處理，以便于瀏覽器能夠顯示你的網(wǎng)站內(nèi)容。

在 CSS 的情況下這是非常重要的，所有的 CSS 規(guī)則都不能與特定媒體直接相關(guān)，規(guī)則只用于處理你準(zhǔn)備在頁(yè)面上所顯示內(nèi)容的優(yōu)先級(jí)。這可以通過(guò)使用 CSS 媒體查詢(xún)來(lái)實(shí)現(xiàn)。媒體查詢(xún)告訴瀏覽器，哪些 CSS 樣式表應(yīng)用在某個(gè)特定的顯示媒體上。舉個(gè)例子，用于打印的某些規(guī)則可以被賦予比用于屏幕顯示更低的優(yōu)先級(jí)。

媒體查詢(xún)可以被設(shè)置成 標(biāo)簽屬性：

輪到 JavaScript 了，關(guān)鍵就在于遵循某些用于內(nèi)聯(lián) JavaScript 的規(guī)則（比如內(nèi)聯(lián)在 HTML 文件當(dāng)中的代碼）。內(nèi)聯(lián) JavaScript 應(yīng)該盡可能短，并將其放在不會(huì)阻塞頁(yè)面剩余部分解析的地方。換句話(huà)說(shuō)，被放在 HTML 樹(shù)中間的內(nèi)聯(lián) JavaScript 將會(huì)在這個(gè)地方阻塞解析器，并強(qiáng)制其等待直到腳本被執(zhí)行完畢。如果在 HTML 文件中隨意放了一些大的代碼塊或者很多小的代碼塊，對(duì)于性能來(lái)說(shuō)這會(huì)成為性能殺手。內(nèi)聯(lián)可以有效減少額外對(duì)于某些特定腳本的網(wǎng)絡(luò)請(qǐng)求。但是對(duì)于重復(fù)使用的腳本或者大的代碼塊來(lái)說(shuō)，這個(gè)好處就可以忽略不計(jì)了。

防止 JavaScript 阻塞解析器和渲染器的一種方法就是將 12. 用于未來(lái)的一個(gè)建議：使用 service workers + 流

Jake Archibald 最近的一篇博文詳細(xì)描述了一種有趣的技術(shù)，可以用于加速渲染時(shí)間：將 service workers 和流結(jié)合起來(lái)。結(jié)果非常令人嘆服：

不幸的是這個(gè)技術(shù)所需要的 APIs 都還不穩(wěn)定，這也是為什么這是一種有趣的概念但現(xiàn)在還沒(méi)有真正被應(yīng)用的原因。這個(gè)想法的主旨就是在網(wǎng)站和客戶(hù)端之間放置一個(gè) service worker。這個(gè) service worker 可以在獲取缺失信息的同時(shí)緩存某些數(shù)據(jù)（比如 header 和一些不會(huì)經(jīng)常改變的東西）。缺失的內(nèi)容就可以盡可能快速地流向被渲染的頁(yè)面。

https://www.youtube.com/watch?v=Cjo9iq8k-bc

我們的一個(gè)讀者指出了一個(gè)非常重要的遺漏：圖片編碼優(yōu)化。PNGs 和 JPGs 在 Web 發(fā)布時(shí)都會(huì)使用次優(yōu)的設(shè)置進(jìn)行編碼。通過(guò)改變編碼器和它的設(shè)置，對(duì)于需要大量圖片的網(wǎng)站來(lái)說(shuō)可以獲得有效的改善。流行的解決方案包括 OptiPNG 和jpegtran。

A guide to PNG optimization 詳細(xì)描述了 OptiPNG 可以如何用于優(yōu)化 PNGs。

The man page for jpegtran 對(duì)它的一些特性提供了很好的介紹。

如果你發(fā)現(xiàn)這些指南相對(duì)于你的要求來(lái)說(shuō)都太復(fù)雜了的話(huà)，這兒有一些在線網(wǎng)站可以提供優(yōu)化服務(wù)。也有一些像 RIOT 一樣的圖形化界面，非常有助于批量操作和結(jié)果檢查。

你可以在下面的鏈接中閱讀更多信息，以及找到有助于優(yōu)化網(wǎng)站的工具：

Best Practices for Speeding up Your Website - Yahoo Developer Network

YSlow - a tool that checks for Yahoo"s recommended optimizations

PageSpeed Insights - Google Developers

PageSpeed Tools - Google Developers

HTTP/2: The Long-Awaited Sequel

我們是一個(gè) Web 公司。就以這種身份來(lái)說(shuō)，我們?yōu)槲覀兊幕A(chǔ)設(shè)施的某些部分部署了一些特定的優(yōu)化。舉例來(lái)說(shuō)，在登錄頁(yè)面你可以發(fā)現(xiàn)，在我們域名的 /learn 路徑下（比如，登錄頁(yè)面的單點(diǎn)登錄），我們采用了一種特別的優(yōu)化：為了方便我們使用 CMS 來(lái)創(chuàng)建每篇文章。因?yàn)槲恼露紱](méi)有中心索引，但是為了能夠被搜索引擎發(fā)現(xiàn)，使用了 webtask 的爬蟲(chóng)來(lái)預(yù)渲染每個(gè)頁(yè)面并生成了一個(gè)靜態(tài)版本然后上傳到我們 CDN。這減少了我們?cè)诜?wù)器端上的壓力，因?yàn)闊o(wú)須為每個(gè)訪客都生成動(dòng)態(tài)的服務(wù)器端內(nèi)容。與此同時(shí)還改善了延遲（并且隔離了我們發(fā)現(xiàn)與 CMS 相關(guān)的安全問(wèn)題）。

對(duì)于文檔部分，我們正在使用_同構(gòu) JavaScript_，這讓我們獲得了非常棒的啟動(dòng)時(shí)間，并且使我們的后端和前端團(tuán)隊(duì)能夠輕松集成。

由于應(yīng)用程序變得越來(lái)越大和越來(lái)越復(fù)雜，性能優(yōu)化對(duì)于 Web 開(kāi)發(fā)來(lái)說(shuō)正在變得越來(lái)越重要。在做出任何值得的時(shí)間和潛在的未來(lái)成本的優(yōu)化嘗試時(shí)，有針對(duì)性的改進(jìn)都是必不可少的。Web 應(yīng)用程序早已突破了大多數(shù)靜態(tài)內(nèi)容的邊界，學(xué)習(xí)常見(jiàn)模式進(jìn)行優(yōu)化則是令人愉悅的應(yīng)用和完全不可用的應(yīng)用之間最大的區(qū)別（這是讓你的訪客留下來(lái)的長(zhǎng)遠(yuǎn)之計(jì)?。](méi)有什么規(guī)則是絕對(duì)的，但是：性能分析和研究特定軟件技術(shù)棧的錯(cuò)綜復(fù)雜之處，是找出如何優(yōu)化它的唯一方式。你曾經(jīng)發(fā)現(xiàn)過(guò)對(duì)你的應(yīng)用產(chǎn)生巨大影響的其他建議嗎？請(qǐng)留言讓我們知道。Hack on！

歡迎關(guān)注知乎專(zhuān)欄 —— 前端的逆襲
歡迎關(guān)注我的博客，知乎，GitHub。