- 原文地址：Front-End Performance Checklist 2018 - Part 3
- 原文作者：Vitaly Friedman
- 译文出自：掘金翻译计划
- 本文永久链接：github.com/xitu/gold-m…
- 译者：Cherry
- 校对者：Ryou、z
下面你将会看到你可能需要考虑到的前端性能优化问题，以保证你的应用具有快速和流畅的响应时间。
- 2018 前端性能优化清单 - 第 1 部分
- 2018 前端性能优化清单 - 第 2 部分
- 2018 前端性能优化清单 - 第 3 部分
- 2018 前端性能优化清单 - 第 4 部分
静态资源优化
- 你是使用 Brotli 还是 Zopfli 进行纯文本压缩？
在 2005 年，Google 推出了 Brotli，一个新的开源无损数据压缩格式，现在 被所有的现代浏览器所支持。实际上，Brotli 比 Gzip 和 Deflate 更有效。取决于设置信息，压缩可能会非常慢。但是缓慢的压缩过程会提高压缩率，并且仍然可以快速解压。当然，解压缩速度很快。
只有当用户通过 HTTPS 访问网站时，浏览器才会采用。Brotli 现在还不能预装在某些服务器上，而且如果不自己构建 NGINX 和 UBUNTU 的话很难部署。不过这也并不难。实际上，一些 CDN 是支持的，甚至 可以也可以通过服务器在不支持 CDN 的情况下启用 Brotli。
在最高级别的压缩下，Brotli 的速度会变得非常慢，以至于服务器在等待动态压缩资源时开始发送响应所花费的时间可能会使文件大小的任何潜在收益都无效。但是，对于静态压缩，高压缩比的设置比较受欢迎 —— （感谢 Jeremy!）
或者，你可以考虑使用 Zopfli 的压缩算法，将数据编码为 Deflate，Gzip 和 Zlib 格式。Zopfli 改进的 Deflate 编码使得任何使用 Gzip 压缩的文件受益，因为这些文件大小比 用Zlib 最强压缩后还要小 3％ 到 8％。问题在于压缩文件的时间是原来的大约 80倍。这就是为什么虽然 使用 Zopfli 是一个好主意但是变化并不大，文件都需要设计为只压缩一次可以多次下载的。
比较好的方法是你可以绕过动态压缩静态资源的成本。Brotli 和 Zopfli 都可以用于明文传输 —— HTML，CSS，SVG，JavaScript 等。
有什么方法呢？在最高等级和 Brotli 的 1-4 级动态压缩 HTML 使用 Brotli+Gzip 预压缩静态资源。同时，检查 Brotli 是否支持 CDN，（例如 KeyCDN，CDN77，Fastly）。确保服务器能够使用 Brotli 或 gzip 处理内容。如果你不能安装或者维护服务器上的 Brotli，那么请使用 Zopfli。
- 图像是否进行了适当的优化？ 尽可能通过
srcset，sizes和Accept头信息）。
Sketch 本身就支持 WebP 并且 WebP 图像可以通过使用 WebP 插件 从 PhotoShop 中导出。也有其他选择可以使用，如果你使用 WordPress 或者 Joomla，也有可以轻松支持 WebP 的扩展，例如 Optimus 和 Cache Enabler（通过 Cody Arsenault）
你可以仍然使用 client hints，但仍需要获得一些浏览器支持。没有足够的资源支持响应式图片？使用 断点发生器 或者类似 Cloudinary 这样的服务自动优化图片。同样，在许多情况下，只使用 srcset 和 sizes 会有不错的效果。
On Smashing Magazine, we use the postfix -opt for image names — for example, brotli-compression-opt.png; whenever an image contains that postfix, everybody on the team knows that the image has already been optimized.
响应图像断点生成器自动生成图像和标记生成。
- 将图像优化到下一个级别 现在有一个至关重要着陆页，有一个特定的图片的加载速度非常关键，确保 JPEGs 是渐进式的并且使用 Adept、 mozJPEG （通过操纵扫描级来改善开始渲染时间）或者 Guetzli 压缩，谷歌新的开源编码器重点是能够感官的性能，并借鉴 Zopfli 和 WebP。唯一的 不足 是：处理的时间慢（每百万像素 CPU 一分钟）。至于 png，我们可以使用 Pingo，和 svgo，对于 SVG 的处理，我们使用 SVGO 或 SVGOMG
每一个图像优化的文章会说明，但始终保持保持矢量资产清洁总是值得提醒的。确保清理未使用的资源，删除不必要的元数据，并减少图稿中的路径点数量（从而减少SVG代码）。（感谢，Jeremy！）
到目前为止，这些优化只涵盖了基础知识。 Addy Osmani 已经发布了 一个非常详细的基本图像优化指南，深入到图像压缩和颜色管理的细节。 例如，您可以模糊图像中不必要的部分（通过对其应用高斯模糊滤镜）以减小文件大小，最终甚至可以开始移除颜色或将图像变成黑白色，以进一步缩小图像尺寸。 对于背景图像， 从Photoshop 导出的照片质量为 0 到 10％ 也是绝对可以接受的。
那么 GIF 图片呢？我们可以使用 循环的 HTML5 视频，而不是影响渲染性能和带宽的重度 GIF 动画，而使用循环的 HTML5 视频， 会使得 浏览器的性能很慢，而且与图像不同的是，浏览器不会预先加载 内容。 至少我们可以使用 Lossy GIF, gifsicle 或者 giflossy 添加有损压缩 GIF。
好 消息: 希望不久以后我们可以使用 img 标签比同等大小的 GIF 显示的要 快 20 多倍解析速度与要快 7 倍多。
还不够好？那么，你也可以使用 多种 背景 图像 技术 提高图像的感知性能。 记着，减少对比度 和模糊不必要的细节（或消除颜色）也可以减小文件的大小。 你需要放大一个小照片而不失真？考虑使用 Letsenhance.io
Zach Leatherman 的 字体加载策略综合指南 提供了十几种更好的网页字体发送选项
- Web字体是否优化？ 首先需要问一个问题，你是否能不使用 UI 系统字体。 如果不可以，那么你有很大可能使用 Web 网络字体，会包含字形和额外的功能以及用不到的加粗。 如果您使用的是开源字体（例如，通过仅包含带有某些特殊的重音字形的拉丁语），则可以只选择部分 Web 字体来减少其文件大小。
WOFF2 非常好，你可以使用 WOFF 和 OTF 作为不支持它的浏览器的备选。另外，从 Zach Leatherman 的《字体加载策略综合指南》（代码片段也可以作为 Web字体加载片段）中选择一种策略，并使用服务器缓存持久地缓存字体。是不是感觉小有成就？Pixel Ambacht 有一个 快速教程和案例研究，让你的字体按顺序排列。
如果你无法从你的服务器拿到字体并依赖于第三方主机，请确保使用 字体加载事件（或对不支持它的浏览器使用 Web字体加载器）FOUT 要优于 FOIT; 立即开始渲染文本，并异步加载字体 —— 也可以使用 loadCSS。 你也可以 摆脱本地安装的操作系统字体，也可以使用 可变的 字体。
怎么才能是一个无漏洞的字体加载策略？ 从 font-display 开始，然后回到 Font Loading API，然后回到 Bram Stein 的 Font Face Observer（感谢 Jeremy！）如果你有兴趣从用户的角度来衡量字体加载的性能， Andreas Marschke 探索了 使用 Font API 和 UserTiming API 进行性能跟踪
此外，不要忘记包含 font-display：optional 描述符来提供弹性和快速的字体回退，unicode-range 将大字体分解成更小的语言特定的字体，以及Monica Dinculescu 的字体样式匹配器 用来解决由于两种字体之间的大小差异，最大限度地减少了布局上的震动的问题。
交付优化
- 你是否异步加载 JavaScript？ 当用户请求页面时，浏览器获取 HTML 并构造 DOM，然后获取 CSS 并构造 CSSOM，然后通过匹配 DOM 和 CSSOM 生成一个渲染树。如果有任何的 JavaScript 需要解决，浏览器将不会开始渲染页面，直到 JavaScript 解决完毕，这样就会延迟渲染。 作为开发人员，我们必须明确告诉浏览器不要等待并立即开始渲染页面。 为脚本执行此操作的方法是使用 HTML 中的
defer和async属性。
事实证明，我们 应该把 defer 改为 async（因为 ie9 及以下不支持 async）。 另外，如上所述，限制第三方库和脚本的影响，特别是使用社交共享按钮和嵌入的