От автора: в целом, в веб-разработке есть реальная проблема с честностью и рациональным мышлением. Есть много педантичной чепухи, которая продвигается как хорошая практика, полностью основанная на сфабрикованных «истинах», которые очень далеки от реальности. Одним из таких больших заблуждений является идея о том, что «универсальный селектор» — одиночная звездочка — медленный, сбивающий с толку, трудный для понимания, и я даже видел, как некоторые люди называли его откровенным злом.
Честно говоря, это полный бред. На самом деле, у меня есть сильнее выражения по этому поводу, но я постараюсь вести себя более сдержанно. Недавно я добавил это в свои посты:
*, *:after, *:before { box-sizing:border-box; }… поскольку я всегда считал, что модель «отступы внутри ширины» имеет больше смысла, даже когда Internet Explorer неправильно реагировал на это. Не в первой я в чем-то не согласен с W3C.
Тем не менее, почти сразу дюжина разных разработчиков потеряли рассудок во всех смыслах и целях, крича: «Не используйте этот селектор таким образом, он медленный и сбивает с толку!»
Как и в случае с другими такими безумными бессмысленными утверждениями, как «селекторы тегов и комбинаторы медленные, вместо этого используйте классы во всем», я подозреваю, что причина кроется в типе мышления, присущего для неспециалистов, когда хорошо звучащие заблуждения принимаются за истину. Как я писал в одной из своих предыдущих статей: люди часто берут выражение «избегайте X в случае Y» и волшебным образом превращают его в «Никогда не используйте X!!!».
Давайте разберемся, что это такое, почему люди думают, что это плохо, почему такое мышление неправильно, а затем докажем это с помощью некоторого тестирования.
Так что же такое универсальный селектор?
В CSS для обозначения «Все» используется звездочка. Так же, как и на последнем уровне с именами файлов. Например:
* { color:red; }Делает ВСЕ элементы HTML красными. Его также можно использовать как дочерний селектор:
main > * { flex:1 0 auto; }В этом случае все прямые дочерние элементы (что > делает в CSS) из <main> будут увеличиваться, а не уменьшаться по отношению к остальным флекс элементам, и автоматически определять их оптимальную ширину.
Вот и все, что он делает. Это буквально то, что в компьютерных файловых системах называется «подстановочным знаком».
Почему люди думают, что это неправильно?
Люди, кажется, думают, что, поскольку селектор применяется ко всем элементам, он… ну, применим ко всему, что используется или нет. Применять ко всему занимает больше времени, не так ли? Имеет смысл, правда?
Что не так в этом предположении?
Альтернатива конкретно указывает, где именно применять и по мере какой необходимости. Это включает в себя написание большего количества кода, который часто повторяется повсюду, и требует БОЛЬШЕ внутренней логики, чтобы сказать: «Это нужно этой конкретной вещи».
Что проще? Просто применять ко всему без тестирования или проходить сравнения / тесты — что в любом случае выполняется на этапе применения CSS — в каждом конкретном случае действительно определить, следует ли применять значение? Сравнение занимает больше времени, чем просто «делать это всегда».
Я сравниваю этот тип ошибочного мышления с тем, как люди думают, что воздух, выходящий из нижней части воздушного шара или ракеты — это то, что толкает их вперед, хотя это факт, что он НЕ толкает что-либо, что находится в движении. Расширяющийся воздух под давлением внутри него толкает в другом направлении — вот что толкает объект вперед.
Также можно ограничить то, что он ищет, с помощью смежных комбинаторов и дочерних комбинаторов. Например, если у нас есть раздел, в котором мы знаем, что все, что находится после <H2>, требует верхнего отступа:
h2 ~ * { padding-top:1.5em; }Это простое прямое дочернее присвоение, мы ограничили его область поиска, поэтому нет причин, по которым это будет медленнее, чем использование классов для всего, что находится после H2, или даже указание тегов, которые могут быть там:
h2 ~ p,
h2 ~ ul,
h2 ~ ol,
h2 ~ table,
h2 ~ footer { padding-top:1.5em; }Во всяком случае, это, вероятно, быстрее, потому что меньше кода и меньше правил!
ДОКАЖИТЕ ЭТО!
Как часто говорят, докажи или замолчи. Я создал два HTML-файла из 5 абзацев lorem ipsum, которые повторяются 500 раз. В одном из них мы воспользуемся универсальным селектором, чтобы сбросить поля, отступы и установить размеры блока до границ. В другом случае мы можем пойти дальше и вручную указать на все соответствующие элементы поименно. В обоих случаях мы сравним p: nth-of-type с h1 + *:nth-of-type что должно помочь «сбить с толку» сложные комбинаторы.
CSS будет встроен в разметку, чтобы исключить возможную причину квитирования. Тест будет запущен на изолированном VPS, который используется только для тестирования, и на котором больше ничего не работает. И оценка будет проводиться с использованием инструментов оценки производительности Google Lighthouse и Chrome.
Вы можете скачать мои тестовые файлы здесь. Два теста в Lighthouse почти неотличимы друг от друга.
Единственная реальная разница между этими двумя тестами заключается в том, что каждые два из трех запусков универсального теста не показывает время блокировки, но иногда показывает 0,9 с LCP. Тогда как при каждом запуске «нормальная» версия показывает, что время блокировки составляет 40 мс, но в остальном на 100% соответствует всем остальным параметрам. Учитывая отсутствие детализации в оценке Lighthouse, это можно считать пределом погрешности.
Учитывая то, что показал Lighthouse, графики производительности меня удивили.
Разница в рендеринге огромна, и при нескольких прогонах эти значения, казалось, были последовательными. То, что версия универсального селектора постоянно работает примерно на 40 мс быстрее, может быть связано с тем, что вызывает «блокировку» в обычной версии. В этом случае очевидно, что универсальный подход к одному и тому же примеру на самом деле БЫСТРЕЕ.
Но даже если мы будем рассматривать это как евангелие, в документе размером 2500 абзацев с использованием 273 тыс. сложных селекторов и комбинаторов разница составляет жалкие 40 мс. Даже если бы это было наоборот, число настолько незначительно, что не имеет значения!
В пользу того, что я думал об утверждении… применение универсального способа должно быть быстрее и проще, чем при подходе с разными селекторами.
Ради интереса я добавил третий тест, использующий дерзкий подход «давайте вставим классы для всего», просто чтобы высмеять этих болтунов. Я не буду тратить время на отчет Lighthouse. Скажем так, было 0,8 стало 0,9. График производительности:
… говорит все, что нам нужно знать о сказочном утверждении, что применение классов везде, где только можно, как-то волшебным образом быстрее, чище или лучше, чем просто использование селекторов и комбинаторов. Это только еще больше усиливает сказанное мной в предыдущей статье! И почему я считаю, что все интерфейсные фреймворки — мусор, а всякие BEM — ерунда.
Черт, это так плохо, что можно подумать, что кода на 30 тысяч символов больше или что-то в этом роде. Совет: если кто-то говорит вам, что большее количество HTML сделает вашу страницу «быстрее» или «проще в обслуживании», они, скорее всего, говорят ерунду.
Заключение
Я подозреваю, что эти утверждения о «пороках» универсального селектора исходили от какого-то «громкого имени» в отрасли, которое открыто выражало свое мнение — я, вероятно, даже знаю, кто — и все просто слепо повторяли утверждение, не проверяя и даже не задумываясь о нем.
Нет никаких доказательств, подтверждающих утверждение, что универсальный селектор в чем-то «плох», поэтому, если у вас представится случай использования, в котором он имеет смысл… знаете что? Берите и используйте его.
Автор: Jason Knight
Источник: levelup.gitconnected.com
Редакция: Команда webformyself.