Relative vs Absolute Links - Which is Slower?

[bzgzd]

Hi.

I am trying to find out what is best to use for internal links on my site (for example for my menu navigation).

I see 3 options:
A) href="page.html"
B) href="/page.html"
C) href="http://www....com/page.html"

I found many blogs about this and some say C is best and few say A is best because of SEO or maintenance.

But my question is are those options same from performance point of view?

[tedster]

No discernible difference from a performance point of view.

[g1smd]

I nearly always use B, occasionally C.

I *never* use A, as there are many dangers, especially when URL rewriting is employed on a site.

[rocknbil]

Think of it from your viewpoint, as a browser on the edge of the Internet. When you click a link

<a href="/somepage.html">Some Page</a>

<a href="http://example.com/somepage.html">Some Page</a>

What actually happens when you click the two links?

In both cases, your browser executes a request for http://example.com/somepage.html. So in respect to faster or slower, there is . . . zero difference.

Exception. :-)

The non-full URL makes the actual page smaller by a few bytes (or kilobytes, with a lot of links) so the page itself will load faster.

However, I've got my usual "two cents" about this:

I found many blogs about this and some say C is best and few say A is best because of SEO or maintenance.

I'll forgo the SEO comment, as there may be things I don't know about in that regard. It seems to me this is the same issue as my example, a link on a web site's page is still http://example.com/somepage.html. However, maintenance wise, IMO the statement about A couldn't be further from the truth, and here is why.

A) href="about.html"

Consider the following:

index.html
about.html
contact.html
css/sitename.css
js/sitename.js
gallery/project-one-name/index.html
gallery/project-one-name/images/screenshot.jpg
gallery/project-two-name/index.html
gallery/project-two-name/images/screenshot.jpg

So from index.html, href="about.html" is fine.

But from gallery/project-one-name/index.html, the directory-relative link to about is usually found as:

href="../../../about.html"

Which works. OK, now let's look at the CSS and JS for the same page:

<link rel="stylesheet" type="text/css" href="../../../css/sitename.css">
<script type="text/javascript" src="../../../js/sitename.js"></script>

OK that works too. But lets compare it with the same files from root:

<link rel="stylesheet" type="text/css" href="css/sitename.css">
<script type="text/javascript" src="js/sitename.js"></script>

So now you want to create a new page. To link it up with all these resources, you need to code up the directory relative path. Which directory does it go in? Now you have to chase down all your href's, src's, links via Javascript, make sure they all have the same toothpick syndrome disease before they work.

Boss says "no, move that to root, not in the gallery directory."

You have to re-code them.

But if you always use this,

B) href="/about.html"

It doesn't matter where in your file system a file exists. The forward slash means "Start at this domain's root and link along this path." It is the equivalent of assigning http://example.com/ to every single link you create.

Look at the following, using this concept:


href="/about.html"
<link rel="stylesheet" type="text/css" href="/css/sitename.css">
<script type="text/javascript" src="/js/sitename.js"></script>

A file containing those domain-relative links can be moved anywhere: root, gallery, project-one-name, 20 directories deep, and it will always work. Without having to chase toothpicks. So the idea that this

A) href="about.html"

is "less" maintenance than this

B) href="/about.html"

is only true if your site has no directory structure to speak of, in which case it really doesn't matter.

Second, this gets really REALLY important if you start using mod_rewrite. Let's say you have an SEO friendly URL,

http://example.com/Green-Widgets

That actually rewrites to

/scripts/product-display/some-section/yourscript.php

The URL is still "top of the domain," right? But any links in your PHP script have to do this . . .

../../../../

or this

/

To link back to home. One you will have to change on a case-by case basis,the other . . . well it doesn't matter if you hard code it or not, it remains the same across the site.

This becomes really important in a custom 404 script, because it can occur from **any** directory, and in order to make the links back to home, about, etc. work, you have to do one of the two: full URL or domain-relative linking.

One last reason I don't like the full URL: if you have a particular template or cloned scenario, let's say, three sites that act differently, you can just move this

/about.html

from domain A to domain B without changing a single thing.

There is one down-side to this: When developing a page on your local computer, /these-links won't work. Your computer is not a web server so doesn't know what to do with /. But once developed, you do a quick S & R of href=" and replace with href="/ before uploading.

There is one time you **need** to use the full URL: when moving to and from a secure location.

[buckworks]

Rocknbil, thank you for a superb post! :)

[bzgzd]

It seems to me this is the same issue as my example, a link on a web site's page is still http://example.com/somepage.html

Those SEO blogs saying that full absolute links are better contain some "horror" stories based on fact that for google and co this is not same:
http://example.com/somepage.html
http://www.example.com/somepage.html

But there are other SEO experts saying relative links are better because with absolute links google thinks those pages are not one page...

For me I think I will continue using B.

[incrediBILL]

The upside to absolute links is that sloppy scrapers often inadvertently leave links directly to your site.

This makes finding them easier and it also gives you a valid link from the scrapers site assuming you leave it intact.

Relative links just make life so much easier for people to mass copy an entire website and have it run first time in a new location.

[rocknbil]

Pojnt taken on that one, but the determined will always find a way no matter how you code it.

Those SEO blogs saying that full absolute links are better contain some "horror" stories based on fact that for google and co this is not same:
http://example.com/somepage.html
http://www.example.com/somepage.html

Choose one or the other, www or non-www, and this should be 301'ed on your site to avoid duplicate content. Right?

Besides, using the full URL on your site is no guarantee that someone is going to link to it incorrectly, omitting or including the www. you should still have a 301 to one or the other.

[jimh009]

In terms of performance, I've never seen a difference.

However, in terms of reliability and reducing the probability of errors, years ago I went to straight full links (aka..."http://www.mysite.com/etc...")

Part of the reason was because of maintenance - in Dreamweaver I find it simpler to do it this way and this reference provides me a handy reference for the full page link on the actual site.

There's also another benefit, though. When you have a deep directory structure, you avoid the nasty /../../ problem. Or, in English, if you have a page deep in one directory and a link on that page is pointing to another page deep inside another directory, by using the full link you avoid having to double check to make sure the actual link is going backwards the required number of folders. I've had far too many times where one of those "/.." somehow disappears or gets chopped off by either Dreamweaver or by me simply not paying attention when playing with the code.

Full links always work, thus, I use them. I also agree that you should either choose "www" or "no www" and then use them throughout the site. Never mix and match.

[lammert]

I use version C because many people seem to like my content and copy it verbatim to their site. This makes it easy to catch them because all internal links still point to my sites. It also gives incoming traffic and link juice if I decide to keep those pages life for a while. I haven't seen any performance issues.

The only drawback I can think of is that it becomes more difficult if I wanted to transfer a site to a new domain name.

[edited by: lammert at 10:04 am (utc) on Feb 9, 2010]

[dreamcatcher]

I *never* use A, as there are many dangers, especially when URL rewriting is employed on a site.

A base href in your head tags usually sorts any rewrite problems.

dc

[bzgzd]

Thanks for answers.

Choose one or the other, www or non-www, and this should be 301'ed on your site to avoid duplicate content. Right?

I am doing my first web page so I had no idea about this... but now I learned something about .htaccess and put there this:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^myPage.com
RewriteRule (.*) http ://www.myPage.com/$1 [R=301,L]

Another think that came to my mind is that I will change my internal links pointing to my main page from href="/index.php" to just href="/" I feel it could be better for seo and if it is same then it is at least shorter. :-)

[jkovar]

If it's a site with a large mobile/smartphone audience, you definitely want to use a base-href and either A or B.

[pageoneresults]

Relative Paths = src="images/file.gif", src="./images/file.gif, src="../images/file.gif, src="../../images/file.gif
Root Relative Path = src="/images/file.gif"
Absolute Path = src="http://www.example.com/images/file.gif"

The <base> element and how to use it effectively
2007-08-03 - [WebmasterWorld.com...]

I use absolute paths for all primary navigation elements. I use Root Relative everywhere else. I will not use Relative Paths. Why, they lack all the URI keyword constructs. Also, Relative Paths leave you open for DNS Jacking.

I look at it this way. I try to avoid any implementation where the UA has to guess at something. I've seen the guessing games get folks into trouble.

From a performance point of view, I would think A would be the least performance oriented because the UA now has to guess.

[blend27]

I use C except when I need to point to Media Files on HTTPS pages, and then it’s a B. I simply setup an application scope variable that points to http://www.example.com/ and then when outputting the link prefix it with that variable. The reason I do this is I host most of the sites on IIS and the HOST of first site I built had a "convenient: UNLIMITED Subdomains feature", and any subdomain by default was pointing to the root of the domain files. The links on site then were created in A style. Someone had linked to the site as in http:// WW.example.com/ by mistake and entire site got indexed under that root URL. I also use C for the reason of not having BOTS knocking on HTTPS version of the site. So there is no guessing for me from that point. Plus what incrediBILL said ;)

[carguy84]

root relative paths on everything I've ever linked.

[explorador]

I agree with all the previous comments, I just add: It depends.

Why? if you develop some kind of CMS (like I did in the past) you will find very useful to use relative paths "/page/" or "/dir/page" as then you can move your CMS from server to server and domain to domain with no problem, unless you will be using the VARIABLE of the domain name.

[Silvery]

incrediBILL has a good point that it makes it slightly harder to scrape-n-steal, and you might benefit slightly from inadvertent scraper links back to you.

Another VERY good reason to use absolute links from an SEO standpoint is that I see so very many cases where relative links result in errors on sites. They seem to inevitably get moved in the directory structure (dreamcatcher is right that a Base HREF can help with this), and there's inevitably a link leak when various subdomains are used, resulting in massive duplication. These errors seem to occur no matter how good a site's programmers are.

I see absolutely ZERO SEO upside to using relative links. I see no compelling reason to believe search engines treat internal links differently, whether they are coded as absolute or relative.

The only reasons I see in favor of using them is to simplify coding, and possibly reduce code bloat (to an extremely minor degree in most cases).

[CyBerAliEn]

My preference is root relative (/css/stuff.css). I fail to see any upside to using a link like "http://example.com/css/stuff.css".

It especially makes moving a page, file, etc from one spot in the site to another spot in the site without breaking everything. It is very frustrating when editing a site someone else made and finding tons of '../../../../../something.htm' all over the place. Biggest problem with this style of links is that if you EVER want to move the file to another directory position, everything gets broken.

And given how most sites I work on are "module-ized" and using URL rewriting, it just makes sense to setup links in a format like '/people/', '/about/', etc.

[frontpage]

We only use version C, the absolute full URL, due to problems with scrapers copying our content.

[BillyS]

Agree with the scraper comments, we use C - changed to C from B.

[Trav]

There are a lot of interesting perspectives here, and I think that's the take-away: the scheme you use depends greatly on your other technology and development choices. For some, the convenience of a root-relative path is the best choice, whereas for others using the base href tag and doc-relative links is the way to go.

On the sites I manage, I tend towards doc-relative links because I want to be able to develop locally and then deploy with a minimum of conversion. Certain elements like required PHP files have to be able to render locally, or there's no way I can develop the site. And there are swf's and flv's - always fun writing correct resource paths there.

All else being equal, I'd say less is more. If the link works without the domain, and there's no other compelling reason to do otherwise, then just make it short.

[httpwebwitch]

A former employer of mine was very concerned about scrapers. So it was company policy to use fully qualified URLs for everything. "http://www.example.com/about/".

On my own projects, I use rooted paths, always. like "/about/".

[JAB Creations]

Use the base element, it's absolutely invaluable especially if you use it to make all your code work flawlessly regardless if it's on the live domain or localhost. Obviously you'd use back end code to determine the base element's href attribute's value. It negates all of the nonsense of dealing with relative and static URL's.

Base element...

http://localhost/Version 2.9.A.4/

Image src value...

images/happy.gif

They are added together so if I access my work on my computer the browser will add the img and base element paths together to form...

http://localhost/Version 2.9.A.4/images/happy.gif

There aren't many bugs with this except for the occasional IE6/CSS url() based bugs however this only seems to effect external cursor files. Besides that I've encountered no troubles and can't stress how massively awesome the base element is. Trust me, I don't say good things unless I mean it.

- John

[rocknbil]

The only drawback I can think of is that it becomes more difficult if I wanted to transfer a site to a new domain name.

You don't find a "link-heavy" page is even heavier with full URL's? When you go about optimizing, it's usually 2K here, 5K there, 1K there and there . . . it's all about "little bits."

Another reason root relative is easier to maintain (which is, really, the question) is it is very easy to move a page to and from SSL in respect to images and support files, like CSS.

The scraper issue . . . ok I'll give you that, but as a coder, if I were scraping, it would take me all of five seconds to do an S & R on a full domain to /. It wouldn't slow down my theft one bit.

I avoid base href like the plague and the <font> tag, for one reason. There are plenty of tools in place to manage things, and most of the time, you go into a project with expectations of some sort of common ground, a standard of sorts. You look at a directory structure, and know the root is here, when I'm in this or that directory, you know where you are.

Oh. No it's not. Someone has changed the rules with base href.

So you adjust your rules. Now you know where you are is not really where you are, but you know where it's supposed to be.

Oh wait. Base href isn't in effect here (in this script, or that set of files, or other elements.) So we go back to the "standard" but just for this set of files.

OMG. Here's another scenario with a DIFFERENT base href. So now we have three environments and have to waste time chasing which one is in effect.

I have seen this, and taken over projects with this sort of chaos. I know their ears are burning. :-)

I have the very same problem with much of what is coded in PHP. An include in a file that includes an include included by another include, and all of them are littered with a Laurel and Hardy combination of DOCUMENT_ROOT, ../../, and other oddments - WHAT ARE YOU THINKING? :-)

Again, less is more. A wise member here once quoted: Just because you can, doesn't mean you should.

[JAB Creations]

rocknbil, when you have red tape and people who don't know what they are doing involved on a large project that did not start with the base element, then yes, of course you're going to avoid it. It's a nightmare implementing good practices in to an already existing nightmare.

However if you start a project with good practices then it won't become a nightmare. So please don't base good practices based on your experience with projects gone bad.

- John

[hutcheson]

I have been a firm believer in relative links, partly because I always want to make content as easy to republish (even to "scrape") as possible. But you've given me something to think about.

I don't see the ultimate solution yet, though. What I still want is some way to have multiple concurrent BASE tags -- and manage them all easily.

[JAB Creations]

Element, not tag.

I'm not sure off hand if multiple base elements are valid though it would make no sense.

Simply add a relative path.

images/happy.gif

themes/classic/style.css

It's really that simple.

- John

[g1smd]

A base href in your head tags usually sorts any rewrite problems.

Not the for the problems I alluded to, and which rocknbil explained in detail.

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example.com
RewriteRule (.*) http://www.example.com/$1 [R=301,L]

There are multiple problems with that code. Replace with:

RewriteEngine On
RewriteCond %{HTTP_HOST} [b]![/b]^www[b]\.[/b]example[b]\.[/b]com[b]$[/b]
RewriteRule (.*) http://www.example.com/$1 [R=301,L]

Another thing that came to my mind is that I will change my internal links pointing to my main page from href="/index.php" to just href="/" I feel it could be better for seo and if it is same then it is at least shorter. :-)

Make sure you also add this index redirect code, or something like it, before your main domain canonicalisation code:

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(([^/]+/)*)index\.(s?html?|php[45]?)\ HTTP/
RewriteRule index\.(s?html?|php[45]?)$ http://www.example.com/%1 [R=301,L]

Don't forget there is one time you absolutely do need protocol and domain name in the link. This is when a http page links to an https page and vice versa.

You also need to make sure that if any agent requests any URL from the site, but using the wrong protocol that the request is redirected to the canonical FQDN URL with the correct protocol included. This should happen site wide. It is therefore usually easier to arrange things such that the HTTPS part of a site is housed on a separate subdomain or at the very least confined to a single folder.

You therefore set up redirects such that if any HTTPS part of the site is requested as HTTP, that the request is redirected to HTTPS, and if any HTTP part of the site is requested as HTTPS, that the request is redirected to HTTP.

[rocknbil]

So please don't base good practices based on your experience with projects gone bad.

There are plenty of tools in place to manage things (clarified, without use of base href)

Just because you can, doesn't mean you should.