antecedentes
El rendimiento es la columna vertebral de los sitios web y las aplicaciones. Con un alto rendimiento del sitio web, la experiencia del usuario será mejor. Al mismo tiempo, la velocidad del sitio web también es un factor en la clasificación de los motores de búsqueda. Por lo tanto, el buen desempeño del sitio web afecta directamente a nuestros indicadores de ingresos, por lo que es necesario mejorar el desempeño del sitio web para obtener beneficios comerciales desde el punto de vista técnico.
Métricas de optimización del rendimiento
El modelo RAIL es un conjunto de modelos de rendimiento centrados en el usuario proporcionados por Google, que proporciona una estructura que considera el rendimiento. El modelo divide la experiencia del usuario en acciones clave (p. ej., hacer clic, desplazarse, cargar) y lo ayuda a definir objetivos de rendimiento para cada acción. FERROCARRIL significa:
- Respuesta: Respuesta
- Animación: animación
- inactivo: inactivo
- carga: carga
Como se muestra abajo:
respuesta
Las transiciones iniciadas por la entrada del usuario se completan en 100 milisegundos, lo que hace que la interacción se sienta instantánea para el usuario.
- Para garantizar una respuesta visible dentro de los 100 ms, los eventos de entrada del usuario deben procesarse dentro de los 50 ms. Esto funciona para la mayoría de las entradas, como hacer clic en un botón, alternar un control de formulario o iniciar una animación. Sin embargo, esto no funciona con el arrastre o el desplazamiento táctil.
- Por paradójico que pueda parecer, responder a la entrada del usuario al instante no siempre es lo correcto. Puede usar esta ventana de 100 milisegundos para realizar otro trabajo que requiera muchos recursos, pero tenga cuidado de no entorpecer al usuario. Debería funcionar en segundo plano si es posible.
- Siéntase libre de proporcionar comentarios sobre las operaciones que tardan más de 50 ms en completarse.
50 ms o 100 ms?
El objetivo es responder a la entrada dentro de los 100 ms, entonces, ¿por qué solo tenemos un presupuesto de 50 ms? Esto se debe a que, a menudo, hay trabajo que debe realizarse además del procesamiento de entrada, y ese trabajo ocupa parte del tiempo disponible para una respuesta de entrada aceptable. Si una aplicación ejecuta trabajo en los fragmentos de 50 ms recomendados durante el tiempo de inactividad, esto significa que si se produce una entrada en uno de estos fragmentos de trabajo, puede ponerse en cola hasta 50 ms. Con esto en mente, es seguro asumir que solo los 50 milisegundos restantes están disponibles para el procesamiento de entrada real. Este efecto se ilustra en el siguiente diagrama, que muestra cómo se pone en cola la entrada recibida durante las tareas inactivas, lo que reduce el tiempo de procesamiento disponible:
animación
Generar un marco en 10ms
- 在 10 毫秒或更短的时间内生成动画的每一帧。从技术上来讲，每帧的最大预算为 16 毫秒（1000 毫秒/每秒 60 帧≈16 毫秒），但是，浏览器需要大约 6 毫秒来渲染一帧，因此，准则为每帧 10 毫秒。
- 目标为流畅的视觉效果。用户会注意到帧速率的变化。
空闲
最大限度增加空闲时间以提高页面在 50 毫秒内响应用户输入的几率。
加载
- 根据用户的设备和网络能力优化相关的快速加载性能。目前，对于首次加载，在使用速度较慢 3G 连接的中端移动设备上，理想的目标是在 5 秒或更短的时间内实现可交互。
- 对于后续加载，理想的目标是在 2 秒内加载页面。
通过APIs动态获取指标
如何通过api来获取网页的一些实时的指标数据，对我们做优化非常重要。一般情况，我们通过performance对象来获取常规的性能指标数据。 下面我们只介绍我们最常用的值
- navigationStart: 浏览器处理当前网页的启动时间
- fetchStart:浏览器发起HTTP读取文档的毫秒时间戳
- domainLookupStart: 域名查询开始的时间戳
- domainLookupEnd: 域名查询结束的时间戳
- connectStart: HTTP请求开始向服务器发送的时间戳
- connectEnd: 浏览器与服务器链接建立
- requestStart: 浏览器向服务器发出HTTP请求的时间戳
- responseStart: 浏览器从服务器收到第一个字节的时间戳
- responseEnd: 浏览器从服务器收到最后一个字节的时间戳
- domLoading: 浏览器开始解析网页DOM结构的时间
- domInteractive: 网页DOM树创建完成，开始加载内嵌资源时间
- domContentLoadEventStart: 网页domContentLoadd时间发生时的时间错
- domContentLoadedEventEnd: 网页所有需要执行的脚本执行完成的时间， domReady的时间
- loadEventStart: 当前网页load事件回调函数开始执行的时间戳
- loadEventEnd: 当前网页load事件回调函数执行结束的时间戳
| 性能数据名称 | 描述 | 计算方法 |
|---|---|---|
| DNS查询时间耗时 | DNS解析耗时 | domainLookupEnd - domainLookupStart |
| 请求响应耗时 | 网络请求耗时 | responseStart - requestStart |
| DOM解析耗时 | DOM解析耗时 | domInteractive - responseEnd |
| 资源加载耗时 | 资源加载耗时 | loadEventStart - domContentLoadedEventEend |
| DOM_READY耗时 | DOM阶段渲染耗时 | domContentLoadedEventEend - fetchStart |
| 首次渲染耗时 | 首次渲染时间/白屏时间 | responseEnd - fetchStart |
| 首次可交互耗时 | 首次可交互耗时 | domInteractive - fetchStart |
| 首包时间耗时 | 首包时间 | responseStart - domainLookupStart |
| 页面完全加载耗时 | 页面完全加载时间 | loadEventStart - fetchStart |
| TCP链接时间 | TCP链接耗时 | connectEnd - connectStart |
自定义指标采集 我们可以通过自定义一些指标来采集我们想要的数据
const observer = new PerformanceObserver((list) => {
for(const entry of list.getEntries) {
console.log(entry)
}
})
observer.observe({ entryTypes: ['longtask'] })
复制代码可以通过PerformanceObserver.supportedEntryTypes属性来查看支持哪些属性
性能优化的工具
有一些工具可以帮助您自动执行 RAIL 测量。具体使用哪一种取决于您需要什么类型的信息，以及您喜欢什么类型的工作流程。
Chrome DevTools #
Chrome DevTools 对加载或运行页面时发生的一切活动进行深入分析。请参阅分析运行时性能入门，熟悉性能面板 UI。
以下 DevTools 功能密切相关：
- 限制 CPU 性能来模拟功能较弱的设备。
- 限制网络速度来模拟速度较慢的连接。
- 查看主线程活动，以查看记录时主线程上发生的每个事件。
- 查看表中的主线程活动，以根据活动占用的时间多少来对活动进行排序。
- 分析每秒帧数 (FPS) 以衡量您的动画能否真正流畅地运行。
- 使用性能监视器 (Performance Monitor) 实时监控 CPU 使用率、JS 堆大小、DOM 节点数、每秒布局数等。
- 使用网络部分可视化记录时发生的网络请求。
- 在记录时捕获屏幕截图，以便准确回放加载页面时页面的外观，或触发的动画等。
- 查看交互，以便快速识别用户与其交互后，页面上发生的情况。
- 通过在潜在问题侦听器触发时突出显示页面来实时查找滚动性能问题。
- 实时查看绘制事件，以便识别可能损害动画性能的高资源消耗绘制事件。
Lighthouse #
web.dev/measure 下的 Chrome DevTools 中以 Chrome 扩展和 Node.js 模块的形式提供了 Lighthouse，WebPageTest 中也提供了此工具。只要您提供一个 URL，它就会模拟使用速度较慢的 3G 连接的中端设备在页面上运行一系列审核，然后提供关于加载性能的报告以及如何改进的建议。
以下审核密切相关：
响应
- 最大首次输入延迟时间。根据主线程空闲时间估算应用响应用户输入所需的时间。
- 不使用被动侦听器来提高滚动性能。
- 总阻塞时间。测量阻止页面响应用户输入（例如鼠标点击、屏幕点击或按键）的总时间。
- 交互时间。测量用户何时可以稳定地与所有页面元素进行交互。
加载
- 不要注册控制 page 和 start_url 的服务工作进程。服务工作进程可以缓存用户设备上的公共资源，从而减少通过网络获取资源所需的时间。
- 移动网络上的页面加载速度不够快。
- 消除阻塞渲染的资源。
- 延迟处理屏幕外图像。推迟加载屏幕外的图像，在需要时才加载。
- 适当调整图像大小。不要提供明显大于移动视口中呈现的尺寸的图像。
- 避免链接关键请求。
- 不要为其所有资源使用 HTTP/2 。
- 对图像进行高效编码。
- 启用文本压缩。
- Evite sobrecargar la red .
- Evite tamaños de DOM demasiado grandes . Reduzca la cantidad de bytes de red pasando solo los nodos DOM necesarios para representar la página.
WebPageTest herramienta de prueba de rendimiento de la página web #
WebPageTest es una herramienta de prueba de rendimiento de páginas web que utiliza navegadores reales para visitar páginas web y recopilar métricas de tiempo. Ingrese una URL en webpagetest.org/easy y podrá obtener un informe sobre el rendimiento de carga de esa página en un dispositivo Moto G4 real usando una conexión 3G más lenta. También puede configurarlo para incluir la auditoría de Lighthouse.
Referencias
Mida el rendimiento utilizando el modelo RAIL ( web.dev/rail/ )