前端性能优化方案(五篇)

前端性能优化方案篇一

上面的脚本计算了 head 中的第一个 js脚本执行后加载页面所需的时间，但它没有给出任何关于从服务器获取页面所需的时间，或是页面初始化生命周期的信息。

由此我们可以计算旧文档的卸载、重定向、应用缓存、dns lookup、tcp 握手、http 请求处理、http 响应处理、dom 处理、document加载完成等页面性能打点。具体可以参考navigation-timing w3c的规范 和 几个页面关键指标是如何计算的

从上图中我们可以看出document processing是 navigation timing 独有的，后面我们也会介绍resource timing。整体而言 level 2 标准更加的全面，把web performance timing分成了各个 performance metric，看起来一目了然，然而各个主流浏览器还存在兼容性问题。

介绍完这两个performance navigation timing api，我们顺便再来看一下其余几个主要的performance timing api：resource timing api 、 paint timing api 和 long task timing api，以及如何使用performanceobserver异步获取性能数据。

performanceobserver 可以被动地订阅与性能相关的事件，也就是说这个 api 通常不会干扰页面主线程的性能，因为它的回调通常在空闲期间触发。默认情况下，performanceobserver 对象只能在条目出现时观察它们。如果想延迟加载性能分析代码（不阻止更高优先级的资源），我们需要这么做：

设置buffered 为true，浏览器将在第一次调用 performanceobserver 回调时返回其性能条目 缓冲区中的历史条目。

前端性能优化方案篇二

（下文以2022年2月a频道页面为例，均为dummy仿造后数据，也不代表整体情况）

.如何衡量性能问题严重性

衡量性能问题严重性，是为了让大家意识到优化的必要性，以及急迫性

同.性能黑榜，不赘述

见下图“可交互时长分布图”，一个记录代表一个用户。

即使不去统计，我们都能很明显的看出来，这个a频道页面：

和开发说明问题严重性时，这个会很有代入感，比如见下图，10%的android用户在以上，是不是可以认为他们大部分都跳失了？

下图不用算都能明显发现，秒开率和 整体数据差异实在太大

.分析性能瓶颈-分析思路

首先要明确，性能分析主要是给相关页面的前端、开发同学看，给关心问题的测试同学看，所以我们可以拆分的更细节、更专业。可以先分前端、后端2个大类：

.分析性能瓶颈-前端环节

业务因素（具体不表），分终端是重点。

从可交互时长、秒开率、3秒 率、5秒 率，分别分析，都能论证--支付宝端问题更明显。

下图将t1~t9 每个阶段打点情况可视化，并分析重点环节的差值（打点逻辑由前端定义）

见图2可以明显观察到：

1、接口耗时太久，且后变差明显（可以去追溯下发生了什么）； 2、lbs获取耗时很久，高于平均1倍以上，而取lbs是a频道页的关键逻辑

我们根据手淘的高中低端机评判标准，埋点获得数据。平均时长，高中低各自占比，以及低端时长分布（也可选中高端）。下图可发现，低端机比例很低（需要思考是否有必要重点优化），但低端机超过3秒以上的比例远高于其他的（和总体的完全时间分布对比） 。

包括：机型、系统等，可做参考

.分析性能瓶颈-后端环节

主要从后端维度来分析

这里可见，下图尽管是开始发起请求-》收到请求的全过程，但也严重超标（几乎是标准值的2倍）

前端性能优化方案篇三

通过线上用户的真实采集，并制定能反应用户体感的指标，进行性能黑榜和全局趋势分析。

从重点单点角度，我们通过性能黑榜；从整体视角，我们通过整体趋势分析。

.性能数据的采集

arms前端监控专注于对web场景、小程序场景的监控，从页面打开速度（测速）、页面稳定性（js诊断错误）和外部服务调用成功率（api）这三个方面监测web和小程序页面的健康度。

sls日志服务为log、metric、trace等数据提供大规模、低成本、实时的平台化服务。日志服务一站式提供数据采集、加工、查询与分析、可视化、告警、消费与投递等功能。

odps即maxcompute，是适用于数据分析场景的企业级saas模式云数据仓库。

fbi是阿里内的智能大数据分析和可视化平台，下面的所有截图都是在fbi平台配置图表而成，还未对外开放。

arms-sdk结合前端的自定义埋点，在海量用户访问的同时，就会自动上报数据到sls日志库，整体过程如下图：

.性能指标的确定

所有前台页面，每个用户每次浏览的有效数据（完全加载