$.ready() перед закрытием тела

Это не реальный вопрос с кодировкой, а скорее утверждение реального мира.

Я ранее отметил, что DOMReady события медленные, очень медленные. Итак, я заметил, что при просмотре источника jQuery событие jQuery domeready может запускаться с помощью $.ready(). Затем я подумал, что это простое выполнение script перед закрытием тела должно запускать все прослушиватели "onDomReady", которые были прикреплены к предыдущему. И да, это работает так, как ожидалось:

     <script>$.ready()</script>
</body>

Вот два примера: это измеряет мс, потраченный во время ожидания DOMReady:

http://jsbin.com/aqifon/10

Как вы можете видеть, триггер DOMReady очень медленный, пользователь должен ждать целое 200-300 миллисекунд до того, как начнется

В любом случае, если мы поместим $.ready() непосредственно перед закрытием тега BODY, получим следующее:

http://jsbin.com/aqifon/16

Посмотрите разницу? При запуске вручную вручную мы можем отключить 100-300 мс задержки выполнения. Это серьезная сделка, потому что мы можем полагаться на jQuery, чтобы позаботиться о манипуляциях с DOM, прежде чем мы их увидим.

Теперь, к вопросу, я никогда не видел, чтобы это было рекомендовано или обсуждалось раньше, но все же это похоже на серьезную проблему с производительностью. Все дело в оптимизации самого кода, что, конечно, хорошо, но напрасно, если выполнение задерживается на такое долгое время, когда пользователь видит "вспышку" unjQueryedContent ".

Любые идеи, почему это не обсуждается/рекомендуется чаще?

ОТВЕТЫ

Ответ 1

Любые идеи, почему это не обсуждается/рекомендуется чаще?

Размещение JavaScript непосредственно перед </body> обсуждалось много, и, как вы знаете, рекомендуется, если вы ищете более быструю загрузку страницы. В действительности, запуск jQuery ready обработчиков вручную недостаточно обсуждается. Зачем? Ну, я не думаю, что есть один объективный ответ на этот вопрос, но я попытаюсь описать некоторые возможности здесь:

  • Производительность не является главной целью jQuery (хотя это определенно вызывает озабоченность), а уроды производительности обычно ищут более легкие библиотеки для кросс-браузерных манипуляций DOM и обработки событий, или roll их.

  • Это дополнительный шаг, и он не выглядит чистым. jQuery пытается быть чистым и элегантным, и рекомендуя дополнительный шаг для инициализации скриптов, не похоже на то, что произойдет. Они рекомендуют привязываться к ready, поэтому рекомендуется принудительно использовать .ready() и игнорировать фактическое событие браузера выглядит "неправильно". Кто бы ни беспокоился об этом, вероятно, знает, что инициализация скриптов прямо перед </body> выполняется быстрее.

  • Оптимизация DOMContentLoaded звучит как задача для поставщиков браузеров. Я не уверен, почему это медленнее, и, возможно, там не так много места для оптимизации – в моем понимании, вызов сценариев init перед </body> всегда должен быть самым быстрым способом инициализации материала (поскольку он выполняется сразу при разборе тега контейнера <script>, в то время как браузеры должны завершить синтаксический анализ всего файла перед запуском DOMContentLoaded).

Вероятно, вы помните, что не так давно было обычной практикой иметь <script> блоки, разбросанные повсюду в HTML. Затем появилось движение Web Standards, и он рекомендовал более разумные и способные делать вещи. Это включало скрипты загрузки из одного места – первоначально, window.onload, который тогда считался проблематичным для того, чтобы быть медленным, тогда DOMContentLoaded и его эмуляции для IE8 и ниже. Тем не менее, мы по-прежнему видим спагетти-HTML со сценариями повсюду ежедневно на StackOverflow. Поэтому я не уверен, что рекомендовать размещение сценариев до конца тела является хорошим звонком сегодня, потому что его можно интерпретировать как лицензию на добавление скриптов в любом месте тела.

Наконец, если вы действительно обеспокоены загрузкой script быстро, а ваш код не манипулирует DOM, самый быстрый способ загрузить его - поместить его в <head> перед любыми таблицами стилей. И я заявляю, что просто сказать, что нет серебряной пули, нет оптимального способа запуска сценариев, который является самым быстрым и элегантным в каждом сценарии. Я думаю, что почему сообщество придерживается рекомендации, которая выглядит разумно и имеет тенденцию создавать более удобный код, а не другие более эффективные альтернативы.

Ответ 2

Выпустив событие самостоятельно, вы указываете своим обработчикам ready(), что ваш dom был загружен, но он, возможно, не был! Нет короткой резки события готовности DOM. Если есть действительно долгое время ожидания, то используйте удивительные инструменты отладки firebug, chrome и т.д.... проверьте свои ресурсы и их временные запросы. Все это в черно-белом цвете и укажет, что так долго (запросы, рендеринг, сколько ресурсов и т.д.)

Ответ 3

Собственно, размещение вызова функции перед тегом </body> делает бессмысленным использование jQuery ready(). Просто поместите вызов функции JS-wrapper, содержащий вызовы всех других функций, которые должны быть вызваны в готовом документе.

В общем, это рабочий (хотя и несколько засоряющий HTML-код и, следовательно, неприемлемый для перфекционистов) вариант для ситуаций, когда автору вообще не нужно/нужно использовать jQuery. Однако в таких ситуациях я бы предпочел использовать собственный обработчик событий DOMContentLoaded, который поддерживается большинством браузеров, включая IE9 + (для IE8 - мы можем использовать window.load() как приемлемый резерв).