I'm working on a WordPress site that has two external javascript files load about half-way down the page. The files are badges from Reddit and Digg, and often add about 4-8 seconds to the total loading time of page — while also preventing the bottom 50% of the page from loading too.
The Digg and Reddit javascripts render an <iframe> (which I assume needs to load completely before the rest of my web page is loaded), and thus adds a big amount of extra load time.
I tried moving the <script> tags to the bottom of the page, right before </body>, but the badges render just below the footer instead of where they need to be.
How can I force these two external javascript files to load last, but still render where they need to?
You could create a div ["divA"] where you want your Digg/Reddit iframes to go [So this is basically just a placeholder]. When the page is done loading, append a "script" element to head so the Digg/Reddit scripts can load. When they're done loading, you can move them from body to divA.
document.body.removeChild(iframe);
document.body.getElementById("divA").appendChild(iframe);
Where you render the script tags shouldn't necessarily imply where the UI those scripts generate appears-- that it does seems a goofy or questionably designed. Do the scripts have known functions in them that let you hand them a container div or something in which to render their UI?
You're correct, of course, in loading them last, before </body>. That's the right strategy.
The quick answer is - no simple way. If you user defer="true" on the script tags, and they use document.write, it will still write out the content where it was when it loaded and not where the script tag was inserted.
Some of the answers in this question might help you: How can I stop an IFrame reloading when I change it's position in the DOM?
Some of the other answers in this thread suggest removing the iframe and then reinserting it. However, that will lead you straight to the problem in the above-linked question -- it will cause the content of the iframe to load twice.
The general approach will be to put a placeholder where you want them and then move them into that placeholder when they are ready.
Related
I want to speed up the load of a Dokuwiki page by button the JavaScript-tags from the header into the bottom just before the closing body. Unfortunately the relevant scripts in there are created by template method of Dokuwiki that I cannot change and that will spill out all javascripts into the header (albeit condensed into one file).
Is it possible to write a Javascript that will the included script to the bottom of the page which I could integrate into the head just before the template method of Dokuwiki is loaded? Or does the execution order of HTML/Javascript prevent that, since the scripts are not yet visible when my script loads?
It would only be possible to move these scripts in the DOM once the DOM is loaded completely. So It would not speed up the pageload at all.
But there are other ways to speed up your pageload time, like minifying resources if possible and minimizing the amount of required requests to the server.
Assume you have 75 div's that have data-id="{some number}" attribute. The overall page size is unfortunately big, very big.
There are many repetitive HTML snippets in my HTML document like image tags or links. These images/links' only changing portion is the id.
The HTML document is quite long, these snippets contribute to the overall size of the document.
I can run a javascript when dom is ready, but the user experience will be:
- wait the page loads, and start seeing nodes etc,
- page loads,
- extra snippets show.
I can make the top container DIV to hide until the page loads but
- worried that google search bot could realize the div is hidden and skip the content (or does it?)
- the users won't be able to see the content while the page is loading.
What ideal is to load the page in HTML without much extra markup for google search bot, and add extra elements while it's loading with javascript.
Any tricks that I can try that comes to your mind to accomplish this?
Thank you.
The best performance and user experience is to do as much work as possible on the server, then send efficient HTML and allow the browser to display the page as it's received. Sending say a single DIV container, then using script to clone it 70 or 80 times will be slower (probably a lot slower for some users).
Hiding content completely until your script has finished is the worst solution - users are left with a blank (or minimal content) page, waiting for something to happen.
The vast bulk of most pages is script and images, replacing HTML with scripting really is playing at the margins. e.g. this page has 90KB of HTML and 264KB of script, images and css. Apple's home page has 12KB of HTML and around 800KB of script, css and images.
Browsers show content progressively as it's received because that's how they evolved over many years on the web. Users prefer to see something rather than nothing, and to start viewing content while the rest loads (it's all about the content, not about fancy layouts or effects). Try to work with browser behaviour and features rather than against them.
You can greatly help the browser by specifying sizes for images and having an efficient layout. That way the layout won't change much as new content is received.
Depending on other page content, you could run your script on DocumentReady as opposed to onload.
DocumentReady runs after the page downloaded and the DOM rendered, but before images are retrieved.
I believe that there is an official DocumentReady event somewhere, but I still have to support IE6 on my pages, so I use a busy loop to watch the DOM.
In my WebApplication i am having many ASPX pages each contain Lot of javaScript at the Beginning of page.
This Increases the Loading time of the page (40 sec min).
I know javascript # beginning of page will block page rendering and the loading time will be increased.
How can i move Javascript to bottom of page without loss of actual functionality in order to reduce page loading time.
ClientScriptManager.RegisterClientScriptBlock (and I think ClientScriptManager.RegisterClientScriptInclude) will render the script block towards the top of the form element, whereas ClientScriptManager.RegisterStartUpScript will render them towards the bottom of the form element.
The problem with RegisterStartUpScript is that it does not output scripts in the order they were added, which is very frustrating. You can try a few things:
Make sure your script names are alphabetically ordered in the order you want them rendered (stupid, I know).
Try implementing your own ClientScriptManager that doesn't act so foolishly.
Avoid ClientScriptManager altogether, emitting scripts into literal blocks exactly where you want the scripts to appear.
Bundle your client scripts and just include the bundle.
The problem with #3 and #4 is that controls may check with the ClientScriptManager to see if a dependency has been added, and if not, it may add it, resulting in the script being included twice.
JavaScript files should be cached. This is the first step to reduce the loading time. Moving JS files at the bottom will help but not that much if is your only action. Also you have to examine the possibility for using the defer attribute for your JS files, meaning that scripts are executed when the page has finished parsing.
I've read that it is better to place your <script> tags at the end of the document. The argument for doing this appears to be that the browser will stall rendering the page below a script tag until it has loaded and and executed the script. If your script tag is at the top of the page, rendering is stalled for a while, which is bad.
However, I am not sure if this is really true any more.
Looking around, I normally see the following locations...
In the <head> of the page or Just inside the <body> tag
Stackoverflow is an example of a site that puts the script tags in the head, and since they are normally rather obsessed with performance, I am starting to wonder if position in the page is important at all.
Last thing in the body element
The other common place to put javascript appears to be right at the very end of the <body> element. I am assuming this means that the page can render while the javascript downloads and gets on with doing its thing.
But which is better?
Does anyone have any thoughts or advice on this? I am looking to try and get our pages to perform and appear to the user as quickly as possible.
Does it matter? What are the advantages of being at the top of the page? Bottom of the page?
It really depends.
There is no catch all answer for this because it depends on what your javascripts are acting on.
Putting scripts at the end of the page is sometimes needed if your acting on a DOM element that needs to be loaded for the script to run. Say you want to focus on a control and your script is:
var mytext = document.getElementById("mytext2");
mytext.focus();
Well in this case you would want it to execute at the end of the page, after mytext2 control has already been loaded by the browser. This is less important for script blocks that only contain functions that are called by events.
If you have a big .js file that contains libraries of functions you may also want to put that at the end of the page so the browser will load the page faster before loading the large .js file.
Google analytics suggests putting their tracker at the end, to make sure the page has been delivered before you count the hits, but in some cases it suggests putting the script into the header too, it works both ways.
So, rule of thumb for me is, HEAD scripts for everything except things that execute in-line and act on DOM objects, or large scripts that you want to load after the page.
Rick Strahl just wrote a great blog on placement of Javascript in .net too:
The only validating way is to include it on the top (in the <head> section), but in the bottom will be faster to load - the rest of the page will load faster if you have script near the bottom, giving the user better response and making the experience better.
The problem is that most web browser stop rendering the HTML of the page until they've fetched and parsed all JavaScript code so far. So if you have a slow-loaded .js file included in the <head>, no HTML will be rendered and images will not even start to download before the .js have been downloaded and parsed, therefore frontend engineers propagate for putting the scripts as far down in the code as possible.
I usually just set a far-future Expires header for my .js files so they are cached in the browser for a long time and then include them in the <head> section. This gives good performance and doesn't look ugly :-)
But if you are serving external .js libraries (that are on other servers than your own), you will probably want them in the bottom because you can't change the Expires-header for other servers and you canät know that the other server always will be responsive.
yeah. Put Scripts at the Bottom
I think the size of the js file is much more important than the location of javascript. I always set highter number of the con-current connection to make sure they download in parallel.
I believe it's better to place script tags just before the closing body tag. Because:
Elements are blocked from rendering if they are below the script.
In IE6, IE7 resources in the page are blocked from downloading if they are below the script.
From this article. Also Yahoo's performance rule 6 is Move Scripts to the Bottom
Google Analytics always used to say to put the script tag at the bottom of the page. I believe the rationale was that if the Google servers ever went down, the page would fail to load if it were in the head (only for IE probably).
I was just using the plugin "Yslow" for Mozilla Firefox, and it told me that I should put JavaScript at the bottom. I have heard this before but haven't really thought about it too much. Is there really an advantage in putting JavaScript at the bottom of a web page compared to the top?
It'll allow the web page to load visibly before executing JavaScript, which makes sense for things like Google Analytics, which don't need to happen before the page loads.
You may also want to look into things like jQuery, prototype, etc and attach to the "ready" handler, which executes JavaScript code after the DOM has been fully loaded, which is an appropriate place for much JavaScript code.
Assuming you aren't running on a CDN or aren't serving your JS from a separate sub-domain or server, it will load synchronously and force your HTML content to wait until it has downloaded the files. By placing the JS at the bottom of your page before the closing </body> tag, you are allowing the HTML to be parsed prior to loading the javascript. This gives the effect of faster page load times.
If you have static html content and a lot of javascript, it can make a difference in perceived page load time since the html will load first giving the user something to look at. If you don't have much javascript, or the existing page content relies on the javascript to be useful, then this is not as useful practically-speaking.
I want to bring update to this topic, google has recently introduced async snipped http://support.google.com/analytics/bin/answer.py?hl=en&answer=1008080&rd=1 which can be added for your site to bring e.g. google statistics support. It should be placed bottom of the <head> section for best performance. The point is that this increases likely hood of tracking beacon to be sent before user leaves the page.
Also it should be located there if you want to verify your site in google webmaster tools using your google analytics.
Other than that, same rules still applies basically - javascript at bottom for "fast" loading of the page. I used quotes because I dont count page fully loaded until javascript finishes ;-)
Yes, the page will load the content and render it before loading and executing javascript, and the page will, as a result, load faster.
TOP
When you put your JavaScript at the top of the page, the browser will start loading your JS files before the markup, images and text. And since browsers load JavaScript synchronously, nothing else will load while the JavaScript is loading. So there will be a timeframe of a few seconds where the user will see a blank page, while the JavaScript is loading.
BOTTOM
On the other hand, if you place your JavaScript at the bottom of the page, the user will see the page loading first, and after that the JavaScript will load in the background. So if, for example, your CSS & HTML takes 5 seconds to load, and your JavaScript takes another 5 seconds, putting our JavaScript on the top of the page will give the user a “perceived” loading time of 10 seconds, and putting it on the bottom will give a “perceived” loading time of 5 seconds.
Taken from Demian Labs.
It allows all the DOM elements to fully load before loading the Javascript which addresses them. This standard is also part of Visual Studio.
Placing scripts at the bottom of the element improves the display speed, because script compilation slows down the display.
Yes including the javascript at the bottom of the page really quickens the loading of the page. Since browser executes things synchronously it impacts the page loading if it is placed at the top of the page. If it is placed at the bottom of the page, the page would have loaded the entire markup by then when the browser starts loading the javascript giving a better experience to the user.
It's advisable to put all inline scripts at the end to improve performance, you don't want your users to be staring at a blank white screen while the script renders. You can use defer attribute eg. to prevent link scripts from delaying your html rendering.