Как CSS может оказать значительное негативное влияние на время рисования страницы в определенной области веб-страницы?

Вопрос:

Бесценная статья по этой проблеме - упомянуто JackPattishallJr.

Например:

Я не знал, что CSS вступил в силу на основе местоположения пользователя на странице. Означает ли это поведение, что он делает?
Есть ли конфликтное или необычное позиционирование CSS, анимация и т.д., которые могут привести к низкой производительности?
Как стилизация CSS напрямую и последовательно связана с производительностью страницы? В частности, время нанесения страницы.

Обновление: я редактировал вопрос и примеры на основе двух тестов, которые я только что сделал:

Без javascript, включенных в моем браузере, низкая производительность (на удивление) непротиворечива.
После удаления стиля проблемной области проблема решена (но не совсем, потому что теперь моя страница уродлива).

Проблема со временем рисования страницы

Я заметил, что моя веб-страница плохо работает (лагги) в одной конкретной области на странице.

Чтобы изучить проблему, я включил show paint rectangles и enable continuous page repainting, чтобы получить некоторые показания на скорости перерисовки страницы.

Здесь представлено видео Youtube, которое я продемонстрировал.

Здесь здоровое чтение, в области моей страницы, которая является отзывчивой и гладкой:

Здесь нездоровое чтение (в проблемной области), где чувствительность страницы медленная, а прокрутка очень отсталая:

Страница выполняется отлично, со здоровыми показателями перерисовки вверху (где активнее всего происходит, фактически), и выполняет ужасно (почти останавливается) в нижней части страницы. Он возвращается к идеальной производительности, когда я прокручиваю прочь от проблемной области.

Обновление: Я полностью отключил Javascript и получил те же проблемы с производительностью и чтения, что и раньше.

Ответ 1

Я не знал, что CSS вступил в силу на основе местоположения пользователя на странице. Означает ли это поведение, что он делает?

Это абсолютно так, потому что браузер не хочет отображать все на странице сразу. Поэтому пятна страницы (если они есть), которые требуют больше обработки, будут медленнее, чем пятна, которые меньше обрабатываются.

Существует ли конфликтное или необычное позиционирование CSS, анимация и т.д., что может привести к низкой производительности?

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

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

Как CSS-стиль напрямую и последовательно связан с производительностью страницы? В частности, время краски страницы.

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

Во втором месте производительность CSS-эффектов - это расположение элементов. Если вы разместите 1000 элементов в одном и том же положении, это, естественно, будет работать хуже, чем если у вас есть 1 в одном месте, независимо от того, сколько их можно увидеть или повлиять на макет. Это не полностью связано с CSS, но определение CSS - это то, что определяет, где находятся элементы, и тем самым влияет на производительность сразу. Изменение компоновки элементов возвращает его в основной поток, что заставляет задуматься над частью процессора в дополнение к перерисовке.

Третий, который вы указали в своем вопросе, - время рисования. Ссылка которую вы связали, хорошо вписывается в нее, объясняя, что box-shadow воняет для времени рисования. Есть лот отчеты этого, потому что он существует. В этом суть вашей конкретной проблемы; основная причина. Вы должны избегать их, особенно навалом, когда сможете. Использование градиентов вместо этого, скорее всего, улучшит время рисования, потому что они дешевле.

В-четвертых, CSS определяет, воспроизводится ли анимация или переход с использованием процессора или графического процессора. Хотя у нас еще нет этой функции, Sara Soueidan в ее статья о свойстве will-change довольно глубоко раскрывается в этом. Таким образом, центральный процессор (центральный процессор) является мозгом компьютера и занимает больше времени для рендеринга, в то время как графический процессор (Graphics Processing Unit) работает быстрее при рендеринге вещей, но не может "думать" так же. В настоящий момент мы делаем трюки типа translate3d(0, 0, 0); или translateZ(0px), чтобы заставить браузер отображать его с помощью графического процессора, но в будущем мы будем иметь свойство will-change.

Как говорит Сара в статье, не делает GPU обрабатывать все, поскольку браузер обрабатывает его как можно лучше, и "некоторые из более сильных оптимизаций, которые, вероятно, будут привязанный к will-change, заканчивается тем, что использует много ресурсов машин, и, когда это злоупотребление, это может привести к замедлению страницы или даже к сбою".

Таким образом, CSS может значительно отрицательно повлиять на время рисования страницы в определенной области веб-страницы, увеличивая время рисования, изменяя способ размещения элементов, заставляя слишком много элементов обрабатываться в CPU или GPU и сколько времени требуется компилятору для интерпретации и применения CSS.

BoltClockбыл на месте, когда он прокомментировал,

Коробочные тени обычно являются одними из самых дорогих в большинстве браузеров. Существует почти нет причин иметь такое большое распространение - вы могли бы также использовать градиент или что-то;)

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

Ответ 2

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

Следите за тем, чтобы удаление одного символа CSS мгновенно менялось.

Извлеченный урок. Никогда не используйте тень в 2000 пикселей. Когда-либо. КОГДА-ЛИБО.

Как CSS может оказать значительное негативное влияние на время рисования страницы в конкретная область веб-страницы?

CSS-стиль имеет очень развитую, прямую связь со временем красок страницы, а эта статья HTML5Rocks объясняет и демонстрирует ее хорошо.

В принципе, разные функции стиля (и некоторые их комбинации) оказывают очень серьезное влияние на вес страницы. Такое поведение можно четко наблюдать с помощью функции хром continuous page repainting.

Если кто-то может дать более подробный, проницательный ответ, пожалуйста.

Обновление: Я опубликовал щедрость, чтобы дать ответ, который объяснит эту проблему более подробно. Хотя статья объясняет ситуацию довольно хорошо, она может не существовать завтра, поэтому полностью подробный ответ всегда намного лучше (и часто имеет большее качество, чем исходные статьи). И у меня нет ни времени, ни понимания.

Ответ 3

Поскольку вы уже обращались к растеризации, вот еще несколько сведений о производительности css.

1) Селекторы

Вот о некоторых проблемах, которые Github имел с CSS, особенно с селекторами и как они могут влиять на производительность страницы: http://vimeo.com/54990931 Слайд-версия здесь: https://speakerdeck.com/jonrohan/githubs-css-performance

Если вы не будете осторожны, препроцессоры css могут генерировать несколько очень длинных селекторов, например, взятый из Bootstrap dist css:

.table > thead > tr > th,
.table > tbody > tr > th,
.table > tfoot > tr > th,
.table > thead > tr > td,
.table > tbody > tr > td,
.table > tfoot > tr > td {
  padding: 8px;
  line-height: 1.42857143;
  vertical-align: top;
  border-top: 1px solid #ddd;
}

2) Несколько экземпляров SVG XML

Недавно я попытался использовать SVG XML, чтобы рисовать и заполнять виджеты "звездного рейтинга". Это работало нормально, пока я не разместил около 20 экземпляров на странице, а затем некоторые из них случайным образом исчезли и/или мерцали при наведении курсора мыши.

3) Использование фонового изображения в раскрывающемся меню. Изображение не загружается до щелчка по всплывающему окну, что создает заметно медленное время загрузки для пользователей при медленных соединениях. Хотя общее время точно такое же, где бы вы не помещали изображение, пользователи заметили его больше, когда время загрузки было после нажатия. Поэтому я осторожно разбираюсь в значках в выпадающих меню.