I was wondering which one is better approach, Having multiple small sized files to be requested by multiple HTTP requests OR Having a big file to be requested at once
Plz provide pros & cons of both approaches too, as I get contradictory search results on net.
One of the tips on Yahoo page is Minimize the HTTP Requests
http://developer.yahoo.com/performance/rules.html#num_http
The main reason is that we have one extra overhead in each request. As yahoo says:
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.
On every ASP.Net call we also have session lock of the entire page request. What this mean is that all requests for all users will have to wait for each other because the session is locking the rest of the page until the current page is finish.
Even if that sounds bad, it is of great help for start and small sites because it helps a lot with the synchronization of all data, not only with the session.
So with multiple calls you have a sequence of getting data, and not paralleled getting of data.
reference: jQuery Ajax calls to web service seem to be synchronous
Replacing ASP.Net's session entirely
On each request you also have cookies that travels from browser to server. So if your cookie is near 500 bytes and you make 100 calls you have an extra 50KB of data to move. This can be solved using a cookie-free domain, but if you do not have this option then the next thing is to try to reduce the calls.
reference : http://developer.yahoo.com/performance/rules.html#cookie_free
If you have many images to be downloaded and shown on the browser, against one file image that contains sprites, or other images, the browser can reduce the rendering time because the browser is re-rendering each part of every image that comes. But if the images come in one sprite file, then the browser take only one action to render them - so it's faster for the browser to have fewer files.
The same thing goes here. Once you combine all your javascript in one or two files then the browser can get it and parse them in a single time. If you have them as many files then the browser needs to parse them one by one. Additionally, if you gzip compress the javascript files it will be much better than having many smaller files.
For me you can use ajax to request for more data when this data can come with a user interaction. This can be informations that request extra database call and calculations that you can avoid on the first request, and maybe the user never actually asks for them.
You can split the requests that way, to get extra data only when the user requests for it, if you do it this way you will reduce database calls.
For example on Amazon's page the carousel control loads extra items only when you ask for more items in the carousel, or show the user history only when you go down the page.
I don't know the whole situation, don't know how you define "big file", but off the top of my head:
One Big File
Several Smaller Files
As always when someone asks an open-ended question with no context, "it depends."
If you are sending a huge lump of data one time across the network, splitting it into smaller chunks just adds overhead. Compression generally works better against larger data, the overhead of each request is not insignificant, and there are benefits to creating and maintaining a single stream of data to the server.
However, since you've tagged this ASP.NET, it's reasonable to assume that you're talking about typical webpage data. That data is often separated into individual files, typically by usage: stylesheets, scripts, page content, images, etc.
There are convenience reasons for this: as a developer, it's easier to work with files that only have one type of content. Technically you could embed all your image files as binary data within the markup of an HTML file, but that makes it pretty difficult to edit the image!
Performance-wise, smaller files does marginally slow the initial transmission, but it is the speed of subsequent transmissions that will typically benefit. Most client browsers will cache individual files and will not download those files repeatedly. By breaking content into smaller files and reusing those files across multiple pages, we reduce the number of times that a particular slice of data will be downloaded across mutliple requests. In that way you can improve the performance of your site as a whole by separating reusable content into smaller files.
