Вопрос о производительности CSS
Возможно, путаница между линеаризуемостью и сериализуемостью.
Линеаризуемость является гарантией отдельных операций над отдельными объектами [...] Линеаризуемость для чтения и записи Операции синонимичны с термином «атомная согласованность» и являются «С» или «согласованностью» в доказательстве Гилберта и Линча теоремы CAP.
Сериализуемость - это гарантия транзакций или групп из одной или нескольких операций над одним или несколькими объектами. Это гарантирует, что выполнение набора транзакций (обычно содержащих операции чтения и записи) над несколькими элементами эквивалентно некоторому последовательному выполнению (полному упорядочению) транзакций [...] Сериализуемость - это традиционное «I» или изоляция, в кислоте.
8 ответов
В документации по Google Page Speed есть раздел об использовании эффективных селекторов CSS . В нем упоминается, что селекторы-потомки неэффективны, потому что после сопоставления крайнего правого селектора «браузер должен [также] пройти вверх по дереву DOM, оценивая каждый элемент-предок, пока не найдет совпадение или не достигнет корневого элемента». Mozilla даже говорит «селектор потомков - самый дорогой селектор в CSS». Так что div.photo-column {...} будет предпочтительнее, чем div.result- строка div.photo-column {...} .
В нем также упоминается, что вам следует удалить избыточные квалификаторы, такие как «селекторы классов, определяемые селекторами тегов (когда класс используется только для одного тега, что в любом случае является хорошей практикой проектирования)». Это имеет смысл, потому что если у вас есть div.photo-column {...} вместо .photo-column {...} , браузер должен выполнить две проверки, одну для проверьте class = "photo-column" и, если это правда, один, чтобы проверить, является ли элемент div, а не просто проверять класс, если это все, что вы указываете.
Это должно влиять только на размер файла и, следовательно, на время загрузки.
Хороший способ сделать это - сделать CSS как можно более читабельным во время разработки (используя столько селекторов, сколько необходимо для этого), но когда вы запускаете сайт в прямом эфире, удалите ненужные селекторы и сожмите их.
в разработке
div.result-row{...}
div.result-row div.photo-column{...}
div.result-row div.main-column{...}
div.result-row div.main-column div.text-row{}
div.result-row div.main-column div.date-row{}
div.result-row div.action-column{...}
live
.result-row{...}.photo-column{...}.main-column{...}.text-row{}.date-row{}.action-column{...}
EDIT
После прочтения некоторых комментариев на этой странице имеет смысл использовать сложные селекторы могут повлиять на время рендеринга. Судя по результатам тестов, которые я читал, время загрузки настолько мало, что его не будет заметно, но похоже, что оно действительно влияет на него.
Это все равно не должно влиять на прокрутку.
Прочтите это :
http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/ http://code.google.com/speed/page-speed / docs / рендеринг. html # UseEfficientCSSSelectors https://developer.mozilla.org/en/Writing_Efficient_CSS
Будьте осторожны. Удаление и добавление области действия для ваших селекторов изменяет приоритет правил и может привести к неожиданным результатам в вашей продукции.
Минификация переоценена. Современные, хорошо настроенные веб-серверы будут отправлять gzip-код CSS, который очень эффективно удаляет пробелы и повторяющиеся слова. Прирост производительности в несколько килобайт на файл CSS незаметен для людей, использующих что-либо более быстрое, чем модем 56k. Напротив, одно изображение JPEG размером 100x100 пикселей может легко потреблять больше трафика, чем ваши файлы CSS и JS вместе взятые.
В сочетании с кешированием это в значительной степени делает необходимость оптимизации размера CSS избыточной или, по крайней мере, гораздо менее важной, чем поддержание вашего кода в сопровождении.
Что касается того, как это влияет на скорость рендеринга, я не знаю,
Удаление имен тегов ничего не даст, кроме экономии нескольких байтов от размера файла. Я считаю, что нотация elm.className более понятна, чем просто добавление туда селекторов, содержащих только имена классов. Не говоря уже о том, что удаление тегов изменит уровень специфичности этого правила. Для сложных (или плохо написанных) макетов CSS это может иметь очень необычные последствия. Прирост производительности будет ограничен несколькими дополнительными символами, которые синтаксический анализатор CSS не должен читать, что будет незаметно.
CSS не приведет к медленной прокрутке. Что может, так это фиксированный фон (через background-attachment: fixed ). По своему опыту я заметил, что они, как правило, замедляют работу браузера при прокрутке, так что это наиболее вероятная вещь. Если вы не используете ни один из них, просто убедитесь, что вы не используете огромные фоновые изображения.
Все правила CSS применяются при загрузке страницы. Когда пользователь перемещается по странице, CSS уже сделал свою работу.
Не совсем уверен, что ответ Галена на 100% правильный. Есть пара хороших статей с тестами производительности с другим выводом « Влияние CSS-селекторов на производительность ». Однако в большинстве реальных случаев вы не заметите никакой разницы, и поэтому возможная выгода не стоит затраченных усилий.
Плохой CSS определенно может повлиять на рендеринг, однако я не верю, что он повлияет на прокрутку после рендеринга. В вашем примере, по крайней мере, избегайте селекторов на 3 уровня. Одноуровневые селекторы CSS будут быстрее, чем двухуровневые селекторы. Ввод типа тега должен ускорить процесс выбора, потому что вместо сопоставления * .class в вашем документе DOM он должен только соответствовать div.class, фильтруя тип узлов dom, для которых вы должны искать класс.