У браузеров предпочитают более компактные пакеты JS?

Question

Я работаю в приложении MVC, которое имеет около 10 BIG JavaScript-библиотек (jquery, modernizr, knockout, flot, bootstrap ...), около 30 плагинов jQuery, и каждый вид (сотни из них) имеет свой собственный Javascript-файл ,

Используется набор по умолчанию MVC4, но все эти файлы JavaScript упакованы в два пакета; один, содержащий все плагины и библиотеки, и один для просмотра конкретных файлов. И эти два пакета загружаются на КАЖДОЙ странице, независимо от необходимости, или нет.

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

Итак, лучше ли для браузеров иметь 2 гигантских связки или создавать «умные» и более светлые связки, специфичные для страниц, но их больше? Браузер будет кэшировать их независимо от того, в первый раз они будут открыты, но есть ли какое-либо преимущество в производительности, если на каждую страницу загружено меньше javascript, и все они загружаются на каждую страницу?

Answer 1

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

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

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

Answer 2

Размер файлов не зависит от браузера сам по себе, размер страницы в целом относится к компьютеру пользователя, это будет влиять на процессор, сеть и память (где три упомянутые компоненты производительности будут несколько зависеть от в используемом браузере).

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

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

Answer 3

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

Сказав, что, как сказал Grdaneault, вы не хотите, чтобы пользователи загружали JS, которые они не будут использовать.

Таким образом, наилучшим подходом было бы объединить все обычные вещи в одно, а затем сделать отдельные пакеты для необычных вещей. Возможно расслоение на просмотр, зависит от вашей структуры. Но не позволяйте вашим связям перекрываться (например, у пакета A есть файл A & B, в комплект B есть файл A & C), так как это приведет к дублированию загрузки.

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