I'm making an ASP.NET web forms web app. I've just started with the client side scripts. I'm planning to put quite a lot of JavaScript code in a file that will be loaded on each page. I want to know some general guidelines about when to start worrying about the size of the file, in consideration of the users and their page loading times.
The users will mostly be using Internet Explorer 7 and 8, but I suppose the script still will be cached after the first visit? If not, is there any way to make IE cache the file?
They'll be cached, like you suppose, after the first visit, so you don't need to worry unless it actually becomes an issue.
Related
Is it possible to force caching of certain Javascript Library files (ie react.min.js, etc.) when navigating between pages of a website that isn't a SPA?
Trying to look at the feasibility of a more componentized structure while not going full on SPA. The website I'm working on oftentimes has people visit a single page and then leave, but in cases where they do stick around, I don't want to have to have them reload each and every library on page load.
Background You Should Understand
There are literally thousands of articles on the web about this topic but here is a very good summary from Make Us Of's Everything You Need to Know About the Browser Cache.
The browser cache is a temporary storage location on your computer for files downloaded by your browser to display websites. Files that are cached locally include any documents that make up a website, such as html files, CSS style sheets, JavaScript scripts, as well as graphic images and other multimedia content.
When you revisit a website, the browser checks which content was updated in the meantime and only downloads updated files or what is not already stored in the cache. This reduces bandwidth usage on both the user and server side and allows the page to load faster. Hence, the cache is especially useful when you have a slow or limited Internet connection.
TL;DR
I don't know if your really looking for a way to force the browser to cache your files or if you just misunderstood how the cache works. In general the browser the visitor is using is the one that makes that decision and handles everything for you. If it sees that a resource is needed that was already accessed in the past it wont request it again, it'll just use its cache. So no, your libraries will not get re-loaded over and over. Just once.
Now if you really do need to force the browser to cache your files take a look at the answer(s) to Caching a jquery ajax response in JavaScript/browser. That should get you on a good path to a solution.
I was wondering if there's any way to attach a js lib to an external webpage after the page has loaded?
To provide a simple example, could I load www.google.com into IE and somehow display the webpage with a green scroll bar?
I would like this process to happen automatically on each page load instead of having to manually execute this process on each page load.
I am assuming that you are talking from a web developer's point of view.
I don't think it is possible without any hacks.
This would also be a huge security risk, because loading javascript code on an external website means that the code can potentially do anything on behalf of the user. It can capture keystrokes, take screenshots, note down passwords and do a lot of illegal stuff.
So instead of this, you can create a browser extension (add-on) which will have to be installed by user's permission (and his knowledge), and can run any code on any page (if the user allows it)
We have a client with thousands of users (who all use Internet Explorer) and a large amount of javascript files that enhance their user experience with our product.
The problem I'm having is that any time we update one of these scripts there is no way to know whether the client is seeing the latest version. What we're having to do is tell our client to do a hard refresh (ctrl+f5) before viewing any changes. Obviously this approach is not ideal.
I know that browsers cache based on the url, so one could use something like
<script src='myScript.js?ver=1.2'>
to get around the issue, but this is not an option for us.
I was hoping that there's some kind of header property or something similar that we could use to tell IE not to cache these scripts.
Any ideas?
You can also version the filename itself like jQuery does:
<script src='myScript-v1-2.js'>
Then, each time you revise the script, you bump the version number and modify the pages that include it to point to the name of the new script. This is foolproof vs. caching, yet still allows your viewers to receive the maximum benefit of caching and requires no server configuration changes for the .js file.
A full solution will typically include setting a relatively short cache lifetime for your host web page and then allow the various resources (stylesheet files, JS files, images, etc...) to have longer cache lifetimes for maximum caching. Anything that is fingerprinted can have a very long cache lifetime. See the reference that fabianhjr posted about for ways to set the cache lifetime of the host web page. It can be done in the web page itself (<meta> settings) or in the http headers via the server.
If you turn off caching for your script file (which would likely have to be done at the web server level for a script file) then all your viewers will lose the performance benefit of caching and you will lose the bandwidth and load-saving benefit of caching. If you use a common .JS file across many pages (a common design pattern), your viewers will see slower performance on every page.
Everything you need to know about cache http://www.mnot.net/cache_docs/
http://www.mnot.net/cache_docs/#CACHE-CONTROL <-- HTTP Headers
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.
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.