性能：绝对 URL 与相对 URL
什么更快？ 热链接（内联链接）到绝对 URI 或自己托管资源并使用 相对 URI？
Remy 在他的有关如何在 Internet Explorer 中设置 HTML5 元素样式的教程中， Sharp 指出热链接会导致“额外的 HTTP [GET] 请求”。如果您将热链接与复制和复制进行比较，我同意。将脚本粘贴（嵌入）到 HTML 中。但是，如果您将热链接与本地托管脚本并通过相对路径链接进行比较，那么我认为热链接实际上（稍微）更快，因为浏览器不必解析绝对路径来自相对路径的 URL。然而，在这两种情况下，都会执行额外的 HTTP GET 请求，对吗？
What's faster? Hot linking (inline linking) to an absolute URI or hosting the resource yourself and using a relative URI?
In his tutorial on how to style HTML5 elements in Internet Explorer, Remy Sharp states that hot linking causes an "extra HTTP [GET] request." I agree if you're comparing hot linking to copying & pasting (embedding) the script into the HTML. But, if you're comparing hot linking to hosting the script locally and linking via a relative path, then I'd argue that hot linking is actually (ever-so-slightly) faster because the browser doesn't have to resolve the absolute URL from the relative path. In both cases, however, an extra HTTP GET request is performed, correct?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
正确答案是——这取决于情况。
热链接可能会很慢，因为 -
在服务器上托管可能会很慢，因为 -
如果您假设两台服务器在各个方面都是相同的，那么我想说在您的服务器上托管会更快。尤其是在每台主机的连接数为 6 个的新浏览器上尤其如此。
但遗憾的是，事情从来没有这么简单。我建议仅在以下情况下使用热链接 -
对于所有其他用例，您最好在自己的服务器上托管。
The correct answer is - it depends.
Hotlinking can be slow because -
Hosting on your server can be slow because -
If you assume both servers are identical in every respect, I'd say hosting on your server is going to be faster. This is true especially on new browsers where the number of connections per host is 6.
But sadly, things are never so simple. I'd recommend using hotlinking only if -
For all other use cases, you are better off hosting on your own servers.
客户端解析相对 URI 所需的时间绝对可以忽略不计。
因此，无论使用绝对 URI 还是相对 URI 链接到文档同一域中的资源都没有任何区别。
唯一的区别是资源托管在不同的服务器上。然后，您将需要一个到该服务器的额外 TCP 连接，而到您已经有连接的服务器的额外 HTTP 请求可以使用该连接。
The time the client needs to resolve the relative URI is absolutely negligible.
So it doesn’t make any difference whether you link to a resource in the same domain of the document using absolute or relative URIs.
The only difference will be when the resource is hosted on a different server. Then you’ll need an additional TCP connection to that server whereas an additional HTTP request to a server that you already have a connection to could use that connection.
这更多地与 tcp 等较低级别的东西有关，而不是 http 本身。如果您现在从同一个网络服务器获取两个项目，您的浏览器可能会通过同一个 TCP 连接获取它们。这是通过一个 tcp 连接进行的两个 http 事务。这避免了建立另一个 tcp 连接的开销。从流量角度来看，这种开销很小，但可能会导致大量延迟。
OTOH，执行两个 http 事务，每个事务都转到不同的服务器，可能更快，也可能更快。确实，您有两个 TCP 连接的开销。在这种情况下，它们被序列化——一个必须在第二个开始之前完成。但是，如果您要拉取许多对象，那么第二个、第三个、第四个……连接都可以并行进行，从而掩盖延迟问题。在这种情况下，事情可能会进展得更快，因为小对象可能不受 ISP 的带宽限制。
水确实很浑浊。
只需留意延迟和带宽即可。实际上取决于您资源的数量和规模。
This is more to do with lower-level stuff like tcp rather than http per-se. If you get two items from the same webserver nowadays, your browser is likely to pull them over the same tcp connection. That's two http transactions over one tcp connection. This avoids the overhead of making another tcp connection. This overhead is small in traffic terms, but can involve a lot of latency.
OTOH, doing two http transactions where they each go to different servers maybe faster, or maybe not. True, you have the overhead of two tcp connections. In this case they are serialized—one must complete before the second one can start. However, if you were pulling down many objects then the 2nd, 3rd, 4th… connections could all proceed in parallel, masking the latency problem. In this scenario things may go a lot faster as small objects may not be subject to your ISP's bandwidth limiting.
The waters are muddy indeed.
Just keep an eye on the latency and bandwidth. Depends really on the number and sizes of your resources.
我想影响这种情况的唯一因素是相关服务器的相对速度（为了速度）以及您是否希望此代码在任何其他站点上运行（为了可维护性）。
I would imagine that the only things affecting such a situation are the relative speeds of the servers in question (for speed) and whether you expect this code to run on any other site (for maintainability).
假设资源没有嵌入到 HTML 文档本身中（即，它是链接的），并且资源位于具有相同主机名的同一服务器上，则通过绝对或相对 URI 检索资源的时间实际上应该相同。无论哪种方式都会提交额外的 HTTP 请求。如果你想分割“几乎相同”，我会倾向于相对路径速度非常非常非常快，因为需要解析的 HTML 量较少，路径解析（正如你提到的）可能是更快（因为字符串标记器不必处理地址的域部分/地址更短）。这里的差异只是为了好奇而现实。我无法想象一个网站会被优化到这个级别（尽管，它可能会建立一个很好的经验法则？相对路径允许您自由更改网站的域/路径无需重写其中包含的所有 URI..）
需要考虑的一件事是，如果资源未托管在同一服务器上，并且引用 HTML 文档的服务器启用了 KeepAlive，另一件事是必须初始化 TCP 连接才能连接到第二个服务器（以及进行 DNS 查询来解析其他服务器的主机名，假设访问不是通过 IP 地址进行），与多个引用的资源相比，会产生额外的开销在同一服务器上（其中 GET 请求将在现有 TCP 连接内发出）。
这同样适用于未启用 KeepAlive 的服务器；将为每个请求的资源初始化一个 TCP 连接。
Assuming the resource is not embedded within the HTML document itself (i.e. it is linked), and the resource is on the same server with the same host name, the time to retrieve the resource via absolute or relative URI should be virtually identical. An additional HTTP request will be submitted either way. If you want to split the 'virtually identical', I would lean toward the relative path being a very, very, very small amount faster, due to the smaller amount of HTML that needs parsed, the path parsing (as you mentioned) potentially being quicker (due to the string tokenizer not having to deal with the domain portion of the address/the address being shorter). The difference here is only realistic for curiosity's sake.. I can't imagine a site being optimized down to this level (although, it may establish a good rule of thumb? Relative pathing allows you to freely change the domain/path of the site without having to rewrite all of the URIs contained within..)
One thing to consider would be if the resource is not hosted on the same server, and the server of the referencing HTML document has KeepAlive enabled, another TCP connection will have to be initialized to connect to the second server (as well as a DNS query being made to resolve the other server's host name, assuming the access is not via IP address), resulting in additional overhead in comparison to multiple referenced resources on the same server (where the GET requests would be issued within the existing TCP connection).
The same would apply to a server that does not have KeepAlive enabled; a TCP connection will be initialized for each requested resource.