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.
Related
The question is very simple and even tho I might get downvoted into oblivion for it, I can't find a good search query for this.
If I link images, stylesheets, scripts and other things with the full website url (http://url.tld/css/style.css) instead of path (css/style.css) , are the visitors affected negatively? Is there any difference?
The html page is on the same link as the resource, so we're not talking about external resources.
This only makes a difference if you change your domain name. You cannot simply transfer the scripts over but have to change each line or the include of those files then.
One small thing to keep in mind: Your string will be longer and so your file will be a very bit bigger in size but it doesn't really matter.
Either won't affect visitors. Specifying the protocol might cause problems in the future if your users can switch between http and https. Specifying the folder also means changes when you move the site. So best to use relative
I've been playing around with Filament's Critical CSS (https://github.com/filamentgroup/grunt-criticalcss) and have a question about it's usage.
As I've been using the tool, it generates a "critical" sheet for every page I point it at so that I can inline those files into my HTML via a <style> tag in the <head>. This all makes sense.
However, once the user visits any of my sites pages, they'll have the main sheet fully cached. At this point does it make sense to stop inlining the CSS, as the user already has the CSS loaded, and instead link to it via a traditional tag?
If you're certain that the user has the stylesheet cached this would be a valid approach, assuming that parsing a cached stylesheet or inline styling of critical css will take the same amount of time.
You however can't be certain that it exists in the users cache. As the critical css also exists in the stylesheet this isn't a problem, but it will make rendering the page slower.
The only way to know when it might be useful is to parse your access logs, try to find how often the stylesheet is also requested when a specific page is requested by a specific user. Using that you can create a probabilistic model on when it's useful to inline critical css. This seems like too much work for a small gain. I'm guessing that using inline critical css is most useful for landing pages or pages that go viral.
Yes, Inline CSS usually now is only needed when you want it to take complete precedence over an external style-sheet you do not control of a .JS file that makes unwanted changes which overwrites your style-sheet as well. Doing this also helps with performance, band-width, etc., etc.
I am going to answer here as it is best to do so instead of in comments.
The problem that you're having is strange in the matter that you are wanting to cover all possible bases with two separate, but tied issues.
Firstly, your performance gains. Since you want to have higher performance doing inline styles is the technically correct answer. There are some minor gains because you are not doing a request. All requests that go out take time and depending on the time it takes for the server to communicate each request you will see a possible performance drop. This is why some requests that are much larger are considered excessive and Google generally informs you to sprite the image or some other form of connection.
The other part is you want ease of accessibility and want to be able to update quickly which is what would be provided by an actual CSS file. You would need to at some point call this CSS file so that it can be cached into the browser as you expect. You can do some cookie checks and depending if the user has been to the site or not they will have a specific call, but here is the major issue:
At some point you HAVE to actually load it. You will have to make the call. Whether it be on the first load or the last at some point for it to be cached it actually has to be retrieved. You will spend a ton of time checking each variable if they don't have it they will need to have the style sheet loaded. If you are already required to load it at some point then it comes down to never really needing to do inline styles. And if you have inline styles you never really need to load it.
You could potentially do a PHP include of the file and have it pull in that way. You would just include the file between a style declaration and it would populate the CSS that way. I wouldn't say that is the best way to do it, but it is possible. It can be done. I still stand by saying inline is not the right way to go. Technically yes it can help. Reality... no. I have not seen it be beneficial ever in my time. If someone wants to show me one that is fine, but I doubt I will use this practice unless it is last resort.
Keep in mind this final thought. Most cases inline styles are styles that are meant to be final styles; ones that end overwrite original external style sheets that we as developers can not edit ourselves (or do not want to change for other reasons).
Google is great and they provide great research, but research is meant to be considered and not always used exactly as they write. It is to provide insight. Not usually a guide into the way.
We are in the process of redesigning our company's web site, and we have been told by consultants that it is important that we either:
1.) Always link to a specific page i.e. foo.com/buy/default.aspx
or -
2.) Always link to a directory and allow the default document to load i.e. foo.com/buy/ where "default.aspx" is the default document
Is there any practical benefit to either approach? Does being 100% consistent in doing one or the other really gain us anything?
In your first example, always linking to a specific page helps prevent ambiguity in your URLs. Prefer a canonical URL (can be with or without a file extension). If you have to have multiple URLs for a single resource, for example /products/product1.aspx and products?productID=product1, then take advantage of the Canonical URL property in your code to specify which is the proper one.
Using extensionless URLs allows you to change technologies later. For example, /blog/post1.aspx is different than /blog/post1.php, say if you ever switched to WordPress (not common, of course, but it happens). It's just an easy way to make the links work no matter the technology. Plus, in my opinion it's always better to, as much as possible, mask the technology stack that you're using where possible. Extensionless URLs are becoming the norm (in my opinion) as people seem to be moving more toward an API-based approach to URIs as resources, and mixed technology stacks.
The second method you mentioned is good because it helps you make clean URLs
(don't click these urls they are just examples)
okay URL
http://www.example.com/example/example.php
clean URL
http://www.example.com/example/ (so much easier to remember, and shorter to write out)
here is a good tutorial I found that shows you how to accomplish this: http://www.desiquintans.com/cleanurls (htaccess)
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
To reduce the number requests on the server I have embedded some images (PNG & SVG) as BASE64 directly into the css. (Its automated in the build process)
like this:
background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAFWHRTb2Z0d2FyZQBBZG etc...);
Is this a good practice? Are there some reasons to avoid this? Are there some major browser that don't have data url support?
Bonus question:
Does it make sense to do this for the CSS & JS also?
Is this a good practice? Are there some reasons to avoid this?
It's a good practice usually only for very small CSS images that are going to be used together (like CSS sprites) when IE compatibility doesn't matter, and saving the request is more important than cacheability.
It has a number of notable downsides:
Doesn't work at all in IE6 and 7.
Works for resources only up to 32k in size in IE8. This is the limit that applies after base64 encoding. In other words, no longer than 32768 characters.
It saves a request, but bloats the HTML page instead! And makes images uncacheable. They get loaded every time the containing page or style sheet get loaded.
Base64 encoding bloats image sizes by 33%.
If served in a gzipped resource, data: images are almost certainly going to be a terrible strain on the server's resources! Images are traditionally very CPU intensive to compress, with very little reduction in size.
Common answers here seems to suggest this is not needed, for a set of legit reasons.
However, all of these seems to neglect modern apps behavior and build process.
It's not impossible (and actually quite easy) to design a simple process that will walk through a folder images and will generate a single CSS with all the images of this folder.
This css will be fully cached and will dramatically reduce round trips to the server, which is as correctly suggest by #MemeDeveloper one of the biggest performance hits.
Sure, It's hack. no doubt. same as sprites are a hack. In perfect world this will not be needed, until then, it's a possible practice if what you need to fix is:
Page with multiple images that are not easily "spritable".
Round trip to servers are an actual bottleneck (think mobile).
speed (to the milliseconds level) is really that important for your use case.
You don't care (as you should, if you want the web to go forward) about IE5 and IE6.
my view.
It's not a good practice. Some browsers are not supporting data URIs (e.g. IE 6 and 7) or support is limited (e.g. 32KB for IE8).
See also this Wikipedia article for complete details on the Data URI disadvantages:
Data URI scheme
Disadvantages
Data URIs are not separately cached from their containing documents (e.g. CSS or HTML files) so data is downloaded every time the containing documents are redownloaded.
Content must be re-encoded and re-embedded every time a change is made.
Internet Explorer through version 7 (approximately 15% of the market as of January 2011), lacks support.
Internet Explorer 8 limits data URIs to a maximum length of 32 KB.
Data is included as a simple stream, and many processing environments (such as web browsers) may not support using containers (such as multipart/alternative or message/rfc822) to provide greater complexity such as metadata, data compression, or content negotiation.
Base64-encoded data URIs are 1/3 larger in size than their binary equivalent. (However, this overhead is reduced to 2-3% if the HTTP server compresses the response using gzip)
Data URIs make it more difficult for security software to filter content.
I was using data-uri's for about a month, and Ive just stopped using them because they made my stylesheets absolutely enormous.
Data-uri's do work in IE6/7 (you just need to serve an mhtml file to those browsers).
The one benefit I got from using data-uri's was that my background images rendered as soon as the stylesheet was downloaded, as opposed to the gradual loading we see otherwise
It's nice that we have this technique available, but I won't be using it too much in the future. I do recommend trying it out though, just so you know for yourself
I'd more inclined to use CSS Sprites to combine the images and save on requests. I've never tried the base64 technique but it apparently doesn't work in IE6 and IE7. Also means that if any images changes then you have to redeliver the whole lost, unless you have multiple CSS files, of course.
I have no idea about general best practices but I for one would not like to see that kind of thing if I could help it. :)
Web browsers and servers have a whole load of caching stuff built in so I would have thought your best bet was to just get your server to tell the client to cache image files. Unless you are having loads of really small images on a page then I wouldn't have thought the overhead of multiple requests was that big a deal. Browsers generally will use the same connection to request lots of files so there are no new network connections being established so unless the volume of traffic through HTTP headers is significant compared to the size of the image files I wouldn't worry about multiple requests too much.
Are there reasons why you think there are too many requests going to the server at the moment?
I would suggest it for tiny images that are used very often, for example common icons of a web application.
Tiny, because the Base64 encoding increases the size
Often used, because this justifies the longer initial load time
Of course support problems with older browsers have to be kept in mind. Also it might be a good idea to use the capability of a framework to automatically inline the images a data urls such as GWT's ClientBundle or at least use CSS classes instead of adding it to the element's style directly.
More information are gathered here: http://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/