I load a page with JavaScript and CSS files included in it from multiple iframes embedded in my flex application, are these JavaScript and CSS files loaded multiple times in the browser for each iframe? If yes how can I avoid it or what are the best practices?
Thanks
So here's a test on JSBin: http://jsbin.com/olome5/edit
I loaded in the home page of Google 3 times, using different iframes.
As you can see from the image below, the JS resources were loaded 3 times, even though they were the exact same files -- not loaded from cache. This means that resources brought in through your iframes, at least if they're brought in simultaneously, are all loaded.
How you could avoid this scenario, I'm not sure. Instead of using iframes, you could use AJAX to load the content right into the DOM of your container page, that way, the JS / CSS would only need to be loaded into the container page and it would apply to all elements loaded within.
Of course, this is tricky for JS, because all of the content brought in would then have to have the events re-attached after they were brought in, etc. This can be made easier with something like jQuery, but still isn't a small amount of effort.
Related
My web page include a lot of img tags, but when it is initially displayed, most of the imgs are hidden. I want to load the imgs only when user shows the intention to view them, otherwise the page could generate too much network traffic.
I know I could insert the img tags into the DOM on the fly with javascript. But that way I lose the benefit of search engine indexing these images, I want the search engine bots to see these imgs.
Is there a way to keep the DOM structure unchanged, while loading the imgs only when needed?
You could try lazy loading:
Lazy Load delays loading of images in long web pages. Images outside of viewport are not loaded until user scrolls to them. This is opposite of image preloading.
demo: http://www.appelsiini.net/projects/lazyload/enabled_timeout.html
http://www.appelsiini.net/projects/lazyload
https://github.com/tuupola/jquery_lazyload
http://luis-almeida.github.io/unveil/
What you could do, is put all the images in a <noscript> tag, so browsers without JavaScript, and thus search engines, can see them.
You can then add the images in using JavaScript manually, for those who do have it.
I am using jquery ajax to load content from one page into a div on the current one, similar to the way gmail switches between inbox, trash, etc. I am using jQuery's load method
$("#divGlobal").load("newPage.html #container");
to load the content I need into my div.
newpage.html #container also has associated javascript & css files associated with it. Right now I am loading them by appending the necessary <script> and <link> tags to <head> but it does not always work. The files always load (I am watching XHR info in Firefox) but do not always seem to work correctly.
For instance, if I load page1.html & associated files (including jQuery functions for UI), everything works fine. However, if I then load page2.html and go back to page1.html, the files load but the jQuery functions are not responding.
Is there a better way of loading javascript & css files associated with the content I am loading?
Reloading the same javascript that you have previously loaded may not do what you want because all the variables and functions are already defined from the previous load and some state may already be in place from the previous load. Loading it again into the same page doesn't start from scratch which is probably what you want.
If you control the pages you're loading, then you can write the javascript in a way that will work by just having the scripts in the content load specifically designed so that they set the state exactly how you want it and clean up any previously loaded state, but you would have to write them that way in order to work that way. This would include resetting any DOM modifications, event handlers, global variables, etc... that the first invocation of the script may have modified.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How bad is it to embed JavaScript into the body of HTML?
Ok, so I've been using JavaScript for a good while now and I'm no stranger to it, but my question is in regards to where the JavaScript should actually be placed in a HTML file.
I've always been told and worked under the impression that all of your references to external script files should be contained in the head tag and any script that is contained in the current HTML file should be at the end of the file.
Now, more recently and having discussions with co-workers I have seen more and more people placing script blocks in seemingly random places throughout the HTML page, such as
<div>
<p>Foo</p>
<script type="text/javascript">
//some script
</script>
<p>Bar</p>
</div>
Now is this good practice? I've always thought that it wasn't. If so, is it beneficial because the script gets executed at that point, but then why can't you wait until the rest of the HTML has been loaded?
+1 vote for at the bottom of the page
give visitors the;
content and markup first
then display with css
then ui with javascript
appreciate this is a tad high brow
Scripts should be placed at the bottom of the page, as that will allow all of the sites resources, such as images, to download in parallel. Once finished the scripts will then be downloaded, one at a time.
The reason it's better to place scripts at the bottom of the page, is because they block parallel downloads. Normally the browser downloads resources such as images in parallel, two resources at a time (as specified by the HTTP 1.1 specification), per hostname. Scripts stop this from happening and will not allow anything else to download until after they have been fully downloaded.
Duplicate of this Question
Is it bad practice to embed JavaScript into the body of HTML?
It is helpful (and perfectly valid) sometimes when you want to ensure that certain dom is created before the script is run.
When I use inline, It has an obvious benefit, for me. for example.
(I will try to explain it with basic scenario. so don't be critical about the scenario)
I have A,B and C html sections (divs) in my page. obviously I will render them all, but I want only one section visible at a time to a visitor. so I can't wait for the whole page and javascript files to be loaded and then apply the "set visibility priority for section" javascript method to fire. because in the meanwhile all three sections (A,B and C) will remain visible until everything is not fully loaded. and the page might look awful so I prefer to use inline javascript.
Started to write a comment underneath Rob Sedge's reply, but it grew larger...
1) CSS at top, in the header (unless you want the user to see page without styling, for large HTML files / external JS, where loading times can be extensive)
2) Content and markup in the body
3) JS in the footer, before </body>
Even though currently JS evaluation is strongly suggested to occur within $(document).ready, or $(window).load events, some external scripts might not do that - in such case they will be evaluated as soon as the content has been downloaded, often causing a random behavior. Furthermore , content is evaluated as soon as browser actually processes given tag (point 1), thus additional fun stuff.
An additional (and at least for me main) point is this - let's say that you've got a templating engine, or PHP inclusion in your documents. Now - let's say that you've got a lot of such files, and in one of them JS code needs to be changed. In such cases, if you're not the only person working on a project, you'd need to search for given bit of code in all of those files. Thus - keeping JS in one place is good practice.
Let's add to that, that if you indeed keep your JS code in one place, then such content can be minified or cached, allowing for faster loading of the site overall. Why indeed you'd want the user to download your bit of JS every time the page is loaded, when that script can be evaluated from the cache. If you separate your scripts, such approach becomes hard.
Basically, the scripts that you put on the header, are downloaded synchronously, and you can be sure that they ar going to be executed in order, but if don't need those scripts to be executed before the page finishes loading, maybe you prefeer to include them at the bottom, or in a deferred way, to finish render the page more quickly, and give the users a better experience.
About the scripts contained in the HTML, it depends on what they do. For example, if for some reason you need to do a Document.write, or you want to execute some code before the page is rendered, to modify the DOM, they are very handy.
I strongly recomend you to read the two books of Steve Souders: "High Performance Web Sites" and "Even Faster Web Sites", there you have a very good explanation on the differences.
I am building a Rails app, and it seems that common practice is to have javascript_include_tags listed on top of a page.
Would it makes browers load javascript before loading the document, and thus makes visible elements take longer to load?
Thank you.
As far as I've read on the web, best practice loads javascript files at the bottom of the body tag. This lets almost everything load before executing the javascript, which generally prevents problems accessing items that may not exist if you loaded the script at the top.
A Yahoo post about web page performance suggests including them at the bottom of the page (Source) because they can block parallel downloads of other dependencies if they are at the top.
Looks like some answers were right, but none sums it all up:
How to prevent javascript loading from loading other elements? Simple, put it right before the closing </body> tag. Which usually means a few characters before the end of your HTML page.
Put all your javascript in external .js files. Why? So that the browsers can cache those files even when the HTML page changes.
Aggregate and minify all your javascript files into one. Why? Because the fewer HTTP requests your clients make, the faster the page loads.
Also, you don't have to care about $(document).ready() or window.onload, since all your HTML elements will be loaded before the javascript files (that is, if you put the JS files right before the closing </body> tag).
It's a good idea to use external JS file and to minify it's content.
http://www.quirksmode.org/js/placejs.html
Bottom of the page is also an option like John Fisher said.
If using i.e. jQuery you in any case use $() or $(document).ready(function() which makes sure the page DOM is loaded before you try to use your JS functions.
Rather than embedding the behavior in its markup, try to segregate the script
by moving it to a script block in the section of the page, outside the scope of the
document body, as follows:
<script type="text/javascript">
window.onload = function() {
document.getElementById('testButton').onclick = function() {
document.getElementById('xyz').style.color = 'red';
};
};
</script>
For performance reasons, script blocks can also be placed at the bottom
of the document body, though modern browsers make the performance
difference rather moot. The important concept is to avoid embedding behavioral
elements within the structural elements.
I've recently read the Yahoo manifesto Best Practices for Speeding Up Your Web Site. They recommend to put the JavaScript inclusion at the bottom of the HTML code when we can.
But where exactly and when?
Should we put it before closing </html> or after ? And above all, when should we still put it in the <head> section?
There are two possibilities for truly unobtrusive scripts:
including an external script file via a script tag in the head section
including an external script file via a script tag at the bottom of the body (before </body></html>)
The second one can be faster as the original Yahoo research showed some browsers try to load script files when they hit the script tag and therefore don't load the rest of the page until they have finished. However, if your script has a 'ready' portion which must execute as soon as the DOM is ready you may need to have it in the head. Another issue is layout - if your script is going to change the page layout you want it loaded as early as possible so your page does not spend a long time redrawing itself in front of your users.
If the external script site is on another domain (like external widgets) it may be worth putting it at the bottom to avoid it delaying loading of the page.
And for any performance issues do your own benchmarks - what may be true at one time when a study is done might change with your own local setup or changes in browsers.
It's never so cut and dry - Yahoo recommends putting the scripts just before the closing </body> tag, which will create the illusion that the page loads faster on an empty cache (since the scripts won't block downloading the rest of the document).
However, if you have some code you want to run on page load, it will only start executing after the entire page has loaded. If you put the scripts in the <head> tag, they would start executing before - so on a primed cache the page would actually appear to load faster.
Also, the privilege of putting scripts at the bottom of the page is not always available. If you need to include inline scripts in your views that depend on a library or some other JavaScript code being loaded before, you must load those dependencies in the <head> tag.
All in all Yahoo's recommendations are interesting but not always applicable and should be considered on a case-by-case basis.
As others have said, place it before the closing body html tags.
The other day we had numerous calls from clients complaining their sites were extremely slow. We visited them locally and found they took 20-30 seconds to load a single page. Thinking it was the servers performing badly, we logged on - but both web and sql servers were ~0% activity.
After a few minutes, we realised an external site was down, which we were linking to for Javascript tracking tags. This meant browsers were hitting the script tag in the head section of the site and waiting to download the script file.
So, for 3rd party/external scripts at least, I'd recommend putting them as the last thing on the page. Then if they were unavailable, the browser would at least load the page up until that point - and the user would be oblivious to it.
To summarize, based on the suggestions above:
For external scripts (Google analytics, 3rd party marketing trackers, etc.) place them before the </body> tag.
For scripts that affect page layout, place in head.
For scripts that rely on 'dom ready' (like jquery), consider placing before </body> unless you have an edge-case reason to place scripts in head.
If there are inline scripts with dependencies, place the required scripts in head.
If you want to tinker with the position of your scripts, YSlow is a great tool for giving you a flavour if it's going to improve or hurt performance. Putting javascript in certain document positions can really kill page load times.
http://developer.yahoo.com/yslow/
No it should not be after the </html> as that would be invalid. The best place to put scripts is right before the </body>
This is basically because most browsers stop rendering the page while they eval the script that you provide. So its OK to put non-blocking code anywhere in the page (I'm mainly thinking of things that attach functions to the onLoad event, since event binding is so fast as to effectively be free). A big killer here is at the beginning of the page putting in some ad server script, which can prevent any of the page loading before the ads have totally downloaded, making your page load times balloon
If you put it at the bottom, it loads last, hence speeding up the speed that the user can see the page. It does need to be before the final </html> though otherwise it won't be part of the DOM.
If the code is needed instantly though, then put it in the head.
It's best to put things like blog widgets at the bottom so that if they don't load, it doesn't affect the usability of the page.