Стоит ли минифицировать и склеивать файлы, если есть http2 и gzip?

Question

[JunDevTest]

Приветствую вас.
Вот недавно занялся поиском утилиты или скрипта для слеивания и минификации CSS и JS файлов и задумался над целесообразностью сего действа в наше время, когда есть GZIP и HTTP2. Кроме того, действительно ли такая оптимизация в наше время важна? Если да, то посоветуйте нормальные, не "смузи-хипсторские" решения, которые не требуют отдельного сервера с целым зоопарком технологий в придачу?

Answer 1

[Евгений Вольф]

Стоит ли минифицировать и склеивать файлы, если есть http2 и gzip?

GZIP тут играет довольно малую роль, к тому же, он был (и есть) и в HTTP1.0/1.1. К минификации он тоже никак напрямую не относится, от слова совсем. Минифицированные файлы становятся меньше с GZIP'ом, в сравнении с неминифицированным, сжатые тем же GZIP'ом (при прочих равных условиях).

Кроме того, действительно ли такая оптимизация в наше время важна?

Это риторический вопрос. Что-то из области: "Действительно ли так важен мизинец на ноге, или можно его отрезать?"

Если да, то посоветуйте нормальные, не "смузи-хипсторские" решения, которые не требуют отдельного сервера с целым зоопарком технологий в придачу?

Единственная известная мне технология, которая требует какого сревера - это модуль "Google PageSpeed", который подключается к Apache'у или "вкомпилировывается" в Nginx. При этом, отдельного сервера он не требует, достаточно того, что установлен в 95% случаев (Nginx и/или Apache). Но, Вы приспокойно можете минифицировать и сжимать файлы и без него, используя для этого массу готовых решений которые не требуют вообще никакого сервера и работают обычно локально, например решения на базе NodeJS (gulp) - модулей просто тонны, но если хотите, могу поискать за Вас. А так же, есть масса онлайн-сервисов занимающихся тем же самым, которые так же, не требуют наличия чего либо, кроме разве что браузера.

P.S. Gulp (и прочие подобные ему инструменты) умеют так же и склеивать JS и "сжимать" картинки и минифицировать CSS и проводить массу действий подобного характера, в зависимости от Ваших потребностей. "Настроить" достаточно 1 раз, потом можно использовать готовую болванку в неограниченном кол-ве проектов.

Comments

[batyrmastyr]

Вангую, что под "целый сервер с зоопарком технологий" нода подходит намного больше, чем модуль ngx_pagespeed, с его установкой в 3 команды + 6 строк настроек.

[Евгений Вольф]

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

[batyrmastyr]

Евгений Вольф, для большинства языков и так уже есть свои библиотеки для сборки и минификации css и js, поэтому, например, установка ноды (требующую сотни мегабайт оперативки и места на винте ради сжатия пары сотен килобайт js) - перебор для всех, у кого она уже не стоит по той или иной причине. Точно так же перебор ставить джаву только ради yui compressor.

[Евгений Вольф]

batyrmastyr, в предыдущем комментарии, говоря о "ноде для сжатия JS/CSS" - я имел в виду не исключительно эти задачи, а эти задачи в том числе, так как два наиболее популярных сборщика (или даже три, если взять во внимание ещё Grunt), а именно Gulp и Webpack - написаны в виде модулей NodeJS, а так же в виде подобного модуля написаны, например, такие полезные вещи как BrowserSync и масса других, не менее полезных плюшек, добрую половину которых, на других языках я либо не встречал вообще, либо не видел ни на одной из других платформ полностью автономного, полноценного и самодостаточного стека для задач подобного рода (под такими задачами, я подразумеваю, нечто более чем вёрстку одной-двух примитивных страниц без надобности поддержки оных в дальнейшем, тестирования и т.д.).

По поводу "сотен мегабайт оперативки" - в полном обвесе, в режиме сборки - я смог заметить потребление ~200Мб памяти, а в режиме постоянной работы ~300Мб памяти... не вижу в этом вообще никаких проблем, планка памяти на 2Гб стоит примерно столько же, сколько час работы не самого квалифицированного программиста, а дисковое пространство - ещё меньше. При том, что IDE на "холостых оборотах" может легко потреблять 1Гб и более памяти.

Но, если в каком-то отдельном (Вашем) случае, всё строго наоборот и труд программистов стоит очень дешево, а лишний гигабайт памяти - очень дорого - могу предложить решение и конкретно для этой ситуации:
1. Арендуете VPS за 1-5$ (в зависимости от того, насколько позволяет бюджет) с 1Гб оперативной памяти
2. Поднимаете там полноценный сервер для сборки (1Гб памяти ему хватит вполне)
3. Пробрасываете туда файловую систему проекта, каждого из участников команды
4. Сервер отслеживает изменения, делает сборку, выгружает готовые файлы обратно потребляя килобайты памяти на поддержку TCP-соединения, и не затрагивая оперативную память несчастных

А если про подсчёт памяти (оперативной и постоянной) речь идёт очень жестко - можно вместо рабочих мест всем раздать тонкие клиенты (вообще без HDD), подключаться и работать прямо на удалённом сервере, вооружившись консольным редактором, типа vi(m)'а, в этом случае, экономия памяти и дискового пространства будет максимальной.

[batyrmastyr]

Евгений Вольф, на серваке на помять почти пофиг (реже вебпаков с гульпами там только миграции БД запускаются), а вот на рабочих машинках всё намного грустнее. И вот тут десяток запущенных в докере проектов выливаются в весьма нескучную цифру.
Просто как-то глупо получается, что сборщик js и css тратит по минуте на элементарные вещи и жрёт в 5 - 10 раз памяти больше, чем основной код (последнего на порядок - два раз больше) и база данных вместе взятые. Извините, но я очень не люблю жирнософт в любых его видах, включая жрущую от гига до двух среду разработки.

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

[Евгений Вольф]

Просто как-то глупо получается, что сборщик js и css тратит по минуте на элементарные вещи и жрёт в 5 - 10 раз памяти больше, чем основной код (последнего на порядок - два раз больше) и база данных вместе взятые

Я пока не очень представляю, какого объёма должны быть постоянно изменяющиеся части JS + CSS и/или насколько всё должно быть спроектировано безграмотно и/или насколько должен быть слаб рабочий компьютер, что бы сборка всего хотя бы отдалённо могла приблизиться к минуте, в частном случае, промежуточная пересборка изменившихся частей кода обычно укладывается в интервал времени менее секунды (лично у меня).

Касательно "сборщик жрёт в 5-10 раз больше чем основной код и база вместе взятые" - если сборщик потребляет, до 300Мб (как я уже писал выше), соотв., число в 5-10 раз меньше будет составлять 30-60Мб... Если основной код "жрёт", скажем, мегабайт 10... На базу остаётся 20-50Мб... Я пока не встречал баз настолько микроскопического размера, которые свободно бы помещались и работали в столь ничтожном объёме памяти, по этому, как либо прокоментировать это не могу.

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

Вёрсткой обычно занимаются на вполне конкретных языках: HTML, CSS, JS. О каких именно "других" языках Вы говорите - я пока не понимаю.

Answer 2

[Moskus]

Как всегда, вопросы на эту тему недоформулированы или содержат термины, которые не определены.
Если под минификацией JS подразумевать самую простую ее форму, то есть удаление пробелов и комментариев (которых у вас в коде может и не быть), эффект от такой минификации после сжатия gzip стремится к нулю, потому что архивация данных устраняет избыточность, пусть и не полностью. Многие решения, которые работают в виде онлайн-сервиса с формой, куда надо вставлять код, занимаются именно такой имитацией минификации.

Если под минификацией JS подразумевать использование более совершенных методов (например, то, что умеет https://github.com/mishoo/UglifyJS2 ), таких, как переименование функций и переменных, удаление из кода готовых библиотек тех функций, которые не вызываются, и так далее - это может давать существенный эффект.

То же касается CSS.

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

Answer 3

[batyrmastyr]

В плане сжатия js, в первую очередь нужно ускорять разбор и выполнение кода т.к., условно, 10 кб js могут быть хуже пары мегабайт картинок (https://medium.com/dev-channel/the-cost-of-javascr... ). В общем, Moskus прав - удаление пробелов и комментариев из кода мало что даёт, а удаление ненужного кода + переименование функций и переменных заметно уменьшает размер файла.
Но будьте осторожны: если минификатор идёт дальше и прикидывается архиватором (например, Packer от Dean Edwards's или webpack с его тысячами eval'ов !function(F,Q){for(var B in Q)F[B]=Q[B]}(global,webpackJsonp([0], {"use strict";eval("var __WEBPACK_AM), то вы не ускорите работу, а наоборот добавите тормозов на клиенте.

Answer 4

[Дмитрий Беляев]

добавлю к вышесказанному про http/2:
без "умных" server-push бандл содержащий весь код сайта для каждой страницы будет грузится быстрее отдельных модулей, даже если Вы грузите их далеко не все.
просто представьте, вы грузите html -> он обрабатывается -> начинает грузить стили, картинки и главный модуль js -> js обрабатывается -> грузит еще 5 модулей, которые после обработки грузят еще 50 модулей
а теперь просто подумайте - у Вас сотня файлов, которые грузятся параллельно в одном tcp потоке, к тому же обернутом в tls - что добавляет. оверхед на шифрование и дешифровку + добавим сюда оверхед на парсинг js, который будет задерживать сеть, а сеть его

выхода из этого 2
- или по прежнему отдавать все одним бандлом
- или настраивать push, но с этим тоже траблы, ибо помимо вычисления файлов нужных начальному запросу (хоть и сложно, но вполне реально), нужно предсказывать, а что у браузера уже в кэше (ошибемся - получим или начальный оверхед (не отдали нужное) или сожрем лишний трафик (отдали ненужное))

Answer 5

[profesor08]

babel + uglifyjs = нормальный минифицированный код, который работает в большинстве браузеров. Так-же опционально можно добавить полифиллы.

Answer 6

[lukoie]

CodeKit поглядите. Он делает всё сам и шустро, и не требует кучи всего вдовесок.