如何调试前端：优化网络资源

时间 2019-11-16

标签如何调试前端优化网络资源繁體版

原文原文链接

原文地址：How to debug front-end: optimising network assets

原文做者：Michał Witkowski

译文出自：掘金翻译计划

本文永久连接：github.com/xitu/gold-m…

译者：stormluke

校对者：Starrier、allenlongbaobao

网络性能能够决定 web app 的成败。最初 app 很新很小时，不多有开发者会持续关注 app 到底用了多长时间发送了多少兆字节给用户。css

若是你从未测量过本身 app 的性能，那极可能会有一些改进余地。问题是，你须要改善多少才能让用户注意到。html

在下面的研究中，你能够找到有关多长的加载时间差别能够被人们明显地感觉到的信息。若是你想让用户注意到你的努力，那就要超过 20% 这个门槛。阅读更多前端

这篇文章中，我会介绍（TL;DR）：android

经过 Chrome Devtool Audit 来测量性能
图像优化
Web 字体优化
JavaScript 优化
渲染阻塞资源时的优化
其余性能测量应用/扩展

若是你正在努力解决这以外的一些问题，请在评论告诉所咱们 —— 咱们的团队和读者们很乐意提供帮助。webpack

这篇文章是《如何调试前端》系列的一部分：ios

衡量 app 的性能

Chrome Devtools Audits

因为整篇文章都是关于 Chrome Devtools 的，咱们就先从 Audit 标签页开始（其自己使用了 Lighthouse）git

打开 Chrome Devtools > Audits > Perform an audit... > Run auditgithub

我决定检查性能（Performance）和最佳实践（Best practices），但咱们此次暂不涉及渐进式 Web 应用（Progressive Web App）或无障碍性（Accessibility）主题。web

不错。一段时间后，咱们完成了性能评估，并知道了一些改进这些性能指标的可行方法。若是 Audit 把屏幕分辨率调成了「移动设备」，请没必要担忧，由于对于 Chrome 来讲这是正常的。我强烈建议你用 Chrome 金丝雀版（Canary）来执行评估。金丝雀版有个能够评估桌面版网页的选项，而且增长了网络限速功能 —— 看看下面的图片。npm

指标

指标（Metrics）选项卡收集了基本的测量结果，而且提供了页面加载时间的整体概况。

首次有意义绘图（First meaningful paint） —— audit 肯定用户首次看到主要内容所需的时间。请尽量保持在 1 秒如下。阅读更多

首次可交互（First interactive） —— 指首次用户看到可交互 UI 元素而且页面能够响应所需的时间。

感知速度指数（Perceptual Speed Index） —— 指显示页面可见部分的平均时间。它以毫秒表示并取决于视口的大小。请尽可能保持在 1250 毫秒如下。阅读更多

预估输入延迟（Estimated Input Latency） —— 应用响应用户输入的时间，以毫秒为单位。

改进点

改进点（Opportunities） —— 是一个更详细的部分，收集了有关图片、CSS 和响应时间的信息。我会介绍每一个项目，并加上一些如何加速的小提示。

减小阻塞渲染（render-blocking）的样式表

CSS 文件被视为渲染阻塞资源。意味着浏览器会等待它们彻底加载完毕，以后才开始渲染。最简单的方法就是不加载没必要要的 CSS 文件。若是你使用 bootstrap，也许你不须要整个库来样式化你的页面 —— 尤为是在项目刚开始时。

其次，你能够考虑针对不一样屏幕尺寸进行优化。要下降加载 CSS 的数量级，可使用条件加载，它只加载特定屏幕分辨率所需的 CSS 文件。下面有个例子。

<link href="other.css" rel="stylesheet" media="(min-width: 40em)">
<link href="print.css" rel="stylesheet" media="print">
复制代码

若是对你来讲还不够，Keith Clark 提出了一个不阻塞页面渲染的加载 CSS 的好主意。诀窍是对媒体查询（media query）使用带有无效值的连接元素。当媒体查询结果为 false 时，浏览器仍然会下载样式表，但不会延迟渲染页面。您能够将剩余的没必要要的 CSS 分离出来并稍后下载。阅读更多

保持较低的服务响应时间

虽然这部分多是不言自明的，但仍值得咱们提醒本身它的做用。为了减小服务器响应时间，你能够考虑为某些资源使用 CDN。也能够采用 HTTP2，或简单地删除没必要要的请求，并在渲染页面后延迟加载它们。

合适尺寸的图片（Properly size Images）、离屏图片（Offscreen images）和下一代格式（next-gen formats）

这三部分都与一个主题紧密相关 —— 图片。要准确了解你正在加载哪些图片以及它们所占的时间比重，请进入 Chrome Devtools 的网络选项卡并经过 IMG 选项进行过滤。经过查看大小和时间这两行，看看你是否满意这些结果。关于每一个图片的大小比重并无通常性的规则。这很大程度上取决于你的客户端设备、客户端群以及更多只有你本身才了解的状况。

我想在这里更多地谈谈图片优化。在 Audit 结果中这个主题屡次出现。

图像优化

图片光栅图和矢量图。光栅图由像素组成。咱们一般将它们用于照片和复杂的动画。扩展名：jpg、jpeg、gif。

矢量图由几何图像组成。咱们将它们用于徽标和图标，由于它们能够随意缩放不失真。扩展名：svg。

SVG

SVG 从一开始就相对较小，但用这些优化器可使它更小。

光栅图

这里有点棘手，由于光栅图像可能很是大。有几种技术可使它们保持较大的分辨率但仍有较小的文件大小。

多张图片

首先准备多个版本的图像。你并不想在手机上加载视网膜级大小的图像，对吗？尝试制做 3 到 4 个版本的图片。手机版、平板版、桌面版和视网膜版。它们的大小取决于你的目标设备。若是你有任何疑问，请查看连接中的标准查询。

Srcset 属性

当你的图像准备好后，src 属性有助于定义什么时候加载哪些图像。

<img src="ing.jpg" srcset="img.jpg, img2x.jpg 2x" alt="img">
复制代码

src 给不支持 srcset 的浏览器用 srcset 给支持的浏览器用 img2x.jpg 给像素缩放比为 2.0 的设备用（视网膜）

<img src="img.jpg" srcset="img1024.jpg 1024w, img2048.jpg 2048w" alt="img">
复制代码

src 给不支持 srcset 的浏览器用 srcset 给支持的浏览器用 img1024 给宽度为 1024 时使用，等等.

上面的例子来自于 Developer Mozilla

媒体查询

你还能够建立上面提到过的媒体查询和样式，例如平板或手机。这种方法与 CSS 预处理器同时使用时特别有效。

srcset 属性的替代品是媒体查询，它的规则不在 HTML 中，而是在 CSS 文件里。对于纯 CSS，这种方法很是耗时，不值得花时间去作。但在这里，预处理器能够经过混入（mixins）和变量来解决问题。有了预处理器后，媒体查询与 srcset 不相上下。决定权在你。

@desktop:   ~"only screen and (min-width: 960px) and (max-width: 1199px)";
@tablet:    ~"only screen and (min-width: 720px) and (max-width: 959px)";

@media @desktop {
  footer {
    width: 940px;
  }
}

@media @tablet {
  footer {
    width: 768px;
  }
}
复制代码

图片 CDNs

当照片准备好并优化后，你还能够优化分发的过程。像 Cloudinary 这样的工具能够显着减小响应延迟。他们的服务器遍及全球，所以分发速度会更快。使用 HTTP 时，对于一个服务器你只能开启 6 个并行请求。使用 CDN 后，并行请求数量会随着服务器数量成倍增加。

延迟加载

有时候，图片必须很花哨且很大。若是你为长时间的延迟而困扰，能够试试图片模糊化或延迟加载。

延迟加载是一种在须要时才开始加载图片或其余任何内容的方法。当图库中有 1000 个图片时，并不是全部图片都须要加载。只需加载前 10 个，其他的等用户须要时再加载。

有大量的库能够作到这点。阅读更多

Facebook 目前正在使用图片模糊化。当你在网络很差的状况下打开某人的资料页时，刚开始图片是模糊的；后来它才变得清晰。阅读更多

诊断

诊断页（Diagnostics）结束了这一系列测试。我不会详细介绍列表里的每个标题，由于其中一些主题已经介绍过了。我只会说起其中的一些，并试图在总体上涵盖这些主题。

对静态资源使用了低效的缓存策略

Goole 很注重缓存和无服务器应用。缓存彻底取决于你，我不是缓存的忠实拥护者。若是你想了解更多缓存的东西，Google 准备了一些不错的课程。阅读更多

关键请求链 / 阻塞渲染的脚本

关键请求链（Critical request chains）包含了须要在页面渲染前就完成的请求。保持它尽量小相当重要。

咱们以前提到了 CSS 加载，如今咱们来讨论一下 Web 字体。

优化 Web 字体

在建立 web 应用/网站时，目前咱们使用四种字体格式：EOT、TTF、WOFF、WOFF2。

没有一种格式是最合适的，所以咱们须要再次针对不一样的浏览器使用不一样的格式。这个主题的入门教程和更多解释在这里。阅读更多不过在刚开始时，最好问问本身是否真的须要使用一个 web 字体。这里有一篇关于它的很是好的文章。

字体压缩

字体是形状和路径描述的集合，用于建立字母。每一个字母都是不一样的，但幸运的是他们有不少共同点，因此咱们能够稍微压缩一下。

因为 EOT 和 TTF 格式默认未压缩，请确保你的服务器配置了使用 GZIP。

WOFF 内置了压缩功能。请在你的服务器上使用最佳压缩设置。

WOFF2具备自定义预处理。阅读更多

限制字符

你是否只使用英文？请记住：不须要在字体中添加阿拉伯文或希腊文字母。你也可使用 unicode 代码点。这使得浏览器能够将较大的 Unicode 字体拆分红较小的子集。阅读更多

字体加载策略

加载字体会阻塞页面渲染，由于浏览器须要使用其中的全部字体来构建 DOM。字体加载策略能够防止加载延迟。字体显示（fonts-display）是策略之一，在 CSS 属性中。阅读更多

优化 JavaScript

没必要要的依赖

如今，随着 ES6 愈来愈重要，咱们普遍使用 webpack 和 gulp。在使用库，务必记住，你并不老是须要整个库。若是你不须要引入整个 lodash，只需引入一个函数。

import _ from 'lodash ' —— 会把整个 lodash 库加到包中

import {map} from 'lodash' —— 也会把整个 lodash 库加到包中，你可使用 lodash-webpack-plugin、babel-plugin-lodash 这些插件

import map from 'lodash/map' —— 只会把 map 模块加入包中

仔细查看框架中的 ES6 函数和你本身的函数。你不须要为每一个功能都引入一个新库。要检查你的包是如何构建的，请使用下面连接中的工具。

其余工具

固然有更多的工具来衡量你网站的性能。

其中一个是 tools.pingdom.com，它或多或少地为你提供与 Audits + Network 选项卡类似的信息。

我同时也推荐安装 PageSpeed Insights 这个 Chrome 扩展。它直接向你显示哪一个图片须要更小点。

总结

本文试图向你展现如何经过减小资源的大小来使你的网站更轻盈。这只是提升网站性能的第一步。毕竟，这个领域十分普遍，并随着现代前端的发展而变化。请关注这个话题和你的竞争对手。尽可能提早一步。

掘金翻译计划是一个翻译优质互联网技术文章的社区，文章来源为掘金上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注掘金翻译计划、官方微博、知乎专栏。