IE11 XMLHttpRequest очень медленно работает

Я бы подключил к браузеру отладчик НАСТОЯЩЕЙ ОС и попытался определить, действительно ли IE запускает поток для выполнения XHR. Это сложное расследование, но оно многое объясняет.

Большинство браузеров делают это, а затем направляют обратные вызовы и данные обратно в MAIN UI THREAD. Но IE СТАРЫЙ, и я не знаю, что он делает.

На другую мысль. Наша БОЛЬШАЯ компания, которая движется медленно, наконец, отказалась от поддержки IE, что позволило нам писать приличный код с обещаниями без полифилла. Наша кодовая база медленно очищает другие странные полифиллы, которые мы приобрели с течением времени. Долгое время мы НЕ могли писать для (клавиша var), потому что в списке появлялся полифилл.

Вы могли бы подумать об этом обсуждении с клиентами. Он начинается с «Как насчет Edge или Firefox». Вы можете поговорить о замене других вещей. Вы обновляете свой телефон и ноутбук... как насчет браузера...

Прежде всего удачи.

Вы можете выяснить, перехватывается ли запрос XMLHttpRequest. В то время как современные браузеры снижают производительность при этом меньше, для IE обмен собственными вызовами с функциями JS влияет в определенной степени и масштабируется по мере его использования. Это относится к множеству полифиллов и расширенному функционалу.

Судя по вашим снимкам экрана, может быть узкое место вокруг предварительных запросов CORS... Возможно, это https://developer.akamai.com/blog/2015/08/17/performance-single-page-apps объяснит вам жизнеспособный обходной путь .

Кроме того, я хотел бы выяснить, почему ваше приложение делает множество запросов OPTION, если только это не предусмотрено, ваше приложение совершает много круговых поездок, каждое из которых задерживает следующее, и с ограничением на одновременные соединения вы в конечном итоге потребляете пул и блокируете дальнейшие просьбы...

Было бы интересно посмотреть, что происходит по сети, через вкладку сети IE...

Похоже, что XMLHttpRequest ставится в очередь, а затем выполняется в пакетном режиме, по существу останавливая каждый запрос, пока какой-то внутренний процесс не отправит их все сразу.

Первое, что я хотел бы исследовать, это то, что IE имеет (плохо задокументированные) внутренние ограничения на количество одновременных запросов XMLHttpRequest и браузера, которые он разрешает одновременно. В более старых версиях это было 2, но оно увеличилось примерно в IE8 до 6 в зависимости от какой-то ужасной и ненадежной внутренней метрики относительно того, насколько быстрой, по мнению IE, является ваша сеть. IE11 по-прежнему делает это, но имеет более высокий предел.

Я предполагаю, что вы достигли этого предела, и как только вы его достигли, проверка внутреннего таймера, которая управляет пакетами в IE, занимает 1-2 секунды, прежде чем он отправит другой набор на сервер.

Чтобы проверить эту гипотезу: в IE11 добавьте только ожидание 100 мс (его просто должно быть достаточно, чтобы ограничить количество параллельных запросов) перед отправкой каждого запроса. Это по-прежнему будет ужасно медленным, но если причиной является внутренняя пакетная обработка, вы не увидите 1-2-секундную задержку в блоках запросов.

Если это проблема, исправление может быть своего рода группировкой, чтобы попытаться избежать ограничения IE, но, поскольку это динамично, я подозреваю, что это будет непропорционально много боли для ‹ 1,5% пользователей.

5-6 мс в Chrome кажутся слишком коротким временем для фактического вызова сервера. Если мы смотрим на одни и те же сетевые вызовы на обоих скриншотах (неясно, так ли это), то более вероятно, что Chrome использует кэшированный ответ, а IE совершает сетевой вызов. Проверьте заголовки кэширования и убедитесь, что вы используете те, которые понимает IE.

Эта проблема связана с конфигурацией браузера Internet Explorer для запросов AJAX.

Выполните следующие локальные изменения:

Внесите изменения в локальную политику, как показано ниже:

Перейдите в Компоненты Windows › Internet Explorer › Функции безопасности › AJAX Включите «Разрешить встроенную поддержку XMLHTTP». Измените «Максимальное количество подключений на хост (HTTP1.1)» на 16. Измените «Максимальное количество подключений на сервер (HTTP1.0)» на 16.

Кроме того, большинство компаний отказываются от поддержки IE. Никто не хочет писать полифиллы для вещей, которыми никто не пользуется, и почему вы используете IE? Пожалуйста, ответьте, я хочу знать.

Вы можете копнуть глубже, чтобы отследить сеть http, используя журналы Microsoft ETL.

• Создайте папку C:\msfiles

• открыть cmd с повышенными правами администратора

• введите команду netsh trace start InternetClient_dbg capture = yes maxsize = 450 filemode = круговой постоянный = yes overwrite = yes traceFile = C:\msfiles\Etl_trace.etl

• выполните действие, которое вы хотите, это фактическая проблема с сетью

• остановить трассировку с помощью команды netsh trace stop

-› теперь у вас есть Etl_trace.etl

Сделайте это один раз с IE и один раз с Chrome и сравните журналы...

У меня была похожая проблема с AngularJS в IE, мы отследили нашу проблему до обновления безопасности для IE (KB2962872). Удаление этого патча вернуло производительность к норме.