?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Как ускорить ваш jQuery

Posted on 2010.12.03 at 15:27
Tags: ,
Например, вот.
http://www.tvidesign.co.uk/blog/improve-your-jquery-25-excellent-tips.aspx

Все подобные советы любопытны. Например:
1) Сведите к минимуму манипуляции с DOM. Тормозит.
2) Не используйте поэлементную сборку DOM-дерева. Тормозит! Используйте текстовые конкатенации, и последующую вставку при помощи .html().
3) Используйте групповые обработчики событий, зацепляясь за верхушки DOM-деревьев. То есть - диспетчеризуйте их вручную, не доверяясь jQuery! Ибо тормозит.

И это все правда. От себя могу добавить:
4) Не используйте виджеты jQuery-UI в динамически перегенерируемых фрагментах DOM. Тормозит ацки. Стоит вырезать, например, button() из кода - и все начинает буквально летать.

То есть, суть всех советов сводится к чему? Если хотите, чтобы ваш проект на jQuery работал быстро - по возможности не используйте jQuery.

Самый эффективный стиль обозначен выше. Надо применять текстовые шаблонные движки для генерации HTML, вставлять результаты в DOM через .html(), и применять только групповые обработчики событий в тех самых точках, куда через .html() вставляется шаблон.

Что удивительно - так не просто все работает заметно быстрее. Так до кучи еще и код получается сильно проще и компактнее. :) При этом, от jQuery остается минимум - фактически, только его DOM-обертка, простые селекторы, и примитивная DOM-манипуляция. Чудеса, правда?

PS: Информация к размышлению. Простой тест, который только что сделал kurilka.
http://kurilka.livejournal.com/322484.html?thread=2029492#t2029492

Тест на работу с "отзязанными" деревьями, не вставленными в документ. 10 тысяч раз вставить один div внутрь другого. Тремя способами:
x) Манипулируя голым DOM-API браузера.
y) Посредством аналогичных вызовов jQuery.
z) Текстовой конкатенацией, после чего - один раз создать из этого DOM дерево.

Загадайте, каким образом, и во сколько будут отличаться результаты. Загадали? А теперь держитесь:

x (DOM-API): 654ms
y (jQuery): 3391ms
z (text): 70ms

1. Вставка элементов DOM через API jQuery в 5 (пять!) раз медленнее прямой вставки.
2. Конструирование дерева в тексте (разворот шаблона) и последующая его вставка в 10 (десять) раз быстрее прямой манипуляции с DOM, и в 50 (стопицот) раз быстрее манипуляций посредством jQuery.

Вопросы есть, господа присяжные заседатели? Вообще-то есть. Но по большей части риторические, в духе "какого хрена".

Comments:


alll
alll at 2010-12-03 12:45 (UTC) (Link)
- Лучшим противозачаточным средством является стакан крепкого чаю с лимоном.
- До или после?
- Вместо!
Boroda aka Hamster
fantaseour at 2010-12-03 12:50 (UTC) (Link)
я из UI пользуюсь draggable. Однако легко можно избежать использования в динамически генерируемых областях.
Lex
lexrwx at 2010-12-03 13:07 (UTC) (Link)
Половина относится к обработка DOM любой библиотекой, например, касаемо повторной обработки DOM в циклах вместо работы с переменными.

Некоторые пункты спорные, некоторые даже вредные.

Например, совет под номером 1 о загрузке с серверов Гугл. Chrome Developer Tools сообщает, для ресурса www.google.com/jsapi: The following resources are explicitly non-cacheable. Consider making them cacheable if possible.

В общем случае, советы для Великобритании, США могут не работать у нас для большинства сайтов, которые не имеют той посещаемости, которая есть на Западе. В частности, я пробовал сравнивать локальную и внешнюю загрузку скриптов, картинок, видео с западных CDN. В Украине разница в скорости заметна невооруженным глазом. Конечно, в теории, кеширование должно работать, но на практике оно зависит, например, от настроек прокси-серверов.
Поэтому рекомендую все таки проверять каждый раз на практике или использовать локальные CDN.
Gaperton
gaperton at 2010-12-03 15:04 (UTC) (Link)
> Половина относится к обработка DOM любой библиотекой, например, касаемо повторной обработки DOM в циклах вместо работы с переменными.

Это не так.

> Некоторые пункты спорные, некоторые даже вредные.
> Например, совет под номером 1 о загрузке с серверов Г

Этот пункт и подобная лабуда меня не интересует совершенно. Интересные мне "советы" я, вообще-то, зацитировал.
Gaperton
gaperton at 2010-12-03 15:10 (UTC) (Link)
А не так это просто потому, что если можно сделать быструю диспетчеризацию событий ручками - а ее сделать можно - то и "любая библиотека" на такое потенциально способна.
Gaperton
gaperton at 2010-12-03 15:24 (UTC) (Link)
А лабуда это потому, что минифицированный jquery в любом случае практически не заметен на фоне остального контента. У меня по крайней мере - так.
aamonster
aamonster at 2010-12-03 13:15 (UTC) (Link)
Вот сколько читаю про DOM - столько удивляюсь, что им пользуются.
aamonster
aamonster at 2010-12-03 13:18 (UTC) (Link)
(полное ощущение, что он сделан для особо мелких xml)
alexsoff
alexsoff at 2010-12-03 14:58 (UTC) (Link)
В DOM буква D не случайна. Он удобен для страниц типа "документ".
А не для приложений. Когда-то давно, когда внутри SUN боролось два направления javascript+DOM и TCL/TK какой-то умник решил, что "серьезных приложений в вебе не будет". :-(
А TCL/TK в задачах скриптовых приложений с рождения был весьма шустр...
Курилыч
kurilka at 2010-12-03 16:29 (UTC) (Link)
SUN - законодатели мод в области браузеров?
Насколько я понимаю по поводу DOM стоит винить в первую очередь Netscape Communications.
alexsoff
alexsoff at 2010-12-04 04:42 (UTC) (Link)
Когда у SUN было много денег, они примазывались к куче стартапов. К финансированию Netscape тоже имели отношение. И не только к финансированию. Результаты работ в исследовательской лаборатории тоже передавались.
Александр Соловьёв
p1r4nh4 at 2010-12-04 13:06 (UTC) (Link)
> внутри SUN боролось два направления javascript+DOM

Звучит смешно. Расскажите Брендану Айку про джаваскрипт в sun'е.
Gaperton
gaperton at 2010-12-03 15:12 (UTC) (Link)
А чем еще пользоваться в браузере? :)
Previous Entry  Next Entry