Как передать веб-клиенту большое количество изображений?

Question

[nikegk]

Всем привет.
На сайте есть слайдер, в котором используется достаточно большое количество изображений, 100-150 шт. Подскажите пожалуйста, как правильно будет хранить и передавать эти изображения веб-клиенту? Хочется минимизировать количество запросов и увеличить скорость.

Сейчас данные хранятся в папке сайта и передается путь к изображению в тег . js фреймворком подставляется путь к нужной картинке. Картинка подгружается после смены пути.

Comments

[d'Ivan]

Какой сервер используется для отдачи статических файлов?

[nikegk]

Роман Мирр: Разрабатывается на локальной из под nodejs webpack-dev-server. Продакшен не знаю на чем будет.

Answer 1

[Valeriu Vodnicear]

Можно использовать например OWL slider.
И указать:

{
     lazyLoad: true
}

Comments

[nikegk]

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

[kn1ght_t]

nikegk: нет, прочитайте про lazy load

Answer 2

[xmoonlight]

1. Можно склеить общую подложку (которая будет одинакова для всех изображений), а отличия (т.е. добавку) - грузить отдельно "довеском" на подложку, получая нужное изображение.
Таким образом - удастся уменьшить значительно общий размер изображений, если они имеют много похожестей и один размер "полотна", т.к. "довесок" - это только уникальное отличие данного изображения от всех остальных в текущем слайдере.
2. Общую "подложку" и "довески" - грузим как единый поток бинарных данных и восстанавливаем в нормальные изображения на клиенте, помещая результат в слайдер.

Чтобы это реализовать, Вы должны представить данные всех изображений в виде "дерева", где каждый узел такого "дерева" содержит добавочные данные. Можно использовать Код Хаффмана.

"Подложка" - самый длинный общий фрагмент изображения, присутствующий на всех изображениях (координаты X,Y и цвета RGB).
"Довески" - незначительные различия между изображений с общей "подложкой" (ветви "дерева").

UPD: facebook.github.io/zstd

Comments

[nikegk]

А как это реализовать?
И как я понимаю количество запросов от этого сильно не уменьшится? Изменится только сам размер изображений.

[xmoonlight]

nikegk: запрос для всех изображений будет ОДИН ЕДИНСТВЕННЫЙ! Как реализовать?! Ну это уже не ко мне - я и так дал алгоритм)

[xmoonlight]

Никита Полевой: дописал в ответ... про "дерево" - схемка анимированная на википедии есть..

[Kovalsky]

xmoonlight: ну это-то я понял, окей, подложка это самый длинный общий фрагмент изображения. А что из себя представляет эта подложка в случае если различия значительные?

[xmoonlight]

Никита Полевой: подложка - это не фрагмент! Это набор данных каждый пиксель - это 5 параметров: XY (позиция пикселя) и RGB (составной цвет).
Возможна ситуация, что общий цвет у всех в этой позиции у пикселя, например, синий, а оттенки - разные для разных изображений (или смешение оттенков). Понимаете?

[Kovalsky]

xmoonlight: идею, мне кажется, я понял. Но также мне кажется, что чем более различаются картинки и чем их больше, тем больше к нулю сводится преимущество использования такого подхода, нет?

[xmoonlight]

Никита Полевой: ну глазами Вы не определите, т.к. всегда есть цветосмешение и одинаковые крупные куски данных для всех изображений могут быть таким изображением, которое Вы никогда не сможете представить даже из 2-х картинок.

[Kovalsky]

xmoonlight: а можете привести пример? Может быть есть уже в интернетах реализации.

Потому что, при всём уважении, вижу выигрыш в количестве запросов, но не вижу никакого профита в плане сжатия/экономии: для расчёта конечного цвета всё равно потребуется информация о всех цветовых компонентах. Это будет просто лишний фильтр. То есть в худшем случае клиенту придётся скачать то же количество информации. С таким же успехом можно просто передавать клиенту картинки склеенные в поток.

Или я чего-то тотально не понимаю?

[xmoonlight]

Никита Полевой: последний пункт - Вы точно угадали.
Посмотрите еще раз код Хаффмана на википедии. Задача - найти одинаковые части на всех изображениях и унифицировать в единую, а отличающиеся - соединить через "дерево". Когда нужна картинка - основная - для всех одна, а дополнительная - несколько байт.

[Kovalsky]

xmoonlight: а примеров нет готовых, может встречали? Если и правда существует какой-то профит от этого, было бы странно если бы никто это не реализовал даже для такой задачи.

Или... можете придумать сферический пример с изображениями не больше чем 4x4? А я попытаюсь реализовать. Я почти уверен, что выигрыша никакого

[xmoonlight]

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

[Kovalsky]

xmoonlight: "Возможна ситуация, что общий цвет у всех в этой позиции у пикселя, например, синий, а оттенки - разные для разных изображений" - то есть речь только лишь о том вакуумном случае когда в _основной_ картинке какой-то конкретный пиксель содержит в себе либо 1, либо 3 компонента, необходимых для расчёта цвета соответствующего пикселя изображения, а остальные компоненты берутся из _дополнительного_ изображения?

[Дмитрий]

nikegk: ерунду он вам советует. Высокотехнологичную, сложно реализуемую, неудобную в поддержке ерунду. Плюс совсем вам не нужную.

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

Первый вариант, слить все в один спрайт, вам не подойдет. Так как картинок у вас много, итоговый вес и размер полученного изображения будет огромный. Он будет грузится долго и памяти такая картинка отъест прилично.
Разновидность этого варианта, которую он предлагает, для слайдеров не используют. Потому как у настоящих 100 фотографий общей подложки может и не быть.
Такой подход используют для создания вот такой анимации https://paneralandofclean.com/
Там и подложка есть, и отдельные спрайты с кусками анимации вроде вот такого https://prod-cdn.azureedge.net/20160828013219_1_0_...

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

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

Ускорить загрузку картинок вы можете оптимизировав их вес и разместив их на CDN

[xmoonlight]

Дмитрий: да если бы не ерунду - то согласен: проще делать "окно": грузим два слева, два справа и отображаемый центральный. А дальше при перелистывании - догружаем, но это не уменьшит кол-во соединений.
Хотя можно грузить по 5 в ряд) Но! Это сложно и ерунда)

[Дмитрий]

xmoonlight: и в чем смысл грузить 5 картинок в ряд?
в чем будет выгода такого для живого сайта?

так то можно вообще страницу всю на стороне сервера в картинку рендерить и пользователю ее выдавать - будет вообще 1 запрос. но зачем?

[xmoonlight]

Дмитрий: хотят меньше запросов - можно "окнами" уменьшить это количество.

[Дмитрий]

xmoonlight: совет звучит как лечить насморк усечением головы.

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

[xmoonlight]

Дмитрий: да вообще поднимать эту тему - ерунда) я бы циклом сделал бы по кликам и всё...

[Дмитрий]

xmoonlight: так зачем тогда такое другому советовать?

[xmoonlight]

Дмитрий: это сложно, однако, совсем не ерунда, т.к. позволяет экономить и трафик и кол-во потоков.
Действительно, что при таком объёме фотографий - нужно всё-таки как-то прибегать к какой-никакой ОПТИМИЗИРОВАННОЙ доставке.
Согласны?

[Дмитрий]

xmoonlight: не согласен.
Повторюсь - полная ерунда.

Как пример, вот несколько картинок:
i.imgur.com/iWKad22.jpg
i3.kym-cdn.com/photos/images/newsfeed/000/284/709/...
301-1.ru/gen-mems/img_mems/273c65cc74729db2d6f49bf...
memok.net/uploads/2014/08/13/53eb6c7a53d52.jpg

Как вы собираетесь у них искать "общую подложку"? Какой выигрыш в скорости доставки или какая экономия трафика от этого получится?

Картинки взял там небольшие, почти все менее 100 кб.
Если брать реальный сайт, это могут быть фотографии по 400-500 кб
Если склеить даже 5 картинок по 500 кб, это выйдет файл больше 2х мегабайт. Сколько будет грузится такой файл? Сколько памяти он отожрет?
При изменении хоть одной из картинок в таком "наборе", скачивать нужно будет опять его по новой, а не только одну эту измененную картинку. Это тоже такая экономия трафика?

[Дмитрий]

xmoonlight: добавлю.
сейчас эти картинки jpg.
Чтоб можно было использовать подложку, как вы предлагаете, их нужно будет сохранять как png с прозрачностью.

На сколько вырастет объем фотографии, если ее пересохранить с jpg в png с прозрачностью?

[xmoonlight]

Дмитрий: Вы не понимаете и придумываете находу. Остановитесь и перечитайте всё сверху внимательно.

[Дмитрий]

xmoonlight: да? ну так вы уточните, что именно я не понимаю.
Я вам сколько вопросов написал, вы хоть на один ответили?

Вполне допускаю, что я не прав, но пока у меня обратное впечатление, что полную чушь именно вы несете.
Но давайте еще раз попробуем? Думаю, вам будет легко доказать, что я не прав. Ниже цитаты с вашего ответа и мои вопросы к нему:
>1. Можно склеить общую подложку
как вы собираетесь клеить общую подложку? Общую теорию не надо.
У вас есть такой скрипт? или может вы в интернете что-то похожее видели?
Бог с ним, с скриптом, вы вообще где-то в интернете хоть раз видели подобный способ оптимизации для фотографий в слайдере (подчеркну, не для анимации картинок, а для слайдера. И не для графики шаблона, а именно для фотографий в контенте страницы)? Ссылку на хоть один сайт в интернете, где ваш чудо инновационный подход используется, дать сможете?

>грузим как единый поток бинарных данных и восстанавливаем в нормальные изображения на клиенте
и как вы это сделаете?
Самое простое тут использовать png с прозрачностью. Но у вас жеж код хаффмана, дерево, бинарный поток.
Поэтому вопрос будет то же - как вы это сделаете, без теории, на практике. У вас есть скрипт? или где-то видели такой же скрипт?

>"Подложка" - самый длинный общий фрагмент изображения, присутствующий на всех изображениях (координаты X,Y и цвета RGB)
Вы же понимаете, что в том же jpg данные на каждый пиксель не хранятся как "координаты X,Y и цвета RGB".
Если описывать картинку и передавать данные в таком виде, это bmp получится. Размер такого файла выйдет значительно выше.
Если конвертировать и подложку и "различия" перед передачей в jpg, вы уверены, что у вас после кодирования/декодирования артефакты на картинки не добавятся?
Да и по производительности - насколько сильно такие преобразования будут нагружать устройство клиента? вам жеж обратно потом все это декодировать.

>UPD: facebook.github.io/zstd
при чем тут вообще Zstandard? С таким же успехом ссылку на WinRar можно было дать. Оно тоже жмет.
Подозреваю, вы планировали его как архиватор для сжатия этих огромных bmp файлов использовать.
Ну и че вы потом с этими файлами сжатыми делали? У него что, есть javascript версия для работы на фронтенде?
Да, под node.js там варианты этого скрипта есть. Возможно, адаптировать его для использования на фронтенде и выйдет.
НО. Мыж экономим (трафик, запросы, вот это все). Вы уверены, что при использовании этого скрипта на фронтенде оно не потащит за собой кучу зависимостей? Не получится, что сам скрипт для разархивирования в итоге будет весить больше картинок?

>Вы не понимаете и придумываете находу. Остановитесь и перечитайте всё сверху внимательно.
Ну да, не понимаю. Не понимаю, как можно советовать полную чушь, которую на практике реализовать нельзя. Особенно новичку.
И я совсем не "придумываю на ходу", я вам по частям разбираю где и на каких этапах у вас будет тупик, и пытаюсь вас спросить, как вы из этого тупика собрались выходить.
Замечу, это я еще не все разобрал)