Short answer

It makes no difference because the browser optimizes and makes calls to the same place. The main difference is the one you mentioned yourself, in the amount of bytes of the HTML file.

Long answer

The main use is to save bytes in source files, but there are some other uses, depending on the type of relative URL. basically there are three of them:

<a href="menu2.html">menu2</a>

<a href="../../teste/menu2.html">menu2</a>

<a href="/menus/menu2.html">menu2</a>

 <a href="//outrosite.com.br/pagina1.html">link em outro site</a>

For the end user, the difference is almost zero, as the browser (or application in general) that requests will normalize the address in an imperceptible time.

However, if you consider ease of maintenance within the "efficiency" scope, everything changes:

• Absolute URLs tend to be a headache when reusing the markup to change the website address or replicate the structure on a new site, and are impractical if you serve more than one URL with functioning different by the same script / page (in case the same application answers multiple URLs) or you want to answer both http:// and https:// .

  Note that you can use an absolute URL without setting the protocol to resolve the problem mentioned. Ex: <a href="//example.com/index.html">

• URLs relative to the current path (without the start bar indicating "relative to the root") have their advantage in structures that can be reused at different levels of the site, but are more complicated to maintain when the structure references things that should always be in the same place (like icons for a website).

  Ex: <a href="index.html"> (depends on the page where you are to determine the rest of the path.) It can either mean meusite.com/index.html , or meusite.com/arquivos/index.html , if the link is arquivos/pagina3.html , for example.)

• Root URLs tend to be better for global things, and avoid many errors and waste of time in the cases mentioned in the paragraph above, referring to media files and global site usage scripts .

  Ex: <a href="/index.html"> (it will always be the same index.html , within the site that presented the link, it does not matter which page or folder your link was shown in)

The ideal in most conventional site and web application cases is a relative relative with relative to the root , relative to the root for global things, and relative to the folder (without start bar) for things that can change level (such as a collection of folders and scripts from a sub-application or stand-alone site functionality), either in the same application, or reuse code for another application. p>

  

When you are going to give a redirect by sending a header Location: http://www.exemplo.com.br/ , you should always prefer an absolute path, but note that in 2014 an RFC has relaxed this restriction, allowing relative URLs.

When you want to use URLs in CSS that can be included with @import it might be interesting to use the root path, so you do not get lost while trying debug style sheets at different levels of the site.

Are there any practical differences in the different URL types?

The other answers are very good.

I can only agree that any efficiency difference compared to the bandwidth used (number of bytes transferred) or performance will be minimal.

However, thinking in terms of portability (see ISO 9126 Quality of Software standard), I believe that systems should use Site root URLs to access your own resources (images, styles, scripts, etc.) and always avoid the protocol for external resources.

What I consider to be most important is to keep a pattern on URLs, and a pattern only exists if all URLs start with the meso prefix. This helps keep developers healthy and eliminates a lot of confusion, such as having to mentally calculate directories.

Is your application prepared to be secure?

Using absolutely absolute paths can lead to serious issues with sites that use HTTPS . The problem begins when your site is accessed via HTTPS and tries to include an HTTP (non-secure) resource.

For example, let's assume you want to include jQuery from a CDN :

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>

However,ifyoursiteisaccessedviaHTTPS,thebrowserwillcomplainabouttheinsecure(HTTP)featureandwillnotloadthescript.Asaresult,Googleitselfindicatesthemostappropriateway:

Note: According to this link , Internet Explorer in versions 7 and 8 will download it twice if you include a CSS with a non-protocol URL, but I did not test it.

A perfectly viable alternative is to always include external resources using HTTP .

A personal experience

Regardless of the approach, not everything is flowers.

Some time ago I made a system using a Java framework that generated root URLs from the server, for example:

  

/application/style.css

However, when the application was installed in production, problems occurred because the company's branches used it under a reverse proxy and the root path would have to look like this:

  

/web/application/style.css

Would the solution simply add the /web path to the URLs generated by the framework? No, because the company's headquarters accessed the system directly, without going through the reverse proxy. That is, the application served two different types of sources that accessed it by different URLs.

A possible solution would be to identify the source of the request or to look at the URL of the request and dynamically change the root of the generated URLs, but in that situation it was much simpler and more straightforward to use

  

../ style.css

This was possible because I developed the system so that all pages were on the same level: /home , /usuarios , /clientes , etc.

But even if the system were not so, I could add the relative path programmatically, just as frameworks usually do by adding a base path to all URLs, right?

  

$ {basePath} / style.css

Here basePath can be both the path relative to the site root and the path of the current page to the home directory where the style is.

The difference should be negligible. Looking at how the browser sends requests (for example, in Chrome under "Tools" -> "Developer Tools" -> "Network") I noticed that both calls send identical URLs in headers .

$.get('/echo/json/');

...

$.get('http://fiddle.jshell.net/echo/json/');

Request details in both:

Request URL:http://fiddle.jshell.net/echo/json/

Example in jsFiddle . (if the example does not work - i.e. if only a single request is made - increase the time in timeout to more than one second)

That is, determining the absolute path from relative is something done in the browser , which should be a simple question of concatenating strings. In the face of overhead of network communication, the difference in performance should not be significant (in fact, it can be argued that using short URLs improves performance) to be downloaded from the server gets smaller).

Efficiency NO. But in development it MUCH DIFFERENCE. Relative paths allow you to rely on two or more environments, for example: set up separate programming environment, approval and production using the SAME code. I can develop and test without compromising the code that is in production, when the improvement or correction is homologated I copy it to the production.

In case of multi-domain system

Sometimes we work on multiclients applications. That is, an application for several clients, these being able to have their domains customized. So for this case, at the development level, it is better to use relative URL. Because? In the case of absolute URLs, the item always points to the same domain: link . However, if you have a custom domain, this can be a problem because you will be in link and will be redirected to the absolute URL domain. So in multidomain applications, the relative URL is used because "/article.html" is equivalent to link and link depending on which domain you are in.

Already, for the browser, these changes are indifferent in case of performance or usability. This implies just the same navigability.