Использование DOMContentReady считается анти-паттерном от Google

Question

Член команды библиотеки Google Closure утверждает , что ожидание события DOMContentReady является плохой практикой.

Короче говоря, мы не хотим ждать DOMContentReady (или хуже событие загрузки), так как это приводит к плохому Пользовательский опыт. Пользовательский интерфейс не реагировать, пока все DOM не был загружен из сети. Итак предпочтительным способом является использование встроенных скриптов как можно скорее.

Поскольку они до сих пор не предоставляют более подробную информацию об этом, поэтому мне интересно, как они работают с Операция прервана в IE Этот диалог - единственная критическая причина, по которой я знаю, ждать события DOMContentReady (или загрузки).

1. Знаете ли вы другую причину?
2. Как вы думаете, как они справляются с этой проблемой IE?

Answer 1

Сначала небольшое объяснение: смысл встроенного JavaScript в том, чтобы включить его как можно скорее. Однако это «возможно» зависит от DOM-узлов, для которых этот сценарий требуется объявить. Например, если у вас есть какое-то навигационное меню, требующее JavaScript, вы должны включить скрипт сразу после того, как меню определено в HTML.

<ul id="some-nav-menu">
    <li>...</li>
    <li>...</li>
    <li>...</li>
</ul>
<script type="text/javascript">
    // Initialize menu behaviors and events
    magicMenuOfWonder( document.getElementById("some-nav-menu") );
</script>

Пока вы обращаетесь только к тем узлам DOM, которые, как вы знаете, были объявлены, вы не столкнетесь с проблемами недоступности DOM. Что касается проблемы IE, разработчик должен стратегически включить свой сценарий, чтобы этого не произошло. Это на самом деле не так уж важно, и это не трудно решить. Реальная проблема с этим - «большая картина», как описано ниже.

Конечно, у всего есть свои плюсы и минусы.

За

1. Как только элемент DOM отображается для пользователя, любые функции, которые добавляются к нему с помощью JavaScript, также становятся почти немедленно доступными (вместо ожидания загрузки всей страницы).
2. В некоторых случаях Pro # 1 может привести к более быстрому восприятию времени загрузки страницы и улучшению взаимодействия с пользователем.

Против

1. В худшем случае вы смешиваете презентацию и бизнес-логику, в лучшем случае вы смешиваете свои script включенные в вашу презентацию, обеими задачами может быть сложно управлять. И то, и другое, по моему мнению, неприемлемо для большой части сообщества.
2. Как указывалось без век , если у рассматриваемого скрипта есть внешние зависимости (например, библиотека), то эти зависимости должны быть загружены первыми, что блокирует рендеринг страницы, пока они анализируются и выполняются.

Использую ли я эту технику? Нет. Я предпочитаю загружать все сценарии в конце страницы, непосредственно перед закрывающим тегом </body>. Почти в каждом случае это достаточно быстро для воспринимаемой и фактической производительности инициализации эффектов и обработчиков событий.

Это нормально для других людей, чтобы использовать его? Разработчики будут делать то, что они хотят / нуждаются, чтобы выполнить работу и сделать своих клиентов / начальников / отдел маркетинга счастливыми. Есть компромиссы, и пока вы понимаете их и управляете ими, вы все равно должны быть в порядке.

Answer 2

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

Более того, JavaScript до конца страницы останавливает синтаксический анализ HTML / оценку DOM, пока JS не будет проанализирован и оценен.Google должен посмотреть на их Java, прежде чем давать советы по JavaScript.

Answer 3

Самая большая проблема с встроенными скриптами в том, что они не могут быть кэшированы должным образом. Если все ваши скрипты хранятся в одном js-файле, который минимизирован (с помощью компилятора), то этот файл может быть кэширован браузером только один раз для всего сайта.

Это приводит к повышению производительности в долгосрочной перспективе, если ваш сайт имеет тенденцию быть занятым. Еще одним преимуществом наличия отдельного файла для ваших сценариев является то, что вы, как правило, не «повторяете себя» и не объявляете многократно используемые функции в максимально возможной степени. DOMContentReady не приводит к плохому пользовательскому опыту. По крайней мере, он предоставляет пользователю контент заранее, а не заставляет его ждать загрузки пользовательского интерфейса, что может в конечном итоге стать большим отключением для пользователя.

Также использование встроенных сценариев не гарантирует, что пользовательский интерфейс будет более отзывчивым, чем при использовании с DOMContentReady. Представьте себе сценарий, в котором вы используете встроенные сценарии для выполнения вызовов AJAX. Если у вас есть одна форма, чтобы отправить свой штраф. Имейте больше чем одну форму, и вы в конечном итоге будете повторять ваши вызовы ajax .. следовательно, повторять один и тот же скрипт каждый раз. В конце концов, это приводит к тому, что браузер кэширует больше кода javascript, чем было бы, если бы он был выделен в файле js, загруженном, когда готов DOM.

Еще один большой недостаток наличия встроенных сценариев заключается в том, что вам необходимо поддерживать две отдельные базы кода: одну для разработки и другую для производства. Вы должны убедиться, что обе базы кода синхронизированы. Разрабатываемая версия содержит не минимизированную версию вашего кода, а рабочая версия содержит минимизированную версию. Это большая головная боль в цикле разработки. Вы должны вручную заменить все ваши фрагменты кода, спрятанные в этих громоздких html-файлах, на минимизированную версию, а также в конце надеяться, что ни один код не сломается! Однако при ведении отдельного файла во время цикла разработки вам просто нужно заменить этот файл на скомпилированную уменьшенную версию в производственной кодовой базе.

Если вы используете YSlow, вы увидите, что:

Использование внешнего JavaScript и CSS файлы обычно выдают более быстрые страницы потому что файлы кэшируются браузер. JavaScript и CSS, которые встраивается в HTML документы загружать каждый раз HTML-документ запрашивается Это уменьшает количество HTTP-запросов, но увеличивает Размер документа HTML. С другой стороны, если JavaScript и CSS находятся в внешние файлы, кэшированные браузером, размер документа HTML уменьшен без увеличения количества HTTP запросы.

Я могу ручаться за встроенные сценарии, если и только если код изменяется так часто, что наличие его в отдельном js-файле несущественно и в конечном итоге окажет такое же влияние, как и у этих встроенных сценариев. Тем не менее, эти скрипты не кэшируются браузером. Единственный способ, которым браузер может кэшировать сценарии, - это сохранить его во внешнем js-файле с etag .

Однако это никак не связано с закрытием JQuery против Google. Закрытие имеет свои преимущества. Однако библиотека закрытия затрудняет размещение всех ваших сценариев во внешних файлах (хотя это и не невозможно, просто затрудняет). Вы просто склонны использовать встроенные сценарии.

Answer 4

Если вам нужно избавиться от HTML самостоятельно, подход Googles кажется очень неловким. Они используют скомпилированный подход и могут тратить свои мозговые циклы на другие проблемы, что разумно, учитывая сложный интерфейс их приложений. Если вы стремитесь к чему-то с более мягкими требованиями (читай: почти все остальное), возможно, это не стоит усилий.

Жаль, что GWT говорит только на Java.

Answer 5

Я думаю, что этот совет не очень полезен. DOMContentReady может быть плохой практикой только потому, что в настоящее время он используется слишком часто (возможно, из-за простого в использовании события готовности jquery). Многие люди используют его как «запускающее» событие для любого действия javascript. Хотя даже событие ready () в jQuery предназначалось только для использования в качестве точки запуска для манипуляций с DOM.

Инференциальные манипуляции с DOM при загрузке страницы приводят к ухудшению восприятия пользователем !! Поскольку они не нужны , серверная сторона могла просто полностью сгенерировать начальную страницу.

Так, может быть, члены команды замыкания просто пытаются повернуть в противоположном направлении и вообще не позволить людям делать манипуляции с DOM при загрузке страницы?

Answer 6

Одна из причин, по которой следует избегать встроенных сценариев, заключается в том, что для этого необходимо поместить в документ любые библиотеки зависимостей, что, вероятно, сведет на нет прирост производительности встроенных сценариев. Лучшая практика, с которой я знаком, - помещать все сценарии (в одном HTTP-запросе!) В самый конец документа, прямо перед </body>. Это связано с тем, что загрузка скрипта блокирует текущий запрос и все подзапросы, пока скрипт не будет полностью загружен, проанализирован и выполнен.

Если не считать волшебной палочки, нам всегда придется идти на компромиссы. К счастью, сам HTML-документ все чаще будет становиться наименее ресурсоемким запросом (если вы не делаете глупостей, таких как огромные data: URL-адреса и огромные встроенные SVG-документы). Для меня компромисс ожидания окончания HTML-документа кажется наиболее очевидным выбором.

Answer 7

Это, вероятно, потому что Google не волнует, если у вас нет Javascript, они требуют его практически для всего, что они делают. Если вы используете Javascript в качестве дополнения к уже функционирующему веб-сайту, тогда загрузка скриптов в DOMContentReady просто прекрасна. Смысл в том, чтобы использовать Javascript для улучшения взаимодействия с пользователем, а не изолировать его, если у него его нет.