我们大多数人都做过现场速度审计，或者看过其他人做过的审计。这些对企业非常有帮助，但我经常发现它们的关注点非常狭窄。通常，我们使用众所周知的工具来抛出一堆东西来查看，然后我们从那里深入研究。
但是，如果我们深入挖掘，通常还有其他关于如何提高网站速度的想法。我经常看到许多站点速度审计从未涵盖的机会。大多数网站速度的提高都是一系列小改动的结果，所以在这篇文章中，我将介绍一些我在任何网站速度审计中从未见过的想法，所有这些都可以产生影响。
图像优化的不同角度
考虑在 PNG 上优化 SVG
我最近想订一些票来观看《冰雪奇缘 2》（因为，呃，我的孩子们……），所以登陆了这个页面。它使用三个 SVG 图像作为传输图标：
SVG 图像是矢量图像，因此它们非常适合图标之类的东西；如果您有显示为 PNG 的图像，您可能需要向您的设计师询问原始 SVG，因为可以节省大量费用。虽然并不总是更好，但使用 SVG 可以节省 60% 的文件大小。
在这种情况下，这些图标的大小约为 1.2k，因此它们非常小。他们可能会在站点速度审计的雷达下飞行（Page Speed Insights 或 GTMetrix 都没有在此页面中提及这些图像）。
所以你可能会想，“它们加起来不到 5k – 你应该寻找更大的问题！”，但让我们来看看。首先，我们可以通过 Jake Archibald 的 SVG 压缩工具来运行它们；这是一个很棒的免费工具，在较大的 SVG 上它可以产生很大的不同。
在这种情况下，文件很小，所以你可能还在想“为什么要麻烦？” 该工具将它们压缩而不会损失从 ~1240 字节到 ~630 字节的质量——这是一个不错的比例，但整体节省的成本并不多。
但是……既然我们已经压缩了它们，我们可以对交付它们有不同的想法……
内嵌图像
GTMetrix 建议内联少量的 CSS 或 JS，但没有提及内联图像。图像也可以内联，有时这可能是正确的方法。
如果您认为即使是非常小的图像文件也需要完整的往返传输（这会对速度产生非常实际的影响），即使对于小文件，这也可能需要很长时间。在上面的 Cineworld 传输图像的情况下，我模拟了“快速 3G”连接并看到：
该站点没有使用 HTTP2，因此等待时间很长，然后加载图像（即 1.2kb）大约需要 600 毫秒（没有 HTTP2 也意味着这会阻止其他请求）。这些图像中有三个，因此它们之间可能会对页面速度产生真正的影响。
然而，我们现在已经将它们压缩到每个只有几百字节，并且 SVG 图像实际上是由标记组成的，其方式类似于 HTML：
您实际上可以将 SVG 标记直接放入 HTML 文档中！
如果我们对所有三个传输图像执行此操作，则从服务器发送到浏览器的该页面的压缩 HTML 将从 31,182 字节增加到 31,532 字节——所有 3 个图像仅增加了 350 字节！
回顾一下：
- 我们的 HTML 请求增加了 350 字节，这几乎不算什么
- 我们可以放弃到服务器的三个往返行程，我们可以看到这需要相当长的时间
你们中的一些人可能已经意识到，如果图像不是内联的，它们可以单独缓存，因此未来的页面请求不需要重新获取它们。但如果我们考虑：
- 每个图像最初在网络上大约为 1.5kb（它们没有压缩 SVG），顶部有大约 350 字节的 HTTP 标头，总共传输了大约 5.5kb。因此，总体而言，我们减少了网络上的内容量。
- 这也意味着需要超过 20 次网页浏览才能从缓存中受益。
要点：考虑在哪里有机会使用 SVG 而不是 PNG。
要点：确保优化 SVG 图像，使用我链接到的免费工具。
要点：内联小图像很有意义，并带来了巨大的性能提升。
注意：您也可以内联 PNG – 请参阅本指南。
注意：对于优化的 PNG/JPG 图像，请尝试 Kraken。
退后，JavaScript！HTML可以处理这个……
如今，由于提供现成解决方案的 JavaScript 库的流行，我发现 JavaScript 被用于实现无需它即可实现的功能。更多的 JS 库意味着更多的下载，可能更多来自服务器的额外文件的往返行程，然后是 JavaScript 执行时间和成本本身。
我非常同情你是如何走到这一步的。开发人员经常收到糟糕的简报/规范，没有指定任何关于性能的内容，只有功能。他们通常没有时间，所以很容易最终只是丢掉一些东西。
但是，在可以使用 HTML 和/或 CSS 实现的功能方面已经取得了很大进展。让我们看一些例子。
带搜索的组合框
具有文本搜索选项的下拉框是当今相当常见的界面元素。我最近看到的一篇文章描述了如何使用 Select2 Javascript 库来制作这样的列表：
它是一个有用的 UI 元素，可以帮助您的用户。但是，在 Select2 库中是一个 JavaScript 库，它又依赖于一些 CSS 和 JQuery 库。这意味着收集一堆不同大小的文件需要三个往返：
- jQuery – 101kb
- Select2 JavaScript – 24kb
- Select2 CSS – 3kb
这对于网站速度来说并不理想，但我们当然可以证明它是值得的，以便为用户提供一个流线型的界面。
但是，实际上可以使用 HTML datalist 元素开箱即用地使用此功能：
这允许用户搜索列表或自由键入他们自己的响应，因此提供了相同的功能。此外，它在智能手机上具有本机界面！
您可以在这个 codepen 中看到这一点。
细节/总结
LonelyPlanet 有一个漂亮的网站，我在看这个关于西班牙的页面，它有一个大多数网络用户都会熟悉的“阅读更多”链接：
就像我看到的几乎每个实现一样，他们使用 JavaScript 库来实现它，这又一次带来了一堆开销。
但是，HTML 有一对内置标签，称为 details 和 summary，旨在准确实现此功能。在 HTML 中免费且原生。没有开销，对于需要屏幕阅读器的用户来说更容易访问，同时也向谷歌传达语义。
这些标签可以使用 CSS 以各种灵活的方式设置样式，并重新创建我在那里看到的大多数 JS 版本。
在这里查看一个简单的演示：https://codepen.io/TomAnthony/pen/GRRLrmm
…和更多
有关可以使用 HTML 而不是 JS 实现的功能的更多示例，请查看以下链接：
- http://youmightnotneedjs.com/
- https://dev.to/ananyaneogi/html-can-do-that-c0n
要点：检查您的网站的功能，看看哪里有机会减少您对有原生 HTML/CSS 选项的大型 Javascript 库的依赖。
要点：请记住，问题不仅在于 JS 文件的大小，还在于所需的往返次数。
注意：在某些情况下您应该使用 JS 解决方案，但重要的是要权衡利弊。
网络调整
每次浏览器必须从服务器收集资源时，它都必须通过互联网发送消息并返回；它的速度受到光速的限制。这听起来像是一件很荒谬的事情，但它意味着即使是很小的请求也会增加页面加载时间。如果您没有看到上面的链接，我在解释 HTTP2 的帖子中更详细地讨论了这个问题。
我们可以做一些事情来帮助减少这些请求的距离或减少所需的往返次数。这些有点技术性，但可以取得一些真正的胜利。
TLS 1.3
TLS（或 SSL）是用于保护 HTTPS 连接的加密技术。从历史上看，浏览器和服务器之间需要两次往返来设置加密——如果用户距离服务器 50 毫秒，那么这意味着每个连接需要 200 毫秒。请记住，Google 历来建议以 200 毫秒为目标来交付 HTML（这在最近的更新中似乎略微放松）；你在这里浪费了很多时间。
最近定义的 TLS 1.3 标准将这从两次往返减少到只有一次，这可以节省用户初始连接到您网站的一些宝贵时间。
与您的技术团队讨论迁移到 TLS 1.3 的问题；不支持它的浏览器将毫无问题地回退到 TLS 1.2。所有这些都在幕后进行，而不是任何形式的迁移。没有理由不这样做。
如果您使用的是 CDN，那么它可以像打开它一样简单。
您可以使用此工具检查您启用了哪些版本的 TLS。
QUIC/HTTP 3
在过去的 2-3 年中，我们看到许多站点从 HTTP 1.1 迁移到 HTTP 2，这是一个幕后升级，可以真正提高速度（如果您想了解更多信息，请参阅上面的链接）。
紧随其后的是一对新兴的标准，称为 QUIC + HTTP/3，它进一步优化了浏览器和服务器之间的连接，进一步减少了所需的往返。
对这些的支持才刚刚开始变得可行，但如果您是 CloudFlare 客户，您可以在今天和未来 6 个月内启用它，因为 Chrome 和 Firefox 推出支持，您的用户将获得速度提升。
在此处阅读更多信息：https://blog.cloudflare.com/http3-the-past-present-and-future/
超级路由
当用户连接到您的网站时，他们必须打开从任何地方到您的服务器（或您的 CDN）的网络连接。如果您将互联网想象为一系列道路，那么您可以想象它们需要通过这些道路“开车”到您的服务器。然而，这意味着拥堵和交通拥堵。
事实证明，一些大型云公司拥有自己的私人道路，这些道路坑洼少，交通量少，限速也有所改善。如果只有您的网站访问者可以访问这些道路，他们就可以更快地向您“开车”！
好吧，你猜怎么着？他们能！
对于 CloudFlare，他们通过他们的 Argo 产品提供这种访问，而如果你在 AWS 上，那么你可以使用他们的 Global Accelerator。这允许对您网站的请求利用他们的专用网络并获得潜在的速度提升。如果您已经是客户，两者都非常便宜。
要点：如果您使用的是 CDN，那么这些好处中的很多都更容易获得。如果您还没有使用 CDN，那么您可能应该使用。CloudFlare 是一个不错的选择，如果您使用 AWS，CloudFront 也是如此。如果您更专业，Fastly 是其中最可配置的。
要点：TLS 1.3 现在得到了非常广泛的支持，并为新连接提供了显着的速度改进。
要点：QUIC / HTTP3 才刚刚开始获得支持，但在接下来的几个月中，它将更广泛地推广。QUIC 包括 TLS 1.3 的优点以及更多。现在一个典型的 HTTP2 连接需要 3 次往返才能打开；QUIC 只需要一个！
要点：如果您使用的是 CloudFlare 或 AWS，那么只需拨动开关以打开智能路由功能，就有可能获得加速。
让 CSS 做更多
上面我谈到了 HTML 如何具有内置功能，您可以利用这些功能来节省依赖“家庭滚动”的解决方案，因此需要更多代码（和浏览器端的处理）来实现。在这里，我将讨论一些 CSS 可以为您做同样事情的示例。
重用图像
通常，您会发现在整个页面中的多个位置使用相似图像的页面。例如，不同颜色的徽标变体，或指向两个方向的箭头。作为独特的资产（尽管它们可能相似），它们中的每一个都需要单独下载。
回到我在上面寻找电影票的过程中，我正在查看此页面，我们可以看到一个带有左右箭头的旋转木马：
与上面使用的逻辑类似，虽然这些图像文件很小，但它们仍然需要往返才能从服务器获取。
然而，箭头是相同的——只是指向相反的方向！我们很容易使用 CSS 的转换功能来双向使用一张图像：
您可以查看此代码笔作为示例。
另一个例子是当相同的标志以不同的样式出现在页面的不同部分时；他们通常会加载多个变体，这是不必要的。CSS 可以通过多种方式为您重新着色徽标：
这里有一个 codepen 展示了这种技术的实际应用。如果您想计算达到任意颜色所需的 CSS 过滤器值，请查看这个惊人的颜色计算器。
交互（例如菜单和标签）
诸如菜单和选项卡之类的导航元素通常是用 JavaScript 实现的，但这些也可以用纯 CSS 来完成。查看此代码笔以获取示例：
动画
CSS3 在 CSS 中引入了很多强大的动画能力。通常这些不仅比 JavaScript 版本更快，而且还可以更流畅，因为它们可以在操作系统的本机代码中运行，而不必执行相对较慢的 Javascript。
以打瞌睡鸟为例：
你可以在这篇文章中找到更多。CSS 动画可以以相对较小的性能成本为页面添加大量字符。
…和更多
有关您可以使用纯 CSS 解决方案实现的功能的更多示例，请查看：
- http://youmightnotneedjs.com/
- https://dev.to/ananyaneogi/css-can-do-that-18g7m
要点：使用 CSS 优化您必须使用旋转或过滤器加载的文件数量。
要点：CSS 动画可以为页面添加字符，并且通常比 JavaScript 需要更少的资源。
要点：CSS 完全有能力实现许多交互式 UI 元素。
包起来
希望您发现这些示例本身很有用，但我想说的更广泛的一点是，我们都应该尝试在网站速度方面开箱即用地思考更多。特别重要的是减少到服务器所需的往返次数；即使是小资产也需要一些时间来获取，并且会对性能（尤其是移动设备）产生显着影响。
有比我们在这里介绍的更多的想法，所以如果您遇到其他事情，请跳到评论中。
