Есть ли смысл в минификации JavaScript, если у вас включено сжатие?

Если на вашем веб-сайте включено сжатие deflate / zip, есть ли смысл в минификации JavaScript?

Моя теория заключается в том, что разница между сжатым минифицированным файлом JavaScript и сжатым неминифицированным файлом JavaScript незначительна.

Осталось очень мало браузеров, которые не поддерживают сжатие. Я предполагаю, что некоторые боты (пауки) могут не поддерживать сжатие (я знаю по крайней мере об одном), но они вряд ли будут «заинтересованы» в вашем JavaScript, поскольку они вряд ли будут выполнять JS и поэтому не должны его загружать.


javascript minify
person Guy    schedule 13.07.2010    source источник
comment
См. Сравнение Gzip и minify.   -  person Matthew Flaschen    schedule 13.07.2010
comment
Минификация будет вырывать комментарии, уменьшая размер по сравнению с тем, что может сделать сжатие в одиночку.   -  person Frank Schwieterman    schedule 13.07.2010
comment
minified будет быстрее анализировать на клиенте и сэкономит больше места, чем только сжатие   -  person    schedule 13.07.2010

Ответы (8)


arrow_upward
29
arrow_downward

Давай просто проверим. Я использовал jQuery 1.4.2 и gzip (без флагов; -9, похоже, не имеет существенного значения), чтобы получить следующие числа.

  • Разработка: 163 855 байт
  • Разработка, сжатие: 45 994 байта
  • Минимизировано: 72 174 байта
  • Уменьшено, сжато: 24 565 байт

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

  • Удалено: 131 155 байт
  • Разрезано, сжато: 32 914 байт

Это все еще значительно больше, чем у минифицированной версии.

person Thomas    schedule 13.07.2010

arrow_upward
2
arrow_downward

Минимизация файла перед его сжатием немного повлияет на производительность сервера, хотя я сомневаюсь, что это в сумме дает много. Минификация удалит комментарии, которые не удаляются с помощью gzip / deflate, но в остальном я бы сказал, что вы правы.

Конечно, всегда есть IE6. По моему опыту, этот браузер ненадежен, когда дело доходит до gzip-архивирования чего-либо, кроме text / html. Это почти доходит до того, что это не имеет значения, поскольку использование IE6 продолжает падать.

person JAL    schedule 13.07.2010
comment
Это почти до того момента, когда это не имеет значения? Я хочу, чтобы мои клиенты придерживались того же мнения. Это похоже на несколько беременный стереотип: пока хотя бы один из ваших клиентов настаивает на поддержке IE6, вы должны поддерживать его. Я бы хотел, чтобы Microsoft как-то форсировала эту проблему и полностью избавилась от нее. - person Robusto; 13.07.2010
comment
Конечно, если вы выполняете работу с клиентами, это их дело. Если нет, то это ваше усмотрение - в последнее время только 2,5% посетителей сайтов, с которыми я работаю, используют IE6. Мы до сих пор поддерживаем это, но, вероятно, если бы мы этого не сделали, эффект был бы не очень большим. Я думаю, что примерно через год перестану об этом беспокоиться. - person JAL; 13.07.2010
comment
MS может помочь решить проблему, предложив бесплатные обновления старых версий InfoPath до InfoPath 2010. Я вижу InfoPath во многих строках пользовательских агентов IE6 из корпоративного мира (через сайт, на котором все еще около 30% IE6 ‹strike› проигравших. ‹/Strike› пользователей). Судя по всему, если вы установите IE7 со старым InfoPath, все сломается. - person Matt; 24.08.2010

arrow_upward
2
arrow_downward

Я попытался заархивировать jquery-1.3.2 как в исходной, так и в минифицированной версии:

jquery-1.3.2.js      118 kb  ->  36 kb
jquery-1.3.2.min.js   56 kb  ->  20 kb

Таким образом, минимизация перед сжатием имеет существенное значение.

person Guffa    schedule 13.07.2010
comment
Это интересно. Есть ли какие-либо предположения о том, почему это может быть, кроме удаления комментариев? - person JAL; 13.07.2010
comment
Минификация делает код более однородным, а это означает, что его можно лучше сжать. У вас меньше шума (длинные имена переменных) и больше одинаковых символов ()[]{} и т. Д., Что обеспечивает более высокую степень сжатия, точно так же, как файл, полный нулей, в конечном итоге будет маленьким при сжатии, чем файл с фактическими данными (это еще не все нули и т. д.) - person Ivo Wetzel; 13.07.2010
comment
Конечно, если вы используете минимизацию, которая переименовывает переменные, это имеет смысл. Разве это не что-то вроде компилятора Closure? Я думал о типе, который удаляет только пробелы и комментарии. - person JAL; 13.07.2010

arrow_upward
1
arrow_downward

Я считаю, что миниатюрная версия будет работать быстрее. Переменная теперь имеет длину 1-2 символа, поэтому синтаксический анализ выполняется быстрее, пробелы и комментарии не являются проблемой. Конечно, вам нужно будет разработать тест, чтобы действительно определить любую разницу.

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

- Дэйв

person the Hampster    schedule 13.07.2010

arrow_upward
0
arrow_downward

На счету каждый байт. Чем больше вы экономите, тем лучше.

person Ashit Vora    schedule 13.07.2010

arrow_upward
0
arrow_downward

Вы также можете использовать компрессор / упаковщик JavaScript, который использует что-то вроде кодировки base-62 (например, this).

Он может превратить 72174 байта (jquery-1.4.2.min.js) примерно в 50640 байтов. Однако его дальнейшее сжатие не улучшит сжатие по сравнению с прямым сжатием минифицированного файла (тоже 24 КБ).

(Вам также может потребоваться сохранить заголовки лицензий, если вы используете компрессор / упаковщик, около 400 байт в этом примере).

person Bruno    schedule 13.07.2010
comment
Не используйте компрессор JavaScript; передаваемый файл будет иметь примерно такой же размер, но он загружается медленнее, так как распаковка в JavaScript выполняется способом медленнее, чем распаковка с использованием собственного GZip. См. ericmmartin.com/comparison-of-javascript-compression-methods - person Marcel Korpel; 13.07.2010

arrow_upward
0
arrow_downward

Посетите сайт разработчиков Yahoo - http://developer.yahoo.com/performance/rules.html - для некоторого объяснения того, почему минификация вместе со сжатием - это хорошо. Также проверьте все, что написал Стив Содерс (высокопроизводительные веб-сайты - отличный сайт и книга!) .

Я бы избегал запутывания, если вы действительно не хотите выжать из своих скриптов как можно больше. Обфускация, в зависимости от того, как вы написали свой JavaScript, может привести к ошибкам. Возможно, вам будет лучше просто минимизировать и пройти 80-90% пути.

Удачи!

person David Hoerster    schedule 13.07.2010

arrow_upward
0
arrow_downward

Помните, что минификация на самом деле отбрасывает информацию. Пробелы / комментарии / длинные имена переменных / и т. Д. полностью отбрасываются (и не могут быть восстановлены).

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

Следовательно, серверное сжатие не может (теоретически) достичь тех же уровней сжатия, которые может достичь минификация (теоретически).

Помните, что хотя теория и практика теоретически одинаковы, на практике < / em> никогда не бывает. :-)

person loneboat    schedule 13.07.2010