wx.getPerformance 返回的entries中拉主包耗时，取得的packageSize（c1）大小差距非常大，是什么原因呢，版本都是一致的 item.entryType === 'loadPackage' && item.name === 'downloadPackage' && item.packageName === '__APP__' [图片]

原文来自「微信开发者」公众号。 本文主要介绍了API wx.reportPerformance的三步操作。 小程序顺利上线完的你，是否收到过用户这样的反馈？ [图片] 而你自己打开一切都挺正常。难道是打开姿势不对？ [图片] 重启大法固然好，用户可能跟着跑。于是，为帮助开发者提前发现性能问题，我们推出了“小程序测速”功能。从“重启试试”到“暗中修复”的距离只要一个API—— wx.reportPerformance。测速三步走，性能无忧愁。 1 新建监控ID 为了实现对某一指标的耗时监控，开发者需要先定义监控指标。在小程序管理后台（mp.weixin.qq.com）的 ：“开发 -运维中心 -小程序测速”中新建监控 ID，并填写监控指标的名称和解释。 [图片] 新建后，可以看到上报需要使用的监控 ID 。 [图片] 2 测速上报 新建后，可以看到上报需要使用的监控 ID 。 定义监控ID后，需要在小程序代码中调用 wx.reportPerformance 接口上报耗时数值，才可实现耗时监控： // 判断接口是否可用，基础库 2.9.2 开始支持 if (wx.canIUse('reportPerformance')) { // id: 监听ID // val: 本次耗时数值 wx.reportPerformance(id, val) } 3 数据观察 上报完成后，我们就可以坐等数据了，目前线上数据会有15分钟的延迟。 有了数据之后，我们可以这样观察平均值曲线和上报次数曲线。 [图片] 也可以这样交叉对比观察： [图片] 甚至~还可以通过区域地图，这样观察数据： [图片] 什么？你还觉得维度不够多？想要根据 url、页面等进行细分更详细的掌握性能状况。  让自定义维度来满足你的需求，只要给 wx.reportPerformance 加上第三个参数 dimensions，即可上报自定义维度。 // dimensions: 自定义维度，String/Array wx.reportPerformance(id, val, dimensions) 上报完成之后，跟前面一样可以直接在小程序管理后台（mp.weixin.qq.com）看到上报的自定义维度。分析的时候，就可以加上自定义维度细化分析数据。 [图片] 小程序测速接入完成~盘腿嗑瓜子，告别“转菊花”的烦恼。 关于小程序测速，你有什么想法或建议？欢迎参与话题交流，即有机会获得微信正版周边礼品哦

微信小程序前端性能监控（1） 本文分为两篇，认识与使用 performance，阅读各大约10分钟 01 打点： performance 是前端性能监控的API，小程序也实现了它。 首先我们回到一个古老的监控方法：Date.now()，用它打点行么? [图片] 图示：W3C提供的一段代码示例 回答当然是可以，那它与 performance 的区别在哪，为什么现在不推荐这种方式了？ 首先就是精度问题，我们知道时间是个无穷小数，时间原点及精度取舍是不同的。有兴趣了解时间起源等更深入知识的小伙伴可以到文章结尾获取链接。 [图片] 图示：获取精度示例 最重要的是它提供了抓取各时间节点的API，定义了专用于测试的时间原点，及浮点数达到微秒级别的精确度等。Date.now() 时间戳可以衡量获取资源所需的时间，但是它不能分解页面加载在各个阶段花费的时间。此外，脚本无法轻松衡量获取标记中描述的资源所花费的时间。 大多系统运行一个守护程序定期同步时间，通常15-20min调整几毫秒，这个速率大约10S间隔的值会有1%的误差。而performence是恒定的速率，它定义了navigationStart，performance.timing.navigationStart + performance.now() 约等于 Date.now()。 02 基础API的认识： 在控制台打印 performance 如下： [图片] 图示：performance API memory 内存相关 jsHeapSizeLimit 内存大小的限制。 totalJSHeapSize 总内存的大小。 usedJSHeapSize 可使用的内存的大小。 注：如果 usedJSHeapSize 大于 totalJSHeapSize的话，那么就会出现内存泄露的问题，因此是不允许大于该值的。 navigation 页面的来源信息 redirectCount：如果有重定向，页面通过几次重定向跳转而来，默认为0 type：该值的含义表示的页面打开的方式。默认为0. 可取值为0、1、2、255这个值在实际项目中蛮实用，它可以判断来源页的跳转方法例如：手机触发返回，它的值为2 0：正常进入该页面(非刷新、非重定向)。 1：通过 window.location.reload 刷新的页面。如果我现在刷新下页面后，再来看该值就变成1了。 2：通过浏览器的前进、后退按钮进入的页面。如果我此时先前进下页面，再后退返回到该页面后，查看打印的值，发现变成2了。 255：非以上的方式进入页面的。 onresourcetimingbufferfull  回调函数 浏览器的资源时间性能缓冲区满了执行的回调 timeOrigin 时间戳它是一系列时间点的基准点，精确到万分之一毫秒。该值是动态的，刷新下，该值是会发生改变的。 timing 各时间点的集合 connectEnd：HTTP完成建立连接的时间(完成握手)。如果是持久链接的话，该值则和fetchStart值相同，如果在传输层发生了错误且需要重新建立连接的话，那么在这里显示的是新建立的链接完成时间。 connectStart：HTTP 开始建立连接的时间，如果是持久链接的话，该值则和fetchStart值相同，如果在传输层发生了错误且需要重新建立连接的话，那么在这里显示的是新建立的链接开始时间。 domComplete：DOM树解析完成，且资源也准备就绪的时间。Document.readyState 变为 complete，并将抛出 readystatechange 相关事件。 domContentLoadedEventEnd：DOM解析完成后，网页内资源加载完成的时间。 domContentLoadedEventStart：DOM解析完成后，网页内资源加载开始的时间。 domInteractive：完成解析DOM树的时间（只是DOM树解析完成，并没有开始加载页面资源）。 domLoading：开始解析渲染DOM树的时间。 domainLookupEnd：DNS域名查询完成的时间，如果使用了本地缓存或持久链接，该值则与fetchStart值相同。 domainLookupStart：DNS域名查询开始的时间，如果使用了本地缓存或持久链接，该值则与fetchStart值相同。 fetchStart：准备好使用http请求抓取文档的时间(发生在检查本地缓存之前)。 loadEventEnd：load事件的回调函数执行完毕的时间，如果没有绑定load事件，该值为0 loadEventStart：load事件发送给文档。也即load回调函数开始执行的时间，如果没有绑定load事件，则该值为0 navigationStar：同一个浏览器上一个页面卸载结束时的时间戳。如果没有上一个页面的话，那么该值会和fetchStart的值相同 redirectEnd：最后一个HTTP重定向完成时的时间戳。如果没有重定向或者重定向到一个不同的源，该值也返回为0 redirectStart：该值的含义是第一个http重定向开始的时间戳，如果没有重定向或者重定向到一个不同源的话，那么该值返回为0 requestStart：HTTP请求读取真实文档开始的时间，包括从本地读取缓存，链接错误重连时。 responseEnd：HTTP响应全部接收完成时的时间(获取到最后一个字节)。包括从本地读取缓存。 responseStart：开始接收到响应的时间(获取到第一个字节的那个时候)。包括从本地读取缓存。 secureConnectionStart：HTTPS 连接开始的时间，如果不是安全连接，则值为 0 unloadEventStart：前一个页面unload的时间戳，如果没有前一个页面，那么该值为0 unloadEventEnd：和 unloadEventStart 相对应，返回是前一个网页unload事件绑定的回调函数执行完毕的时间戳。 拓展学习 W3C Web Performance：https://www.w3.org/TR/resource-timing-2/#cross-origin-resources Web Performance Working Group：https://www.w3.org/webperf/ Chrome Web Fundamentals：https://developers.google.cn/web/fundamentals/performance/navigation-and-resource-timing chrome.loadTimes() API：https://developers.google.cn/web/updates/2017/12/chrome-loadtimes-deprecated#requesttime MDN Performence API：https://developer.mozilla.org/zh-CN/docs/Web/API/Performance MDN Timing-Allow-Origin API：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Timing-Allow-Origin Unix time：https://en.wikipedia.org/wiki/Unix_time Performance Navigation Timing：https://w3c.github.io/navigation-timing/#dom-performancenavigationtiming Resource Timinghttps://www.w3.org/TR/resource-timing-2/#cross-origin-resources

第二版真正改进中。欢迎提建议哈