8

Let's say I want to link to a parent directory (http://example.com/library/) from a subdirectory (http://example.com/library/html/basics/).

The link to the parent directory can be:

  • href="../../"
  • href="/library/"
  • href="http://example.com/library/"

Is there a speed difference based on which way I write the link? I'm not asking about the website loading speed, but if there is a noticeable difference while traversing to the directory.

  • 4
    Why would you think there would be a difference in traversing the directories? As far as the server is concerned, it's just a hit, the user wouldn't actually be "moving around" from one directory to another - they are just requesting another resource. Whether somebody goes to example.com first and then example.com/library/books/fiction/1984.html with or without "traversing" all the path should be irrelevant. And remember that you'll be having multiple user - one could be requesting the base directory, while another a deep nested one and the server would just be doing the same work. – VLAZ Jul 30 '16 at 23:45
  • 1
    All 3 of those URLs are identical when it comes to the HTTP request, so as far as the server is concerned, there is no difference - the browser must resolve the request to http://example.com/library/ in all 3 cases, otherwise it's simply not valid. – MrWhite Jul 31 '16 at 14:49
  • One thing missed so far is the effect on maintaining the site. Using /library/ has the following advantages over the other options: you don't need to update all your links if you change your domain name or move to SSL everywhere; if you change the folder name, or move the child folder you can find & replace the path easily, working out what needs to change from ../.. etc. – Zhaph - Ben Duguid Aug 4 '16 at 19:37
9

Effect for browser:

Though this looks like a bit of work for web browser, but technically it does not make much of a difference. The browsers are too fast to handle these relative url structure and make a call to application server

Effect for application Server:

None, as it needs to return the requested file (relative/absolute link ultimately maps to a web path)

Effect on page size:

Yes there would be some reduction in size (again not something that would make a huge difference to your page's performance that could be achieved by something like content encoding gzip or minifying resource)

So i think technically the absolute/relative urls dont make much of a difference on page speed / any weightable matrix.

Yes it make huge difference in managing multiple environments like dev, pp, prodpp etc

Example : on your local development you might have dev.example.com on pre production you might have : pp.example.com . .

So in those scenarios it would be relatively easy to manage code with relative urls (though can be managed by environment settings also)

|improve this answer|||||
2

HTML/CSS relative based paths will always be faster for server speed, this is because the server has less code to send. Relative paths in HTML or CSS form are translated by the end-user's browser and not the server.

So technically, its faster for the server and slower for the end-user, but the end-user would never notice the difference, since the processing required is less than nano-seconds, therefore end users are far more likely to see the difference from relative because the server is going to be able to serve them better.

|improve this answer|||||
  • "HTML/CSS relative based paths will always be faster for server speed, this is because the server has less code to send." I don't really believe that. While http://example.com/category/cats.html is longer than /category/cats.html, I can't see this having a significant enough impact on performance to even be considered. Gzipping the sent data, which takes fractions of a second, would both already cover the "size inefficiency" and whatever "speed penalty" it imposes. – VLAZ Jul 30 '16 at 23:41
  • I did say technically faster... and you're picking strings. even with cached compression using gzip, a html page with absolute vs relative will be slightly larger (gz relative vs gz absolute), hence technically... the end-user has to decompile that gzip, and resolve the relative, this is slower for the end user... but this is so minimal the end user isn't going to notice, again this is fact. Even with server side technologies such as GZIP a compressed HTML file, or CSS file using relative paths vs absolute, relative will always be smaller in a compressed file, again this is fact, try it. – Simon Hayter Jul 31 '16 at 8:09
  • While the difference may just be a few bytes, or few kb on larger pages, the savings for one visitor is not major, but in the millions of users that becomes more noticeable... hence, technically faster. Now, if your asking if its worth using relative vs absolute for the average website with only a few hundred visits a day? the answer is probably no... but that wasn't the question being asked. – Simon Hayter Jul 31 '16 at 8:13
  • The performance hit, at best, is going to be negligible. It could be entirely non-existent, as well. Servers are generally good at one thing. It's in their name - serving content. I don't think few bytes or a KB would be a problem. It's just content, at the end. If size were a problem, the HTML we write would look very different. That's not the case. The minification of the content is purely for user convenience in case their bandwidth is small. I'm confident that processing the request and responding is where the performance is, not in the actual act of sending the data. – VLAZ Jul 31 '16 at 10:27
  • 1
    "relative based paths will always be faster for server speed" - but the OP does state, "I'm not asking about the website loading speed" - which is the only place where the site could possibly be faster. (To be honest, I'm not really sure what "speed" the OP is talking about?) – MrWhite Jul 31 '16 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.