共计 4518 个字符,预计需要花费 12 分钟才能阅读完成。
前端性能监控的关注点有很多,这篇文章次要介绍 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%
能够看到脚本的执行耽搁了首屏渲染的工夫。这样也能够指引咱们在工作中的一些优化。
正文完
发表至: javascript
2021-11-04