對(duì)于后臺(tái)開(kāi)發(fā)來(lái)說(shuō)，刷新刷新記錄日志是當(dāng)前當(dāng)前一種非常常見(jiàn)的開(kāi)發(fā)習(xí)慣，通常我們會(huì)使用try...catch代碼塊來(lái)主動(dòng)捕獲錯(cuò)誤、頁(yè)面頁(yè)面對(duì)于每次接口調(diào)用，白屏也會(huì)記錄下每次接口調(diào)用的滿滿時(shí)間消耗，以便我們監(jiān)控服務(wù)器接口性能，干貨進(jìn)行問(wèn)題排查。刷新刷新

點(diǎn)擊上方藍(lán)字,記得關(guān)注我們！本文5240字，頁(yè)面頁(yè)面預(yù)計(jì)閱讀需要24分鐘

對(duì)于后臺(tái)開(kāi)發(fā)來(lái)說(shuō)，記錄日志是滿滿一種非常常見(jiàn)的開(kāi)發(fā)習(xí)慣，通常我們會(huì)使用try...catch代碼塊來(lái)主動(dòng)捕獲錯(cuò)誤、干貨對(duì)于每次接口調(diào)用，刷新刷新也會(huì)記錄下每次接口調(diào)用的當(dāng)前當(dāng)前時(shí)間消耗，以便我們監(jiān)控服務(wù)器接口性能，頁(yè)面頁(yè)面進(jìn)行問(wèn)題排查。

剛進(jìn)公司時(shí)，在進(jìn)行Node.js的接口開(kāi)發(fā)時(shí)，我不太習(xí)慣每次排查問(wèn)題都要通過(guò)跳板機(jī)登上服務(wù)器看日志，后來(lái)慢慢習(xí)慣了這種方式舉個(gè)例子：/** * 獲取列表數(shù)據(jù) * @parma req, res */exports.getList =

asyncfunction (req, res) {//獲取請(qǐng)求參數(shù)const openId = req.session.userinfo.openId; logger.info(`handler getList, user openId is

${openId}`);try {// 拿到列表數(shù)據(jù)const startTime = newDate().getTime();let res = await ListService.getListFromDB(openId);

logger.info(`handler getList, ListService.getListFromDB cost time ${newDate().getTime() - startDate}

`);// 對(duì)數(shù)據(jù)處理，返回給前端// ... } catch(error) { logger.error(`handler getList is error, ${JSON.stringify(error)}

`); }};以下代碼經(jīng)常會(huì)出現(xiàn)在用Node.js的接口中，在接口中會(huì)統(tǒng)計(jì)查詢DB所耗時(shí)間、亦或是統(tǒng)計(jì)RPC服務(wù)調(diào)用所耗時(shí)間，以便監(jiān)測(cè)性能瓶頸，對(duì)性能做優(yōu)化；又或是對(duì)異常使用try ... catch主動(dòng)捕獲，以便隨時(shí)對(duì)問(wèn)題進(jìn)行回溯、還原問(wèn)題的場(chǎng)景，進(jìn)行bug的修復(fù)。

而對(duì)于前端來(lái)說(shuō)呢？可以看以下的場(chǎng)景最近在進(jìn)行一個(gè)需求開(kāi)發(fā)時(shí)，偶爾發(fā)現(xiàn)webgl渲染影像失敗的情況，或者說(shuō)影像會(huì)出現(xiàn)解析失敗的情況，我們可能根本不知道哪張影像會(huì)解析或渲染失敗；又或如最近開(kāi)發(fā)的另外一個(gè)需求，我們會(huì)做一個(gè)關(guān)于webgl渲染時(shí)間的優(yōu)化和影像預(yù)加載的需求，如果缺乏性能監(jiān)控，該如何統(tǒng)計(jì)所做的渲染優(yōu)化和影像預(yù)加載優(yōu)化的優(yōu)化比例，如何證明自己所做的事情具有價(jià)值呢？可能是通過(guò)測(cè)試同學(xué)的黑盒測(cè)試，對(duì)優(yōu)化前后的時(shí)間進(jìn)行錄屏，分析從進(jìn)入頁(yè)面到影像渲染完成到底經(jīng)過(guò)了多少幀圖像。

這樣的數(shù)據(jù)，可能既不準(zhǔn)確、又較為片面，設(shè)想測(cè)試同學(xué)并不是真正的用戶，也無(wú)法還原真實(shí)的用戶他們所處的網(wǎng)絡(luò)環(huán)境回過(guò)頭來(lái)發(fā)現(xiàn)，我們的項(xiàng)目，雖然在服務(wù)端層面做好了日志和性能統(tǒng)計(jì)，但在前端對(duì)異常的監(jiān)控和性能的統(tǒng)計(jì)。

對(duì)于前端的性能與異常上報(bào)的可行性探索是有必要的異常捕獲方法對(duì)于前端來(lái)說(shuō)，我們需要的異常捕獲無(wú)非為以下兩種：接口調(diào)用情況；頁(yè)面邏輯是否錯(cuò)誤，例如，用戶進(jìn)入頁(yè)面后頁(yè)面顯示白屏；對(duì)于接口調(diào)用情況，在前端通常需要上報(bào)客戶端相關(guān)參數(shù)，例如：用戶OS與瀏覽器版本、請(qǐng)求參數(shù)（如頁(yè)面ID）；而對(duì)于頁(yè)面邏輯是否錯(cuò)誤問(wèn)題，通常除了用戶OS與瀏覽器版本外，需要的是報(bào)錯(cuò)的堆棧信息及具體報(bào)錯(cuò)位置。

異常捕獲方法全局捕獲可以通過(guò)全局監(jiān)聽(tīng)異常來(lái)捕獲，通過(guò)window.onerror或者addEventListener，看以下例子：window.onerror = function(errorMessage, scriptURI, lineNo, columnNo, error

) {console.log(errorMessage: + errorMessage); // 異常信息console.log(scriptURI: + scriptURI); // 異常文件路徑

console.log(lineNo: + lineNo); // 異常行號(hào)console.log(columnNo: + columnNo); // 異常列號(hào)console.log(error:

+ error); // 異常堆棧信息// ...// 異常上報(bào)};thrownewError(這是一個(gè)錯(cuò)誤);

通過(guò)window.onerror事件，可以得到具體的異常信息、異常文件的URL、異常的行號(hào)與列號(hào)及異常的堆棧信息，再捕獲異常后，統(tǒng)一上報(bào)至我們的日志服務(wù)器亦或是，通過(guò)window.addEventListener方法來(lái)進(jìn)行異常上報(bào)，道理同理：。

window.addEventListener(error, function() {console.log(error);// ...// 異常上報(bào)});thrownewError(這是一個(gè)錯(cuò)誤);

try... catch使用try... catch雖然能夠較好地進(jìn)行異常捕獲，不至于使得頁(yè)面由于一處錯(cuò)誤掛掉，但try ... catch捕獲方式顯得過(guò)于臃腫，大多代碼使用try ... catch包裹，影響代碼可讀性。

常見(jiàn)問(wèn)題跨域腳本無(wú)法準(zhǔn)確捕獲異常通常情況下，我們會(huì)把靜態(tài)資源，如JavaScript腳本放到專門的靜態(tài)資源服務(wù)器，亦或者CDN，看以下例子：

>// 在index.htmlwindow.onerror = function(errorMessage, scriptURI, lineNo, columnNo, error

) {console.log(errorMessage: + errorMessage); // 異常信息console.log(scriptURI: + scriptURI); // 異常文件路徑

console.log(lineNo: + lineNo); // 異常行號(hào)console.log(columnNo: + columnNo); // 異常列號(hào)console.log(error:

+ error); // 異常堆棧信息// ...// 異常上報(bào)};// error.js

thrownewError(這是一個(gè)錯(cuò)誤);

結(jié)果顯示，跨域之后window.onerror根本捕獲不到正確的異常信息，而是統(tǒng)一返回一個(gè)Script error，解決方案：對(duì)script標(biāo)簽增加一個(gè)crossorigin=”anonymous”，并且服務(wù)器添加Access-Control-Allow-Origin。

sourceMap通常在生產(chǎn)環(huán)境下的代碼是經(jīng)過(guò)webpack打包后壓縮混淆的代碼，所以我們可能會(huì)遇到這樣的問(wèn)題，如圖所示：

我們發(fā)現(xiàn)所有的報(bào)錯(cuò)的代碼行數(shù)都在第一行了，為什么呢？這是因?yàn)樵谏a(chǎn)環(huán)境下，我們的代碼被壓縮成了一行：!function(e){var n={};functionr(o){if(n[o])return n[o].exports;

var t=n[o]={i:o,l:!1,exports:{}};return e[o].call(t.exports,t,t.exports,r),t.l=!0,t.exports}r.m=e,r.c=n,r.d=

function(e,n,o){r.o(e,n)||Object.defineProperty(e,n,{enumerable:!0,get:o})},r.r=function(e){"undefined"

!=typeofSymbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object

.defineProperty(e,"__esModule",{value:!0})},r.t=function(e,n){if(1&n&&(e=r(e)),8&n)return e;if(4&n&&"object"

==typeof e&&e&&e.__esModule)return e;var o=Object.create(null);if(r.r(o),Object.defineProperty(o,"default"

,{enumerable:!0,value:e}),2&n&&"string"!=typeof e)for(var t in e)r.d(o,t,function(n){return e[n]}.bind(

null,t));return o},r.n=function(e){var n=e&&e.__esModule?function(){return e.default}:function(){return

 e};return r.d(n,"a",n),n},r.o=function(e,n){returnObject.prototype.hasOwnProperty.call(e,n)},r.p="",r(r.s=

0)}([function(e,n){throwwindow.onerror=function(e,n,r,o,t){console.log("errorMessage: "+e),console.log(

"scriptURI: "+n),console.log("lineNo: "+r),console.log("columnNo: "+o),console.log("error: "+t);var l={

errorMessage:e||null,scriptURI:n||null,lineNo:r||null,columnNo:o||null,stack:t&&t.stack?t.stack:null};

if(XMLHttpRequest){var u=new XMLHttpRequest;u.open("post","/middleware/errorMsg",!0),u.setRequestHeader(

"Content-Type","application/json"),u.send(JSON.stringify(l))}},newError("這是一個(gè)錯(cuò)誤")}]);在我的開(kāi)發(fā)過(guò)程中也遇到過(guò)這個(gè)問(wèn)題，我在開(kāi)發(fā)一個(gè)功能組件庫(kù)的時(shí)候，使用npm link了我的組件庫(kù)，但是由于組件庫(kù)被npm link后是打包后的生產(chǎn)環(huán)境下的代碼，所有的報(bào)錯(cuò)都定位到了第一行。

解決辦法是開(kāi)啟webpack的source-map，我們利用webpack打包后的生成的一份.map的腳本文件就可以讓瀏覽器對(duì)錯(cuò)誤位置進(jìn)行追蹤了此處可以參考webpack document其實(shí)就是webpack.config.js中加上一行devtool: source-map，如下所示，為示例的webpack.config.js：。

var path = require(path);module.exports = {devtool: source-map,mode: development,entry: ./client/index.js

,output: {filename: bundle.js,path: path.resolve(__dirname, client)}}在webpack打包后生成對(duì)應(yīng)的source-map，這樣瀏覽器就能夠定位到具體錯(cuò)誤的位置：

開(kāi)啟source-map的缺陷是兼容性，目前只有Chrome瀏覽器和Firefox瀏覽器才對(duì)source-map支持不過(guò)我們對(duì)這一類情況也有解決辦法可以使用引入npm庫(kù)來(lái)支持source-map，可以參考mozilla/source-map。

這個(gè)npm庫(kù)既可以運(yùn)行在客戶端也可以運(yùn)行在服務(wù)端，不過(guò)更為推薦的是在服務(wù)端使用Node.js對(duì)接收到的日志信息時(shí)使用source-map解析，以避免源代碼的泄露造成風(fēng)險(xiǎn)，如下代碼所示：const express =

require(express);const fs = require(fs);const router = express.Router();const sourceMap = require(source-map

);const path = require(path);const resolve = file => path.resolve(__dirname, file);// 定義post接口router.get(

/error/, asyncfunction(req, res) {// 獲取前端傳過(guò)來(lái)的報(bào)錯(cuò)對(duì)象let error = JSON.parse(req.query.error);let url = error.scriptURI;

// 壓縮文件路徑if (url) {let fileUrl = url.slice(url.indexOf(client/)) + .map; // map文件路徑// 解析sourceMaplet consumer =

awaitnew sourceMap.SourceMapConsumer(fs.readFileSync(resolve(../ + fileUrl), utf8)); // 返回一個(gè)promise對(duì)象

// 解析原始報(bào)錯(cuò)數(shù)據(jù)let result = consumer.originalPositionFor({line: error.lineNo, // 壓縮后的行號(hào) column: error.columnNo

// 壓縮后的列號(hào)});console.log(result); }});module.exports = router;如下圖所示，我們已經(jīng)可以看到，在服務(wù)端已經(jīng)成功解析出了具體錯(cuò)誤的行號(hào)、列號(hào)，我們可以通過(guò)日志的方式進(jìn)行記錄，達(dá)到了前端異常監(jiān)控的目的。

Vue捕獲異常在我的項(xiàng)目中就遇到這樣的問(wèn)題，使用了js-tracker這樣的插件來(lái)統(tǒng)一進(jìn)行全局的異常捕獲和日志上報(bào)，結(jié)果發(fā)現(xiàn)我們根本捕獲不到Vue組件的異常，查閱資料得知，在Vue中，異常可能被Vue自身給try ... catch了，不會(huì)傳到window.onerror事件觸發(fā)，那么我們?nèi)绾伟裋ue組件中的異常作統(tǒng)一捕獲呢？

使用Vue.config.errorHandler這樣的Vue全局配置，可以在Vue指定組件的渲染和觀察期間未捕獲錯(cuò)誤的處理函數(shù)這個(gè)處理函數(shù)被調(diào)用時(shí)，可獲取錯(cuò)誤信息和Vue 實(shí)例Vue.config.errorHandler = 。

function (err, vm, info) {// handle error// `info` 是 Vue 特定的錯(cuò)誤信息，比如錯(cuò)誤所在的生命周期鉤子// 只在 2.2.0+ 可用}在React中，可以使用ErrorBoundary組件包括業(yè)務(wù)組件的方式進(jìn)行異常捕獲，配合React 16.0+新出的componentDidCatch API，可以實(shí)現(xiàn)統(tǒng)一的異常捕獲和日志上報(bào)。

classErrorBoundaryextendsReact.Component{constructor(props) {super(props);this.state = { hasError: false

}; } componentDidCatch(error, info) {// Display fallback UIthis.setState({ hasError: true });// You can also log the error to an error reporting service

logErrorToMyService(error, info); } render() {if (this.state.hasError) {// You can render any custom fallback UI

return

Something went wrong.

性能監(jiān)控最簡(jiǎn)單的性能監(jiān)控最常見(jiàn)的性能監(jiān)控需求則是需要我們統(tǒng)計(jì)用戶從開(kāi)始請(qǐng)求頁(yè)面到所有DOM元素渲染完成的時(shí)間，也就是俗稱的首屏加載時(shí)間，DOM提供了這一接口，監(jiān)聽(tīng)document的DOMContentLoaded事件與window的load事件可統(tǒng)計(jì)頁(yè)面首屏加載時(shí)間即所有DOM渲染時(shí)間：

// 記錄頁(yè)面加載開(kāi)始時(shí)間var timerStart =

Date.now();

document.addEventListener(DOMContentLoaded, function() {console.log("DOM 掛載時(shí)間: ", Date.now() - timerStart);

// 性能日志上報(bào)});window.addEventListener(load, function() {console.log("所有資源加載完成時(shí)間: ", Date.now()-timerStart);

// 性能日志上報(bào)});對(duì)于使用框架，如Vue或者說(shuō)React，組件是異步渲染然后掛載到DOM的，在頁(yè)面初始化時(shí)并沒(méi)有太多的DOM節(jié)點(diǎn)，可以參考下文關(guān)于首屏?xí)r間采集自動(dòng)化的解決方案來(lái)對(duì)渲染時(shí)間進(jìn)行打點(diǎn)。

performance但是以上時(shí)間的監(jiān)控過(guò)于粗略，例如我們想統(tǒng)計(jì)文檔的網(wǎng)絡(luò)加載耗時(shí)、解析DOM的耗時(shí)與渲染DOM的耗時(shí)，就不太好辦到了，所幸的是瀏覽器提供了window.performance接口，具體可見(jiàn)MDN文檔

幾乎所有瀏覽器都支持window.performance接口，下面來(lái)看看在控制臺(tái)打印window.performance可以得到些什么：

可以看到，window,performance主要包括有memory、navigation、timing以及timeOrigin及onresourcetimingbufferfull方法navigation對(duì)象提供了在指定的時(shí)間段里發(fā)生的操作相關(guān)信息，包括頁(yè)面是加載還是刷新、發(fā)生了多少次重定向等等。

timing對(duì)象包含延遲相關(guān)的性能信息這是我們頁(yè)面加載性能優(yōu)化需求中主要上報(bào)的相關(guān)信息memory為Chrome添加的一個(gè)非標(biāo)準(zhǔn)擴(kuò)展，這個(gè)屬性提供了一個(gè)可以獲取到基本內(nèi)存使用情況的對(duì)象在其它瀏覽器應(yīng)該考慮到這個(gè)API的兼容處理。

timeOrigin則返回性能測(cè)量開(kāi)始時(shí)的時(shí)間的高精度時(shí)間戳如圖所示，精確到了小數(shù)點(diǎn)后四位onresourcetimingbufferfull方法，它是一個(gè)在resourcetimingbufferfull事件觸發(fā)時(shí)會(huì)被調(diào)用的event handler。

這個(gè)事件當(dāng)瀏覽器的資源時(shí)間性能緩沖區(qū)已滿時(shí)會(huì)觸發(fā)可以通過(guò)監(jiān)聽(tīng)這一事件觸發(fā)來(lái)預(yù)估頁(yè)面crash，統(tǒng)計(jì)頁(yè)面crash概率，以便后期的性能優(yōu)化，如下示例所示：functionbuffer_full(event

) {console.log("WARNING: Resource Timing Buffer is FULL!"); performance.setResourceTimingBufferSize(

200);}functioninit() {// Set a callback if the resource buffer becomes filled performance.onresourcetimingbufferfull = buffer_full;

}計(jì)算網(wǎng)站性能使用performance的timing屬性，可以拿到頁(yè)面性能相關(guān)的數(shù)據(jù)，這里在很多文章都有提到關(guān)于利用window.performance.timing記錄頁(yè)面性能的文章，例如alloyteam團(tuán)隊(duì)寫的初探 performance – 監(jiān)控網(wǎng)頁(yè)與程序性能，對(duì)于timing的各項(xiàng)屬性含義，可以借助摘自此文的下圖理解，以下代碼摘自此文作為計(jì)算網(wǎng)站性能的工具函數(shù)參考：

// 獲取 performance 數(shù)據(jù)var performance = { // memory 是非標(biāo)準(zhǔn)屬性，只在 Chrome 有// 財(cái)富問(wèn)題：我有多少內(nèi)存 memory: { usedJSHeapSize:

16100000, // JS 對(duì)象（包括V8引擎內(nèi)部對(duì)象）占用的內(nèi)存，一定小于 totalJSHeapSize totalJSHeapSize: 35100000, // 可使用的內(nèi)存 jsHeapSizeLimit:

793000000// 內(nèi)存大小限制 },// 哲學(xué)問(wèn)題：我從哪里來(lái)？ navigation: { redirectCount: 0, // 如果有重定向的話，頁(yè)面通過(guò)幾次重定向跳轉(zhuǎn)而來(lái)

type: 0// 0 即 TYPE_NAVIGATENEXT 正常進(jìn)入的頁(yè)面（非刷新、非重定向等）// 1 即 TYPE_RELOAD 通過(guò) window.location.reload() 刷新的頁(yè)面

// 2 即 TYPE_BACK_FORWARD 通過(guò)瀏覽器的前進(jìn)后退按鈕進(jìn)入的頁(yè)面（歷史記錄）// 255 即 TYPE_UNDEFINED 非以上方式進(jìn)入的頁(yè)面 }, timing: {

// 在同一個(gè)瀏覽器上下文中，前一個(gè)網(wǎng)頁(yè)（與當(dāng)前頁(yè)面不一定同域）unload 的時(shí)間戳，如果無(wú)前一個(gè)網(wǎng)頁(yè) unload ，則與 fetchStart 值相等 navigationStart:

1441112691935,// 前一個(gè)網(wǎng)頁(yè)（與當(dāng)前頁(yè)面同域）unload 的時(shí)間戳，如果無(wú)前一個(gè)網(wǎng)頁(yè) unload 或者前一個(gè)網(wǎng)頁(yè)與當(dāng)前頁(yè)面不同域，則值為 0 unloadEventStart:

0,// 和 unloadEventStart 相對(duì)應(yīng)，返回前一個(gè)網(wǎng)頁(yè) unload 事件綁定的回調(diào)函數(shù)執(zhí)行完畢的時(shí)間戳 unloadEventEnd: 0,// 第一個(gè) HTTP 重定向發(fā)生時(shí)的時(shí)間。

有跳轉(zhuǎn)且是同域名內(nèi)的重定向才算，否則值為 0 redirectStart: 0,// 最后一個(gè) HTTP 重定向完成時(shí)的時(shí)間有跳轉(zhuǎn)且是同域名內(nèi)部的重定向才算，否則值為 0 redirectEnd: 。

0,// 瀏覽器準(zhǔn)備好使用 HTTP 請(qǐng)求抓取文檔的時(shí)間，這發(fā)生在檢查本地緩存之前 fetchStart: 1441112692155,// DNS 域名查詢開(kāi)始的時(shí)間，如果使用了本地緩存（即無(wú) DNS 查詢）或持久連接，則與 fetchStart 值相等

domainLookupStart: 1441112692155,// DNS 域名查詢完成的時(shí)間，如果使用了本地緩存（即無(wú) DNS 查詢）或持久連接，則與 fetchStart 值相等

domainLookupEnd: 1441112692155,// HTTP（TCP） 開(kāi)始建立連接的時(shí)間，如果是持久連接，則與 fetchStart 值相等// 注意如果在傳輸層發(fā)生了錯(cuò)誤且重新建立連接，則這里顯示的是新建立的連接開(kāi)始的時(shí)間

connectStart: 1441112692155,// HTTP（TCP） 完成建立連接的時(shí)間（完成握手），如果是持久連接，則與 fetchStart 值相等// 注意如果在傳輸層發(fā)生了錯(cuò)誤且重新建立連接，則這里顯示的是新建立的連接完成的時(shí)間

// 注意這里握手結(jié)束，包括安全連接建立完成、SOCKS 授權(quán)通過(guò) connectEnd: 1441112692155,// HTTPS 連接開(kāi)始的時(shí)間，如果不是安全連接，則值為 0 secureConnectionStart:

0,// HTTP 請(qǐng)求讀取真實(shí)文檔開(kāi)始的時(shí)間（完成建立連接），包括從本地讀取緩存// 連接錯(cuò)誤重連時(shí)，這里顯示的也是新建立連接的時(shí)間 requestStart: 1441112692158

,// HTTP 開(kāi)始接收響應(yīng)的時(shí)間（獲取到第一個(gè)字節(jié)），包括從本地讀取緩存 responseStart: 1441112692686,// HTTP 響應(yīng)全部接收完成的時(shí)間（獲取到最后一個(gè)字節(jié)），包括從本地讀取緩存

responseEnd: 1441112692687,// 開(kāi)始解析渲染 DOM 樹的時(shí)間，此時(shí) Document.readyState 變?yōu)?loading，并將拋出 readystatechange 相關(guān)事件

domLoading: 1441112692690,// 完成解析 DOM 樹的時(shí)間，Document.readyState 變?yōu)?interactive，并將拋出 readystatechange 相關(guān)事件

// 注意只是 DOM 樹解析完成，這時(shí)候并沒(méi)有開(kāi)始加載網(wǎng)頁(yè)內(nèi)的資源 domInteractive: 1441112693093,// DOM 解析完成后，網(wǎng)頁(yè)內(nèi)資源加載開(kāi)始的時(shí)間// 在 DOMContentLoaded 事件拋出前發(fā)生

domContentLoadedEventStart: 1441112693093,// DOM 解析完成后，網(wǎng)頁(yè)內(nèi)資源加載完成的時(shí)間（如 JS 腳本加載執(zhí)行完畢） domContentLoadedEventEnd:

1441112693101,// DOM 樹解析完成，且資源也準(zhǔn)備就緒的時(shí)間，Document.readyState 變?yōu)?complete，并將拋出 readystatechange 相關(guān)事件 domComplete:

1441112693214,// load 事件發(fā)送給文檔，也即 load 回調(diào)函數(shù)開(kāi)始執(zhí)行的時(shí)間// 注意如果沒(méi)有綁定 load 事件，值為 0 loadEventStart: 1441112693214

,// load 事件的回調(diào)函數(shù)執(zhí)行完畢的時(shí)間 loadEventEnd: 1441112693215// 字母順序// connectEnd: 1441112692155,// connectStart: 1441112692155,

// domComplete: 1441112693214,// domContentLoadedEventEnd: 1441112693101,// domContentLoadedEventStart: 1441112693093,

// domInteractive: 1441112693093,// domLoading: 1441112692690,// domainLookupEnd: 1441112692155,// domainLookupStart: 1441112692155,

// fetchStart: 1441112692155,// loadEventEnd: 1441112693215,// loadEventStart: 1441112693214,// navigationStart: 1441112691935,

// redirectEnd: 0,// redirectStart: 0,// requestStart: 1441112692158,// responseEnd: 1441112692687,// responseStart: 1441112692686,

// secureConnectionStart: 0,// unloadEventEnd: 0,// unloadEventStart: 0}};// 計(jì)算加載時(shí)間functiongetPerformanceTiming

() {var performance = window.performance;if (!performance) {// 當(dāng)前瀏覽器不支持console.log(你的瀏覽器不支持 performance 接口

);return;}var t = performance.timing;var times = {};//【重要】頁(yè)面加載完成的時(shí)間//【原因】這幾乎代表了用戶等待頁(yè)面可用的時(shí)間 times.loadPage = t.loadEventEnd - t.navigationStart;

//【重要】解析 DOM 樹結(jié)構(gòu)的時(shí)間//【原因】反省下你的 DOM 樹嵌套是不是太多了！ times.domReady = t.domComplete - t.responseEnd;//【重要】重定向的時(shí)間

//【原因】拒絕重定向！比如，http://example.com/ 就不該寫成 http://example.com times.redirect = t.redirectEnd - t.redirectStart;

//【重要】DNS 查詢時(shí)間//【原因】DNS 預(yù)加載做了么？頁(yè)面內(nèi)是不是使用了太多不同的域名導(dǎo)致域名查詢的時(shí)間太長(zhǎng)？// 可使用 HTML5 Prefetch 預(yù)查詢 DNS ，見(jiàn)：[HTML5 prefetch](http://segmentfault.com/a/1190000000633364)

times.lookupDomain = t.domainLookupEnd - t.domainLookupStart;//【重要】讀取頁(yè)面第一個(gè)字節(jié)的時(shí)間//【原因】這可以理解為用戶拿到你的資源占用的時(shí)間，加異地機(jī)房了么，加CDN 處理了么？加帶寬了么？加 CPU 運(yùn)算速度了么？

// TTFB 即 Time To First Byte 的意思// 維基百科：https://en.wikipedia.org/wiki/Time_To_First_Byte times.ttfb = t.responseStart - t.navigationStart;

//【重要】?jī)?nèi)容加載完成的時(shí)間//【原因】頁(yè)面內(nèi)容經(jīng)過(guò) gzip 壓縮了么，靜態(tài)資源 css/js 等壓縮了么？ times.request = t.responseEnd - t.requestStart;

//【重要】執(zhí)行 onload 回調(diào)函數(shù)的時(shí)間//【原因】是否太多不必要的操作都放到 onload 回調(diào)函數(shù)里執(zhí)行了，考慮過(guò)延遲加載、按需加載的策略么？ times.loadEvent = t.loadEventEnd - t.loadEventStart;

// DNS 緩存時(shí)間 times.appcache = t.domainLookupStart - t.fetchStart;// 卸載頁(yè)面的時(shí)間 times.unloadEvent = t.unloadEventEnd - t.unloadEventStart;

// TCP 建立連接完成握手的時(shí)間 times.connect = t.connectEnd - t.connectStart;return times;}日志上報(bào)單獨(dú)的日志域名對(duì)于日志上報(bào)使用單獨(dú)的日志域名的目的是避免對(duì)業(yè)務(wù)造成影響。

其一，對(duì)于服務(wù)器來(lái)說(shuō)，我們肯定不希望占用業(yè)務(wù)服務(wù)器的計(jì)算資源，也不希望過(guò)多的日志在業(yè)務(wù)服務(wù)器堆積，造成業(yè)務(wù)服務(wù)器的存儲(chǔ)空間不夠的情況其二，我們知道在頁(yè)面初始化的過(guò)程中，會(huì)對(duì)頁(yè)面加載時(shí)間、PV、UV等數(shù)據(jù)進(jìn)行上報(bào)，這些上報(bào)請(qǐng)求會(huì)和加載業(yè)務(wù)數(shù)據(jù)幾乎是同時(shí)刻發(fā)出，而瀏覽器一般會(huì)對(duì)同一個(gè)域名的請(qǐng)求量有并發(fā)數(shù)的限制，如Chrome會(huì)有對(duì)并發(fā)數(shù)為6個(gè)的限制。

因此需要對(duì)日志系統(tǒng)單獨(dú)設(shè)定域名，最小化對(duì)頁(yè)面加載性能造成的影響跨域的問(wèn)題對(duì)于單獨(dú)的日志域名，肯定會(huì)涉及到跨域的問(wèn)題，采取的解決方案一般有以下兩種：一種是構(gòu)造空的Image對(duì)象的方式，其原因是請(qǐng)求圖片并不涉及到跨域的問(wèn)題；

var url = xxx;new Image().src = url;利用Ajax上報(bào)日志，必須對(duì)日志服務(wù)器接口開(kāi)啟跨域請(qǐng)求頭部Access-Control-Allow-Origin:*，這里Ajax就并不強(qiáng)制使用GET請(qǐng)求了，即可克服URL長(zhǎng)度限制的問(wèn)題。

if (XMLHttpRequest) {var xhr = new XMLHttpRequest(); xhr.open(post, https://log.xxx.com, true); // 上報(bào)給node中間層處理

xhr.setRequestHeader(Content-Type, application/json); // 設(shè)置請(qǐng)求頭 xhr.send(JSON.stringify(errorObj));

// 發(fā)送參數(shù)}在我的項(xiàng)目中使用的是第一種的方式，也就是構(gòu)造空的Image對(duì)象，但是我們知道對(duì)于GET請(qǐng)求會(huì)有長(zhǎng)度的限制，需要確保的是請(qǐng)求的長(zhǎng)度不會(huì)超過(guò)閾值省去響應(yīng)主體對(duì)于我們上報(bào)日志，其實(shí)對(duì)于客戶端來(lái)說(shuō)，并不需要考慮上報(bào)的結(jié)果，甚至對(duì)于上報(bào)失敗，我們也不需要在前端做任何交互，所以上報(bào)來(lái)說(shuō)，其實(shí)使用HEAD請(qǐng)求就夠了，接口返回空的結(jié)果，最大地減少上報(bào)日志造成的資源浪費(fèi)。

合并上報(bào)類似于雪碧圖的思想，如果我們的應(yīng)用需要上報(bào)的日志數(shù)量很多，那么有必要合并日志進(jìn)行統(tǒng)一的上報(bào)解決方案可以是嘗試在用戶離開(kāi)頁(yè)面或者組件銷毀時(shí)發(fā)送一個(gè)異步的POST請(qǐng)求來(lái)進(jìn)行上報(bào)，但是嘗試在卸載（unload）文檔之前向web服務(wù)器發(fā)送數(shù)據(jù)。

保證在文檔卸載期間發(fā)送數(shù)據(jù)一直是一個(gè)困難因?yàn)橛脩舸硗ǔ?huì)忽略在卸載事件處理器中產(chǎn)生的異步XMLHttpRequest，因?yàn)榇藭r(shí)已經(jīng)會(huì)跳轉(zhuǎn)到下一個(gè)頁(yè)面所以這里是必須設(shè)置為同步的XMLHttpRequest請(qǐng)求嗎？。

window.addEventListener(unload, logData, false);functionlogData() {var client = new XMLHttpRequest();

client.open("POST", "/log", false); // 第三個(gè)參數(shù)表明是同步的 xhr client.setRequestHeader("Content-Type",

"text/plain;charset=UTF-8"); client.send(analyticsData);}使用同步的方式勢(shì)必會(huì)對(duì)用戶體驗(yàn)造成影響，甚至?xí)層脩舾惺艿綖g覽器卡死感覺(jué)，對(duì)于產(chǎn)品而言，體驗(yàn)非常不好，通過(guò)查閱MDN文檔，可以使用sendBeacon()方法，將會(huì)使用戶代理在有機(jī)會(huì)時(shí)異步地向服務(wù)器發(fā)送數(shù)據(jù)，同時(shí)不會(huì)延遲頁(yè)面的卸載或影響下一導(dǎo)航的載入性能。

這就解決了提交分析數(shù)據(jù)時(shí)的所有的問(wèn)題：使它可靠，異步并且不會(huì)影響下一頁(yè)面的加載此外，代碼實(shí)際上還要比其他技術(shù)簡(jiǎn)單！下面的例子展示了一個(gè)理論上的統(tǒng)計(jì)代碼模式——通過(guò)使用sendBeacon()方法向服務(wù)器發(fā)送數(shù)據(jù)。

window.addEventListener(unload, logData, false);functionlogData() { navigator.sendBeacon("/log", analyticsData);

}小結(jié)作為前端開(kāi)發(fā)者而言，要對(duì)產(chǎn)品保持敬畏之心，時(shí)刻保持對(duì)性能追求極致，對(duì)異常不可容忍的態(tài)度前端的性能監(jiān)控與異常上報(bào)顯得尤為重要代碼難免有問(wèn)題，對(duì)于異常可以使用window.onerror或者addEventListener的方式添加全局的異常捕獲偵聽(tīng)函數(shù)，但可能使用這種方式無(wú)法正確捕獲到錯(cuò)誤：對(duì)于跨域的腳本，需要對(duì)script標(biāo)簽增加一個(gè)crossorigin=”anonymous”；對(duì)于生產(chǎn)環(huán)境打包的代碼，無(wú)法正確定位到異常產(chǎn)生的行數(shù)，可以使用source-map來(lái)解決；而對(duì)于使用框架的情況，需要在框架統(tǒng)一的異常捕獲處埋點(diǎn)。

而對(duì)于性能的監(jiān)控，所幸的是瀏覽器提供了window.performance API，通過(guò)這個(gè)API，很便捷地獲取到當(dāng)前頁(yè)面性能相關(guān)的數(shù)據(jù)而這些異常和性能數(shù)據(jù)如何上報(bào)呢？一般說(shuō)來(lái)，為了避免對(duì)業(yè)務(wù)產(chǎn)生的影響，會(huì)單獨(dú)建立日志服務(wù)器和日志域名，但對(duì)于不同的域名，又會(huì)產(chǎn)生跨域的問(wèn)題。

我們可以通過(guò)構(gòu)造空的Image對(duì)象來(lái)解決，亦或是通過(guò)設(shè)定跨域請(qǐng)求頭部Access-Control-Allow-Origin:*來(lái)解決此外，如果上報(bào)的性能和日志數(shù)據(jù)高頻觸發(fā)，則可以在頁(yè)面unload時(shí)統(tǒng)一上報(bào)，而unload時(shí)的異步請(qǐng)求又可能會(huì)被瀏覽器所忽略，且不能改為同步請(qǐng)求。

此時(shí)navigator.sendBeacon API可算幫了我們大忙，它可用于通過(guò)HTTP將少量數(shù)據(jù)異步傳輸?shù)絎eb服務(wù)器而忽略頁(yè)面unload時(shí)的影響就醬，下期再見(jiàn)

免責(zé)聲明：本站所有信息均搜集自互聯(lián)網(wǎng)，并不代表本站觀點(diǎn)，本站不對(duì)其真實(shí)合法性負(fù)責(zé)。如有信息侵犯了您的權(quán)益，請(qǐng)告知，本站將立刻處理。聯(lián)系QQ：1640731186