Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 42
How browsers work есть на русском, если что. Даже была статья на Хабре.
В этом аспекте я, признаться, допустил оплошность — в действительности будет так:
Привычка к инкапсуляции уже работает на автомате. Дополнил этот пункт в статье, спасибо за замечание!
.list-item {...} // хорошо
#list-1 .list-item {...} // немного медленнее, т.к. ключевой селектор совпадает с предыдущим стилем, но добавлена вложенность
Привычка к инкапсуляции уже работает на автомате. Дополнил этот пункт в статье, спасибо за замечание!
#list-1 .list-item {...} // идеально
#list-1 > .list-item {...} // ещё идеальнее
css селекторы по id — никогда не было идеальным. Это примерно как goto, использовать можно, но не нужно, пусть хоть и незначительно быстрее.
Каскадность и идентификаторы в качестве селекторов — это ни разу не идеально, а плохо.
Тем не менее, каскад до трёх элементов можно допустить, но только в случае особой необходимости. В остальных случаях это bad practice.
Тем не менее, каскад до трёх элементов можно допустить, но только в случае особой необходимости. В остальных случаях это bad practice.
#list-1 .list-item {...} // идеально
А почему идеально? Разве браузер будет разбирать это слева направо?
Да, вы правы, браузер обрабатывает css справа налево, и идеальным с точки зрения производительности этот вариант назвать нельзя. Дал более развёрнутый ответ выше.
Интересно, почему универсальный селектор (*), работает быстрее селектора по аттрибуту или псевдоэлементов?
По логике, он должен быть самым медленным.
По логике, он должен быть самым медленным.
Подобные статьи летают из блога в блог, но существуют тесты которые подтверждают пользу от такой оптимизации для современных браузеров? Речь не об искусственных тестах на абсурдно сложном DOM и тысяче селекторов по атрибуту.
Мне кажется, тут речь не о том, что нужно бежать всё оптимизировать, а о том, что нужно думать головой, когда пишешь код.
Я говорю о блоке «Практические советы по оптимизации». Сколько в этом реальной пользы?
Польза есть. Я, например, и так до этого знал, что не очень хорошо допускать высокий уровень вложенности — просто мне напомнили об этом и я стараюсь впредь следить за своим scss лучше.
Вопрос в том, станет ли большая вложенность причиной заметных тормозов на реальном проекте. Если нет, то почему это «не очень хорошо»?
Могу точно заверить, что причина падения производительности в мобильных приложениях или сайтах, на мобильных устройствах — это html и css, отнюдь не js (даже на десятки тысяч строк), как бы это могло бы показаться. Так что если отвечать на этот вопрос — да, могут стать причиной и облегчение подобных css правил вполне могут в некоторой степени ускорить работу приложения.
Небольшой оффтоп: Более того — в основном причины падения производительности — это модные css3 фишки: transition, transform, border-radius, box-shadow, rgba, filter, linear\radial-gradient и прочее. Приходится поднапрячь память и начать верстать скруглённые уголки по-старинке, пиля картиночки и расставляя их в ламповую табличку.
Небольшой оффтоп: Более того — в основном причины падения производительности — это модные css3 фишки: transition, transform, border-radius, box-shadow, rgba, filter, linear\radial-gradient и прочее. Приходится поднапрячь память и начать верстать скруглённые уголки по-старинке, пиля картиночки и расставляя их в ламповую табличку.
Cкругления — это ведь Безье + антиалиазинг, которые генерируются, а картиночки — тупо рисование поверх. При тех макетах страничек, что у нас на работе — разница видна (на замерах, глазу не особо заметно — что так тормозит, что так :D ). Но если брать целостные оптимизации (избавление от комплекса стилей) — скорость возросла заметно, раньше вообще всё еле двигалось.
Какую методику использовали для замеров? Можете вкратце описать?
Weinre + Timeline
Ага, спс. А я вот как раз подумывал о Performance Log из Chromedriver2.
Про «модные css3 фишки» я в курсе (border-radius к ним бы точно не относил), но вот селекторы… как по мне это экономия на спичках. Особенно на мобильных сайтах, там DOM как правило небольшой.
Да, я ответил выше, что хоть скругления — это такие же мелочи, как и использование id, вместо классов, но комплексное решение — действительно ускоряет (тем более при наличии должного самописного миксина в scss для подобных нужд — это делается с пол пинка).
Со скруглениями мороки много, это же придётся ещё и под весь зоопарк dpi нарезать. Мне для этого нужны весомые аргументы)
Пока что (во время разработки) спасает background-size для изображений x2 размера — это позволяет использовать одни и те же картинки, как для retina, так и для девайсов со стандартной плотностью пикселей. Но потом, конечно можно заменить на размеры 1 к 1 для ускорения (масштабирование тоже откушивает довольно сильно).
Буквально только сегодня набросал: pastebin.com/jqs95q2C но для идеального решения — проще проставлять общий класс ".sprite-x1\.sprite-x2" в html\body тегах и от него отталкиваться при отображении изображений из спрайтов =) Вот
Буквально только сегодня набросал: pastebin.com/jqs95q2C но для идеального решения — проще проставлять общий класс ".sprite-x1\.sprite-x2" в html\body тегах и от него отталкиваться при отображении изображений из спрайтов =) Вот
Не думаю что получится добиться идеального результата, границы всё равно будут «мылить», особенно при зуме. Градиентов это тоже касается.
Согласен, с другой стороны не всё так плохо, как могло бы быть при ресайзе с увеличением (размытием пикселей).
Ниже скрин андроида с двухкратным уменьшением (на айфончиках всё было бы 1к1):
Ниже скрин андроида с двухкратным уменьшением (на айфончиках всё было бы 1к1):
Скрытый текст
картинками:
— иконка с человечком
— тёмно-красная полосочка ниже (она из двух картиночек)
— красная полосочка с засечками ещё ниже (она состоит из 3х картиночек)
— иконка с кулаком
предлагаю открыть на девайсе и понять, что не особо всё страшно.
— иконка с человечком
— тёмно-красная полосочка ниже (она из двух картиночек)
— красная полосочка с засечками ещё ниже (она состоит из 3х картиночек)
— иконка с кулаком
предлагаю открыть на девайсе и понять, что не особо всё страшно.
Подтверждение от гитхаб speakerdeck.com/jonrohan/githubs-css-performance
Избавление от вложенности даёт не столько выигрыш в производительности, сколько удобство будущей поддержки – если у вас изменится DOM, например, меню из заголовка куда-то подвинули, не надо будет переписывать все селекторы типа .head .menu .list .item {…}
А на чем, собственно, базируются доводы из статьи и скорости работы с селекторами?
Интереса ради решил проверить, получилось вот что:
В первом столбце показывается время отработки селектора из второго столбца в миллисекундах. Поиск происходил по 100000 элементов «div» в body, при 100 итерациях на каждом селекторе.
Пример скрипта (результат выведется в консоль браузера, поддерживающего console.table()) (количество итераций уменьшено до 10000).
Как видно из таблицы скорость отработки различных селекторов по отношению друг к другу не совпадает с той, что указана в статье.
Интереса ради решил проверить, получилось вот что:
В первом столбце показывается время отработки селектора из второго столбца в миллисекундах. Поиск происходил по 100000 элементов «div» в body, при 100 итерациях на каждом селекторе.
Пример скрипта (результат выведется в консоль браузера, поддерживающего console.table()) (количество итераций уменьшено до 10000).
Как видно из таблицы скорость отработки различных селекторов по отношению друг к другу не совпадает с той, что указана в статье.
Небольшая поправка. Количество итераций — 100, а количество элементов, среди которых происходит поиск — 100000 в таблице, и 10000 в примере.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рендеринг WEB-страницы: что об этом должен знать front-end разработчик