Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Кажется, всё более чем доступно описано в абзаце предшествующем табличке...
Автор четко написал: «Все времена даны в миллисекундах»
Что касается выделения жирным - довольно нетрудно заметить, что выделен лучший вариант каждого браузера в каждой паре тестов (т.е. с p и без p)
Что касается выделения жирным - довольно нетрудно заметить, что выделен лучший вариант каждого браузера в каждой паре тестов (т.е. с p и без p)
Да, я согласен, что так намного нагляднее и доступнее. Я бы на месте автора эту ключевую часть поста постарался бы оформить полученные результаты репрезентативно.
PS: Кстати, спасибо что потратили эти 5 минут, чтобы сделать табличку по-человечески. Думаю, если вы не против, автор охотно поместит ее в пост :)
PS: Кстати, спасибо что потратили эти 5 минут, чтобы сделать табличку по-человечески. Думаю, если вы не против, автор охотно поместит ее в пост :)
Ещё бы цветом раз уж такое дело :) Позиции которые меньше подсветить оранжевым или каким-нибудь ещё цветом, а то серое на сером. :(
Грандиозное творение, даже не задумывался о том, что возможна разница в скорости рендеринга различных типов селекторов. Странно. Хоть я сам и не верстальщик, но своих коллег, я думаю, заставлю оценить ваши исследования.
Но в данный момент, приходиться сталкиваться с ужасной семантикой html-кода... к несчастью не многие хотят изучать все возможности css, и даже в тех местах где можно обойтись лишь этими средствами, прибегают к какого то рода кривым js-хакам...
Но в данный момент, приходиться сталкиваться с ужасной семантикой html-кода... к несчастью не многие хотят изучать все возможности css, и даже в тех местах где можно обойтись лишь этими средствами, прибегают к какого то рода кривым js-хакам...
спасибо за ваш труд, было интересно!
А нельзя ли таблицу сделать более читаемой? Границы там между ячейками, отступы внутри...
Материал интересный, спасибо.
Материал интересный, спасибо.
А часто ли мы соблюдаем эти правил ускорения CSS?
Никогда бы не задумался заказчику править каскадные таблицы ради этих милисекунд: времени потратишь, а ему не объяснишь на что.
Но вот для своего блога обязательно поэкспериментирую, автору спасибо.
Никогда бы не задумался заказчику править каскадные таблицы ради этих милисекунд: времени потратишь, а ему не объяснишь на что.
Но вот для своего блога обязательно поэкспериментирую, автору спасибо.
Спасибо, интересно. По моему, не стоит, надо использовать те селекторы которые больше всего подходят для решения задачи.
Что-то опера показала себя не с лучшей стороны... А вообще очень удивлен что IE самый быстрый
Я бы не стал такого про Оперу говорить в данном тесте. Лично у меня явакод не сработал, результатов мне не показали (битая версия?), я уж не стал разбираться почему, но по ощущениям в Опере вся страница (не знаю, сколько времени из этого тратилось на отработку именно селекторов) открывалась всего раза в полтора медленнее чем в ФФ и ИЕ, НО!!! при этом после открытия в Опере окошко ресайзилось легко и непринужденно, в отличие от эксплорера где дело двигалось со скрипом, и уж совсем в отличии от ФФ, который при любом изменении размеров окна намертво зависал секунд на 5-10, будто вся страница переоткрывалась заново, за что ему вечный позор, не зря я его не люблю.
Спасибо автору за результаты эксперимента. Как раз об этом задумывался, что нужно подобный тест сделать проверить скорость работы селекторов, какие типы лучше использовать. Конечно, на среднестатистическом сайте это вря ли пригодится, так как редко когда для этих целей используются трехсот килобайтные таблицы с тысячами правил - обычно все ограничивается несколькими сотнями. Но для больший интернет приложений полученные результаты использовать стоит.
Кстати, уже не раз натыкался на то, что в большинстве браузеров селекторы с простым указанием классов (.class) работает быстрее других, например по id или по имени теги (как ни пародоксально). Так что результатам можно доверять.
Для большей наглядности стоило бы добавить в таблицу:
1. разница в процентах для первого и второго случая (то есть какой выигрыш для разных случаев, для конкретного браузера);
2. процентное соотношение для каждого случая относительно самого медленного или быстрого случая для конкретного браузера;
3. показать средне взвешенные данные, и соотношение относительно самого медленного или быстрого
4. добавить несколько дополнительных случаев таких как .div .class, div p и некоторые другие
5. для браузеров, которые не поддерживают div>p поставить прочерк
6. добавить в тест последнюю версию Opera 9, так как 9-я версия сейчас больше используется
Кстати, уже не раз натыкался на то, что в большинстве браузеров селекторы с простым указанием классов (.class) работает быстрее других, например по id или по имени теги (как ни пародоксально). Так что результатам можно доверять.
Для большей наглядности стоило бы добавить в таблицу:
1. разница в процентах для первого и второго случая (то есть какой выигрыш для разных случаев, для конкретного браузера);
2. процентное соотношение для каждого случая относительно самого медленного или быстрого случая для конкретного браузера;
3. показать средне взвешенные данные, и соотношение относительно самого медленного или быстрого
4. добавить несколько дополнительных случаев таких как .div .class, div p и некоторые другие
5. для браузеров, которые не поддерживают div>p поставить прочерк
6. добавить в тест последнюю версию Opera 9, так как 9-я версия сейчас больше используется
2) будет ли иметь смысл сравнение разных в принципе конструкций?
4) а вот более сложное комбинирование, кстати, было бы еще полезнее, аха
4) а вот более сложное комбинирование, кстати, было бы еще полезнее, аха
2) Конечно если .div div.class будет медленнее .div .class на 1%, то смысл оптимизировать я не вижу, а если на 10% и более уже есть о чем задуматься.
4. Я имел ввиду "простые" селекторы .div .class и div p, а не группу, так как любой браузер разбивает группу на два разных селектора. А вот указаных случаев в таблице нет, только в сочетании с #id и т.п.
4. Я имел ввиду "простые" селекторы .div .class и div p, а не группу, так как любой браузер разбивает группу на два разных селектора. А вот указаных случаев в таблице нет, только в сочетании с #id и т.п.
о, спасибо!
Указанная заметка была полезна только идеей об оптимизации css, к тому же использовалась библиотека ie7. А такие конкретные тесты информативнее на порядки.
По поводу дополнений - было бы интересно посмотреть на тесты таких конструкций:
1) для a > b > c — "a c {...}" в сравнении с "a b c {...}"
2) ".a.b" в сравнении с ".a" (скорее не сравнение, а разница в обработке сложных и простых конструкций)
ЗЫ
"Уменьшаем погрешность" -> "при разработке методикИ выше"
"Результаты" -> "Хочется подчеркнуть, что имеЮт смысл только относительные значения"
Указанная заметка была полезна только идеей об оптимизации css, к тому же использовалась библиотека ie7. А такие конкретные тесты информативнее на порядки.
По поводу дополнений - было бы интересно посмотреть на тесты таких конструкций:
1) для a > b > c — "a c {...}" в сравнении с "a b c {...}"
2) ".a.b" в сравнении с ".a" (скорее не сравнение, а разница в обработке сложных и простых конструкций)
ЗЫ
"Уменьшаем погрешность" -> "при разработке методикИ выше"
"Результаты" -> "Хочется подчеркнуть, что имеЮт смысл только относительные значения"
Очень интересно, несколько правил можно для себя вынести и использовать. Хоть выигрышь и не будет особо большим, но сам понимаешь, что делаешь правильнее :))
Мне кажется некорректным использовать в тесте Opera 9.5, в то время как она еще находится в разработке. С таким же успехом можно было бы включить Firefox 3 Beta 3.
В таблице говориться что в IE запись типа: p.class работает медленее нежели .class
Хотел б с этим поспорить, основываясь на следующий опыт.
В начале разработки приложения(написано окола 30%),
когда у нас начались жуууткие тормаза в ИЕ мы никак не могли понять изза чего они беруться.
Проштудировав кучу информации было выявленно что IE,
а тем более 7й версии, очень медленно парсит CSS.
Ну и пришлось мне классы типа .class переписывать именно на div.class
Я не был уверен что это может как-то помочь, но все же взялся переписывать стили самого большого, на тот момент, виджета.
И действительно получил после небольшой прирост производительности. Переписав остаток приложения его использование под IE уже выходил на вполне юзабельный уровень (тестилось минимум на 6 комах).
Так же если взять за пример extjs.com и взглянуть на их код,
то можно легко проследить одну фичу: они генерируют css стили "на лету" и "прикручивают" их к ID объекта, так как запись div#id являеться наиболее производительной для парсинга в IE.
Довольно таки, имхо, извращенный способ поднять производительность в IE, но если б они этого не сделали, то у них просто напросто все легло медным тазом (((
2автор, жалко что в тест не вошели: FF3, Opera 9.2, Safari for Windows
не вижу смысла тестировать IE5.5.
ЗЫ: собственно, имхо, первые 2 строки теста отображенные в таблице являются неверными. Так пологать мне дает опыт.
ЗЫЫ: И еще скажу на заметку, очень большое влияние на производительность браузера и рендеринга страницы в IE, как окозалось, сказываеться DOCTYPE.
Под IE6/7 мы в текущем приложении (и на данный момент в будущих) были вынуждены выключить DOCTYPE вообще и работать в режимк QuirksMode, так как с XHTML 1.1 или HTML 4.0, производительность браузера падала на ~30% (а это очень существенно)
ЗЫЫЫ: Так же часть стилей типа div:hover, так как они не поддерживаются в IE6 и медленно работают в IE7 перенесли на JavaScript, что так же нам придало производительности 8)
Хотел б с этим поспорить, основываясь на следующий опыт.
В начале разработки приложения(написано окола 30%),
когда у нас начались жуууткие тормаза в ИЕ мы никак не могли понять изза чего они беруться.
Проштудировав кучу информации было выявленно что IE,
а тем более 7й версии, очень медленно парсит CSS.
Ну и пришлось мне классы типа .class переписывать именно на div.class
Я не был уверен что это может как-то помочь, но все же взялся переписывать стили самого большого, на тот момент, виджета.
И действительно получил после небольшой прирост производительности. Переписав остаток приложения его использование под IE уже выходил на вполне юзабельный уровень (тестилось минимум на 6 комах).
Так же если взять за пример extjs.com и взглянуть на их код,
то можно легко проследить одну фичу: они генерируют css стили "на лету" и "прикручивают" их к ID объекта, так как запись div#id являеться наиболее производительной для парсинга в IE.
Довольно таки, имхо, извращенный способ поднять производительность в IE, но если б они этого не сделали, то у них просто напросто все легло медным тазом (((
2автор, жалко что в тест не вошели: FF3, Opera 9.2, Safari for Windows
не вижу смысла тестировать IE5.5.
ЗЫ: собственно, имхо, первые 2 строки теста отображенные в таблице являются неверными. Так пологать мне дает опыт.
ЗЫЫ: И еще скажу на заметку, очень большое влияние на производительность браузера и рендеринга страницы в IE, как окозалось, сказываеться DOCTYPE.
Под IE6/7 мы в текущем приложении (и на данный момент в будущих) были вынуждены выключить DOCTYPE вообще и работать в режимк QuirksMode, так как с XHTML 1.1 или HTML 4.0, производительность браузера падала на ~30% (а это очень существенно)
ЗЫЫЫ: Так же часть стилей типа div:hover, так как они не поддерживаются в IE6 и медленно работают в IE7 перенесли на JavaScript, что так же нам придало производительности 8)
И кстати... более детальнее изучив таблицу, вывелась тенденция что, собственно, IE быстрее любого браузера, что уже само собой ведет к раздумиям.
Мне кажется данные результаты имеют огромные погрешности, или же это просто пиар IE :)
Мне кажется данные результаты имеют огромные погрешности, или же это просто пиар IE :)
если бы Вы потрудились изучить методику, а не только пару десятков циферок с погрешностью в 10% (которая нивелирует почти все результаты), можно было бы конструктивно поспорить.
Тесты прогонялись именно в Standard Mode и на специфическом окружении (которое просто очень быстро парсилось под IE). Если взять другой режим, другое окружение и другие селекторы, то и результат будет совсем другим.
Тесты прогонялись именно в Standard Mode и на специфическом окружении (которое просто очень быстро парсилось под IE). Если взять другой режим, другое окружение и другие селекторы, то и результат будет совсем другим.
В таком случае, работая в Стандартном Режиме, запись типа div>p уже работать не будет, так как это CSS спецификации 2. А работая в QuirksMode браузер не понимает CSS2. И так же на сегодняшний день тестировать производительность браузера в QuirksMode совершенно не актуально.
По всей видимости, возможно так случилось, окужение, как Вы сказали, было, в данном конкретном случае, для IE наиболее приемлимое по производительности. А собственно ссылаться на на данный тест и принимать его за правило было б ошибкой, так как в реалиях разработчик может существенно понизить производительность будущего проекта :(
По всей видимости, возможно так случилось, окужение, как Вы сказали, было, в данном конкретном случае, для IE наиболее приемлимое по производительности. А собственно ссылаться на на данный тест и принимать его за правило было б ошибкой, так как в реалиях разработчик может существенно понизить производительность будущего проекта :(
Для средневзвешенного значения бралось следующая популярность браузеров: IE6 — 35%, IE7 — 35%, Firefox — 25%, Opera — 4%, Safari — 1%.
Для рунета это не так:
http://stat.yandex.ru/stats.xml?ReportID…
http://www.liveinternet.ru/stat/ru/brows…
Положение дел в 2018 году — перевод статьи с sitepoint Оптимизация CSS: ID селекторы и другие мифы. Если вкратце, то для совеременных браузеров разница в скорости обработки ничтожна.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разгоняем CSS-селекторы: стоит ли?