Difference between absolute and relative Urls in page contents

Question

The contents of the page can be requested by entering a complete URL, relative or relative to the root of the location where our base file is located (generally the index.php or index.html):

Complete

<script src="http://www.meusite.com/assets/js/script.js"></script>

Relative

<script src="assets/js/script.js"></script>

Root-related

<script src="/assets/js/script.js"></script>

Question

There is some practical difference in page efficiency between using any of the three options we have at our disposal?

^{Of course we have a reduction in the amount of code, but beyond that...}

Answer 1

Short answer

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 the source files, but there are some other uses depending on the type of relative URL. basically there are three of them:

1. URL relative to where the current file is

   Ex.:

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

   Here you are accessing a file in the same directory you are.

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

   Here you are accessing a two-level file before the directory you are in.

2. URL related to the server (full domain) that the current file is

   Ex.:

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

   Here you are accessing another file from the root of the site.

3. URL relating to the protocol current

   Ex.:

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

   Here you are accessing another site using the same protocol. This case is widely used to maintain compatibility in the use of HTTPS and HTTP and ensure that all accesses are in the same protocol, regardless of the way the user initially accessed the site.

Answer 2

For the end user, the difference is practically null, because the browser (or application in general) that makes the request will normalize the address in an imperceptible time.

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

• Absolute urls tend to be a pain in the ass to repurpose Markup to change the address site or replicate the structure on a new site, and are impracticable if you attend more than one URL that works differently by the same script/page (in case the same application caters to multiple Urls) or want to meet as much http:// how much https://.

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

• Urls relative to the current path (without the initial bar indicating "relative to the root") have its 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 (such as icons of a site).

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

• Urls for the root tend to be better for global things, and avoid too many errors and waste of time in the cases mentioned in the above paragraph, referring to media files and scripts for overall website use.

  Ex: <a href="/index.html"> (will always be the same index.html, within the site that presented the link, no matter in which of its pages or folders the link was shown)

The ideal in most conventional cases of website and web application is a mix of relative with root-related, being relative to the root for global things, and relative to the folder (no initial bar) for things that may change levels (such as a collection of folders and scripts from a sub-application or functionality isolated from the site), either in the same application, or reuse code for another application.

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

When you want to use CSS Urls that can be included with @importit might be interesting to use the root path, so as not to get lost in trying thresh style sheets at different levels of the site.

Answer 3

There are practical differences in different URL types?

The other answers are very good.

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

However, in terms of portability (see standard ISO 9126 Software Quality), I believe that systems should use whenever possible Urls related to the site root to access its own resources (images, styles, scripts, etc.) and always avoid the protocol for external resources.

The aspect that I consider most important is to maintain a pattern in Urls and a pattern only exists if all Urls start with the meso prefix. This helps keep developers sane and eliminates a lot of confusion, such as having to keep calculating directories mentally.

Your application is prepared to be safe?

Using completely absolute paths can create serious problems on websites that use HTTPS. The problem starts when your site is accessed via HTTPS (half secure) and tries to include a resource HTTP (unsafe).

For example, let’s assume you want to include the jQuery of a CDN:

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

However, if your website is accessed via HTTPS, browser will complain of unsafe resource (HTTP) and will not load the script. As a result, Google itself indicates the most appropriate form:

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

Note: second this link, Internet Explorer in versions 7 and 8 will download twice if you include a CSS with a protocol-free URL, but I didn’t run the test.

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

A personal experience

Regardless of approach, not everything is flowers.

Some time ago I made a system using a Java framework that generated Urls concerning the root of the server, for example:

/application/style.css

However, when the application was installed in production problems occurred as the company’s subsidiaries used it under a reverse proxy and the path to the root would have to be like this:

/web/application/style.css

The solution would simply add the way /web Urls generated by the framework? No, because the company headquarters accessed the system directly, without going through the reverse proxy. That is, the application met two types of different origins that accessed it by different Urls.

A possible solution would be to identify the source of the request or still look at the URL of the request and dynamically change the root of the generated Urls, but in that situation was much simpler and direct to use paths related to pages:

../css style.

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 wasn’t like this, I could add the relative path programmatically, exactly the same way frameworks normally do by adding a base path to all Urls, it’s not even?

${basePath}/style.css

Here basePath can be both the path relative to the site root and the path from the current page to the base folder where the style is.

Answer 4

The difference should be negligible. Inspecting the way 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/');

Details of the request, 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 the timeout for more than a second)

That is, determining the absolute path from the relative is something done in itself browser, which should be a simple question of string concatenation. Facing the overhead network communication, the difference in performance should not be significant (in fact, it can be argued that using short Urls improvement performance - because the file size to be downloaded from the server gets smaller).

Answer 5

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

Answer 6

In case of a system for several domains

Sometimes we work in applications multiclients. That is, an application for several clients, these can have their domains customized. So for this case, at the development level, it is better to use relative URL. Why? In the case of absolute Urls, the item always points to the same domain: https://dominio.com/arquivo.html. However, if you have a custom domain, this may be a problem, as you will be on https://personalizado.com/ and will be redirected to the absolute URL domain. Therefore, in multi-sector applications, the relative URL is used, because "/.html file" is equivalent to https://dominio.com/arquivo.html and https://personalizado.com/arquivo.html depending on the domain you are using.

For the browser, these changes are indifferent in case of performance or usability. This implies only in navigability.