Комментарии 17
Люблю такие штуки. Как инженер. А как руководитель разработки - нет. Стоимость производства такого арта космическая. Внятно обучить этому дизайнеров, поставить на поток, чтобы стабильно получать подобный эффект по качеству нереально. Привлекать к этом разработчика смысла никакого не имеет. Лучше он что-то более полезное для бизнеса за это время сделает. Из практики по хоть сколько-то устоявшимся продуктам, которые привлекают пользователя, значимого эффекта на деньги от ускорения загрузки не замечено. Понятно что если продукт грузится минуту это жесть, и то не всегда, но начиная с определённых величин затраты на сокращение времени загрузки всё больше, а эффекта всё меньше. Что не отменяет красоты решения, а также того факта, что еще 15 лет назад во флеше так уже делали одним кликом(convert to bitmap) и более того, там нормально работал прозрачный jpeg в любой комбинации с вектором. Но уже тогда подобные рекомендации на поток нормально не ставились.
Да, я бы остановился на экспериментах с WebP.
Дальнейшие улучшения уже слишком трудозатратны и не оправдывают себя.
Тут именно что нужно "технико-экономическое обоснование". Одно дело - акционный лэндинг для местного сельпо, другое дело - какой-нибудь Алиэкспресс с миллионами закачек. В первом случае на художественных "приседаниях" можно и нужно экономить, т.е. не заморачиваться. Во втором - воевать за каждый байт. На практике каждый проект оптимизируется где-то на удобной конкретно ему середине.
PS: хотя на фоне этих экономий считанных килобайтов иногда просто до слёз обидно видеть в статьях даже на Хабре иллюстрации в статье весом под десяток МегаБайт - люди (технари!) прямо со своих многомегапиксельных айфонов вываливают фотки непосредственно в статью - банально ни ресайза, ни кропа... я уж не говорю про какую-то там оптимизацию.
Только али тормозит постоянно разлогинивает, что оказывает влияние на продукт гораздо большее, и даже в али приложить программистов в другие задачи гораздо эффективнее. И даже с такими глюками али продолжает развиваться, потому что предлагает уникальный товар. И при высокой замотивированности пользователя, начиная с определённого уровня качества сервиса, улучшение этого качества серсива не позволит сильно больше заработать, а очень часто это будет неизмеримо вообще.
Какой ерундой люди готовы заниматься, лишь бы не открывать SVG в текстовом редакторе...
Сохранили бы в JPEG и не мучились. Изменится фон сайта? Ну, придётся переделать JPEG, займёт минуту.
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<image href="data:image/jpg;base64,/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDABALDA4MCh..."/>
<image href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA88AAAMrCAYAAAB3Xq..."/>
</svg>Размер файла практически идентичен сумме исходных файлов, процесс изготовления тоже довольно прост (открыл картинку в первом слое, нарисовал подписи во втором слое, удалил первый слой, экспортировал все в png, простеньким самописным скриптом сконвертировал в вышеприведенный SVG (возможно, есть проще способы, без скриптов, но я не дизайнер, у меня Gimp и лапки). Что не радует — это что всякие дефолтные графические просмотрщики такое открывают плохо или не открывают вовсе, и в какое-нибудь корпоративное вики оно тоже не встраивается как изображение — сперва качай файл, потом у себя отдельно открывай браузером.
Подобные идеи разделения текста и картинок лежат в основе формата djvu. Но вместо png там - более агрессивные методы сжатия бинарных изображений текста.
И результат - около 60кб на скан страницы А4.
Вообще есть такой универсальный формат - pdf, в нем подобные случаи как раз предусмотрены. Но если для себя -- да, отличное решение.
И второй вопрос — каким достаточно простым и бесплатным софтом такой pdf можно изготовить? Из того, чем я обычно пользуюсь — Gimp сделал как-то криво, к тому же, файл таки опух со 100 Кб до мегабайта; Inkscape экспортировать в PDF не дает вообще; самому писать скрипт — как-то уныло, в отличие от SVG за пять минут левой ногой не сделаешь.
А чисто для себя-то можно во внутреннем формате любого редактора хранить, да и размер файла не особо важен.
Судя по двум последним картинкам (Вектр + Раст), растровую часть тоже вполне можно было перевести в вектр. Там логотипы и текст, а они и так почти всегда в векторном виде.
Решил провести исследование и скачал эти файлы сайта. Учтем, что у меня не исходники и они уже оптимизированы.
Если открыть .svg файл в Photoshop, то узнаем, что его размер 3721х3721 пикс. Открыв .png - 1786х1786 с прозрачным полем, т.е. он уже меньше сам по себе.
Увеличиваем png до размеров svg (как на сайте). И теперь наложим два файла в редакторе в соответствии с сайтом. Градиент делаем растром - изначально по тексту он был таким. А для чистоты эксперимента изменяем цвета, накладываем шум, вносим хаос в оптимизированное изображение.
Успешно получаем примерно такие же размеры файлов или даже хуже - svg с растром более 13 мб, png с градиентом около 3-х мб. Опять же разные алгоритмы сжатия и само качество изображения хуже. Средний размер jpeg такого же размера (5000х5000 пикс) будет примерно 4-5 мб.
Получаем: разработчики сами экспортировали файл из Figma, получили svg со встроенным битмэпом 4х4 тысячи пикселей весом в 10 мб и поняли что что-то пошло не так. И начали решать проблему сами, вместо того, чтобы озадачить ответственных. Или их нет и делал дизайн индус-фрилансер, который ушел в закат. А дальше начались шаманские пляски с бубном. И на каком-то этапе они изменили размеры в пикселях и убрали градиент, который давал большое увеличение веса файла, плюс оптимизация цвета. Скорее всего достаточно было на первой попытке открыть векторный файл в векторном же редакторе, увидить кривой битмап и далее по списку.
А вывод какой? Не в оптимизации сайта, а во взаимодействии между отделами. Точнее, его отсутствии.
У меня png без оптимизации (с градиентом и сеткой) получился около 0,8 мб, jpeg с фоном как на сайте 0,7 мб. Это без каких либо ухищрений. А так при желании тут все изображение можно сделать svg, кроме 5 мелких фото. Такой вот реверс-инжиниринг в дизайне.
Ну можно пойти еще дальше, уже только теоретические методы.
Разработать исполняемый файл, для генерации исходного изображения. Фон кажется можно создать алгоритмически, квадратная сетка и градиент синего. Десяток строк кода.
Сжать данные нейронной сетью и передавать только веса нейронов для восстановления исходного образа. Тут чем выше допустимый уровень абстракции, тем выше сжатие.
Вектор? Растр? А может — и то, и другое?