[TOC]
理解web性能概念以及常用分析工具
理解web性能概念
web性能主要是提升用户体验。核心是:减少等待,使用不卡
以下将分2块介绍:
- 性能指标:目的是 解决等待问题,让用户可以尽快的看到网页,并且可以交互
- 体验优化:目的是 使用过程中不卡,或感觉不那么卡
性能指标
目的:解决等待问题,让用户可以尽快的看到网页,并且可以交互 (以下 指标和工具 重点是和首屏加载相关的)
核心:
- 想尽快看到东西(参考下面FCP)
- 想尽快看全东西(参考下面SI,LCP)
- 想尽快能操作(参考下面TTI,TBT)
- 页面元素布局最好不要移位(参考下面CLS)
如何使用工具来一键生成性能报告,并且给出解决方案?
博主的姊妹篇:web性能分析工具 PageSpeed Insights 和 Lighthouse 使用教程
性能指标介绍
- FCP(First Contentful Paint):首次内容渲染,详细可看博主的姊妹篇:web性能-白屏时间详解以及优化
- from — 用户开始输入url(开始导航) to — 页面出现东西(浏览器渲染第一段DOM。图片、非白色的 < canvas > 元素和 svg 被认为是 DOM 内容,iframe中的任何内容不包含在内)
- TTI(Time to Interactive):首次可操作(比如可点击可滚动)
- from — 用户开始输入url(开始导航) to — 可操作(比如可点击可滚动)
- SI(Speed Index):速度指数
- shows how quickly the contents of a page are visibly populated.
- 显示页面内容(全部内容渲染完成)的速度有多快
- TBT(Total Blocking Time):总阻塞时间
- LCP(Largest Contentful Paint):当前页面上”最大的内容“渲染时间
- 概念诞生的原因:有时候越简单越好。基于 W3C Web 性能工作组的讨论和 Google 的研究,发现一个更准确的测量页面主要内容何时被加载的方法是 查看最大的元素何时被渲染
- 范围:可视区内。具体如何查找最大元素,同上链接
- 概念诞生的原因:有时候越简单越好。基于 W3C Web 性能工作组的讨论和 Google 的研究,发现一个更准确的测量页面主要内容何时被加载的方法是 查看最大的元素何时被渲染
- CLS(Cumulative Layout Shift):累积布局移位
- 可视区内,累积 布局移动的位置
- 意思是 元素的偏移量,比如最开始a元素渲染出现在(1,1)的位置,结果1秒后变成了(7,7)的位值。有可能造成用户的误触
体验优化
目的:使用过程中不卡,或感觉不那么卡(以下重点是 在使用过程中的优化)
能够量化体验的工具暂无。所以下面会举几个例子,以及解决方法,希望能讲清楚一些可能存在的体验问题
计划以2个方面介绍:
- Smoothness and interactivity(流畅性和互动性)
- Perceived performance(可感知的表现,实际可能慢 但给人感觉不慢)
Smoothness and interactivity(流畅性和互动性)
体验点比如:滚动是否平滑?按钮可否点击?弹窗是否迅速打开,并且动画是否平滑过渡?
最佳实践可以参考:
- 使用css动画而不是JavaScript来制作动画
- 要用avaScript来制作动画的话,用window.requestAnimationFrame(),他会告诉浏览器在下次重绘之前调用指定的回调函数更新动画。比生硬的定时器性能高很多
- 最小化由于DOM的变化而需要重排重绘的次数
Perceived performance(可感知的表现,实际可能慢 但给人感觉不慢)
有些时候,你可能很难让你的网站运行得更快,但是你很可能能够让用户感觉它快。
简单举例:
- 一个操作可能需要花费较长时间(例如 调接口,long tasks),可以用一个loading图标+文字(比如“拼命加载中”),告诉用户,你的操作(比如点击)已经生效了,程序已经开始加载了
- 骨架屏
- 大图可以先加载缩略图
- 有广告、图片或者其他资源可能会导致页面重排重绘的话,最好提前就计划好布局,留好空间。(流畅性和互动性也适用这条)
(原创整理,有疑问或错误可以留言。如果有用,谢谢点赞~)
性能优化合集快速入口: