С чем связаны проблемы производительности CSS?

Что проверяют

Знаете ли вы конвейер рендеринга и понимаете ли, что дорого в нём на самом деле. Вопрос хорошо делит людей: одни пересказывают советы про селекторы, другие говорят про раскладку, отрисовку и композицию, и про то, как это видно в профайлере.

Как отвечать

Разложите на три стадии.

Загрузка: таблица стилей блокирует первую отрисовку, поэтому важны размер бандла, критические стили прямо в разметке и отказ от @import внутри CSS, который выстраивает запросы в цепочку вместо параллельной загрузки. Неиспользуемые правила видно во вкладке Coverage.

Стили и раскладка: подбор селекторов на современных движках редко становится узким местом, а вот принудительная синхронная раскладка становится всегда. Это чтение offsetHeight или getBoundingClientRect сразу после записи стилей в цикле: браузер вынужден пересчитывать дерево на каждой итерации. Лечится разделением чтения и записи, а тяжёлые куски отсекаются через content-visibility и contain.

Отрисовка и композиция: анимировать стоит transform и opacity, они не требуют пересчёта раскладки. Анимация width, top или margin дёргает весь конвейер. Дорого стоят большое размытие в box-shadow, filter и особенно backdrop-filter.

.card { transition: transform .2s ease; }

Где спотыкаются

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

Второе: раздают will-change всем элементам подряд, считая это бесплатным ускорением. Каждый слой занимает память видеокарты, и на телефоне лишние слои дают ровно обратный эффект.

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