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

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

Однако, представил себе процессы компании, архитектуру решения и подумал, что ребята просто решили оптимизировать процессы избавившись от лишних артефактов с которыми нужно работать и поддерживать. Оптимизация — наше все! И тогда я решил проверить вес такого решения. Как я и предполагал изображение хранится в формате SVG, что логично для его переиспользования и на странице квартиры, однако…

318 048 bytes — простите, сколько?

По умолчанию на странице 12 карточек. общий вес графики планировок 3,3 метра. Я не поленился и скачал все, пересмотрев каждую. Были там  и планировки по 108 831 bytes и по 416 634 bytes

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

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

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

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

Спинофнимся к джипегу

В карточке, логический размер изображения 200x200 пикселей, соответственно для Retina экранов размер JPG должен быть x2, т.е. 400x400. Экспортирую файл в jpg, получаю 75 815 bytes, далее оптимизирую через tinypng и получаю всего 17 180 bytes. 

17 — это не 300. чувствуете разницу?! Понятно, что при открытии страницы лота, в таком подходе придется еще одно более качественное изображение подгружать, и если пользователь реально будет открывать все карточки подряд суммарная загрузка будет больше, но обычно люди так не делают, смотрят пару квартир из списка, фильтруют, смотрят еще пару. 

Да и на самой странице размер изображения 368x368. В джипегах это будет всего 171 777 bytes при том же x2. И только третьим шагом сайт предлагает возможность зума, где 300 байтный svg оправдан, но до него пользователь должен еще захотеть дойти. 

Возвращаемся к SVG

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

Меня заинтересовал вопрос оптимизации изображения с сохранением формы и внешнего вида растра. Для работы я выбрал простой, но комплексный объект, встречающийся в каждой современной квартире —  фаянсовый друг.

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

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

Каждый промежуточный этап давал небольшое сокращение веса. Не сразу, но дошел, что позиционирование размеров по целым числам, тоже облегчит вес. 

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

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

Оставил себе пометку, пойти, таки, изучить математику SVG формата, но это на будущее.

277 против 515. Дальше собираю всю конструкцию, добавляя поэлементно контуры и прикидывая возможности оптимизации. Так, при обозначении отверстия, в основном контуре можно сэкономить пару десятков байт оставив углы без скругления. Эта деталь будет заметна только при максимальном приближении. Можно и овал нарисовать, но задача — быть максимально близким к формам оригинала.

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

После технической работы, включаем психолога и вспоминаем, что унитаз всегда стоит у стены, и только в «смертельном оружие» он был центральной деталью интерьера. Поэтому можно сэкономить еще пару байт.

Цвет добавит еще 10 байт — и на такой дизайнерский изыск пойти можно, а можно и не ходить и задать слою прозрачность в свойствах при отрисовке. Итоговый результат 575 бит против 3369.

Продолжим с раковиной

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

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

Ванна. О ней тоже пара слов: все лишние контуры выкидываются, отверстие для перелива из овала заменяю простой линией внешний контур превращается в одну линию с запасом по высоте.

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

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

Комментарии (34)


  1. n0isy
    23.10.2025 22:33

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

    Кстати, перегружаю ЭТУ страницу, сортирую в консоли изображения, и получаю 15 рекламных картинок (в основном PNG!) на 20 мегабайт. Из них несколько одинаковых. И только 16ой идёт изображение из статьи.


  1. dom1n1k
    23.10.2025 22:33

    В карточке, логический размер изображения 200x200 пикселей, соответственно для Retina экранов размер JPG должен быть x2, т.е. 400x400. Экспортирую файл в jpg, получаю 75 815 bytes, далее оптимизирую через tinypng и получаю всего 17 180 bytes.

    В этом абзаце прекрасно всё:
    1. Разрешения 2x для таких картинок очень мало, потому что их часто пинч-зумят прямо на месте.
    2. Большинство экранов под виндой имеют дробный масштаб, на них 2x будет выглядеть грязно. Должен быть вектор.
    3. Конвертировать векторную графику в изначально неподходящий jpeg, а потом ещё раз перегонять в другой jpeg — двойная потеря качества.

    Никакого растра и тем более джипега там быть не должно.

    Дальнейшие ручные ковыряния в SVG — ну... эту бы энергию, да в мирное русло.
    Да, там есть изрядное пространство для оптимизаций, но то что описано в статье — дичь. Это нужно делать автоматическими инструментами.
    Во-первых, код после Фигмы всё равно будет грязноватый.
    Во-вторых, вся ручная подгонка будет слетать при модификациях контента. Очевидно же, что это не в Фигме по пикселям равняли, это экспорт из Автокада или чего-то подобного.
    И текст там переведён в кривые абсолютно оправдано.

    Может надо поменьше пафоса там, где ничего не понимаешь?


    1. AndrewYaremko Автор
      23.10.2025 22:33

      Мало, не должно, будет не будет слетать — это субъективно все. Личное мнение имеет место быть, но я вам цифры привожу в каждой итерации. Оптимизация на то и оптимизация, что как процесс она может идти специальным инструментарием или алгоритмом после генерации в кадрах. Тут главное подготовить хорошо кассеты.


      1. dom1n1k
        23.10.2025 22:33

        Прикрывать левыми цифрами непонимание сути происходящего - такое себе.

        Эти чертежи рисуются в каком-то автокаде и экспортируются, там другая система координат. Всё, что было выровнено по пиксельной сетке в фигме, пойдет в мусор при первом же изменении. Поэтому эта оптимизация не может быть ручной, она обязана быть скриптом svgo.


    1. AndrewYaremko Автор
      23.10.2025 22:33

      Ваше замечание, про пинч ту зум очень весомый аргумент, но код страницы не даёт этого делать, так что джипег в данном кейсе вполне рабочее решение


      1. dom1n1k
        23.10.2025 22:33

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


        1. AndrewYaremko Автор
          23.10.2025 22:33

          Вы имеете ввиду изучить математику алгоритмов растеризации и сжатия? Иным владею в совершенстве. Юзкейс вы привели дельный, но для 90% мобильного трафика он не рабочий. Аргументируйте пожалуйста позицию, почему джипег не годится? Он меньше весит, при х2 растеризу5тся не хуже свг в прэвью.


          1. dom1n1k
            23.10.2025 22:33

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

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


            1. AndrewYaremko Автор
              23.10.2025 22:33

              Лучше на все свои 300 в противовес 17ти? Разумеется я проверил растеризации вектора и джипеге прежде чем предлагать этот вариант в принципе. Картинка с таким количеством объектов го там жуйня, го там. Разница только в весе. Выж помимо теоретических знаний, смотрите финальную картинку

              Даже мак ось рендерит изображение больше чем логическое разрешение экрана, поэтому искажения будут в любом случае


  1. dyadyaSerezha
    23.10.2025 22:33

    Согласен с предыдущим комментарием и добавлю свое.

    Старорусское слово "оных" в техническом тексте - зачем? И тут же вес меряется в слэнговых и не сразу понятных метрах. Какая-то эклектика.

    то, уверен, можно прийти и к сотне килобайт

    Какой сотне, если на картинках уже размеры по 6 КБ?

    Ну и главное. Люди, покупающие квартиры за 40+ миллионов рублей (посчитайте, сколько лет надо среднему программисту копить, откладывая по 100 тыс в месяц), наверняка имеют достаточно мощные компы или телефоны, и достаточно быстрый инет, чтобы вообще не думать о весе скачанной страницы. Что же до самого Самолёта, им тоже нет дела до этого, потому что у таких сайтов нет даже сотен запросов в секунду, не говоря уже о десятках тысяч.

    Вывод: о чем статья, зачем статья? Непонятно.


    1. AndrewYaremko Автор
      23.10.2025 22:33

      Хороший телефон, быстрый интернет, а вы уверены что сервер нормально с запросами написан и также быстро все отдает?) а есть ещё метро в котором связь в час пик то ещё развлечение.

      Когда люди забивают на оптимизацию, мы получаем 40fps на 5090 в триплэй тайтлах.