Улучшение времени загрузки JavaScript - конкатенация по сравнению со многими + кэш

Я бы определенно выбрал немонолитный подход. Не только в вашем случае, но и в целом дает вам больше гибкости, когда вам нужно что-то изменить или перенастроить.

Если вы внесете изменения в один из этих файлов, вам придется выполнить объединение-сжатие и доставку. Если вы делаете это автоматически, то все в порядке.

Что касается вопроса браузера «если срок действия кеша для файла javascript не был достигнут, то кешированная версия используется немедленно; HTTP-запрос не отправляется на сервер вообще», я думаю, что есть HTTP-запрос сделан, но с ответом "НЕ ИЗМЕНЕНО". Чтобы быть уверенным, вы должны проверить все запросы к веб-серверу (используя один из доступных инструментов). После получения ответа браузер использует неизмененный ресурс - файл js, изображение или другой.

Удачи в вашем B2B.

Вы пробовали Google Closure? Судя по тому, что я читал об этом, это кажется весьма многообещающим.

• http://code.google.com/closure/

• http://googlecode.blogspot.com/2009/11/introduction-closure-tools.html - сообщение в блоге

• http: //axod.blogspot.com/2010/01/google-closure-compiler-advanced-mode.html - производительность GC

• http://www.sitepoint.com/google-closure-how-not -to-write-javascript / - несколько советов по javascript

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

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

Обычно лучше иметь меньше больших запросов, чем иметь много маленьких запросов, поскольку браузер будет выполнять только два (?) Запроса параллельно с определенным доменом.

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

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

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

Если вас беспокоит первоначальная загрузка «большого» файла javascript, вы можете попробовать загрузить его асинхронно, используя метод, описанный здесь: http://www.webmaster-source.com/2010/06 / 07 / loading-javascript-asynchronously /

Каким бы путем вы ни пошли в конце, помните, что, поскольку вы устанавливаете дату изменения в далеком будущем, вам нужно будет изменить имя javascript (и CSS), когда в них вносятся изменения , в противном случае клиенты все равно не получат изменения, пока не истечет срок их кеширования.

PS: Профилируйте его в разных браузерах разными методами и запишите, так как он окажется полезным для тех, кто также застрял на медленных JS-движках, таких как IE6 :)

Я использовал следующее для CSS и Javascript - большинство моих страниц в Google Speed report имеют 94-96/100 и загружаются очень быстро (всегда в течение секунды, даже если есть 100kb's Javascript).

1. У меня есть PHP функция для вызова файлов - это класс и хранит все уникальные файлы, которые запрашиваются. Мой вызов выглядит примерно так:

javascript( 'jquery', 'jquery.ui', 'home-page' );

2. Я выплевываю url-кодированную версию этих строк, объединенных вместе, чтобы вызвать динамическую PHP-страницу:

<script type="text/javascript" src="/js/?files=eNptkFsSgjAMRffCP4zlTVmDi4iQkVwibbEUHzju3UYEHMffc5r05gJnEX8IvisHnnHPQN9cMHZeKThzJOVeex7R3AmEDhQLCEZBLHLMLVhgpaXUikRMXCJbhdTjgNcG59UJyWSVPSh_0lqSSp0KN6XNEZSYwAqt_KoBY-lRRvNblBZrYeHQYdAOpHPS-VeoTpteVFwnNGSLX6ss3uwe1fi-mopg8aqt7P0LzIWwz-T_UCycC2sQavrp-QIsrnKh"></script>

3. Эта динамическая PHP-страница декодирует строку и создает массив файлов, которые необходимо вызвать. Создается путь cache_file:

$compressed_js_file_path = $_SERVER['DOCUMENT_ROOT'] . '/cache/js/' . md5( implode( '|', $js_files ) ) . '.js';

4. Проверяется, существует ли этот путь к файлу в кэше, если да, то файл просто считывается:

if( file_exists( $compressed_js_file_path ) ) {
    echo file_get_contents( $compressed_js_file_path );
} else {

5. Если он не существует, он сжимает весь javascript в один "монолитный" файл, но поймите, что он содержит ТОЛЬКО необходимый javascript для этой страницы, а не для всего сайта.

if( $fh = @fopen( $compressed_js_file_path, 'w' ) ) {
    fwrite( $fh, $js );
    fclose( $fh );
}

// Echo the compressed Javascript
echo $js;

Я привел вам выдержки из кода. Программа, которую вы используете для сжатия javascript, полностью зависит от вас. Я использую это и с CSS, и с Javascript, так что все эти файлы требуют 1 HTTP-запрос, когда-либо, результат кэшируется на сервере (просто удалите этот файл, если вы что-то измените), и он содержит только необходимые Javascript и CSS для этой страницы.

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

Во-первых, проанализируйте свои журналы, чтобы понять, действительно ли ваш уровень кэширования настолько хорош, насколько вы ожидаете для вашей пользовательской базы. Например, если каждая html-страница включает jquery.js, просмотрите журналы за день - сколько запросов было для html-страниц? Сколько для jquery.js? Если скорость кэширования хорошая, вы должны увидеть гораздо меньше запросов для jquery.js, чем для html-страниц. Возможно, вы захотите сделать это в течение дня сразу после обновления, а также в течение нескольких недель после обновления, чтобы посмотреть, как это повлияет на скорость кэширования.

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

<html>
<!-- all your HTML content... -->
<script src="jquery.js"></script>
<script src="jquery-ui.js"></script>
<script src="mycode.js"></script>

В этом случае вы засекаете время, необходимое для загрузки JS, и пингуете сервер следующим образом:

<html>
<!-- all your HTML content... -->

<script>var startTime = new Date().getTime();</script>

<script src="jquery.js"></script>
<script src="jquery-ui.js"></script>
<script src="mycode.js"></script>

<script>
var endTime = new Date().getTime();
var totalTime = endTime - startTime; // In milliseconds
new Image().src = "/time_tracker?script_load=" + totalTime;
</script>

Затем вы можете просмотреть журналы /time_tracker (или как вы хотите его назвать) и посмотреть, сколько времени требуется людям для загрузки сценариев.

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