Повечето отговори тук се фокусират върху ефективността на селектора, сякаш това е единственото нещо, което има значение. Ще се опитам да разгледам някои любопитни факти за spriting (предупреждение за спойлер: те не винаги са добра идея), ефективността на използваната стойност на css и изобразяването на определени свойства.

Преди да стигна до отговора, позволете ми да премахна IMO: лично аз категорично не съм съгласен с заявената необходимост от „данни, базирани на доказателства“. Това просто прави твърдението за ефективност да изглежда достоверно, докато в действителност областта на машините за изобразяване е достатъчно разнородна, за да направи всяко подобно статистическо заключение неточно за измерване и непрактично за приемане или наблюдение.

Тъй като оригиналните констатации бързо остаряват, бих предпочел да видя предните разработчици да имат разбиране за основните принципи и тяхната относителна стойност спрямо точките за поддръжка/четимост - в края на краищата, преждевременната оптимизация е коренът на всяко зло ;)

Нека започнем с ефективността на селектора:

Плитките, за предпочитане едно ниво, специфични селектори се обработват по-бързо. Липсват изрични показатели за ефективност от първоначалният отговор, но ключовият момент остава: по време на изпълнение HTML документ се анализира в DOM дърво, съдържащо N елемента със средна дълбочина D и след това се прилагат общо S CSS правила. За да намалите изчислителната сложност O(N*D*S), трябва

1. Нека най-десните клавиши съвпадат с възможно най-малко елементи - селекторите се съпоставят отдясно наляво^ за допустимост на индивидуално правило, така че ако най-десният ключ не съвпада с определен елемент, няма нужда от допълнителна обработка на селектора и той се отхвърля.

   Общоприето е, че селекторът * трябва да се избягва, но тази точка трябва да се разгледа допълнително. „Нормалното“ нулиране на CSS всъщност съответства на повечето елементи – когато тази SO страница е профилирана, нулирането е отговорно за около 1/3 от цялото време за съвпадение на селектора, така че може да предпочетете normalize.css (все пак, това добавя само до 3,5ms - точката срещу преждевременната оптимизация стои силно)

2. Избягвайте селектори на наследници, тъй като те изискват до ~D елемента да бъдат итерирани. Това засяга основно потвържденията на несъответствията - например положителното .container .content съвпадение може да изисква само една стъпка за елементи във връзка родител-дете, но DOM дървото ще трябва да бъде обходено до html, преди да може да бъде потвърдено отрицателно съвпадение.

3. Намалете до минимум броя на DOM елементите, тъй като техните стилове се прилагат индивидуално (заслужава да се отбележи, че това се компенсира от логиката на браузъра, като кеширане на референтни файлове и рециклиране на стилове от идентични елементи – например, когато стилизирате идентични братя и сестри )

4. Премахнете неизползваните правила, тъй като браузърът в крайна сметка трябва да оцени тяхната приложимост за всеки изобразен елемент. Достатъчно - най-бързото правило е това, което го няма :)

Те ще доведат до количествено измерими (но, в зависимост от страницата, не непременно осезаеми) подобрения от гледна точка на производителността на машината за изобразяване, но винаги има допълнителни фактори, като натоварване на трафика и анализ на DOM и др.

След това ефективността на свойствата на CSS3:

CSS3 ни донесе (наред с други неща) заоблени ъгли, градиенти на фона и вариации на падащи сенки - и с тях, камион с проблеми. Помислете за това, по дефиниция предварително изобразеното изображение се представя по-добре от набор от CSS3 правила, които първо трябва да бъдат изобразени. От webkit wiki:

Градиенти, сенки и други декорации в CSS трябва да се използват само когато е необходимо (напр. когато формата е динамична въз основа на съдържанието) - в противен случай статичните изображения винаги са по-бързи.

Ако това не е достатъчно лошо, градиентите и т.н. може да се наложи да се преизчисляват при всяко събитие на пребоядисване/преформатиране (повече подробности по-долу). Имайте предвид това, докато по-голямата част от потребителите не могат да разглеждат страница с много css3 като тази без забележки закъснение.

След това изпълнение на spriting:

Избягвайте високи и широки спрайтове, дори ако техният отпечатък от трафика е относително малък. Обикновено се забравя, че машината за изобразяване не може да работи с gif/jpg/png и по време на изпълнение всички графични активи се оперират като некомпресирани растерни изображения. Поне е лесно да се изчисли: ширината на този спрайт по височина по четири байта на пиксел (RGBA) е 238*1073*4≅1MB. Използвайте го върху няколко елемента в различни едновременно отворени раздели и той бързо добавя значителна стойност.

Доста екстремен случай на това е открит в mozilla webdev, но това изобщо не е неочаквано, когато съмнителни практики като диагонални спрайтове се използват.

Алтернатива, която да разгледате, е индивидуални кодирани с base64 изображения, вградени директно в CSS.

След това преформатиране и пребоядисване:

Погрешно схващане е, че reflow може да се задейства само с JS DOM манипулация - всъщност всяко приложение на стил, засягащ оформлението, би го задействало, засягайки целевия елемент, неговите деца и елементите, които го следват и т.н. Единственият начин да предотвратите ненужни повторения от него е да опитате и избягвайте изобразяване на зависимости. Ясен пример за това би бил изобразяване на таблици:

Таблиците често изискват множество преминавания, преди оформлението да бъде напълно установено, защото те са един от редките случаи, в които елементи могат да повлияят на показването на други елементи, които са били преди тях в DOM. Представете си клетка в края на таблицата с много широко съдържание, което кара колоната да бъде напълно преоразмерена. Ето защо таблиците не се визуализират постепенно във всички браузъри.

Ще правя редакции, ако си спомня нещо важно, което е пропуснато. Някои връзки, с които да завършите:

http://perfectionkills.com/profiling-css-for-fun-and-profit-optimization-notes/

http://jacwright.com/476/runtime-performance-with-css3-vs-images/

https://developers.google.com/speed/docs/best-practices/payload

https://trac.webkit.org/wiki/QtWebKitGraphics

https://blog.mozilla.org/webdev/2009/06/22/use-sprites-wisely/

http://dev.opera.com/articles/view/efficient-javascript/

Докато е вярно, че

компютрите бяха много по-бавни преди 10 години.

Освен това разполагате с много по-голямо разнообразие от устройства, които могат да осъществят достъп до вашия уебсайт в наши дни. И докато настолните компютри/лаптопи се появиха с бързи темпове, устройствата на пазара на смартфони от среден и нисък клас в много случаи не са много по-мощни от това, което имахме в настолните компютри преди десет години.

Но като казахме, че скоростта на избор на CSS вероятно е близо до дъното на списъка с неща, за които трябва да се тревожите по отношение на осигуряването на добро изживяване за възможно най-широк диапазон от устройства.

Разширявайки това, не успях да намеря конкретна информация, свързана с по-модерни браузъри или мобилни устройства, които се борят с неефективни CSS селектори, но успях да намеря следното:

1. http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/

   Вече е доста остарял (IE8, Chrome 2), но има приличен опит за установяване на ефективността на различни селектори в някои браузъри и също така се опитва да определи количествено как броят на CSS правилата влияе върху времето за изобразяване на страницата.

2. http://www.thebrightlines.com/2010/07/28/css-performance-who-cares/

   Отново доста остарял (IE8, Chrome 6), но стига до крайности в неефективните CSS селектори * * * * * * * * * { background: #ff1; }, за да установи влошаване на производителността.

За такава голяма премия съм готов да рискувам нулевия отговор: няма официални CSS селектори, които да причиняват осезаемо забавяне на изобразяването и (в днешно време на бързи компютри и бързи итерации на браузъра) всички намерени се бързо решен от производителите на браузъри. Дори в мобилните браузъри няма проблем, освен ако непредпазливият разработчик желае да използва нестандартни jQuery селектори. Те са маркирани като рискови от разработчиците на jQuery и наистина могат да бъдат проблематични.

В този случай липсата на доказателства е доказателство за липсата на проблеми. Така че използвайте семантично маркиране (особено OOCSS) и докладвайте за всяко забавяне, което откриете, когато използвате стандартни CSS селектори в неясни браузъри.

Хора от бъдещето: Проблемите с производителността на CSS през 2012 г. вече бяха нещо от миналото.

не е ли css неуместен начин да го направите по-бърз, трябва да е последното нещо, което гледате, когато гледате производителността. Направете своя css по начин, който ви подхожда, компилирайте го. и след това го сложете в главата. Това може да е грубо, но има много други неща, които трябва да търсите, когато търсите ефективността на браузъра. Ако работите в дигитално бюро, няма да ви плащат, за да направите тази допълнителна 1ms във времето за зареждане.

Както коментирах, използвайте pagespeed за chrome, това е инструмент на Google, който анализира уебсайта в 27 параметъра, css е 1 от тях.

Моят пост се отнася точно до това, че не бих предпочел около 99% от уеб потребителите да могат да отворят уебсайта и да го видят правилно, дори хората с IE7 и други подобни. След това да затворите около 10% с помощта на css3, (Ако се окаже, че можете да получите допълнителни 1-10ms за производителност).

Повечето хора имат поне 1mbit/512kbit или повече и ако заредите тежък сайт, зареждането отнема около 3 секунди, но можете да спестите 10ms може би от css??

И когато става въпрос за мобилни устройства, трябва да правите сайтове само за мобилни телефони, така че когато имате устройство с размер на екрана по-малък от „Width“px, вие имате отделен сайт

Моля, коментирайте по-долу, това е моята гледна точка и моят личен опит с уеб разработката

Въпреки че не е пряко свързано с кода, използването на <link> върху @import за включване на вашите таблици със стилове осигурява много по-бърза производителност.

„Не използвайте @import“ през stevesouders.com

Статията съдържа множество примери за тестове за скорост между всеки тип, както и включването на един тип с друг (напр.: CSS файл, извикан чрез <link> също съдържа @import към друг css файл).