Комментарии 22
В посте картинка 7372x4392, в примере уже 3 686px × 2 196px
Откуда такие числа? Не лучше ли сделать нормальную картинку для фона и забыть про эти ниндзя-техники?
Откуда такие числа? Не лучше ли сделать нормальную картинку для фона и забыть про эти ниндзя-техники?
Я так понимаю это сделано в угоду ретине. Но если для мелких иконок это норм, то для больших джепегов это уже перебор.
Ну как же?!
Все юзвери смотрят сайт на теликах 50" 4к и будут агриться на любое разрешение фона меньше, чем дефолтное у экрана потому, что смотрят его с расстояния меньше полуметра и видно КВАДРАТИКИ.
И делают всё это они это через мобильный интернет.
И ещё желательно делать фоновую картинку повырвиглазней, чтобы текст похуже читался.
Проще сделать картинку размера FullHD со сжатием JPG порядка 10%+. И этого будет достаточно для оптимизации, кмк. Это в случае, если без бэкграунда совсем никак.
Все юзвери смотрят сайт на теликах 50" 4к и будут агриться на любое разрешение фона меньше, чем дефолтное у экрана потому, что смотрят его с расстояния меньше полуметра и видно КВАДРАТИКИ.
И делают всё это они это через мобильный интернет.
И ещё желательно делать фоновую картинку повырвиглазней, чтобы текст похуже читался.
Кстати
В примере по ссылке вот такие параметры изображения:
Image propertiesТ.е. вместо 5МБ уже 1МБ.
Image type: JPEG (image/jpeg)
Dimensions: 3686 × 2196 px
Screen Size: 728 × 434 px
File size: 892.1 kB (892,138 bytes)
Address: i.imgur.com/EWx6Ao5.jpg
Проще сделать картинку размера FullHD со сжатием JPG порядка 10%+. И этого будет достаточно для оптимизации, кмк. Это в случае, если без бэкграунда совсем никак.
Блин, ну это просто демо-пример, для большего контраста. В реальности картинки будут меньше, но зато не одна, а несколько.
Вот за что действительно автору нужно попенять, так это за слишком современный js-код со стрелочными функциями, шаблонными строками и прочими финтифлюшками. Потому что: подмена картинки на LQIP подразумевает временную поломку контента. Всё что связано с поломкой контента, должно быть железобетонно надежно и работать во всех сколько-нибудь (полу)живых браузерах. Тут не свалишь на graceful degradation или progressive enhancement.
Вот за что действительно автору нужно попенять, так это за слишком современный js-код со стрелочными функциями, шаблонными строками и прочими финтифлюшками. Потому что: подмена картинки на LQIP подразумевает временную поломку контента. Всё что связано с поломкой контента, должно быть железобетонно надежно и работать во всех сколько-нибудь (полу)живых браузерах. Тут не свалишь на graceful degradation или progressive enhancement.
В этом году появилась автоматическая «ленивая загрузка». Достаточно всего лишь добавить атрибут
Картинки будут загружаться автоматически когда они попадут в область видимости. И не нужно будет вручную создавать Intersection Observer
loading="lazy"<img src="image.png" loading="lazy">Картинки будут загружаться автоматически когда они попадут в область видимости. И не нужно будет вручную создавать Intersection Observer
Штука вроде и хорошая, но:
а) Нет никакой гибкости управления (это бывает нужно, а бывает и не нужно — когда как).
б) Поддерживается только в Хроме. IE и FF — черт с ними. Но мы ведь понимаем, что эти техники в первую очередь предназначены для мобильного рынка? Важнейший сегмент яблочных устройств оказывается за бортом.
а) Нет никакой гибкости управления (это бывает нужно, а бывает и не нужно — когда как).
б) Поддерживается только в Хроме. IE и FF — черт с ними. Но мы ведь понимаем, что эти техники в первую очередь предназначены для мобильного рынка? Важнейший сегмент яблочных устройств оказывается за бортом.
Я бы в качестве селектора для поиска атрибута использовал сам атрибут, возможно с другим названием, но так вроде понятнее и не надо лишний класс прописывать:
const objects = document.querySelector('[data-src]');
При таком подходе поисковики будут индексировать фото низкого разрешения. Как сделать, чтобы индексировалось фото в большом?
Может, я что-то не понимаю, но какая разница, какая картинка будет проиндексирована? title\alt же правильные, поисковики максимум показывают небольшую превьюшку, где низкого разрешения более чем достаточно
Пользователи же по картинкам тоже ищут. Если находят нужные им фото, то переходят на сайт. Вряд-ли их заинтересуют очень низкого качества. Плюс, часто видел как ссылались на мой сайт и вставляли фото с него.
Поисковики показывают нормальную картинку и более того позволяют искать с учётом её размеров и по содержимому
А если микро-картинку заинлайнить в html, то ещё быстрее первичная загрузка пройдёт.
И в png такая малышка вообще 600 байт у меня заняла (я эту же картинку уменьшил и сохранил).
И в png такая малышка вообще 600 байт у меня заняла (я эту же картинку уменьшил и сохранил).
Еще в комментариях не озвучили способ положить рядом картинку в webp и через вебсервер определять если браузер поддерживает webp то отсылать ему webp версию. Экокномия может быть очень существенной
А элемент picture из html5 не подходит?
Уже давно придумана такая штука, как interlaced image. В большом изображении зашита его мини версия, которую браузер первым делом подгружает и показывает. Вы могли встречать это при сохранении png в photoshop.
LOL, это стёб такой? background фотографией размером в 5мб? Да, сейчас не 2000 год и это изображение не качается несколько ночей с BBS. Зачем ?!!! Если мне действительно нужно это изображение, я на него нажму. Оно никому не нужно просто так. Особенно где-либо с GPRS. Делаем preview {320,640,1024}. И всё решение занимает 2 строчки.
Оптимизаторы [цензура]…
Так же чуть выше писали про формат webp. Так вот, я потратил некоторое время на оптимизацию изображений в lossless и единственный вывод для себя: Leanify — это круто. Пользуйтесь Leanify. Leanify выше крыши для 99% кейсов с изображениями. webp почти всегда выдаёт изображение с большим весом.
Всё! Простое и надёжное решение в 2 строчки. Можно ещё третьей строчкой watermark добавить и больше нет никаких проблем с оптимизацией изображений. Больше уже либо Google, либо совсем жёсткий перфекционизм.
ffmpeg -i image.png -s 320x240 -c:a copy image_320x240.png
leanify image320x240.png
Оптимизаторы [цензура]…
Так же чуть выше писали про формат webp. Так вот, я потратил некоторое время на оптимизацию изображений в lossless и единственный вывод для себя: Leanify — это круто. Пользуйтесь Leanify. Leanify выше крыши для 99% кейсов с изображениями. webp почти всегда выдаёт изображение с большим весом.
Всё! Простое и надёжное решение в 2 строчки. Можно ещё третьей строчкой watermark добавить и больше нет никаких проблем с оптимизацией изображений. Больше уже либо Google, либо совсем жёсткий перфекционизм.
Если WebP весит больше «почти всегда», то похоже с процессом конвертации что-то не так. В нормальных условиях такое бывает иногда, но обычно WebP весит всё-таки меньше, чем PNG.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимизация загрузки изображений