Производительность Reflow / Layout для больших приложений

Я использую GWT для создания приложения HTML, где производительность в целом является правильной.

Иногда он может загрузить много объектов в DOM, и приложение становится медленным. Я использовал Chrome Developer Tools Profiler, чтобы увидеть, где было потрачено это время (в Chrome после компиляции приложения, т.е. без затрат на GWT), и стало ясно, что методыgetAbsoluteLeft () / getBoundingClientRect () потреблять большую часть этого времени.

Вот реализация, используемая в Chrome (com.google.gwt.dom.client.DOMImplStandardBase):

private static native ClientRect getBoundingClientRect(Element element) /*-{
  return element.getBoundingClientRect && element.getBoundingClientRect();
}-*/;

@Override
public int getAbsoluteLeft(Element elem) {
  ClientRect rect = getBoundingClientRect(elem);
  return rect != null ? rect.getLeft()
     + elem.getOwnerDocument().getBody().getScrollLeft()
     : getAbsoluteLeftUsingOffsets(elem);
}

Это имеет смысл для меня, поскольку чем больше элементов в DOM, тем больше времени может потребоваться для вычисления абсолютных позиций.Но это расстраивает, потому что иногда вы знаете, что изменилась только часть вашего приложения, в то время как этим методам все равно потребуется время для вычисления абсолютного позиционирования, возможно потому, что он излишне перепроверяет целую кучу элементов DOM, Мой вопрос не обязательно ориентирован на GWT, так как это проблема, связанная с браузером / JavaScript:

Есть ли какое-либо известное решение для улучшения GWT getAbsoluteLeft / javascript getBoundingClientRect для решения больших DOM-элементов?

Я не нашел никаких подсказок в Интернете, но я думал о решении, как:

(уменьшение количества вызовов для этих методов :-) ...изолировать часть DOM через iframe, чтобы уменьшить количество элементов, которые браузер должен оценить, чтобы получить абсолютную позицию (хотя это затруднит взаимодействие компонентов ...)в той же идее, может быть какое-то свойство css (переполнение, позиция?) или какой-то элемент html (например, iframe), которые говорят браузеру пропустить целую часть dom или просто помогают браузеру быстрее получить абсолютную позицию

РЕДАКТИРОВАТЬ :

При использовании отладчика Chrome TimeLine и выполнении определенных действий, когда в DOM много элементов, у меня средняя производительность:

Пересчитать стиль: почти нольКраска: почти 1 мсМакет: около 900 мс

Макет занимает 900 мс через метод getBoundingClientRect. Этот список страницвсе методы запуска макета в WebKit, включая getBoundingClientRect ...

Поскольку в моей жизни много элементов, на которые не влияют мои действия, я полагаю,расположение делает пересчет во всем DOM, тогда какпокрасить может с помощью свойства css / дерева DOM сузить область его действия (например, через MozAfterPaintEvent в firebug).

За исключением группировки и менее вызова методов, запускающих макет,какие-нибудь подсказки о том, как сократить время на верстку?

Некоторые похожие статьи:

Минимизация перекомпоновки браузера

Ответы на вопрос(2)

Ваш ответ на вопрос