is there any concern of adding javascript code at the very beginning of opening tag of body?
does it affect SEO??
Thanks for your help
No, but for reasons of speed I suggest to insert it at the end of the body.
Why don't you put it in the head section so it's all loaded up for you before the page renders? In my experience, the more code you just randomly litter in the body of the HTML page, the more likely there will be conflicts, especially if one subset of JavaScript requires another subset to load or run first.
Of course, if you must put the code in the body, the best place is right before the closing body tag. Sometimes this is necessary.
The best place to put it is at the end, as page rendering blocks when loading JS. Mind you that the Google crawler won't care but your users will
Yes, because speed is a direct and indirect (via usage metrics) important performance factor for the search engines.
It depends which script, it is recommended to put it at the end to increase load times, but if it is a "low weight" script and it is important to you you can put it on the top and check the load time , if you are still in the "green" area then it is OK. If your site will take 0.5 sec longer to load it will not crash all your SEO efforts.
Related
As per my knowledge when ever a web-page is loading, always header is loading first and then body(top to bottom approach). But it makes me confused when people ask they want to load header first and body last?
Here I'm not getting what they want actually. Is there some concept which loads some portion of page first and some portion of page last?
Please help me to understand this concept.
Thanks in advance.
First try
May be you are asking about AJAX
This technology let to
“… loads some portion of page first and some portion of page last?”
Second try
If your question is
“Is it possible to load particular portion of a web page to be load first or last to enhance the performance of a webpage?”
Put Scripts at the bottom by Yahoo
Yes, you can all scripts include at the bottom (quite before </body>). This trick let browser to render page faster (read performance improvement to end user), because browser in this case not wait to load of all scripts in your page.
Short answer: nope.
Long answer: I assume that what the people in question mean is "make sure the external resources load before the page content loads." You can do this with JavaScript, but it's not always a good idea. People usually reeeeeally hate staring at a blank page for anything more than a second or two.
I've published a website and every page has an or element with Cufon (cufon-yui.js) and sometimes while the page is loading , the visitor can see the text replacement tool doing it's job. It looks bad, some users are asking about it.
Why would that be happening if I'm using it (cufon) like anybody else and I don't' see this text rendering issue happening in most sites.
Also, there's an issue happening as well, with the Hyperlinks that are using Cufon.
Sometimes the cursor (a hand that appears for hyperlinks) disappear , it's bizarre.
Adding the following to your css should solve the issue:
.cufon-loading {
visibility: hidden;
}
use one of the google web fonts or typeface/
I've just started looking at Cufon, so I'm not sure I'm qualified to give an opinion, but I've read the IE has (or had) rendering issues and that you needed to add <script type="text/javascript">Cufon.now();</script> to the end of your body (right before the </body>. If you are running any other heavy scripts on the page, you might want to put them as low on the page as possible and place the Cufon.now() right above those scripts (place Cufon higher in priority). If that doesn't work, try hiding your Cufon elements with JS as soon as the DOM has loaded (visibility:hidden) and then unhide them when the onload event fires (though I'm not sure that's much better than the text flickering).
Use something better?: http://reisio.com/examples/webfonts/
(if you worry about distribution legality, replace your fonts with any of the numerous free clones available all over the internet)
Most of javascript and web development books/articles says that you must put CSS in the head tag and javascript at the bottom of the page.
But when I open html source of famous websites such as this one stackoverflow, I find they put some js files in the head tag.
What's Pros and Cons of both approaches and when to use which?
Found another question for the same issue:
Where should I declare JavaScript files used in my page? In <head></head> or near </body>?
From Yahoo's Best Practices for Speeding Up Your Web Site:
The problem caused by scripts is that
they block parallel downloads. The
HTTP/1.1 specification suggests that
browsers download no more than two
components in parallel per hostname.
If you serve your images from multiple
hostnames, you can get more than two
downloads to occur in parallel. While
a script is downloading, however, the
browser won't start any other
downloads, even on different
hostnames.
In some situations it's not easy to
move scripts to the bottom. If, for
example, the script uses
document.write to insert part of the
page's content, it can't be moved
lower in the page. There might also be
scoping issues. In many cases, there
are ways to workaround these
situations.
An alternative suggestion that often
comes up is to use deferred scripts.
The DEFER attribute indicates that the
script does not contain
document.write, and is a clue to
browsers that they can continue
rendering. Unfortunately, Firefox
doesn't support the DEFER attribute.
In Internet Explorer, the script may
be deferred, but not as much as
desired. If a script can be deferred,
it can also be moved to the bottom of
the page. That will make your web
pages load faster.
Therefore, in general, it is preferrable to put them at the bottom. However, it isn't always possible, and it often doesn't make that much of a difference anyway.
As other people have said, when you put javascript in the head it delays the rendering of the page until after the scripts have loaded, which means the page may take longer to load - especially if you are downloading large script files.
If you move your script tags to the end of the page, you will ensure that the browser downloads images and stylesheets before the script tags and the page will likely apear to be rendered before the scripts start to run. This also means that if you are depending on some functionality from your scripts, this will not be available until a bit after the page is visible to the user.
If you are adding styles or elements (etc. switching textfields with some form of richer editor) this will be visible to the user as flickering.
If you are adding click-events to elements, they will not be clickable until a bit after the elements themselves are visible.
Sometimes theses issues requires you to put your scripts in the head, other times you will be fine by sticking them in the bottom.
IMHO (completely against YSlow and lot's of clever people) you should keep your scripts in the head tag, and just rely on them to be cached most of the time.
In general you should place script references at the bottom of your page. Scripts not only need to be downloaded, they must also be evaluated and executed before the block is released and the page proceeds with the rendering process. Things like Modernizr should be placed in the top because it does some feature detections as well as HTML5 shims that you will probably want.
Another reason you want to try to place scripts at the bottom of the page is Single Points of Failure or SPOFs. This is where a script call times out or for some other reason blocks the page execution. This can happen a lot with third party advertising libraries, etc.
Yes you may have to think a little harder about how you architect your application, but I found it to become very natural very quickly for me. I have built hundreds of web apps over the past 4 years with the script at the bottom and I can tell the difference. I may be 500ms it might be 5000ms but it all matters.
It really depends on your website. If you are accessing and invoking the JavaScript functions inside the body then it must be referenced in the header so that is is loaded. Else if you are only going to call the JavaScript when the whole document is loaded then it is wise to put the JavaScript at the end of body. By putting .JS file at the end you load the whole page and then fetch the .JS file. This way the user will be able to quickly see the page and by the time he/she gets familiar with the page the .JS file has already been downloaded.
Any javascript in the head will be evaluated before the page is loaded, meaning the page feels like it takes longer to load. It is slightly harder to get events to work properly if all the javascript is at the end, but jQuery pretty much solves this problem for you.
I'm building a site that makes extensive use of FLIR to allow the use of non-websafe fonts. However, pageloads are an ugly process, as first the HTML text version of each field loads and then (a few hundred milliseconds later) it's replaced by its FLIR image counterpart.
Is there any way to avoid this sort of thing? I've got a client presentation in a few hours and I know it'll raise eyebrows. My situation is sort of related to this question which is in regards to sIFR, not FLIR. Any ideas?
Thanks,
Justin
Try putting the following rules into your stylesheet:
.flir-replaced{text-indent:-5000px;}
.flir-image{display:block;}
You may have to modify your other FLIR-related CSS rules to account for the fact that the generated images are now vertically aligned to the top of their respective parents.
It's been a while since I used FLIR, but I recall there was an internal caching method that would pull from cache on load instead of generate it each time.
http://docs.facelift.mawhorter.net/configuration:settings
Also, you can't have too many on the page at once. I found that between 6-10 were optimal for performance.
Are you on shared hosting? Is your css/js compressed? I found that the initial load was a little slow, but fairly quick after the images had been generated.
We are developing large ASP.NET applications with lot of dynmically created pages containing ASCX controls. We use a lot of jQuery everywhere.
I have been reading that it would make sense to move the inline JavaScript code to the bottom of the page as it could delay the loading of the page when it's included "too early".
My question is now: Does this still make sense when working with jQuery?
Most of the code is executed in the ready handler, so I would expect that is does not slow down the loading of the page.
In my case the multiple Usercontrols ASCX have all their own jQuery bits and pieces, and it would not be easy to move that all down in the rendered page.
Placing scripts late in the HTML is recommended because loading and executing scripts happens sequentially (one script at a time) and completely blocks the loading and parsing of images and CSS files meanwhile.
Large/lagged/slow-running scripts near the top of the page can cause unnecessary delay to the loading and rendering of the page content/layout.
Script's size (download time) and complexity (execution time (dom traversal, etc.)) factor in - but more importantly, the number of individual <script> HTTP requests matters far more (the fewer requests the better).
Using the "document.ready" handler lessens the delay caused by slow execution - but still leaves the problem of the sequential HTTP overhead.
Recommended reading: High Performance Web Sites by Nate Koeckley.
You could model the different ways of ordering the JavaScript in Cuzillion to see how it affects page loading.
See the examples and this blog post for examples of how ordering of page elements can affect speed.
When you include JS then the loading of the page from that point will defer because of that the JS file might contain a "document.write" statement.
This means that the entire page will STOP being rendered from the point where you include your JS files and make the browser go "white" or something (at least not display the rest of the page) so the short answer is definitely yes...!
(Longer answer is "probably" with 99% probability)
As in move the inclusion of JS (and also inline JS - which you shouldn't use BTW) to the bottom...
When that's said if you're on ASP.NET you shouldn't use jQuery but rather Ra-Ajax which BTW have all these "best practices" automagically included for you...
Most of the time, the reason to move your JavaScript to the bottom of the page is to ensure that any DOM elements the JavaScript might reference have been created before the JavaScript is run. This also ensures that the page has time to render before running any JavaScript.
In this case, I wouldn't worry about moving the JavaScript down lower on the page.