乐趣区

关于javascript:前端性能监控Web-APIperformance属性和使用

jiezi

前端性能监控的关注点有很多，这篇文章次要介绍 Web API 之 performance 属性和应用。

一、属性

在浏览器下方打印 window 能够看到外面的 performance 属性，开展后能够看到外面有数十条属性，上面用表格的模式列一下对应属性的阐明。

属性 阐明 用处
performance.eventCounts 它记录了所有曾经散发过的 Event，解决工夫是否大于 50ms。
performance.memory 记录内存属性
performance.memory.jsHeapSizeLimit 上下文内可用堆的最大体积，以字节计算。
performance.memory.totalJSHeapSize 已调配的堆体积，以字节计算。
performance.memory.usedJSHeapSize 以后 JS 堆沉闷段（segment）的体积，以字节计算。
performance.navigation 示意呈现在以后浏览上下文的 navigation 类型，比方获取某个资源所须要的重定向次数。
performance.navigation.redirectCount 示意在达到这个页面之前重定向了多少次。
performance.navigation.type 示意是如何导航到这个页面的。 检测页面时如何跳转过来的
performance.onresourcetimingbufferfull 一个回调的 EventTarget，当触发 resourcetimingbufferfull 事件的时候会被调用。 一个回调函数
performance.timeOrigin 返回性能测量开始时的工夫的高精度工夫戳。
performance.timing 蕴含提早相干的性能信息。依据 w3c 规范，该属性未来会被 performanceTiming 取代。 能够从该属性下获取浏览器首屏渲染期间产生各事件的工夫戳，用于页面性能剖析。
performance.timing.navigationStart 表征了从同一个浏览器上下文的上一个文档卸载 (unload) 完结时的 UNIX 工夫戳。如果没有上一个文档，这个值会和 PerformanceTiming.fetchStart 雷同。
performance.timing.unloadEventStart 表征了 unload (en-US) 事件抛出时的 UNIX 工夫戳。在没有上一个文档、重定向、不同源的状况下, 这个值会返回 0。
performance.timing.unloadEventEnd 表征了 unload (en-US) 事件处理实现时的 UNIX 工夫戳。在没有上一个文档、重定向、不同源的状况下, 这个值会返回 0。
performance.timing.redirectStart 表征了第一个 HTTP 重定向开始时的 UNIX 工夫戳。如果没有重定向，或者重定向中的一个不同源，这个值会返回 0。
performance.timing.redirectEnd 表征了最初一个 HTTP 重定向实现时（也就是说是 HTTP 响应的最初一个比特间接被收到的工夫）的 UNIX 工夫戳。如果没有重定向，或者重定向中的一个不同源，这个值会返回 0。
performance.timing.fetchStart 表征了浏览器筹备好应用 HTTP 申请来获取 (fetch) 文档的 UNIX 工夫戳。这个工夫点会在查看任何利用缓存之前。 可作为性能检测的起始工夫点
performance.timing.domainLookupStart 表征了域名查问开始的 UNIX 工夫戳。如果应用了继续连贯(persistent connection)，或者这个信息存储到了缓存或者本地资源上，这个值将和 PerformanceTiming.fetchStart 统一。
performance.timing.domainLookupEnd 表征了域名查问完结的 UNIX 工夫戳。如果应用了继续连贯(persistent connection)，或者这个信息存储到了缓存或者本地资源上，这个值将和 PerformanceTiming.fetchStart 统一。 DNS 解析实现的工夫点
performance.timing.connectStart 返回 HTTP 申请开始向服务器发送时的 Unix 毫秒工夫戳。如果应用长久连贯（persistent connection），则返回值等同于 fetchStart 属性的值。
performance.timing.connectEnd 返回浏览器与服务器之间的连贯建设时的 Unix 毫秒工夫戳。如果建设的是长久连贯，则返回值等同于 fetchStart 属性的值。连贯建设指的是所有握手和认证过程全副完结。
performance.timing.secureConnectionStart 返回浏览器与服务器开始平安链接的握手时的 Unix 毫秒工夫戳。如果以后网页不要求平安连贯，则返回 0。
performance.timing.requestStart 返回浏览器向服务器收回 HTTP 申请时（或开始读取本地缓存时）的 Unix 毫秒工夫戳。 开始发送 http 申请（获取资源文件）的工夫点
performance.timing.responseStart 返回浏览器从服务器收到（或从本地缓存读取）第一个字节时的 Unix 毫秒工夫戳。如果传输层在开始申请之后失败并且连贯被重开，该属性将会被数制成新的申请的绝对应的发动工夫。
performance.timing.responseEnd 返回浏览器从服务器收到（或从本地缓存读取，或从本地资源读取）最初一个字节时（如果在此之前 HTTP 连贯曾经敞开，则返回敞开时）的 Unix 毫秒工夫戳。 html 文件获取实现的工夫点
performance.timing.domLoading 返回以后网页 DOM 构造开始解析时（即 Document.readyState 属性变为“loading”、相应的 readystatechange (en-US)事件触发时）的 Unix 毫秒工夫戳。
performance.timing.domInteractive 返回以后网页 DOM 构造完结解析、开始加载内嵌资源时（即 Document.readyState 属性变为“interactive”、相应的 readystatechange (en-US) 事件触发时）的 Unix 毫秒工夫戳。
performance.timing.domContentLoadedEventStart 返回当解析器发送DOMContentLoaded (en-US) 事件，即所有须要被执行的脚本曾经被解析时的 Unix 毫秒工夫戳。 留神，这里并不是说 JS 脚本开始执行的工夫，而是说 html 文档加载结束，并且 html 所援用的内联 js、以及外链 js 的同步代码都执行结束后触发。
performance.timing.domContentLoadedEventEnd 返回当所有须要立刻执行的脚本曾经被执行（不管执行程序）时的 Unix 毫秒工夫戳。 须要执行的 JS 脚本执行结束的工夫
performance.timing.domComplete 返回以后文档解析实现，即Document.readyState 变为 'complete' 且绝对应的`readystatechange (en-US)` 被触发时的 Unix 毫秒工夫戳。
performance.timing.loadEventStart 返回该文档下，load (en-US)事件被发送时的 Unix 毫秒工夫戳。如果这个事件还未被发送，它的值将会是 0。
performance.timing.loadEventEnd 返回当 load (en-US) 事件完结，即加载事件实现时的 Unix 毫秒工夫戳。如果这个事件还未被发送，或者尚未实现，它的值将会是 0。 可作为首屏渲染实现工夫

二、用处

从下面表格里记录的参数用处来看，咱们应该在页面渲染实现后应用该参数，防止 loadEventEnd 为 0，获取对应参数信息并上传到日志中去。

上面做一个测试，对应的 html 如下。

<!DOCTYPE html>
<html>

<head>
  <script>
    let sum1 = 0
    for (let i = 0; i < 99999999; i++) {sum1 += 1}
  </script>
  <meta charset="utf-8">
  <title> 我是伯约同学 </title>
</head>

<body>
  <script>

    let sum2 = 0
    for (let i = 0; i < 99999999; i++) {sum2 += 2}
  </script>
  <div class="my-div">performance</div>
  <p style="background-color: aqua;">learn</p>
</body>
<style>
  .my-div {font-size: 20px;}
</style>
<script>

  let sum3 = 0
  for (let i = 0; i < 99999999; i++) {sum3 += 1}
  window.onload = function () {
    let t = performance.timing
    console.log('DNS 查问耗时：' + (t.domainLookupEnd - t.domainLookupStart).toFixed(0))
    console.log('TCP 链接耗时：' + (t.connectEnd - t.connectStart).toFixed(0))
    console.log('request 申请耗时：' + (t.responseEnd - t.responseStart).toFixed(0))
    console.log('解析 dom 树耗时：' + (t.domComplete - t.domInteractive).toFixed(0))
    console.log('白屏工夫：' + (t.responseStart - t.navigationStart).toFixed(0))
    console.log('js 脚本执行工夫：' + (t.domContentLoadedEventEnd - t.domContentLoadedEventStart).toFixed(0))
    console.log('首屏渲染工夫：' + (t.loadEventEnd - t.navigationStart).toFixed(0))
    console.log('js 内存应用占比：' + (t.usedJSHeapSize / t.totalJSHeapSize * 100).toFixed(2) + '%')
  }
</script>

</html>

查看对应后果

DNS 查问耗时：0
test-html.html:42 TCP 链接耗时：0
test-html.html:43 request 申请耗时：1
test-html.html:44 解析 dom 树耗时：0
test-html.html:45 白屏工夫：0
test-html.html:46 js 脚本执行工夫：0
test-html.html:47 首屏渲染工夫：2183

js 内存应用占比：100.00%

能够看到脚本的执行耽搁了首屏渲染的工夫。这样也能够指引咱们在工作中的一些优化。

退出移动版