Performance: Absolute vs. Relative URLs

Question

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?

Diplomate

Answer 1

The correct answer is - it depends.

Hotlinking can be slow because -

1. An extra DNS lookup is needed
2. Unable to reuse an existing TCP/IP socket connection

Hosting on your server can be slow because -

1. Browsers only allow n concurrent requests per host. Having one more request to the same host has the potential to introduce queuing, which can be slow. The number 'n' is browser specific, and is anywhere between 2 and 6. See browserscope > network > connections per host name.

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 -

1. You have too many resources (images/js) on your domain
2. The other server is a CDN, and the resource is a popular enough so that there is a decent chance it will be present in the browser's cache. Think JQuery on google's servers.

For all other use cases, you are better off hosting on your own servers.

Sabrasabre

Although "your server" could be res1.domain, res2.domain, that is, split up by type (or load) across multiple internal domains (this woul differ from implicit load balancing where it "looks different" to the browser). The DNS issue should be non-existence once cached. – Xerophyte

Answer 2

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.

Guest

Answer 3

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.

Brat

Answer 4

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).

Ossieossietzky

Answer 5

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.

File