Cómo optimizar el rendimiento del front-end (Parte 1)

¡Trabajar juntos para crear y crecer juntos! Este es el séptimo día de mi participación en el "Nuevo plan diario de los Nuggets · Desafío de actualización de agosto", haga clic para ver los detalles del evento .

prefacio

La optimización del rendimiento de front-end es otra palabra que suena muy bien, de hecho, porque es necesaria 高在性能，大在范围. Afortunadamente, muchos grandes ya han generado una gran cantidad de contenido de alta calidad para su referencia. El autor también está aprendiendo y comprendiendo este contenido recientemente. Si hay una comprensión inapropiada de algunos de los siguientes, ¡puedes corregirlo en el área de comentarios! ! !

El contenido de la optimización del rendimiento de front-end está planeado para dividirse en dos partes . Originalmente planeé terminar una parte, pero descubrí que la parte de conocimientos previos ya ha ocupado el 3000+texto . Por lo tanto, este artículo explica principalmente algunos conocimientos previos. requisitos que deben ser entendidos.

¿Qué es exactamente lo que optimiza la optimización del rendimiento de front-end?

De hecho, el núcleo de la optimización del rendimiento front-end son dos puntos:

• Carga de recursos más rápida garantizada : cuanto más rápido es el renderizado, más rápido se muestra la vista
• Garantice una mayor velocidad de renderizado/velocidad de interacción de la vista : el usuario interactúa con la página, la premisa es que la página necesita ser renderizada, y la segunda es que la página necesita ser retroalimentada lo antes posible, el propósito es garantizar una buena experiencia de usuario

Y estos contenidos básicos se pueden ampliar a partir de la siguiente pregunta común.

¿Qué sucede desde la entrada URLhasta la finalización de la carga de la página?

Creo que hasta ahora, se puede decir que la respuesta de todos a esta pregunta es capaz de elocuentemente (如果不能，请忽略)! Sin embargo, la dirección y el enfoque de cada respuesta deben ser diferentes. Por ejemplo B 站, winterla perspectiva y el análisis del tipo grande al escuchar este tema es más profundo y amplio.

Aquí hay un breve resumen del contenido principal:

• DNSanalizar
• establecer TCPconexión
• Cliente envía HTTPsolicitud
• HTTPrecurso de respuesta del servidor
• 浏览器获取响应内容，进行解析和渲染

以上任意一点都可进行无限扩展、延伸，但点到为止才是现在真正需要的。

性能指标

RAIL 模型

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 的 总节点数 和 嵌套层级 来计算一个网站的分数等，这里就不再额外介绍。

Performance 面板（Google）

具体参数介绍可以看 Big shark@LX 大佬的文章，里面介绍的非常详细，这里只列举一些核心点。

火焰图

Networks 指标

通过 Networks 指标可以查看到对应服务器加载资源的相关信息：

可以将鼠标 移动 或 点击 到具体的请求上查看加载时间和加载速度，如下：

鼠标移入：

鼠标点击：

Frames 指标

通过 Frames 指标可以查看页面每一帧渲染时 CPU 所消耗的时间和持续时间 Duration 的信息，如下：

图一：

图二：

Timings 指标

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

• 首次绘制（First Paint，FP）
• 首次内容绘制（First Contentful Paint，FCP）
• 首屏时间 / 最大内容绘制（Largest Contentful Paint, LCP）
• HTML 文档被完全加载 和 解析完成的时间（DOMContentLoaded, DCL）

Main 指标

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

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

Lighthouse 面板（Google）

Performance 面板最大的优点就是各种数据信息非常的全，但这也是它最大的缺点，数据信息庞大到需要自行过滤，对于不熟悉的开发者来说，还是需要一定的学习成本的。

相反，Lighthouse 面板中的信息就相对简洁一些，除了检测结果以外，还会提供对应的改进方案，真是考虑得妥妥的，主要检测五个方面的内容：

• Performance（性能）
• Accessibility（可访问性）
• Best practice（最佳实践）
• SEO（搜索引擎优化）
• Progressive Web App（渐进式 Web 应用）

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

下面以 Performance 性能 为例简单看一下具体包含的内容，由于篇幅有限，其他内容可自行测试并进行阅读。

Performance 性能（举一反三）

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

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

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

Using the Node CLI

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

性能指标数据收集

上述性能指标工具的能力已经足够强大，覆盖信息也很全面，但如果我们需要将页面性能指标数据收集并上报又该怎么办呢？

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

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

Performance API

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

下面就简单介绍一下和 window.performance 相关一些核心属性和方法。

performance.timing 属性

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.getEntries() 方法可以获取所有资源请求的时间数据，如下：

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

performance.now() 方法

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

• Date.now() 返回自 1970年1月1日 00:00:00 (UTC) 到 当前时间 的 毫秒数

  • los medios Date.now()dependen de la hora actual del sistema, que puede considerarse modificada, por lo que no es precisa en milisegundos

• performance.now()El tiempo se incrementa a un ritmo constante y no se ve afectado por el tiempo del sistema

  // 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 vitales

web-vitalsLa biblioteca Googlees una 1.5Kbiblioteca modular pequeña (aproximadamente) que se utiliza para medir todos los indicadores Web Vitalsrelevantes . Su información de indicador central importante es la siguiente (una imagen vale más que mil palabras):

A continuación, npx create-react-app my-react-appcreemos un reactproyecto con y echemos un vistazo a su estructura de proyecto:

¿Es súper llamativo? reportWebVitals.jsDespués de ingresar el archivo, encontrará que los indicadores de rendimiento básicos que necesitamos están todos en él:

Al final

El contenido de la optimización del rendimiento de front-end ha sido planeado para escribirse antes. Después de todo, hay una falta de conocimiento. Hasta ahora, puede considerarse como salida mientras se aprende. ¡El próximo artículo resumirá algunas soluciones de optimización del rendimiento! ! !

Si el contenido anterior es útil para usted, acceda a tres enlaces con un solo clic, ¡necesita el poder de la luz! ! !