Comments 8
Отличная статья! А может что нибудь посоветуете в плане JS? Ну, например, открываем страницу с большим количеством JS и как понять, что сколько времени выполняется. Для современных 2.0 сайтов актуально.
В том же Chrome developer tools есть профайлинг js.
Рекомендую к просмотру discover-devtools.codeschool.com/
Рекомендую к просмотру discover-devtools.codeschool.com/
Спасибо.
Для начала можно начать с анализа timing'a страницы и профилирования CPU через devtools. А потом можно посмотреть в chrome://tracing используя при записи пункт «Javascript and rendering».
Для начала можно начать с анализа timing'a страницы и профилирования CPU через devtools. А потом можно посмотреть в chrome://tracing используя при записи пункт «Javascript and rendering».
i.imgur.com/4jpsfvE.png
Почему-то именно в вашем блоге на хабре дикие лаги. Наблюдаю больше недели точно. Хотел пройтись по пунктам статьи, но выяснилось, что:
1) проблемы только в первой открытой вкладке,
2) когда первая закрывается, то начинает лагать вторая,
3) ситуацию меняет магическим образом изменение размеров окна.
После 3го пункта пока не могу воспроизвести ситуацию.
Почему-то именно в вашем блоге на хабре дикие лаги. Наблюдаю больше недели точно. Хотел пройтись по пунктам статьи, но выяснилось, что:
1) проблемы только в первой открытой вкладке,
2) когда первая закрывается, то начинает лагать вторая,
3) ситуацию меняет магическим образом изменение размеров окна.
После 3го пункта пока не могу воспроизвести ситуацию.
Спасибо за интересный обзор. В свою очередь хотел бы отметить следующее.
В целом «притормаживание скролла» указывает на другую проблему, а именно композиция слоёв (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
Sign up to leave a comment.
Анализ рендеринга через Skia Debugger: как можно найти самые дорогие для отрисовки элементы