IE11 GZIP slow for AJAX requests

Question

So this is a bit of a weird issue and I'm really searching for some best practices and potential solutions here.

Background:

I'm working on a very substantial enterprise application. It's a single page app, and aside from initial load, there are no full page loads in the app. Almost all service transactions return JSON.

The app produces large data sets, some of which can exceed 1 to 2 MB uncompressed. That's obviously not desirable, but given the complexity of our app and what it does, it's also not something we can readily change in a substantial way. So we have enabled dynamic compression in IIS for JSON and XML, which effectively knocks us down to around 47K on a 500K uncompressed JSON package.

(Getting IIS to dynamically compress JSON and XML at all was a bit of a chore, so if anyone needs tips there, I'm happy to oblige.)

The Problem State:

We are happy to get our data sets down in size, but we have noted that IE11 seems to deal rather poorly with compressed data coming back in an AJAX response object. Basically what happens is that there is a visible halt in the UI layer while IE decompresses GZipped data coming back from an AJAX request. It's not substantial (1.5 seconds), but it is quite noticeable. No other browsers we have tested suffer from this; Chrome, Safari, FireFox, Opera... all decompress and deal with this compressed data without any visible pause in the UI. So, this appears to be one of IE's charming eccentricities.

Attempted Solutions:

We've attempted to reduce this by optimizing our object sizes, and also by tweaking compression level. Of these, reducing the starting object size is the only thing that has successfully reduced the render lag; compression level seems to do little or nothing. But as I said, we've hit the outer limits of what we can do to optimize our data sizes.

What I need:

Ideally, someone out there has confronted this same problem, and can offer suggestions with respect to how we can get around this issue with IE11. Alternatively, I'd be thrilled if anyone can offer insight into exactly what is different about how IE processes gZipped responses, and why that difference boils down to a complete cessation of anything happening in the browser UI.

I'm far from being an IIS expert, so speak slowly and use small words ;-)

Coral

Just curious did you do anything to optimize the serialization of JSON datasets? When I started running 250k rows in a dataset JSON was getting enormous compared to XML because JSON. Infact I would get out of memory errors when serializing such big datasets. – Casi

Answer 1

There's no reason why IE should be slower here; GZIP content is expanded down in the network stack, and the code used is basically a port of Zlib, almost identical to what all other browsers are using.

Have you used IE's F12 Developer Tools' profiler to look into the performance?

If you load the site while Fiddler is running and the "Decode" option is set to Enable in its toolbar, does performance change?

Spaceband

Perhaps not compression level. Rather, maybe just IE DOM manipulation nastiness. We didn't see it with smaller sets... but when we started delivering larger sets (with compression) perhaps we noticed the lag because latency no longer obscured it. I've never been able to narrow down the reason why IE is so much slower than every other browser at DOM inserts / manipulation, but the issue persists even in Edge. – Coral