关于前端:前端性能优化到底该怎么做上-开门见山

前端性能优化 又是个听起来很高大上的词，的确是的，因为它须要 高在性能，大在范畴，所幸很多大佬都曾经输入了很多高质量的内容供大家参考，作者最近也在学习和理解这方面的内容，对如下文中的一些了解若有不当之处，可在评论区斧正！！！

前端性能优化这个内容打算分为 高低两篇，原本打算一篇写完，但发现前置常识局部曾经占了 3000+ 文字，因而本篇文章次要还是解说一些必要理解的前置内容。

下一篇：前端性能优化到底该怎么做（下）— 直捣黄龙

其实前端性能优化外围就是两点：

保障资源更快的加载速度：达到越快渲染越快，视图展示就越快
保障视图更快的渲染速度 / 交互速度：用户与页面交互，前提是页面要渲染进去，其次是页面须要尽早反馈，目标就是保障用户良好的体验性

而这些核心内容都能够从上面这个陈词滥调的问题中延长开来。

从输出 URL 到页面加载实现产生了什么？

置信到当初为止，大家对这个问题的答复能够说是可能做到滔滔不绝了吧（~~如果不能，请疏忽~~）！不过每个人答复的方向和重点应该都不一样，比方之前在 B 站 听 winter 大佬对这个问题的认识和解析的角度是更深、更广的。

在这还是要简略的总结一下核心内容：

进行 DNS 解析
建设 TCP 连贯
客户端发送 HTTP 申请
服务端响应 HTTP 资源
浏览器获取响应内容，进行解析和渲染

以上任意一点都可进行有限扩大、延长，但点到为止才是当初真正须要的。

Google 为前端页面性能的评估提出了 RAIL 模型，核心内容如下：

Response 响应
Animation 动画
Idle 闲暇
Load 加载

性能指标其实有不少的内容，但在这咱们指列举比拟罕用的几种：

首次绘制（First Paint，FP）
- 在渲染过程确认要渲染以后响应资源后，渲染过程会先创立一个空白页面，通常把创立空白页面的这个工夫点称为 First Paint，简称 FP
- 所谓的 白屏工夫 其实指的就是创立这个空白页面到浏览器开始渲染非空白内容的工夫，比方页面背景发生变化等
首次内容绘制（First Contentful Paint，FCP）
- 当用户看见一些 “ 内容 ” 元素被绘制在页面上的工夫点，和白屏是不一样，它能够是 文本 首次绘制，或 SVG 首次呈现，或 Canvas 首次绘制等，即当页面中绘制了第一个像素时，这个工夫点称为 First Content Paint，简称 FCP
首屏工夫 / 最大内容绘制（Largest Contentful Paint, LCP）
- LCP 是一种新的性能度量规范，LCP 侧重于用户体验的性能度量规范，与现有度量规范相比，更容易了解与推理，当首屏内容齐全绘制实现时，这个工夫点称为 Largest Content Paint，简称 LCP
- 最大内容绘制应在 2.5s 内实现
首次输出提早（First Input Delay, FID）
- FID 测量的是当用户第一次在页面上交互的时候（点击链接 、 点击按钮 或 自定义基于 js 的事件），到浏览器理论开始解决这个事件的工夫
- 首次输出提早应在 100ms 内实现
累积布局偏移（Cumulative Layout Shift, CLS)
- CLS 是为了测量 视觉稳定性，以便提供良好的用户体验
- 累积布局偏移应放弃在 0.1 或更少
首字节达到工夫（Time to First Byte，TTFB）
- 指的是浏览器开始收到服务器响应数据的工夫（后盾解决工夫 + 重定向工夫），是反映服务端响应速度的重要指标
- TTFB 工夫如果超过 500ms，用户在关上网页的时就会感觉到显著的期待
性能指标工具

通过上述内容理解了性能指标的相干内容和一些阀值，那么接下来的问题是咱们怎么获取一个网站的具体性能指标数据呢？

为了不便还是得应用工具或者说是 API，当然能够 自定义页面性能指标 的计算形式，比方有些就是通过计算以后页面 DOM 的 总节点数 和 嵌套层级 来计算一个网站的分数等，这里就不再额定介绍。

具体参数介绍能够看 Big [email protected] 大佬的文章，外面介绍的十分具体，这里只列举一些外围点。

Networks 指标

通过 Networks 指标能够查看到对应服务器加载资源的相干信息：

能够将鼠标挪动或点击到具体的申请上查看加载工夫和加载速度，如下：

鼠标移入：

鼠标点击：

通过 Frames 指标能够查看页面每一帧渲染时 CPU 所耗费的工夫和持续时间 Duration 的信息，如下：

图一：

图二：

通过 Timings 指标能够查看在下面列举的一些性能指标的值，如下：

首次绘制（First Paint，FP）
首次内容绘制（First Contentful Paint，FCP）
首屏工夫 / 最大内容绘制（Largest Contentful Paint, LCP）
HTML 文档被齐全加载和解析实现的工夫（DOMContentLoaded, DCL）

Main 指标蕴含了加载过程的三个阶段：

导航阶段
- 次要是解决响应头的数据，并执行一些老页面退出之前的清理操作
解析 HTML 文件阶段
- 次要是解析 HTML 数据、解析 CSS 数据、执行 JavaScript 来生成 DOM 和 CSSOM
生成位图阶段
- 次要是将生成的 DOM 和 CSSOM 合并，包含了布局 (Layout)、分层、绘制、合成等一系列操作

Performance 面板最大的长处就是各种数据信息十分的全，但这也是它最大的毛病，数据信息宏大到须要自行过滤，对于不相熟的开发者来说，还是须要肯定的学习老本的。

相同，Lighthouse 面板中的信息就绝对简洁一些，除了检测后果以外，还会提供对应的改良计划，真是思考得妥妥的，次要检测五个方面的内容：

Performance（性能）
Accessibility（可拜访性）
Best practice（最佳实际）
SEO（搜索引擎优化）
Progressive Web App（渐进式 Web 利用）

能够通过 Analyze page load 按钮来开始对页面利用进行检测，这里以掘金首页为例：

上面以 Performance 性能 为例简略看一下具体蕴含的内容，因为篇幅无限，其余内容可自行测试并进行浏览。

从性能指标的数据来看，只有 累积布局偏移（Cumulative Layout Shift, CLS) 满足要求，其余指标显示黄色和红色，意味着仍有改良的空间，特地是 首屏工夫 是 2.9s 曾经是超过了对应的阈值 2.5s。

性能指标数据如下图所示：

甚至还提供了对应的诊断后果，比方提到的图片没有设置对应的宽高：

甚至还反对在 Node 环境运行，感兴趣的自行去 npm 中查看文档即可，这里不过多介绍。

上述性能指标工具的能力曾经足够弱小，笼罩信息也很全面，但如果咱们须要将页面性能指标数据收集并上报又该怎么办呢？

首先排除的必定是通过 性能指标工具 的形式来收集，一旦要检测性能指标数据意味着得是不同的客户端统计数据的后果合集（ ~~除非你违心一台一台客户端来手动记录和收集数据，呸，你违心你领导还不违心呢~~），最现实的形式当然是主动收集和上报，那就意味着这应该是代码要干的活！！！

既然有这样的需要，那么必然有对应的解决方案，您接着往下看！

实际上在浏览器端的全局对象 window 上有一个名为 performance 的属性，它是一个用于反对 IE9 以上及 webkit 内核浏览器中用于记录页面加载和解析过程中要害工夫点的机制，其兼容性在 caniuse 中的体现如下：

上面就简略介绍一下和 window.performance 相干一些外围属性和办法。

performance.timing 属性中提供了很多要害的工夫信息，咱们能够通过这些工夫节点来简略的计算出须要的性能指标数据（不肯定精确），计算形式如：

const {
 domainLookupStart,
 domainLookupEnd,
 navigationStart,
 loadEventEnd,
 responseStart,
 responseEnd,
 connectStart,
 connectEnd,
 redirectStart,
 redirectEnd,
 domContentLoadedEventEnd,
 domComplete,
} = performance.timing

// DNS 查问工夫
DNS = domainLookupEnd - domainLookupStart

// TCP 建设连接时间
TCP = connectEnd - connectStart

// 页面重定向工夫
Redirect = redirectEnd - redirectStart

// 首字节到底工夫
TTFB = responseStart - navigationStart

// 首次渲染工夫
FP = responseStart - navigationStart

// DOM 解析工夫
DOM = domComplete - responseEnd

// 首屏工夫
LCP = loadEventEnd - navigationStart

performance.getEntries() 办法能够获取所有资源申请的工夫数据，如下：

点击可查看具体的资源信息，其余属性和上述内容有反复，就不在额定介绍计算形式了，具体如下：

performance.now() 办法能够准确计算程序执行工夫，它会返回以微秒（百万分之一秒）为单位的工夫，即更加精准，这也是它和 Date.now() 是不同点：

Date.now() 返回自 1970 年 1 月 1 日 00:00:00 (UTC) 到 以后工夫 的 毫秒数
- 意味着 Date.now() 依赖于零碎的以后工夫，而零碎工夫能够被认为批改，因而它的毫秒数并不精确

performance.now() 的工夫是以恒定速率递增的，不受零碎工夫的影响

// Date.now()
let a = 2, b = 3;
const begin = Date.now();
console.log('a + b =', a + b);

console.log('time =', Date.now() - begin); // 2

// performance.now()
let a = 2, b = 3;
const begin = performance.now();
console.log('a + b =', a + b);

console.log('time =', performance.now() - begin); // 0.10000002384185791

web-vitals 库是 Google 推出的一个小型（约 1.5K）模块化库，用于测量实在用户的所有 Web Vitals 相干的指标，其重要外围指标信息如下（一图胜千言）：

接下来，让咱们通过 npx create-react-app my-react-app 来创立一个 react 我的项目，而后察看一下它的我的项目构造：

是不是超级显眼的 reportWebVitals.js，在进入文件查看你会发现咱们须要的外围性能指标都在外面：

前端性能优化这个内容是之前始终打算要写的，终归常识有所欠缺，到当初也算是边学习边输入中，下一篇 就针对性能优化的计划进行一些总结！！！

如果以上内容对你有所帮忙，来个一键三连，须要光的力量！！！

关于前端:前端性能优化到底该怎么做上-开门见山

前言

前端性能优化到底是在优化什么？

性能指标

RAIL 模型

惯例性能指标

性能指标工具

Performance 面板（Google）

火焰图

Networks 指标

Frames 指标

Timings 指标

Main 指标

Lighthouse 面板（Google）

Performance 性能（触类旁通）

Using the Node CLI

性能指标数据收集

Performance API

performance.timing 属性

performance.getEntries() 办法

performance.now() 办法

Web Vitals

最初

Just My Socks（注册教程内含优惠码）

关于前端:前端性能优化到底该怎么做上-开门见山

前言

前端性能优化到底是在优化什么？

性能指标

RAIL 模型

惯例性能指标

性能指标工具

Performance 面板（Google）

火焰图

Networks 指标

Frames 指标

Timings 指标

Main 指标

Lighthouse 面板（Google）

Performance 性能（触类旁通）

Using the Node CLI

性能指标数据收集

Performance API

performance.timing 属性

performance.getEntries() 办法

performance.now() 办法

Web Vitals

最初

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）