Comments 80
Про селекторы я бы расписал подробнее. Очень многие делают так: $('.class')… Но поиск идет по всему документу, я обычно указываю сначала родительский элемент. При большом DOM дереве даже визуально можно заметить разницу
Жаль что ничегоне сказано об labjs.com/ — сам не пробовал, но один крупный магазин был замечен в использовании.
Про то что не очень хорошо обращаться к DOM элементам не через классы или id а вот так
Лично я конечно все равно использую этот метод ради минимизации html кода, и за некой мифической оптимизацией не гонюсь.
Но жаль все же что такие статьи выходят забугром, потому что это означает — не читают самих отцов, а ведь большинство отсюда:
developers.google.com/speed/articles/
help.yandex.ru/webmaster/?id=1108938
Про то что не очень хорошо обращаться к DOM элементам не через классы или id а вот так
.header > a
Лично я конечно все равно использую этот метод ради минимизации html кода, и за некой мифической оптимизацией не гонюсь.
Но жаль все же что такие статьи выходят забугром, потому что это означает — не читают самих отцов, а ведь большинство отсюда:
developers.google.com/speed/articles/
help.yandex.ru/webmaster/?id=1108938
«Забугром» не читают хелп яндекса? В самом деле?:)
Я правильно понимаю, что запись $(".header > a") медленнее чем $(".header").find(«a»)?
Но по сути они эквивалентны. Я прав?
Но по сути они эквивалентны. Я прав?
я скорее про обращение из css к dom.
Первая
$(".header > a") будет быстрее потому, что будет использоваться нативный метод для выборки, где он есть. Но вторая $(".header").find("a") строго говоря не эквивалентна первой: find находит все дочерние элементы, а селектор > — только непосредственно вложенные (в данном случае, поскольку <a> не могут быть вложенными друг в друга, результаты будут одинаковые).
> 11. Всегда используйте последнюю версию jQuery
Профессионализм прям за версту видать. Ничего, что jQuery ломает обратную совместимость даже в минорных релизах?
Профессионализм прям за версту видать. Ничего, что jQuery ломает обратную совместимость даже в минорных релизах?
Тоже про это писать хотел а потом бац и перешел по ссылке:
code.jquery.com/jquery-latest.js
Версия 1.9.1 но не ясно… на долго ли…
code.jquery.com/jquery-latest.js
Версия 1.9.1 но не ясно… на долго ли…
Прочитайте пункт 11 до конца, пожалуйста.
«Подключайте версию библиотеки, которая у вас поддерживается.»
Круто. Я бы даже сказал, гениально. Можно даже развить. «Всегда используйте последние версии любого программного обеспечения, но только ту последнюю версию, что у вас поддерживается, что бы не сломать обратную совместимость.»
Круто. Я бы даже сказал, гениально. Можно даже развить. «Всегда используйте последние версии любого программного обеспечения, но только ту последнюю версию, что у вас поддерживается, что бы не сломать обратную совместимость.»
а по-моему самого главного правила нет. Насчет того, что сначала нужно 10 раз попробовать обойтись без каждой отдельной строчки яваскрипта или стиля и все-таки использовать эту строчку только если не получилось :)
Я бы еще добавил пункт про то, что при выполнении сложных вычислений можно их разбивать с помощью
setTimeout(function(){},0); И, таким образом, предотвращать блокировку отрисовки страницы браузером.
Немного дополню:
— Желательно подключать jQuery с гугловых серверов, т.к. для большинства пользователей она возьмется из кеша.
— Если на странице нужно следить за 100500 элементами, лучше навесить обработчик на их контейнер и пользоваться всплытием событий.
— $("#foo") на все случаи жизни может не хватить, а вот вместе $(".bar"), который эквивалентен getElementsByClassName, получается минимальный боекомплект для очень быстрого доступа к DOM, конечно если скорость критична. Лично мое мнение, что лучше добавить к элементу лишний id-ик или класс, чем подключать XPath.
— Желательно подключать jQuery с гугловых серверов, т.к. для большинства пользователей она возьмется из кеша.
— Если на странице нужно следить за 100500 элементами, лучше навесить обработчик на их контейнер и пользоваться всплытием событий.
— $("#foo") на все случаи жизни может не хватить, а вот вместе $(".bar"), который эквивалентен getElementsByClassName, получается минимальный боекомплект для очень быстрого доступа к DOM, конечно если скорость критична. Лично мое мнение, что лучше добавить к элементу лишний id-ик или класс, чем подключать XPath.
— Желательно подключать jQuery с гугловых серверов, т.к. для большинства пользователей она возьмется из кеша.Не 100%-ое добро. Когда в прошлом году несколько серверов гугла попали в говнореестр, некоторые сайты, использующие этот подход, не работали. Тут правильнее использовать комплексный подход, как например делает lingualeo.ru:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.1/jquery.min.js"></script>
<script>
window.jQuery || document.write('<scr'+'ipt src="//OUR_SITE/js/jquery-1.8.1.min.js"><\/scr'+'ipt>');
</script>
<script src="//ajax.googleapis.com/ajax/libs/jqueryui/1.8.23/jquery-ui.min.js"></script>
<script>
window.jQuery.ui || document.write('<scr'+'ipt src="//OUR_SITE/js/jquery-ui-1.8.23.custom.min.js"><\/scr'+'ipt>')
</script>Это позволит в случае недоступоности у посетителя гугловских серверов, всё равно подгрузить jQuery но с вашего сайта.
Кеш у современного юзера дико переполнен даже на десктопе (спасибо толстым сайтам, которые всю свою статику научились метить как кешируемую), не говоря уже про iPad-ы. В сумме получаем, что если только человек не ходит только по сайтам, у которых jQuery открывается с Гугла, почти наверняка загрузка с Гугла окажется дольше, чем с сервера самого сайта — минимум на dns lookup, да и то не факт, если сервер сайта все же быстрый и доступный (что, вообще, достижимо).
Не писал бы, но много раз мерял — с Гуглом часто получается не быстрее, и в кеше этого добра не оказывается :(
Не писал бы, но много раз мерял — с Гуглом часто получается не быстрее, и в кеше этого добра не оказывается :(
18. Загружайте сторонний контент асинхронноИ
… например, подключает с помощью этой функции локальный jQuery если Google не отвечает на запрос.
Совершенно не совместимы. В пункте 18 боремся за быстроту загрузки, подключая асинхронно скрипты. А тут «если Google не отвечает на запрос» (но это врятли конечно), в общем противоречие.
Думаю стоит надеется на работоспособность CDN
$('a').on('click', function() {
console.log( this.id );
});
Прелестный пример неиспользования jQuery.
Илья Кантор негодует, прочитав 13 пункт (про сжатие скриптов). Его код данной оптимизации не подлежит, ибо не будет работать и требует дополнительного времени на расстановку запятых.
На мой взгляд лучше сразу писать код, соблюдая синтаксическую пунктуацию. То количество недостающий запятых занимает всяко меньше памяти, чем количество пробельных символов «украшенного» кода.
На мой взгляд лучше сразу писать код, соблюдая синтаксическую пунктуацию. То количество недостающий запятых занимает всяко меньше памяти, чем количество пробельных символов «украшенного» кода.
Насчет «5. Не меняйте масштаб изображений» — если только это не целенаправленная оптимизация изображений для Retina-экранов.
Пусть у нас есть изображение размером 1024x640 и 99 Кб, а делать его в более высоком качестве слишком дорого, оно будет больше весить. Поэтому возьмем такое же изображение, но с размером 2048x1280 и 75 Кб. Так вот, если второму изображению принудительно задать размер в CSS 1024x640, то изображение будет выглядеть качественнее, чем первое.
Минус этой техники, что заставляем браузер делать лишнюю работу. Поэтому эту технику следует применять, когда на странице не очень много изображений. Источник — pepelsbey.net/pres/clear-and-sharp/.
Пусть у нас есть изображение размером 1024x640 и 99 Кб, а делать его в более высоком качестве слишком дорого, оно будет больше весить. Поэтому возьмем такое же изображение, но с размером 2048x1280 и 75 Кб. Так вот, если второму изображению принудительно задать размер в CSS 1024x640, то изображение будет выглядеть качественнее, чем первое.
Минус этой техники, что заставляем браузер делать лишнюю работу. Поэтому эту технику следует применять, когда на странице не очень много изображений. Источник — pepelsbey.net/pres/clear-and-sharp/.
UFO just landed and posted this here
Конечно, чудес не бывает, 99 Кб и 75 Кб выбраны только для примера. Надо было это подчеркнуть.
В формате Jpeg особенно сильно видны размытия на границах объектов. Когда мы делаем картинку в два раза большего размера, сжимаем в Jpeg-формате, а потом искусственно уменьшаем в два раза, то как раз вот эти самые размытия на границах становятся менее видны. По ссылке это хорошо видно на 49-ом и на 52-ом слайдах.
В формате Jpeg особенно сильно видны размытия на границах объектов. Когда мы делаем картинку в два раза большего размера, сжимаем в Jpeg-формате, а потом искусственно уменьшаем в два раза, то как раз вот эти самые размытия на границах становятся менее видны. По ссылке это хорошо видно на 49-ом и на 52-ом слайдах.
> Используя тег script, с указанием атрибута link для CSS файла или же src для JavaScript.
WAT?
WAT?
> Между изображениями в спрайте, оставляйте минимум свободного места.
Не согласен. По своему опыту знаю, что между спрайтами нужно оставлять отступы хотя бы в 10px. Если отступы не сделать, то в webkit-браузерах при увеличении масштаба страницы картинка внутри спрайта размоется и по бокам проступят размытые края соседних элементов спрайта.
Не согласен. По своему опыту знаю, что между спрайтами нужно оставлять отступы хотя бы в 10px. Если отступы не сделать, то в webkit-браузерах при увеличении масштаба страницы картинка внутри спрайта размоется и по бокам проступят размытые края соседних элементов спрайта.
Думаю, основным правилом должно быть «думай», вторым — «ничего не забывай», третьим — «проверь еще раз в самом конце» и четвертым — «не переусердствуй».
К последнему — отдельное замечание: например, то, что из кода страницы будут выкинуты переводы строки, вряд ли уменьшит количество пакетов для загрузки этой страницы, разве что на единицу. Кроме для как совсем частных случаев, экономия 0-1 пакетов никак заметно не повлияет на загрузку, зато повлияет на читаемость кода, случись кому-то его хотя бы просмотреть, если даже не отлаживать.
По опыту возни с большими сайтами, где «исторически наслаиваются» много разных улучшений страниц, могу сказать, что куда важнее, когда после каждого улучшения и добавления не забывают заново хотя бы собрать в один файл те же css- или js-файлы, не просто добавляют чужие скрипты, а добавляют с умом… Так что куда важнее не просто сделать страницу, а не забывать ее поддерживать в хорошей форме.
К последнему — отдельное замечание: например, то, что из кода страницы будут выкинуты переводы строки, вряд ли уменьшит количество пакетов для загрузки этой страницы, разве что на единицу. Кроме для как совсем частных случаев, экономия 0-1 пакетов никак заметно не повлияет на загрузку, зато повлияет на читаемость кода, случись кому-то его хотя бы просмотреть, если даже не отлаживать.
По опыту возни с большими сайтами, где «исторически наслаиваются» много разных улучшений страниц, могу сказать, что куда важнее, когда после каждого улучшения и добавления не забывают заново хотя бы собрать в один файл те же css- или js-файлы, не просто добавляют чужие скрипты, а добавляют с умом… Так что куда важнее не просто сделать страницу, а не забывать ее поддерживать в хорошей форме.
Ожидал большего от статьи, а получил список банальных и, в некоторых случаях, даже вредных советов для совсем уже новичков в веб-разработке.
HTML
0. Изучай инструменты, с которыми ты работаешь
Меньше размер документа — меньше размер ответа с сервера. Меньше тегов — меньше DOM. Меньше DOM — быстрее грузится страница, быстрее работают манипуляции скриптами, быстрее применяются стили. Это основное правило!
0.a кешируй все, что только можно Кешируй куски страницы, кешируй всю страницу, почитай про ETag наконец.
CSS
0. Изучай инструменты, с которыми ты работаешь
Меньше правил — быстрее они применяются. Меньше глобальных правил, больше специфических, с умом. Не будь онанистом на размер файла, он важен, конечно, но у кого на сервере gzip не настроен еще? Никакой алгоритм сжатия не поможет, если твои правила написаны коряво.
20. Объединяйте CSS файлы
Во-первых, объеденять нужно с умом. Грохнуть все в один кусок имеет смысл только тогда, когда вам не жалко при малейшем изменении стилей каждый раз раздавать полмегабайта стилей всем клиентам. Лучше подумать головой и выделить основные части (например: основные правила, формы и админка) и отдавать их по отдельности с тем, что бы клиент кешировал как можно больше из них.
Во-вторых, объединение CSS файлов в один может вызвать забавные баги в ИЕ, вполть до девятой версии.
Приятной отладки!
JavaScript
0. Изучай инструменты, с которыми ты работаешь
Изучи язык, черт возьми, почитай про оптимизации для разных движков.
Перестань читать дурацкие советы вида «используй for вместо each, храни размер массива, используй одинарные кавычки вместо двойных». Черт, да в твоих массивах в среднем 10 элементов, о какой экономии идет речь?!.. Это экономия на спичках, один ajax запрос на сервер или вставка в сложный DOM перекроют эти «микропотимизации» на три порядка. Если ты используешь библиотеку, не читай такие статьи, читай документацию на официальном сайте, смотри примеры, загляни в исходники. Включи мозг.
13. Сжимайте скрипты если у вас 100% покрытие js-кода тестами. Сжатие, а особенно «умные» алгоритмы типа advanced режима у Closure Compiler предназначены либо для людей, которые понимают, что делают (такие не читают статьи для новичков), либо для владельцев целой индийской деревни, полной спецов по QA, либо для смелых духом. У тебя и правда четыре мегабайта скриптов и ты правда не слышал про техники, вроде AMD?
7. Используйте CSS спрайты если у вас очень редко изменяются иконки или появляются новые. Иначе, вы заставите клиентов выкачивать мегабайты ваших спрайтов каждый раз. Очевидно, совет подходит для главной гугла, с небольшим количеством иконок и изображений, и совсем не подходит для админки с двумя сотнями пиктограмм или для магазина с шестью тысячами изображений продуктов. Все нужно делать с умом.
Средставми языка, это как-то так:
HTML
0. Изучай инструменты, с которыми ты работаешь
Меньше размер документа — меньше размер ответа с сервера. Меньше тегов — меньше DOM. Меньше DOM — быстрее грузится страница, быстрее работают манипуляции скриптами, быстрее применяются стили. Это основное правило!
0.a кешируй все, что только можно Кешируй куски страницы, кешируй всю страницу, почитай про ETag наконец.
CSS
0. Изучай инструменты, с которыми ты работаешь
Меньше правил — быстрее они применяются. Меньше глобальных правил, больше специфических, с умом. Не будь онанистом на размер файла, он важен, конечно, но у кого на сервере gzip не настроен еще? Никакой алгоритм сжатия не поможет, если твои правила написаны коряво.
Во-первых, объеденять нужно с умом. Грохнуть все в один кусок имеет смысл только тогда, когда вам не жалко при малейшем изменении стилей каждый раз раздавать полмегабайта стилей всем клиентам. Лучше подумать головой и выделить основные части (например: основные правила, формы и админка) и отдавать их по отдельности с тем, что бы клиент кешировал как можно больше из них.
Во-вторых, объединение CSS файлов в один может вызвать забавные баги в ИЕ, вполть до девятой версии.
Приятной отладки!
JavaScript
0. Изучай инструменты, с которыми ты работаешь
Изучи язык, черт возьми, почитай про оптимизации для разных движков.
Перестань читать дурацкие советы вида «используй for вместо each, храни размер массива, используй одинарные кавычки вместо двойных». Черт, да в твоих массивах в среднем 10 элементов, о какой экономии идет речь?!.. Это экономия на спичках, один ajax запрос на сервер или вставка в сложный DOM перекроют эти «микропотимизации» на три порядка. Если ты используешь библиотеку, не читай такие статьи, читай документацию на официальном сайте, смотри примеры, загляни в исходники. Включи мозг.
Когда его можно достать средствами самого языка:
$('a').on('click', function() {
console.log( this.id );
});
Средставми языка, это как-то так:
var links = document.getElementsByTagName('a');
var onclick = function(e) {e.preventDefault(); console.log(this.id, e.target.id); };
for(var i = 0; i < links.length; i++) { links[i].addEventListener('click', onclick, false); }
17. Храните размер массива
Не согласен. Это экономия на спичках.
Это не так, если речь идет о массивах, в которых лежат DOM элементы.
то есть?
так? :)
var arr = [document.createElement('div'), ..., document.createElement('div')];
так? :)
Почти, если в темноте и со зрением -3. Возьмите хотя бы более приближенный к реальности пример из статьи.
а ещё бывает вот так joxi.ru/ZMSIUdg5CbCabVw6N_w
отчего становится совсем грустно…
отчего становится совсем грустно…
Хм… Объединить все скрипты и css в один? И браузер при малейшем изменении будет снова тягивать ВЕСЬ(!) файл. Я бы озанокимлся с двумя докладами с последнего Я.Субботника про фриз и инкрементальные обновления (http://events.yandex.ru/events/yasubbotnik/kiev-apr-2013/)
Мы позвали кучу страшных имен, чтобы они пересказали то что написано в любом хауту по запросу «оптимизация»
В пункте 17 у меня «плохой» вариант работает быстрее «хорошего»
Где «у вас»? Они работают приблизительно одинаково, но все же «хороший» вариант должен прорабатывать чуточку быстрее, а если массив DOMов то намного быстрее.
Вы уже второй раз говорите про какой-то массив DOMов. Чем этот массив так отличается от массива других объектов? Может быть, правильный ответ — ничем, а вам пора перестать вводить людей в заблуждение?
В js возможны два варианта массивов: собственно Array и «array-like» объект (вроде arguments или написанного руками {0: 'a', lenght: 1}) и ни один из них не накладывает ограничений на итерирование в цикле for (и с чего бы стал?).
В js возможны два варианта массивов: собственно Array и «array-like» объект (вроде arguments или написанного руками {0: 'a', lenght: 1}) и ни один из них не накладывает ограничений на итерирование в цикле for (и с чего бы стал?).
Честно, не могу сказать точно в чём тут дело. Но возьмите в пример результаты, полученные по примеру из статьи. Рискну предположить, что jQuery сам кэширует размер своего массива, поправьте меня, если я не прав.
Извините, я вас не понял в первый раз. При вызове getElementsByTagName вы получаете не совсем массив, а array-like-объект (NodeList), который содержит ссылки на все теги 'a' и будет автоматически обновлен при манипуляциях с DOM. В этом случае кеширование действительно помогает работать с такими объектами быстрее, но ценой отказа от актуального состояния коллекции.
Дайте угадаю. У вас Firefox 20- или же Safari 6.0.3+. Внизу теста в jsPerf интересная статистика. Firefox выше 20ой версии работает быстрее с хранением размера массива. А Safari начиная с версии 6.0.3 работает, наоборот, медленнее при тех же условиях.
Статья для новичков конечно нужная, так как объединяет в себе почти все по клиентской оптимизации. Однако наличие Apache only кусков конфигов смущает. Серьезно, сейчас кто-то еще отдает статику апачем?
это западная статья, на западе еще к Nginx не привыкли. Если нужны оптимизированные конфиги для Nginx, то мы их выложили здесь
code.google.com/p/web-optimizator/wiki/IntegrationWithWebsite#Changes_for_nginx_configuration_file
code.google.com/p/web-optimizator/wiki/IntegrationWithWebsite#Changes_for_nginx_configuration_file
Читал года три назад статью, в которой было показано с помощью примеров, что при ВКЛЮЧЕННОМ gzip разница минимизированных js и ccs файлов с обычными — незначительна. Зато затрудняет отладку.
Дополняя: недавно на Веб-стандартах мы опубликовали перевод большой статьи Быстродействие фронтенда для дизайнеров и разработчиков, которая рассматривает лёгкость фронтенда с ещё одной стороны.
> 6. Data URI
Это, насколько я понимаю, очень актуально для svg?
jsfiddle.net/estelle/SJjJb/
Знал, что его можно напрямую вставлять в HTML, но не в CSS.
Это, насколько я понимаю, очень актуально для svg?
jsfiddle.net/estelle/SJjJb/
Знал, что его можно напрямую вставлять в HTML, но не в CSS.
UFO just landed and posted this here
Спасибо, но пример не мой.
С другой стороны, при непосредственной вставке кода нельзя одну и ту-же картинку использовать для нескольких классов. Нет, конечно можно объединить правила, но, как по мне, получится черти что. (А если еще использовать несколько картинок).
С другой стороны, при непосредственной вставке кода нельзя одну и ту-же картинку использовать для нескольких классов. Нет, конечно можно объединить правила, но, как по мне, получится черти что. (А если еще использовать несколько картинок).
UFO just landed and posted this here
Честно говоря, не понял как. Я просто не профи) Например, если одна картинка под один класс — все просто, прописываем ее, но если нужно что-то такое:
Можно ли это сделать непосредственной вставкой кода svg в css файл без дублирования кода svg?
.foo {
background-image: url(a.svg);
}
.bar {
background-image: url(a.svg), url(b.svg);
}
Можно ли это сделать непосредственной вставкой кода svg в css файл без дублирования кода svg?
в п.14 опечатка, должно быть
document.getElementById("myList").innerHTML += myList;
Все браузеры начиная с IE8 поддерживают технологию кодирования base64.
Совсем забыли сказать что в IE8 32кб лимит на uri.
Совсем забыли сказать что в IE8 32кб лимит на uri.
Sign up to leave a comment.
Лёгкий сайт или как посадить браузер на диету