How to speed up my websites (backoffices)

Question

Hello im developing some backends in ASP.NET 2.0 and i have put all the images in Cache, GZIPED my CSS, JS files and everything to speedup the load of each options.

the performance its good and i have no problems with the clients but i want "MORE" fast loads and im looking for some recomendations.

Is important to mention that those websites are using only in intranets so im thinking to implement my next projects using IFRAME for content that way (i think) the options will be loading faster because they not have to load the entire site.

any help / recomendations?

thanks in advance.

====

EDIT:

im not using viewstates i wrote HTML (code behing) generated controls and use as less as possible ASP.NET Rich controls, all my static contents are in Static vars (Header, Menu, Footer) but im just looking for speed up a litter more.

After compile my website i compress all the HTML, CSS, JS and use less of those files as possible.

but i was seeying others Backend that loads faster than my and the difference is the IFrame control that they use (i think), we check code, design, etc and we use the same (they use #INCLUDES for static HTML instead STATIC VARS with the HTML)

Answer 1

I'd recommend you dont frame your content in an IFRAME - you will most likely run into problems with things like styling, back/forward button functionality and compatability.

If you do want to try speed things up here are some tips:
- Combine and minify your css and js files
- Look into minimizing full page loads by using ajax to load content
- Make sure your images are a suitable size for the web

Answer 2

Do NOT use IFRAMEs. Just don't.

Since you're writing for the Intranet, I guess that the size of your resources is not such a big deal (still, keep them as small as you can). What leaves you with the server processing time as your bottle neck.

My recommendations:

1. I highly recommend you deep dive into output cache and use it wisely. It can do wonders! Caching stuff with the Cache object is good too, but output caching a page saves you most of the page load life cycle and therefore saves you precious time.
2. Compress the responses (look here for a starter).
3. Reduce the VIEWSTATE size as much as possible and if it's still big, move it to the server (if possible).

Answer 3

I agree do not use frames.

Also I like to ask you - what is the delay for loading the page in ms ? - latency and download. If you latency is more than 500ms then your code need impovments and not the load/cache.

On intranet my latency is 80-300ms on usually pages, 600-800-1000ms when make many calculations.

Maybe the delay is somewhere else on the code and not on how fast they load.

I check the latency using the google chrome and the chrome developer tools. (there are similar tool on firefox)

For the cache

read this article, I like to point on Expires, and on post-check.

http://stackoverflow.com/questions/2426103/asking-browsers-to-cache-as-aggressively-as-possible

For Intranet

I think that if you compress gZip your pages on an intranet - assume is very very fast, then you lost the time for compress and decompress, because the time that takes the page to go from one computer to the other is less than few ms - I believe that the compress/decompress time is more. Need some tests - with again the developer tools and the download time on google ghrome.

The minified maybe is not that bad, and to keep all the css, and js in one file each.

ps. Every lost second on the wait of the computer is a lost second from our life.

Answer 4

Don't overlook CSS Sprites also, as this can eliminate your zillion little icons and such.

Answer 5

Generally speaking, over an intranet, loading images/js/css etc will not be your bottleneck. That means that using iframes will not help you.

You need to find where the actual bottlenecks are before you start to plug them, but I would suggest that the first place to look would be calls to the database. In particular, number of calls per page (definitely make sure you're not making multiple calls for the same data per page!) size of data returned (for example, if you're returning 10,000 records and then only displaying the first 100 to the user).

Once you get the easy stuff out of the way you really do need to start profiling to find out where the bottlenecks are. Use the Trace.axd tool in ASP.NET to find out which parts of your page are taking the longest and concentrate your effort on those.