幸运的是，Typekit 的 Web Font Loader 和 Bram Stein 的 Font Face Observer 可以协助管理字体加载行为。此外，网页字体功用专家 Zach Leatherman 发布了 字体加载策略综合指南 ，这将有助于为您的项目选择正确的办法。
字体功用清单
选择正确的格式
审核字体范围
运用Unicode范围子集
树立字体加载策略
JavaScript 优化
目前， JavaScript 的平均大小为446 KB ，曾经使其成为第二大的资源类型(第一为图片)。
我们能够没无看法到，我们所爱的JavaScript隐藏着愈加严峻的功用瓶颈。
监控JavaScript的流量
优化交付只是处置网页收缩的第一步。JavaScript 下载后，必须由阅读器停止解析、编译和运转。快速阅读一些盛行的网站，不言而喻的是，gzip 紧缩的 JS 在 解压之后至少变大三倍 。理想上，我们正在发送一大堆代码。
1MB JavaScript 在不同设备上的解析时间。图片由 Addy Osmani 和他的 JavaScript Start-up Performance 文章提供。
剖析解析和编译时间，关于了解运用顺序能否预备好停止交互至关重要。这些耗时依据用户设备的硬件才能而异。 解析和编译会很容易在低端手机上高出2-5倍 。 Addy 的研讨证明，在常规手机上，一个运用顺序将需求16秒才能到达交互式形状，而在桌面电脑上为8秒。剖析这些目的至关重要，幸运的是，我们可以经过 Chrome DevTools 来完成。
请务必阅读 Addy Osmani 对 JavaScript 启动功用 的详细阐明。
摆脱不必要的依赖
现代软件包管理器的任务方式，可以轻而易举地掩盖依赖关系的数量和大小。 webpack-bundle-analyzer 和 Bundle Buddy 是很好的可视化工具，协助辨认出代码重复、最大功用成绩和过时的、不必要的依赖。
经过 VS Code 和 Atom 中的 Import Cost 扩展，我们可以使导入依赖成本愈加清楚。
实现代码联系
只需有能够， 我们就应只提供用户体验所必需的资源 。向用户发送一个残缺的
bundle.js 文件，包括他们能够永远看不到的交互效果处置代码，并不太理想(假定在拜访着陆页时，去下载处置整个运用顺序的 JavaScript)。异样，我们不应普遍提供针对特定阅读器或用户代理的代码。
Webpack，最受欢迎的模块打包器之一，天生具有 代码联系支持 。最复杂的代码联系可以按页面完成(如用于着陆页的 home.js ，联络人页面的 contact.js 等)，Webpack 还提供了一些初级策略，如静态导入及 延迟加载 ，值得一看。
思索框架选择
JavaScript 前端框架一日千里。依据 2016年的 JavaScript 调查 ，React 是最受欢迎的选择。细心审视架构选择，能够会发现，您可以运用更为轻量级的替代方案，例如 Preact (请留意，Preact 并不是一个残缺的 React 重新完成，只是一个 高功用 ，功用更轻的虚拟 DOM 库)。相似地，我们可以将较大的库改换成更小的版本—— moment.js 换成 date-fns (或许在特定状况， 删除 moment.js 中未运用的 locales )。
在末尾一个新项目之前，有必要确定什么样的功用是必需的，并为您的需求和目的选择最具功用的框架。有时这能够意味着选择写更多的原生 JavaScript。
JavaScript 功用清单
监控 JavaScript 流量
摆脱不必要的依赖
实现代码联系
思索框架选择
功用追踪，行进之路
我们曾经讨论了一些策略，在大少数状况下会对我们正在树立的产品用户体验产生积极的变化。功用能够是一个顺手的成绩，有必要长期地跟踪我们调整的结果。
以用户为中心的功用目的
出色的功用目的，旨在尽能够接近描画用户体验。以往的 onLoad ， onContentLoaded 或 SpeedIndex 对「用户多快能与页面交互」给出的信息十分少。当聚焦到传输资源时，量化地 感知功用 十分困难。好在，有一些时间可以片面地描画内容的可视性和互动性。
这些目的是初次渲染(First Paint)，初次有意义渲染(First Meaningful Paint)，视觉残缺(Visually Complete)和可交互时间(Time to Interactive)。
初次渲染 ：阅读器从白色屏幕到第一次视觉出现的变化。
初次有意义渲染 ：文字，图像和主要内容都已可见。
视觉残缺 ：视口中的一切内容都可见。
可交互时间 ：视口中的一切内容都是可见的，可以与之停止交互(JavaScript 主线程中止活动)。
这些时间直接对应于用户的实践体验，因此可以作为重点停止追踪。假设能够，将它们记载全部，否则选择一两个来更好地监控功用。其他目的也需求留意，特别是我们发送的字节数(优化和解紧缩)。
设置功用预算
一切这些上报数字能够会很快变得混乱和不易了解。没有可操作的目的和对象，很容易迷失我们最后的目的。几年前， Tim Kadlec 写过关于 功用预算 的概念。
遗憾的是，并没有一个万能的神奇公式。功用预算通常归结为竞争剖析和产品目的，而这是每个业务所各异的。
设定预算时，重要的是要到达清楚的差异，通常是至少改善20%。实际和迭代您的预算，应用 Lara Hogan 的 办法新设计与功用预算 作为参考。
试用 功用预算计算器 或Chrome扩展 阅读器卡路里 ，以协助创立预算。
继续监控
监控功用不应该是手动的。市面上有很多弱小的工具，还可以提供片面的报告。
Google Lighthouse 是一个可以审核功用、可拜访性、渐进式网络运用顺序等的开源项目。您可以在命令行中或直接在 Chrome Developer Tools 中运用Lighthouse。
(责任编辑：admin)