Ресурсы в архиве или как уменьшить количество подгружаемых файлов

[@JDima]

А чем это лучше GZIP и переиспользования одного TCP соединения для множества GET запросов?

[@Demogor]

GZip не всегда работает. Кроме того, описанный способ позволяет выбирать файлы для упаковки.
Про 2 — можно поподробнее?

[@LordMerlin]

Как уже сказали, GZIP можно и нужно использовать для уменьшения объема передаваемой информации. И ваш метед в этом слкчае не чуть не лучше, кроме случая если вы будете использовать более сильный алгоритм сжатия.
А задержки на переоткрытие кучи коннектов как раз и решает механизм повторного использования ТСР соединения для передачи всех фацлов. То есть утрировано к серверу откроется всего одно соединение по которому пеиедадутся все данные без переконнекта на каждый файл.

[@Demogor]

Ссылку на описание можно? Через что реализуется?

[@Fesor]

SPDY и вроде как в HTTP2 планируется это же.

[@qw1]

Реализуется через http-заголовок Connection: Keep-Alive, см. RFC 2068

[@Demogor]

Благодарю)

[@isden]

Подозреваю, что передать один файл вместо сотни будет в любом случае быстрее. Хотя сильно подозреваю, что это экономия на спичках и проблемы с архитектурой приложения.

[@extempl]

Некоторые хостинг-площадки дополнительно считают кол-во запросов. Там это определённо не спички.

[@isden]

Имхо, бежать нужно с таких площадок. Это уже совсем за гранью добра и зла.

[@extempl]

Ну почему же? А облачный хостинг? Он ничем не хуже, там просто другие правила экономии.

[@isden]

Эм. А можно примеры хостингов, где тарификация включает в себя количество запросов?
S3 — не в счет.

[@Demogor]

www.1gb.ua/default.aspx?hti=92&ti=6

[@isden]

Извините, но с такими ограничениями я все еще придерживаюсь вышеозвученного мнения.

[@Demogor]

В этом плане — согласен, хотя если на странице штук под 100 разного плана картинок, js'ок и css(к примеру, на моей странице вконтакте 106 запросов пришло) и посещаемость сайта хотя бы 1000 человек в день(даже если они открывают страницы 1 раз в день), то их
«Веб-сервер Apache
Статический сайт/контент (html, jpg/gif, …) 50 000 – 150 000»

начинает вызывать смутные сомнения.

[@rekby]

Это не ограничение по количеству запросов, а очень приблизительный ориентир — сколько запросов какую нагрузку на процессор создает.

В тарифе указывается именно % процессорной нагрузки, а дальше всё зависит от того как сайт написан. Сами запросы 1Гб не считает и не ограничивает.

[@Demogor]

Понятно, спасибо.

[@extempl]

Вроде у селектела очень гибкая тарификация в плане «платишь за потребление», где учитывается буквально всё.
Кроме того, спрайты, в частности, ещё и исправляют совсем некрасивые подзагрузки при наведении и прочих действиях.
+ время на открытие запроса на получение каждого файла в больших объёмах значительно увеличивает время загрузки. Выше написали про переиспользование коннекта, я об этом как-то не слышал раньше, нужно будет вникнуть подробнее.

[@isden]

Емнип, у селектела запросы считаются только к ихнему cloud storage, что как-бы не хостинг.

[@Demogor]

Кстати, а подход с упаковкой в архив позволяет отказаться/уменьшить количество спрайтов. Да и подгружается сайт при медленном коннекте не рывками, а единовременно(если не паковать гигибайтное видео в тот же архив, конечно).
Хотя вот про реюз соединения тоже в 1 раз слышу, если он прост в использовании, то действительно является отличным решением.

[@JDima]

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

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

[@Demogor]

Естественно, даже в тестовой версии сделал простенькое окно загрузки) И да, согласен с замечанием — применения загрузчика в итоге не дает разницы между обычной подгрузкой и подгрузкой 1 файлом.

[@extempl]

Зависит от того с чем сравнивать. Несколько секунд — это когда уже совсем всё плохо.

[@IkaR49]

… не стоит паковать динамический контент или большие файлы ...

Ну ладно, большие файлы ещё не страшно, но учитывая проблемы с динамическим контентом — то вся идея теряет свои преимущества. Тогда уж можно CSS встроить в тело HTML, а изображения вставить в виде base64, а потом сжать GZip'ом.

[@Vest]

Закрадывается мысль, что мы получим на выходе пакет PhoneGap или Cordova :)

[@Demogor]

… сжатый в zip.

[@Demogor]

У base64 минус — увеличивается размер. На мелких файлах не критично, но все же.
Для крупных файлов метод, в принципе, использовать можно… но если есть крупные файлы на странице — то это уже проблема архитектуры)
Для динамического контента можно тоже использовать, но только если для большого количества единовременно подгружаемых элементов.
Для стриминга способ явно неприемлем.

Но вообще, ему вполне может быть найдено применение — к примеру, если сайт нужно просматривать через прокси, который не поддерживает gzip.

[@IkaR49]

Даже с простым динамическим контентом (не стриммингом) будет проблема, так как потребуется дополнительное время на запаковку и распаковку. Возможно будет даже быстрее просто скачать это всё в живом виде, нежели в архиве. Надо проводить тесты производительности, в том числе на мобильных телефонах.

[@Demogor]

Ну вот для интереса забил произвольным текстом css на 4.77 метра. ZLib на хосте включен.
Время упаковки архива — около 0.1 секунды. Размер архива — 19кб.
Zlib'ом пожатая либа весит 27.9кб.
В принципе, сказать, что бы сильно большая разница была — так нет, разве что в пропорциях сравнивать)

[@IkaR49]

Я больше волнуюсь за мобильные платформы: как они будут архивы распаковывать.

[@Demogor]

Под android Blob'ик сдох.
Впрочем, через BlobBuilder заработал, css'ка распаковалась и подгрузилась.
Изображения и js'ка исдохли, надо смотреть, почему.

[@Demogor]

Ан нет.
Обновил браузер — все разом заработало через Blob. Так что для мобильных платформ способ также подходит, по крайней мере, для android.

[@cy-ernado]

Советую посмотреть в сторону SPDY и PageSpeed от гугла. Есть модули для nginx и apache. Использую на продакшене в одном проекте. Для использования придется скомпилировать nginx с этими модулями и добавить их в конфигурацию.

[@Demogor]

Возможно, хорошие штуки, но не всегда есть выделенный сервер и возможность менять конфиги.

[@cy-ernado]

Согласен, более того, не всегда есть возможность перекомпилировать nginx.
В моем случае nginx разворачивается через docker, и добавить эти модули было тривиально.

[@Demogor]

В любом случае, спасибо за совет)

[@igordata]

Я думаю минусы происходят от костности мышления. Автор не постулирует данный алгоритм на замену gzip'ования трафика. Данный подход еще надо осмыслить. Очевидно он будет иметь свои плюсы в каком-то узком классе задач. Я пока не понимаю, где именно. Но возможно например на интерфейсах, которые должны после загрузки страницы какое-то время работать в браузере без связи с сетью, например. Или возможность быстро откатить какие-то измения, например при работе в графическом онлайн редакторе. Хотя мне в голову не придёт так насиловать браузер и редактировать многослойный файл онлайн, тем не менее в XXI веке можно встретить онлайн-воплощение практически любой фантазии.

Наверное, стоит воспринимать этот способ не как имеющий своей целью сжатие, а скорее как нацеленный на передачу кучки файлов в архиве с возможностью оперировать ими на клиентской стороне в браузере. Когда это может понадобиться и кому — я не знаю. Но если кому-то по какой-то мистической причине окажется удобнее работать с одним архивом, то вот он способ. Описан и опробован.

И уж всяко, не зависимо от того, согласны вы с тезисом статьи или нет, этот материал более достоин Хабра, чем материал про то, как делать панораму одной кнопкой на автомате.