For my webpage http://www.example.com/homepage.html which is the best way to link static resources, such as CSS files?
http://www.example.com/css/base.css
http://example.com/css/base.css
/css/base.css
Neither is better.
One will survive moving the linking document to a different location. The other will survive moving the entire tree to a different location.
In most cases, the latter is more useful (as it lets the links work between environments (development, staging, test, production)) but your needs may vary.
Relative path is best way to use.
Ex : http://www.example.com - Absolute path
Relative path
var style="css/base.css";
var style1="css/base1.css";
Then, Absolute path+style;
or absolute path+style1 . We can able to change relative path without hard coding.
For internally-served resources, typically you would use a relative URL, for the reasons stated by Quentin (upvoted accordingly).
However, absolute URL's are useful in some important scenarios that you should be aware of, for example:
When you use a CDN (content delivery network) to serve your static files (such as the CSS files you mention in your question) more quickly. These are served from other servers than yours, so you have to fully specify the location.
When you need to change the protocol. The most common case is switching to https, e.g., for actions like signins and purchases.
If you are putting links into an email, where of course relative paths won't go anywhere. This isn't relevant for loading a CSS file, since styles are inlined in HTML emails, but still it's a case to consider, e.g., for images.
Related
I'm developing a website which will live on https://www.example.com/. While developing, and later as a test site, it's at http://127.0.0.1/temp-dir-for-my-project/.
This means that I currently have a bunch of hrefs in the HTML, as well as CSS files, starting with /temp-dir-for-my-project/, which obviously break once I'm done and upload it to the live site. Over there, it should be / instead.
Sadly, the BASE element, which I thought would solve this, only applies to relative paths. For example, ./meow.html with /temp-dir-for-my-project/ as the BASE would refer to /temp-dir-for-my-project/meow.html, but /meow.html in the same situation would be... /meow.html, because it's an "absolute" path.
Before you say "just use relative paths, then!", well... If I do that, I have to keep track of in which "dir" I am. For example, for the webpage at https://www.example.com/test.html, I could do: ./other.html and it would work both on the live site and in my test site (assuming the BASE is set). But the webpage at https://www.example.com/subdir/test.html would have to link to './../other.html' or else it wouldn't link to the correct page.
This gets messy. I wish I could use "absolute" paths and still have the BASE be the... base. Is there a way, or am I forced to use ./../../blabla... for any page located in subdirs (whether those be real subdirs or just how the URL is rewritten to look)?
I am developing a website on a web server which can be accessed by 2 URL: mywebsite.example.com or example.com/mywebsite. For example, when I access mywebsite.example.com/images/abc.jpg and example.com/mywebsite/images/abc.jpg, I get the same picture.
The problem is, I have many links inside my website, and I am not sure should I use an absolute or relative path.
From another question
Absolute vs relative URLs
I found someone suggesting using URL relative to root (like /images/abc.jpg), however when I access the website using example.com/mywebsite, every link just break.
For relative paths, I found it hard to manage since webpages are in different folders, but using the same template which contains some links. It means I have to manually set some links as ../ and some as ./.
I have also tried using <base> tag however it messes up with anchor. Even if I try to include the full path before the # symbol, some jQuery libraries does not function properly since they get the value inside the attribute href directly, but not extracting the part after #.
Would there be any better practice or suggestion?
I think you should use relative urls, and concentrate your searchs on how to use relative urls in templates, that would be resolved relatively to the final page.
I don't know the technology you are using for templating, but I see two common solutions :
declare a "relative path" variable in the template, and then override it in the different pages, with the new relative path. Use this relative path as a prefix for all urls
delegate urls construction to a service that would know the final page. Somethinkg like resolveUrl(..)
This is a newbie question, I know, but I couldn't find clear answer.
My web root looks like this:
/index.html
/img
I set up subdomain img.my-domain.com, it points to /img folder
Now, in my index.html I call image located in subdomain i.e. folder img
I can do it using relative and absolute path, both are working:
src="/img/image.jpg"
src="http://img.my-domain.com/image.jpg"
My question is: is there any difference? In the context of parallel downloads concept, is the image gonna be perceived by browser as coming from subdomain in both cases?
I have a lot of images and want to serve them from 2 subdomains. However I develop locally and when the website will go online, I would have to change image links from relative to absolute in case absolute path is required.
Thanks
src="/img/image.jpg"
Will send cookies for www.my-domain.com. Won't appear as a separate domain.
src="http://img.my-domain.com/image.jpg"
Will have separate cookies. Many websites do this to improve performance.
You should real use the relative protocol so if you need SSL, you won't get warnings. src="//img.my-domain.com/image.jpg"
no there isn't but the relative path is the common way.
A coworker just asked me if there were any reason why referring to images with a relative path would impede site speed.
While for cleanliness it's a good idea to have the fewer characters of a relative path, but wondering if there are other slowdowns/consequences to using absolute/full paths? I'm thinking there may be a DNS lookup involved by having the full path.
What are the other consequences, if any?
Using absolute paths forces the web server to establish a connection, send and receive the HTTP requests. If using relative, the connection is already established, so it doesn't have to go through that logic (hence increasing page load speed). You probably won't see an amazing difference, but every bit saved is a good thing, right?
Edit: After doing a quick test, the difference is extremely negligible, and doesn't seem to produce that great of a case for my answer. I created a test page with the same image twice, one with relative and one with absolute path: http://damonbauer.me/test/index.html.
Test One: Image w/ Absolute path in HTML code first: (click for larger version)
http://damonbauer.me/test/images/results1.jpg
The absolute path image took 869ms to load, while the relative path image, listed second in the HTML code, loaded in 635ms.
Test Two: Image w/ Relative path in HTML code first: (click for larger version)
http://damonbauer.me/test/images/results1.jpg
The absolute path image took 303ms to load, while the relative path image, listed first in the HTML code, loaded in 315ms.
My opinion? It's faster to load using relative. Even when listed after the absolute path image, it took only 12ms longer for the relative image to load. When the absolute path image was loaded second, it took it 234ms longer to load. In both cases, they are close, and it looks to me like it matters more about what loads first. Either way, I would go with relative, if only for portability's sake.
nah, there isn't any noticeable difference, and both have their uses. There is no DNS lookup client-side, it's the browser (or maybe the web server?) that changes the url to what it should be.
Use them as what you need to, relative paths are more portable (no need to do anything to make them work in your development or live server), while absolute paths take you to specific location (regardless in what server you are).
In my case, I use relative paths unless I want a specific address to be used. Also, when you're switching from non-secure to secure, you'd want to specify https so full path (or do an extra redirect somewhere else)
A remote absolute path will go thru DNS but it frees up your web server to serve pages while another server gets the work of serving images. That lightens the network load on the page server and speeds things up.
A local absolute path will be the same as local relative in that after the first page it, it will be cached by the web server and it's not going to matter after that.
I am examining some code for a friend, and have found that the developer who built his site began each and every relative src, href, and include with a forward slash /.
For example:
src="/assets/js/jquery.js"
I have never seen this before. So my question is, why would a developer place a forward slash / at the start of a relative path?
It's done in order to root the path (making it an absolute path).
It ensures that the path is not relative but read from the root of the site.
This allows one to move a file around and not have to change the links to the different resources.
Using your example:
src="/assets/js/jquery.js"
If the referencing file is in /pages/admin/main.html (for example) using relative paths you would use:
src="../../assets/js/jquery.js"
Suppose you move the file to a child directory. No changes would be needed for with the original rooted path, but the relative one would need to change to:
src="../../../assets/js/jquery.js"
Adding on #Oded's answer, the slash makes the URL absolute.
For example:
/foo/bar/baz.css
This translates to:
http://www.example.com/foo/bar/baz.css
But without the slash, things become a bit different:
foo/bar/baz.css
This tells the browser to look in the current folder (not the root folder) for the directory foo and then the subsequent directories and the file.
Also, take for instance this HTML:
<script type="text/javascript" src="foo.js"></script>
If you move the HTML file into another folder, then the script will not load, as foo.js isn't being moved with the HTML file.
But if you use an absolute URL:
<script type="text/javascript" src="/foo.js"></script>
Then the JS file is loaded EXACTLY from http://www.example.com/foo.js no matter where the HTML file is.
This is to ensure the asset comes from the "root" of the web server.
e.g.
Host is www.example.com
URL becomes www.example.com/assets/js/jquery.js
I do this with project I want to ensure live on their own virtual host.
The issue really comes down to where those assets are being included. For example if the asset is being included from /help/pages/faq then the developer can be sure the path will work correctly when the site is hosted on a non changing host, e.g. example.com.
The issue of using relative paths, 'assets/js/jquery.js' is that if the assets are included from the /help/pages/faqs then the path becomes relative to that starting point, e.g. /help/pages/faqs/assets/js/jquery.js
Hope that helps
This is a bit off topic, but if there is any chance that your application will ever be served behind a reverse proxy (eg. using apache2 or nginx) under a sub-path, you should try to avoid absolute paths.
For example, if you reference "/style.css" on https://example.com/, and you tried to hide it behind a reverse proxy at https://proxy.example.com/example/, your absolute reference would break. The browser would make the request to "https://proxy.example.com/style.css" when it should have requested "https://proxy.example.com/example/style.css".
Unintentional absolute paths from a leading forward slash are a nightmare for reverse proxies to deal with.