Объединение JavaScript и CSS в одном файле

[enej]

Первый перевод

[Nicholass]

По-моему в Опере раньше возникали проблемы с обработкой всех комментариев в CSS кроме /**/
Правда, может пофиксили...

[korchasa]

Возвращаться к хакам, ради экономии на спичках?

[Nicholass]

О да. Black Megic Art хорош не везде.

[Nicholass]

*Magic

[Zibx]

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

[DeMx]

Экономия для страшной нагрузки на сервера?! Бугага. Не смешите мои тапочки. :D

[Nadya]

Это экономятся http-пакеты от пользователя к серверу. И страница быстрее загружается.

[sturm]

Отличный подход в стиле МС. Ради 30kb усложнить код для понимания человека, что очень плохо, если саппортят проект разные люди.

[xOr]

Согласен с тем что такое объединение кода скорее будет иметь иметь негативные последствия для проекта который поддерживает несколько человек, но считаю что статья полезна с теоретической точки зрения - рассматривается поведение интерпретаторов JS и CSS в не тривиальной ситуации.

[Cooluck]

и забыт такой нюанс, что файл 5 кб будет грузиться медленнее чем 2 файла по 2.5 кб

[edy]

это почему?

[Cooluck]

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

Тоже самое с файлами, так написано почти во всех учебниках по web.

[kost]

Цитата из учебника какого года?

[Cooluck]

Я сам не проверял, но стречаю данную цитату очень часто, даже в материалах по seo.

[denver]

Будет не быстрее, будет "постепеннее". Т.е. быстрее пользователь начнет видеть уже что-то. А большое количество будет нормально грузить сервер одновременными соединениями. Поэтому не быстрее по скорости.

[Cooluck]

может Вы и правы, нужно бы проверить.

[masterbo]

Всегда удивлялся что народ верит этой глупости.

1. с точки зрения просмотра мелкие картинки действительно показывают "хоть что-то" раньше крупной, но общая картинка раньше не соберётся.

2. у каждого файла картинки есть собственный заголовок (много картинок с частями одного изображения БОЛЬШЕ, чем то же самое в одном файле) и также есть заголовок http, который увеличивает передаваемый объём данных при увеличении числа файлов.

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

[den_rad]

Потому что делается 2 GET запроса. Это в теории, а на практике с 1Мбит каналом разницы не будет видно.

[Cooluck]

не у всех 1 Мбит

[Cooluck]

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

[silverwind]

Любой крутой сервер находясь под нагрузкой «запарится» выдавать по 100 картинок (мелких) раздельно, и не запарится выдавать их 2-мя или пятью файлами.

[prudis]

Впервые слышу что 2 запроса быстрее чем один.

[Blisswise]

А зачем тогда многие менеджеры закачек качают одновременно несколько секций?

[edy]

А вот это действительно аргумент. Точнее вопрос, в котором следует разобраться.

[Cha0S]

Потому что некоторые сервера в нескольно потоков выдают быстрее, чем в один. А ещё некоторые админы шейпят траф так, что в несколько потоков качать быстрее

[Cooluck]

а может быть также потому что несколько потоков могут идти через разные промежуточные сервера и соотвественно разделять нагрузки интрнете каналов?
Прошу не бить ногами, в этом вопросе разбираюсь не сильно :)

[prudis]

Несколько секций это что имелось ввиду?
Вообще когда качается большой файл то практически всё время это именно сама закачка. В данном случае, с 2 очень маленькими файлами, думаю половина времени, если не больше, будет уходить только на запросы к серверу. Да и серверу лучше обработать один запрос вместо 2-х.
А вообще если посмотреть на тот же яху, помоему в WebDeveloper экстеншине можно посмотрть отдельно все картинки на странице. Так вот там все иконки сгруппированы по большим файлам.

[korchasa]

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

[prudis]

А мы чем хуже? Всю жизнь хомпаги лепить будем? :)

[korchasa]

А у вас на хомпаге стоит балансировщик? Если да, то я вам завидую.

[prudis]

Да нет, вы не правильно поняли меня. Я про то что мы же не будем всю жизнь делать хомпаги где будет паралельно на оптимизацию кода/запросов/страниц/т.д. Надо же и нам создавать толковые посещаемые ресурсы. А учиться надо то того как их создавать и не после. После может и не быть.

[korchasa]

Проблемы с количеством запросов начинаются у ОЧЕНЬ посещаемых сайтов. http://vkontakte.ru живет и не кашляет с разделенными CSS и JS файлами. А если у вас стоит тяжелый бексайд, то один пропущенный индекс в БД убъет вам любую подобную экономию.

[prudis]

Никто и не говорил что какой то сайт не сможет жить с раздельными файлами. Речь идёт об оптимизации, такой же оптимизации как и добавление индекса в базу. Оптимизации нет предела :)

[korchasa]

Во-первых оптимизации есть предел. Передел есть всему. Это как обычно деньги: если оптимизация настолько сложна, что не окупиться, то какой смысл ей заниматься?
Во-вторых - YAGNI.

[b_r]

Имхо, это извращение...
Два статических файла дадут минимальную нагрузку на сервер.. Тем более, в большинстве случаев, они будут кэшироватся браузером.

[masterbo]

1 файл даст ещё меньшую нагрузку на сервер и кешироваться будет не хуже.

[wert2all]

аха, теперь в одином файле будут рыться верстальщики и кодеры! ТОгда всё в один файл - и с сервера!

[korchasa]

Это вряд ли. Слияние это надо по идее делать на стадии deploy, там же где CSS и JavaScript "обфрускачиваются" (obtruscate).

[korchasa]

извините obfuscate

[masterbo]

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

[besisland]

Есть способ даже ещё лучше! Зачем нам целых два файла, html и js+css, если можно сделать один?! script и style внутри html-файла вроде никто ещё не отменял.

Мощная экономия на нагрузке на сервер (вдвое меньше обращений к ресурсам) налицо!

[korchasa]

Вы это серьезно? Про кеш не забыли?

[XEK]

yandex.ru -> view source

[Blisswise]

Это у них просто кто-то диверсию закатил.

[Junior]

А как же задержки соединения? :)

[besisland]

Не мелочитесь! Какой кэш, когда речь идёт о сокращении количества файлов вдвое!

[korchasa]

Вы можете обоснованно сказать, что даст это сокращение мне, если вся статика лежит на отдельном сервере, и отдаётся без каких бы то ни было скриптов?

[nertz]

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

[vithar]

Это не всегда так: http://levgem.livejournal.com/194721.htm…

[besisland]

(Шёпотом) их там нет (зато есть красивый «болдовый фонт»).

[userdef]

Так есть и более интересное решение - весь сайт отдавать в одном .chm файле. Это ж какая экономия..

[besisland]

Точно. Или pdf.

[masterbo]

чушь. сам html ведь будет создаваться скриптом. это значит что экономя ресурс числа запросов вы расходуете ресурс в 1000 раз дороже. также напоминаю, что этот способ ЗНАЧИТЕЛЬНО увеличивает трафик, что тоже скорее минус, чем плюс.

[besisland]

html не будет создаваться скриптом. Будет html, а в нём script. Как было ещё десять лет назад.

[korchasa]

Под скриптом, подразумевались серверные скрипты, а не клиентские.

[masterbo]

Боюсь в эпоху web 2.0 далеко не все сайты могут себе позволить статические html. Кроме того такой способ очень безответственно относится к трафику пользователей — ведь закешированный css в отдельном файле сейчас значительно экономит трафик.

[besisland]

А закешированные css и js в одном файле экономят трафик вдвойне значительнее!

[masterbo]

С этим я и не спорил, хотя у меня по-прежнему есть вопросы к применимости такого подхода.

[chx]

а js зачастую тоже кэшируется.

[besisland]

Конечно.

[enej]

Так не кто и не говорит что все вместе) Вместе оно непосредственно передается клиенту!

[caston]

Скорее забавная возможность, нежели руководство к практическому действию. Спасибо за перевод, интересно.

[Majak]

имхо, всё-таки забавное наблюдение возможности, потому что, приминение этого "хака" мне представляеться занятием очень подозрительным

[MTonly]

Здравый смысл по дороге потеряли.

[frst]

не хватает списка протестированных платформ

[enej]

IE6, IE7 и Firefox 2.0

[frst]

маловато для применения в реальных условиях

[amgorb]

я бы такой метод на production web сайтах использовать не стал бы..

[Fireangel]

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

[monsterzz]

Это можно делать во время деплоя на сервер вместе с обфускацией и остальными тасками.
Вы же не заливаете каждый проект ручками?

[SunDrop]

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

[Melnaron]

Всему свое место!
Что за изврат вообще ?!

[anatoly_rr]

Интересно, кстати, насколько эффект выигрыша от загрузки одного файла вместо двух перекрывается увеличенным размером исходников за счёт лишних символов?

[masterbo]

интересный вопрос. но однозначного ответа нет и не будет.

[Xeor]

В этой технике виден один сомнительный плюс (предполагаемый выигрыш в скорости не подтверждён никакими цифрами) и огромная куча минусов:

рассчёт на определённое поведение парсеров (начало html-комментария в принципе вообще не должно встречаться в чистом .js и .css за которые автор пытается выдать файл)

хак с Content-type (*/*), не дающий никаких гарантий что браузер обработает файл корректно

неудобство чтения/редактирования смешанного файла

список можно продолжать, в целом, думаю, идея подойдет разве что посмотреть "а вот как можно хитро сделать", но практическая её ценность близка к нулю

[nertz]

Я думаю проблеммы в том, что совмещенный код становится нечитабельным, обходится очень легко.Все решается созданием дополнительного скрипта для разаработчиков (эдакого компилятора) который перед публикацией файлов на сайте, производит нужный объединения. Тем самым можно даже некоторые картинки закатать в ХТМЛ в Base64, хотя это, мне кажется уже излишне. А прирост скорости будет весьма существенным как например 10000 или 20000 коннектов при обращении 10к юзерей одновременно, Хотя эта проблемма также решается тем же самым nginx.

[korchasa]

Вооот. Nginx(поклон Игорю) здесь ключевое слово ;)

[sphere]

Ага. А с картинками что делать? Эмбедом?

[bug13]

А по моему - бред. Кто отменил в браузерах многопоточность? Да и не такая большая нагрузка для сервера выдать статический файл, нагрузка - когда что-то генерится. Зато плюсы на лицо - начиная от разделения по смыслу, заканчивая разделением по функционалу. Скажем бывает что некий js функционал нужен на определенных страницах, а на других не нужен. При этом этот функционал (скажем аякс-библиотека для какого-нибудь фидбека) весит скажем 40 кб. Зачем объединять основной js с этим если неизвестно, будет пользователь заходить на страницу с фидбеком или нет?
Лучше +1 лишний запрос, чем +40кб лишнего траффика на клиента, разве я не прав?
То же самое и тут. Не будет быстрее, не будет удобнее, может быть будет чуть легче серверу. Хотя опять-же не известно что быстрее - открыть два коннекта отдать два маленьких файла и закрыть, или открыть коннект и отдавать файл в два с половиной раза больше.

[enej]

так не кто же говорит что надо выполнять объединение в ручную или во время разработки. Объединение необходимо производить не посредственно при deploy!!! Так что + не куда не деваются при разработке.

[bug13]

А вы внимательнее прочитайте что я написал. При учете что даже js кода в проекте много - лучше делить его на куски по мере использования. Само собой что одну функцию на 10 строк выносить нет смысла, а вот библиотеки связанные скажем с Ajax, анимацией и прочим, что используется только на некоторых страницах - их лучше в отдельные файлы.
То же и с css. Если у вас есть отдельный раздел с огромным нагромождением разнообразных стилей - почему бы специально для этого раздела не сделать отдельный css? А при таком подходе объединять js с css вообще глупо.
Другое дело что все это имеет смысл если у проекта css и js весит вместе хотябы 100 кило, т.е. если проект более менее большой, а на маленьких проектах говорить об оптимизации количества запросов просто нет смысла.

Вобщем статья интересна исключительно как шпаргалка по хакам парсера js и css. Практического применения я этому пока не вижу( хотя не исключаю что я еще не дорос до такого уровня :) )

[YuppY]

Кто отменил в браузерах многопоточность?

На самом деле там все не так гладко (http://www.die.net/musings/page_load_time/).

[Rulez]

Вы правы, но речь шла о файла css и js которые нужны на всех страницах

[GeniyZ]

Я считаю, что для клиента будет приятнее, если каскадники и скрипты подгружать динамически используя аякс. Причём не кучей сразу, - а по мере надобности.

[masterbo]

Будет, но при условии, что вам не нужно много посетителей.

[GeniyZ]

Существует кеширование и proxy-серверы.
Объём данных будет такой-же как и при кучной загрузке.
Кешироваться будет всё одинаково хорошо.
Вас смущает большое количество соединений??
Это раньше на каждую картинку открывалось своё соединение, сегодня (конечно если подойти к этому с умом) можно избежать этой проблемы. Лично меня это не смущает ни коим образом. По мере надобности - значит при каком-нить действии (например при клацании по ссылке) при котором, в абсолютном большинстве случаев, будет происходит обращение к серверу.
Я не предлагаю аяксом подгружать по две-три строчки стилей. Но если каскадники реально большие, то их стоит всё-таки разбить на несколько файлов по схожести (или необходимости).

[korchasa]

Клиенту глубоко параллельно, КАК они грузяться. ИМХО, единственная ситуация, где надо применять AJAX, для CSS и JS, это динамические дэшборды и MashUp.

[GeniyZ]

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

[eZzo]

Любопытное решение, но в IE7 это не работает. Более того, эффект прямо противоположный. На базе проведённого мной тестирования могу сделать вывод, что IE загружает одновременно первые CSS и JS файлы вне зависимости от того на одинаковый ли URL они указывают или нет.
В FF всё работает так, как и ожидается.

[Methos]

Как сейчас обстоит с этим дело?