Summary:

Exchange 2010 has an updated OWA - now renamed Outlook Web App.  There are plenty of new features and improvements, but I've also noticed a dramatic increase in the page loadtimes, particularly on slower client connections.  Page loadtimes can be improved without any server-side code (JS/HTML) changes by ensuring that gzip compression is enabled end-to-end - which is, by default, not the case if OWA is published through Forefront TMG.  I reduced my OWA page loadtime from 27.47s down to 11.22s.

Problem:

Large pages of text can be compressed with gzip which dramatically improves loadtimes for most browsers.  By default, gzip compression may not be enabled in your Exchange 2010 IIS configuration, and may not pass through your Forefront TMG server publishing rule.  My Forefront TMG MBE was NOT configured to gzip .js and .css files, nor was it correctly configured to return compressed content (where appropriate) from published servers.

Solution:

1. Load OWA in Firebug and note the current loadtimes.  In the screenshot below, the JS library loadtime constitutes a significant portion of the overall page loadtime.  If you are not seeing this, then the following steps are unlikely to improve your loadtimes.  Make sure you hit Ctrl+F5 to reload the page without a cache.
   See http://justinho.com/files/uploads/OWA-01.png .  Note the ClientStrings currently is 29.6kb and the uglobal.js file is 799.1kb, resulting in a page loadtime of 27.47s, a near eternity.
    
2. Drill into the uglobal.js file in Firebug.  This step is to confirm that gzip compression is not enabled for the .JS file in question.
   See http://justinho.com/files/uploads/OWA-02.png .  Note the lack of the gzip compression in the Response headers.  gzip compression is not enabled when the client receives this JS file, but it is being requested (note the presence of gzip, deflate in the Request headers under Accept-Encoding.)
    
3. Let's fix that.  Ensure the /owa directory has high compression enabled on your OWA/CAS server. (Depending on your exact TMG configuration, this may prove to be moot since TMG may decompress your CAS server's response only to compress it again before sending it over the WAN.  See [2] before proceeding with this step.)
   
   In an Exchange PowerShell on the CAS [3]:
   Set-OwaVirtualDirectory -identity "owa (Default Web Site)" -GzipLevel High
   
   Restart IIS services:
   iisreset /noforce
   (I personally got error messages when I did this, so you can also just run iisreset without the additional parameter, which will interrupt open sessions.  You are doing this change during a maintenance period, right?)
    
4. Ensure Forefront TMG returns compressed HTTP content where possible.
   
   In Forefront TMG management, under Web Access Policy, find Configure HTTP Compression under Related Tasks on the right.  Ensure you Return Compressed Data from Anywhere (or at the very least, add your Exchange CAS servers):
   See http://justinho.com/files/uploads/OWA-06.png
   
   Note which filetypes are compressed as well:
   See http://justinho.com/files/uploads/OWA-07.png
    
5. Ensure .CSS and .JS files are compressed.  By default, TMG compresses HTML Documents, and Text (as we saw in the previous step.)  This is fine since images don't compress well.  However, we want to ensure .css and .js files are also returned compressed.
   
   In Forefront TMG management, under Firewall Policy, click Toolbox on the right, then Content Types, and find HTML Documents.  Double click to edit and add the following types [4]:
   
   application/json
   application/x-javascript
   .css
   .js
   
   Screenshot: http://justinho.com/files/uploads/OWA-09.png.  Yes, I realise these are "applications" - but we really don't want to gzip .EXE and other files through this webserver - I just want to fix this particular JS and CSS slow page loadtime problem right now.
    
6. Load OWA again now and note the reduced loadtimes in Firebug.
   
   See http://justinho.com/files/uploads/OWA-03.png .  The same ClientStrings request is now only 10.4kb, and uglobal.js is down to 202.7kb.  Page loadtime is now 11.22s, which is a dramatic improvement.
   
   Anyway, if we drill into the headers, we also see Content-Encoding shows gzip is now enabled in the server response:
   See http://justinho.com/files/uploads/OWA-04.png 
    
7. Done.  This is still an eternity as far as I'm concerned, so I hope Microsoft gets this cleaned up in a future Service Pack for Exchange.  I suppose using a standard JS library that other people use would be too much to ask.  Perhaps this library can be hosted somewhere by Microsoft on a CDN, or at least the GUI should allow customers to host these JS files elsewhere on a secure CDN?

References:

[1] http://getfirebug.com/ or https://addons.mozilla.org/en-US/firefox/addon/1843

[2] If your TMG is decompressing then recompressing the CAS OWA response, you might as well disable compression on your CAS and let TMG do the work.  Regardless of what compression level you set on OWA on the CAS, the TMG always appears to use low gzip compression.  To find out what the TMG is doing, access your CAS directly on the LAN via https://internalIP/owa then access it when published by the TMG (i.e. https://mail.contoso.com/owa) and note any change in content size.  See step 1 above, ensuring you hit Ctrl+F5 to force a reload of the page.

If I load my OWA directly from the CAS, I see the effects of high gzip compression: http://justinho.com/files/uploads/OWA-05.png
If I load my OWA published through TMG, I see lower gzip compression (and thus larger file sizes): http://justinho.com/files/uploads/OWA-03.png

In this case (TMG publish filesizes > CAS OWA filesizes) gzip compression can likely be disabled on the CAS (or at least left at Low compression) to reduce unnecessary server load.

[3] http://technet.microsoft.com/en-us/library/aa996547.aspx

[4] These filetypes were determined by inspection via Firebug.  Ensure you load the Exchange Control Panel (/ecp) via the Options link, etc. to ensure you hit all file types.