Каковы технические причины использования нескольких небольших файлов вместо одного большого JS-файла?

Question

Есть ли разница между наличием одного большого файла Javascript по сравнению с множеством разных файлов Javascript?

Недавно я узнал, что отдельное приложение в моем офисе содержит два файла Javascript для всего, что требуется. Они составляют почти 2 МБ и содержат примерно 40 тыс. Строк кода.

С точки зрения ремонтопригодности, это очевидно ужасно. Я не могу представить, что это связано с SVN. Но действительно ли это влияет на производительность приложения?

В IIS есть настройка для chunked transfer encoding, но я мало знаю об этом, кроме того, что упоминается в статье. Раздел «Обоснование» не имеет особого отношения к Javascript. Это кажется более важным для «реальных» страниц в приложении и для обмена сообщениями между клиентом и сервером.

С тегами ASP.NET как параметр находится в разделе «ASP» IIS ... Если это не связано с нами, отредактируйте и удалите тег или дайте мне знать, и я могу.

Answer 1

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

Каждый отдельный запрос несет накладные расходы HTTP, в основном дополнительные данные, прикрепленные к заголовкам запроса/ответа, которые также должны быть загружены. Некоторые из них будут изменены с помощью реализации протокола HTTP2, а более мелкие файлы станут более эффективными.

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

Существует множество инструментов, которые вы можете использовать для автоматизации этого процесса сборки, такого как Gulp, Grunt или npm. В некоторых системах управления контентом .NET, таких как DNN, есть настройки, которые позволяют делать это автоматически в процессе производства.