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

Posted on 2010.12.03 at 15:27
Tags: javascript, jquery

Например, вот.
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.

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

13 comments Leave a comment

Add to Memories Share

Comments:

alll at 2010-12-03 12:45 (UTC) (Link)

- Лучшим противозачаточным средством является стакан крепкого чаю с лимоном.
- До или после?
- Вместо!

(Reply) (Thread)

fantaseour at 2010-12-03 12:50 (UTC) (Link)

я из UI пользуюсь draggable. Однако легко можно избежать использования в динамически генерируемых областях.

(Reply) (Thread)

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.

(Reply) (Thread)

gaperton at 2010-12-03 15:04 (UTC) (Link)

> Половина относится к обработка DOM любой библиотекой, например, касаемо повторной обработки DOM в циклах вместо работы с переменными.

Это не так.

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

Этот пункт и подобная лабуда меня не интересует совершенно. Интересные мне "советы" я, вообще-то, зацитировал.

(Reply) (Parent) (Thread)

gaperton at 2010-12-03 15:10 (UTC) (Link)

А не так это просто потому, что если можно сделать быструю диспетчеризацию событий ручками - а ее сделать можно - то и "любая библиотека" на такое потенциально способна.

(Reply) (Parent) (Thread)

gaperton at 2010-12-03 15:24 (UTC) (Link)

А лабуда это потому, что минифицированный jquery в любом случае практически не заметен на фоне остального контента. У меня по крайней мере - так.

(Reply) (Parent) (Thread)

aamonster at 2010-12-03 13:15 (UTC) (Link)

Вот сколько читаю про DOM - столько удивляюсь, что им пользуются.

(Reply) (Thread)

aamonster at 2010-12-03 13:18 (UTC) (Link)

(полное ощущение, что он сделан для особо мелких xml)

(Reply) (Parent) (Thread)

alexsoff at 2010-12-03 14:58 (UTC) (Link)

В DOM буква D не случайна. Он удобен для страниц типа "документ".
А не для приложений. Когда-то давно, когда внутри SUN боролось два направления javascript+DOM и TCL/TK какой-то умник решил, что "серьезных приложений в вебе не будет". :-(
А TCL/TK в задачах скриптовых приложений с рождения был весьма шустр...

(Reply) (Parent) (Thread)

kurilka at 2010-12-03 16:29 (UTC) (Link)

SUN - законодатели мод в области браузеров?
Насколько я понимаю по поводу DOM стоит винить в первую очередь Netscape Communications.

(Reply) (Parent) (Thread)

alexsoff at 2010-12-04 04:42 (UTC) (Link)

Когда у SUN было много денег, они примазывались к куче стартапов. К финансированию Netscape тоже имели отношение. И не только к финансированию. Результаты работ в исследовательской лаборатории тоже передавались.

(Reply) (Parent) (Thread)