- It can also help alot if you try to use short identifiers of css class names, element ID's, Javascript Functions, etc. Especially when u have large grids with lots of columns and rows.

- Check out the  "OptimizeCSSClassNamesOutput" property this does what i described directly from Infragistics, so the grid renders more Compact.

- Setting style/appearance property at top most level
We in our company make really heavy use from Infragistics Appearances in our Fatclient, and we had to port this to web. So pay attention how you build your Grid on the server side. Keep the defaults in mind and set the stuff on the server side only exactly when its needed. If you iterate through cells in the Webgrid on server and set some style/appearance properties, this will have a direct inpact to the html. Because then everycell has the style directly set (not through CSS identifiers). Never set any properties on a level where you can set a property on a parent level. (If the row itself has backcolor=red, avoid setting it on the cell) I know this sounds simple and clear but its very important to always keep this in mind. A wrong implemented appearance on server side can heavily destroy performance.
We get so far in our company that we created "CSS styled" appearance merge logic for infragistics appearances... 

http://help.infragistics.com/Help/NetAdvantage/NET/2008.2/CLR2.0/html/WebGrid_Performance.html

1. Use profiling tools to see where the problems is. Sometimes the problem can be at the datasource layer (slow SQL query). Sometimes it can be server-side processing (the C# server-side code). Sometimes it can be slow loading time (maybe - a lot of HTML generated). Sometimes it is the browser itself that is sluggish (client-side / javascript problems). Knowing where the bottleneck is makes things much easier.

2. Use server side data caching. That is, never execute a complex and time consuming SQL query twice - store the result (for example DataTable in the application Cache and then retrieve from there on rebind).

3. Use ASP.NET Page Caching. That is the OutputCache directive. ASP.NET has a great great caching infrastructure built-in - through OutputCache you can customize caching in many ways (and invalidate cache when needed when data changes with Sql Dependencies, or through time dependency, etc)

4. Play with ViewState. Sometimes in some scenarios it is possible to turn ViewState off (EnableViewState = false) and then rebind from cache in each postback to server. ViewState off will reduce the HTML size signifficantly.

5. Script combining may also work fine (it was already suggested by a customer here, check out Tony Lombardo's post on our forums)

6. Install a ZIP add-on for IIS. There are many ZIP compression Add-Ons for IIS. ZIP compressors typically zip the IIS response and browsers decompress it on the client - this may speed things up a LOT. Just make sure you are using popular ones and test before deployment. I've seen page load times go up 5-6 times just because of that.

7.  Use Paging - either built-in or custom - it is unlikely that your end-users need more than 20-30 rows at a time, so PageSize > 20 will just make the requests slower whie not helping end-users a lot.

8. Use Load On Demand / AJAX. The grid has at least 4 different modes of that (Virtual Scrolling, AJAX, LoadOnDemand) - check out the samples and help for that - fetch only the data you need to display and load the rest when user interaction occurs.

9. Change the interface. I am not sure many end-users will be able to cope with 80 columns and 400 rows at once. I myself find it difficult to even read more than 5 columns and 20 rows at a time (this is 100 cells with data). You can show the rest of the rows with paging and / or AJAX, while for the columns - you can show them on row click in a different window, HTML placeholder, or even in our great WebDialogWindow component.

HTH, and keep the feedback coming - great stuff.

 I'm still looking for every eke of performance I can get, I am going to see what script combing does for me.  See: http://blogs.infragistics.com/blogs/tony_lombardo/archive/2008/07/28/script-combining-what-s-the-big-deal.aspx

So far, as a (paying) customer for a week now, I've been impressed with the support I've gotten both here in the forums, and via their chat interface.

Performance often depends a lot on what you are doing.  I once revesed the sort order of a medium-sized dataset and it more than quadrupled the response time.

To see what others have done, use the Search function at the top of the page.  Look for "performance" and (separately) for "slow".

And please keep in mind the fact that, when a WebGrid perfoms well, nobody ever posts anything like "Hey, everyone, my WebGrid has a wonderful response time."  ;-)