Since I started making my own web applications, rather than managing other peoples, I have fallen into the habit of making each reference url start from / .
This was becuase I wanted a convention, and I would find I was testing/deploying apps that used relative and absolute(/ not including http://....) urls in the app.
What convention should I be using for web applications, and will I run into problems with either approach (Aside from not being able to run apps in different folders with the absolute one)
Is there a benefit I get from using absolute? Or would relative always work just as well, and give me an added benefit of portability?
No benefit from absolute versus relative as long as the reference gets properly resolved. As for portability, this is one of those "it depends" situations.
For external page it is obviously that you can use only absolute paths. But for internal links I would suggest to use relative paths, as you'll gain from portability of the site.
Related
I have been given the task to embed a bunch of small websites into a larger website on our main domain.
The problem is that the small websites previously each had their own domain and were programmed with absolute paths. They will stop working if they are simply copied into subdirectories next to the main website.
Additional constraints:
The absolute paths can not be replaced automatically, since some of them are generated with JavaScript. A few parts of the unminified source code have been lost, so it would be extremely painful to fix.
The chances are good that this stuff will never be touched again. It has been decided that it should not be fixed in a proper way since "that would be waste of time".
It should be easy to add additional small websites.
I came up with the idea to create a subdomain for each website, but that violates constraint 3, because it would involve bothering the people responsible for DNS whenever a new website is added.
Is there a simpler solution?
I would be tempted to write a one-off program that I can point at a directory, and all it does is open the javascript files that have the absolute paths, and replace them with a relative path. A little bit of complexity in writing the program, but then super simple after that.
As for the simplicity in adding new sites, it depends a little on how these sites are hosted. If they're all retaining their own hosts, bugging the DNS people might be necessary no matter what. If they are being moved to the host server to live in the same directory structure as the main website, you can just put them in subdirectories so it looks a little like...
http://maindomain.com/
http://maindomain.com/subsite1/
http://maindomain.com/foobar/
http://maindomain.com/imspecial/
http://maindomain.com/shopping/
Adding a new site would then just be a matter of sticking another directory in there with it's own site code.
In my website the menu is loaded from a file called "menu.php".
But my website has some sub-directories - /blog/ , /searchtool/, /shop/
They are with the same design, using the same CSS file.
But the urls for the images and for the links are like this:
<a href="my-page.html" >
<img src="images/my-image.jpg" >Image description</a>
If I add my website full URL before them - it works
<a href="http://example.com/my-page.html" >
<img src="http://example.com/images/my-image.jpg" />Image description</a>
My question is how does this affect my website performance?
Is it good or bad?
What problems can it cause?
Is there anything I should know before doing it?
How about using "../" before the addresses, will it work?
It depends.
The performance gain from using relative URLs is absolutely negligible compared to using absolute URLs. Of course, it is recommended to use relative URLs where you can, for example, the content residing on your own server within folders, which you can link easily.
The browsers are efficient enough to resolve relative URLs and as I said, it gives you no major performance increase as such. To answer your question, it is generally a common practice to use relative linking if you are referring to resources on your servers.
One could argue that using absolute URLs could cause a subtle decrease in load time as there will be a touch more DNS lookups, but don't worry, its so minimal it won't even matter. But always, use relative resource referencing where you can, its just less fussier.
Reasons for using Relative URLs
Easier to debug issues on localhost
Migrating to a different server like from Bluehost to Hostgator
Easier to work with shorter paths for development reasons
Helpful in developing on multiple environment
Reasons for using Absolute URLs
From a SEO standpoint,its better.Offers canonicalization
For search engines, doesn't matter really. They resolve relative well enough too.
All sorts of SEO problems on the web are caused by the use of relative URLs in links, canonicals and more.
An absolute URL contains more information than a relative URL does. Relative URLs are more convenient because they are shorter and often more portable. However, you can use them only to reference links on the same server as the page that contains them
Relative URLs are often used because developers have a test environment on another hostname and it makes it easy for them to move stuff between their test environment and their live environment. Other reasons include that it’s “just easier in website maintenance”. They’re also, in my opinion falsely, promoted by some websites about site speed because they’re “shorter” and thus “faster”.
have a good read here relative-urls-issues
Is there any reason to prefer
<a href="alpha/beta.html">
over
<a href="http://mysite.com/dir/alpha/beta.html">
(assuming that the links refer to the same location)? And similarly for references to scripts and style sheets.
I worry that the former might be slightly slower because the browser might reuse a connection in the former case but open a new connection in the latter.
Or are browsers smart enough to handle this in the optimal way?
Yes, there is a major reason : portability. When something changes, you feel better if it is not hard-written in one thousand places.
Additionnally, the relative form — the first one — is much shorter. So, when you have dozens of internal links in your page, using the relative links saves many bytes. Here is for the performance. This gives shorter transfer times, so it saves energy and it is good for the planet Earth.
Regarding the reuse of connections, the relative or absolute form of the links do not matter. Web browsers don't work that way. Anyway, Web browsers are very good at using relative links and directing them to the good server.
Relative links are definitely the way to go.
HTTP is a state less protocol, therefore everytime a user clicks on a link which links to a new HTML page a HTTP request is sent to the server, so using the full URL is not slower or faster than a relative URL.
No, there isn't any difference in performance in terms of requesting the page to load because they will both resolve to the exact same address, though the page size will be slightly larger with absolute paths by virtue of the src attributes being longer but that is obviously, not worth mentioning unless you have a page with thousands of links on of course.
Relative paths (your first example) are in most cases preferred over absolute as if the domain needs to change, you wont have to go through your entire site updating the image/file paths.
If I'm not moving my site around, any good reason for why I should use absolute URL's over relative?
Absolute URL's will work no matter if you move the content from folder to folder, however each language will have a way to reference a BASE URL in one way or another.
For example if you have "test/1.html" as a URL on index.html it will redirect to /test/1.html however if you copy that link to /dom/index.html it will redirect to /dom/test/1.html
It would be best practice to use the base URL and then the relative URL e.g. {BASE URL}/test/1.html
I tend to prefer using relative because if you ever make any changes to the site relative urls tend to be much more adaptable.
If you are talking about efficiency, there is no real difference between the two.
If I'm not moving my site around [...]
This will come up one day. Even if you're just moving your site from one folder to another, you want the links to be relative. You may not think that will ever happen, but it's better to be safe than sorry.
[This question is somewhat related to this question, but the answers are not...]
I have always used relative paths in HTML and scripting languages (PHP/ASP/JSP) to refer to EVERYTHING. I think the justification had to do with 'what if the website gets hosted in some weird subdirectory.' But my coworker has started throwing absolute paths into a PHP site we're working on. At first I was appalled, but then I thought, "why not? We'll never be hosted in a subdirectory." Nowadays, getting hosted in the root is not an uncommon necessity. Is it still necessary to "code" (markup, really) with relative paths? I think it's probably an antiquated practice by now.
Definitely. You never know where your code is going to end up, or for what purpose.
Suppose you build a new version of a site, but to help your users transition, you move the old version to a "/classic" subdirectory. The same often happens the other way around where sites will host a beta version of the new redesign in a "/new" directory.
Building it properly the first time shouldn't be a hassle, and you'll thank yourself for it one day.
Well, it's probably not the end of the world but it's building in a dependency that you don't need.
If for example you ever want to put a number of versions in subdirectories in a test harness, or subdirectories help to work around some other issue (such as combining this with some other app that insists on being in the root), you may find it harder.
Sure, you can probably always work around it in some other way - but the problem is you now have to.
Edit: Killed my opening paragraph as it was based on a miss-interpretation of the referenced article.
I always use an absolute path for the following reasons:
Includes:
1. When you use a templating system, you never know the directory structure that a document is going to have when it's calling the include.
2. If documents are going to be moved around, you can be pretty sure it's going to be the documents themselves rather than the includes. If it is the includes, then they're being moved my someone who knows what going on. Added to this, if it is someone not familiar with absolute/relative path, they'll understand absolute a lot better than relative.
css: (as well as the items above)
1. When editing with Web Developer, relative backgrounds disappear when your style sheet isn't in the same directory as the doc.
2. By spec, when you put something on the 'Net, it should be there for the duration. When I'm building something new, I build it in a new folder, or with a new file name and leave all the old docs alone.
If you're using dynamically-generated pages, dynamically generate your URLs. For example, with JSTL use <c:url>. Not only does this allow you to move your pages in the future, it also ensures that your URLs will be properly escaped (tell the truth: how often do you build query strings with &? if you want the W3C validator to accept them, you need to).
For my personal website, which uses PHP to build pages, I've created several methods: insertPageRef(), insertCodeRef(), and so on, that create valid HREFs. As a result, I don't hesitate to re-arrange my site structure as it evolves.
The case of being moved to a subdirectory is fairly unusual, I'd say. Far more usual is being hosted on different servers: you create your site for testing on "dev.yourcompany.com" then go live by moving it to "www.yourcompany.com". In that case, you need to use relative links for obvious reasons.