js刷新当前页面(js刷新当前页面白屏)满满干货

2025-10-04 16:57 來源：廣西云-廣西日?qǐng)?bào) 記者羅莎楊思悅通訊員劉鵬飛編輯：馮芯然

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

js刷新當(dāng)前頁面(js刷新當(dāng)前頁面白屏)滿滿干貨

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

剛進(jìn)公司時(shí)，在進(jìn)行Node.js的接口開發(fā)時(shí)，我不太習(xí)慣每次排查問題都要通過跳板機(jī)登上服務(wù)器看日志，后來慢慢習(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ì)問題進(jìn)行回溯、還原問題的場(chǎng)景，進(jìn)行bug的修復(fù)。

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

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

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

異常捕獲方法全局捕獲可以通過全局監(jiān)聽異常來捕獲，通過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ò)誤);

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

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

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

常見問題跨域腳本無法準(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)過webpack打包后壓縮混淆的代碼，所以我們可能會(huì)遇到這樣的問題，如圖所示：

我們發(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ò)誤")}]);在我的開發(fā)過程中也遇到過這個(gè)問題，我在開發(fā)一個(gè)功能組件庫的時(shí)候，使用npm link了我的組件庫，但是由于組件庫被npm link后是打包后的生產(chǎn)環(huán)境下的代碼，所有的報(bào)錯(cuò)都定位到了第一行。

解決辦法是開啟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ò)誤的位置：

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

這個(gè)npm庫既可以運(yùn)行在客戶端也可以運(yùn)行在服務(wù)端，不過更為推薦的是在服務(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) { // 獲取前端傳過來的報(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)，我們可以通過日志的方式進(jìn)行記錄，達(dá)到了前端異常監(jiān)控的目的。

Vue捕獲異常在我的項(xiàng)目中就遇到這樣的問題，使用了js-tracker這樣的插件來統(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.

; }returnthis.props.children; }}使用方式如下：

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

// 記錄頁面加載開始時(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或者說React，組件是異步渲染然后掛載到DOM的，在頁面初始化時(shí)并沒有太多的DOM節(jié)點(diǎn)，可以參考下文關(guān)于首屏?xí)r間采集自動(dòng)化的解決方案來對(duì)渲染時(shí)間進(jìn)行打點(diǎn)。

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

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

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

timing對(duì)象包含延遲相關(guān)的性能信息這是我們頁面加載性能優(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è)量開始時(shí)的時(shí)間的高精度時(shí)間戳如圖所示，精確到了小數(shù)點(diǎn)后四位onresourcetimingbufferfull方法，它是一個(gè)在resourcetimingbufferfull事件觸發(fā)時(shí)會(huì)被調(diào)用的event handler。

這個(gè)事件當(dāng)瀏覽器的資源時(shí)間性能緩沖區(qū)已滿時(shí)會(huì)觸發(fā)可以通過監(jiān)聽這一事件觸發(fā)來預(yù)估頁面crash，統(tǒng)計(jì)頁面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屬性，可以拿到頁面性能相關(guān)的數(shù)據(jù)，這里在很多文章都有提到關(guān)于利用window.performance.timing記錄頁面性能的文章，例如alloyteam團(tuán)隊(duì)寫的初探 performance – 監(jiān)控網(wǎng)頁與程序性能，對(duì)于timing的各項(xiàng)屬性含義，可以借助摘自此文的下圖理解，以下代碼摘自此文作為計(jì)算網(wǎng)站性能的工具函數(shù)參考：

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

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

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

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

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

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

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

0,// 和 unloadEventStart 相對(duì)應(yīng)，返回前一個(gè)網(wǎng)頁 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 域名查詢開始的時(shí)間，如果使用了本地緩存（即無 DNS 查詢）或持久連接，則與 fetchStart 值相等

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

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

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

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

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

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

responseEnd: 1441112692687,// 開始解析渲染 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í)候并沒有開始加載網(wǎng)頁內(nèi)的資源 domInteractive: 1441112693093,// DOM 解析完成后，網(wǎng)頁內(nèi)資源加載開始的時(shí)間// 在 DOMContentLoaded 事件拋出前發(fā)生

domContentLoadedEventStart: 1441112693093,// DOM 解析完成后，網(wǎng)頁內(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ù)開始執(zhí)行的時(shí)間// 注意如果沒有綁定 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 = { };//【重要】頁面加載完成的時(shí)間//【原因】這幾乎代表了用戶等待頁面可用的時(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ù)加載做了么？頁面內(nèi)是不是使用了太多不同的域名導(dǎo)致域名查詢的時(shí)間太長？// 可使用 HTML5 Prefetch 預(yù)查詢 DNS ，見：[HTML5 prefetch](http://segmentfault.com/a/1190000000633364)

times.lookupDomain = t.domainLookupEnd - t.domainLookupStart;//【重要】讀取頁面第一個(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;

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

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

// DNS 緩存時(shí)間 times.appcache = t.domainLookupStart - t.fetchStart;// 卸載頁面的時(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ù)器來說，我們肯定不希望占用業(yè)務(wù)服務(wù)器的計(jì)算資源，也不希望過多的日志在業(yè)務(wù)服務(wù)器堆積，造成業(yè)務(wù)服務(wù)器的存儲(chǔ)空間不夠的情況其二，我們知道在頁面初始化的過程中，會(huì)對(duì)頁面加載時(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ì)頁面加載性能造成的影響跨域的問題對(duì)于單獨(dú)的日志域名，肯定會(huì)涉及到跨域的問題，采取的解決方案一般有以下兩種：一種是構(gòu)造空的Image對(duì)象的方式，其原因是請(qǐng)求圖片并不涉及到跨域的問題；

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

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ì)有長度的限制，需要確保的是請(qǐng)求的長度不會(huì)超過閾值省去響應(yīng)主體對(duì)于我們上報(bào)日志，其實(shí)對(duì)于客戶端來說，并不需要考慮上報(bào)的結(jié)果，甚至對(duì)于上報(bào)失敗，我們也不需要在前端做任何交互，所以上報(bào)來說，其實(shí)使用HEAD請(qǐng)求就夠了，接口返回空的結(jié)果，最大地減少上報(bào)日志造成的資源浪費(fèi)。

合并上報(bào)類似于雪碧圖的思想，如果我們的應(yīng)用需要上報(bào)的日志數(shù)量很多，那么有必要合并日志進(jìn)行統(tǒng)一的上報(bào)解決方案可以是嘗試在用戶離開頁面或者組件銷毀時(shí)發(fā)送一個(gè)異步的POST請(qǐng)求來進(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è)頁面所以這里是必須設(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覽器卡死感覺，對(duì)于產(chǎn)品而言，體驗(yàn)非常不好，通過查閱MDN文檔，可以使用sendBeacon()方法，將會(huì)使用戶代理在有機(jī)會(huì)時(shí)異步地向服務(wù)器發(fā)送數(shù)據(jù)，同時(shí)不會(huì)延遲頁面的卸載或影響下一導(dǎo)航的載入性能。

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

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

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

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

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

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