前端代码机能质量监测

2019年8月25日 172次阅读 来源: 小无路

1.页面团体机能

经由历程浏览器供应的 window.performance.timing 要领，我们能够获得网页每一个处置惩罚阶段的准确时候。翻开一个页面后，这些信息会被浏览器记录下来，我们直接在控制台输出，就能够检察效果

PerformanceTiming 接口包含了当前页面中与时候相干的信息。

能够经由历程只读属性Performance.timing 获得完成该接口的一个对象。

var timing = window.Performance.timing;
console.log(timing);

概况以下：

https://developer.mozilla.org…

PerformanceTiming 接口不包含任何继续属性。

  • PerformanceTiming.navigationStart 只读

是一个无标记long long 型的毫秒数，表征了从同一个浏览器上下文的上一个文档卸载(unload)完毕时的UNIX时候戳。假如没有上一个文档，这个值会和PerformanceTiming.fetchStart雷同。

  • PerformanceTiming.unloadEventStart 只读

是一个无标记long long 型的毫秒数，表征了unload事宜抛出时的UNIX时候戳。假如没有上一个文档，or if the previous document, or one of the needed redirects, is not of the same origin, 这个值会返回0.

  • PerformanceTiming.unloadEventEnd 只读

是一个无标记long long 型的毫秒数，表征了unload事宜处置惩罚完成时的UNIX时候戳。假如没有上一个文档，or if the previous document, or one of the needed redirects, is not of the same origin, 这个值会返回0.

  • PerformanceTiming.redirectStart 只读

是一个无标记long long 型的毫秒数，表征了第一个HTTP重定向最先时的UNIX时候戳。假如没有重定向，或许重定向中的一个差别源，这个值会返回0.

  • PerformanceTiming.redirectEnd 只读

是一个无标记long long 型的毫秒数，表征了末了一个HTTP重定向完成时（也就是说是HTTP响应的末了一个比特直接被收到的时候）的UNIX时候戳。假如没有重定向，或许重定向中的一个差别源，这个值会返回0.

  • PerformanceTiming.fetchStart 只读

是一个无标记long long 型的毫秒数，表征了浏览器准备好运用HTTP请求来猎取(fetch)文档的UNIX时候戳。这个时候点会在搜检任何运用缓存之前。

  • PerformanceTiming.domainLookupStart 只读

是一个无标记long long 型的毫秒数，表征了域名查询最先的UNIX时候戳。假如运用了延续衔接(persistent connection)，或许这个信息存储到了缓存或许当地资本上，这个值将和 PerformanceTiming.fetchStart一致。

  • PerformanceTiming.domainLookupEnd 只读

是一个无标记long long 型的毫秒数，表征了域名查询完毕的UNIX时候戳。假如运用了延续衔接(persistent connection)，或许这个信息存储到了缓存或许当地资本上，这个值将和 PerformanceTiming.fetchStart一致。

  • PerformanceTiming.connectStart 只读

是一个无标记long long 型的毫秒数，返回HTTP请求最先向服务器发送时的Unix毫秒时候戳。假如运用耐久衔接（persistent connection），则返回值等同于fetchStart属性的值。

  • PerformanceTiming.connectEnd 只读

是一个无标记long long 型的毫秒数，返回浏览器与服务器之间的衔接竖立时的Unix毫秒时候戳。假如竖立的是耐久衔接，则返回值等同于fetchStart属性的值。衔接竖立指的是一切握手和认证历程悉数完毕。

  • PerformanceTiming.secureConnectionStart 只读

是一个无标记long long 型的毫秒数，返回浏览器与服务器最先平安链接的握手时的Unix毫秒时候戳。假如当前网页不请求平安衔接，则返回0。

  • PerformanceTiming.requestStart 只读

是一个无标记long long 型的毫秒数，返回浏览器向服务器发出HTTP请求时（或最先读取当地缓存时）的Unix毫秒时候戳。

  • PerformanceTiming.responseStart 只读

是一个无标记long long 型的毫秒数，返回浏览器从服务器收到（或从当地缓存读取）第一个字节时的Unix毫秒时候戳。假如传输层在最先请求以后失利而且衔接被重开，该属性将会被数制成新的请求的相对应的提议时候。

  • PerformanceTiming.responseEnd 只读

是一个无标记long long 型的毫秒数，返回浏览器从服务器收到（或从当地缓存读取，或从当地资本读取）末了一个字节时（假如在此之前HTTP衔接已封闭，则返回封闭时）的Unix毫秒时候戳。

  • PerformanceTiming.domLoading 只读

是一个无标记long long 型的毫秒数，返回当前网页DOM构造最先剖析时（即Document.readyState属性变成“loading”、响应的 readystatechange事宜触发时）的Unix毫秒时候戳。

  • PerformanceTiming.domInteractive 只读

是一个无标记long long 型的毫秒数，返回当前网页DOM构造完毕剖析、最先加载内嵌资本时（即Document.readyState属性变成“interactive”、响应的readystatechange事宜触发时）的Unix毫秒时候戳。

  • PerformanceTiming.domContentLoadedEventStart 只读

是一个无标记long long 型的毫秒数，返回当剖析器发送DOMContentLoaded 事宜，即一切须要被实行的剧本已被剖析时的Unix毫秒时候戳。

  • PerformanceTiming.domContentLoadedEventEnd 只读

是一个无标记long long 型的毫秒数，返回当一切须要马上实行的剧本已被实行（不管实行递次）时的Unix毫秒时候戳。

  • PerformanceTiming.domComplete 只读

是一个无标记long long 型的毫秒数，返回当前文档剖析完成，即Document.readyState 变成 ‘complete’且相对应的readystatechange 被触发时的Unix毫秒时候戳。

  • PerformanceTiming.loadEventStart 只读

是一个无标记long long 型的毫秒数，返回该文档下，load事宜被发送时的Unix毫秒时候戳。假如这个事宜还未被发送，它的值将会是0。

  • PerformanceTiming.loadEventEnd 只读

是一个无标记long long 型的毫秒数，返回当load事宜完毕，即加载事宜完成时的Unix毫秒时候戳。假如这个事宜还未被发送，或许还没有完成，它的值将会是0.

performance支撑状况

http://caniuse.com/#search=pe…
《前端代码机能质量监测》

2.window.onerror

运用 window.onerror

https://developer.mozilla.org…

函数参数：

message：毛病信息（字符串）。Available as event (sic!) in HTML onerror=”” handler.

source：发作毛病的剧本URL（字符串）

lineno：发作毛病的行号（数字）

colno：发作毛病的列号（数字）

error：Error对象（对象）

若该函数返回true，则阻挠实行默许事宜处置惩罚函数。

经由历程在 window.onerror 上定义一个事宜监听函数，顺序中代码发生的毛病就会被 window.onerror 上面注册的监听函数捕获到，一般我们会如许完成一个 onerror 的函数

window.onerror = function(msg, url, line, col, error){
        var errInfo = {};

        errInfo.msg = msg;// 毛病信息
        errInfo.url = url;//毛病文件途径
        errInfo.line = line;//行号，紧缩事后，然并卵
        errInfo.col = col;//列号

        if (error && error.stack) {
          errInfo.stack = error.stack;
        }
        // 把毛病信息发送到背景服务器 
           sendLog(errorInfo);
        return true;
    };
function sendLog(log){
    var img = new Image();
    img.src="url?errorInfo="+encodeURIComponent(JSON.stringify(log));
}

3.Script error的处理办法

当加载自差别域的剧本中发作语法(?)毛病时，为防止信息泄漏（拜见bug 363897），语法毛病的细节将不会报告，而代之简朴的”Script error.”。在某些浏览器中，经由历程在<script>运用crossorigin属性并请求服务器发送恰当的CORS HTTP响应头，该行动可被掩盖。

ex：

html的url为www.taobao.com; js途径为https://g.alicdn.com/xxx.js
碰到如许的报错。这是浏览器出于平安性的斟酌，在加载非同源的JS文件时会隐蔽部份信息，包含我们此处想要获得的毛病信息，并给出一个一致的 Script error 提醒，想要处理这个题目，我们须要浏览器端和服务端都做响应的调解

服务器端：

header('Access-Control-Allow-Origin: *');

也能够直接变动nginx的设置许可跨域援用

客户端：

<script src = 'https://blog.sentry.io/js/script.js' crossorigin></script>

服务端必需加许可跨域援用，不然这段js不会实行。。。
更多信息请移步本人博客 https://www.56way.com/p/106.html

    原文作者：小无路
    原文地址: https://segmentfault.com/a/1190000010337617
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞