I am working on a website who have to work on Internet Explorer and Firefox. A page of this website has to load 80MB of data, put this information into a hidden HTML table and I use JS to show only a part of it (just some lines of the table instead of the entire 20 000 rows).

The request take around 10 seconds to be executed and, on Firefox, the result is printed immediatly. The problem is on Internet Explorer: it takes around 10 minutes (really) to show the page.

Are there some techniques to help Internet Explorer to manage this data? How can I resolve or bypass this problem?

Edit: I noticed this problem is caused by DataTables library who has problem to handle this amount of data. How can I customize it to resolve my problem? Will I have to create a light-version of DataTables for IE?

  • 2
    80Mb load? LOL You will likely find FireFox has it cached. Change some data and see if it loads instantly in FireFox. It won't...or if it does, you won't see the new data.
    – Steve
    May 3, 2017 at 10:10
  • 1
    Why 80MB? Just store the load on the server and pass only to the client the minimal amount needed. And besides, passing too much out to a client that's on a mobile device could cause him/her to incur significant data charges. May 4, 2017 at 18:13
  • This application is not made for mobile (it's not a public website). I want to load all the data at the loading of the page to avoid connection each time the user make a research (dynamic filtering) or switch page.
    – Pierre
    May 5, 2017 at 7:18
  • How to edit that library is off-topic here as well as too broad for Stack Overflow.
    – John Conde
    May 11, 2017 at 20:55
  • @JohnConde : I'm okay with that. But I recently found the solution without editing DataTables library: I used some particular option to do it. Can I edit my question and add my response in this question?
    – Pierre
    May 12, 2017 at 9:11

1 Answer 1


I suggest you don't put 20.000 rows of data on the screen. My very basic workstation will crash because of the amount of data, regardless of the browser. 80MB is a lot, especially if it's html!

Parsing so much is quite intens. I suggest you make something with a prev/next-page functionallity, I doubt the user requires all 20.000 lines on their screen at once, this would be a UI disaster.
You could add some search/filter functionallity to give the users tools to get to the relevant info ASAP.

If you really must, find ways to minimize the amount of html element and make sure it's 100% valid html. Both are optimalisations, not fixes, but it might safe you a few percent. You want to take that 80MB as much down as you possibly can, because we're talking about a huge amount of rendering.

  • I don't print the 20 000 rows and I use a prev/next-page functionnallity. But if I don't load all the rows at first, I have to make a new request each time.
    – Pierre
    May 3, 2017 at 12:09
  • 1
    It doesn't matter (much) wether you show all the rows or not. It's the fact that they're in the DOM. The tiny weight of a request does not outweight the costs your current solution has. Remember, when you select (say) 50 items per page, the request will be a whole lot faster because it's small.
    – Martijn
    May 3, 2017 at 13:19
  • Also consider that if you are using SQL, selecting rows by count becomes especially easy to do. Querying an entire result set that size for the web is going be trouble and non-standard.
    – closetnoc
    May 3, 2017 at 16:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.