Хабр Курсы для дизайнеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Дизайн доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 36
Ребята просто накачали ассеты (ну точнее заплатили копирастам, они уже накачали бесплатных). Ваш подход правильный, но для бизнеса дорогой.
Кстати, перегружаю ЭТУ страницу, сортирую в консоли изображения, и получаю 15 рекламных картинок (в основном PNG!) на 20 мегабайт. Из них несколько одинаковых. И только 16ой идёт изображение из статьи.
В карточке, логический размер изображения 200x200 пикселей, соответственно для Retina экранов размер JPG должен быть x2, т.е. 400x400. Экспортирую файл в jpg, получаю 75 815 bytes, далее оптимизирую через tinypng и получаю всего 17 180 bytes.
В этом абзаце прекрасно всё:
1. Разрешения 2x для таких картинок очень мало, потому что их часто пинч-зумят прямо на месте.
2. Большинство экранов под виндой имеют дробный масштаб, на них 2x будет выглядеть грязно. Должен быть вектор.
3. Конвертировать векторную графику в изначально неподходящий jpeg, а потом ещё раз перегонять в другой jpeg — двойная потеря качества.
Никакого растра и тем более джипега там быть не должно.
Дальнейшие ручные ковыряния в SVG — ну... эту бы энергию, да в мирное русло.
Да, там есть изрядное пространство для оптимизаций, но то что описано в статье — дичь. Это нужно делать автоматическими инструментами.
Во-первых, код после Фигмы всё равно будет грязноватый.
Во-вторых, вся ручная подгонка будет слетать при модификациях контента. Очевидно же, что это не в Фигме по пикселям равняли, это экспорт из Автокада или чего-то подобного.
И текст там переведён в кривые абсолютно оправдано.
Может надо поменьше пафоса там, где ничего не понимаешь?
Мало, не должно, будет не будет слетать — это субъективно все. Личное мнение имеет место быть, но я вам цифры привожу в каждой итерации. Оптимизация на то и оптимизация, что как процесс она может идти специальным инструментарием или алгоритмом после генерации в кадрах. Тут главное подготовить хорошо кассеты.
Прикрывать левыми цифрами непонимание сути происходящего - такое себе.
Эти чертежи рисуются в каком-то автокаде и экспортируются, там другая система координат. Всё, что было выровнено по пиксельной сетке в фигме, пойдет в мусор при первом же изменении. Поэтому эта оптимизация не может быть ручной, она обязана быть скриптом svgo.
Ваше замечание, про пинч ту зум очень весомый аргумент, но код страницы не даёт этого делать, так что джипег в данном кейсе вполне рабочее решение
Я зашел с макбука и всё зумится.
Но даже если бы и нет, jpeg всё равно не годится - стоит изучить теоретическую базу графических форматов.
Вы имеете ввиду изучить математику алгоритмов растеризации и сжатия? Иным владею в совершенстве. Юзкейс вы привели дельный, но для 90% мобильного трафика он не рабочий. Аргументируйте пожалуйста позицию, почему джипег не годится? Он меньше весит, при х2 растеризу5тся не хуже свг в прэвью.
Да бог с ней с математикой, просто базовые свойства (которые описаны в интернетах миллион раз и кажется что общеизвестны - но вот оказывается что нет).
Во-первых, jpeg предназначен для фотографических изображений без контрастных границ, для схем другие форматы.
Во-вторых, это формат с потерями - его нельзя сжимать более одного раза.
В-третьих, (это уже не про джипег, а про растр вообще) - он может мылиться даже при наличии 2x разрешения из-за несовпадения с масштабом конкретного экрана. Вектор будет лучше.
Лучше на все свои 300 в противовес 17ти? Разумеется я проверил растеризации вектора и джипеге прежде чем предлагать этот вариант в принципе. Картинка с таким количеством объектов го там жуйня, го там. Разница только в весе. Выж помимо теоретических знаний, смотрите финальную картинку
Даже мак ось рендерит изображение больше чем логическое разрешение экрана, поэтому искажения будут в любом случае
Согласен с предыдущим комментарием и добавлю свое.
Старорусское слово "оных" в техническом тексте - зачем? И тут же вес меряется в слэнговых и не сразу понятных метрах. Какая-то эклектика.
то, уверен, можно прийти и к сотне килобайт
Какой сотне, если на картинках уже размеры по 6 КБ?
Ну и главное. Люди, покупающие квартиры за 40+ миллионов рублей (посчитайте, сколько лет надо среднему программисту копить, откладывая по 100 тыс в месяц), наверняка имеют достаточно мощные компы или телефоны, и достаточно быстрый инет, чтобы вообще не думать о весе скачанной страницы. Что же до самого Самолёта, им тоже нет дела до этого, потому что у таких сайтов нет даже сотен запросов в секунду, не говоря уже о десятках тысяч.
Вывод: о чем статья, зачем статья? Непонятно.
Хороший телефон, быстрый интернет, а вы уверены что сервер нормально с запросами написан и также быстро все отдает?) а есть ещё метро в котором связь в час пик то ещё развлечение.
Когда люди забивают на оптимизацию, мы получаем 40fps на 5090 в триплэй тайтлах.
Я ни в чем не уверен. Но не заморачиваюсь по этому поводу ни разу)
А в кино так вообще 25 fps (через пробел, блин) 😎
Вы не заморачиваетесь, продакт оунер не заморачиваетесь, арт директор не париться, проектный офис кайфует, а в итоге сидим и ждём по пол минуте пока страница подгрузится.
Я вот такими штуками заморачиваюсь, об этом и публикация. А вот пробелами и опечатками я не заморачиваюсь, поэтому об этом не пишу)
Сочувствую вашим страданиям (и где-то даже мучениям) в процессе ожидания загрузки страниц Самолёта. И предлагаю подать на них в суд за моральный ущерб)
Скажите, я вам цифры привел, итерации показал. Не считаете важным оптимизацию и работу с мелочами, ваше право. Если есть, что по делу, давайте обсудим. А обсуждать уровень моего погружения в детали, это уход в субъективные оценки. Я предпочитаю цифры словам.
Ну смешно же. Вы не привели главных цифр - как долго грузится та страница с хорошего домашнего интернета на мощном компе или телефоне. А если реально долго, то не привели доказательств, что причина этого - большой размер картинок планов квартир. Все остальное, то есть, вся статья - одни чистые эмоции.
Да, насчёт метро. Люди, покупающие квартиры за 40+ млн, на метро не ездят)
Справедливости ради, аргумент про хороший интернет у миллионеров - слабый. Жизнь чуть разнообразнее.
Несколько лет назад Виталий Фридман рассказывал кейс. Они делали сайт для Porsche. Посмотрели статистику и выяснили, что все заказы делаются только с десктопа. "Очевидный" и при этом неправильный вывод - забить на мобилу. Ну действительно - это же не пицца, кто заказывает машину из метро?
Но дело в том, что у дорогих покупок всегда есть период созревания. Человек думает, сравнивает, крутит в голове варианты. И периодически в рандомные моменты заходит на сайт что-то посмотреть или уточнить. Типа пока жена в магазине, он сидя на парковке открывает сайт и листает фотки. Решению нужно созреть.
Не увидел, как отсутствие заказов машин с мобил объясняется тем, что "решению нужно" созреть?
Также, покажите хоть одну фирму, которая старается делать страницы своих сайтов настолько маленькими, чтобы они быстро загружались там, где "ловит даже на парковке" (с)
Уже вижу красивый сертификат на крутых сайтах для богатых клиентов - "на парковке certified".
Что непонятного?
С мобил не заказывают потому, что самый ответственный шаг люди делают в стационарных условиях, где можно аккуратно заполнить все данные, перепроверить и тд.
Но это не значит, что мобильная версия не нужна в процессе выбора и дозревания.
Письмо на Балабановскую спичечную фабрику:
"Я 11 лет считаю спички у вас в коробках - их то 59, то 60, а иногда и 58. Вы там сумасшедшие что ли все???"
Довольно интересный разбор оптимизации одного из элементов страницы сайта, эффект от этого конечно будет мизерный с учетом того что на главной будет видеобаннер с рекламой ЖК по сравнению с которым не оптимальность SVG плана квартиры ничто.
Но идеи по оптимизации изображений вполне здоровые и полезные.
Все точно подметили. Эффект мизерный именно для пользователей, но в корпоративной культуре, этот ход будет иметь особый вес. Ибо продакт оунер изображений сможет тогда настоять на оптимизации асинхронной загрузки контента, чтобы скорректировать ее так, чтобы на ключевых страницах, грузились сначала характеристики лотов, а потом уже мишура. В таких компаниях как Самолёт, разные команды делают составляющие сайта и очень часто их интересы разнятся.
Сначала мне просто было интересно с этим поработать, но теперь уже вырисовывается и коммерческая составляющая
Круто!
Интересно, почему никто не упомянул svgo?
Выбрал картинку наугад.
Сырой вес: 374 346, при передаче клиенту она жмётся гзипом до 231 321 ("wire bytes").
После npx svgo@latest: 79 409 несжатая, 27 860 по проводу.
я слабо представляю принципы работы алгоритмов оптимизации вектора, хотя периодически пользуюсь. Поэтому решил данной темы в публикации не касаться. Полагаю приглубоком погружении материала накопится ещё на одну, а то и две публикации. Для себя я решил в этом вопросе разобраться, но будет ли время об этом писать, пока не знаю
Спасибо, за анализ и цифры.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимизируя фаянс