Должен ли JavaScript, указанный в разделе заголовка, обслуживаться с того же имени хоста, что и основной документ?

12

У меня сложилось впечатление, что для лучшей производительности Javascript должен рассматриваться как статический контент и обслуживаться из домена без файлов cookie вместе с файлами CSS, изображениями и т. Д.

Но Google говорит здесь: не обслуживайте ранее загруженные внешние файлы JS из домена без файлов cookie.

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

Так что теперь я в конфликте. Я не понимаю, что означает «необходимо для запуска страницы».

Обычно у меня есть две ссылки на JavaScript: JQuery, предоставленный из ajax.googleapis.com, и файл master.js, который в основном содержит обработчики событий в функции $ (document) .ready (). Это нужно для запуска страницы?

Учитывая доступные параметры (ajax.googleapis.com, статический домен без файлов cookie, оригинальное имя хоста), где должен обслуживаться мой JavaScript?

Джеймс Лаврук
источник

Ответы:

5

Так что теперь я в конфликте. Я не понимаю, что означает «необходимо для запуска страницы».

Это очень сильно зависит от того, как функционирует ваш сайт. По сути, это JavaScript, который должен быть запущен, прежде чем кто-то сможет использовать веб-страницу.

Например, если вы зайдете на http://www.weather.com/ , вы увидите, что хорошие люди решили использовать некоторую магию JavaScript, чтобы дать подсказку для формы поиска погоды. Т.е. слова Enter Zip, City or Place (e.g. Disney World)появляются в поле ввода текста. К сожалению, при загрузке страницы есть небольшая задержка, по крайней мере, с моей стороны. Таким образом, если страница загружается достаточно медленно и вы достаточно быстры, чтобы начать вводить текстовый ввод до того, как JavaScript выполнится - что не является натяжкой - ваш ввод может быть испорчен JavaScript, который слепо помещает эту подсказку текст в поле ввода.

Конечно, этого можно избежать, сначала проверив пользовательский ввод в текстовом поле или просто отказавшись от этой анахроничной техники. Однако тогда это не послужило бы хорошим примером.

Учитывая доступные параметры (ajax.googleapis.com, статический домен без файлов cookie, оригинальное имя хоста), где должен обслуживаться мой JavaScript?

На этот вопрос нельзя ответить, не зная, что делает ваш JavaScript. Кроме того, как намекает bpeterson76, это зависит от конкретной ситуации на вашем сайте. Т.е. насколько велика страница? насколько хорошо ваш хозяин встречается? сколько CSS-файлов, изображений и т. д. загружается? сколько внешних ресурсов загружается?

В зависимости от конкретной ситуации это может быть преждевременной оптимизацией.

Джордж Мариан
источник
4

Правило "все, что требуется для начала рендеринга страницы должно быть с одного сервера", обычно применяется к вашемусерверы или другие более мелкие ресурсы - ситуации, когда поиск DNS может занять заметную долю секунды (что может быстро сложиться, если ваши объекты разбросаны по многим доменам). При использовании общедоступных ресурсов, таких как кэш Google jQuery и других библиотек, есть большая вероятность того, что браузер вашего посетителя уже выполнил этот поиск DNS сегодня (потому что другие сайты ссылаются на контент из этой службы) и, вероятно, также имеет файл в кеше, так что нет Передача должна быть выполнена (или, если сделан запрос, он может просто получить короткий ответ «304 - не изменен»). Даже если для объекта требуется полная загрузка, сеть доставки контента Google будет быстрее для большинства пользователей, чем ваша операция меньшего масштаба.

Одно связанное правило: объекты, которые не требуются для правильного функционирования страницы (как видит пользователь), должны упоминаться как можно позже в основном ответе HTTP. Например, такие вещи, как сценарии, необходимые для служб рекламы / статистики (т. Е. Google Analytics и тому подобное), - предоставьте пользователю свой контент как можно быстрее, а затем загрузите фоновые данные, которые действительно вас интересуют. Я заблокировал несколько служб рекламы / статистики (сопоставив их с 127.0.0.1 в моем файле hosts), потому что они часто бывают слишком медленными, и сайты, которые ссылаются на них раньше, просто дают мне пустую страницу, в то время как сценарии ждут вместо этого о том, чтобы ссылаться на них поздно, чтобы я мог прочитать содержание, на котором я нахожусь, в то время как другие вещи бродят в фоновом режиме.

Полезность домена без файлов cookie для статического содержимого зависит от масштаба. Если у вас есть только один 10-байтовый идентификатор сеанса в файлах cookie и десять тысяч посетителей в день, запрашивающих ~ 20 статических объектов за посещение, вы экономите всего ~ 118 Мбайт в месяц (20 * 20 * 10000 * 31/1024/1024). Если, с другой стороны, ваш сайт хранит в файлах cookie один или два килобайта содержимого, разница может быть гораздо более значительной, особенно если кто-то из ваших пользователей получает доступ к сайту через медленные соединения (например, GPRS через привязку к мобильному телефону или более - переполненная ссылка Wi-Fi в зоне сильных помех), или если вы получаете миллионы посещений в день.

Подводя итог, можно сказать, что для сценариев, которые должны быть загружены до того, как страница может отобразиться, мои предпочтения будут такими:

  1. ajax.googleapis.com или аналогичный
  2. оригинальное имя хоста вызывающей страницы
  3. статический домен без файлов cookie

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

Дэвид Спиллетт
источник
With common public resources ... there is a good chance that your visitor's browser has already done that DNS lookup today Лично мне было бы неудобно полагаться на это для моего сайта. Я бы хотел, чтобы это было как можно быстрее в максимально возможной степени. Независимо от того, вы делаете хорошие очки. +1
Джордж Мариан
1

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

Этот вопрос постоянно обсуждался в Stackoverflow, и приведенный выше ответ, кажется, всегда является консенсусом. Но с реалистической точки зрения, выгоды, полученные от размещения одного против другого, в конечном итоге будут довольно минимальными. Вы получите гораздо больше преимуществ от минимизации, оптимизации и сокращения общих http-запросов, чем от тщательного изучения мест физического расположения. В ситуациях, когда это начинает иметь значение (я выполнял работу, когда страница загружалась более 1,5 миллионов раз в день, поэтому улучшение в 5 тысяч раз означало 5 гигабайт экономии пропускной способности), как правило, существует группа лиц, принимающих решения, которым поручено тщательно анализировать эти решения.

Лично я обычно размещаюсь в Google по единственной причине, что они собираются дать мне самую последнюю копию того, что я ищу.

bpeterson76
источник
Где вы размещаете свой собственный JavaScript? Статический домен без cookie или оригинальное имя хоста?
Джеймс Лаврук
Честно говоря, вне (в основном) встроенного Jquery, на самом деле не так уж много всего, что не может быть динамически связано. Я стараюсь свести к минимуму вуду, используя (в основном) ядро ​​Jquery и Jquery UI, за возможным исключением плагина Datatables. Я большой сторонник концепции «Делай это простым (глупым)» и не буду выпускать код, если он не имеет обратной совместимости, что исключает множество вариантов. Как я уже говорил выше, размещение одного файла в домене без файлов cookie не так уж сложно.
bpeterson76
1

Важно помнить, что браузеры имеют ограничения на количество ресурсов, которые будут загружаться одновременно из одного домена, обычно от 2 до 6, в зависимости от браузера. Использование другого домена позволяет браузеру загружать больше вещей одновременно с вашего домена.

Поэтому лучшее решение - использовать популярный CDN, такой как ajax.googleapis.com, поскольку в этом случае нет файлов cookie. Пользователь, вероятно, уже выполнил поиск DNS и, возможно, даже кэшировал ресурс. CDN оптимизированы по скорости и, вероятно, имеют сервер, близкий к вашему пользователю.

Если CDN не подходит, тогда, если у вас много файлов cookie или есть много ресурсов для загрузки (изображения и т. Д.), Тогда используйте домен без файлов cookie (в любом случае поиск DNS нужно выполнять только один раз).

Если у вас есть несколько ресурсов (только один пользовательский файл javascript) и несколько файлов cookie (только небольшой идентификатор сеанса) хоста из одного домена.

Хорошие ресурсы:

http://www.phpied.com/free-falling-waterfalls/

http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/

http://developer.yahoo.com/performance/rules.html

Адам
источник
1

Хотя ответы, приведенные выше, разбили большую часть вашего вопроса, я внесу вклад в раздел «Необходим для запуска страницы». Я перевожу это на: является ли этот скрипт необходимым для использования сайта? Исходя из опыта, обычно ответ - нет. Однако случаи, когда я бы:

  • Проверка формы
  • Навигация на основе JavaScript (все равно не идеально)
  • Если макет зависит от JavaScript
  • Если JavaScript или библиотека (например, jQuery) используются для критических модификаций DOM

И рекомендации по производительности YSlow от Yahoo для справки.

Тейлор Эдмистон
источник