Sign up ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I'm using Openlayers, Geoserver and noticed that IE is very very slow to display WFS layers. I haven't so many WFS features, about 300. Google base layer appears after 1 sec. but my two WFS layers need each from 10 to 20 seconds to display. With Chrome, it requires only 2 seconds.

I tried to disable style rules, events, no change. It's really a client issue, my cpu goes up to 50% for iexplore during features loading. I tried with IE8 and 9, with two differents pc, same results.

It seems that I'm not the only one. I can keep using Chrome but would be interested to share ideas


share|improve this question
did you profile it with the IE dev tools? What istakingthe lomgest? – Ragi Yaser Burhum Mar 24 '12 at 18:51
I suspect your features are too detailed. How many vertices do they have? 2 seconds on Chrome is an awful lot for just 300 features. – unicoletti Mar 24 '12 at 20:09
unicoletti : It's a set of cables, most of them have only 3 to 5 vertices, a few dozens have up to 30. I have no problem waiting 2 sec, my problem is to wait more than 30 with IE. @Ragi I don't know how to do that. I tried with 'F12' tool, with some break point I saw that my javascript is done in an instant and after, I wait 30 seconds not knowing what is happening, just seeing the CPU at 50% for iexplore. – Olivier Mar 25 '12 at 8:28
I tried again to remove everything and keep only my WFS layer with gmap. Same result. By the way, one can try Even if this layer is very light, it possible to see that Chrome displays immediately when IE requires several seconds between gmap and WFS layer of states. – Olivier Mar 25 '12 at 11:07
IE9 supports SVG renderer, so performance in this browser more better than in IE8 (SVG renderer is not supported in IE8). What renderer do you use? Make sure to set the doctype properly in your HTML document: <!DOCTYPE html> for using SVG in IE9. – drnextgis Mar 26 '12 at 2:23

1 Answer 1

We are using OpenLayers 2.13.1 with the Dutch PDOK map implementation and were experiencing severe performance problems with WFS sources. I found a simple way to speed IE up by about a factor 2. It is still slow, but at least there is a significant improvement. Also it seems to use less CPU than before.

When profiling, I noticed that the most time is spent in the XMLHttpRequest.responseText property. Looking at the OpenLayers code, I saw that a version of is used. That class was intended to emulate XMLHttpRequest for Internet Explorer versions lacking a built-in XMLHttpRequest object. However, this should not be required in IE9 and newer, and Open Layers 2.x does not work properly in older IE versions. IE < 9 has become very uncommon anyway, even for the most convervative of our customers.

To make a long story short, here is how to speed up Open Layers 2 in IE:

  • Start with OpenLayers.debug.js (unminified code)
  • Look for the XMLHttpRequest.js code block
  • Replace the browser sniffing code at the start of the class by:

    var bGecko = !!window.controllers, bIE = false, bIE7 = false;

  • Look for occurences of the text "ActiveXObject". Ensurte that all code depending on this is not executed. E.g.,

    if (false /* window.ActiveXObject */) {

  • Finally, a fix is needed for a namespace problem in IE. Look for this function inside OpenLayers.Format.XML:

    write: function (node) {

  • Add this code just before the closing bracket of the function:

    if ("ActiveXObject" in window) // If IE is detected

    data = data.replace(new RegExp('xmlns:NS\d+="" NS\d+:', 'g'), '');

  • After testing the fix, re-minify the code for release, e.g., by using Microsoft's Ajax minifier.

The replace statement was always needed to get WFS to work in IE11 and Edge. After disabling the XMLHttpRequest emulation, the same applies to older IE versions as well.

[edit]In addition to the above, we should fully avoid accessing request.responseText in IE. With the built-in XMLHttpRequst object, responseXML should always be available and valid. In my test, the original code spent about 8000 ms in responseText and 600 ms in responseXML. Actually, we do not need responseText at all in WFS.

Additional changes:

  • In function fGetDocument(oRequest) remove all code related to sResponse, leave only oDocument
  • In function fSynchronizeValues(oRequest) set oRequest.responseText = '';
  • Replace var response = arcxml.parseResponse(request.responseText); by var response = arcxml.parseResponse(request);

With these changes, no more time is spent in responseText, while the time spent in responseXML does not increase. I have also tested WMS and WMTS layers, they still work as before. I've repeated all tests in firefox and chrome, dit not find side effects.


Hope this helps,


share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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