Комментарии 42
НЛО прилетело и опубликовало эту надпись здесь
В этом аспекте я, признаться, допустил оплошность — в действительности будет так:
.list-item {...} // хорошо
#list-1 .list-item {...} // немного медленнее, т.к. ключевой селектор совпадает с предыдущим стилем, но добавлена вложенность

Привычка к инкапсуляции уже работает на автомате. Дополнил этот пункт в статье, спасибо за замечание!
#list-1 .list-item {...} // идеально
#list-1 > .list-item {...} // ещё идеальнее
css селекторы по id — никогда не было идеальным. Это примерно как goto, использовать можно, но не нужно, пусть хоть и незначительно быстрее.
Каскадность и идентификаторы в качестве селекторов — это ни разу не идеально, а плохо.
Тем не менее, каскад до трёх элементов можно допустить, но только в случае особой необходимости. В остальных случаях это bad practice.
#list-1 .list-item {...} // идеально

А почему идеально? Разве браузер будет разбирать это слева направо?
Интересно, почему универсальный селектор (*), работает быстрее селектора по аттрибуту или псевдоэлементов?
По логике, он должен быть самым медленным.
Ну как, звездочка выбирает все элементы вниз по дереву. Селектор по аттрибуту делает то же самое, но еще проверяет аттрибут у каждого найденного элемента — в два раза больше необходимых действий даже не зная алгоритмов селекции.
В данном случае речь именно про селектор, т.е. поиск элементов, а не про какие-либо изменения в стилях.
Подобные статьи летают из блога в блог, но существуют тесты которые подтверждают пользу от такой оптимизации для современных браузеров? Речь не об искусственных тестах на абсурдно сложном DOM и тысяче селекторов по атрибуту.
Мне кажется, тут речь не о том, что нужно бежать всё оптимизировать, а о том, что нужно думать головой, когда пишешь код.
Я говорю о блоке «Практические советы по оптимизации». Сколько в этом реальной пользы?
Польза есть. Я, например, и так до этого знал, что не очень хорошо допускать высокий уровень вложенности — просто мне напомнили об этом и я стараюсь впредь следить за своим scss лучше.
Вопрос в том, станет ли большая вложенность причиной заметных тормозов на реальном проекте. Если нет, то почему это «не очень хорошо»?
Могу точно заверить, что причина падения производительности в мобильных приложениях или сайтах, на мобильных устройствах — это html и css, отнюдь не js (даже на десятки тысяч строк), как бы это могло бы показаться. Так что если отвечать на этот вопрос — да, могут стать причиной и облегчение подобных css правил вполне могут в некоторой степени ускорить работу приложения.

Небольшой оффтоп: Более того — в основном причины падения производительности — это модные css3 фишки: transition, transform, border-radius, box-shadow, rgba, filter, linear\radial-gradient и прочее. Приходится поднапрячь память и начать верстать скруглённые уголки по-старинке, пиля картиночки и расставляя их в ламповую табличку.
НЛО прилетело и опубликовало эту надпись здесь
Cкругления — это ведь Безье + антиалиазинг, которые генерируются, а картиночки — тупо рисование поверх. При тех макетах страничек, что у нас на работе — разница видна (на замерах, глазу не особо заметно — что так тормозит, что так :D ). Но если брать целостные оптимизации (избавление от комплекса стилей) — скорость возросла заметно, раньше вообще всё еле двигалось.
НЛО прилетело и опубликовало эту надпись здесь
Помнится на хабре уже были замеры по этому поводу и более-менее сложный SVG бывало тормозил даже в обычных браузерах, уж я не говорю про мобильные.
Какую методику использовали для замеров? Можете вкратце описать?
Про «модные css3 фишки» я в курсе (border-radius к ним бы точно не относил), но вот селекторы… как по мне это экономия на спичках. Особенно на мобильных сайтах, там DOM как правило небольшой.
Да, я ответил выше, что хоть скругления — это такие же мелочи, как и использование id, вместо классов, но комплексное решение — действительно ускоряет (тем более при наличии должного самописного миксина в scss для подобных нужд — это делается с пол пинка).
Со скруглениями мороки много, это же придётся ещё и под весь зоопарк dpi нарезать. Мне для этого нужны весомые аргументы)
Пока что (во время разработки) спасает background-size для изображений x2 размера — это позволяет использовать одни и те же картинки, как для retina, так и для девайсов со стандартной плотностью пикселей. Но потом, конечно можно заменить на размеры 1 к 1 для ускорения (масштабирование тоже откушивает довольно сильно).

Буквально только сегодня набросал: pastebin.com/jqs95q2C но для идеального решения — проще проставлять общий класс ".sprite-x1\.sprite-x2" в html\body тегах и от него отталкиваться при отображении изображений из спрайтов =) Вот
Не думаю что получится добиться идеального результата, границы всё равно будут «мылить», особенно при зуме. Градиентов это тоже касается.
Согласен, с другой стороны не всё так плохо, как могло бы быть при ресайзе с увеличением (размытием пикселей).

Ниже скрин андроида с двухкратным уменьшением (на айфончиках всё было бы 1к1):
Скрытый текст
картинками:
— иконка с человечком
— тёмно-красная полосочка ниже (она из двух картиночек)
— красная полосочка с засечками ещё ниже (она состоит из 3х картиночек)
— иконка с кулаком


предлагаю открыть на девайсе и понять, что не особо всё страшно.

Избавление от вложенности даёт не столько выигрыш в производительности, сколько удобство будущей поддержки – если у вас изменится DOM, например, меню из заголовка куда-то подвинули, не надо будет переписывать все селекторы типа .head .menu .list .item {…}
А на чем, собственно, базируются доводы из статьи и скорости работы с селекторами?

Интереса ради решил проверить, получилось вот что:

image

В первом столбце показывается время отработки селектора из второго столбца в миллисекундах. Поиск происходил по 100000 элементов «div» в body, при 100 итерациях на каждом селекторе.

Пример скрипта (результат выведется в консоль браузера, поддерживающего console.table()) (количество итераций уменьшено до 10000).

Как видно из таблицы скорость отработки различных селекторов по отношению друг к другу не совпадает с той, что указана в статье.
Небольшая поправка. Количество итераций — 100, а количество элементов, среди которых происходит поиск — 100000 в таблице, и 10000 в примере.
НЛО прилетело и опубликовало эту надпись здесь
Да, id уникальный, class дублировался. В итоге просто по id только один элемент нашелся, а по class'у несколько.
НЛО прилетело и опубликовало эту надпись здесь
можно попробовать и Id'ы сделать не уникальными. Браузеры их все находят, а не только один (то-есть если создать два элемента с одним ID, то .querySelectorAll() вернет оба элемента).
НЛО прилетело и опубликовало эту надпись здесь
Универсальный селектор не тормозит. Просто «querySelectorAll» находит все элементы по нему. Попробуйте изменить на «querySelector» и результат будет уже иной:

Chrome 37.0.2020.0 canary
image


Еще можно попробовать использовать псевдо-кдасс :only-of-type и т.п.
НЛО прилетело и опубликовало эту надпись здесь
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.