Fast ASPX Pages with CSS Class - External JavaScript - Small Viewstate

[Meleagant]

All,

I am in the midst of trying to speed up an Asp Net site. I've read a couple of articles on how to squeeze as much speed out of pages as possible. Of the articles I've read 3 things kept on reoccurring: Control the ViewState, use CSS instead of <asp:Control ForeColor="Red" BackBolor="Blue" etc.. and if you have a lot of inline JavaScript move it to an external file.

I have done all of these and have noticed no real improvement. In fact I've slowed things down quite a bit. On the main user work page, sort of like a Case Management Page:
- Before I started the ViewState was over 150,000 charecters long. Now it is a tenth of that.
- I've moved my javascript to an external file and even ran a "minimizer" against it and now the js file is 47K as opposed to 75K.
- I've moved lost of my asp:GridView row styling to CSS classes.

The average file size sent to the client is now 210K down from 374K, BUT THE PAGE IS BLOODY WELL SLOWER! Why would pumping a smaller file across the network be slower? Does anyone have any idea's/suggestions?

Thanks,
-- Joe --

* Sine scientia ars nihil est
* Respondeat superior

 

[Meleagant]

I have been to the IG forums, a lot, and I have seen several users post regarding the speed of the controls. I had done some simple tests with the asp:GridView vs. the igtbl:UltraGridView. Although the IG grid was rich in features, it couldn't handle large data sets. So I started replacing the IG grids with native asp Grids. The only IG controls I have left is the Tab itself, a couple of buttons and some input boxes on a form for the CSR to fill in.

But here's the thing, my development code and my production code is identical (slow IG scripts and all) except for:
-- I use CSS styling for most of my controls now instead of using skins or setting their values declaratively.
-- I moved my 75K worth of inline JavaScript to a "minimized" 47K external file.
-- I've reduced the view state from over 150,000+ characters down to 17,000+ characters.

So the net result is the browser is trying to load 210K file instead of a 374K file. If we have a slow network (I assure you that we DO), wouldn't be faster for the slow network to download a smaller file. This is what started me down this path in the first place. I know our network is slow, so the less information I pump over it the better.

I'll hop on over to the IG forums to see what I can dig up there. It is possible to have too many external files right? May be my two extra external files, (1 CSS & 1 JavaScript) are two too many for the browser to effectively handle due to the demands of the IG external js files?

Thanks you all for all of your help & suggestions

* Sine scientia ars nihil est
* Respondeat superior

 

[DotNetBlocks]

Try HTTP Compresion, I have personaly seen it dramaticly increase the speed of sites.

Directions:

http://www.microsoft.com/technet/pr...289-94d3-4085-bc4e-24eb4f312e0e.mspx?mfr=true

PipeBoost offers a free tool to check and see if your compression is working properly.

http://www.pipeboost.com/

 

[SiriusBlackOp]

1 extra second in the FormLoad is about all. Maybe it’s a fluke, but it may be worth reviewing later... 1 sec is small fries here.

jmeckley headed in the same direction I would have taken you next with the file download, but I'm not certain you tested this right. Move that file to the web-server and point the remote site browser at the file. Time the download from the web-server to the remote site. Test this soon. I have a feeling that this is a major part of the problem.

What kind of connection does the remote site have? The problem may be the site’s connection… if they expect to work with large amounts of data over the internet then they have to have a good ISP. No way around that.

You need to get this site down under the magic 7-second mark for users to be even remotely happy with it… and on a LAN, 5.2 seconds is a long time. I know you are using some form of paging, but you may have to use custom paging if you are working with large numbers of rows. Standard paging pulls all rows of a query every single time, where as you can setup custom paging to only pull a subset of the entire query from the db… which saves time in getting, moving and binding the data to the grid. Custom paging is more work, but sometimes it is needed.


Senior Software Developer

http://www.scoutsft.com

 

[jmeckley]

It is possible to have too many external files right? May be my two extra external files, (1 CSS & 1 JavaScript) are two too many for the browser to effectively handle due to the demands of the IG external js files?

i doubt IG loads so many scipts that 2 more put a browser over the edge. Instead I think the js is poorly structured causing the long load time. note: I have no experience with IG controls.

i assume you're using asp.net 2.0. If so try exchaning the IG tab control for an asp.net wizard or multi-view. for now don't worry about postbacks. what is the preformance gain/loss?

you may also want to consider the MS Ajax library and control toolkit. there is a tab-control extender you could use to reduce postbacks.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[Meleagant]

SirusBlackOps:
Just to make sure I did this right, I took the View Source of my aspx page and saved to an HTML file. Then copied that file to Server18 (my dev server). In the address bar of IE I typed in \\Server18\D\Dev\FitTabs.html. This took 42 seconds to load. I tested this from a PC Anywhere connection into our satilite office.

When I test from my PC, the file loaded in 2.18 seconds.

The remote office I believe has a bonded T1 connection through Verizon. In fact we just upgraded it to the 2.whatever speed from the 1.whatever.

So what does this tell me, that the network is dreadfully slow? Is there anything I can do?

JMeckley:
Yes we are using Asp.Net 2.0. I have a lot of javascript built around that tab and the tab has ajax functionality already built in. I'm sure at some point that I will replace the IG tab for a multi-view control, I've just never used one and I don't know how difficult it would be to replace one for the other.


* Sine scientia ars nihil est
* Respondeat superior

 

[jmeckley]

one thing to note aboute a multiview: views are mutually exclusive and don't interact with each other. only the active view is initialized and loaded the other views are not (possible preformance boost).

with a wizard, steps(views) know about each other and all controls are initialized before rendering. the down side of wizards is css formatting. they are a pain because it's an overuse of nested tables.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[SiriusBlackOp]

I have never seen Verizon do anything right. LOL! I would next try to test your bandwidth at the remote site.

http://www.speedtest.net

Test both your site and the remote site to a place that is about the same distance away from both you and your remote site.

From here to Denver, I get 847 kbs Down and 1269 kbs Up on our T1. 847 kbs Down means that I should be able to download that 210-kb file in less than half a second.

Is the FitTabs.html file larger than 210 kb?


Also, while it is loading/rendering. Watch the taskmanager for both network use and cpu use to determine which is taking longer. Or are they both sitting idle for a while?

Senior Software Developer

http://www.scoutsft.com

 

[SiriusBlackOp]

I just retested to Denver and got 1243 kbs Down and 1376 kbs Up. Someone else here must have been downloading something while I was testing. Which reminds me... you don't have a bunch of people at the remote site streaming Audio or something do you? That is a common problem where one person figures out that they can stream in their favorite radio station, and the next thing you know everyone wants to do that and the bandwidth is gone.

Senior Software Developer

http://www.scoutsft.com

 

[Meleagant]

We try to discourage steaming audio, (although I do love to listen myself). I will try that speed test site.

The file was actually more like 726K. I forgot that I left tracing on and when I went to view to soure I got all of the trace information. Without the trace information my FitTabs.html file is 81K.

I have my tabs set to load on demand. A tab won't kick off it's server side code until it is selected. One really interesting thing is that I can see all of the other tabs controls in the control tree in the trace information. I switch tabs via Infragistics "Ajax" capability. I little animated gif spins around while the next tab is being loaded, and the tab's content area updates. I'm definitely going to look into the multi view control and see what I can do with that. It may not be a quick fix but if it gets me the performance that I need then it is worth doing.

I've got a little "fire" going on right now and if you guys wouldn't mind looking back at this post tomorrow I'll post the results of the speed test, cpu & network usage.

I really appreciate you guys helping me out and giving me ideas.

Thanks,
-- Joe --

* Sine scientia ars nihil est
* Respondeat superior

 

[Meleagant]

I went to

http://www.SpeedTest.net,

what a really cool site! Anyways from our remote office (NJ) to Denver I got 933K down and 1782 up. So with Tracing enabled on my web page it was about 726K, so that means I should be able to pull down that file in just under a second right?

From my desk: 2823 down and 642 up. So here I should be able t o download that 700K file in about a quarter of a sec right?

I looked at the CPU usage while the page loaded. The CPU bounced between 7 - 13% and then right before the page rendered it shot up briefly to 46%. The bytes sent/received didn't even use 1% of the network resources.

Something is not quite right and I don't know what...



* Sine scientia ars nihil est
* Respondeat superior

 

[Meleagant]

May be this will help....

You know that little progress/status bar in IE? When I watch my page load, that little guy really cooks. The bar zips right on by and then as soon as it gets all the way to the right, the page just seems to hang. I'm sitting here watching and that little bar gets all of the way to the right and I expect to page to render out right then, but it doesn't, it'll take another 10 seconds or so before the page writes itself out. Does anyone know what events go on during this "lag" time? May be it's linking out to the external js file and caching it at this point? Is there anyway I could do this *after* the page renders?

Just a thought and I thought that it might give someone a better clue as I don't seem to have one about this


* Sine scientia ars nihil est
* Respondeat superior

 

[SiriusBlackOp]

Well... here is a pic that is about 700 KB.

http://www.wakefieldmill.com/_files/mediainfo/EPV0440_low.jpg

I think we are talking about the difference bewteen kilo-bits (kb) and kilo-bytes (KB) for our download speed.


Sounds like it's trying to bring more stuff in once the page begins to render. You mention a js file, is that for a treeview or something? I've seen treeviews take some time to load, but I've never seen them interupt the entire page render before.

I would start removing bits and peices of code from your test file and retest for the delay symptom to see where it is.

Senior Software Developer

http://www.scoutsft.com