Вопрос по html, optimization, performance, html-table, css – Как избежать затрат производительности на переполнение: скрыто?

9

У меня есть HTML-таблица, которая может содержать более 1 000 строк и около десятка столбцов.

Я хочу, чтобы столбцы были фиксированного размера (контролируемого пользователем) и не увеличивались / уменьшались ни по вертикали, ни по горизонтали. Таким образом, визуально содержимое отдельной ячейки таблицы будет в одной строке, а переполнение будет обрезано в конце ячейки.

Анализ производительности в Chrome на большом столе является основным фактором снижения производительности.overflow:hidden.

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

Что люди рекомендуют улучшить производительность?

При необходимости мне не нужно использовать тег таблицы, но я бы предпочел придерживаться тега таблицы, если можно добиться хорошей производительности.

Update 1Я включил файл, который демонстрирует проблему производительностиВот, Предупреждение: файл довольно большой (25 МБ) и замедляет работу компьютера. По умолчанию таблица не имеет переполнения скрытого, и после загрузки таблицы (может занять некоторое время) производительность браузера относительно плавно.

Однако, если вы редактируете файл и раскомментируете строки 12-15, а затем открываете его. Вы увидите, что после загрузки браузера за столом значительно меньше отклика.

Есть ли причина, по которой вы не используете нумерацию страниц? Michael Christensen
Общая производительность браузера после загрузки таблицы. Прокрутка, нажатие и т. Д. Omar Ismail
Не могли бы вы опубликовать образец используемой разметки и стилей? Вот: Gist.github.com / 2705929 Я настроил таблицу 12x1800 с 400+ символами на ячейку. Производительность кажется хорошей (хотя я не на медленной машине). Beejamin
Многие причины на самом деле. В первую очередь с точки зрения UX. Но у вас может быть ситуация, когда у вас всего 100 рядов, и человек работает на медленном компьютере. Повышение производительности принесет пользу не только пользователям с большим количеством данных, но и всем. Omar Ismail
Кроме того, не могли бы вы рассказать о спектакле, который вас интересует? Начальное время рендеринга, прокрутка, поиск, манипулирование DOM и т. Д ... Beejamin

Ваш Ответ

4   ответа
3

Я столкнулся с этой проблемой на iPad / iOS, что вызвало проблемы с производительностью страницы, содержащей около ста строк в таблице с разметкой таблицы: исправлено.

Как только ячейка или элемент div в ячейке получает атрибут, который заставляет ее рисовать ячейку по отдельности, на рисование уходит около 300 мс вместо 100 мс (что приводит к ужасно медленному интерфейсу в моей ситуации).

Любое из двух свойств position:relative илиoverflow:hidden) вызвал проблему для меня, удаление их оптимизировало скорость, но вызвало переполнение текста, если текст ячейки был слишком широк для столбцов фиксированной ширины.

Замедление происходило даже после того, как таблицы были нарисованы, потому что я динамически показываю абсолютный div над таблицей. При профилировании JavaScript (используя(new Date).getTime()), замедление измеряется в местах в JavaScript, которые не имеют ничего общего с таблицей.

[edit: добавлено следующее как частичное решение]

Поместите все содержимое ячейки вspan element (поэтому можно измерять offsetWidth содержимого, а не ширину содержащего блочного элемента). После добавления строки в документ проверьте, является ли каждый span.offsetWidth больше ширины столбца, если это так, добавьте «overflow: hidden» к стилю (или через класс) содержащего блока. Можно пропустить 1 и 2 выше для некоторых столбцов (если известно, что содержимое ячейки никогда не будет нуждаться в отсечении).

Caveats:

Измерения сделаны только для iOS5 Safari (я не профилировал другой браузер). Работает для нас, потому что мы динамически создаем строки таблицы (обработка вашего примера с использованием javascript будет медленной?). Большинство ячеек для наших данных не переполняются (отсечение требуется только редко - только ограниченное количество ячеек). Скомпрометированная начальная загрузка страницы (генерация таблицы на странице была увеличена с 80 до 800 мс). Но ускорило динамическое всплывающее окно со списком (340 мс до 130 мс), что значительно улучшило отклик клавиатуры.

Для вашей ситуации может быть быстрым первое использование столбцов переменной ширины, измерение offsetWidth всех столбцов, установка ширины столбца в ширину пикселей и настройка переполнения: скрыто только для столбцов, где offsetWidth столбца больше ширины пикселя, которую вы будете использовать для колонка

2

чный подход к эффективному созданию таких вещей, как бесконечно прокручиваемые игры.

Поместите все ваши данные в массив Javascript, а затем добавьте N + 1 рядов в таблицу, в которой видимы N строк. Когда вы прокрутите вниз, последний элемент переместится в поле зрения. В тот момент, когда вы прокрутите достаточно далеко, чтобы первый элемент переместился из поля зрения, вы сдвигаете все данные вверх на строку и сбрасываете положение прокрутки обратно туда, где оно началось. Если все сделано правильно, сдвиг будет полностью прозрачным для пользователя. Вы бы работали только с N + 1 строками в таблице, видимой с N-строками.

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

1

количество разметки, необходимой для создания таблицы, намного больше, чем просто использование div с clear: both css для новой строки. так что это первый хит производительности.

Кроме того, вы устанавливаете переполнение как класс (?)

 <style type="text/css"> .ovfl { overflow:hidden; }</style>

  <td class="ovfl"></td>

Кроме того, 1000 строк - это вес для доставки.

С divs у вас, по крайней мере, есть более простая возможность выбросить их из поля зрения (за пределами свитка) в div сdisplay: нет пока посетитель не прокрутит их.

мало шкур для кота, скорее всего, на этой работе,

У Хоуп были хорошие мысли.

1

Веб-баг 75001 связана с этой проблемой и охватывает работу, которая делается для ее решения (см. также информацию о зависимостях bugzilla).

Похожие вопросы