MSIE vs. Firefox and asynchronous AJAX...is MSIE really NOT doing async?

Question

Apex v4.1
MSIE v8.0 and Windows XP
Firefox v6.0.2
Background
Sorry it's a lot but I figure giving all this context would help avoid tangental questions that could derail from my real question(s).
I have a master-detail page where I have such business and functional requirements to do a lot of various validations, checking, disabling/enabling, etc. in the detail region. Given that detail regions in master-detail pages are nothing more than tabular forms that are filtered by the master record's PK and that tabular forms have limited validation and nonexistent calculation ability via declarative calculation processes, my detail region is immensely javascript heavy. In addition, I have the functional requirement that the user see all detail lines on the same page, so I cannot limit the page to 10-15 lines per page anyway.
When the page loads, I need to do a number of functional things to the detail region before the page control is turned over to the user, such as:
1. Disable certain columns that are saved as database columns but never touched by the user.
2. Disable certain columns that the user does not have authorization to modify (but tabular forms have no "readonly" attribute for columns like page items do)
3. Disable certain fields on a row (but not on all rows) based on business rules (e.g.: if PART_NO on a row is null, PART_SERIAL_NO on that row only needs to be disabled (as the user shouldn't be able to enter it).
4. Etc., etc...you get the idea. There are just a lot of things that cannot be declaratively done to a tabular form column and also things that cannot be done on a row-by-row basis, hence the javascript.
When the page loads, I also have to do two cosmetic things to the rows and these can be done after the control is turned over to the user since they are cosmetic only and do not affect their ability to be disabled out of a row-field combo, etc.:
1. For one column that is a popup key LOV, override the displayed value with a different value than Apex generates from the LOV definition. In other words, the LOV definition is "a || b" for the display value and "c" for the return value, but on the main page the users want "a" for the display value that they see.
2. For all records, evaluate several fields on a record and as a result, highlight certain other fields in red, yellow, or black via the background color.
Everything is actually working in both MSIE and Firefox and I'm happy about that. However, the stuff I'm doing in the second group (the popup key LOV display field and the coloring of the background of fields) is only working nicely and quickly in Firefox but is super slow in MSIE. My worst-case scenario in testing is my master-detail has 281 detail rows and in Firefox it takes about 20-25 seconds to paint the page, give control to the user, and then finish doing the asynchronous AJAX stuff after that (which sems to also go quickly). In MSIE, my page rendering time ranges from 1 minute 30 seconds with the AJAX async stuff commented out and not even running to over five minutes (!) with the AJAX stuff left in and running. The difference of 4+ minutes also implies to me that the AJAX stuff is not running asynchronously (or if it is, something else is getting in the way of the effective purpose of it being asynchronous).
Right or wrong, how I built my page is that since a lot of the Javascript code is to act on the detail region onlly, I defined the javascript in the region and not in the page just so that when the detail region isn't displayed (usually when a new master is being created), we don't even display or render any of the javascript.
When the detail region does show, the Javascript that goes along with it to do all the work to the detail region rows/columns also runs.
Example...this is in the region footer of the detail region:
<script type="text/javascript">
//Always when region loads
//Initialize special processing on the fields on the lines that can't be done
//elsewhere.
if (window.addEventListener) // W3C standard
  addLoadEvent(InitDetailItems());
else if (window.attachEvent) // Internet Explorer
  addLoadEvent(InitDetailItems);
if (window.addEventListener)
  window.addEventListener('load', postLoad, false);
else
  window.attachEvent('onload', postLoad);
</script>When the detail region loads, I append a call to the onload event of the page so that the function InitDetailItems is called (addLoadEvent is just another wrapper that detects if the page even has an InitDetailItems function and if it does, it then adds a call to InitDetailItems to fire in addition to any other on-load processing). I did it this way as a matter of style such that if a developer added any onload at the page header that this would just be appended to it. This call to addLoadEvent and InitDetailItems all runs javascript to prepare the detail region non-async (the user must wait for it to finish processing before they should get control of the browser).
Then, the call to also add on a call to postLoad is where the cosmetic async stuff is supposed to happen. I am not a javascript expert by no means but from what I can gather:
1. "window.addEventListener('load', postLoad, false);" works for most non-IE browsers, adds a call to postLoad on the event 'load', and "false" means that it is done non-binding (async).
2. There is no "addEventListener" in MSIE, so it uses "window.attachEvent" to add the call to postLoad to the onload event. This is non-async with no async option, but....keep reading...
PostLoad itself looks like this:
function postLoad()
{ //Stuff do to after this region loads but can be done in an async fashion
  //because they're only cosmetic things.
  setAllMaintDescr(gMaintItemIdCol,gMaintItemIdCol + "_DISPLAY");
  checkAndColorFields();
}setAllMaintDescr is the function that sets my popup key LOV values by querying the database and returning and setting the values in this field accordingly.
checkAndColorFields is the function that passes some fields' values to a PL/SQL packaged function, it computes a color of black, red, yellow, or none and the javascript sets some field background colors accordingly. This logic resides in a PL/SQL package because we have a BI report that is a near copy of this page and needs to call the same logic.
Both setAllMaintDescr and checkAndColorFields call htmldb_Get and get.GetAsync when the database work is done, so even though in MSIE the call to postLoad is not async, the functions themselves call async code that should theoretically be executing in an async manner.
The Real Question(s)
So...bottom line is that in Firefox, the page always takes about 20-25 seconds to load with or without setAllMaintDescr and checkAndColorFields commented/uncommented. This leads me to believe that my code in InitDetailItems (all non-async) is consistently taking 20-25 seconds to execute and postLoad processing is truly async since the page is returned to user control in the same amount of time.
But in MSIE, without setAllMaintDescr and without checkAndColorFields, page load already is a slower 1 minute 35 seconds. With setAllMaintDescr and checkAndColorFields, it swells to well over 5 minutes whereas these async calls to htmldb_Get I would think should not increase much if at all over the initial 1:30 load time.
Any tricks with MSIE? Any settings in the browser I need to know about? Is it truly ignoring my get.Get_Async calls and treating them as get.get()?
Or is MSIE just truly that much of a turd as a browser? Ugh.
Sorry for the long narrative but wanted to answer as many questions about my page first.

Answer 1

^^^ Long post.
Cliff's notes for those I may have lost:
Page dynamically adds two Javascript functions to the onload event.
Each Javascript function calls some PL/SQL but it's all done using get.GetAsync.
Firefox returns control of the page to the end user relatively quickly and consistently regardless of what functions are commented out/uncommented.
MSIE is much slower and takes more time as I uncomment the async Javascript functions.
Why does MSIE seem as if it's behaving non-asynchronously?