Контекст: Несмотря на то, что HTTP-издержки более значительны, чем синтаксический анализ JS и CSS, игнорирование влияния синтаксического анализа на производительность браузера (даже если у вас меньше мегабайта JS) - хороший способ чтобы попасть в беду.
YSlow, Fiddler и Firebug - не самые лучшие инструменты для контроля скорости разбора. Если только они не были обновлены совсем недавно, они не отделяют количество времени, необходимое для извлечения JS по HTTP или загрузки из кэша, от количества времени, потраченного на анализ фактической полезной нагрузки JS.
Скорость анализа немного сложно измерить, но мы несколько раз гонялись за этим показателем в проектах, над которыми я работал, и влияние на загрузку страниц было значительным даже при ~ 500 тыс. JS. Очевидно, что старые браузеры страдают больше всего ... надеюсь, Chrome, TraceMonkey и тому подобное помогают разрешить эту ситуацию.
Предложение: В зависимости от типа трафика на вашем сайте, может быть, стоит разделить полезную нагрузку JS, поэтому некоторые большие куски JS никогда не будут использоваться на сервере. Самые популярные страницы никогда не отправляются клиенту. Конечно, это означает, что когда новый клиент попадает на страницу, где требуется этот JS, вам придется отправить его по сети.
Однако вполне может быть так, что, скажем, 50% вашего JS никогда не нужны 80% ваших пользователей из-за ваших моделей трафика. Если это так, вы должны определенно использовать меньшие, упакованные полезные нагрузки JS только на страницах, где JS необходим. В противном случае 80% ваших пользователей будут подвергаться ненужным штрафам за синтаксический анализ JS при каждой загрузке страницы .
Итог: Трудно найти правильный баланс кеширования JS и меньших, упакованных полезных нагрузок, но в зависимости от вашей структуры трафика, безусловно, стоит рассмотреть методику, отличную от разбивки всех ваших JS на каждый загрузка одной страницы.