Или вот зашла речь о сборке JavaScript и CSS.
Собирать, подключаемые на странице ресурсы, в меньшее количество файлов, вещь хорошая и позволяющая повышать эффективность загрузки. Только многие не видят очевидных минусов.
Например, на одной страничке у нас подключаются файлы A.js, B.js и C.js. Загружаются они браузером за три запроса и сохраняются в кэше.
Но мы, при деплое, запускаем свою супер-склеивалку и у нас вместо трёх файлов получается один ABC.js. Браузеру приходится загружать тот же самый объём, но всего за один запрос, что намного оптимальнее. Пока всё хорошо.
А теперь мы переходим на другую страницу, на которой у нас используются сценарии A.js, B.js и D.js. В обычной ситуации браузер бы запросил D.js, а остальные два файла взял бы из кэша. Но теперь у нас на продакшене вместо трёх файлов — один ABD.js. И браузеру приходится тащить к себе по второму разу содержимое A и B.
А потом мы вносим изменения в B.js. В случае без сборки, браузеру пришлось бы обновить только один этот файл. В случае со сборокой же, пришлось обновлять все сборки, где участвует B. В нашем случае, это и ABC.js и ABD.js.
Мораль, как обычно: ни одна крутая тулза не избавляет от необходимости думать головой. Собирать имеет смысл только самое ядро, которое используется на всём сайте и очень редко меняется.
Проблема решается правильным кешированием несклееных файлов в браузере.
Или cклеивать все-все в один файл… и все равно жестко кешировать в браузере
Sergey, 21.02.2013, 13:12
>Проблема решается правильным кешированием несклееных файлов в браузере.
не понял, как?
>Или cклеивать все-все в один файл… и все равно жестко кешировать в браузере
да, но после изменений в одном из исходных файлов, будет каждый раз обновляться весь супер-файл.
vasa_c, 21.02.2013, 13:32
Почитайте о кешировании и версионности тут — http://javascript.ru/optimize/cache-versioning
Ничего нет страшного в том, что клиент раз загрузит обновленную большую склееную библиотеку. Но надо смотреть в конкретной ситуации.
У нас проект на php + js + css — делаем сборку через phing. Все статические файлы копируем в папки типа v/1.2.3/ и настраиваем nginx на отдачу статики с правильными заголовками с этих папок. Так решаем версионность. Phing так же компилит js темплейты, сжимает и соединяет нужные файлы.
Sergey, 21.02.2013, 13:39
>Ничего нет страшного в том, что клиент раз загрузит обновленную большую склееную библиотеку. Но надо смотреть в конкретной ситуации.
Ну, если клиент загрузит все исходные файлы по отдельности и даже не сжатые, то солнце на землю тоже не упадёт.
Однако, мы же боремся за оптимизацию. Я написал о том, что бездумная сборка всего в один файл не обязательно будет оптимальнее, чем ситуация вообще без сборки.
>Все статические файлы копируем в папки типа v/1.2.3/
1.2.3 — это общая ревизия? То есть каждый раз создаётся папка и туда копируются все файлы вне зависимости от того, изменились ли они или нет?
vasa_c, 21.02.2013, 13:56
Ну нужно решить что оптимизировать. Количество запросов к серверу или трафик, или скорость загрузки страницы. И подобрать нужное для вашего проекта.
1.2.3 — это номер версии сборки файлов. Автоматически номер добавляется в урлу ко всей статике в проекте. Загружается пользовательским браузером раз на месяц. Обновление файлов выкатываются раз в 2-3 недели. Паралельно с этим можно и пожать файлы и объединить.
Sergey, 21.02.2013, 15:05
Ну я об этом и говорю — нужно сначала решить, а потом подобрать нужное :)
А неправильное использование сборки негативно скажется, как на трафике, так и на скорости загрузки.
vasa_c, 21.02.2013, 15:41