Является ли использование встроенного JavaScript предпочтительным для внешнего, если script действительно короткий?

Я использую внешние JavaScripts на веб-сайте, поскольку я всегда стараюсь держать JavaScript внизу и внешним.

Но скорость страницы Google дает это предложение

Следующие внешние ресурсы имеют небольшие органы реагирования. Встраивание ответ в HTML может уменьшить блокировку рендеринга страницы.

http://websiteurl/ должен включать следующие небольшие ресурсы: http://websiteurl/script.js

Этот внешний js файл имеет только этот контент

$(document).ready(function() {
    $("#various2").fancybox({
        'width': 485,
        'height': 691,
    });
});

Но в Yslow я получаю это предложение

Оценка n/a on Сделать JavaScript и CSS внешними

Учитывайте это только в том случае, если ваше свойство является общей домашней страницей пользователя.
There are a total of 3 inline scripts
JavaScript и CSS, которые встроены в HTML-документы, загружаются каждый раз, когда запрашивается документ HTML. Это уменьшает количество HTTP, но увеличивает размер документа HTML. С другой стороны, если JavaScript и CSS находятся во внешних файлах, кэшированных браузером, размер документа HTML уменьшается без увеличения количества HTTP-запросы.

Что такое Google или Yahoo?

Ответ 1

Это немного проблематичный пример, на нескольких фронтах.

Вы можете организовать свои сценарии таким образом, чтобы вам не нужно встраивать этот JS. Например, у вас может быть файл common.js, который запускает этот фрагмент, другие подобные фрагменты и упрощает ваш код.

Кроме того, это, похоже, пробудило архитектуру архитектуры "никогда не встраивайте JavaScript". Оказывается, иногда рекомендуется использовать встроенный JavaScript, например, просматривать общий фрагмент из аналитики Google.

Почему Google предлагает, вы должны добавить этот маленький script?

Потому что 20% посещений страниц, у вас есть незапечатанный кеш
Если у вас есть промаха в кеше, скорее всего, вам нужно будет открыть новое соединение с вашим сайтом (1 туда и обратно), а затем данные, отправленные во 2-м раунде. (если вам повезет, вы можете использовать keepalive-соединение, и оно сокращается до 1 раунда.
Для общего "глобального" английского веб-приложения вы просматриваете типичное время в пути на 110 мс для службы, размещенной в США. Если вы используете CDN, число, вероятно, будет сокращено наполовину.
Даже если ресурс является локальным, веб-браузеру все равно может потребоваться доступ к диску для захвата этого крошечного файла.
Без асинхронных или отложенных тегов JavaScript script блокировка, если этот script находится где-то посередине вашей страницы, он будет застрять там, пока script загрузок.

С точки зрения производительности, если доступны только два варианта:

Поместите 50 char JavaScript-бит inline
Поместите 50 символов в отдельный файл и подайте его.

Учитывая, что вы являетесь хорошим гражданином в Интернете и сжимаете весь свой контент, количество дополнительной полезной нагрузки, которую это добавляет, незначительно по сравнению с 20-процентным риском для того, чтобы дать людям значительную задержку. Я всегда выбирал бы # 1.

В несовершенном мире очень редко бывает такой четкий и простой набор опций. Существует опция 3, которая включает асинхронную загрузку jQuery и захват этой функции из общей области.

Ответ 2

Это не совсем так. Вы можете настроить веб-сервер (хорошо atleast apache), чтобы сделать скрипты /ccs встроенными, когда они будут обслуживаться.

Вот полезная ссылка

http://www.websiteoptimization.com/speed/tweak/mod_pagespeed/

Ответ 3

Создание встроенных скриптов может иметь некоторые отрицательные эффекты -

a) Организация кода. Ваш код разбрасывается между вашей разметкой, что влияет на читаемость.

b) Код Сложность и обфускация затрудняются

Лучше всего сохранить js в отдельных файлах, а затем во время сборки интегрировать все из них в один файл и минимизировать и обфускацию.

Ответ 4

Здесь есть два фактора. Один - время загрузки, другое - ремонтопригодность. На оба из них влияют, сколько раз требуется часть Javascript.

Что касается времени загрузки, у вас, очевидно, есть два варианта: включить JS в тело страницы или в качестве внешнего файла. Включение JS в тело сохраняет дополнительный HTTP-запрос, хотя он также немного раздувает HTML и может быть больно поддерживать, если у вас есть несколько сценариев, которые вы вкладываете в ряд на нескольких разных страницах.

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

Ответ 5

Я обычно пишу javascript inline, особенно если script этот маленький. Я бы сказал, просто вставьте его в свой код. Он не будет увеличивать размер документа http на много.

Ответ 6

Пока вложение script будет сохранять запрос, так как Yslow предлагает увеличить размер документа HTML и смешивает контент/разметку с кодом/логикой, чего вы обычно хотите избежать как можно больше.

Причина Yslow дает это оговорку:

Учитывайте это только в том случае, если ваше свойство является общей домашней страницей пользователя.

Это, если страница загружается часто, стоит иметь внешний вид javascript, так как файлы будут кэшироваться в браузере. Итак, если вы объедините JS в один файл, по первому запросу вы получите один дополнительный запрос, а при последующих запросах файл загрузится из кеша.

Ответ 7

Аарон Питерс говорит с прошлого года. Velocity EU дает хорошее представление о вариантах, и курс вы должны выбрать - http://www.slideshare.net/startrender/fast-loading-javascript

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

В зависимости от времени ожидания может потребоваться большое количество сценариев, например. Bind mobile имеет загруженные js на первой загруженной странице, которые затем кэшируются в localstorage для последующих страниц.

Адди Османи недавно собрал экспериментальную библиотеку, чтобы помочь людям играть с кешированием скриптов в localstorage - http://addyosmani.github.com/basket.js/