Web性能优化

查看更多学习笔记：GitHub：LoveEmiliaForever
MDN中文官网
性能优良的网站能够提高访问者留存和用户满意度，减少客户端和服务器之间传输的数据量可降低各方的成本
不同的业务目标和用户需求需要不同的性能度量，要提高网站性能，你需要了解用户体验、加载和渲染性能，以及如何将性能度量与业务指标结合起来

什么是Web性能

• 减少总体负载时间
  • 一般策略是使文件尽可能小，尽可能减少 HTTP 请求的次数，并采用巧妙的加载技术（例如 preload）使文件更快可用
• 尽快使网站可用
  • 以合理的顺序加载你的网站资源，以便用户能够更快地开始使用
  • 有时我们也会在实际需要时才加载资源（这被称为懒加载）
  • 从开始加载，到达到可用状态为止所需的时间被称为交互等待时间
• 流畅性和交互性
  • 在制作流畅的应用程序时，有很多优秀实践可以参考
  • 使用 CSS 动画而不是 JavaScript，尽量减少由于 DOM 变化而引起重绘 UI 的次数
• 感知性能
  • 用户感受到的性能与任何客观统计数据一样重要，甚至可能更重要
  • 通过显示“加载中”的旋转指示器或一系列有用的提示和技巧（或笑话，以及其他你认为合适的内容）来保持用户在等待期间的参与度
• 性能测量
  • Web 性能包括测量应用程序的实际速度和感知速度，然后监视性能

许多特性都会影响性能：延迟、应用程序大小、DOM 节点数量、资源请求数量、JavaScript 性能、CPU 负载等等
重要的是尽量缩短加载和响应时间，并通过增加额外的功能来隐藏延迟
而在此之前，应该要了解一些基础知识：

• 关键路径
  • 它是服务器下载文件后，浏览器用来构建 web 文档的过程
  • 可以查看我的笔记：浏览器关键路径-学习笔记
  • 或MDN文档：关键渲染路径
• 浏览器工作原理
  • 知晓浏览器是如何工作的有利于我们对Web性能优化有个整体视野
  • 我的笔记：浏览器工作原理-学习笔记
  • MDN文档：渲染页面：浏览器的工作原理
• 源顺序
  • HTML 索引文件的源顺序会显著影响性能
  • 也就是HTML中的<link>、<script>等，它们通常是按序下载
• 文档对象模型
  • 也就是DOM，它是一种树状结构，具体知识在JS学习中有
• 延迟
  • 延迟是你的网站信息从服务器传输到用户计算机所需的时间
  • 包括：建立连接消耗的时间、传输消耗时间
  • 我的笔记：CDN与网络延迟-学习笔记
  • MDN英文文档：Understanding latency

感知性能

感知性能是用户对网站速度的感受，它是主观感受，但是非常重要
虽然是主观感受，但是也可以用客观的评价指标来大致说明它

感知性能指标

虽然指标不能绝对度量用户性能感知，但是可以作为一种相关提示

• 首次绘制时间：第一次绘制运算开始的时间
• 首次有内容绘制时间：第一次重要渲染（如：文本、前景或背景图像、画布或 SVG 等）开始的时间
• 首次有意义绘制时间：第一次有用的内容渲染到屏幕上的时间
• 最大内容绘制时间：视口中可见的最大内容元素的渲染时间
• 速度指数：测量可见屏幕上像素绘制的平均时间
• 可交互时间：UI 可用于用户交互的时间

感知性能提升tips

最小化初始加载

首先下载用户将立即与之交互的内容，然后在“后台”下载其余内容
将交互功能与内容分开，并加载初始加载时可见的文本、样式和图像，延迟或懒加载在初始页面加载时未使用或不可见的图像或脚本
图像和视频应以最佳格式、经过压缩和正确尺寸提供，减少其大小

防止内容跳转和重排

图片或其他资源导致内容下移或跳转到不同位置（例如第三方广告的加载），会让页面感觉仍在加载中，这对感知性能是不利的
如果某些资源的加载速度比其他资源慢，在其他内容已经显示在屏幕上之后才加载这些元素，那么就需要提前规划，在布局中为它们留出空间，以便内容不会跳动或改变大小

避免字体文件延迟

从感知性能的角度来看，“字体导入不佳”可能会导致文本在样式化或回退到其他字体时出现闪烁
使回退字体具有相同的大小和粗细，以便在字体加载时页面变化不那么明显

确保可交互性

确保可见的可交互元素始终可交互且可响应，如果输入元素可见，用户应能够无延迟与它们交互
当响应时间超过50 毫秒时，用户会感受到延迟
内容重绘速度慢于16.67 毫秒，或者重绘间隔不均匀时，会感觉页面卡顿不流畅

让任务启动器更有交互性

在按下按键keydown时发出内容请求，而不是等待按键弹起keyup，可以使内容加载的感知时间减少 200 毫秒
向 keyup 事件添加有趣但不引人注目的 200 毫秒动画，可以再减少 200 毫秒的加载感知

测量性能

测量性能提供了一个重要的指标，以帮助你评估应用程序、网站或 web 服务的成功程度
它们应以一致的方式收集和测量，并以普通人可以使用和理解的格式进行分析

对于这些指标，有着许多工具能够帮助进行测量，它们分为两大类

• 表明或测量性能的工具：直接展示了你的网站加载的快慢，也指出了你的 Web 应用程序中可以优化的区域
• 可以用来构建自定义性能工具的性能 API

通用性能报告工具

像 webpagetest.org(推荐)、PageSpeed Insights 这样的工具可以衡量网站的性能
输入一个 URL，并在几秒钟内获得一份详细的性能报告
性能报告包含有关用户在页面上显示任何内容之前需要等待多长时间、显示页面需要下载多少字节等信息

网络监视工具

按F12打开浏览器开发者工具，能够看到网络选项，使用它即可监视网络情况

性能监视工具

同样的，在浏览器开发者工具中还可以监视网站性能

性能API

有着各种各样的API可以用来创建自己的性能测量工具
MDN文档-性能API

关于图片的优化

图片占据了非常多的资源空间，优化它对于提高web性能的效果立竿见影
对于一般网站而言，其带宽的 51% 来自图像，其次是视频占 25%
我们需要考虑流量问题，许多人使用的是有限流量套餐，甚至是按使用量付费，每兆字节都要付费
还需要考虑内存问题，因为许多移动设备的 RAM 有限，优化太差会很卡

图片加载优化

虽然图片下载耗时长，但是对感知性能的影响却没有很大，我们先用占位符代替图片
虽然如此，但能更快下载好图片，就应该更快下载好

页面整体懒加载

对于大多数网站来说，最大的改进之一是 延迟加载(懒加载) 可视区域以下的图像
而不是在初始页面加载时，无论访客是否滚动查看，都下载所有这些内容
例如GitHub:lazysizes库就可以帮助实现这个功能

图片格式优化

根据不同图像的特点，可以选择最适合的图片格式，可以查看MDN：图像格式指南

SVG格式的图片，适合于图标，徽标等
它是矢量的，放大缩小不会失真，但是适用范围比较小
可以用在线的一些工具调整SVG图片，如SVGOMG

PNG格式是比较常见的，它支持透明度，因此比较大，常见有以下三种情况

• RGB通道+Alpha通道：32bit/px，图片质量好，但是图片大小比较大
• Grey通道+Alpha通道：16bit/px，颜色很少，支持平滑的透明度
• Grey通道+Aplha比特：9bit/px，颜色很少，只有有和无透明度

对于PNG，也有很多的在线工具使用，如ImageOptim、Squoosh

JPEG格式是不具有透明度的图片格式，但也很广泛使用
其中，有一个叫做渐进式JPEG的技术，用户先看到的是一个低分辨率的图像版本，随着图像下载而逐渐清晰，而不是图像以全分辨率从上到下加载，或者只有在完全下载后才显示

推荐使用在线工具处理JPEG图片，如在Squoosh里面就有MozJPEG压缩选项

可以看到，图片由1.62MB，直接压缩到了154KB，效果显著

其它还有一些图片的格式，它们在压缩方面更加厉害，但是不是所有浏览器都支持

• WebP：既适用于图像又适用于动图的绝佳选择，非常不错的格式，但是不支持渐进式显示，除了Safari的14以前的浏览器外其它浏览器都支持它
• AVIF：高性能和免费的图像格式，性能高于WebP，但只有 Chrome、Opera 和 Firefox 支持
• JPEG2000：仅受 Safari 支持，也不支持渐进式显示

虽然有这么多图片格式，但是你又不是只能选择一种是不是？
使用响应式图片技术，你的web可以根据情况选择最适合的图片格式进行下载
甚至还有一些帮助你构建响应式图片的在线工具Cloudinary

图片最佳尺寸

对于较小的屏幕，应该提供更低分辨率的图像，而对于较大的屏幕则相反
此外，为那些具有高 DPI 屏幕的设备应该提供更高分辨率的图像

这些都是响应式图片涉及的内容，可以查看MDN：响应式图片

对于图片在高DPI屏幕上，有两个有用的客观事实：

• 在高 DPI 屏幕上，人眼对压缩伪影的敏感度要低得多，这意味着对于这些屏幕上的图像，你可以使用非常高的压缩程度来压缩图片
• 只有很少的人能够察觉到超过 2 倍 DPI 的分辨率增加，这意味着你不需要提供超过 2 倍分辨率的图像

控制图片下载顺序

将最重要的图像优先展示给访问者会提供更好的感知性能
通过采用优先级提示（Priority Hints），你可以进一步控制优先级，只需在图像标签中添加 fetchPriority 属性即可

图片渲染优化

由于图像是异步加载的，并且在第一次绘制后继续加载，如果在加载之前未定义其尺寸，它们可能会导致页面内容重新布局
因此，你需要设置 width 和 height 属性，以便浏览器可以在布局中为它们预留空间
这也是优化感知性能的重要环节

浏览器在实际加载图像之前有一种调整图像大小的机制

1. <img>、<video> 或 <input type="button">元素设置了 width 和 height 属性时，它的宽高比会在加载前计算出来，并使用提供的尺寸提供给浏览器
2. 根据宽高比计算出图片的高度，并将正确的尺寸赋给 <img> 元素，宽高比仅在图片加载时用于保留空间
3. 一旦图片加载完成，将使用加载的图片的实际宽高比，而不是属性中的宽高比

这样做的好处，是可以优化渲染的流程，减少卡顿、尺寸不精确等

关于视频的优化

对于一般网站来说，25% 的带宽来自视频，所以对视频的优化也很重要

压缩视频

视频也有着许多格式，在web上常见的有WebM、MPEG-4/H.264、Ogg/Theora
有着很多本地使用的视频编辑工具都有格式转换功能，也可以查看线上工具如FFmpeg

优化视频的<source>顺序

根据需要，选择最适合的顺序，是低带宽优先？还是高质量优先？
不同的环境和要求下，有着不同的选择

为静音的视频移除音轨

没理由要为了静音的视频传输音轨过去，例如首页动画这类的就不需要音轨
删除音频可以节省 20% 的带宽
而删除音轨的操作，需要在本地的视频编辑软件中进行

视频预加载

预加载属性preload有三个可用选项：auto|metadata|none，默认设置是 metadata

• none：在播放开始之前，视频不会被下载
• metadata：在页面加载时下载视频的一小部分
• auto：自动下载整个视频

根据视频资源的重要程度，可以结合使用预加载参数，来构建合理的加载策略

流媒体与动态质量

流媒体的视频，视频数据将会像流一样传输，也就是视频一边传输，网站一边播放
由于这个特性，可以动态调整视频的质量，做到这一秒是1080p，下一秒就变成480p
不过，这一技术应该要仔细研究才能使用，应该自己找找有没有更好的讲解资源

JS优化

JS脚本会显著影响下载时间、渲染性能、CPU 和电池使用

JS下载优化

• 评估是否应该使用框架，某些项目十分简单，根本不必要使用框架进行开发
• 简约设计，某些页面有很多的绚丽特效（如拼多多），但是它们真的有必要吗？
• 删除无用代码，解释性语言的特性决定了所有的代码都会被解析，优化代码就很必要
• 使用浏览器内置功能，某些功能浏览器已经内置了，不需要再用JS实现一遍

使用JS模块设计程序整体结构，把大文件拆分为多个小文件，以及把代码分为关键文件和非关键文件，对于优化加载，以及按需导入都很重要
最后，可以进行代码压缩减少文件大小，再使用Gzip进一步压缩文件
使用Webpack这类的构建工具会很方便的完成这些事情

处理解析和执行

默认情况下，JavaScript 的解析和执行会阻塞渲染
浏览器在遇到 JavaScript 之后，会阻塞解析任何出现在其后的 HTML 代码，直到脚本处理完成
因此，要充分考虑代码的运行时机和运行方式

优先加载关键资源

如果某个脚本非常重要，而且担心加载速度影响性能，那么可以在<head>中加载它（不推荐）

<head>
  <script src="main.js"></script>
</head>

上面的方法会阻塞渲染，更好的方法是使用rel="preload"来为JS文件创建一个预加载器

<head>
  <!-- 预加载 JavaScript 文件 -->
  <link rel="preload" href="important-js.js" as="script" />
  <!-- 预加载 JavaScript 模块 -->
  <link rel="modulepreload" href="important-module.js" />
</head>

预加载是异步的，因此不能保障文件是否加载完成，可能你使用它时它还没加载好

延后非关键脚本的执行

应该尽量推迟解析和执行非关键 JavaScript 的时间，直到它真正需要时再加载，以减少阻塞

例如，可以给<script>设置async或defer

<head>
  <script async src="main.js"></script>
</head>

或者，可以在HTML和JS中动态加载脚本

• 通过DOM操作，添加<script>来动态决定请求脚本的时机
• 通过import().then(() => {})来动态引入JS模块

原子化任务操作

浏览器运行脚本时，会按序运行其中的操作任务
任务大部分都在主线程上运行，有一些在Worker上运行，主线程一次只能运行一个任务

一个耗时超过50ms的任务，会让用户感觉到延迟，导致看起来卡卡的
所以，把大任务分解成小任务会让使用体验更好，就像是CPU的时间片一样

具体操作为，使用await和Promise来进行异步操作，以让出线程

合理使用JS动画

动画效果如果很多很复杂，那么会明显降低性能，会卡卡的（如：拼多多）

• 非必要，不使用动画，减少动画的数量和复杂度
• 提供动画的开关按钮，让用户自主选择能否开启动画效果
• 尽可能使用CSS动画，CSS动画的性能要明显优于JS动画，使用JS动画时，尽可能以操作DOM的方式实现而不要用操作CSS的方式实现
• 如果要进行非常高定制化的动画，推荐使用<canvas>

优化事件性能

跟踪及处理事件是很耗资源的，特别是当你持续运行一个事件时（如：跟踪鼠标位置）
最好动态删除不再需要的事件监听器，以减少资源浪费
尽可能使用事件委托，当你有一些代码需要在用户与大量子元素中的任何一个进行交互时，可以在它们的父元素上设置事件监听器

高效JS代码最佳实践

• 减少DOM操作：访问和更新 DOM 的计算成本很高
• 批量进行 DOM 更改：对于 DOM 更改，你应该将它们按批次统一处理，而不是分散执行
• 简化HTML代码：DOM 树越简单，使用 JavaScript 进行访问和操作的速度就越快
• 减少循环代码：循环是很消耗资源的，因此尽可能减少代码中的循环，使用break或continue
• 使用多线程处理高开销任务：
  • 异步进行高开销操作
  • 使用Worker来进行高开销运算
  • 使用WebGPU进行图像和3D模型操作（但这太底层，比较难掌握）

HTML优化

HTML理论上应该要保证快速、易于访问，这两个是基本要求
HTML主要是文本，因此比较快，所以真正影响网页性能有三大点

• 图像和视频：可以使用上面介绍的对图像和视频的优化方式进行优化
• 嵌入内容：尽可能不要用嵌入内容<iframe>，会影响性能
• 资源加载顺序：合理的安排资源加载顺序，以及合理利用preload

使用响应式设计

利用媒体查询技术，以及响应式设计，可以为不同的设备提供最合适的网页
这样就不会造成资源浪费，一般在图像和视频上使用较多

图片懒加载技术，指图片仅在实际对用户可见时加载
浏览器现今可以使用loading属性，指示<img>标签以进行图片懒加载
以及，在设置<video>时，指示preload属性的值，以合适的方式加载视频

嵌入内容的处理

对于嵌入内容，只有一个建议：不必要就不要使用<iframe>
此外，<iframe>同样可以使用loading属性，指示进行懒加载

处理资源加载顺序

对于JS资源的处理，可以参照上面介绍的JS优化来进行

对于链接到其它资源时资源的获取，可以使用预加载
一般即使用rel="preload"将<link>转换为预加载器

CSS优化

优化渲染

由于浏览器的运行原理，只有在下载完所有CSS并生成CSSOM后，浏览器才能够绘制画面
因此，优化CSSOM的构建可以提高页面性能

• 删除非必要样式：删除不会影响绘制结果的CSS样式可以加快CSSOM构建
• 原子化CSS文件：将CSS模块化，并延迟加载非必要CSS，可以减少渲染阻塞
• 压缩CSS文件：可以使用CSS压缩工具，再使用gzip压缩
• 简化选择器：越具体的选择器开销越大，减少选择器复杂度会优化性能
• 不要将样式应用于不需要的元素：这种类型的操作会对性能产生负面影响，特别是在较大的站点上
• 使用CSS精灵图：CSS 精灵图 是一种技术，它将你希望在站点上使用的多个小图像（例如图标）放入单个图像文件中，然后使用不同的 background-position 值在不同的位置显示图像的一部分，这可以大大减少获取图像所需的 HTTP 请求数量
• 预加载重要资源：使用预加载器

动画优化

• 减少使用动画
• 提供控制动画播放与否的选项
• 使用CSS动画，而非JS动画

慎重选择要进行动画处理的属性，某些属性在进行动画处理时会触发回流、重绘
避免使用下面的属性做动画：

• 修改元素的尺寸：如：width、height、border 和 padding
• 重新定位元素：如：margin、top、bottom、left 和 right
• 更改元素的布局：如：align-content、align-items 和 flex
• 添加改变元素几何形状的视觉效果：如：box-shadow

浏览器是很智能的，仅会重绘被更改的区域，因此动画越大开销越多
在使用动画时，transforms、opacity、filter都不会引起回流或重绘

在GPU上处理动画

将动画处理工作转移到主线程之外，并放到设备的 GPU 上进行，也称为合成
这可以通过选择特定类型的动画来实现，浏览器会自动将这些动画发送到 GPU 来处理

• 3D 变换动画，例如 transform: translateZ() 和 rotate3d()
• 具有某些其他属性动画的元素，例如 position: fixed
• 应用了 will-change 的元素
• 特定的在其自己层中渲染的元素，包括 <video>、<canvas> 和 <iframe>

使用will-change

浏览器可能会在元素实际发生变化之前进行优化设置
这类优化可以通过提前完成可能需要的大量工作，提高页面的响应速度
CSS 的will-change属性向浏览器提示元素预期的变化方式

.element {
  will-change: opacity, transform;
}

优化渲染阻塞

CSS可以使用媒体查询将样式限定在特定条件下
而浏览器会阻塞渲染直到解析完所有的CSS样式，但不会阻塞不会使用的样式
通过根据媒体查询将 CSS 拆分为多个文件，可以防止在下载未使用的 CSS 时阻塞渲染

改善字体性能

字体加载

字体仅在使用 font-family 属性应用于元素时才会加载，而不是在首次使用 @font-face 规则引用时加载

/* 字体在此处没有加载 */
@font-face {
  font-family: "Open Sans";
  src: url("OpenSans-Regular-webfont.woff2") format("woff2");
}

h1,
h2,
h3 {
  /* 字体实际上在此处加载 */
  font-family: "Open Sans";
}

所以，使用 rel="preload" 来提前加载重要的字体可以让字体更快可用

<link
  rel="preload"
  href="OpenSans-Regular-webfont.woff2"
  as="font"
  type="font/woff2"
  crossorigin />

只加载需要的字形

如果你知道你将使用特定的字形集（例如，仅用于标题或特定标点符号字符的字形），你可以限制浏览器需要下载的字形数量
这可以通过创建仅包含所需子集的字体文件来实现，这个过程叫做子集化
然后可以使用 @font-face 的 unicode-range 描述符来指定何时使用你的子集字体

@font-face {
  font-family: "Open Sans";
  src: url("OpenSans-Regular-webfont.woff2") format("woff2");
  unicode-range: U+0025-00FF;
}

字体回退

应用于 @font-face 规则的 font-display 描述符定义了浏览器加载和显示字体文件的方式，使得文字在字体正在加载或加载失败时都能以备用字体显示
代价是出现未样式化文本的闪烁

@font-face {
  font-family: someFont;
  src: url(/path/to/fonts/someFont.woff) format("woff");
  font-weight: 400;
  font-style: normal;
  font-display: fallback;
}

使用 CSS 局限进行样式重新计算的优化

通过使用 CSS 局限模块中定义的属性，你可以指示浏览器将页面的不同部分隔离开来，并独立地优化它们的渲染
这允许在渲染各个部分时提高性能。例如，你可以指定浏览器在特定容器于视口中可见之前不要渲染它们

contain 属性允许作者精确指定要应用于页面上各个容器的局限类型
这使得浏览器可以针对 DOM 的一部分重新计算布局、样式、绘制、大小或它们的任意组合

article {
  contain: content;
}

content-visibility 属性是一个有用的快捷方式，允许作者在一组容器上应用一组强大的局限，并指定浏览器在需要之前不要布局和渲染这些容器
contain-intrinsic-size 也可用，它允许你为容器提供一个占位大小，同时它们受到局限的影响

article {
  content-visibility: auto;
  contain-intrinsic-size: 1000px;
}

### 使用 CSS 局限进行样式重新计算的优化

通过使用 CSS 局限模块中定义的属性，你可以指示浏览器将页面的不同部分隔离开来，并独立地优化它们的渲染  
这允许在渲染各个部分时提高性能。例如，你可以指定浏览器在特定容器于视口中可见之前不要渲染它们  

`contain` 属性允许作者精确指定要应用于页面上各个容器的局限类型  
这使得浏览器可以针对 DOM 的一部分重新计算布局、样式、绘制、大小或它们的任意组合  

```css
article {
  contain: content;
}

content-visibility 属性是一个有用的快捷方式，允许作者在一组容器上应用一组强大的局限，并指定浏览器在需要之前不要布局和渲染这些容器
contain-intrinsic-size 也可用，它允许你为容器提供一个占位大小，同时它们受到局限的影响

article {
  content-visibility: auto;
  contain-intrinsic-size: 1000px;
}