Performance 性能：绝对URL与相对URL

什么更快？您是否可以使用或自己托管资源并使用

---

雷米·夏普（Remy Sharp）在他的文章中指出，热链接会导致“额外的HTTP[GET]请求”。如果你将热链接与复制粘贴（嵌入）脚本到HTML中进行比较，我同意。但是，如果您将热链接与本地托管脚本和通过相对路径链接相比较，那么我认为热链接实际上（稍微）更快，因为浏览器不必从相对路径解析绝对URL。但是，在这两种情况下，都会执行一个额外的HTTP GET请求，对吗？

我认为影响这种情况的唯一因素是相关服务器的相对速度（速度），以及您是否希望此代码在任何其他站点上运行（可维护性）.

假设资源未嵌入HTML文档本身（即它已链接），并且资源位于具有相同主机名的同一服务器上，则通过绝对或相对URI检索资源的时间应该几乎相同。无论哪种方式，都将提交一个额外的HTTP请求。如果您想拆分“几乎相同”，我会倾向于相对路径，因为需要解析的HTML数量较少，路径解析（如您所述）可能会更快，因此相对路径的速度会非常、非常、非常小（由于字符串标记器不必处理地址的域部分/地址更短）。这里的区别只是出于好奇才现实。我无法想象一个站点会被优化到这个级别（尽管如此，它可能会建立一个良好的经验法则？相对路径允许您自由更改站点的域/路径，而无需重写..中包含的所有URI）

要考虑的是，如果资源没有托管在同一个服务器上，并且引用的HTML文档的服务器启用了KePiValk，则必须初始化另一个TCP连接来连接到第二个服务器。（以及为解析另一台服务器的主机名而进行的DNS查询，假设访问不是通过IP地址进行的），与同一台服务器上的多个引用资源（GET请求将在现有TCP连接中发出）相比，这会导致额外的开销

---

这同样适用于未启用KeepAlive的服务器；将为每个请求的资源初始化TCP连接。

这更多地是与较低级别的内容（如TCP）有关，而不是http本身。如果您现在从同一Web服务器获得两个项目，您的浏览器可能会将它们拉到同一TCP连接上。这就是通过一个tcp连接进行两个http事务。这避免了建立另一个tcp连接的开销。此开销在流量方面很小，但可能会涉及大量延迟

OTOH，执行两个http事务，每个事务都到不同的服务器可能更快，也可能更快。没错，您有两个tcp连接的开销。在这种情况下，它们是序列化的，必须先完成一个事务，然后才能启动第二个事务。但是，如果您要拉下许多对象，那么第二个、第三个、第四个…连接都可以继续并行，屏蔽延迟问题。在这种情况下，事情可能会发展得更快，因为小对象可能不受ISP的带宽限制

水的确是泥泞的

---

只需关注延迟和带宽。这实际上取决于资源的数量和大小。

正确答案是-这取决于

热链接可能会很慢，因为-

需要额外的DNS查找

无法重用现有的TCP/IP套接字连接

在服务器上托管可能会很慢，因为-

浏览器只允许每个主机有n个并发请求。如果对同一主机有多个请求，则可能会引入队列，这可能会很慢。数字“n”是特定于浏览器的，介于2和6之间

如果你假设两台服务器在各个方面都是相同的，我会说在你的服务器上托管会更快，尤其是在每台主机连接数为6的新浏览器上

但遗憾的是，事情从来没有这么简单。我建议只有在以下情况下才使用热链接-

您的域上有太多的资源（图像/js）

另一个服务器是CDN，而且该资源非常流行，因此它很有可能出现在浏览器的缓存中

---

对于所有其他用例，最好在自己的服务器上托管。

客户机解析相对URI所需的时间完全可以忽略不计

因此，使用绝对或相对URI链接到文档同一域中的资源没有任何区别

唯一的区别是当资源托管在不同的服务器上时。然后，您需要与该服务器建立额外的TCP连接，而对已建立连接的服务器的额外HTTP请求可以使用该连接。

尽管“您的服务器”可以是

res1.domain

，

res2.domain

，也就是说，在多个内部域之间按类型（或负载）划分（这与浏览器“看起来不同”的隐式负载平衡不同）。一旦缓存，DNS问题就不存在。