Осмотренный, не мог найти этот конкретный вопрос обсужденным. Вполне уверенный различие незначительно, просто любопытно относительно Ваших мыслей.
Сценарий: Весь JavaScript, который не должен быть загружен перед рендерингом страницы, был помещен непосредственно перед закрытием </body>
тег. Есть ли какие-либо преимущества или вред к ленивой загрузке их вместо этого через некоторый код JavaScript в голове, которая выполняется, когда DOM загружают/подготавливают, событие запущено? Скажем, то, что этот единственные проблемы, загружающие один весь .js файл, полный функций и не ленивой загрузки нескольких отдельных файлов по мере необходимости после использования.
Надежда это ясно, спасибо.
На мой взгляд, есть большая разница.
Когда вы вставляете JS в нижнюю часть тега , вы заставляете страницу загружать эти
синхронно (должно произойти сейчас) и последовательно (подряд), поэтому вы немного замедляете страницу, так как должны ждать завершения HTTP-вызовов и интерпретации JS-движком ваших скриптов. Если вы размещаете множество JS, сложенных вместе в нижней части страницы, вы можете тратить время пользователя из-за сетевой очереди (в старых браузерах только 2 соединения на хост одновременно), так как скрипты могут зависеть друг от друга, поэтому они должны быть загружены по порядку.
Если вы хотите, чтобы ваш DOM был готов быстрее (обычно это то, чего большинство ждет для выполнения любой обработки событий и анимации), вы должны уменьшить размер необходимых вам скриптов до минимально возможного, а также распараллелить их.
Например, в YUI3 есть небольшой скрипт разрешения зависимостей и загрузки, который вы должны последовательно загрузить в страницу (см. seed.js в YUI3). После этого вы проходите по странице, собираете зависимости и делаете 1 асинхронный и конвейерный вызов к их CDN (или вашим собственным серверам), чтобы получить большой шар JS. После того как JS-шарик возвращается, ваши скрипты выполняют обратные вызовы, которые вы предоставили. Вот общая схема:
<script src="seed.js"></script>
<script>
YUI().use('module', function(Y) {
// done when the ball returns and is interpretted
});
</script>
Я не очень люблю собирать ваши скрипты в один большой шар (потому что если хоть одна зависимость изменится, вам придется скачивать и интерпретировать все заново!), но я поклонник pipe-lining (объединения скриптов) и модели, основанной на событиях.
Когда вы допускаете асинхронную, основанную на событиях загрузку, вы получаете лучшую производительность, но, возможно, не воспринимаемую производительность (хотя с этим можно бороться).
Например, часть страницы может не загружаться секунду или две, и, следовательно, выглядеть по-другому (если вы используете JS для влияния на стиль страницы, чего я не советую) или не быть готовой к взаимодействию с пользователем, пока вы (или те, кто размещает ваш сайт) не вернете свои скрипты.
Кроме того, вы должны проделать определенную работу, чтобы убедиться, что ваши ы имеют нужные зависимости для правильного выполнения. Например, если у вас нет jQuery или Prototype, вы не сможете успешно вызвать:
<script>
$(function () {
/* do something */
});
</script>
или
<script>
document.observe('dom:loaded', function {
/* do something */
});
</script>
так как интерпретатор скажет что-то вроде "Переменная $ не определена". Это может произойти, даже если вы добавили оба а в DOM одновременно, поскольку я готов поспорить, что jQuery или Prototype больше, чем JS вашего приложения (поэтому запрос данных занимает больше времени). В любом случае, без какого-либо типа ограничения, вы оставляете это на волю случая.
Итак, выбор действительно за вами. Если вы сможете правильно сегментировать свои зависимости - т.е. поместить нужные вам вещи вперед и лениво загружать другие вещи позже, это приведет к более быстрому общему времени, пока вы не достигнете готовности DOM.
Однако, если вы используете монолитную библиотеку, такую как jQuery, или пользователь ожидает увидеть что-то, связанное с JS-анимацией или стилем сразу, инлайнинг может быть лучше для вас.
С точки зрения юзабилити, вы определенно не должны делать этого с тем, от чего пользователь ожидает быстрой реакции, например, чтобы кнопка выполняла двойную функцию триггера загрузки в дополнение к своей другой функции.
В то же время замена пагинации на непрерывную загрузку страницы по мере прокрутки пользователем - очень хорошая идея. Правда, меня отвлекает, когда триггер загрузки находится в конце страницы, лучше поместить его на 1/2 - 3/4 пути вниз.