为 HTTP2 做好准备:Web 设计师和开发人员指南

已发表: 2022-03-10
快速总结↬详细了解适用于网页设计人员和开发人员的 HTTP/2 基础知识。 我们将了解新协议的关键特性、浏览器和服务器兼容性,并详细说明随着我们看到更多采用 HTTP/2 时您可能需要考虑的事项。

超文本传输​​协议 (HTTP) 是管理服务器与网站访问者浏览器之间连接的协议。 自 1999 年以来,我们第一次有了这个协议的新版本,它承诺为每个人提供更快的网站。

在本文中,我们将了解适用于 Web 设计人员和开发人员的 HTTP2 基础知识。 我将解释新协议的一些关键特性,看看浏览器和服务器的兼容性,并详细说明随着我们看到更多采用 HTTP2 时您可能需要考虑的事情。

关于 Smashing 的进一步阅读

  • 预载:它有什么用?
  • 你需要知道的关于 AMP 的一切
  • 提高 Smashing Magazine 的性能

通过阅读本文,您将大致了解在短期和长期的工作流程中需要考虑哪些变化。 如果您想进一步深入研究提出的问题,我还将提供大量资源。 我的目标是为您提供足够的背景知识,以便您在计划迁移到 HTTP2 时能够做出正确的决定。

跳跃后更多! 继续往下看↓

HTTP简史

HTTP 是一个古老的协议,最初定义于 1991 年,最后一次重大修订——HTTP/1.1——发布于 1999 年。1999 年的网站与我们今天开发的网站大不相同。 在http2 解释中,Daniel Sternberg 指出,现在加载一个普通网站的主页所需的数据量为 1.9 MB,显示一个页面需要超过 100 个单独的资源——“资源”是图像或字体中的任何内容到 JavaScript 或 CSS 文件。

HTTP/1.1 在检索显示现代网站所需的大量资源时表现不佳。 正如我们将在本文后面看到的那样,我们作为 Web 开发人员所知道的许多性能最佳实践都来自于我们应对 HTTP/1.1 的限制。

SPDY

2009 年,谷歌的两名工程师发布了他们一直在从事的名为 SPDY 的研究项目。 这个项目解决了 HTTP/1.1 中的一些问题。 SPDY 着手:

  • 允许跨单个 TCP 连接的并发请求,称为多路复用
  • 允许浏览器优先考虑资产,以便服务器首先发送对页面显示至关重要的资源;
  • 压缩和减少 HTTP 标头;
  • 实现服务器推送,服务器可以在被请求之前将重要资源推送到浏览器。

此外,SPDY 需要在浏览器和服务器之间建立加密 (HTTPS) 连接。

SPDY 不会取代 HTTP; 相反,它是协议的隧道,并修改了现有 HTTP 请求和响应的发送方式。 它需要服务器和连接到该服务器的浏览器的支持。 借助 NGINX 中的支持以及 Google 提供的用于在 Apache 中启用支持的软件包,SPDY 的采用量相当合理。 浏览器支持也很好,所有主流浏览器的现代版本都支持它。

关于我可以使用的 SPDY 浏览器支持信息
关于我可以使用的 SPDY 浏览器支持信息。 (查看大图)

HTTP2

我们已经看到 SPDY 取得了一些成功,获得了服务器和浏览器的采用。 但是,您可能还发现,尽管支持 Internet Explorer 11,但 Microsoft 的 Edge 浏览器已经放弃了它。 这里发生了什么事?

由于 Microsoft 实现了对 HTTP2(最新版本的 HTTP 协议)的支持,Edge 中已放弃对 SPDY 的支持。 虽然目前其他浏览器仍保持对 SPDY 的支持,但 Chrome 将在 2016 年取消支持,其他浏览器可能会跟进。 在撰写本文时,Edge、Firefox、Chrome 和 Opera 同时支持 SPDYHTTP2。 随着 Safari 9 的推出,包括 iOS 在内的 Safari 将在今年晚些时候加入该团队。

关于我可以使用的 SPDY 浏览器支持信息
关于我可以使用的 SPDY 浏览器支持信息。 (查看大图)

HTTP2 建立在 SPDY 的成功之上,后者被用作新协议的起点。 因此,SPDY 的大部分目标都在 HTTP/2 中实现。 已放弃对 HTTPS 连接的要求。 也就是说,所有浏览器供应商都决定只为 TLS (https) 连接实现 HTTP2。 因此,虽然您可能在服务器到服务器的通信中使用带有明文的 HTTP/2,但我们为浏览器提供 HTTP2 的用例意味着您需要让您的网站在 https 上运行,然后才能考虑迁移到 HTTP2。

HTTP2 规范于 2015 年 2 月完成; 一年过去了,现代浏览器中的浏览器支持非常出色。 与 SPDY 一样,HTTP2 需要浏览器和服务器级别的支持,并且已经有许多 Web 服务器实现。 您可以在 HTTP/2 wiki 上跟踪这些内容。 W3Techs 还发布了 2015 年 7 月的帖子,详细介绍了采用率。 考虑到它相对较新,该协议的采用正在迅速发生。

我们是否必须更改我们的网站?

HTTP/2 与 HTTP/1.1 向后兼容,因此可以完全忽略它,一切都会像以前一样继续工作。 协议更改对用户完全透明。 许多本文的读者多年来一直在使用 HTTP/1.1 以外的协议。 如果您有一个 Gmail 帐户并使用 Chrome 访问它,那么您将一直使用 SPDY,然后使用 HTTP/2,而对此一无所知。

但是,许多您认为是最佳实践的事情可能会损害 HTTP/2 下的性能。 随着时间的推移,随着越来越多的服务器更新为使用 HTTP/2 并且越来越多的人拥有支持 HTTP/2 的浏览器,您的网站曾经根据最佳实践进行了很好的优化,但似乎开始比针对新协议优化的网站慢。

我们需要改变什么来拥抱 HTTP/2?

在本文的其余部分,我们将介绍一些常见的最佳实践,这些实践将随着 HTTP/2 的采用而成为反模式。 正如我们所看到的,对于许多网站来说,过渡将是一个缓慢的过程。 要迁移到 HTTP/2,您的服务器软件将需要更新以支持该协议——这可能很容易或几乎不可能,具体取决于您的托管方式。

在专门针对 HTTP/2 更改您的网站之前,您还需要考虑您的访问者是否倾向于拥有支持它的浏览器。 吸引大量使用最新浏览器的人的网站所有者将能够比日志显示大多数用户使用旧浏览器的所有者更快地进行切换。 为了反映这一点,我还将就如何在这个过渡时期工作提出一些建议。

转向 TLS

对于很多网站来说,迁移到 HTTP/2 最困难的事情可能根本不是 HTTP/2,而是需要通过安全连接运行网站。 如果您正在开发新站点或更新旧站点,您的第一步应该是确保尽快启动或迁移到 https。 这不仅对 HTTP/2 很重要,Google 使用安全连接作为排名信号,并且浏览器开始将非 https 网站标记为“不安全”。 将来您会发现一些强大的 HTML5 功能(例如地理定位)在没有安全连接的情况下将无法使用。

如果您有一个当前只有 http 的网站,那么我的建议是优先考虑迁移到 https,然后再决定您的 HTTP/2 策略。

将多个图像文件转换为 Sprite

在 HTTP 1.1 中,检索一张大图像对浏览器来说比对小图像发出大量请求要高效得多。 这是因为多个请求彼此排在后面。 为了解决这个问题,我们被建议将我们的小图标变成一个 sprite 文件。

生成的精灵与一个 HTTP 请求一起返回,防止了多个请求排队的问题。 但是,即使访问者在仅显示其中一个图标的页面上,他们仍然需要下载比他们需要的更大的文件才能看到那个图像。

借助HTTP/2 的多路复用能力,这种资源排队不再是问题。 在许多情况下,单独提供小图像会更好; 您只需要提供访问者所在页面所需的内容。 在某些情况下仍然需要创建精灵; HTTP 请求只是性能的一个方面。 将一些图像组合在一个 sprite 中可能会获得更好的压缩效果,因此整体下载大小会更小,尤其是在正在加载的页面上使用所有这些图像的情况下。 然而,精灵不再是最好的选择。

使用数据 URI 内联图像

HTTP/1.1 中多个 HTTP 请求问题的另一个解决方法是使用数据 URI 在 CSS 中内联图像。 以这种方式嵌入图像会使样式表变得更大。 如果您将此与用于连接资产的另一种优化技术相结合,则访问者可能会下载所有这些代码,即使他们从未访问过使用图像的页面。

由于 HTTP/2 中的 HTTP 请求非常便宜,这种“最佳实践”将阻碍而不是帮助提高性能。

连接 CSS 和 JavaScript

作为我们构建过程的最后一步,我们中的许多人将连接我们网站上使用的所有小型 CSS 和 JavaScript 文件。 我们经常希望在开发过程中将它们分开,以便更轻松地管理这些资源——但我们知道向浏览器提供一个文件比提供五个文件更有效。 我们再次尝试限制 HTTP 请求。

如果您这样做,那么登陆您主页的访问者可能会下载您网站所需的所有 CSS 和 JavaScript,即使他们从不使用其中的大部分内容。 作为开发人员,您可以通过在构建过程中仔细选择并包含网站每个区域的特定文件来解决此问题,但这可能需要大量工作。

连接的另一个问题是需要立即从缓存中清除所有内容。 您不能给一些从不更改较长到期日期的文件,而给经常更改的代码库部分提供较短的日期。 如果在单个页面上使用的一行 CSS 被更改,这一切都必须过期。

我想你知道这是怎么回事! HTTP 请求在 HTTP/2 的世界中很便宜。 在开发过程中根据将要使用它们的页面来组织你的资产会好得多。 然后,您可以只提供访问者需要的代码。 下载很多微小的样式表并不重要。 您还可以根据事物变化的频率进行组织; 寿命长的资产可以得到更长时间的照顾。

在主机之间拆分资源:分片

使用 HTTP/1.1,您受限于打开的连接数。 如果加载大量资源是不可避免的,绕过此限制的一种方法是从多个域中检索它们。 这称为域分片。 这可以实现更好的加载时间,但本身可能会导致问题,更不用说为您的网站准备它的开发开销了。

HTTP/2 消除了对域分片的需求,因为您可以根据需要请求尽可能多的资源。 事实上,这种技术可能会损害性能,因为它会创建额外的 TCP 连接并阻碍 HTTP/2 对资源进行优先级排序。

现在如何准备 HTTP/2

如果您正在启动一个您希望有一定寿命但可能由于服务器支持而无法启动 HTTP/2 的项目,那么值得考虑如何为 HTTP/2 做准备。 您现在可以在构建过程中添加一些东西,这将使以后的切换更容易。

除了 Sprite 和数据 URI 之外,还创建单独的资产

如果您正在创建精灵,请将这些单独资产的创建和优化也添加到您的流程中,或者如果您认为这些可以最好地提高性能,则添加较小的特定于页面的精灵。 当您的网站达到临界点时,这将使您更容易从大精灵切换到小(或没有)精灵。

数据 URI 也是如此。 如果您当前在 CSS 中使用这些,请准备好图像,以便在您放弃此技术时使用。

按网站部分组织您的资产

使用 CSS 和 JavaScript 连接,很容易优化以简化开发,因为无论如何文件都会被压缩在一起。 当您切换到 HTTP/2 时,您将通过仔细管理资源来获得最佳性能,以便仅将某个页面所需的东西传递到该页面。 因此,现在开始以这种方式组织您的开发将获得回报。 目前,您可能仍然可以连接,当达到临界点时,您可以停止构建过程的这一部分并单独提供资源。

管理域分片

HTTP/1.1 当前的最佳实践是将分片限制为两个主机名。 如果 TLS 证书对两个主机都有效并且主机解析到相同的 IP,那么有一种方法可以让 HTTP/2 合并连接。 由于浏览器实现者要求 HTTP/2 在 HTTPS 上运行,因此有必要让 TLS 证书在 HTTP/2 上运行。 请参阅 Velocity Conference 中 Ilya Grigorik 幻灯片的第 26 张幻灯片。

来自 Ilya Grigorik 演示文稿的幻灯片
幻灯片来自 Ilya Grigorik 的演示文稿。 (查看大图)

更多未来

最终,我们将获得大量关于 HTTP/2 的最佳实践。 为了获得最佳性能,此协议会将大量控制权交还给您,这意味着您需要为每个项目做出决策。 我没有在本文中介绍如何利用 HTTP/2 的新特性,例如服务器推送。 该技术允许您决定哪些资源是优先级,并指示服务器在不太重要的事情之前分发这些资源。

何时切换?

对于无法完全控制他们部署到的服务器的设计人员和开发人员,可能必须等到他们使用的服务器更新后才能做出决定。 已经有提供 HTTP/2 的托管公司——即使是共享托管——所以部署到支持服务器是你可以向客户推荐的东西,如果你知道他们会受益的话。

一旦您的网站托管在支持 HTTP/2 的服务器上,是继续针对 HTTP/1.1 优化还是针对 HTTP/2 进行优化的决定将归结为您的大多数用户支持的协议。 请记住,HTTP/2 是向后兼容的——您不需要做任何特定的事情。 您需要做出的决定是何时对其进行优化。

您需要根据您的分析数据做出决定。 如果更多的访问者使用支持 HTTP/2 的浏览器,那么我建议这是为这些用户进行优化的合理转折点。 我们中的许多人已经达到了这一点。 您应该使用来自 Can I Use 等网站的数据,以及从您自己的分析和对可能受众的了解中收集的数据。 例如,支持 HTTP/2 的移动设备的用户将最敏锐地感受到 HTTP/2 的许多好处。 如果您的移动流量比例很高,则可能表明您需要尽快迁移到 HTTP/2。 但是,如果您的移动流量来自使用 Opera Mini 浏览的用户的比例很高,那么这将是推迟迁移到 HTTP/2 的一个原因,因为它目前不支持,而在某些地区拥有大量用户世界部分地区。

如果您今天正在构建一个全新的网站,我建议您在整个构建过程中牢记 HTTP/2 优化。 如果在发布时,由于浏览器或服务器的支持,您觉得需要对 HTTP/1.1 做出让步,很多可以在构建过程中完成,让您一感觉就切换到 HTTP/2 版本时机成熟了。

你的 HTTP/2 行动计划

  1. 使用安全连接启动或立即迁移到 TLS这应该是您的首要任务。
  2. 在构建过程中为 HTTP/2 做好准备。 您现在构建的任何网站都可能受益于在其生命周期内针对 HTTP/2 进行的优化。 使用上述提示创建可以针对两种协议进行优化的构建过程。
  3. 检查您的统计数据。 通过将您网站上的浏览器使用情况与 Can I Use 上的支持表进行比较,您可以了解有多少百分比的访问者将从 HTTP/2 优化中受益。
  4. 检查您的主机。 当您达到可以从切换中受益的地步时,您需要确保您的服务器支持 HTTP/2。 与您的托管服务提供商或服务器管理员联系,了解他们的迁移计划。
  5. 推出 HTTP/2 优化。 一旦你的服务器支持 HTTP/2,剩下的就看你自己了。 停止使用旧的最佳实践并切换到新的。 这意味着使用不支持 HTTP/2 的浏览器的用户将获得较慢的体验,这就是为什么您的更改背后的驱动程序应该是大多数人受益的临界点。

当您确实迁移到 HTTP/2 时,对速度提高进行基准测试并查看哪些技术在您的网站上产生了最大的差异会很有趣。 随着人们迁移网站,我期待看到来自真实案例的信息。 这些信息将帮助我们开发新一代的最佳实践。

了解更多

越来越多的关于 HTTP/2 的信息可以在线获得。 我在这里列出了一些资源供您参考,其中许多是我在撰写本文时提到的。

  • “超文本传输​​协议版本 2 (HTTP/2)”(规范),Internet Engineering Task Force 这适用于喜欢阅读规范或需要了解细节的人。 对于其他人来说,HTTP/2 FAQ 是对主要特性的一个很好的总结。
  • http2 解释,Daniel Sternberg 如果您想在计划策略时深入了解协议的细节,这本免费电子书值得一读。
  • 高性能浏览器网络,Ilya Grigorik,O'Reilly 这本书涵盖了 HTTP/1.1 最佳实践和 HTTP/2。 对于想要提高今天的绩效并为未来做准备的人来说,这将是有用的。
  • “HTTP/2 来了,让我们进行优化”(幻灯片) Ilya Grigorik 这套出色的幻灯片提供了有关本文所涵盖的一些要点的更多信息。
  • HTTP/2 指标:Firefox 和 Chrome 这个浏览器插件告诉您您所在的网站是否通过 HTTP/2 提供服务。
  • 如需更多阅读内容,请参阅由 Rebecca Murphey 策划的大量链接列表。