I am in the process of creating an online portfolio and I am using the Isotope jquery to present images on my site. The problem I'm having is that when you go to my site the content loads and sits for a second before self-organizing using the Isotope jquery.
I have 2 linked CSS files (one local and one on a separate hosted site), the latest Jquery (hosted on Jquery's site), and then the Isotope script (hosted locally). Is this amount of referencing files the cause of the slow self-organizing with the Isotope script? If I hosted all of these locally would it run faster?
Because you are waiting until the whole page is loaded before setting up Isotope, the browser has to wait not just for the code to download, but also for all the elements to download, the images, the video player javascript and so on. So only when everything is ready is isotope moving stuff around: leading to the delay you see.
That may be necessary, if the size of all the content is only available after it has been loaded.
To improve performance.
Put explicit sizes on any content to be loaded (like images, video).
Move the jquery, isotope and isotope initialization script tags to the end of your HTML body.
Don't wrap the init in a document load handler.
Then what will happen is the HTML page will load first, then as all the images and other stuff are loading, the browser will load each of the script tags in order, when it has loaded isotope, it will call your init script which will arrange everything right then. Isotope will cope because everything it needs to know the size of has its size set, and as the browser continues to receive the resources it is loading, they'll appear in the correct location.
There are some good reasons for doing things in an onLoad handler, but often putting your scripts at the bottom of the page is just as good, unless your script needs any data coming in from other external files (like CSS, or images).
Related
is it possible to load web page in background using javascript/jquery? I mean load DOM, run all scripts, load all dependencies (CSS, external JS libraries). I don't want to load HTML and replace it. It's easy to do but will cause all styles/scripts to be loaded after replacement, not before (as far as I know).
The reason is that page loading time is 10-20s and I don't want page to freeze during loading content. There is single JS script which takes 2-4s to initialize. The idea is to show some placeholder page like "page is loading, please wait" and load everything in background.
I know page should be rebuilt so it doesn't take so much time to load but it's not possible in page owner's budget.
EDIT: I thought about loading page in iframe and then move iframe's content to the main body. Would it work? Wouldn't I loose some JS/Jquery data, pointers to DOM elements etc.? Wouldn't it cause to reload all JS?
I was watching this video, and found some elements of it going over my head.
He says that scripts are 'serialized' and also block subsequent files from being loaded. If this is the case then Script 1 would finish loading and then Script 2 would begin loading and then the CSS files would load.
I do not see how loading the CSS files before would inhibit this behaviour. Since the script files should have a set waiting time even if they are loaded one after the other, swapping around the order should not change this behaviour?
Thanks in advance.
Blocking the CSS file won't block the page load, but it will cause the page to be re-rendered; possibly causing a noticeable flicker. This is because each time the browser encounters another block of CSS it needs to re-render the DOM, in case the new styles change anything.
This is all about user experience / perceptual load speed:
Put CSS as high as possible (pref in <head>) to negate the chance of the DOM being re-rendered
Keep JS scripts as low as possible (pref just before </body>) because it ensures the DOM is loaded into the browser (and therefore visible to the user) before any potentially blocking external scripts are loaded
Browsers are now better about allowing things to "load" in parallel, but scripts will be executed in the order they appear on the page. The video's advice applies best to older browsers. The best thing you can do is move script tags to just before the closing of the body tag so that the page will be rendered before needing to execute all of your javascript. Here is the Google Best Practices recommendation about this: https://developers.google.com/apps-script/guides/html/best-practices#load_javascript_last
Also note that it is potentially a great performance benefit if you load scripts from a CDN. For example, if you include your own copy of jQuery, every person that visits your site the first time must download it. If you link to jQuery from its CDN, your users have likely already downloaded that same file while visiting another site, and that same file will be used when they visit your site, thus no reason to download it again from you. Also, if you're loading a lot of scripts at once from your server, the download of some of them could be delayed, so loading from other sources opens that up as well.
Regarding the video (outdated):
He's saying that the css files will begin downloading if they come before the script tags. If your script tags are already loading, the css files won't begin loading until the scripts are done.
To exaggerate the issue, imagine that if one script begins to load, we won't allow anything else to start loading at all. On the other hand, if a css file starts to load, the next script can begin to load immediately after the css file starts to load. This way, they are both loading at the same time. However, if a script begins to load, the css file CANNOT begin to load until the script is fully loaded.
Its generally good practice to load your JS files at the bottom of your page as you then give HTTP request priority to other elements on the page such as styles (CSS), images and text etc. These will be shown visually to the user first instead of waiting for scripts to load in the background.
I've seen a few tutorials on how to create a JavaScript preloader for images. Is it possible to use a JavaScript preloader for other JavaScript?
My website uses mootools (and others too) for animations and a copious amount of pictures, etc -- therefore it takes awhile to load. Is it possible for the website to have a "loading" centered in the page -- and nothing more -- until all the Javascript libraries load, all the images load, etc. The website has around 300k of JavaScript (compressed), 800k of images on the front page.
In pure flash design, it's possible to have the flash movie simply say loading before any of the associated libraries, other code, images, download and appear. Can this be done in JavaScript?
Execute all your code on window.onload()
Here's a ridiculously simple example to give you the basic idea: http://jsfiddle.net/kennis/jHJ3T/1/
Think of the hideous red div as your preloader. Once the document loads all the resources (images, js files, whatever), the preloader disappears and your content is now visible and your javascript libraries have been fully loaded and are ready to execute.
If you want run the jsfiddle example more than once, change the "random" values at the end of the image tags so your browser doesn't pull cached versions.
I have a web application that uses quite a bit of JavaScript.
When the page loads, it's very clear visually that something is blocking the rendering of a particular portion of the web site. This portion is generated by a Tabber Tabify JavaScript library.
How can I determine what's blocking the HTML rendering specifically so that I can modify my code to prevent this blocking?
Can I use Firebug, or some other tool, to walk through my HTML/JavaScript to determine where the HTML rendering is being blocked and if so, how?
UPDATE:
YSlow gives my web-application a score of "A" and Page Speed give a score of 94/100.
UPDATE 2:
The live site is linked below.
http://www.elite.com
What I'm specifically referring too is the actual Tabs themselves being rendering (and NOT the panel content inside the tab panes). It seems strange to me that the Tab headings themselves are taking so long to generate on the first (empty cache) page load.
A few possibilities:
Loading scripts in your page will block rendering (the only fix for this is to put them in the head (blocks initial rendering) or at the end just before the </body> or load them after the page is loaded (e.g. onload)
Whatever the Tabber/Tabify tool is, needs time to process content... see if there is a way to optimize it.
Either way, if you post some code we can likely be of more help
Update:
If I load the page with my cache cleared, I see content rendering on the screen, then hiding (as it becomes hidden tab content)
Changing the non-visible content to display:none; when loading, and then only setting it back to display:block; once the Tabify stuff is done might help (a) speed up the rendering and (b) remove any flash of content that later gets hidden.
The RadComboBox'es you have load inline (which means the scripts block rendering)... if you can delay this until the onload event fires it will speed up rendering.
I would move the Unica Page Tag (tracking) to the end of your page too.
You have 8 external script files - if there is any way you can combine them it would be good.
You don't have gzip turned on for most of those script files
All of your static content (images, css, scripts) don't have an expires header which means they won't get cached, which means pages won't load fast after the first page.
I have seen JavaScript libraries being loaded at the top and bottom of the page.
I would love to know when to make these choices. All the JavaScript code I've written all work at the top of the page, which includes jquery plugins.
When do i load my script at any of these positions?
Top: When having JavaScript events function on elements immediately is more important (so if you use a DOM Ready event to load everything, this is the wrong place)
Bottom: When loading the content is more important
Yahoo says to Put Scripts at the Bottom. Google says something similar but not as clearly.
The reason you do it at the bottom of the page is because if you put it at the top of your page then the rendering of your page will wait for these files before it renders. This is why a lot of people put JavaScript at the bottom of the page as it allows the entire page to be rendered then the JavaScript is loaded.
There's very rarely any reason you'd want to put the JavaScript at the top of the page, and unless you have an explicit reason you want the JavaScript loaded in before the main page then put it at the bottom. Most optimization guides suggest putting it at the bottom for this reason.
I place all CSS in the HEAD to avoid excessive screen paintings and flashes of style.
I place most JavaScript file requests at the bottom of the page so that the page can render quickly (HTML/CSS loading will block until script tags above them have been loaded and processed). Any code that needs to be executed after the library files have loaded are executed onDOMReady, which is all code except for library initialization. I pretty much followed Google's PageSpeed recommendations.
I've been thinking about using LABjs as well to further decrease page load times, but this works well enough right now.
When the browser encounters a script element it has to evalute the JavaScript contained in that element because the script might alter the content of the page (via document.write) or inspect the current state of the page.
If the script element loads script using the src attribute, loading of other resources (JavaScript, CSS, images, etc.) will be blocked until the current script is loaded.
Both of these factors can slow down the perceived load time of your page.
If your JavaScript does not alter the page or if it doesn't need to inspect the state of the page until it has loaded you can mark your script element with defer="defer" (supported by IE 6+ and Firefox 3.5+) which indicates that the evaluation of the script can happen "later". Moving your script elements to the bottom of the page effectively does the same thing - since your scripts appear at the end of the document they'll be evaluated after CSS, images, etc. are loaded and the HTML is rendered.
Because of the fact that browsers have to pause displaying content of a page when it's parsing a Javascript file, the recommendation is to load the Javascript at the bottom of the page to speed up displaying a page's content. This works best if your website can be rendered without any Javascript executing to modify the page because the page will be available for user interaction even if a script hangs for longer than expected.
I put all external scripts (such as Google analytics) at the bottom so their lag does not effect the loading of the DOM.
Simply put, if your script have snippets that would start executing right away (outside all function(){} bodies) and that access DOM elements, it should go at the end of the page so that DOM would have been built and be ready to be accessed by the time the script starts executing.
If you are accessing DOM only from function calls (like onload, onclick etc), you can put the script safely in the head section itself.
I put a small script in the head that does anything I want done before the rest of the page renders, and loads any other required scripts onload, or as needed after the document loads.