Smashing Podcast Episode 39 With Addy Osmani: Оптимизация изображения

Этот эпизод был любезно поддержан нашими дорогими друзьями из Storyblok, которые помогают людям создавать мощный контент на любой платформе: корпоративных веб-сайтах, сайтах электронной коммерции, мобильных приложениях и экранах. Спасибо!

В сегодняшнем выпуске Smashing Podcast мы говорим об оптимизации изображений. Какие шаги мы должны предпринять для эффективных изображений в 2021 году? Я поговорил с экспертом Адди Османи, чтобы выяснить это.

Показать примечания

• «Оптимизация изображений», Эдди Османи
• Эдди в Твиттере
• личный сайт Адди

Еженедельное обновление

• Встречайте :has, родной CSS-селектор родительских элементов (и многое другое)
  автор Адриан Бес
• Три внешних инструмента аудита, которые я обнаружил недавно
  автор Стефан Джудис
• Полезные интерфейсные шаблоны и стартовые наборы
  автор Козима Мильке
• Удачный веб-дизайн: использование аудио
  автор Фредерик О'Брайен
• Когда CSS недостаточно: требования к JavaScript для доступных компонентов
  автор Стефани Эклз

Стенограмма

Дрю Маклеллан: Он технический менеджер, работающий над Google Chrome, где его команда уделяет особое внимание скорости, помогая поддерживать скорость Интернета. Посвященный сообществу открытого исходного кода, его прошлые работы включают Lighthouse, Workbox, Yeoman, Critical и to do NVC. Таким образом, мы знаем, что он знает, как оптимизировать веб-производительность. Но знаете ли вы, что он хочет получить «Оскар» за лучшую женскую роль второго плана из-за канцелярской ошибки? Мои потрясающие друзья, пожалуйста, поприветствуйте Эдди Османи. Привет, Эдди. Как твои дела?

Эдди Османи: Я разбиваю.

Дрю Маклеллан: Приятно слышать. Сегодня я хотел поговорить с вами об изображениях в Интернете. Это область, в которой за последние несколько лет произошло удивительное количество изменений и инноваций, и вы только что написали очень подробную книгу об оптимизации изображений для Smashing. Что побудило в то время подумать: «Сейчас самое время для книги по оптимизации изображений?»

Эдди Османи: Отличный вопрос. Я думаю, мы знаем, что изображения были довольно важной частью Интернета на протяжении десятилетий и что наш мозг способен интерпретировать изображения намного быстрее, чем текст. Но эта общая тема со временем становится все более и более интересной и детализированной. И я всегда говорю людям, что это, наверное, моя третья или четвертая книга. Я никогда намеренно не собирался писать книгу.

Эдди Османи: Я начал эту книгу с написания статьи об оптимизации изображений, а затем со временем обнаружил, что случайно написал об этом целую книгу. Мы работали над этим проектом около двух лет. И даже за это время в отрасли развивались браузеры и инструменты для работы с изображениями и форматами изображений.

Эдди Османи: И поэтому я написал эту книгу, потому что обнаружил, что мне трудно оставаться в курсе всех этих изменений. И я подумал: «Я собираюсь стать хорошим веб-гражданином и постараюсь отслеживать все, что я узнал, в одном месте, чтобы все остальные могли этим воспользоваться».

Дрю Маклеллан: Это одна из тех областей, я думаю, с большой оптимизацией производительности в браузере, это быстро меняющийся ландшафт, не так ли? Там, где техника, которую вы изучили как актуальную и передовую, происходит некоторый технологический сдвиг, и тогда вы обнаруживаете, что на самом деле это анти-шаблон, и вам не следует его использовать. И пытаться поддерживать свои знания и убедиться, что вы читаете правильные статьи и изучаете правильные вещи, а не читаете что-то двухлетней давности, довольно сложно.

Дрю Маклеллан: Собрать все это в одной хорошо проработанной книге из авторитетного источника — это действительно здорово.

Эдди Османи: Да. Даже с точки зрения автора, одним из самых интересных и, возможно, одним из самых напряженных моментов для нашей редакционной команды было то, что я сдавал главу и говорил, что она готова. А через две недели что-то менялось в браузере, и я такой: «Ой, подождите. Я должен внести еще одно изменение в последнюю минуту».

Эдди Османи: Но имиджевый ландшафт сильно изменился даже за последний год. Мы видели, как поддержка WebP, наконец, вышла на финишную прямую в большинстве современных браузеров. Поддержка изображений AVIF есть в Chrome, появится в Firefox, JPEG XL, отложенная загрузка. И по всем направлениям мы видели улучшения в том, как вы можете использовать изображения в Интернете довольно конкретно в браузерах. Но опять же, людям есть о чем держать в курсе.

Дрю Маклеллан: Некоторым людям оптимизация изображений может показаться довольно уравновешенной темой. Мы все в какой-то момент своей карьеры узнали, как экспортировать для Интернета из нашего графического программного обеспечения. И у некоторых из нас может быть привычка брать эти экспортированные изображения и запускать их через что-то вроде ImageOptim.

Дрю Маклеллан: Итак, мы можем знать, что нам следует выбирать JPEG, когда это фотографическое изображение, и PNG, когда это графическое изображение, и думать: «Хорошо, вот и все. Я знаю оптимизацию изображений, я готов». Но на самом деле все это просто ставки, не так ли?

Эдди Османи: Да, это так. Я думаю, что наша способность отображать более подробные, более четкие изображения и изображения внутри даже в другом контексте, в зависимости от того, заботитесь ли вы об художественном направлении или нет, со временем развивалась. Я думаю, что необходимость выяснить, как вы можете сделать эти изображения такими красивыми, как задумано для ваших конечных пользователей, с учетом их среды, ограничений их устройств, их сетевых ограничений, является сложной проблемой, и я знаю, что многие люди до сих пор бороться с.

Эдди Османи: Итак, когда дело доходит до размышлений об изображениях и получения чуть более утонченного взгляда на них, а не просто «Эй, давайте использовать JPEG» или «Давайте использовать PNG», я думаю, что есть несколько аспектов этой ценности. имея в виду. Первый — это просто обычное сжатие. Вы упомянули ImageOptim, и многие из нас привыкли просто перетаскивать изображение в нужное место и получать от него что-то меньшего размера.

Эдди Османи: Когда дело доходит до сжатия, мы обычно говорим о разных кодеках. А кодеки — это технология сжатия, которая обычно имеет компонент кодировщика для кодирования файлов и компонент декодера для их декодирования и распаковки. И когда вы решаете, используете ли вы что-то, вам обычно нужно подумать о том, подходят ли фотографии или изображения, которые вы используете, для подхода с использованием подхода сжатия с потерями или подхода с меньшими потерями.

Эдди Османи: На всякий случай, если люди не очень хорошо знакомы с этими концепциями, подход без потерь — это тот, при котором вы воспроизводите тот же самый файл в самом конце после распаковки. Таким образом, вы не сильно теряете в качестве. Lossless — это гораздо больше, чем отправка вашего изображения через факсимильный аппарат. Вы получаете факсимиле оригинала, и это не будет оригинальным файлом. Там могут быть какие-то другие артефакты. Это может выглядеть немного по-другому. Но в общих чертах, чем больше вы сжимаете, тем больше качества вы обычно теряете.

Адди Османи: Таким образом, со всеми этими современными кодеками изображений они пытаются понять, какое качество можно выжать, сохраняя при этом относительно приличный размер файла, в зависимости от варианта использования.

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

Эдди Османи: Абсолютно. Абсолютно. И я думаю, что, опять же, возвращаясь к тому, с чего мы начали с JPEG и PNG, люди могут знать, что JPEG был создан для сжатия фотографий с потерями. Обычно вы получаете файл меньшего размера с задней стороны, и иногда он может иметь различные артефакты полос. Формат PNG изначально создавался для сжатия без потерь, он неплохо справляется с нефотографическими изображениями.

Эдди Османи: Но с тех пор многое изменилось. Примерно в 2010 году мы начали получать поддержку WebP, который должен был заменить JPEG и PNG и немного превосходил их в сжатии. Но с тех пор количество доступных форматов изображений и опций резко возросло. Я думаю, что в целом дела идут в правильном направлении, особенно с такими современными форматами, как AVIF и JPEG XL. Но нам потребовалось время, чтобы добраться сюда. Даже получение поддержки WebP во всех браузерах заняло довольно много времени.

Эдди Османи: И я думаю, что в конечном итоге это повлияло на то, что разработчики просили об этом, у них был аппетит к возможности получить лучшее сжатие из этих современных форматов и желание просто иметь хорошую совместимость между браузерами. для этих вещей тоже.

Дрю Маклеллан: Да. WebP кажется мне действительно интересным, потому что, помимо того, что в этом формате доступно сжатие без потерь и с потерями, в результате мы, очевидно, имеем значительно уменьшенный размер файла. И есть хорошая поддержка браузеров, и мы видим принятие со стороны крупных компаний, таких как Google и Netflix, и других крупных компаний.

Дрю Маклеллан: Но мое мнение в отрасли таково, что мы не видим такого же понимания на низовом уровне. WebP все еще ждет своего часа?

Эдди Османи: Думаю, я бы сказал, что на подходе WebP. Многие ждали появления поддержки Safari и WebKit, и наконец-то она у нас есть. Но когда мы думаем о новых форматах изображений, очень важно понимать, что на самом деле означает поддержка. Браузер поддерживает декодирование этих изображений. Нам также нужна действительно хорошая инструментальная поддержка, чтобы вы могли использовать эти форматы изображений, независимо от того, работаете ли вы в среде узлов, CDN изображений или в CMS.

Эдди Османи: Я помню много лет назад, когда впервые появился WebP. У первых пользователей была проблема: вы сохраняли файл WebP на рабочем столе, а затем вдруг: «О, подождите. Нужно ли мне перетаскивать это в свой браузер, чтобы просмотреть?» или «Если мои пользователи загружают WebP, они застрянут и будут задаваться вопросом, что происходит?»

Эдди Османи: Поэтому я думаю, что для того, чтобы формат изображения взлетел, очень важно убедиться, что существует достаточно целостная поддержка формата изображения как на уровне операционной системы, так и в другом контексте. Также важно, чтобы люди, которые раздают изображения, немного подумали об этих вариантах использования, чтобы, если я сохраняю или загружаю файл, вы пытались поместить его в переносимый формат, которым люди обычно могут легко поделиться. И я думаю, что именно здесь, по крайней мере, на iOS, iOS получила поддержку похода и дефиса. А преобразование вещей в JPEG, когда это необходимо, позволяет людям делиться ими.

Эдди Османи: Поэтому, я думаю, важно продумать те типы вариантов использования, в которых мы можем убедиться, что пользователи не проигрывают, в то время как мы обеспечиваем им лучшее сжатие.

Дрю Маклеллан: У меня есть служба обмена слайдами, которой я управляю и, как вы понимаете, работает с сотнями тысяч изображений. И когда я смотрел на WebP, а это было, наверное, три года назад, я в первую очередь искал способ снизить затраты на полосу пропускания CDN, потому что, если вы обслуживаете файл меньшего размера, с вас взимается меньшая плата за его обслуживание. Но, несмотря на то, что мне по-прежнему требовалось полное изображение, а также устаревший формат изображения, мои расчеты показали, что стоимость хранения всего другого набора изображений перевешивает преимущества обслуживания файла меньшего размера. Итак, мы живем в 2021 году. Стоит ли мне сейчас пересмотреть это решение?

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

Эдди Османи: Я думаю, что когда вам нужно помнить о хранении, иногда стоит помнить о попытках найти лучший, наиболее общий знаменатель для обслуживания ваших пользователей. В наши дни я бы сказал, что WebP стоит рассматривать как общий знаменатель. Для людей, которые привыкли использовать тег изображения для условного предоставления различных форматов людям, обычно вы должны использовать JPEG в качестве основного запасного варианта. Может быть, в наши дни нормально использовать WebP в качестве запасного варианта для большинства пользователей, если только у вас нет людей, которые используют очень, очень старые браузеры. И я думаю, что мы видим намного меньше этого в эти дни. Но у вас определенно есть некоторая гибкость.

Эдди Османи: Теперь, если вы пытаетесь смотреть вперед, я бы посоветовал вам выбрать один формат, который, по вашему мнению, работает очень хорошо. Если вы можете подойти к хранению так, чтобы оно масштабировалось и было гибким в соответствии с вашими потребностями, я бы сказал, что людям следует подумать о JPEG XL. Технически это еще не доставка в браузере. Когда это произойдет, JPEG XL должен быть отличным вариантом для большого количества фотографий в случаях использования с потерями или без потерь, а также для случаев использования без фотографий. И, вероятно, это будет намного лучше, чем WebP V1. Так это одно место.

Эдди Османи: Я думаю, что AVIF, вероятно, будет лучше, если вам нужно перейти на очень низкий битрейт. Может быть, вы очень заботитесь о пропускной способности. Может быть, вы немного меньше заботитесь о точности изображения. И при таких битрейтах я мог себе представить, что он выглядит более четким, чем некоторые альтернативы. И пока у нас не будет JPEG XL, я бы попробовал взглянуть на вашу аналитику и понять, возможно ли у вас обслуживать AVIF. В противном случае я бы сосредоточился на этом WebP. Если бы вы были аналитиком, я думаю, что большинство людей могли бы обслуживать WebP, и вы немного меньше заботились бы о широкой гамме или текстовых наложениях, местах, где выборка хромосом может быть не идеальной в WebP. Это, безусловно, стоит иметь в виду.

Эдди Османи: Поэтому я постараюсь помнить, что не будет универсального решения для всех. Лично я в эти дни немного меньше беспокоюсь о расходах на хранение, исходящий трафик и полосу пропускания только потому, что использую образ CDN. И я рад сообщить, что использую Cloudinary лично. Там, где я работаю, мы используем множество различных CDN для изображений. Но я обнаружил, что мне не нужно так сильно беспокоиться о затратах на обслуживание конвейеров изображений, о том, как я буду поддерживать, например: «О, эй, вот еще один формат изображения, или новые типы резервных копий, или новые веб-API. », это было хорошим преимуществом для инвестиций в то, что просто позаботится об этом за меня.

Адди Османи: И тогда общая стоимость моих вариантов использования была в порядке. Но я вполне могу себе представить, что если вы используете сервис слайдов в таком масштабе, это тоже не обязательно будет вариантом.

Дрю Маклеллан: Да. Поэтому я хочу вернуться к некоторым из этих будущих форматов. Но я думаю, что это стоит покопаться, потому что с любыми инструментами производительности, Lighthouse или WebPageTests, если кто-то из нас запускает свои сайты через них, одна из ключевых вещей, которые он предложит, это использование CDN для изображений. И это очень реалистично для очень крупных компаний. Является ли это реалистичным и доступным для людей, создающих небольшие веб-сайты и приложения, или это на самом деле так просто сделать, как кажется?

Эдди Османи: Я думаю, люди должны задать вопрос: «Для чего вы используете изображения?» Если у вас есть только несколько изображений, если вы создаете блог и изображения, которые вы добавляете, относительно просты, у вас нет сотен, сотен или тысяч изображений, вы можете просто подойти к этому во время сборки очень статическим образом, когда вы устанавливаете пару пакетов NPM. Возможно, вы просто используете Sharp. И это заботится о вас по большей части.

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

Эдди Османи: И затем для людей, которые хотят иметь возможность использовать несколько форматов, они не хотят иметь дело с таким количеством мелочей инструментов и хотят иметь возможность получить действительно богатое отзывчивое изображение или историю на месте, я сказал бы попробовать изображение CDN. Я лично довольно сдержанно относился к использованию его для личных проектов из соображений стоимости поначалу, а затем, со временем, когда я взглянул на свой счет, я действительно понял, что это экономит мне время, которое я в противном случае инвестировал бы в решение этих проблем самостоятельно. Я не знаю, сколько вам приходилось писать пользовательские сценарии для работы с вашими изображениями в прошлом, но я понял, что если я смогу сэкономить хотя бы пару дней на отладку этих различных пакетов npm в месяц, тогда расходы вид заботиться о времени, которое я экономлю и так что все в порядке.

Адди Османи: Но это может быть что-то такое, когда вы масштабируете до сотен или тысяч изображений или миллионов изображений, и это не обязательно покрывается вашим доходом или не то, за что вы готовы платить, вам нужно подумать об этом. альтернативные стратегии. И я думаю, что нам повезло, что у нас есть достаточно гибкости с инструментами, которые доступны нам сегодня, чтобы иметь возможность двигаться в любом из этих направлений, когда мы делаем что-то более нестандартное, мы решаем это сами или катаемся. наш собственный имидж CDN или мы инвестируем в что-то более коммерческое. И мы находимся в том месте, где я бы сказал, что для некоторых случаев использования, да, вы можете использовать CDN для изображений, и это доступно.

Дрю Маклеллан: Думаю, один из руководящих принципов — всегда быть гибким и быть готовым к изменениям. И вы можете начать с использования CDN изображений для динамического преобразования ваших изображений по мере их запроса, и если это дойдет до точки, когда это не будет устойчивым с точки зрения затрат, вы можете посмотреть на другое решение и иметь свою кодовую базу в состоянии где будет легко заменить одно решение другим. Я думаю, что в целом и везде, где вы полагаетесь на сторонний сервис, это хороший принцип, не так ли? Вы упомянули форматы изображений JPEG XL. Что такое JPEGXL? Откуда это? И что это делает для нас?

Эдди Османи: Отличный вопрос. Таким образом, JPEG XL — это формат изображения следующего поколения, он должен быть универсальным и является кодеком, разработанным комитетом по JPEG. Все началось с некоторых корней в формате Google pic, а затем в формате FUIF от Cloudinary. За прошедшие годы появилось много форматов, которые были включены в эту категорию, но он стал намного больше, чем просто сумма его отдельных частей, и некоторые из преимуществ JPEG XL заключаются в том, что он отлично подходит для высокой точности. изображения, действительно хороши для без потерь, у него есть поддержка прогрессивного декодирования, транскодирования JPEG без потерь, а также без суеты и без лицензионных отчислений, что, безусловно, является преимуществом. Я думаю, что JPEG XL потенциально может быть действительно сильным кандидатом. Мы говорили ранее о том, что если бы вы просто выбрали один, что бы вы использовали? И я думаю, что у JPEG XL есть потенциал для этого.

Эдди Османи: Я также не хочу обещать слишком много, мы все еще очень рано начинаем поддерживать браузеры. И поэтому я думаю, что нам действительно следует подождать и посмотреть, поэкспериментировать и оценить, насколько хорошо это работает на практике и соответствует ожиданиям людей, но я вижу большой потенциал в JPEG XL как для этих случаев с потерями, так и для случаев без потерь. Прямо сейчас я считаю, что Chrome, вероятно, продвинулся дальше всех с точки зрения поддержки, но я также видел определенный интерес к этому со стороны Mozilla и других браузеров, поэтому я с нетерпением жду будущего с JPEG XL. И если бы мы должны были сказать, что еще более короткий срок интереса для людей? Есть, конечно, и AVIF.

Дрю Маклеллан: Расскажите нам о AVIF, это еще один, с которым я не знаком.

Эдди Османи: Хорошо. Итак, мы упоминали немного ранее о том, что AVIF, возможно, является лучшим кандидатом, если вам нужно перейти на низкие скорости передачи данных, и вы заботитесь о пропускной способности больше, чем о точности изображения, как общий принцип, AVIF действительно лидирует в низкокачественном сжатии с высокой привлекательностью. И JPEG XL, он должен превосходить точность от средней до высокой, но это немного разные форматы сами по себе. Мы находимся в том месте, где AVIF получает все более хорошую поддержку браузеров, но позвольте мне сделать шаг назад и рассказать немного больше об этом формате. Таким образом, сам AVIF основан на видеокодеке AV1, который был стандартизирован Альянсом открытых медиа, и он пытается дать людям значительный выигрыш в сжатии по сравнению с JPEG, по сравнению с WebP, о котором мы говорили ранее. И хотя точная экономия, которую вы можете получить от AVIF, будет зависеть от контента и ваших целевых показателей качества, мы видели множество случаев, когда он может предложить более 50% экономии по сравнению с JPEG.

Эдди Османи: У него много хороших функций, он может предоставить вам контейнерную поддержку новых функций, таких как расширенный динамический диапазон и широкая цветовая гамма, синтез зернистости пленки. И снова, аналогично разговору о том, чтобы смотреть вперед, одна из приятных особенностей тега изображения заключается в том, что вы можете предоставлять пользователям файлы AVIF прямо сейчас, и он по-прежнему будет возвращаться к вашему WebP или вашему JPEG в случаях, когда он не обязательно поддерживается. . Но возвращаясь к вашему примеру о Photoshop Save For Web, вы можете взять JPEG размером 500 килобайт, попытаться снять с качеством, аналогичным Photoshop Save For Web, а с AVIF я бы сказал, что вы, вероятно, сможете получить точка, где размер этого файла составляет около 90 килобайт, 100 килобайт, так что довольно много экономии без реальной заметной потери качества.

Эдди Османи: И одна из приятных вещей в этом заключается в том, что в идеале вы не увидите такой большой потери текстуры на любых изображениях с богатой детализацией. Так что, если у вас есть фотографии леса, кемпинга или чего-то подобного, они все равно должны выглядеть очень богато с AVIF. Так что я очень воодушевлен тем направлением, которое выбрал AVIF. Я действительно думаю, что нужно немного больше работы с точки зрения инструментальной поддержки. Итак, я написал твит об этом на днях, у нас есть несколько вариантов использования AVIF прямо сейчас, для отдельных изображений у нас есть Squoosh, squoosh.app, который написан другой командой в Chrome, так что кричите Сурма и Джейк за работу над Squoosh. У Avif.io есть несколько хороших вариантов для людей, которые пытаются использовать AVIF сегодня, независимо от того, на каком технологическом стеке они сосредоточены, Sharp также поддерживает AVIF.

Эдди Османи: Но обычно вы думаете о других местах, где мы имеем дело с изображениями, будь то в Figma, в Sketch, в Photoshop или в других местах, и я бы сказал, что нам все еще нужно немного поработать с точки зрения Там поддерживается AVIF, потому что он должен быть повсеместным, чтобы разработчики и пользователи действительно чувствовали, что он приземлился и вернулся домой. И это одно из направлений нашей работы с командами, работающими над AVIF в Chrome в данный момент, пытаясь убедиться, что мы можем получить инструменты в достаточно хорошем месте.

Дрю Маклеллан: Теперь у нас есть в HTML элемент изображения, который дает нам больше гибкости по сравнению с традиционным тегом изображения. Хотя тег изображения тоже прошел долгий путь, не так ли? Но мы увидели добавление изображения, это было примерно в то же время, что и нативный тег видео, я думаю, в такой исходной партии изменений HTML5. И это дает нам возможность указать несколько источников, верно?

Эдди Османи: Да, верно.

Дрю Маклеллан: Таким образом, вы можете перечислить различные форматы изображений, и браузер выберет тот, который он поддерживает, и это позволяет нам сразу же приступить к экспериментам, не беспокоясь о том, что что-то может сломаться для людей со старыми браузерами.

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

Эдди Османи: Есть ли другие пути решения этих проблем? Я не хочу продавать людям слишком много на CDN изображений, я хочу, чтобы они стояли сами по себе. Но это одно из тех мест, где идея, называемая обсуждением содержания, действительно может предложить вам интересный путь. Итак, мы немного поговорили о теге изображения, где вам нужно сгенерировать кучу разных ресурсов и выбрать порядок предпочтения, правильно, дополнительный HTML. Что касается согласования контента, то он говорит, что давайте проделаем всю эту работу на сервере. Таким образом, клиенты могут заранее сообщить серверу, какие форматы он поддерживает, через список типов MIME через HTTP-заголовок Accept. Затем сервер может выполнять всю тяжелую работу по созданию конечных ресурсов и управлению ими, а также решать, какие из них отправлять клиентам. И одна из сильных вещей здесь заключается в том, что если вы используете CDN изображений, вы можете указать на один ресурс.

Эдди Османи: Так что, может быть, если у нас есть изображение щенка, такое как puppy.JPEG, мы могли бы дать людям URL-адрес puppy.JPEG, и если их браузер поддерживает WebP или поддерживает AVIF, сервер может быть очень умным, чтобы обслуживать правильно image для этих пользователей в зависимости от того, как выглядит их поддержка, но в противном случае отступите без необходимости выполнять массу дополнительной работы самостоятельно. Теперь я думаю, что это мощная идея. На сервере можно многое сделать, мы иногда говорим о том, что не у всех есть доступ к действительно качественной сети, ваш эффективный тип подключения может сильно различаться в зависимости от того, где вы находитесь.

Эдди Османи: Даже живя в Силиконовой долине, я могу идти от кафе до отеля или быть в машине, и качество моего Wi-Fi или сигнала может быть не таким хорошим. Так что здесь у вас есть доступ к другим API, другим идеям, таким как подсказка клиента Save-Data для потенциальной возможности обслуживать людей с еще меньшими ресурсами, если пользователь выбрал экономию данных. Так что есть много интересных вещей, которые мы могли бы сделать на стороне сервера, и я действительно думаю, что мы должны продолжать продвигать эти идеи по поиску хорошего баланса, когда люди, которым удобно идти по рыночному пути, имеют всю гибкость для этого. и у людей, которые хотят немного более волшебного решения, также есть несколько вариантов.

Дрю Маклеллан: Впервые о концепции такого подхода к экономии данных я узнал из вашей книги. Я имею в виду, давайте углубимся в это немного больше, потому что это довольно интересно. Итак, вы говорите о том, что браузер может сигнализировать о желании вернуть уменьшенный объем данных, потому что, возможно, он использует лимитное соединение, или у него низкий заряд батареи, или что-то в этом роде.

Эдди Османи: Точно. Точно. Я путешествовал в обычное время или в прежние времена, когда мы путешествовали намного больше, я испытал множество мест в мире или ситуаций, когда качество моей сети могло быть очень плохим или действительно нестабильным, и поэтому даже открывая вверх по веб-странице может быть разочаровывающим или трудным опытом. Я мог бы просматривать меню, и если я не вижу фотографий прекрасной еды, которую они приготовили, я мог бы пойти куда-нибудь, где я могу, или я мог бы, я не знаю, вместо этого приготовить себе еду. Но я думаю, что одна из интересных вещей в экономии данных заключается в том, что она дает вам связь с предпочтениями пользователя. Так что, если я как пользователь знаю, что у меня проблемы с сетевым подключением. Я могу сказать: «Хорошо, я включу режим экономии трафика в своем браузере».

Эдди Османи: И тогда вы как разработчик можете использовать это как сигнал, чтобы сказать: «Хорошо, что ж, пользователь немного ограничен, может быть, мы пролистаем его до изображений гораздо меньшего размера или изображений гораздо более низкого качества». Но они все еще могут увидеть некоторые изображения, что лучше, чем то, что они очень долго ждут, пока им подадут что-то гораздо более богатое. Другие преимущества этих типов сигналов заключаются в том, что вы можете использовать их для условного обслуживания мультимедиа. Так что, возможно, есть случаи, когда текст является самой важной частью этой страницы, может быть, вы можете отключить эти изображения, если обнаружите, что пользователи находятся в своего рода ограниченной среде. Я потрачу на это всего 30 секунд, но вы действительно можете довести эту идею до крайности. Некоторые из интересных вещей, которые вы можете сделать с помощью Save-Data, возможно, даже отключают очень дорогостоящие функции, реализованные в JavaScript.

Эдди Османи: Если у вас есть определенные компоненты, которые считаются немного более необязательными, возможно, их не обязательно отправлять всем пользователям, если они только улучшают работу. Вы по-прежнему можете предоставить всем очень простой, небольшой, быстрый опыт, а затем просто наложить на него немного приятной глазури для людей, у которых более быстрое соединение или устройство.

Дрю Маклеллан: Потенциально, я думаю, это могло бы повлиять на нумерацию страниц, и вы могли бы вернуть 10 результатов на странице, а не 100, и тому подобное. Так много интересных, интересных возможностей там. Я думаю, что мы все знакомы с разочаровывающим процессом подготовки нового сайта, оптимизации всех ваших изображений, передачи его клиенту, предоставления им CMS для управления контентом и обнаружения, что они просто заменяют все на плохо оптимизированные изображения. Я имею в виду, опять же, образ CDN, я думаю, был бы действительно удобным решением для этого, но есть ли другие решения, есть ли что-то, что CMS может делать на сервере, чтобы помочь с этим, или CDN изображения, вероятно, просто путь?

Эдди Османи: Я думаю, что после, по крайней мере, шести или семи лет попыток заставить всех оптимизировать свои изображения, мы обнаружили, что это сложная проблема, когда некоторые люди, участвующие в изображении, могут быть немного более технически подкованными и, возможно, более удобными в настройке. создавать свои собственные инструменты, запускать и запускать Lighthouse или пробовать другие инструменты, чтобы они знали, есть ли возможности для улучшения. Я бы хотел, чтобы люди постоянно использовали такие вещи, как Lighthouse, чтобы поймать, есть ли у вас возможности для дальнейшей оптимизации или показа изображений нужного размера, но помимо этого, иногда мы сталкиваемся с вариантами использования, когда люди, загружающие изображения, не могут обязательно даже понимать стоимость ресурсов, которые они загружают. Обычно мы с этим сталкиваемся, и я приношу свои извинения, я не собираюсь слишком сильно обзывать людей, но это то, с чем мы сталкиваемся даже в блоге Google.

Эдди Османи: Каждые пару недель в блоге Google кто-нибудь загружает очень большие 20- или 30-мегабайтные анимированные GIF-файлы. И я не ожидаю, что они поймут, что это не очень хорошая идея, они пытаются сделать статью крутой, интересной и интерактивной, но эта аудитория не обязательно узнает, что нужно идти и запускать инструменты или использовать ImageOptim. или использовать любой из этих других инструментов на месте и так документировать для них, что они должны проверить их, безусловно, один из вариантов. Но возможность автоматизировать проблему, я думаю, очень убедительна и помогает нам последовательно достигать места, где мы надеемся сбалансировать потребности всех наших пользователей CMS, будь то технические или нетехнические, а также как потребности наших пользователей.

Addy Osmani: So I think the image CDNs can definitely play a role in helping out here. Ultimately, the thing that's important is making sure you have a solution in place between people, stakeholders who might be uploading those images, and what gets served down to users. If it's an image CDN, if it's something you've rolled yourself, if it's a built step, just needs to be something in place to make sure that you are not serving down something that's very, very large and inefficient.

Drew McLellan: Talking about animated GIFs, they're surprisingly popular. They're fun, we love them, but they're also huge. And really, it's a case where a file format that was not designed for video is being used for video. Is there a solution to that with any of these image formats? What can we do?

Addy Osmani: Oh, gosh. The history of GIFs is fascinating. We saw a lot of the formats we know and love or have been around for a while were originated in the late '80s to early '90s, and the GIF is one of those. It was created in 1987. I'm about as old as the GIF.

Addy Osmani: As you mentioned, it wasn't originally created necessarily for use case. I think it was Netscape Navigator which in mid '90s maybe added support for looping GIFs and giving us this kind of crazy fun way to do memes and the like, but GIFs have got so many weaknesses. They're kind of limited in many cases to a very finite color palette; 256 colors, in many cases. They're a bitmapped raster format with pixel value stored in image files.

Addy Osmani: They're very inefficient, for a number of reasons. And you mentioned that they're also quite large. I think that we've gotten into this place of thinking that if we want a short segment of video or animation that's going to be looping, the GIF is the thing that we have to use. And that's just not the case.

Addy Osmani: While we do see that there are modern image formats that have support for animation, I think that the most basic thing you can do these days is make sure you're serving a video down instead of a GIF. Muted auto-play videos combined with HD64, HD65, whatever video you're going to use, can be really powerful, and significantly smaller for use cases where you need to be showing a sequence of images.

Addy Osmani: There are options for this. AVIF has got image sequences in there, potentially. Other formats have explored these ideas as well. But I think that one thing you can do is, if you're using GIFs today, or you have users who are slightly less technical who are using GIFs today, try to see if you can give them tools that will allow them to export a video instead, or if your pipeline can take care of that for them, that's even better.

Addy Osmani: I have plenty of conversations with CMS providers where you do see people uploading GIFs. They don't know the difference between a video and a GIF file. But if you can just, whether it's with an image CDN or via some built process, change the file over to a more efficient format, that would be great.

Drew McLellan: We talked briefly about tools like ImageOptim that manage to strip out information from the files to give us the same quality of result with a smaller file size. I'm presuming that's because the file formats that we commonly deal with weren't optimized for delivery over the Web in the first place, so they're doing that step of removing anything that isn't useful for serving on the Web. Do these new formats take that into consideration already? Is something like ImageOptim a tool that just won't be required with these newer formats?

Addy Osmani: I'm anticipating that some of the older formats… Things that have been around for a while, take a while to phase out or to evolve into something else. And so I can see tools like ImageOptim continuing to be useful. Now, what are modern image formats doing that are much better? Well, I would say that they're taking into account quite a few things.

Addy Osmani: They're taking into account, are there aspects of the picture that the human eye can't necessarily make out a difference around? When I'm playing around with different quality settings or different codecs, I'm always looking for that point where if I take the quality down low enough, I'm going to see banding artifacts. I'm going to see lots of weird looking squares around my buildings or the details of my picture.

Addy Osmani: But once those start to disappear, I really need to start zooming in to the image and making comparisons across these different formats. And if users are unlikely to do that, then I think that there are good questions around is that point of quality good enough? I think that modern image formats are pretty good at being able to help you navigate, filtering out some of those details pretty well. Keeping in mind what are the needs of color, because obviously we've got white gamut as a thing right now as well.

Addy Osmani: Some people might be okay with an amount of changing your color palette versus not, depending on the type of images that you have available, but definitely I see modern formats trying to be resilient against things like generational loss as well. Generational loss is this idea that… We mentioned memes earlier. A common problem on the Web today is you'll find a meme, whether it's on Facebook or Instagram or Reddit or wherever else, you'll save it, and maybe you'll share it around with a friend. Maybe they'll upload it somewhere else. And you suddenly have this terrible kind of copy machine or fax effect of the quality of that image getting worse and worse and worse over time.

Addy Osmani: And so when I see something get reshared that I may have seen three months ago, now it might not be really, really bad quality. You can still make out some of the details, but image formats, being able to keep that in mind and work around those types of problems, I think are really interesting.

Addy Osmani: I know that JPEG XL was trying to keep this idea of generational loss in mind as well. So there's plenty of things that modern codecs and formats are trying to do to evolve for our needs, even if they're very meme focused.

Drew McLellan: Let's say you've inherited a project that has all sorts of images on it. What would be the best way to assess the state of that project in terms of image optimization? Are there tools or anything that would help there?

Addy Osmani: I think that it depends on how much time you've got to sink into the problem. There are very basic things people can try doing, like obviously batch converting those images over to more modern formats at the recommended default quality and do an eyeball check on how well they're doing compared to the original.

Addy Osmani: If you're able to invest a little bit more time, there are plenty of tools and techniques like DSSIM and other ways of being able to compare what the perceptual quality differences are between different types of images that have been converted. And you can use that as a kind of data-driven approach to deciding, if I'm going to batch convert all of my old images to WebP, what is the quality setting that I should be relying on? If I'm going to be doing it for AVIF or JPEG XL, what is the quality setting that I should be relying on?

Addy Osmani: I think that there's plenty of tools people have available. It really just depends on your time sink that's possible. Other things that you can do, again, going back to the image CDN aspect, if you don't have a lot of time and you're comfortable with the cost of an image CDN, you can just bulk upload all of those images. And there are CDNs that support this idea of automatic quality setting. I think in Cloudinary it's q_auto, or something like that.

Addy Osmani: But the basic idea there is they will do a scan of the image, try to get a sense of the type of content that's in there, and automatically decide on the right level of quality that you should be using for the images that are getting served down to users. And so you do have some tooling options that are available here, for sure.

Drew McLellan: I mean, you mentioned batch processing of images. Presumably you're into the area of that generational loss that you're talking about, when you do that. When you take an already compressed JPEG and then convert it to a WebP, for example, you risk some loss of quality. Is batch converting a viable strategy or does that generational loss come too much into play if you care about the pristine look of the images?

Addy Osmani: I think it depends on how much you're factoring in your levels of comfort with lossy versus lossless, and your use case. If my use case is that I've inherited a project where the project in question is all of my family's photos from the last 20 years, I may not be very comfortable with there being too much quality loss in those images, and maybe I'm okay with spending a little bit more money on storage if the quality can remain mostly the same, just using a more modern format.

Addy Osmani: If those are images for a product catalog or any commerce site, I think that you do need to keep in mind what your use case is. Are users going to require being able to see these images with a certain level of detail? And if that's the case, you need to make those trade-offs in mind when you're choosing the right format, when you're choosing the right quality.

Addy Osmani: So I think that batch is still okay. To give you a concrete idea of one way of seeing people approach this at scale, sometimes people will take a smaller sample of the images from that big collection that they've inherited, and they'll try out a more serious set of experiments with just that set. And if they're able to land on an approach that works well for the sample, they'll just apply it to the whole batch. And I've seen that work to varying degrees of success.

Drew McLellan: So optimizing file size is just sort of one point on the overall image optimization landscape. And I'd like to get on to talking about what we can do in our browsers to optimize the way the images are used, which we'll do after a quick word from this episode sponsor.

Drew McLellan: So we've optimized and compressed our large files, but now we need to think about a strategy for using those in the browser. The good old faithful image tag has gained some new powers in recent times, hasn't it?

Addy Osmani: Yeah, it has. And maybe it's useful for folks… I know that a lot of people that ask me about images these days also ask me to frame it in terms of metrics and the Core Web Vitals. Would it be useful for me to talk about what the Core Web Vitals are and maybe frame some of those ideas in those current terms?

Drew McLellan: Absolutely, because Core Web Vitals is a sort of initiative from Google, isn't it, that we've seen more recently? We're told that it factors into search ranking potentially at some level. What does Core Web Vitals actually mean for us in terms of images?

Addy Osmani: Great question. As you mentioned, Core Web Vitals is an initiative by Google, and it's all about trying to share unified guidance for quality signals. That can be pretty key to delivering a great user experience on the Web. And it is part of a set of page experience signals Google Search may be evaluating for ranking purposes, but they can impact the Core Web Vitals in a number of ways.

Addy Osmani: Now, before I talk about what those ways are, I should probably say, what are the Core Web Vitals metrics? There's currently three metrics that are in the Core Web Vitals. There's largest contentful paint, there's cumulative layout shift, and there's first input delay. Now, in a lot of modern Web experiences we find that images tend to be one of the largest visible elements on the page. We see a lot of product pages where we have a big image that's the main product item image. We see images in carousels, in stories and in banners.

Addy Osmani: Now, largest contentful paint, or LCP, is a Core Web Vitals metric that tries to measure when the largest contentful element, whether it's an image text or something else, is in a user's viewport, such that we're able to tell when that image becomes visible. And that really allows a browser to determine when the main content of the page has really finished rendering.

Эдди Османи: Так что, если я пытаюсь перейти на сайт рецептов, меня может волновать, как этот рецепт выглядит, и поэтому мы заботимся о том, чтобы это большое изображение рецепта было видно мне. Теперь элемент LCP может меняться со временем. Очень возможно, что в начале загрузки самой большой вещью может быть заголовок, но по мере того, как страница продолжает загружаться, на самом деле это может оказаться гораздо большим изображением или каким-то плакатом.

Эдди Османи: Итак, когда вы пытаетесь оптимизировать самую большую содержательную отрисовку, вы можете сделать примерно четыре вещи. Во-первых, убедитесь, что вы запрашиваете свое ключевое изображение героя как можно раньше. Как правило, у нас есть ряд вещей, которые важны на странице. Мы хотим убедиться, что можем отобразить содержимое и макет главной страницы.

Эдди Османи: Для макета обычно мы говорим о CSS. Таким образом, вы можете использовать критический CSS, встроенный CSS на своих страницах, хотите избежать вещей, которые блокируют рендеринг, но тогда, когда дело доходит до вашего изображения, в идеале вы должны запрашивать это изображение заранее. Возможно, для этого нужно просто убедиться, что браузер может обнаружить это изображение как можно раньше на странице, учитывая, что многие из нас в наши дни полагаются на фреймворки.

Эдди Османи: Если вы не обязательно используете SSR, рендеринг на стороне сервера, если вы ждете, пока браузер обнаружит некоторые из ваших пакетов JavaScript, пакетов для ваших компонентов, есть ли у вас компонент для вашего основного изображения или изображения продукта, если браузеру приходится ждать, чтобы получить, проанализировать, выполнить, скомпилировать и выполнить все эти различные файлы, прежде чем он сможет обнаружить изображение, это может означать, что ваше самое большое содержательное изображение займет некоторое время, прежде чем его можно будет обнаружить.

Эдди Османи: Теперь, если это так, если вы обнаружите, что изображение запрашивается довольно поздно, вы можете воспользоваться функцией браузера, называемой предварительной загрузкой ссылки, чтобы убедиться, что браузер может обнаружить это изображение как можно раньше. насколько это возможно. Предварительная загрузка — это действительно мощная возможность. Это также то, с чем вам нужно проявлять большую осторожность. В наши дни очень легко добраться до места, где, возможно, вы услышите, что мы рекомендуем предварительную загрузку для вашего ключа.

Эдди Османи: Может быть, вы слышали, что мы рекомендуем предварительную загрузку для вашего ключевого изображения, а также для ваших ключевых скриптов, а также для ваших ключевых шрифтов. И это становится действительно большой, массивной попыткой убедиться, что вы упорядочиваете вещи в правильном порядке. Таким образом, изображения LCP, безусловно, являются одним из ключевых мест, о которых стоит помнить.

Эдди Османи: Во-вторых, как я упомянул четыре вещи, во-вторых, убедитесь, что вы используете исходный код и эффективный современный формат изображения. Я думаю, что исходный набор действительно мощный. Я также иногда вижу, когда люди используют его, они пытаются перекомпенсировать и, возможно, отправляют туда 10 разных версий изображений для каждого возможного разрешения. Мы склонны обнаруживать, по крайней мере, в некоторых исследованиях, что за пределами трех изображений пользователям действительно трудно сказать, в чем разница в качестве изображения, резкости и детализации. Таким образом, ограничение DPR, ограничение соотношения пикселей устройства, безусловно, является идеей, о которой стоит помнить.

Эдди Османи: Что касается современных форматов изображений, мы говорили о форматах ранее, но рассмотрим ваш WebP, ваш AVIF, ваш JPEG XL. Не теряйте пиксели. Для обеспечения качества очень важно иметь хорошую стратегию. И я думаю, что есть много случаев, когда даже качество по умолчанию иногда может быть слишком много. Поэтому я бы поэкспериментировал с попыткой снизить скорость передачи данных, снизить настройки качества и посмотреть, насколько далеко вы можете зайти для своих пользователей, сохраняя при этом четкость.

Эдди Османи: И затем, когда мы говорим о загрузке, одна из других вещей, которую тег изображения как бы эволюционировал для поддержки за последние пару лет, — это отложенная загрузка. Таким образом, если загрузка равна отложенной, вам больше не нужно обязательно использовать библиотеку JavaScript для добавления отложенной загрузки к вашим изображениям. Просто поместите это на свое изображение. А в браузерах Chromium и Firefox вы сможете лениво загружать эти изображения без необходимости использования каких-либо сторонних зависимостей. И это тоже довольно приятно.

Эдди Османи: Итак, у нас есть отложенная загрузка. У нас есть поддержка других вещей, таких как декодирование синхронизации, но я собираюсь продолжить и очень быстро рассказать о двух других основных показателях жизненно важных функций.

Дрю Маклеллан: Дерзайте, да.

Эдди Османи: Итак, избавьтесь от смены макета. Никто не любит, когда что-то прыгает по их страницам. Я чувствую, что одним из моих самых больших разочарований является то, что я открываю веб-страницу. Я навожу палец на кнопку, которую хочу нажать, а потом вдруг выскакивает куча либо рекламы, либо изображений без заданного размера или чего-то еще. И это вызывает очень неприятные ощущения.

Эдди Османи: Таким образом, кумулятивный сдвиг макета пытается измерить нестабильность контента. И в большинстве случаев обычными вещами, которые подталкивают ваши изменения макета, являются изображения или другие элементы на вашей странице, для которых просто не задан размер. Я думаю, что это одно из тех мест, где людям часто несложно задать размеры изображения. Возможно, это не то, чем мы исторически занимались, но, безусловно, то, на что стоит потратить ваше время. Такие инструменты, как маяк, попытаются помочь вам собрать, например, каков список изображений на вашей странице, для которых требуются размеры? Таким образом, вы можете пойти, и вы можете установить их.

Дрю Маклеллан: Я хотел сказать, что это действительно интересный момент, потому что, когда адаптивный веб-дизайн стал чем-то особенным, мы все просматривали наши сайты и убирали размеры изображений, потому что инструменты, которые были в нашем распоряжении для выполнения этой работы, требовали, чтобы мы этого не делали. у наших изображений нет атрибутов высоты и ширины. Но сейчас это плохая идея, не так ли?

Эдди Османи: Старое снова становится новым. Я бы сказал, что определенно стоит установить размеры на ваших изображениях. Установите размеры для ваших объявлений, ваших глазных рамок, всего, что является динамическим контентом, который потенциально может измениться в размере, стоит установить размеры.

Эдди Османи: А для людей, которые создают действительно забавный опыт, есть неправильная фраза, действительно забавный макет, где, возможно, вам нужно больше работать над адаптивными карточками и тому подобным; Я бы подумал об использовании пропорций CSS или полей соотношения сторон, чтобы зарезервировать ваше пространство. И это также может дополнить установку размеров на этих изображениях, чтобы гарантировать, что все будет максимально фиксированным, когда вы пытаетесь избежать изменений макета.

Эдди Османи: И, наконец, последний Core Web Vital — первая задержка ввода. Это то, о чем люди не обязательно всегда думают, когда дело доходит до изображений. Таким образом, на самом деле изображения могут блокировать пропускную способность и процессор пользователя при загрузке страницы. Они могут мешать загрузке других критически важных ресурсов, в частности, при очень медленных соединениях или на более дешевых мобильных устройствах, что может привести к перегрузке полосы пропускания.

Эдди Османи: Таким образом, задержка первого ввода — это показатель Core Web Vital, который фиксирует первое впечатление пользователей об интерактивности и отзывчивости сайта. И поэтому, уменьшая использование ЦП основного потока, ваша первая задержка ввода также может быть минимизирована. В общем, просто избегайте изображений, которые могут вызвать конкуренцию в сети. Они не блокируют рендеринг. Но они по-прежнему могут косвенно влиять на производительность рендеринга.

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

Эдди Османи: Я думаю, что в наши дни очень важно иметь хорошее представление о правильной оптимальной последовательности изображений для отображения чего-либо в верхней части страницы. Я знаю, что выше сгиба — это перегруженный термин, но как в первом окне просмотра пользователя. Очень часто мы можем закончить тем, что пытаемся запросить целую кучу ресурсов, некоторые из которых являются изображениями, которые на самом деле не нужны для того, что пользователь сразу увидит. И это, как правило, отличные кандидаты для загрузки на более поздних этапах жизненного цикла страницы, отличные вещи для ленивой загрузки на месте. Но если вы запрашиваете целую кучу изображений, например, целую очередь вещей на очень раннем этапе, это потенциально может оказать влияние.

Дрю Маклеллан: Да. Итак, я имею в виду, вы упомянули отложенную загрузку изображений, для которой нам исторически требовалась библиотека JavaScript, у которой есть свои недостатки, я думаю, из-за исторических способов, которыми браузеры оптимизируют загрузку изображений, когда почти невозможно остановить их загрузку изображений , если вы просто не дадите ему источник. И если вы не дадите ему исходный код, а затем попытаетесь исправить его с помощью JavaScript, если этот JavaScript не запустится, вы не получите изображения. Так что ленивая загрузка, нативная ленивая загрузка — это ответ на все это.

Эдди Османи: Да, абсолютно. И я думаю, что это то место, где мы пытались улучшить в разных браузерах нативную ленивую загрузку за последний год. Как вы знаете, это одна из тех функций, где мы выпустили что-то раньше, и мы можем воспользоваться беседами с лидерами мнений в отрасли, чтобы понять, например: «О, эй, какие пороги вы на самом деле устанавливаете вручную. если вы используете ленивые размеры или используете другие библиотеки JavaScript с ленивой загрузкой?» А затем мы настроили наши пороги, чтобы попытаться немного приблизиться к тому, что вы ожидаете.

Эдди Османи: Так что во многих случаях вы можете просто использовать нативную ленивую загрузку. Если вам нужно что-то более совершенное, если вам нужно гораздо больше контроля над возможностью установки пороговых значений наблюдателя пересечения, момент, когда браузер будет запрашивать что-то, мы обычно предлагаем пойти и использовать библиотеку в этих случаях. , просто потому, что мы пытаемся решить вариант использования 90%. Но 10% все еще в силе. Возможно, есть люди, которым все еще нужно что-то еще. Итак, я надеюсь, что для большинства людей встроенная отложенная загрузка будет достаточно хороша в обозримом будущем.

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

Эдди Османи: Для начала стоит понять, насколько это проблема для вашего сайта. Я бы пошел и проверил либо маяк, либо платную информацию о скорости. Запустите его на нескольких ваших самых популярных страницах и просто посмотрите, что получится. Если вам кажется, что у вас есть только одно или два небольших дела, это просто фантастика. Может быть, вы можете провести там некоторое время.

Эдди Османи: Если у вас есть длинный список вещей, которые вы должны сделать, возможно, взгляните на самые высокие возможности, которые у вас есть, вещи, которые говорят: «О, эй, вы могли бы сэкономить несколько секунд, если бы вы сделали это. предмет." И сосредоточьте свою энергию там для начала.

Эдди Османи: Как мы уже говорили, инструменты для современных форматов изображений со временем стали лучше. CDN изображений, безусловно, стоит рассмотреть. Но помимо этого, есть много маленьких шагов, которые вы можете предпринять. Иногда, если это достаточно маленький сайт, даже если вы просто открываете Squoosh, размещение нескольких ваших изображений может стать отличной отправной точкой.

Дрю Маклеллан: Это хороший совет. Теперь я знаю, что это потрясающее издание, но я действительно должен поздравить вас с книгой. Это настолько всесторонне и действительно легко усваивается. Я думаю, что это действительно ценное чтение.

Дрю Маклеллан: Итак, я узнал все об оптимизации изображений. О чем ты узнал в последнее время, Эдди?

Эдди Османи: О чем я узнал в последнее время? На самом деле, это немного другая тема, которая все еще связана с изображениями, поэтому, когда я учился в магистратуре в колледже, я очень глубоко погрузился в компьютерное зрение и пытался понять, как мы можем обнаруживать разные части изображения и делать дикие и интересное с ними?

Эдди Османи: И конкретная проблема, которую я недавно исследовал, заключается в том, что я смотрю на свои фотографии, когда я был младенцем или ребенком. И тогда многие продукты, которые брали с собой мои родители, не обязательно были на цифровых камерах. Это были поляроиды. Часто это изображения с низким разрешением. И я хотел найти способ масштабировать их. И вот я недавно снова начал копаться в этой проблеме. И это привело меня к тому, что я узнал гораздо больше о том, что я могу делать в браузере.

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

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

Дрю Маклеллан: Забавно, не правда ли? Когда появляется технология, которая переворачивает все, что вы знаете, с ног на голову. Мы всегда говорили, что в Интернете мы можем уменьшать изображения. Но если у нас есть только маленькое изображение, мы не можем сделать его больше. Это просто невозможно. Но теперь у нас есть технология, которая при многих обстоятельствах может сделать это возможным. Это действительно увлекательно.

Дрю Маклеллан: Если вы, дорогой слушатель, хотели бы услышать больше от Эдди, вы можете найти его в Твиттере, где он @AddieOsmani, и найти ссылки на все его проекты на AddyOsmani.com. Книга «Оптимизация изображений» доступна как в физическом, так и в цифровом виде от Smashing прямо сейчас на smashingmagazine.com. Спасибо, что присоединилась к нам сегодня, Эдди. У тебя есть напутствие?

Эдди Османи: Какие-нибудь напутствия? У меня есть небольшая причуда из истории, которой я поделюсь с людьми. Тим Бернерс-Ли загрузил самое первое изображение в Интернет в 1992 году. Я не уверен, что вы можете догадаться, что это было, но вы, вероятно, будете удивлены. Дрю, у тебя есть предположения?

Дрю Маклеллан: Полагаю, кошка.

Эдди Османи: Кошка. Это хорошее предположение, но нет. Это было в ЦЕРНе. На самом деле это был образ группы Les Horribles Cernettes, пародийной поп-группы, созданной группой сотрудников CERN. И музыка, которую они будут делать, похожа на музыку ду-воп. И они пели песни о любви о коллайдерах, причудах, жидком азоте и антиматерии, одетые в костюмы шестидесятых, которые я находил просто замечательными и случайными.