Производительность анализа Javascript и CSS

Question

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

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

Существуют ли какие-либо инструменты, которые могли бы помочь мне сгенерировать для этого показатели?­­­­­­­­­­­­­­­­­­­­­­­­­­­

Answer 1

Контекст: Хотя это правда, что накладные расходы 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 на каждую отдельную загрузку страницы.

Answer 2

Я считаю YМедленный да, но имейте в виду, что, если все запросы не выполняются через петлевое соединение, вам не о чем беспокоиться.Накладные расходы HTTP на разделенные файлы повлияют на производительность. далеко больше, чем синтаксический анализ, если только ваши файлы CSS/JS не превышают нескольких мегабайт.

Answer 3

В дополнение к великолепному ответу Камена я бы сказал, что в некоторых браузерах время анализа больших ресурсов js растет нелинейно.То есть для анализа JS-файла размером 1 МБ потребуется больше времени, чем для двух файлов по 500 КБ.Таким образом, если большую часть вашего трафика составляют люди, которые, вероятно, будут кэшировать ваш JS (постоянные посетители), и все ваши файлы JS стабильны к кешу, возможно, имеет смысл разбить их, даже если вы в конечном итоге загрузите их все на каждый просмотр страницы.