Производительность дочернего селектора CSS против раздувания классов

18

Я пытаюсь научиться писать более эффективный CSS, особенно потому, что работаю с довольно сложным сайтом, который нужно быстро рендерить.

Я привык иметь много этого в моем HTML / CSS (в основном потому, что мне нравится удобочитаемость):

.spotlight {}
.spotlight ul {}
.spotlight ul li {}
.spotlight ul li a {color: #333;}

<div class="spotlight">
  <ul>
    <li><a href="">link</a></li>
    <li><a href="">link</a></li>
    <li><a href="">link</a></li>
  </ul>
</div>

Теперь я понимаю, что браузеры запускают процесс сопоставления правил CSS справа налево, это означает, что элемент <a> в последнем вышеприведенном правиле CSS сначала будет соответствовать каждой ссылке на странице, что приведет к снижению производительности.

Итак, из того, что я понял, решение для браузера было бы более конкретным и использовало, например:

.spotlight {}
.spotlight-link {color: #333;}

    <div class="spotlight">
      <ul>
        <li><a class="spotlight-link" href="">link</a></li>
        <li><a class="spotlight-link" href="">link</a></li>
        <li><a class="spotlight-link" href="">link</a></li>
      </ul>
    </div>

(при условии, что я использую наследование, где это возможно, но часто по-прежнему требуется особый контроль над последним элементом в дереве)

Что вызывает у меня сомнение: разве все лишнее раздувание HTML, возникающее при печати имен классов на элементах по всей странице, не сводит на нет прирост производительности, достигнутый благодаря отказу от вложенных дочерних селекторов CSS? Я привык пытаться писать меньше HTML, и это противоречит этому. Любое понимание будет оценено.

    
задан Tom 23.12.2012 в 19:36
источник
  • Причины (на практике), что селекционеры-потомки обычно избегают, - это не производительность, а CSS-область / обслуживание (трудно объяснить в комментарии). Браузеры очень быстро разбираются в CSS, я бы серьезно не беспокоился об этом. Если вы действительно обеспокоены скоростью, а не обслуживанием, вы можете использовать одиночные имена классов символов <- не одобрение. –  Wesley Murch 23.12.2012 в 19:44
  • @Wesley Murch: «Причины (на практике), что селекционеры-потомки обычно избегают, - это не производительность, а CSS-область / обслуживание« К сожалению, это не то, что они хотели бы, чтобы вы думали ... –  BoltClock♦ 23.12.2012 в 22:53
  • "не все ли лишнее раздувание HTML от печати имен классов на элементах всей страницы отрицают выигрыши в производительности, связанные с предотвращением вложенных селекторов дочерних CSS?" В точку. На самом деле нет смысла раздувать все ваши HTTP-запросы ради производительности на стороне клиента. –  BoltClock♦ 23.12.2012 в 22:56
  • Для записи статья Mozilla изначально была предназначена для стилизации собственного пользовательского интерфейса, где производительность на стороне клиента, по понятным причинам, имеет первостепенное значение. Я не могу вынести никаких дискриминационных обобщений, которые они делают против определенных селекционеров. Комбинаторы потомков существуют уже почти 20 лет; если через 20 лет браузеры по-прежнему сталкиваются с трудностями в их сопоставлении, то что-то очень, очень неправильно. Это глупо. –  BoltClock♦ 23.12.2012 в 23:18
  • Я просто избегаю JavaScript, CSS и HTML вообще - они ужасно плохи для производительности. О, и не заставляйте меня начинать с изображений ... –  Wesley Murch 23.12.2012 в 23:21
Показать остальные комментарии

2 ответа

12

Вы должны взвесить это. Добавление класса к каждому якору смешно, лишняя разметка в HTML значительно компенсировала бы сэкономленное время рендеринга (которое составляло бы 1/10 000 тысяч ноги пчелы). Не говоря уже о том, как трудно будет поддерживать ваш код.

Вам просто нужно прекратить использовать излишне дорогие селекторы, например

.spotlight ul li a

Может быть написано как

.spotlight a

Если вы продолжите указывать один класс для одних и тех же элементов в вашем HTML (как во втором примере), вам, вероятно, будет лучше использовать вместо этого селектор тегов.

Вы также должны взвешивать свое время и время браузеров. Сколько будет стоить в ваше время сэкономить несколько наносекунд на каждой загрузке страницы? Честно говоря, это действительно не стоит.

Кроме того, приведение вашей структуры CSS в соответствие с вашей структурой HTML сводит на нет смысл CSS - если HTML меняется, вам нужно изменить свой CSS. Таким образом, вы всегда хотите, чтобы ваши селекторы были как можно более неопределенными.

Но здесь нет правильного или неправильного ответа.

    
ответ дан Christian Varga 23.12.2012 в 19:41
3

Я думаю, что лучший компромисс - использование дочернего комбинатора > для элементов, которые повторяются много раз, и использование классов, когда вещи начинают становиться слишком вложенными.

Изменение правил БЭМ

Приведенная выше статья, как мне кажется, обеспечивает идеальный баланс, учитывая наши варианты.

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

.header__nav {
  > ul {
    > li {
      > a {}
    }
  }
}
    
ответ дан dalgard 06.02.2014 в 12:30