xmoonlight: да? ну так вы уточните, что именно я не понимаю.
Я вам сколько вопросов написал, вы хоть на один ответили?
Вполне допускаю, что я не прав, но пока у меня обратное впечатление, что полную чушь именно вы несете.
Но давайте еще раз попробуем? Думаю, вам будет легко доказать, что я не прав. Ниже цитаты с вашего ответа и мои вопросы к нему:
>1. Можно склеить общую подложку
как вы собираетесь клеить общую подложку? Общую теорию не надо.
У вас есть такой скрипт? или может вы в интернете что-то похожее видели?
Бог с ним, с скриптом, вы вообще где-то в интернете хоть раз видели подобный способ оптимизации для фотографий в слайдере (подчеркну, не для анимации картинок, а для слайдера. И не для графики шаблона, а именно для фотографий в контенте страницы)? Ссылку на хоть один сайт в интернете, где ваш чудо инновационный подход используется, дать сможете?
>грузим как единый поток бинарных данных и восстанавливаем в нормальные изображения на клиенте
и как вы это сделаете?
Самое простое тут использовать png с прозрачностью. Но у вас жеж код хаффмана, дерево, бинарный поток.
Поэтому вопрос будет то же - как вы это сделаете, без теории, на практике. У вас есть скрипт? или где-то видели такой же скрипт?
>"Подложка" - самый длинный общий фрагмент изображения, присутствующий на всех изображениях (координаты X,Y и цвета RGB)
Вы же понимаете, что в том же jpg данные на каждый пиксель не хранятся как "координаты X,Y и цвета RGB".
Если описывать картинку и передавать данные в таком виде, это bmp получится. Размер такого файла выйдет значительно выше.
Если конвертировать и подложку и "различия" перед передачей в jpg, вы уверены, что у вас после кодирования/декодирования артефакты на картинки не добавятся?
Да и по производительности - насколько сильно такие преобразования будут нагружать устройство клиента? вам жеж обратно потом все это декодировать.
>UPD: facebook.github.io/zstd
при чем тут вообще Zstandard? С таким же успехом ссылку на WinRar можно было дать. Оно тоже жмет.
Подозреваю, вы планировали его как архиватор для сжатия этих огромных bmp файлов использовать.
Ну и че вы потом с этими файлами сжатыми делали? У него что, есть javascript версия для работы на фронтенде?
Да, под node.js там варианты этого скрипта есть. Возможно, адаптировать его для использования на фронтенде и выйдет.
НО. Мыж экономим (трафик, запросы, вот это все). Вы уверены, что при использовании этого скрипта на фронтенде оно не потащит за собой кучу зависимостей? Не получится, что сам скрипт для разархивирования в итоге будет весить больше картинок?
>Вы не понимаете и придумываете находу. Остановитесь и перечитайте всё сверху внимательно.
Ну да, не понимаю. Не понимаю, как можно советовать полную чушь, которую на практике реализовать нельзя. Особенно новичку.
И я совсем не "придумываю на ходу", я вам по частям разбираю где и на каких этапах у вас будет тупик, и пытаюсь вас спросить, как вы из этого тупика собрались выходить.
Замечу, это я еще не все разобрал)
xmoonlight: добавлю.
сейчас эти картинки jpg.
Чтоб можно было использовать подложку, как вы предлагаете, их нужно будет сохранять как png с прозрачностью.
На сколько вырастет объем фотографии, если ее пересохранить с jpg в png с прозрачностью?
Как вы собираетесь у них искать "общую подложку"? Какой выигрыш в скорости доставки или какая экономия трафика от этого получится?
Картинки взял там небольшие, почти все менее 100 кб.
Если брать реальный сайт, это могут быть фотографии по 400-500 кб
Если склеить даже 5 картинок по 500 кб, это выйдет файл больше 2х мегабайт. Сколько будет грузится такой файл? Сколько памяти он отожрет?
При изменении хоть одной из картинок в таком "наборе", скачивать нужно будет опять его по новой, а не только одну эту измененную картинку. Это тоже такая экономия трафика?
xmoonlight: совет звучит как лечить насморк усечением головы.
кто будет писать серверную часть для склеивания этих картинок?
допиливать слайдер, чтоб он умел работать с такими склеенными картинками?
ерунда жеж полная.
nikegk: ерунду он вам советует. Высокотехнологичную, сложно реализуемую, неудобную в поддержке ерунду. Плюс совсем вам не нужную.
Способов уменьшить количество одновременных запросов два:
либо слить все в один файл,
либо запрашивать ресурс не сразу, а только перед тем, как он попадет в зону видимости или будет где-то использоваться.
Первый вариант, слить все в один спрайт, вам не подойдет. Так как картинок у вас много, итоговый вес и размер полученного изображения будет огромный. Он будет грузится долго и памяти такая картинка отъест прилично.
Разновидность этого варианта, которую он предлагает, для слайдеров не используют. Потому как у настоящих 100 фотографий общей подложки может и не быть.
Такой подход используют для создания вот такой анимации https://paneralandofclean.com/
Там и подложка есть, и отдельные спрайты с кусками анимации вроде вот такого https://prod-cdn.azureedge.net/20160828013219_1_0_...
Второй вариант, подгружать ресурс только когда он нужен, вам как раз и нужен.
Вообще, у вас скорее всего и так все нормально работает. Насколько понимаю, у вас при загрузки страницы сразу все 100 этих картинок не грузятся. А начинают грузится они позже по одной, после того, как меняется слайд.
Если так, то это вполне нормальная ситуация.
Уменьшать нужно количество одновременных запросов. То, что у вас будет после загрузки страницы происходить, можете игнорировать.
Ускорить загрузку картинок вы можете оптимизировав их вес и разместив их на CDN
i_want_to_know_everything: тогда смотрите, что у вас скрипты делают.
на втором скриншоте - 1 http запрос, на 17 кб, и все равно время до загрузки сайта 20 секунд.
ну и правила таки не все выполнены
"удалите код, блокирующий отображение верхней части страницы". стоит начать смотреть с этого
vjjvr: значит вы подключили сервис, который не входит в бесплатный план.
перепроверил свой аккаунт - подключался так же с использованием первого бесплатного года. первый год ничего не оплачивал.
выставляли счет на AWS Service Charges, на $0.09 Но к оплате их не просили.
Деньги начали снимать только после окончания бесплатного срока.
