Comments 8
Отличная статья! А может что нибудь посоветуете в плане JS? Ну, например, открываем страницу с большим количеством JS и как понять, что сколько времени выполняется. Для современных 2.0 сайтов актуально.
+5
В том же Chrome developer tools есть профайлинг js.
Рекомендую к просмотру discover-devtools.codeschool.com/
Рекомендую к просмотру discover-devtools.codeschool.com/
+1
Спасибо.
Для начала можно начать с анализа timing'a страницы и профилирования CPU через devtools. А потом можно посмотреть в chrome://tracing используя при записи пункт «Javascript and rendering».
Для начала можно начать с анализа timing'a страницы и профилирования CPU через devtools. А потом можно посмотреть в chrome://tracing используя при записи пункт «Javascript and rendering».
+3
i.imgur.com/4jpsfvE.png
Почему-то именно в вашем блоге на хабре дикие лаги. Наблюдаю больше недели точно. Хотел пройтись по пунктам статьи, но выяснилось, что:
1) проблемы только в первой открытой вкладке,
2) когда первая закрывается, то начинает лагать вторая,
3) ситуацию меняет магическим образом изменение размеров окна.
После 3го пункта пока не могу воспроизвести ситуацию.
Почему-то именно в вашем блоге на хабре дикие лаги. Наблюдаю больше недели точно. Хотел пройтись по пунктам статьи, но выяснилось, что:
1) проблемы только в первой открытой вкладке,
2) когда первая закрывается, то начинает лагать вторая,
3) ситуацию меняет магическим образом изменение размеров окна.
После 3го пункта пока не могу воспроизвести ситуацию.
0
Спасибо за интересный обзор. В свою очередь хотел бы отметить следующее.
В целом «притормаживание скролла» указывает на другую проблему, а именно композиция слоёв (layer compositing). Так как сегодня практически все браузеры используют GPU для отрисовки некоторых вещей, а отовсюду слышится «ставь
Если коротко, то в браузерах (как минимум на базе WebKit и Blink) есть набор триггеров, которые переносят некоторые слои на отдельную поверхность на GPU (в терминах Blink это перенос RenderLayer на свой GraphicsLayer). Эти триггеры могут быть как явно указаными у слоя (тот же
Вынос на GPU, помимо каких-то внутренних процессов, как правило сопровождается полной перерисовкой слоя, поэтому иногда можно наблюдать всякие «моргания» и прочие артефакты. На GPU такие слои фактически становятся текстурой на плоскости, которой удобно (а самое главное — очень дёшево) можно применять различные 3D-трансформации. Но тут есть один очень важный нюанс: если хотя бы один пиксель текстуры поменяется (например, на ховер, анимацию, что-то ещё) — её нужно заново перерисовать. Это очень сильно заметно, например, в WebKit на iOS. Соответственно, неумелое использование GPU-триггеров для «ускорения» страницы может на самом деле привести к очень серьёзным тормозам.
Из всего вышесказанного конкретно для вашей ситуации: скорее всего, источник проблемы не в самом
Дебажить такие вещи очень удобно Safari Web Inspector: там есть отдельная панелька Layers, которая для выделенного элемента показывает, какие слои вынесены на GPU и, что особенно важно, причину такого выноса. Лично я уже нескольким ребятам помог сильно оптимизировать производительность с помощью этого инструмента, особенно для мобилок :)
Чуть подробнее об этом можно почитать тут: www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
В целом «притормаживание скролла» указывает на другую проблему, а именно композиция слоёв (layer compositing). Так как сегодня практически все браузеры используют GPU для отрисовки некоторых вещей, а отовсюду слышится «ставь
translateZ(0)
чтобы быстро и плавно всё» эта проблема становится очень актуальной.Если коротко, то в браузерах (как минимум на базе WebKit и Blink) есть набор триггеров, которые переносят некоторые слои на отдельную поверхность на GPU (в терминах Blink это перенос RenderLayer на свой GraphicsLayer). Эти триггеры могут быть как явно указаными у слоя (тот же
translateZ(0)
, CSS-анимации на transform
и opacity
), так и косвенными, например, не-GPU слой по z-index’у находится выше GPU-слоя и их границы пересекаются.Вынос на GPU, помимо каких-то внутренних процессов, как правило сопровождается полной перерисовкой слоя, поэтому иногда можно наблюдать всякие «моргания» и прочие артефакты. На GPU такие слои фактически становятся текстурой на плоскости, которой удобно (а самое главное — очень дёшево) можно применять различные 3D-трансформации. Но тут есть один очень важный нюанс: если хотя бы один пиксель текстуры поменяется (например, на ховер, анимацию, что-то ещё) — её нужно заново перерисовать. Это очень сильно заметно, например, в WebKit на iOS. Соответственно, неумелое использование GPU-триггеров для «ускорения» страницы может на самом деле привести к очень серьёзным тормозам.
Из всего вышесказанного конкретно для вашей ситуации: скорее всего, источник проблемы не в самом
box-shadow
, а в неправильной композиции, которая вызывает неявный вынос на GPU ненужных слоёв и, соответственно, перерисовку тени. Потому что при правильной композиции можно обвешаться различными эффектами и ничего не будет тормозить. Наверняка при включении “Show paint rectangles” вы наблюдали, что область перерисовки занимает всю станицу, хотя по-хорошему так быть не должно.Дебажить такие вещи очень удобно Safari Web Inspector: там есть отдельная панелька Layers, которая для выделенного элемента показывает, какие слои вынесены на GPU и, что особенно важно, причину такого выноса. Лично я уже нескольким ребятам помог сильно оптимизировать производительность с помощью этого инструмента, особенно для мобилок :)
Чуть подробнее об этом можно почитать тут: www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
+22
Sign up to leave a comment.
Анализ рендеринга через Skia Debugger: как можно найти самые дорогие для отрисовки элементы