Комментарии 45
1. минификация JS кода легко может быть сделана на стадии компоновки проекта в IDE. Или на сервере на первом запуске или любым другим способом до рабочей загрузки кода страницы. Так что главное для упаковщиков-минимфикаторов это оставить код рабочим.
Да, пользую YUI компрессор. Проблем не наблюдалось, но я отключаю все фишки оптимизатора.
2. Слияние скриптов в один включая сжатие легко делается управляемым. По-моему все зрелые CMS умеют это делать. Если кто не умеет — стащить код у тех кто умеет.
Да, пользую YUI компрессор. Проблем не наблюдалось, но я отключаю все фишки оптимизатора.
2. Слияние скриптов в один включая сжатие легко делается управляемым. По-моему все зрелые CMS умеют это делать. Если кто не умеет — стащить код у тех кто умеет.
-1
Подход, естественно, верный. Но не работает для миллионов «кривых» сайтов. Например, для WordPress с его десятками тысяч плагинов. Ручная оптимизация изучена вдоль и поперек — здесь уже вряд ли будет что-то новое. А вот автоматическая на неизвестном окружении — ммм…
-1
Wordpress имеет встроенный загрузчик скриптов и правильно запиханный скрипт им подхватывается, к стати… жалко что не все фишечки вытащены в API.
В универсальном окружении — это упаковка на лету сервером или кэшем? тут куча подводных камней, например зависимость от браузера, версии и прочая интересная, но имхо совершенно излишняя работа. Потому как на условно среднем сайте самые длинные и замысловатые скрипты вянут на фоне загружаемых тонн графики. Но и кэшируются также хорошо браузером. Иногда даже слишком хорошо :)
В универсальном окружении — это упаковка на лету сервером или кэшем? тут куча подводных камней, например зависимость от браузера, версии и прочая интересная, но имхо совершенно излишняя работа. Потому как на условно среднем сайте самые длинные и замысловатые скрипты вянут на фоне загружаемых тонн графики. Но и кэшируются также хорошо браузером. Иногда даже слишком хорошо :)
-1
-1
в данном случае еще неплохо было бы привести timeline
дело в том, что большинство браузеров, когда грузят JS файлы блокируют загрузку всех остальных файлов (некоторые, правда, грузят JS параллельно с CSS) и если на странице JS файлов много то могут возникнуть проблемы с загрузкой:
Как известно, протокол HTTP 1.1 позволяет создавать браузеру только 2 соединения с 1 доменом в каждый момент времени (правда единственный браузер, который следует стандартам это IE, FF создает по 6 параллельных соединений с доменом).
так что размер скриптов тут не так важен, как их количество — 2 скрипта по 80 кб загрузятся гораздо быстрее чем 16 по 10кб, просто потому что в случае с 16 скриптами будет происходить упирание в пинг + задержка очереди загрузки в браузере. а 1 скрипт в 167кб, подключенный асинхронным способом, вообще не затормозит загрузку страницы в реалиях нынешних скоростей интернета.
Но вообще да, это не тонны графики тормозят загрузку страницы, это если у вас на странице тонна графики необходимо думать об оптимизации JS иначе может возникнуть проблема что куча JS файлов забила всю очередь загрузки (как я уже говорил если началась загрузка JS загрузка картинок блокируется, кроме тех что уже грузятся) и пользователь полминуты пялится на страницу без картинок. а если у картинок еще не заданы размеры (height и width) то пользователь может еще получить в итоге веселую «прыгающую» страницу.
опять же, использование css sprites наше все в случае с тонной графики, 2-3 большие картинки прогрузятся быстрее чем 20-30 маленьких.
дело в том, что большинство браузеров, когда грузят JS файлы блокируют загрузку всех остальных файлов (некоторые, правда, грузят JS параллельно с CSS) и если на странице JS файлов много то могут возникнуть проблемы с загрузкой:
Как известно, протокол HTTP 1.1 позволяет создавать браузеру только 2 соединения с 1 доменом в каждый момент времени (правда единственный браузер, который следует стандартам это IE, FF создает по 6 параллельных соединений с доменом).
так что размер скриптов тут не так важен, как их количество — 2 скрипта по 80 кб загрузятся гораздо быстрее чем 16 по 10кб, просто потому что в случае с 16 скриптами будет происходить упирание в пинг + задержка очереди загрузки в браузере. а 1 скрипт в 167кб, подключенный асинхронным способом, вообще не затормозит загрузку страницы в реалиях нынешних скоростей интернета.
Но вообще да, это не тонны графики тормозят загрузку страницы, это если у вас на странице тонна графики необходимо думать об оптимизации JS иначе может возникнуть проблема что куча JS файлов забила всю очередь загрузки (как я уже говорил если началась загрузка JS загрузка картинок блокируется, кроме тех что уже грузятся) и пользователь полминуты пялится на страницу без картинок. а если у картинок еще не заданы размеры (height и width) то пользователь может еще получить в итоге веселую «прыгающую» страницу.
опять же, использование css sprites наше все в случае с тонной графики, 2-3 большие картинки прогрузятся быстрее чем 20-30 маленьких.
-1
Хоть в чём то IE следует стандартам...))
-1
А в чем он не следует?
Все современные стандарты (CSS 2.1, HTML 4.01) он поддерживает в достаточной мере, на уровне остальных браузеров (я, естественно, говорю об IE8, говорить об IE 6 это все равно что говорить что FF 1.5 не поддерживает каких то стандартов, а Opera 4 вообще платный)
CSS 3, HTML 5- это еще все в разработке и их поддержка встраивается в браузеры от доброй души разработчиков браузеров (кстати, в IE 8 частично тоже реализована поддержка некоторых элементов этих стандартов).
Кроме того, в IE уже с 5 (вроде бы) версии поддерживается замечательный аттрибут для тега <script> defer, который означает что скрипт надо грузить и выполнять только после загрузки DOM. непонятно, почему в других браузерах это до сих пор не сделано и приходится извращаться с DOMContentLoaded и т.д.
Все современные стандарты (CSS 2.1, HTML 4.01) он поддерживает в достаточной мере, на уровне остальных браузеров (я, естественно, говорю об IE8, говорить об IE 6 это все равно что говорить что FF 1.5 не поддерживает каких то стандартов, а Opera 4 вообще платный)
CSS 3, HTML 5- это еще все в разработке и их поддержка встраивается в браузеры от доброй души разработчиков браузеров (кстати, в IE 8 частично тоже реализована поддержка некоторых элементов этих стандартов).
Кроме того, в IE уже с 5 (вроде бы) версии поддерживается замечательный аттрибут для тега <script> defer, который означает что скрипт надо грузить и выполнять только после загрузки DOM. непонятно, почему в других браузерах это до сих пор не сделано и приходится извращаться с DOMContentLoaded и т.д.
+3
Про IE8 щас говорить особо смысла нету — доля IE7 и IE6 ещё достаточно велика… Особенно в корпоративном секторе.
Да и ява скрипт у него всё таки если не ошибаюсь какой то другой, не стандартный
Да и ява скрипт у него всё таки если не ошибаюсь какой то другой, не стандартный
0
>проблемы объединения Javascript-файлов
Главная проблема объединения, имхо, — критерий по которому нужно объединять. Например, если наиболее тяжеловесные скрипты (какая-нибудь сложная процедура регистрации или подачи объявлений) исрользуются одноразово или крайне редко — зачем их тащить в общую кучу?
Главная проблема объединения, имхо, — критерий по которому нужно объединять. Например, если наиболее тяжеловесные скрипты (какая-нибудь сложная процедура регистрации или подачи объявлений) исрользуются одноразово или крайне редко — зачем их тащить в общую кучу?
-1
вот тут была неплохая статья на тему JS-объединения с этой точки зрения
webo.in/articles/habrahabr/57-javascript-merging/
а вот здесь — одно из возможных решений (алгоритмическое кэширование)
webo.in/articles/habrahabr/48-flow-slices-optimization/
webo.in/articles/habrahabr/57-javascript-merging/
а вот здесь — одно из возможных решений (алгоритмическое кэширование)
webo.in/articles/habrahabr/48-flow-slices-optimization/
-1
Читал давно. Особенно запомнилось:
«Спешу заверить — это легко5 решается вручную выделением 23 независимых групп со своими собственными ядрами.»
Это называется «жопа» :(
В идеале система объединения должна строиться на основе статистики по результатам тестирования/опытной эксплоатации. Директивная сборка все равно будет иметь большие зазоры.
«Спешу заверить — это легко5 решается вручную выделением 23 независимых групп со своими собственными ядрами.»
Это называется «жопа» :(
В идеале система объединения должна строиться на основе статистики по результатам тестирования/опытной эксплоатации. Директивная сборка все равно будет иметь большие зазоры.
-1
да, Microsoft уже выкатило свое DOLOTO. Мы, наверное, тоже поднажмем и сделаем «интеллектуальное» объединение JS-файлов на основе статистики запросов. Но это не очень тривиальная задача :)
-1
Она станет тем более нетривиальной, если туда включить информацию о поведении пользователей :)
Например сайт вакансий с тремя разными группами пользователей:
1) незалогиненные
2) залогниненные рекрутеры, размещающие вакансии и ищущие резюме
3) залогиненные соискатели, размещающие резюме и ищущие вакансии.
Например сайт вакансий с тремя разными группами пользователей:
1) незалогиненные
2) залогниненные рекрутеры, размещающие вакансии и ищущие резюме
3) залогиненные соискатели, размещающие резюме и ищущие вакансии.
-1
для сжатия js я всегда использую хттп://bananascript.com/
-1
попробовал им сжать, там как я понял он еще кроме уменьшения размера классическими методами (укорачивание имен переменных и т.д.) еще «обфусцирует» код?
остается открытым вопрос, сколько времени тратит браузер на раскодирование этой обфускации и будет ли там реальн выигрыш во времени — в реалиях совеременных скоростей интернета лишний килобайт может загрузится быстрее чем браузер распарсит этот скрипт.
как известно, классические методы сжатия, которые убирают комментарии, заменяют имена переменных и т.д., кроме скорости загрузки также увлеичивают производительность JS в браузере: за счет убора всего лишнего и уменьшения имен переменных JS-движок быстрее парсит файлы.
остается открытым вопрос, сколько времени тратит браузер на раскодирование этой обфускации и будет ли там реальн выигрыш во времени — в реалиях совеременных скоростей интернета лишний килобайт может загрузится быстрее чем браузер распарсит этот скрипт.
как известно, классические методы сжатия, которые убирают комментарии, заменяют имена переменных и т.д., кроме скорости загрузки также увлеичивают производительность JS в браузере: за счет убора всего лишнего и уменьшения имен переменных JS-движок быстрее парсит файлы.
-1
он работает по принципу описанного Packer. Использовать не рекомендуется: на -2% после сжатия получите +100% на распаковку на клиенте.
+2
имхо все кроме Google Compiler — половинчатые решения.
смысла сделать скрипт на 10кб меньше( и это для очень больших скриптов данные ) и иметь лого по размеру больше скриптов — фигня :)
А вот раскрытие в инлайн функций в гугле — она не только размер уменьшает, но и выполнение укоряет.
Местами мало, местами очень даже ничего
смысла сделать скрипт на 10кб меньше( и это для очень больших скриптов данные ) и иметь лого по размеру больше скриптов — фигня :)
А вот раскрытие в инлайн функций в гугле — она не только размер уменьшает, но и выполнение укоряет.
Местами мало, местами очень даже ничего
-3
фишка в том что ваше лого не загрузится пока не загрузятся ваши скрипты если лого прописано как в а скрипты в просто потому что лого попадет в очередь загрузки позже, а загрузка JS блокирует загрузку всех остальных файлов.
поэтому, кстати, если способ клиентской оптимизации, когда все <script src=> переносятся в конец , что позволяет не тормозить очередь загрузки и быстрее прогружать клиентскую часть страницы (картинки, css, etc) а потом только подгружать скрипты.
поэтому, кстати, если способ клиентской оптимизации, когда все <script src=> переносятся в конец , что позволяет не тормозить очередь загрузки и быстрее прогружать клиентскую часть страницы (картинки, css, etc) а потом только подгружать скрипты.
-1
если для клиента загрузка лишних 10кб может вызвать проблему — тогда об этом можно уже особо не париться :)
Тут лучше не брутфорсом подходить а хитростями
хинт:
в начале страницы начинаем загрузку скриптов как обычных файлов через ajax
по готовности делаем им eval или инжекстив в тело тутже созданого script тэга.
что получаем — асинхронную загрузку скрипта, котороая и в конце страницы нас не задержит
Тут лучше не брутфорсом подходить а хитростями
хинт:
в начале страницы начинаем загрузку скриптов как обычных файлов через ajax
по готовности делаем им eval или инжекстив в тело тутже созданого script тэга.
что получаем — асинхронную загрузку скрипта, котороая и в конце страницы нас не задержит
-1
если просто разместить все скрипты в конце страницы ээфект будет почти какой же как если делать вашим способом, с той разницей что ваш способ может не сработать если не подгрузились какие то билиотеки, которые нужны для работы скриптов, которые уже подгрузились.
Я в курсе этого хинта, только у него есть дополнительные сложности — надо знать «зависимости» каждого из подгружаемых скриптов и евалить их только при удовлетворении этих зависимостей.
насчет лишних 10кб — если 10кб скриптов будут грузится до картинок то клиент вместо, например, фото товара, ничего не увидит.
в интернете есть интересная статистика, в которой говорится так же о том, что уменьшение времени загрузки на 100мс у амазона сразу отразилось на продажах — продаж стало на 1% больше. 1% клиентов это неплохой прирост для 10кб скрипта, не считаете? :)
Я в курсе этого хинта, только у него есть дополнительные сложности — надо знать «зависимости» каждого из подгружаемых скриптов и евалить их только при удовлетворении этих зависимостей.
насчет лишних 10кб — если 10кб скриптов будут грузится до картинок то клиент вместо, например, фото товара, ничего не увидит.
в интернете есть интересная статистика, в которой говорится так же о том, что уменьшение времени загрузки на 100мс у амазона сразу отразилось на продажах — продаж стало на 1% больше. 1% клиентов это неплохой прирост для 10кб скрипта, не считаете? :)
-1
speedupyourwebsite.ru/books/speed-up-your-website/online/SpeedUpYourWebsite.v1.4/outline_11.htm
вот нашел ссылку на материал
вот нашел ссылку на материал
-1
Я бы ещё добавил, что все компрессоры, начиная с самых слабых, полностью вырезают комментарии. Как результат, количество комментариев никак не влияет на размер сжатых файлов. Если использовать только GZip, такого эффекта не получится.
0
Я для себя решил, что лучше всего вырезать комментарии, немного минифицировать, слить скрипты в один и сжать gzip-ом.
-1
Сливает скрипты в один и минифицирует его замечательная штука django-assets ( https://launchpad.net/django-assets ). И то же самое делает с CSS.
Там нет никакого движка — это обертка. Сильно автоматизированная.
Там нет никакого движка — это обертка. Сильно автоматизированная.
+2
Недостатки компрессоров из моего опыта:
1) JSMin — ломает скрипты на раз, кроме того медленный, так как парсит скрипт посимвольно
2) Dean's Packer — требует после всех функций, и не только, ставить точки с запятой (а в яваскрипте, что конечно плохо, есть автоподстновка этой самой точки с запятой)
3) Ну YUIComprssor — ставить например на VPS с 256 Мб Яву — дикость.
Так как менять привычки и ставить всюду точки с запятой было лень :), проще оказалось написать свой маленький компрессор, который сохранял частично переводы строк (и иногда пробелы) и не ломал автоподстановку. Кроме того, он работал на регекспах, довольно-таки неплохо.
Конечно, жал он хуже упомянутых здесь скриптов, но ненамного, а главное что комментари резал и пробелы сжимал, что и требовалось :) К тому же все равно в итоге скрипты жмутся gzip, так что разница становится еще меньше.
1) JSMin — ломает скрипты на раз, кроме того медленный, так как парсит скрипт посимвольно
2) Dean's Packer — требует после всех функций, и не только, ставить точки с запятой (а в яваскрипте, что конечно плохо, есть автоподстновка этой самой точки с запятой)
3) Ну YUIComprssor — ставить например на VPS с 256 Мб Яву — дикость.
Так как менять привычки и ставить всюду точки с запятой было лень :), проще оказалось написать свой маленький компрессор, который сохранял частично переводы строк (и иногда пробелы) и не ломал автоподстановку. Кроме того, он работал на регекспах, довольно-таки неплохо.
Конечно, жал он хуже упомянутых здесь скриптов, но ненамного, а главное что комментари резал и пробелы сжимал, что и требовалось :) К тому же все равно в итоге скрипты жмутся gzip, так что разница становится еще меньше.
+2
первый отработал, второй сломался
если сделать так как ты сказал, то первый отработает ещё раз, что черевато
если сделать так как ты сказал, то первый отработает ещё раз, что черевато
-1
было бы хорошо писать более развернутые комментарии, понятные не только их автору :)
-1
первый скрипт из пакета, второй, третий…
-1
понятное дело, что чревато. Но обычно скрипты не настолько критичны к окружению — можно допустить, чтобы по два раза отрабатывали. Главное, чтобы отрабатывали.
А полностью исключить двойную обработку — имхо, слишком «дорогая» задача.
А полностью исключить двойную обработку — имхо, слишком «дорогая» задача.
-1
ещё как критично. лучше, если скрипты вообще не отработают, чем буду работать кое как
-2
У нас разный взгляд на критичность: для миллионов леммингов лучше двойной обработчик событий пусть навесится, и jQuery два раза проинициализируется, чем «галерея развалится».
Для разработчиков — пусть уж лучше галерея развалится (будет понятно, что чинить), чем такая слабо детектируемая фигня с утечками случится.
Вы посмотрите на проблему с разных точек зрения.
Для разработчиков — пусть уж лучше галерея развалится (будет понятно, что чинить), чем такая слабо детектируемая фигня с утечками случится.
Вы посмотрите на проблему с разных точек зрения.
-1
LightSpeed — o_O => lighttpd
-1
поправьте ссылку — webo.in/articles/habrahabr/11-minifing-javascript/
0
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Проблемы сжатия и объединения Javascript