Комментарии 45
1. минификация JS кода легко может быть сделана на стадии компоновки проекта в IDE. Или на сервере на первом запуске или любым другим способом до рабочей загрузки кода страницы. Так что главное для упаковщиков-минимфикаторов это оставить код рабочим.
Да, пользую YUI компрессор. Проблем не наблюдалось, но я отключаю все фишки оптимизатора.
2. Слияние скриптов в один включая сжатие легко делается управляемым. По-моему все зрелые CMS умеют это делать. Если кто не умеет — стащить код у тех кто умеет.
Да, пользую YUI компрессор. Проблем не наблюдалось, но я отключаю все фишки оптимизатора.
2. Слияние скриптов в один включая сжатие легко делается управляемым. По-моему все зрелые CMS умеют это делать. Если кто не умеет — стащить код у тех кто умеет.
Подход, естественно, верный. Но не работает для миллионов «кривых» сайтов. Например, для WordPress с его десятками тысяч плагинов. Ручная оптимизация изучена вдоль и поперек — здесь уже вряд ли будет что-то новое. А вот автоматическая на неизвестном окружении — ммм…
Wordpress имеет встроенный загрузчик скриптов и правильно запиханный скрипт им подхватывается, к стати… жалко что не все фишечки вытащены в API.
В универсальном окружении — это упаковка на лету сервером или кэшем? тут куча подводных камней, например зависимость от браузера, версии и прочая интересная, но имхо совершенно излишняя работа. Потому как на условно среднем сайте самые длинные и замысловатые скрипты вянут на фоне загружаемых тонн графики. Но и кэшируются также хорошо браузером. Иногда даже слишком хорошо :)
В универсальном окружении — это упаковка на лету сервером или кэшем? тут куча подводных камней, например зависимость от браузера, версии и прочая интересная, но имхо совершенно излишняя работа. Потому как на условно среднем сайте самые длинные и замысловатые скрипты вянут на фоне загружаемых тонн графики. Но и кэшируются также хорошо браузером. Иногда даже слишком хорошо :)
графики на фоне скриптов загружается совсем не тонны. Например, характерное распределение неоптмизированного сайта
в данном случае еще неплохо было бы привести 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 маленьких.
Хоть в чём то IE следует стандартам...))
А в чем он не следует?
Все современные стандарты (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 и т.д.
>проблемы объединения Javascript-файлов
Главная проблема объединения, имхо, — критерий по которому нужно объединять. Например, если наиболее тяжеловесные скрипты (какая-нибудь сложная процедура регистрации или подачи объявлений) исрользуются одноразово или крайне редко — зачем их тащить в общую кучу?
Главная проблема объединения, имхо, — критерий по которому нужно объединять. Например, если наиболее тяжеловесные скрипты (какая-нибудь сложная процедура регистрации или подачи объявлений) исрользуются одноразово или крайне редко — зачем их тащить в общую кучу?
вот тут была неплохая статья на тему 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/
Читал давно. Особенно запомнилось:
«Спешу заверить — это легко5 решается вручную выделением 23 независимых групп со своими собственными ядрами.»
Это называется «жопа» :(
В идеале система объединения должна строиться на основе статистики по результатам тестирования/опытной эксплоатации. Директивная сборка все равно будет иметь большие зазоры.
«Спешу заверить — это легко5 решается вручную выделением 23 независимых групп со своими собственными ядрами.»
Это называется «жопа» :(
В идеале система объединения должна строиться на основе статистики по результатам тестирования/опытной эксплоатации. Директивная сборка все равно будет иметь большие зазоры.
да, Microsoft уже выкатило свое DOLOTO. Мы, наверное, тоже поднажмем и сделаем «интеллектуальное» объединение JS-файлов на основе статистики запросов. Но это не очень тривиальная задача :)
Она станет тем более нетривиальной, если туда включить информацию о поведении пользователей :)
Например сайт вакансий с тремя разными группами пользователей:
1) незалогиненные
2) залогниненные рекрутеры, размещающие вакансии и ищущие резюме
3) залогиненные соискатели, размещающие резюме и ищущие вакансии.
Например сайт вакансий с тремя разными группами пользователей:
1) незалогиненные
2) залогниненные рекрутеры, размещающие вакансии и ищущие резюме
3) залогиненные соискатели, размещающие резюме и ищущие вакансии.
для сжатия js я всегда использую хттп://bananascript.com/
попробовал им сжать, там как я понял он еще кроме уменьшения размера классическими методами (укорачивание имен переменных и т.д.) еще «обфусцирует» код?
остается открытым вопрос, сколько времени тратит браузер на раскодирование этой обфускации и будет ли там реальн выигрыш во времени — в реалиях совеременных скоростей интернета лишний килобайт может загрузится быстрее чем браузер распарсит этот скрипт.
как известно, классические методы сжатия, которые убирают комментарии, заменяют имена переменных и т.д., кроме скорости загрузки также увлеичивают производительность JS в браузере: за счет убора всего лишнего и уменьшения имен переменных JS-движок быстрее парсит файлы.
остается открытым вопрос, сколько времени тратит браузер на раскодирование этой обфускации и будет ли там реальн выигрыш во времени — в реалиях совеременных скоростей интернета лишний килобайт может загрузится быстрее чем браузер распарсит этот скрипт.
как известно, классические методы сжатия, которые убирают комментарии, заменяют имена переменных и т.д., кроме скорости загрузки также увлеичивают производительность JS в браузере: за счет убора всего лишнего и уменьшения имен переменных JS-движок быстрее парсит файлы.
он работает по принципу описанного Packer. Использовать не рекомендуется: на -2% после сжатия получите +100% на распаковку на клиенте.
имхо все кроме Google Compiler — половинчатые решения.
смысла сделать скрипт на 10кб меньше( и это для очень больших скриптов данные ) и иметь лого по размеру больше скриптов — фигня :)
А вот раскрытие в инлайн функций в гугле — она не только размер уменьшает, но и выполнение укоряет.
Местами мало, местами очень даже ничего
смысла сделать скрипт на 10кб меньше( и это для очень больших скриптов данные ) и иметь лого по размеру больше скриптов — фигня :)
А вот раскрытие в инлайн функций в гугле — она не только размер уменьшает, но и выполнение укоряет.
Местами мало, местами очень даже ничего
фишка в том что ваше лого не загрузится пока не загрузятся ваши скрипты если лого прописано как в а скрипты в просто потому что лого попадет в очередь загрузки позже, а загрузка JS блокирует загрузку всех остальных файлов.
поэтому, кстати, если способ клиентской оптимизации, когда все <script src=> переносятся в конец , что позволяет не тормозить очередь загрузки и быстрее прогружать клиентскую часть страницы (картинки, css, etc) а потом только подгружать скрипты.
поэтому, кстати, если способ клиентской оптимизации, когда все <script src=> переносятся в конец , что позволяет не тормозить очередь загрузки и быстрее прогружать клиентскую часть страницы (картинки, css, etc) а потом только подгружать скрипты.
если для клиента загрузка лишних 10кб может вызвать проблему — тогда об этом можно уже особо не париться :)
Тут лучше не брутфорсом подходить а хитростями
хинт:
в начале страницы начинаем загрузку скриптов как обычных файлов через ajax
по готовности делаем им eval или инжекстив в тело тутже созданого script тэга.
что получаем — асинхронную загрузку скрипта, котороая и в конце страницы нас не задержит
Тут лучше не брутфорсом подходить а хитростями
хинт:
в начале страницы начинаем загрузку скриптов как обычных файлов через ajax
по готовности делаем им eval или инжекстив в тело тутже созданого script тэга.
что получаем — асинхронную загрузку скрипта, котороая и в конце страницы нас не задержит
если просто разместить все скрипты в конце страницы ээфект будет почти какой же как если делать вашим способом, с той разницей что ваш способ может не сработать если не подгрузились какие то билиотеки, которые нужны для работы скриптов, которые уже подгрузились.
Я в курсе этого хинта, только у него есть дополнительные сложности — надо знать «зависимости» каждого из подгружаемых скриптов и евалить их только при удовлетворении этих зависимостей.
насчет лишних 10кб — если 10кб скриптов будут грузится до картинок то клиент вместо, например, фото товара, ничего не увидит.
в интернете есть интересная статистика, в которой говорится так же о том, что уменьшение времени загрузки на 100мс у амазона сразу отразилось на продажах — продаж стало на 1% больше. 1% клиентов это неплохой прирост для 10кб скрипта, не считаете? :)
Я в курсе этого хинта, только у него есть дополнительные сложности — надо знать «зависимости» каждого из подгружаемых скриптов и евалить их только при удовлетворении этих зависимостей.
насчет лишних 10кб — если 10кб скриптов будут грузится до картинок то клиент вместо, например, фото товара, ничего не увидит.
в интернете есть интересная статистика, в которой говорится так же о том, что уменьшение времени загрузки на 100мс у амазона сразу отразилось на продажах — продаж стало на 1% больше. 1% клиентов это неплохой прирост для 10кб скрипта, не считаете? :)
speedupyourwebsite.ru/books/speed-up-your-website/online/SpeedUpYourWebsite.v1.4/outline_11.htm
вот нашел ссылку на материал
вот нашел ссылку на материал
Я бы ещё добавил, что все компрессоры, начиная с самых слабых, полностью вырезают комментарии. Как результат, количество комментариев никак не влияет на размер сжатых файлов. Если использовать только GZip, такого эффекта не получится.
Я для себя решил, что лучше всего вырезать комментарии, немного минифицировать, слить скрипты в один и сжать gzip-ом.
Сливает скрипты в один и минифицирует его замечательная штука django-assets ( https://launchpad.net/django-assets ). И то же самое делает с CSS.
Там нет никакого движка — это обертка. Сильно автоматизированная.
Там нет никакого движка — это обертка. Сильно автоматизированная.
Недостатки компрессоров из моего опыта:
1) JSMin — ломает скрипты на раз, кроме того медленный, так как парсит скрипт посимвольно
2) Dean's Packer — требует после всех функций, и не только, ставить точки с запятой (а в яваскрипте, что конечно плохо, есть автоподстновка этой самой точки с запятой)
3) Ну YUIComprssor — ставить например на VPS с 256 Мб Яву — дикость.
Так как менять привычки и ставить всюду точки с запятой было лень :), проще оказалось написать свой маленький компрессор, который сохранял частично переводы строк (и иногда пробелы) и не ломал автоподстановку. Кроме того, он работал на регекспах, довольно-таки неплохо.
Конечно, жал он хуже упомянутых здесь скриптов, но ненамного, а главное что комментари резал и пробелы сжимал, что и требовалось :) К тому же все равно в итоге скрипты жмутся gzip, так что разница становится еще меньше.
1) JSMin — ломает скрипты на раз, кроме того медленный, так как парсит скрипт посимвольно
2) Dean's Packer — требует после всех функций, и не только, ставить точки с запятой (а в яваскрипте, что конечно плохо, есть автоподстновка этой самой точки с запятой)
3) Ну YUIComprssor — ставить например на VPS с 256 Мб Яву — дикость.
Так как менять привычки и ставить всюду точки с запятой было лень :), проще оказалось написать свой маленький компрессор, который сохранял частично переводы строк (и иногда пробелы) и не ломал автоподстановку. Кроме того, он работал на регекспах, довольно-таки неплохо.
Конечно, жал он хуже упомянутых здесь скриптов, но ненамного, а главное что комментари резал и пробелы сжимал, что и требовалось :) К тому же все равно в итоге скрипты жмутся gzip, так что разница становится еще меньше.
первый отработал, второй сломался
если сделать так как ты сказал, то первый отработает ещё раз, что черевато
если сделать так как ты сказал, то первый отработает ещё раз, что черевато
было бы хорошо писать более развернутые комментарии, понятные не только их автору :)
первый скрипт из пакета, второй, третий…
понятное дело, что чревато. Но обычно скрипты не настолько критичны к окружению — можно допустить, чтобы по два раза отрабатывали. Главное, чтобы отрабатывали.
А полностью исключить двойную обработку — имхо, слишком «дорогая» задача.
А полностью исключить двойную обработку — имхо, слишком «дорогая» задача.
ещё как критично. лучше, если скрипты вообще не отработают, чем буду работать кое как
У нас разный взгляд на критичность: для миллионов леммингов лучше двойной обработчик событий пусть навесится, и jQuery два раза проинициализируется, чем «галерея развалится».
Для разработчиков — пусть уж лучше галерея развалится (будет понятно, что чинить), чем такая слабо детектируемая фигня с утечками случится.
Вы посмотрите на проблему с разных точек зрения.
Для разработчиков — пусть уж лучше галерея развалится (будет понятно, что чинить), чем такая слабо детектируемая фигня с утечками случится.
Вы посмотрите на проблему с разных точек зрения.
LightSpeed — o_O => lighttpd
поправьте ссылку — webo.in/articles/habrahabr/11-minifing-javascript/
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблемы сжатия и объединения Javascript