個人覺得相對路徑效能應是快一點點點，因為網頁載入時少了http://xxx.xxx.xxx 這幾個字元，而且不需要再做DNS解析^^

很有趣的比較，不曉得正確性，參考參考~~

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.

answered Gboast

ps.使用相對路徑在變更網址或做coding時會方便許多