I have a web page I run locally on a WebKit mobile browser (not on a web server) which has around 27 MB of JavaScript files, YES 27 MB of JavaScript files. It is because I have custom JSON objects and arrays hard-coded inside my .js file.
I have split the complete JS contain into 27 small .js files of around 1 MB.
The problem is that when I includes these .js files inside my header, the page load time increases very much.
I'd like to know how can I reduce the page load time in such a case where the js files are required.
1) Is there a way wherein we can inject the .js files inside the HTML after the page loads for the first time? (because the JavaScript content comes into picture only after a link is clicked on the page)
2) What would be an optimium solution to includes such a large JavaScript content inside a web page? I have minified my all js files to reduce the file size as much as possible!
Thanks in advance.
UPDATE 1:
The page runs locally and no WEB SERVER is involved. Finally, it would run inside a mobile browser, and so that's how all the problem arised i.e. the load timing is very high in mobile browser, so want to reduce the initial load time.
(Note: Most of the below was written before you'd bothered to tell us you were running an HTML file locally in a mobile browser without using a web server. Much of it still applies, some of it doesn't, but I've left it for others actually doing web pages.)
1) Is there a way wherein we can inject the .js files inside the HTML after the page loads for the first time?
Yes, it's actually really easy (live example: run / edit):
var script = document.createElement('script');
script.src = "path/to/the/file.js";
document.body.appendChild(script);
Note that the script will load asynchronously (you can't just assume it's loaded after the appendChild call).
But if your goal is just to have the page showing while the 27MB file downloads, you can just put your script tag at the end of your page, just before the closing </body> tag. Update: If you're running a local HTML file, not a web page, I'd think this is all you'd need: A single script tag at the end of the page loading your 27MB .js file.
2) What would be an optimium solution to includes such a large JavaScript content inside a web page?
Ideally, reduce the size if at all possible. If you can demand-load assets as you need them (either using the technique above or ajax), do that instead. Update: If you're running a local file, not a web page, you basically can't do ajax reliably. But you can demand-load what you need, when you need it, via adding script elements as per the above.
Regarding your 27 1MB .js files: If you hardcode the script tags for them, it's much better to do one 27MB file than 27 1MB files. Minimizing HTTP requests to your server (ideally at most one .js file and one .css file) is one of the key ways to improve page load time. In your case, though, you've said various parts aren't needed until various things are clicked, so you'll probably end up with a main file (which will hopefully be a lot smaller than 27MB), and then a bunch of other things you demand load (as per the above) as necessary.
Other things you can do:
Minify, compress, or "compile" your .js files (this means you'll have separate "source" and "production" files, since typically this is a one-way process that removes comments and such)
Ensure that your server is serving .js files with gzip compression (for instance, with Apache you'd use mod_deflate); you can test that it's working with various tools
Also very much worth a read: Best Practices for Speeding Up your Website, which makes the points above and a whole bunch more.
At 27MB it's always going to be slow as you're going to run into the memory limits on the device.
Most mobiles don't have a lot of RAM and once you load and parse the JSON it's going to be using more the 27MB
Minification will help you but gzip won't as the browser still has to decompress it)
If you're just rendering HTML in response to user actions, why don't you create HTML fragments instead of JSON and fetch these and insert them into the DOM when someone clicks on the link?
You have to combine again that *.js files into one. That will reduce the server requests that cost in time !
Compress your JavaScript content with that tool : http://www.refresh-sf.com/yui/ or that http://closure-compiler.appspot.com/home
Also you have to put that files at the page footer, in order to allow the page to be rendered while you download the js files into the client browser.
Another thing that can help is the long time caching of the file. This will allow your JavaScript to be "saved" into client web browser cache and next time is not important to re-downloaded.
Finally I am not 100% sure is that help but try lazy JavaScript loading.
Edit for Lazy Laod
<script type="text/javascript">
(
function()
{
var sc = document.createElement('script');
sc.type = 'text/javascript';
sc.async = true;
sc.src = 'http://www.url-to-your-javascript.file/my-javascript.js';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(sc,s);
}
)();
</script>
Another helpful source
http://gtmetrix.com/dashboard.html
Tests your web site speed. This will help you find your way on speed optimization about your web site :)
I would load the data after page load with ajax. That is after you loaded the page, you make an asyncronous request for the 27MB of data. This allows you also to eventually add a load animation while the data is transferred. You can have a look at jquery to implement this.
As a best practice, you should always load javascript in bottom oh html file. Put css at top, and js at bottom will greatly help.
27MB is too large. Why are you using hard code in js. you can use ajax. Take help from an expert, may be he can minimize your js
I finally solved over this problem of mine by creating a native application for the mobile device rather than using the hybrid (HTML5) technology i.e. I moved the 27 MB JS files which were containing the actual app data to an sqlite file and used it directly in my Android app.
Related
This is a best practice type of question. I am developing a complete AJAX application. The user navigates to the main page of the application and everything from there on out is loaded via AJAX into the content section of the main page. Is it better to take all the javascript files I have and merge them into one file that is loaded on the main page or to split them up into just what is needed for each page that is loaded?
Putting it all in one file obviously has the benefit that only one HTTP request is made to load the javascript needed for the site and any request for a page there after will only need to fetch the HTML. But, this requires that every event that is wired up (using jQuery) be attached to the document using the live or on function. So everything will look like:
$(document).on('click', '#SomeButton', function () { });
Doing it this way will cause there to be many hundreds and possibly over a thousand events being tied to a single element, the document.
Putting them in separate files requires multiple HTTP requests to be made to load the various pages of the site but limits the number of events that are attached to the document.
Any thoughts on what is best here?
I would vote for separate js files for each page for bigger projects specially if your project is using any js library like jQuery and its plugins like grid plugin etc. In case you have a big single javascript file your first page will load slowly obviously giving your user a bad first impression. What we do is that we create separate js files for each page specially when there are ajax calls to load data for the pages. Plus there are separate files for each pluggable component like custome drop down or date counter etc. This way its easy to manage the code and customize it later.
Before deploying the app we can merge related files and create single file for a single page. For example if a page called editProfile.php uses a data picker, a jquery validation plugin and custom js to load user data, we can combine them in a single file so that only file will be loaded for a single page.
So I would vote for separate files for each page and applying optimizations before deploying.
Honnestly i'm not really an expert in this domain but this is my piece of advice on this subject on a production environment.
I would use CDNs for libraries (like jquery). They offer maximum cacheability, and there is a very big chance it is already cached in your client's browsers from visiting other websites. This saves some requests already.
Group and minify your common javascript code, like plugins, utilities, things used throughout your site. It will be requested once for all and will then be available.
Have a separate, minified, script file for each "page" you load dynamically that you will load along with your content.
Loading script for content pages:
Using the .load() method from jquery to load fragments of pages will unfortunately remove any <script> tag present in the fragment. As noted in the jquery load() method, this is to avoid "Permission denied" in IE.
What you can do is to have a <script id="contentScript"></script> tag in your base page and load the script along with the content by replacing the src.
I don't know if it is a good practice but it makes sense to me :-)
I am reading this How to make HTML rendering fast it says that scripts in the HEAD tag can be cached.
Can JavaScript in the BODY tag be cached? If not, why does YUI recommend putting scripts in the body tag?
JavaScript will be cached (and reused between pages) if it is in an external file and the cache control headers say it should be cached.
It may be cached if it is embedded in the page itself (i.e. between <script> and </script> instead of at the end of src="..."), but only if the entire page is cached and it will not be reusable between pages.
It makes no difference, to caching, if the <script src="..."></script> is in the head or body.
The code will be cached if you cache the entire HTML page, not otherwise. HTML pages are usually dynamic these days (generated by scripts and CGIs) and therefore not possible to cache without sacrificing functionality. Therefore you usually want to place JS code in external files which then can be cached by setting HTTP cache headers for the JS file.
The answer, for the most part, is that you cannot cache JavaScript which is inlined into the HTML code (in the HEAD section or otherwise). To make it cacheable you need to put it in an external file, but then the browser will need to do an extra HTTP request to get the JavaScript the first time.
Mate, I think you might have misunderstood what Rich said.
He said put the JavaScript into an external file and link it from the head.
This is in contrast to placing the JavaScript into a script tag in the body of the page.
It would be reasonable to put JavaScript into a script tag in the page body if it is used only on that page. In fact, if its used only one that page, it would not be an optimisation to place it into an external file. The additional GET request for the JS file will be almost simultaneous on Firefox, Opera, Safari but not on IE6. The reason is that IE6 has only a few (2) threads to use for fetching files, whereas Firefox has up to 16. That is why having a separate file for page-specific code would be a step backwards because it might actually slow down the page load.
If however, you have a common JavaScript file that you want to use on many pages then you should definitely place it in an external file and link it from the head, because it will be cached the first time any of those pages are loaded, and it will not need to be fetched again when any of the other pages use it. The bigger the file, the bigger the advantage to caching it.
I think that was the point he was making. Does that help?
Would a page load faster if I keep all my JavaScript in a separate file say MyCode.js and include that file rather than have the JavaScript included in the html file?
Or does it not really matter?
It very rarely matters for speed purposes unless you're Google. However, for readability and maintainability, it's much better to keep your JavaScript in external files.
If you put your <script> tags at the end of the page (just before the closing <body> tag) the JavaScript won't block loading of the page.
There are benefits for both inline and included script files.
Inline scripts get loaded with the HTML therefore only one HTTP request is required to download both this saves time, the resulting HTML file will be bigger but you do not waste time with the handshake and headers.
Included scripts get loaded as a separate HTTP request and therefore there is this overhead, however, included scripts get cached by the browser which means subsequent pages do not need to request this resource from the server again.
As a rule, include inline scripts wherever those scripts directly relate to the content of the page that is being requested, you will save HTTP requests for the page and you do not need to cache the scripts separately. For site wide scripts, always include these as separate script files, these will get downloaded once the first time they are needed and then a cached copy will be used for subsequent pages.
If you've got plenty of scripts, there might be some to be saved by keeping js in external files as it allows the browser to do a better job of caching your script files. Same goes for CSS.
But generally, meh. The obvious advantage of externalising is maintainability.
Depending on JS code size. If You have huge JS code part then putting everything separately has few pluses:
You can split different file types among different domain names which can increase page load time - while most of browsers limit to 4 concurrent connections to the same domain.
It is easier to maintain
I have product website. On one page I show thumbnails and a brief description of all the products. When you click on the photos, you get to a detailed product page.
Is there a way to get the browser to start loading and caching the javascript and CSS for the "detailed product" page while the user is just looking at the "all the products" page and trying to make a choice?
I want this preloading and caching to start only once the page has fully loaded as to not slow it down.
Any suggestions on how to implement this?
If you're using a JavaScript framework (like jQuery, protype, etc) then you can use a simple method to do an AJAX call. If not you'll have to write one which might be a bit confusing for someone that isn't familiar with JavaScript. A basic example is here.
You can use JavaScript to add script tags to your html page and it will include JS. Remember that if the JS is set to auto execute any code it will happen. For CSS, your only option is probably using JavaScript to send a request to grab the file (see above). You could include the CSS but it will override any styles from your original CSS file.
Websites that precache:
Websites including sites as big as Google and Yahoo use preaching to help performance. Google for instances loads a CSS sprite http://www.google.com/images/nav_logo7.png on their main page along with other CSS and JS files that are not completely used on the main page alone. Most people already do something similar to this by just combining their CSS and JS files into one file in production. HTTP requests take more time than downloading the actual content. An example of Yahoo preaching is here
Yahoo talks about this on YSlow's help here.
Taken from one part of the guidelines here:
80% of the end-user response time is spent on the front-end. Most of this time is tied up in downloading all the components in the page: images, stylesheets, scripts, Flash, etc. Reducing the number of components in turn reduces the number of HTTP requests required to render the page. This is the key to faster pages.
Organization in development, speed in production:
What I usually try to do is in development I will split up my JS files if needed (hardly ever my CSS though). When its time to push this data to production servers, I run a compiler (simple script that combines all the files, and minifies them) and then put them online.
Minifying/compressing:
Remember HTTP requests are evil. A compressed JavaScript file and a compressed CSS file are so small, that I'm almost 100% sure there is an image on your main page that is smaller than it. Therefor it's pointless to worry about splitting them up per page. It's actually more of a performance hog to split them up across multiple pages.
CSS Sprites
The point in CSS sprites is a website probably has 40+ images on their page using CSS. Well thats 40+ HTTP requests on a users page load, thats A LOT of requests. Not only is that bad for the user, but thats also a lot of requests your web server is having to handle. If you aren't using a static content server and are just using Apache that is on your main host, you're poor Apache server is getting loaded with requests it could be serving for your web application. You can reduce this by combing your images into one file, or at least into fewer files. Using CSS's background-position property, you can do wonders.
I highly recommend reading the YSlow guidelines by Yahoo here: http://developer.yahoo.com/yslow/help/#guidelines
Theoretically you can start accessing resources from subsequent pages so that they are later available in the cache.
However, this is not good practice - especially if you are loading resources for all detail pages they may select. In doing so, you make the assumption that you should determine how the user's bandwidth is used, not them. If they are browsing multiple things at the same time, or doing other things with their bandwidth besides viewing your website, you are using their bandwidth in a manner they do not intend.
If their connection is slow enough that the load time for your detail pages needs to be optimized, chances are their connection is slow enough that they will feel the loss if they are doing other things at the same time.
use setTimeout in the load event of the page, and set a timeout of a few seconds, after that, insert a script tag and a css tag into page (those ones from the next page)
something like this: (where url is the url of the thing you want to cache)
//cache a script
var scriptTag = document.createElement("script");
scriptTag.setAttribute("type", "text/javascript");
scriptTag.setAttribute("src", url);
document.getElementsByTagName("head")[0].appendChild(scriptTag);
//cache an image:
var img = new Image(); img.src = url;
//cache a css
var css= document.createElement("style");
css.setAttribute("type", "text/css");
css.setAttribute("src", url);
document.getElementsByTagName("head")[0].appendChild(css);
on all the "speed up your website" sites and books they always tell us to minimize HTTP requests at all costs. This is fine and nice but what if that means that on every page you have to reload 120kb again and again and again because the user cache is empty?
If i use 5 js files on every page of my website, wouldnt it be better to put them in one file and load this file on every page instead of putting them together with all other variable files in one big file and save one HTTP request. From which point or filesize on is it ok "cache" a file and have another HTTP request?
I give you an example of 3 pages when i use only one HTTP request for one minifed JS file per page:
jquery, jquery ui, thickbox, lavalamp menu => together minified in one file = 300kb
jquery, jquery ui, cycle plugin => together minified in one file => 200kb
jquery, jquery ui, galleria plugin => together minified in one file => 250kb
And now the other possibility with always 2 HTTP requests: One File consisting of jquery and jquery ui => 150kb, lets call it "jui.js" for now
jui.js, thickbox, lavalamp = again 300kb in the beginning, BUT now jui.js is cached for the other 2 pages
(jui.js is cached now so not loaded), only cycle plugin => only 50kb to load but one more HTTP request as i load jui.js and the cycle plugin seperately.
(jui.js is already cached), only load galleria plugin => only 100kb more to load but again 2 HTTP requests where one request is already cached
So at which point or Kb size is it ok to have another HTTP request on a normal "responsive" web server?
Does anybody have any best practices or is it just "Minimize HTTP requests at all costs!"?
(I hope i made myself clear :) And i will vote up people as soon as i have some points!)
EDIT:
It is basicly a simpler question:
How long does a extra HTTP roundtrip for a cached js file need? If the http request is slower than the time i would need to download the extra non cached parts on every page, then i would put everything in 1 big file on every page(1 different big file on every page).
If the HTTP request for a cached js file is nearly nothing, then i would split the parts that every page needs in an extra js file(minifed of course) and include the dynamic parts of every page in differend(again minified) js files.
So if on most pages i need a 100kb extra(the dynamic part), how do i test the time for a cached HTTP request? Are there any numbers, did anybody test something like this already?
Thanks for the great answers already!
This is big complex subject. They write whole books on this subject ;)
For resources (javascript, css etc) it is sometimes better to download them individually. The browser will download them in parallel. if page a needs resources x y z but page b only needs x and z, separating them out is a good thing. Other times a resource that is needed on every page might be better downloaded all at once. It depends.
But with javascript, the browser downloads the JS first before it renders the page (if the script tag is in the head section) so you would see better performance if you add a defer attribute, or include at the bottom of the page, and trigger your javascript with a body=onload.
Remember too you can set caching headers on resources so the browser will cache them in memory or disk. This makes a huge difference in many cases.
There are really no hard and fast rules, just some guidelines. Your best bet is to test! what works better over dialup doesn't work as well over broadband.
Fiddler is a nice program that will show you your loading times if you are on a modem for instance.
in short, there is no rule of thumb here. Depending on your webserver settings you may want to try optimizing by merging files to one larger file... I know apache could be configured to use same connection to stream several files. Best thing to do is use a benchmarking tool such as apache AB to simply test your changes.
As for jquery stuff though, you may include your scripts from a publicly located domain such as google to 1) avoid connections 2) many people have them cached in browser already.
ie: http://code.google.com/p/jqueryjs/
You'll really have to do your own analysis based on your own traffic. Initial load times matter too, so if users are landing on a page with a single JS, you may want to split that out. However, if users end up clicking around on your site a bit, the net benefit to loading it all at once is obvious.
That said, my users land on "content" which needs more scripts, and so I usually lean towards minimizing what I can on the assumption that users will click around.
I'll leave the argument about linking to google's copy of your scripts to a link to a previous discussion:
Should I link to Google API's cloud for JS libraries?
I think how you handle this situation heavily depends on the type of traffic your site gets. If it is a site where people are only hitting a few (less than 3) pages and leaving then you can split up files more liberally with the assumption that you are giving users only the minimum for what they need. However, if your site gets users who are viewing a lot of pages then just bundle most of it up and ship it over once.
Also, take a look at where the javascript is being used before putting it into the javascript package. If it is only used a page or two that aren't frequently visited then you can make it a separate file.
In practice, since you are gzipping your scripts when they are sent out (your doing that right?) then its often faster to just include scripts since you avoid the extra round-trip-time. Like Byron mentioned, downloading javascript blocks everything else from being loaded (unless its done asynchronously) so you want to do your best to minimize that time.
Start playing around with the Net tab in Firebug to see how performance is affected.