注册
登录
互联网发展非常迅速，所以我们创造了Web平台。通常 我们会忽视连通性等问题，但用户们却不会视而不见 。一瞥万维网的现状，可以发现我们并没有用同情心、变通意识去构建它，更不要说性能了。 所以，今天的Web是什么状态呢？ 在这个星球上的74亿人中，只有46％可以上网。平均网络速度上限为7Mb/s。更重要的是，有93％的互联网用户正在通过移动设备进行访问——若不适配移动设备将引起用户反感。通常情况下，数据比我们假设的更昂贵——可能需要1到13小时才能购买500MB的数据包（德国 vs. 巴西；更有趣的统计数据参见 Ben Schwarz 的 Beyond the Bubble: The Real World Performance）。 我们的网站也不是完美的——平均网站是 原始Doom游戏的大小 （约3 MB）（请注意，为了统计准确，应使用中位数，阅读 Ilya Grigorik 的 优秀“平均页面”是一个神话 ，中档网站大小目前为1.4MB）。图像可以轻松占用1.7 MB的带宽，而JavaScript平均值也有400KB的体积。这不仅是Web平台的问题，原生应用程序可能更糟，还记得为了获取错误修复版本，而下载200MB安装包的情景吗？ 技术人员经常会发现自己处于特权状态。随着最新的高端笔记本电脑、手机和快速有线互联网连接，很容易让我们忘记，这些并不是每个人都有的条件（实际上，真的很少）。 如果我们从特权和缺乏同情的角度来构建网络平台，那么将导致排他性的糟糕体验。 考虑到设计和开发的性能，我们怎样才能做得更好？ 优化所有资源理解浏览器如何分析和处理资源，是显著提高性能的最强大但未充分利用的方式之一。事实证明，浏览器在嗅探资源方面非常出色，同时解析并确定其优先级。这里是 关键请求 的来源。 如果请求中包含用户视口中呈现内容所必需的资源，则该请求至关重要。 对于大多数网站，它将是HTML、必要的CSS、logo、网络字体，也可能是图片。在许多情况下，几十个其他不相关的资源（JavaScript、跟踪代码、广告等）影响了关键请求。幸运的是，我们能够通过仔细挑选重要资源并调整优先级来控制这种行为。 通过
关键请求对许多人来说，似乎仍然是一个黑匣子，可共享资料的缺乏并不能改变现状。幸运的是， Ben Schwarz 发表了关于这个问题的非常全面并平易近人的文章—— 关键请求 。另外，请参阅Addy的文章， 在Chrome中的预加载、预取和优先级（Preload, Prefetch and Priorities in Chrome ）。
[在Chrome开发人员工具中启用优先级] 要跟踪在请求优先级处理方面的情况，请使用Lighthouse性能工具和 关键请求链审核工具 ，或查看Chrome开发人员工具中“网络”选项卡下的请求优先级。 通用性能清单
图片优化图片通常占网页传输的大部分有效载荷，因此图片优化可以带来最大的性能提升。有许多现有的策略和工具可以帮助我们删除额外的字节，但是首先应考虑的问题是：“图片对于我想传达的信息和效果至关重要吗？”。如果可以消除它，不仅可以节省带宽，而且还节省了请求。 在某些情况下，可以通过不同的技术实现类似的结果。比如CSS就具有艺术方向的一系列属性，例如阴影、渐变、动画及形状，允许我们构造适当风格的DOM元素。 选择正确的格式如果不能舍弃图片，确定哪种格式更合适就很重要了。首先要在矢量和光栅图形之间做出选择：
做出首个决定后，可以选择以下几种格式：JPEG、GIF、PNG–8、PNG–24，或最新的 WEBP 与 JPEG-XR 格式。有了这么多的选项，如何确保我们做出正确的选择？以下是找出最佳格式的基本方法：
Photoshop可以通过各种设置，例如降低质量、降低噪音或色彩数量来优化以上每一种格式。确保设计师了解上述性能实践，并能够使用正确的方式优化相应格式的图片。如果您想了解更多如何处理图片，请阅读 Lara Hogan 的好文 Designing for Performance 。 试用新格式图像格式有几个较新的玩家，即WebP、JPEG 2000 和 JPEG-XR。它们都是由浏览器厂商开发的：Google 的 WebP，Apple 的 JPEG 2000 和 Microsoft 的 JPEG-XR。 WebP是最受欢迎的竞争者，支持无损和有损压缩，这使得它非常灵活。 无损的 WebP 比 PNG 小26％，比 JPG 小25-34％ 。WebP 有着74％的浏览器支持，它可以安全地进行降级，最多可节省1/3的传输字节。JPG 和 PNG 可以在 Photoshop 和其他图像处理应用程序以及命令行界面（ 如果你想探索其他格式之间的视觉差异，推荐 Github 上这个很赞的 Demo 。 用工具和算法进行优化即使 使用了高效的图像格式，也不应跳过后处理优化 。这一步很重要。 如果您选择了尺寸相对较小的 SVG，它们也是可以再次压缩的。 SVGO 是一个命令行工具，可以通过剥离不必要的元数据来快速优化 SVG。另外，如果您喜欢Web界面或受操作系统的限制，请使用 Jake Archibald 的 SVGOMG 。因为 SVG 是基于 XML 的格式，它也可以在服务器端进行 GZIP 压缩。 ImageOptim 是大多其他图像类型的最好选择。包括 pngcrush、pngquant、MozJPEG、Google Zopfli等，它在一个全面的开源包中捆绑了一大堆优秀的工具。ImageOptim 可以以 Mac OS 应用程序、命令行界面和 Sketch 插件形式，轻松地实现到现有的工作流程中。对于那些在 Linux 或 Windows 上的场景，大多数 ImageOptim 的 CLI 都可以在您的平台上使用。 如果您倾向于尝试新兴的编码器，Google 今年早些时候发布了 Guetzli ——源自 WebP 和 Zopfli 的开源算法。 Guetzli 可以比任何其他可用的压缩方法生成35％更小体积的 JPEG 。唯一的缺点是：处理时间慢（CPU 每处理百万像素需要1分钟）。 选择工具时，请确保它们生成所需的结果并适应团队的工作流程。理想情况是，将优化过程自动化，这样就不会产生漏掉的情况。 响应式图片十年前，我们使用一种分辨率，就可以为所有人服务，但时代变化太快，现今的响应式 Web 已非往日可比。这也是为什么我们必须要特别留心，去精心优化视觉资源，确保它们适应各种视口设备。幸运的是，感谢 Responsive Images 社区小组 ，我们可以完美使用 srcset 属性
[srcset 使用示例] picture 元素
[picture 元素使用示例] 请务必阅读 Jason Grigsby 的 Responsive Images 101 指南，以便对这两种方法进行彻底的阐述。 使用图片 CDN 进行分发视觉优化的最后一步是分发。所有资源都可以从使用 内容分发网络 中受益，但还有一些针对图片优化的特定工具，例如 Cloudinary 和 imgx 。使用这些服务的好处远远超过了减少服务器上的流量，并显着降低了响应延迟。 CDN可以很好的解决重图片网站的复杂度，包括响应式服务与图片优化。虽然产品不同（价格也是如此），但是大多数方案都是根据设备和浏览器，调整大小、裁剪来确定哪种格式最适合用户。甚至更多——它们可以压缩、检测像素密度、水印、识别面部，并允许后置处理能力。借助这些强大的功能，和将参数附加到URL的能力，以用户为中心的图片服务变得十分容易。 图像性能清单
Web 字体优化自定义字体是一项非常强大的设计工具。但是能力伴随着很多责任 。现有68％的网站在使用 Web字体，这种类型的资源是性能杀手之一 （平均轻松可达100KB，取决于变体和字体的数量）。 即使体积不是最大的问题， 不可见文本闪动 （FOIT）也算是。当Web字体加载中或加载失败时，会发生FOIT，这会让空白页面，从而导致内容无法访问。 首先仔细检查我们是否需要Web字体 可能是值得的。如果真是这样，有一些策略可以帮助我们减轻对业务的负面影响。 选择正确的格式有4种网络字体格式：EOT、TTF、WOFF 和最近的 WOFF2。TTF 和 WOFF 被广泛使用，拥有超过90％的浏览器支持率。根据支持情况， 最有可能安全地使用WOFF2 ，并在旧版浏览器降级使用 WOFF。使用WOFF2的优点是，一套定制的预处理和压缩算法（如Brotli），并有 大约30％的文件大小减少 和改进的解析能力。 在 如果您使用 Google Fonts 或 Typekit 来提供字体，这两种工具都实施了一些策略来优化其性能。Typekit 现在可以异步地为所有套件提供服务，防止 FOIT 以及允许其JavaScript套件代码的10天延长缓存期限（而不是默认10分钟）。Google Fonts 可以根据用户设备自动提供最小的文件。 审核字体范围无论是否自主托管，字体数量、字体体积和样式，都将显著影响您的性能预算。 理想情况下，我们只需要一种包括常规和粗体的字体。如果您不确定如何选择字体范围，请参考 Lara Hogan 的 Weighing Aesthetics and Performance 。 使用Unicode范围子集Unicode范围子集允许将大字体分割成较小的集合。这是一个相对先进的策略，特别是在处理亚洲语言的时候，可能会带来显着的节省（你知道中文字体有平均数为 20,000 个字形吗？）。第一步是将字体限制为必要的语言集，例如拉丁语，希腊语或西里尔语。如果仅使用Web字体做Logo类使用，则应使用Unicode范围描述符，来选择特定字符。 Filament Group 发布了一个开源命令行工具，可以根据文件或URL生成必要字形列表的 glyph hanger 。或者，基于 Web 的 Font Squirrel Web Font Generator 提供高级子集和优化选项。如果在字体选择器界面中内置了使用Google Fonts 或 Typekit 选择语言子集，则使基本子集更容易。 建立字体加载策略字体是阻塞渲染的——因为浏览器必须首先构建 DOM 和 CSSOM；在使用与现有节点相匹配的CSS选择器之前，浏览器并不会下载Web字体。这种行为会明显延迟文本呈现，通常会导致前面提到的不可见文本闪动（FOIT）。在较慢的网络和移动设备上，FOIT会更加显着。 实施字体加载策略，可防止用户无法访问您的内容。通常，选择 无样式文本闪动 （FOUT）是最简单和最有效的解决方案。
[font-display 属性实践] 幸运的是，Typekit 的 Web Font Loader 和 Bram Stein 的 Font Face Observer 可以帮助管理字体加载行为。此外，网页字体性能专家 Zach Leatherman 发布了 字体加载策略综合指南 ，这将有助于为您的项目选择正确的方法。 字体性能清单
JavaScript 优化目前， JavaScript 的平均大小为446 KB ，已经使其成为第二大的资源类型（第一为图片）。 我们可能没有意识到，我们所爱的JavaScript隐藏着更加严峻的性能瓶颈。 监控JavaScript的流量优化交付只是解决网页膨胀的第一步。JavaScript 下载后，必须由浏览器进行解析、编译和运行。快速浏览一些流行的网站，显而易见的是，gzip 压缩的 JS 在 解压之后至少变大三倍 。事实上，我们正在发送一大堆代码。
1MB JavaScript 在不同设备上的解析时间。图片由 Addy Osmani 和他的 JavaScript Start-up Performance 文章提供。 分析解析和编译时间，对于理解应用程序是否准备好进行交互至关重要。这些耗时根据用户设备的硬件能力而异。 解析和编译会很容易在低端手机上高出2-5倍 。 Addy 的研究证实，在常规手机上，一个应用程序将需要16秒才能达到交互式状态，而在桌面电脑上为8秒。分析这些指标至关重要，幸运的是，我们可以通过 Chrome DevTools 来完成。
[在 Chrome 开发工具中查看解析和编译过程] 请务必阅读 Addy Osmani 对 JavaScript 启动性能 的详细说明。 摆脱不必要的依赖现代软件包管理器的工作方式，可以轻而易举地掩盖依赖关系的数量和大小。 webpack-bundle-analyzer 和 Bundle Buddy 是很好的可视化工具，帮助识别出代码重复、最大性能问题和过时的、不必要的依赖。 图 webpack bundle analyzer 实践 （译者注：原gif太大，只能用外链了） 通过 VS Code 和 Atom 中的 实现代码分割只要有可能， 我们就应只提供用户体验所必需的资源 。向用户发送一个完整的 bundle.js 文件，包括他们可能永远看不到的交互效果处理代码，并不太理想（假设在访问着陆页时，去下载处理整个应用程序的 JavaScript）。同样，我们不应普遍提供针对特定浏览器或用户代理的代码。 Webpack，最受欢迎的模块打包器之一，天生具备 代码分割支持 。最简单的代码分割可以按页面实现（如用于着陆页的 考虑框架选择JavaScript 前端框架日新月异。根据 2016年的 JavaScript 调查 ，React 是最受欢迎的选择。仔细审视架构选择，可能会发现，您可以使用更为轻量级的替代方案，例如 Preact （请注意，Preact 并不是一个完整的 React 重新实现，只是一个 高性能 ，功能更轻的虚拟 DOM 库）。类似地，我们可以将较大的库更换成更小的版本—— |
