Heavy HTML, медленная декомпрессия браузера

Question

У меня очень тяжелый отчет, который я визуализирую в html-таблице. Он динамический, иногда он может иметь 100 строк раз 100 столбцов, иногда он может достигать более 1000 строк. Этот отчет также имеет различные способы визуализации, поэтому я использую CSS для отображения/скрытия некоторых значений в зависимости от того, каким образом я хочу его видеть. Данные в строках - это то, что подобно дереву, поэтому я использую кнопки для отображения/скрыть дочерние строки для имитации эффекта дерева (по умолчанию дочерние строки «закрыты»/отображаются: нет).

Проблема заключается в том, что когда я получаю один из этих больших отчетов с 1000 строк, браузер иногда (почти всегда на Chrome, а иногда и на Firefox) занимает длительное время (более 5 минут), чтобы дефрагментировать HTML (что происходит от вызова Ajax). Все дело в том, что около 37 Мб распаковывается, иногда браузер управляет им быстро, в других случаях он очень медленный.

Единственное, о чем я мог думать, - это предоставление частей четкого «представления» отчета (что означает меньшие штыри html), но тогда мне нужно будет обрабатывать все это как минимум три раза (по требованию) поэтому пользователь увидит все возможные комбинации.

Я только начинаю иметь эту проблему, когда hmlt составляет 30 мб плюс. Я знаю, что есть что-то очень неправильное, что я должен делать, но я не знаю, с чего начать большинство материалов, которые я читал о производительности html, похоже, не применяется. У меня нет привязки jquery, работающих при обратном вызове, так что это ничего не связано с этим.

Edit:

Я сделал некоторые испытания после рендеринга его в мелкие куски (большой один пошел от 35MB до 21MB меньший теперь 2,4mb.). Но, похоже, это не связано с размером html, даже меньший иногда замедляется (5 секунд, 3 секунды, а не 30 секунд). Я ошибся.

В настоящее время я использую .html(), чтобы поместить результат вызова ajax в div, я также попытался использовать .load().

Answer 1

Кажется, я ошибался все время. Он не имел никакого отношения к размеру hmlt и тому, как браузер обрабатывает декомпрессию. Дело в том, что html вообще не сжимался.

Я заметил это, когда сравнил вкладку сети с Chrome. В нашей среде разработки с Visual Studio и IIS Express было показано, что HTML был сжат, но в нашей внешней среде песочницы (где я запускал тесты данных havier) он не был сжат.

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

http://weblogs.asp.net/owscott/iis-7-compression-good-bad-how-much

Но он все еще работал неправильно, я думал, что это связано с включенными mimeTypes для сжатия IIS, но это все еще не решило проблему.

Наконец-то я заметил, что дома было хорошо, но на моем рабочем месте все еще было очень медленно. Причиной этого является прокси-сервер для сети.

noCompressionForProxies Необязательный логический атрибут.

Указывает, отключен ли ответ HTTP 1.1 для сжатия запросов, поступающих через прокси-серверы.

Примечание. Некоторые HTTP-прокси-серверы не обрабатывают кеширование сжатых объектов правильно. Вы можете использовать этот параметр, чтобы избежать возврата сжатого файла на прокси-сервер, который не может его распаковать.

Значение по умолчанию - true.

http://www.iis.net/configreference/system.webserver/httpcompression

Это означает, только изменяя степень сжатия уже была исправлена ​​проблема.

Answer 2

Вы можете начать загрузку 100 строк, а затем загрузить еще 100 с помощью Ajax, затем все больше и больше.

На самом деле, вы не можете видеть весь отчет 30+ МБ сразу, потому что размер монитора, а затем вы можете динамически загружать-уничтожать данные. Остается видимым только 1000 строк данных.