Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 93
Первый перевод
По-моему в Опере раньше возникали проблемы с обработкой всех комментариев в CSS кроме /**/
Правда, может пофиксили...
Правда, может пофиксили...
Возвращаться к хакам, ради экономии на спичках?
Отличный подход в стиле МС. Ради 30kb усложнить код для понимания человека, что очень плохо, если саппортят проект разные люди.
Согласен с тем что такое объединение кода скорее будет иметь иметь негативные последствия для проекта который поддерживает несколько человек, но считаю что статья полезна с теоретической точки зрения - рассматривается поведение интерпретаторов JS и CSS в не тривиальной ситуации.
и забыт такой нюанс, что файл 5 кб будет грузиться медленнее чем 2 файла по 2.5 кб
это почему?
Составляйте крупные изображения из более мелких. Несколько маленьких картинок загружаются значительно быстрее, чем одна большая.
Тоже самое с файлами, так написано почти во всех учебниках по web.
Цитата из учебника какого года?
Я сам не проверял, но стречаю данную цитату очень часто, даже в материалах по seo.
Будет не быстрее, будет "постепеннее". Т.е. быстрее пользователь начнет видеть уже что-то. А большое количество будет нормально грузить сервер одновременными соединениями. Поэтому не быстрее по скорости.
Всегда удивлялся что народ верит этой глупости.
1. с точки зрения просмотра мелкие картинки действительно показывают "хоть что-то" раньше крупной, но общая картинка раньше не соберётся.
2. у каждого файла картинки есть собственный заголовок (много картинок с частями одного изображения БОЛЬШЕ, чем то же самое в одном файле) и также есть заголовок http, который увеличивает передаваемый объём данных при увеличении числа файлов.
3. нагрузка на сервера действительно пропорциональна числу запросов и даже если учесть что запрос к php-скрипту занимает сервер в 1000 раз сильнее, чем запрос статической картинки, то число соединений это всё равно дорогой ресурс и на успешных сайтах любое снижение числа запросов это дополнительная возможность получения прибыли на том же оборудовании.
1. с точки зрения просмотра мелкие картинки действительно показывают "хоть что-то" раньше крупной, но общая картинка раньше не соберётся.
2. у каждого файла картинки есть собственный заголовок (много картинок с частями одного изображения БОЛЬШЕ, чем то же самое в одном файле) и также есть заголовок http, который увеличивает передаваемый объём данных при увеличении числа файлов.
3. нагрузка на сервера действительно пропорциональна числу запросов и даже если учесть что запрос к php-скрипту занимает сервер в 1000 раз сильнее, чем запрос статической картинки, то число соединений это всё равно дорогой ресурс и на успешных сайтах любое снижение числа запросов это дополнительная возможность получения прибыли на том же оборудовании.
Потому что делается 2 GET запроса. Это в теории, а на практике с 1Мбит каналом разницы не будет видно.
Впервые слышу что 2 запроса быстрее чем один.
А зачем тогда многие менеджеры закачек качают одновременно несколько секций?
А вот это действительно аргумент. Точнее вопрос, в котором следует разобраться.
Потому что некоторые сервера в нескольно потоков выдают быстрее, чем в один. А ещё некоторые админы шейпят траф так, что в несколько потоков качать быстрее
Несколько секций это что имелось ввиду?
Вообще когда качается большой файл то практически всё время это именно сама закачка. В данном случае, с 2 очень маленькими файлами, думаю половина времени, если не больше, будет уходить только на запросы к серверу. Да и серверу лучше обработать один запрос вместо 2-х.
А вообще если посмотреть на тот же яху, помоему в WebDeveloper экстеншине можно посмотрть отдельно все картинки на странице. Так вот там все иконки сгруппированы по большим файлам.
Вообще когда качается большой файл то практически всё время это именно сама закачка. В данном случае, с 2 очень маленькими файлами, думаю половина времени, если не больше, будет уходить только на запросы к серверу. Да и серверу лучше обработать один запрос вместо 2-х.
А вообще если посмотреть на тот же яху, помоему в WebDeveloper экстеншине можно посмотрть отдельно все картинки на странице. Так вот там все иконки сгруппированы по большим файлам.
Yahoo, Yandex, и прочие монстры это разговор особый, т.к. при таком количестве запросов, как у них, даже время на балансировку критично.
А мы чем хуже? Всю жизнь хомпаги лепить будем? :)
А у вас на хомпаге стоит балансировщик? Если да, то я вам завидую.
Да нет, вы не правильно поняли меня. Я про то что мы же не будем всю жизнь делать хомпаги где будет паралельно на оптимизацию кода/запросов/страниц/т.д. Надо же и нам создавать толковые посещаемые ресурсы. А учиться надо то того как их создавать и не после. После может и не быть.
Проблемы с количеством запросов начинаются у ОЧЕНЬ посещаемых сайтов. http://vkontakte.ru живет и не кашляет с разделенными CSS и JS файлами. А если у вас стоит тяжелый бексайд, то один пропущенный индекс в БД убъет вам любую подобную экономию.
Никто и не говорил что какой то сайт не сможет жить с раздельными файлами. Речь идёт об оптимизации, такой же оптимизации как и добавление индекса в базу. Оптимизации нет предела :)
Во-первых оптимизации есть предел. Передел есть всему. Это как обычно деньги: если оптимизация настолько сложна, что не окупиться, то какой смысл ей заниматься?
Во-вторых - YAGNI.
Во-вторых - YAGNI.
Имхо, это извращение...
Два статических файла дадут минимальную нагрузку на сервер.. Тем более, в большинстве случаев, они будут кэшироватся браузером.
Два статических файла дадут минимальную нагрузку на сервер.. Тем более, в большинстве случаев, они будут кэшироватся браузером.
аха, теперь в одином файле будут рыться верстальщики и кодеры! ТОгда всё в один файл - и с сервера!
Это вряд ли. Слияние это надо по идее делать на стадии deploy, там же где CSS и JavaScript "обфрускачиваются" (obtruscate).
Очень странно слышать от специалистов по автоматизации замечания про необходимость ручного труда. Вам не приходило в голову, что это легко автоматизировать? Что дизайнер и программист могут спокойно продолжать писать два разных файла, а слияние происходить в момент записи правок в эти файлы.
Есть способ даже ещё лучше! Зачем нам целых два файла, html и js+css, если можно сделать один?! script и style внутри html-файла вроде никто ещё не отменял.
Мощная экономия на нагрузке на сервер (вдвое меньше обращений к ресурсам) налицо!
Мощная экономия на нагрузке на сервер (вдвое меньше обращений к ресурсам) налицо!
Вы это серьезно? Про кеш не забыли?
yandex.ru -> view source
Не мелочитесь! Какой кэш, когда речь идёт о сокращении количества файлов вдвое!
Даже если страничка закэширована, это всеравно не избавляет сервер от дополнительного запроса, со стороны клиента с целью уточнения актуальности закэшированной копии.
Это не всегда так: http://levgem.livejournal.com/194721.htm…
Так есть и более интересное решение - весь сайт отдавать в одном .chm файле. Это ж какая экономия..
чушь. сам html ведь будет создаваться скриптом. это значит что экономя ресурс числа запросов вы расходуете ресурс в 1000 раз дороже. также напоминаю, что этот способ ЗНАЧИТЕЛЬНО увеличивает трафик, что тоже скорее минус, чем плюс.
html не будет создаваться скриптом. Будет html, а в нём script. Как было ещё десять лет назад.
Под скриптом, подразумевались серверные скрипты, а не клиентские.
Боюсь в эпоху web 2.0 далеко не все сайты могут себе позволить статические html. Кроме того такой способ очень безответственно относится к трафику пользователей — ведь закешированный css в отдельном файле сейчас значительно экономит трафик.
Скорее забавная возможность, нежели руководство к практическому действию. Спасибо за перевод, интересно.
Здравый смысл по дороге потеряли.
не хватает списка протестированных платформ
я бы такой метод на production web сайтах использовать не стал бы..
При таком подходе читабельность кода сведется к такому уровню, что следующая команда разработчиков, которая будет брошена на саппорт подобного проекта перепишет все, разнеся CSS и JS в разные места. Хороший стиль кода - это компромисс между скоростью и читабельностью/организацией кода, а не резкий бросок в одну из этих сторон.
Дело в том, что если стили будут применяться одинаковые на разных страничках, а js код разный (довольно частая ситуация), то разбиение на два файла будет куда эффективнее.
Всему свое место!
Что за изврат вообще ?!
Что за изврат вообще ?!
Интересно, кстати, насколько эффект выигрыша от загрузки одного файла вместо двух перекрывается увеличенным размером исходников за счёт лишних символов?
В этой технике виден один сомнительный плюс (предполагаемый выигрыш в скорости не подтверждён никакими цифрами) и огромная куча минусов:
рассчёт на определённое поведение парсеров (начало html-комментария в принципе вообще не должно встречаться в чистом .js и .css за которые автор пытается выдать файл)
хак с Content-type (*/*), не дающий никаких гарантий что браузер обработает файл корректно
неудобство чтения/редактирования смешанного файла
список можно продолжать, в целом, думаю, идея подойдет разве что посмотреть "а вот как можно хитро сделать", но практическая её ценность близка к нулю
рассчёт на определённое поведение парсеров (начало html-комментария в принципе вообще не должно встречаться в чистом .js и .css за которые автор пытается выдать файл)
хак с Content-type (*/*), не дающий никаких гарантий что браузер обработает файл корректно
неудобство чтения/редактирования смешанного файла
список можно продолжать, в целом, думаю, идея подойдет разве что посмотреть "а вот как можно хитро сделать", но практическая её ценность близка к нулю
Я думаю проблеммы в том, что совмещенный код становится нечитабельным, обходится очень легко.Все решается созданием дополнительного скрипта для разаработчиков (эдакого компилятора) который перед публикацией файлов на сайте, производит нужный объединения. Тем самым можно даже некоторые картинки закатать в ХТМЛ в Base64, хотя это, мне кажется уже излишне. А прирост скорости будет весьма существенным как например 10000 или 20000 коннектов при обращении 10к юзерей одновременно, Хотя эта проблемма также решается тем же самым nginx.
Ага. А с картинками что делать? Эмбедом?
А по моему - бред. Кто отменил в браузерах многопоточность? Да и не такая большая нагрузка для сервера выдать статический файл, нагрузка - когда что-то генерится. Зато плюсы на лицо - начиная от разделения по смыслу, заканчивая разделением по функционалу. Скажем бывает что некий js функционал нужен на определенных страницах, а на других не нужен. При этом этот функционал (скажем аякс-библиотека для какого-нибудь фидбека) весит скажем 40 кб. Зачем объединять основной js с этим если неизвестно, будет пользователь заходить на страницу с фидбеком или нет?
Лучше +1 лишний запрос, чем +40кб лишнего траффика на клиента, разве я не прав?
То же самое и тут. Не будет быстрее, не будет удобнее, может быть будет чуть легче серверу. Хотя опять-же не известно что быстрее - открыть два коннекта отдать два маленьких файла и закрыть, или открыть коннект и отдавать файл в два с половиной раза больше.
Лучше +1 лишний запрос, чем +40кб лишнего траффика на клиента, разве я не прав?
То же самое и тут. Не будет быстрее, не будет удобнее, может быть будет чуть легче серверу. Хотя опять-же не известно что быстрее - открыть два коннекта отдать два маленьких файла и закрыть, или открыть коннект и отдавать файл в два с половиной раза больше.
так не кто же говорит что надо выполнять объединение в ручную или во время разработки. Объединение необходимо производить не посредственно при deploy!!! Так что + не куда не деваются при разработке.
А вы внимательнее прочитайте что я написал. При учете что даже js кода в проекте много - лучше делить его на куски по мере использования. Само собой что одну функцию на 10 строк выносить нет смысла, а вот библиотеки связанные скажем с Ajax, анимацией и прочим, что используется только на некоторых страницах - их лучше в отдельные файлы.
То же и с css. Если у вас есть отдельный раздел с огромным нагромождением разнообразных стилей - почему бы специально для этого раздела не сделать отдельный css? А при таком подходе объединять js с css вообще глупо.
Другое дело что все это имеет смысл если у проекта css и js весит вместе хотябы 100 кило, т.е. если проект более менее большой, а на маленьких проектах говорить об оптимизации количества запросов просто нет смысла.
Вобщем статья интересна исключительно как шпаргалка по хакам парсера js и css. Практического применения я этому пока не вижу( хотя не исключаю что я еще не дорос до такого уровня :) )
То же и с css. Если у вас есть отдельный раздел с огромным нагромождением разнообразных стилей - почему бы специально для этого раздела не сделать отдельный css? А при таком подходе объединять js с css вообще глупо.
Другое дело что все это имеет смысл если у проекта css и js весит вместе хотябы 100 кило, т.е. если проект более менее большой, а на маленьких проектах говорить об оптимизации количества запросов просто нет смысла.
Вобщем статья интересна исключительно как шпаргалка по хакам парсера js и css. Практического применения я этому пока не вижу( хотя не исключаю что я еще не дорос до такого уровня :) )
Кто отменил в браузерах многопоточность?
На самом деле там все не так гладко (http://www.die.net/musings/page_load_time/).
На самом деле там все не так гладко (http://www.die.net/musings/page_load_time/).
Вы правы, но речь шла о файла css и js которые нужны на всех страницах
Я считаю, что для клиента будет приятнее, если каскадники и скрипты подгружать динамически используя аякс. Причём не кучей сразу, - а по мере надобности.
Будет, но при условии, что вам не нужно много посетителей.
Существует кеширование и proxy-серверы.
Объём данных будет такой-же как и при кучной загрузке.
Кешироваться будет всё одинаково хорошо.
Вас смущает большое количество соединений??
Это раньше на каждую картинку открывалось своё соединение, сегодня (конечно если подойти к этому с умом) можно избежать этой проблемы. Лично меня это не смущает ни коим образом. По мере надобности - значит при каком-нить действии (например при клацании по ссылке) при котором, в абсолютном большинстве случаев, будет происходит обращение к серверу.
Я не предлагаю аяксом подгружать по две-три строчки стилей. Но если каскадники реально большие, то их стоит всё-таки разбить на несколько файлов по схожести (или необходимости).
Объём данных будет такой-же как и при кучной загрузке.
Кешироваться будет всё одинаково хорошо.
Вас смущает большое количество соединений??
Это раньше на каждую картинку открывалось своё соединение, сегодня (конечно если подойти к этому с умом) можно избежать этой проблемы. Лично меня это не смущает ни коим образом. По мере надобности - значит при каком-нить действии (например при клацании по ссылке) при котором, в абсолютном большинстве случаев, будет происходит обращение к серверу.
Я не предлагаю аяксом подгружать по две-три строчки стилей. Но если каскадники реально большие, то их стоит всё-таки разбить на несколько файлов по схожести (или необходимости).
Клиенту глубоко параллельно, КАК они грузяться. ИМХО, единственная ситуация, где надо применять AJAX, для CSS и JS, это динамические дэшборды и MashUp.
Лично мне не параллельно что загрузится раньше - смысл или украшательства.
Лично мне не всё-равно как быстро загрузится страница.
Раньше, когда скорость оставляла желать лучшего, я довольно часто не дожидался загрузки многих страниц - если б сначала загрузилась её смысловая составляющая, а потом по-чуть-чуть (чтоб остальные странички не тормозили сильно) подгружать по мере надобности украшательства, то наверное я б просмотрел намного больше сайтов.
Лично мне не всё-равно как быстро загрузится страница.
Раньше, когда скорость оставляла желать лучшего, я довольно часто не дожидался загрузки многих страниц - если б сначала загрузилась её смысловая составляющая, а потом по-чуть-чуть (чтоб остальные странички не тормозили сильно) подгружать по мере надобности украшательства, то наверное я б просмотрел намного больше сайтов.
Любопытное решение, но в IE7 это не работает. Более того, эффект прямо противоположный. На базе проведённого мной тестирования могу сделать вывод, что IE загружает одновременно первые CSS и JS файлы вне зависимости от того на одинаковый ли URL они указывают или нет.
В FF всё работает так, как и ожидается.
В FF всё работает так, как и ожидается.
Как сейчас обстоит с этим дело?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Объединение JavaScript и CSS в одном файле