Разное

Прогрессивный jpeg – новый best practice / Habr

Содержание

новый best practice / Habr


С точки зрения пропускной способности канала, изображения — обжоры. В среднем, они занимают наибольший (62%) средний трафик сайтов и чаще всего их передача является узким местом. Загружаясь, изображения рвут страницу, расталкивая другие элементы вокруг и вызывая неуклюжую перерисовку (прим. перев.: от этого, конечно, можно избавиться определенной версткой, но тогда нужно хардкодить или ограничивать размеры картинок). Загрузка изображения на странице воспринимается или как «тик, тик, тик, тик, тик, готово», или же сначала вообще ничего нет, а потом внезапно «бум!» и оно появляется ниоткуда. Все понимают, что подразумевается под «тик, тик, готово» и «бум» и всех нас это немного раздражает, потому что мы чувствуем, сколько времени наших прелестных и коротких жизней потеряно в ожидании загрузки картинок.
Упущенная возможность

Фотографии — главный виновник медленного рендеринга. Они являются наиболее часто запрашиваемым типом изображений и в среднем весят больше остальных. В них миллионы цветов и количество бит на пиксель продолжает увеличиваться. Они красивы и мы не хотим компромиссов на качестве.

Оптимизированные для веба фото — это jpeg, а jpeg делится на два типа: базовый последовательный (baseline) и прогрессивный (progressive). Последовательный jpeg — это один скан изображения сверху вниз в полном разрешении, а прогрессивный jpeg — это серия сканов улучшающегося качества. Так они и рендерятся — последовательный jpeg отрисовывается сверху вниз («тик, тик, тик, …»), а прогрессивный быстро размечает свою территорию и затем совершенствуется (по крайней мере так задумано).

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

В локальном эксперименте — иллюстрация в начале поста — на задушенном канале, 80-килобайтный прогрессивный jpeg появляется на странице раньше, чем 5-килобайтный последовательный jpeg (то же самое изображение, уменьшенное в размере) в Firefox под Windows, что должно произвести впечатление. Конечно, на первом проходе прогрессивный jpeg имеет низкое разрешение, но он содержит столько же информации, сколько и маленькое изображение, или даже больше. А если масштаб страницы уменьшен, например, на мобильном устройстве, то низкое разрешение даже не заметно. Адаптивные изображения работают на нас прямо сейчас (

прим. перев.: отсылка к responsive web design)!

По существу, прогрессивный jpeg лучше. Так какой же самый распространенный тип jpeg в сети? Угадали: последовательный, и с очень большим отрывом. В выборке из тысячи изображений, 92.6% — последовательные.

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

Проверка реальностью №1

Прогрессивные jpeg отрисовываются во всех браузерах, об этом не стоит переживать. Нас волнует то, как они отрисовываются.

Поведение прогрессивных jpeg в браузерах

Браузер (конкретная версия) Отрисовка прогрессивных jpeg переднего плана (foreground)
Отрисовка прогрессивных jpeg заднего плана (background)
Chrome (v 25.0.1323.1 dev Mac, 23.0.1271.97 m Win) прогрессивно (очень быстро!) прогрессивно (очень быстро!)
Firefox (v 15.0.1 Mac, 12.0 Win) прогрессивно (очень быстро!) мгновенно после загрузки файла (медленно)
Internet Explorer 8 мгновенно после загрузки файла (медленно) мгновенно после загрузки файла (медленно)
Internet Explorer 9 прогрессивно (очень быстро!) мгновенно после загрузки файла (медленно)
Safari (v 6.0 Desktop, v 6.0 Mobile) мгновенно после загрузки файла (медленно) мгновенно после загрузки файла (медленно)
Opera (v 11.60) UPD: прогрессивно (очень быстро!) (proof) мгновенно после загрузки файла (медленно)

Результаты разочаровывающие, но в целом, доля рынка браузеров с прогрессивной отрисовкой прогрессивных jpeg идет вверх. Поддержка пока что составляет около 65% (Chrome + Firefox + IE9).

К сожалению, браузеры, которые не рендерят прогрессивные jpeg прогрессивно, отрисовывают их сразу целиком после того, как загрузка изображения завершена, что, по сути, делает их менее прогрессивными. Они становятся медленнее, чем последовательные jpeg. Несмотря на то, что последовательная отрисовка не такая быстрая и плавная, как прогрессивная, она по крайней мере дает хоть что-то, пока мы ждем, и «тик, тик» является своего рода индикатором загрузки (хорошей вещью). Нельзя недооценивать уверенность, которую чувствуют пользователи видя, что что-то происходит.

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

Проверка реальностью №2

Вы можете спросить «А не будут ли прогрессивные jpeg весить больше, чем обычные? Не платим ли мы за “слои”?». С некотороыми другими типами многослойных изображений — платим, но не с jpeg. Прогрессивный jpeg обычно на несколько килобайт меньше, чем его же последовательная версия. Стоян Стефанов в процессе построения графика конвертации 10000 случайных последовательных jpeg в прогрессивные, открыл ценное практическое правило: файлы больше 10Кб, чаще всего, будут весить меньше в прогрессивном варианте.

Убеждать стало бы проще, если бы можно было сказать, что прогрессивные jpeg всегда весят меньше, так что их и нужно всегда использовать. Стоян нам в этом помогает. Он говорит: «Еще одно наблюдение по поводу правила 10Кб: в тех случаях, когда вес последовательного jpeg меньше, он меньше с небольшой разницей. А когда меньше прогрессивный, то он обычно меньше намного. Так что говорить, что нужно всегда использовать прогрессивный и станет лучше — это нормально».

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

Причиной того, что последовательные jpeg наиболее распространены в сети, является, без сомнения, то, что инструменты оптимизации изображений создают их по умолчанию. Однако, все просмотренные мною — Photoshop, Fireworks, ImageMagick, jpegtran — имеют возможность сохранения и в прогрессивном варианте. Таким образом, чтобы отдавать прогрессивные jpeg, нужно сознательно модифицировать свой процесс оптимизации изображений.

Например, Smushit может переводить последовательные jpeg в прогрессивные. Smushit, кстати, можно запускать из командной строки и интегрировать в процесс оптимизации изображений.

Как узнать, что ваши jpeg прогрессивные? Вот несколько способов идентификации типа jpeg:

  1. ImageMagick — из командной строки запустите: identify -verbose mystery.jpg | grep Interlace На выходе будет или “Interlace: JPEG”, или “Interlace: None.”
  2. Photoshop — Откройте файл. Выберите File -> Save for Web & Devices. Если это прогрессивный jpeg, то флажок Progressive будет отмечен.
  3. Любой браузер — Последовательные jpeg будут загружаться сверху вниз, а прогрессивные будут вести себя по-другому. Если файл загружается слишком быстро, может понадобиться ограничение пропускной способности канала. Я использую ipfw под Mac’ом.
Проверка реальностью №3

Согласно этому FAQ по сжатию jpeg, каждый прогрессивный проход отрисовки нагружает ЦПУ примерно на столько же, на сколько отрисовка целого последовательного jpeg. Это неважно для настольных ПК, но возможно имеет значение для мобильных устройств.

Лишние вычисления — недостаток, но не камень преткновения. Предоставление фотографий на слабом аппаратном обеспечении — сложная задача вне зависимости от этого. Я в курсе дела, потому что пишу приложение-фотогалерею с бесконечным скроллингом и оно падает на iPad’e. При обработке большого количества изображений на мобильных платформах сложные задачи возникнут в любом случае.

Как видно в таблице, мобильный Safari не отрисовывает прогрессивные jpeg прогрессивно и вероятно потому, что они нагружают ЦПУ. Прогрессивый jpeg не является новым форматом изображений. Следовательно, осознанно и без причин не поддерживать прогрессивный jpeg — не вариант для браузеров, даже для мобильных. Будем надеяться, что скоро мобильные браузеры станут справляться с прогрессивным рендерингом, но причины текущего отсутствия поддержки имеют смысл. Очень обидно, потому что как раз на мобильных устройствах прирост скорости и экономия в размерах файлов, которые предоставляет прогрессивный jpeg, пришлись бы очень кстати. Выше было упомянуто, что он как бы является решением для адаптивных изображений на данный момент. На самом деле он мог бы быть таковым, но время еще не пришло.

Глядя в будущее

Месяц назад, Google запрыгнул на борт со своим сервисом Mod_Pagespeed, сделав convert_jpeg_to_progressive основным фильтром. SPDY тоже не отстает, переводя jpeg более 10Кб в прогрессивные по умолчанию, согласно практическому правилу Стояна. Браузеры, поддерживающие инкрементальное отображение, от этого станут казаться намного быстрее. Как видно из таблицы выше, включающей Google Chrome, такие действия Google имеют смысл. Я не стану говорить, что если уж «не-причиняй-зла-делай-веб-быстрее» Гугл выбрал progressive jpeg как best practice, то и мы должны тем более. Но это лишнее подтверждение. И самое главное, это показывает, что прогрессивный jpeg — формат, который был в своего рода морозилке на протяжении десятилетия — начинает свое возвращение.

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

habr.com

Progressive JPEG - что за зверь?

Что такое progressive JPEG?

Progressive JPEG – это JPEG-изображение в прогрессивном формате. Прогрессивный формат изображения позволяет браузеру загружать не количественно, а качественно. Другими словами – загружать изображение постепенно, постоянно отображая это изображение с различным качеством от 0 до 100 процентов.

Просто сравните

Рис1. Загрузка изображения в обычном (последовательном) формате

Рис 2. Загрузка изображения в прогрессивном формате

На мой взгляд, progressive JPEG – это чертовски здорово! Знаете, progressive JPEG появился уже очень давно (порядка 10 лет назад), однако сайтов, использующих эту технологию довольно мало, особенно в нашей стране.

И я не знаю почему. На Хабре есть статья на эту тему. Она там лежит аж с 2013 года. Да, на тот момент не так хорошо браузеры поддерживали эту технологию. Но время не стоит на месте. И поэтому уже давно пора переходить на progressive JPEG.

Как сделать progressive JPEG своими руками

Сохранить изображение в прогрессивном формате проще простого. Способов несколько:

  1. Если вы владеете Photoshop, то можете сохранить изображение с помощью него. Нужно всего лишь выбрать в меню опцию “Сохранить для веб” и поставить галочку напротив пункта “Прогрессивный формат”.
  2. Использовать онлайн-сервис, например https://www.jpeg.io/. Таких сервисов довольно много, нужно только уметь искать 🙂
  3. Использовать плагин для CMS. Для WordPress можно рассмотреть, например, Kraken.io Image Optimizer. Правда, он платный… Взвесьте все «за» и «против», прежде чем покупать его.
  4. Если же вы или ваши сотрудники имеют навыки администрирования серверов, то вы можете настроить оптимизацию у себя на сервере. Но об этом побеседуем в другой теме.

А нужно ли оно мне вообще?

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

Разница между последовательным и прогрессивным JPEG может быть незаметна на компьютерах. На компьютерах с очень хорошим интернетом (больше 100 Мбит/с) браузер загружает изображение настолько быстро, что изображение прогружается моментально в полном объёме. Тоже самое может происходить с маленькими изображениями. Если же соединение слабое (обычно это мобильные сети, к примеру 3G), или изображение имеет большой размер, то разница между последовательным и прогрессивным форматом будет “налицо”.

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

walnut.team

Ускоряем изображения еще больше при помощи HTTP2 и Progressive JPEG

От автора: прогрессивные изображения на HTTP2 быстрее отрисовываются на экране, что повышает восприятие производительности. Используйте сканирующие слои JPEG изображений для показа понятного контента при отправке всего лишь 25% от самого изображения. Для максимального увеличения производительности ключевых изображений используйте HTTP2 Server Push для сканирующих слоев JPEG.

Проблемы с изображениями

Изображения очень важны: они завлекают нас, бесят, побуждают к чему-либо. Интернет в известной нам форме зависит от изображений. Изображения составляют ~65% от общего веса страницы, а также они сильно связаны со временем загрузки страницы и индексом скорости. Если коротко, изображения очень тяжелые и все замедляют.

Сжимайте!

Сжатие – лучший способ исправления отрицательного эффекта от загрузки изображений. С помощью сервисов типа ImageOptim от Kornel Lesiński, который использует замечательные библиотеки mozjpeg и pngquant, можно уменьшить вес изображений без визуальных потерь качества. Благодаря библиотекам типа DSSIM мы можем тестировать качество изображений на разных уровнях сжатия.

Плохая новость заключается в том, что даже после сжатия изображений в среднем на ~29% с помощью описанных выше инструментов, а также при использовании других форматов типа WebP, изображения все равно остаются самыми большими файлами на сайте. Ближайший собрат в этом отношении – JS. Нужно найти способ, как быстрее поставлять эти компоненты, чтобы быстрее завлекать пользователя.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

Знакомство с многоканальной передачей

Частично вопрос производительности решается с помощью HTTP2. Одно из главных преимуществ данного протокола – многоканальная передача – способность обрабатывать несколько запросов и ответов за раз, используя одно TCP соединение.

Многоканальная передача ускоряет загрузку файлов с сайта. В зависимости от структуры сайта можно выставить приоритет ресурсов при многоканальной передаче: если критическому CSS поставить высокий приоритет, он будет загружаться быстрее через HTTP2. Кроме того, подгружая еще не запрошенные файлы через HTTP2 Server Push, при правильном подходе можно серьезно улучшить восприятие производительности. Более подробно на эту тему чуть ниже.

При загрузке изображений через многоканальную передачу данных появляется интересный побочный эффект: с точки зрения восприятия производительности отдельные типы изображений загружаются значительно быстрее из-за того, что первичная информация об изображении загружается параллельно через многоканальную передачу данных HTTP2. К таким типам можно отнести прогрессивный JPEG и чересстрочный PNG.

Все прогрессивно

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

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

Джон Меллор из Google в 2012 году уже говорил о восприятии производительности и индексе скорости при загрузке сканирующих слоев прогрессивных JPEG изображений через HTTP2 Multiplexing. Он экспериментировал с протоколом SPDY, предшественником HTTP2. Сегодня мы можем продвинуть еще дальше его открытие и заставить прогрессивные изображения загружаться еще быстрее.

Возвращаем власть в наши руки или сканирующие файлы

По умолчанию в прогрессивных JPEG изображениях 10 сканирующих слоев. То есть для загрузки изображения с исходным качеством проходит 10 итераций с загрузкой слоев с информацией. Первый слой JPEG изображений всегда имеет высокую пикселизацию и зачастую выполнен в черно-белом варианте для экономии на цветовых каналах. Хотите узнать, как выглядят все слои? Воспользуйтесь инструментом jsk от Frédéric Kayser, в котором прогрессивное изображение можно разбить на отдельные слои.

Почему именно 10 слоев? Это значение по умолчанию во всех стандартных кодировках JPEG. Так достигается идеальный баланс между размером каждого слоя и качеством, а также данное значение помогает достичь наименьшего веса конечного файла путем оптимизации через таблицы Хаффмана.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

В отличие от PNG изображений, где для создания черессточных слоев используется фиксированный метод кодировки Adam7, JPEG кодировки можно расширить директивами: флаг «-scans» для кодировок JPEG. С mozjpeg флаги можно использовать следующим образом: «cjpeg -quality 75 -scans customscans.txt -outfile output.jpg input.jpg». Кодеры JPEG принимают текстовые файлы с вашими командами для создания слоев.

Каждая строка в сканирующих файлах задает новый сканирующий слой. Каждый слой хранит много информации о цветовом канале, индексе матрицы и потерях.

В сканирующем файле есть три канала – яркость (Y), синий (Cb) и красный (Cr) под номерами 0, 1 и 2 соответственно. Индекс матрицы в файле начинается с 0 и идет до 63, покрывая блок в 64 пикселя (кодировка JPEG имеет блок 8х8).

Креативим

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

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

Скрипт сканирования выше – лишь один пример настройки кодировки прогрессивных JPEG изображений: используя этот подход, можно воссоздать технику LQIP от Guy Podjarny в прогрессивных изображениях JPEG, как показал Jon Sneyers.

Push! Push! Push!

Для еще более быстрой загрузки изображений в HTTP есть еще один инструмент — Server Push. На серверах с поддержкой HTTP2 есть возможность помечать отдельные слои прогрессивных JPEG изображений высоким приоритетом, что заставит сервер передать эти слои в Push-кэш браузера пользователя еще до самого запроса на изображение. Браузеры могут выстраивать структуру страницы и отрисовывать первичные слои изображения из кэша, ускоряя тем самым для пользователей воспринимаемую отрисовку изображений.

Более подробно изучить HTTP2 Server Push можно в замечательной статье в разделе Performance Advent Calendar.

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

Заключение

Благодаря многоканальной передаче через HTTP2, прогрессивные и чересстрочные изображения отрисовываются гораздо быстрее.

Управление созданием прогрессивных JPEG изображений может дать пользователю лучший визуальный опыт.

HTTP2 Server Push может улучшить восприятие производительности важных изображений.

Автор: Tobias Baldauf

Источник: https://calendar.perfplanet.com/

Редакция: Команда webformyself.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

Верстка-Мастер. От теории до верстки популярных шаблонов

Изучите современную верстку сайтов с нуля

Подробнее

webformyself.com

Progressive JPEG для фотографов - эффективное использование PJPEG


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

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

Мы не сильно погрешим против истины, если скажем, что фотограф – это человек с фотоаппаратом, талантом и знаниями, плюс своя аудитория.

В конце концов, не только фотографы-профессионалы жаждут презентовать своё творчество зрителям, которые могут стать еще и потенциальными клиентами впоследствии.

Буквально все, у кого есть современные устройства, активно эксплуатируют всемирную паутину для донесения застывших моментов реальности широкой публике.

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

Но при размещении фотографий высокого качества в интернете, могут появиться определённые трудности.

Общая картина с приличными по скорости интернет-каналами заставляет желать лучшего. А уж высокоскоростная передача данных стационарного (оптика, ADSL и т.д.) и мобильного (UMTS, WiMax, LTE) типов доступна далеко не везде.

Вот ведь ирония: сейчас компания Yota разворачивает в ряде регионов сети 4G, на основе LTE Advanced. В то время, как предшественник - 3G, представлен скорее фрагментарно, ограничиваясь мегаполисами и связывающими их крупными транспортными артериями.

Внушительный процент всех существующих интернет-каналов (радио и проводных) представлен низкоскоростными каналами.

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

Вывод на экран полноразмерного снимка при медленном интернете может достигать минут. Можно ли что-нибудь сделать? Пожалуй, что да.

Progressive JPEG - эффективное использование PJPEG

Речь здесь пойдёт не о каналах и провайдерах и не о тех случаях, когда постятся фотки с мобильника в Контакт. Но если загружаем снимки на 16 Мп в Panoramio, то достаточно пары кликов, чтобы существенно улучшить и скорость загрузки фото, и комфорт для зрителей.

Всё это при том же самом размере файлов и кадров.

Как правило, основная масса фото отправляется на сервер в формате JPEG после предварительной обработки - цвето и яркостная коррекция, обрезка и прочее.

И здесь есть шанс повлиять на ситуацию. При сохранении снимка в JPEG, по умолчанию используется метод Baseline. Снимок, созданный с его применением, в браузере "разворачивается" последовательно сверху донизу - по мере загрузки файла.

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



Затем далее...



И так – до победного конца. Но часто пользователь понятия не имеет о том, что находится на загружаемом фото и нужно ли оно ему.

Однако, приходится ждать, пока достаточный для понимания сути снимка объём загрузится.

Избежать такого неудобства для пользователя несложно: технология JPEG имеет ещё один метод построения снимка – прогрессивный метод или Progressive JPEG.

В нём весь массив данных может быть разделён особым образом на несколько групп по частотам либо по разрядам значений пикселей. Количество таких групп можно задать при сохранении файла.

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

При этом грузится сразу весь снимок, но сниженного качества, т.к. передаётся лишь часть информации. Можно не дожидаясь вывода всех групп принять решение – нужен нам этот снимок или нет.

Так, последовательно друг за другом грузятся все группы (в стандарте они называются СКАНЫ):

Первая...



Вторая...



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



Таким образом, Progressive JPEG способен экономить время на медленных каналах. Кроме того, многочисленные опыты подтвердили снижение времени полной загрузки изображений в формате Progressive JPEG, по отношению к Baseline. В этом нетрудно убедиться каждому желающему.

Создавать файлы с использованием Progressive JPEG способен довольно широкий спектр графических редакторов. Их различие лишь в количестве доступных пользователю настроек.




Так, Adobe Photoshop способен задавать различное количество сканов. Ряд других же программ - к примеру, популярный FastStone Image Viewer, на сегодняшний момент такой опции пока не имеет.

Как показала практика, на низкоскоростном канале в 64 кб/с изображение в Progressive JPEG весом 100-200 кБ грузится быстрее, нежели меньшее по весу такого же размера в Baseline JPEG.

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

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


Добавить эту страницу в закладки:

hightech.in.ua

Прогрессивная загрузка изображений: как она воспринимается пользователями

532

В последнее время часто встречаются статьи о том, как не показывать пользователям пустое место на странице, пока там не загрузилось изображение. Подобную технологию можно встретить на сайтах и в приложениях Medium и Facebook.

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

Быстрый рендеринг всегда лучше медленного. Главное — вывести на экран хоть что-то, пусть это и не готовый контент.

Но уверены ли мы в этом? Изучив комментарии на Reddit, я нашёл много интересных (в том числе и негативных) комментариев. Вот два из них:

«Ненавижу сайты, которые показывают размытое изображение, пока не загрузилось основное. Приходится отводить взгляд и щуриться, чтобы читать дальше. Хочу найти способ отключить этот функционал».
— rocky1138, Hacker News

«Кто и когда решил, что если показывать сначала картинку низкого качества, загрузка будет казаться более быстрой? По мне, так все эти эффекты только отвлекают и выглядят ужасно. Загрузка уж точно не кажется более быстрой. Я все равно не могу понять, что на изображении, пока оно не загрузилось, есть там размытая заглушка или нет».
— dwb, Hacker News

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

Уже давно существует встроенная в изображения «технология прогрессивной загрузки». Хороший пример — прогрессивный JPEG.

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

«Изображения в прогрессивном JPEG лучше, потому что они быстрее. Субъективная скорость важнее, чем настоящая скорость. Даже если мы загрузим на сайт слишком много изображений, то с помощью прогрессивного JPEG можно отобразить намного больше информации».

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

Базовое кодирование JPEG— изображения

Прогрессивное кодирование JPEG— изображения

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

С точки зрения пользователя, методы прогрессивной загрузки, такие как Blur-up и SQIP, похожи на прогрессивный JPEG: сначала браузер показывает изображение с низкой детализацией, а после загрузки заменяет его оригинальным.

Что интересно, большинство JPEG-файлов используют базовый режим. Прогрессивные JPEG-изображения составляют максимум 7% от всех файлов JPEG. Если прогрессивная кодировка субъективно ускоряет загрузку, почему прогрессивный JPEG не получил большего распространения?

Мне удалось найти только одно исследование по теме, озаглавленное «Прогрессивный рендеринг изображений: добро или зло?»

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

Согласно результатам этого исследования, людям сложнее воспринимать прогрессивные JPEG, хотя на первый взгляд они и должны улучшать опыт пользователей.

Недавно я упомянул об этом исследовании в дискуссии, посвящённой LQIP («изображениям-заглушкам низкой детализации», от английского Low-Quality Image Placeholders). Сразу в нескольких ответах прозвучали сомнения в научной строгости исследования:

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

— Tobias Baldauf 🥠 (@tbaldauf) 9 декабря, 2017

Ограниченное и спорное исследование. Чтобы делать какие-либо выводы, нужны большие объёмы данных.

— Yoav Weiss (@yoavweiss) 9 декабря, 2017

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

Представим две следующих раскадровки, записанных с некого сайта:

Схема загрузки одного и того же сайта.

Пользователь субъективно воспринимает версию B как загружающуюся быстрее, чем версия A. Это происходит из-за того, что отдельные части страницы в версии B загружаются быстрее, чем в версии А.

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

Чтобы оценить, как быстро загружается страница, сегодня используются такие показатели, как индекс скорости (Speed Index). Он измеряет процент того, насколько визуально закончена загрузка страницы. Чем ниже результат, тем лучше:

Формула индекса скорости

Изначально Speed Index измерял прогресс, сравнивая изменения в гистограммах каждого из основных цветов (красного, зелёного и синего). Этот метод называется «средняя разница гистограмм». Он помогает избежать ошибок, когда все элементы страницы могут одновременно сдвигаться на несколько пикселей в процессе загрузки. Подробно ознакомиться с работой алгоритма Speed Index можно в разделе документации, посвящённом измерению визуального прогресса.

Я решил испытать, как работает с заглушками низкой детализации тест WebPagetest:

Раскадровка, демонстрирующая степень визуальной завершённости в процентах.

Мы видим, что изображение загружается между 8 и 10 секундами. Размытая заглушка увеличивает процент завершённости с 75 до 83. Загрузка окончательной версии изображения доводит эту цифру до 93%.

Получается, что, согласно алгоритму Speed Index, заглушка вносит свой вклад в визуальную завершённость страницы. Видно и то, что заглушка не воспринимается как завершённая зона.

Speed Index — не единственный способ измерения скорости рендеринга страницы. В инструментах разработчика Chrome есть возможность запустить проверку производительности. Зайдите в меню Audits → Perform an audit → Run audit.

После выполнения проверка выдаёт вот такой отчёт:

Обратите внимание на размытую заглушку, которая затем превращается в финальное изображение.

Один из показателей проверки называется “Perceptual Speed Index” («Субъективный индекс скорости») и показывает значение 4,245. Что он означает? Возможно, это то же самое, что и Speed Index из теста WebPagetest?

Подход Speed Index с измерением схожести пикселей (та самая «средняя разница гистограмм») имеет свои недостатки. К примеру, он не учитывает визуальную схожесть фигур, цветов и объектов.

Четыре разных фигуры с одинаковым количеством чёрных и белых пикселей.

В большинстве случаев это не сильно повлияет на оценку визуальной завершённости — на практике Speed Index и Perceptual Speed Index в значительной степени совпадают.

«В ходе масштабных исследований (с использованием собранных WebPagetest видеозаписей более чем 500 страниц из мобильного рейтинга Alexa) мы увидели, что SI и PSI демонстрируют линейную корреляцию с коэффициентом 0,91», — Измерение скорости загрузки видимой части страницы при помощи Perceptual Speed Index (PSI)

В документации к инструментам Google Lighthouse сказано, что PSI измеряется при помощи модуля Speedline. Он рассчитывает субъективный индекс скорости исходя из тех же принципов, что и обычный индекс скорости. Но при этом учитывает видимый прогресс загрузки, используя SSIM, а не разницу гистограмм.

SSIM («структурное сходство», от английского Structural Similarity) используется для измерения сходства двух изображений. Этот метод моделирует восприятие изображений человеческим глазом и учитывает, насколько похожи фигуры, цвета и объекты. Но на этом применение SSIM не ограничивается. Интересно использование структурного сходства при оптимизации сжатия изображений. Например, кодировка cjpeg-dssim использует максимальную степень сжатия jpeg и создаёт изображение с SSIM, близким к оригинальному.

В примере, приведенном ниже, показаны SVG-изображения, созданные в Primitive и проверенные в Image SSIM JS. Чем больше фигур мы используем, тем ближе оценка к изначальному изображению, где SSIM = 1.

Воспроизведение двух изображений при помощи треугольников. Чем больше фигур используется, тем ближе изображение к оригиналу.

Более новые альтернативы SSIM — это butteraugli (используется в кодеке Guetzli, Google’s Perceptually Guided JPEG Encoder) и SSIMULACRA.

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

Мы — разработчики, и наша задача — измерять производительность. Это единственный способ, позволяющий понять, над чем конкретно нужно работать.

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

Мы, как разработчики, должны уделять больше внимания скорости загрузки сайтов. Хорошо, что у нас есть такие инструменты, как WebPageTest и Lighthouse, помогающие измерить эффективность прогрессивных методов загрузки изображений!

Данная публикация представляет собой перевод статьи «Taking A Look At The State Of Progressive Images And User Perception» , подготовленной дружной командой проекта Интернет-технологии.ру

www.internet-technologies.ru

Прогрессивный JPEG: новый best practice


С точки зрения пропускной способности канала, изображения — свиньи. В среднем, они занимают наибольший (62%) средний трафик сайтов и чаще всего являются бутылочным горлом. Загружаясь, изображения рвут страницу, расталкивая другие элементы вокруг и вызывая неуклюжую перерисовку (прим. перев.: от этого, конечно, можно избавиться определенной версткой, но тогда нужно хардкодить или ограничивать размеры картинок). Загрузка изображения на странице воспринимается или как «тик, тик, тик, тик, тик, готово», или же сначала вообще ничего нет, а потом внезапно «бум!» и оно появляется ниоткуда. Все понимают, что подразумевается под «тик, тик, готово» и «бум» и всех нас это немного раздражает, потому что мы чувствуем, сколько времени наших прелестных и коротких жизней потеряно в ожидании загрузки картинок.

Упущенная возможность

Фотографии — главный виновник медленного рендеринга. Они являются наиболее часто запрашиваемым типом изображений и в среднем весят больше остальных. В них миллионы цветов и количество бит на пиксель продолжает увеличиваться. Они красивы и мы не хотим компромиссов на качестве.

Оптимизированные для веба фото — это jpeg, а jpeg делится на два типа: базовый последовательный (baseline) и прогрессивный (progressive). Последовательный jpeg — это один скан изображения сверху вниз в полном разрешении, а прогрессивный jpeg – это серия сканов улучшающегося качества. Так они и рендерятся — последовательный jpeg отрисовывается сверху вниз («тик, тик, тик, …»), а прогрессивный быстро размечает свою территорию и затем совершенствуется (по крайней мере так задумано).

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

В локальном эксперименте — иллюстрация в начале поста — на задушенном канале, 80-килобайтный прогрессивный jpeg появляется на странице раньше, чем 5-килобайтный последовательный jpeg (то же самое изображение, уменьшенное в размере) в Firefox под Windows, что должно произвести впечатление. Конечно, на первом проходе прогрессивный jpeg имеет низкое разрешение, но он содержит столько же информации, сколько и маленькое изображение, или даже больше. А если масштаб страницы уменьшен, например, на мобильном устройстве, то низкое разрешение даже не заметно. Адаптивные изображения работают на нас прямо сейчас (прим. перев.: отсылка к responsive web design)!

По существу, прогрессивный jpeg лучше. Так какой же самый распространенный тип jpeg в сети? Угадали: последовательный, и с очень большим отрывом. В выборке из тысячи изображений, 92.6% — последовательные.

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

Проверка реальностью №1

Прогрессивные jpeg отрисовываются во всех браузерах, об этом не стоит переживать. Нас волнует то, как они отрисовываются.

Поведение прогрессивных jpeg в браузерах

Браузер (конкретная версия) Отрисовка прогрессивных jpeg переднего плана (foreground) Отрисовка прогрессивных jpeg заднего плана (background)
Chrome (v 25.0.1323.1 dev Mac, 23.0.1271.97 m Win) прогрессивно (очень быстро!) прогрессивно (очень быстро!)
Firefox (v 15.0.1 Mac, 12.0 Win) прогрессивно (очень быстро!) мгновенно после загрузки файла (медленно)
Internet Explorer 8 мгновенно после загрузки файла (медленно) мгновенно после загрузки файла (медленно)
Internet Explorer 9 прогрессивно (очень быстро!) мгновенно после загрузки файла (медленно)
Safari (v 6.0 Desktop, v 6.0 Mobile) мгновенно после загрузки файла (медленно) мгновенно после загрузки файла (медленно)
Opera (v 11.60) мгновенно после загрузки файла (медленно) мгновенно после загрузки файла (медленно)

Это разочаровывающие результаты, но в целом, доля рынка браузеров с прогрессивной отрисовкой прогрессивных jpeg идет вверх. Поддержка пока что составляет около 65% (Chrome + Firefox + IE9).

К сожалению, браузеры, которые не рендерят прогрессивные jpeg прогрессивно, отрисовывают их сразу целиком после того, как загрузка изображения завершена, что, по сути, делает их менее прогрессивными. Они становятся медленнее, чем последовательные jpeg. Несмотря на то, что последовательная отрисовка не такая быстрая и плавная, как прогрессивная, она по крайней мере дает хоть что-то, пока мы ждем, и «тик, тик» это своего рода индикатор загрузки (хорошая вещь). Нельзя недооценивать уверенность, которую чувствуют пользователи видя, что что-то происходит.

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

Проверка реальностью №2

Вы можете спросить «А не будут ли прогрессивные jpeg весить больше, чем обычные? Не платим ли мы за “слои”?». Это так для других типов многослойных изображение, но не для jpeg. Прогрессивный jpeg обычно на несколько килобайт меньше, чем его же последовательная версия. Строя график конвертации 10000 случайных последовательных jpeg в прогрессивные, Стоян Стефанов открыл ценное практическое правило: файлы больше 10Кб, чаще всего, будут весить меньше в прогрессивном варианте.

Убеждать стало бы проще, если бы можно было сказать, что прогрессивные jpeg всегда весят меньше, так что их и нужно всегда использовать. Стоян нам в этом помогает. Он говорит: «Другое наблюдение по поводу правила 10Кб заключается в том, что в тех случаях, когда вес последовательного jpeg меньше, он меньше с небольшой разницей. А когда меньше прогрессивный, то он обычно меньше намного. Так что говорить, что нужно всегда использовать прогрессивный и станет лучше — это нормально».

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

Причиной того, что последовательные jpeg наиболее распространены в сети, является, без сомнения, то, что инструменты оптимизации изображений создают их по умолчанию. Однако, все просмотренные мною — Photoshop, Fireworks, ImageMagick, jpegtran — имеют возможность сохранения и в прогрессивном варианте. Таким образом, чтобы отдавать прогрессивные jpeg, нужно сознательно модифицировать свой процесс оптимизации изображений.

Например, Smushit может переводить последовательные jpeg в прогрессивные. Smushit, кстати, можно запускать из командной строки и интегрировать в процесс оптимизации изображений.

Как узнать, что ваши jpeg прогрессивные? Вот несколько способов идентификации типа jpeg:

  1. ImageMagick — из командной строки запустите: identify -verbose mystery.jpg | grep Interlace На выходе будет или “Interlace: JPEG”, или “Interlace: None.”
  2. Photoshop — Откройте файл. Выберите File -> Save for Web & Devices. Если это прогрессивный jpeg, то флажок Progressive будет отмечен.
  3. Любой браузер — Последовательные jpeg будут загружаться сверху вниз, а прогрессивные будут вести себя по-другому. Если файл загружается слишком быстро, может понадобиться ограничение пропускной способности канала. Я использую ipfw под Mac’ом.
Проверка реальностью №3

Согласно этому FAQ по сжатию jpeg, каждый прогрессивный проход отрисовки нагружает ЦПУ примерно на столько же, на сколько отрисовка целого последовательного jpeg. Это неважно для настольных ПК, но возможно имеет значение для мобильных устройств.

Лишние вычисления — недостаток, но не камень преткновения. Предоставление фотографий на слабом аппаратном обеспечении — сложная задача вне зависимости от этого. Я в курсе дела, потому что пишу приложение-фотогалерею с бесконечным скроллингом и оно падает на iPad’e. При обработке большого количества изображений на мобильных платформах сложные задачи возникнут в любом случае.

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

Глядя в будущее

Месяц назад, Google запрыгнул на борт со своим сервисом Mod_Pagespeed, сделав convert_jpeg_to_progressive основным фильтром. SPDY тоже не отстает, переводя jpeg более 10Кб в прогрессивные по умолчанию, согласно практическому правилу Стояна. Браузеры, поддерживающие инкрементальное отображение, от этого станут казаться намного быстрее. Как видно из таблицы выше, включающей Google Chrome, такие действия Google имеют смысл. Я не стану говорить, что если уж «не-причиняй-зла-делай-веб-быстрее» Гугл выбрал progressive jpeg как best practice, то и мы должны тем более. Но это лишнее подтверждение. И самое главное, это показывает, что прогрессивный jpeg — формат, который был в своего рода морозилке на протяжении десятилетия — начинает свое возвращение.

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

Автор: Falco

Источник

www.pvsm.ru

Прогрессивная загрузка изображений и как её воспринимают пользователи. Прогрессивный jpeg против базовой линии jpegs

Стандарт JPEG определяет различные режимы сжатия. Только три из них широко используются:

  • Baseline Sequential
  • Расширенная Последовательная
  • Progressive

Единственное различие в первой находится в ряде таблиц допускается. В противном случае они кодируются и декодируются точно так же.

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

  • Последовательный поток JPEG в градациях серого будет иметь одно сканирование.
  • Цветовой последовательный поток JPEG может иметь одно или три сканирования.

JPEG принимает 8x8 блоков данных пикселей и применяет дискретное косинусное преобразование к этим данным. 64-пиксельные данные становятся 64 DCT-коэффициентами. Первый коэффициент DCT называется коэффициентом «DC», а другой 63 называется «AC».

Это путаная терминология, основанная на аналогии с постоянным током и переменным током. Коэффициент DC аналогичен среднему значению пикселя блока.

В последовательном JPEG, 64 коэффициента в блоке кодируются вместе (с коэффициентами DC и AC, закодированными по-разному). В Progressive JPEG DC и AC коэффициенты сканируют кодированные битовые поля (настраиваемого размера) в пределах коэффициента. Теоретически у вас может быть отдельное сканирование для каждого бита каждого компонента.

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

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

Вопрос о скорости в прогрессивном декодировании зависит от того, как это делается. Если вы полностью декодируете все изображение, прогрессивный, возможно, будет медленнее, чем последовательный. Если ваш декодер показывает затухание изображения, поскольку он обрабатывает поток, он будет намного медленнее, чем последовательный. Каждый раз, когда вы обновляете дисплей, вам необходимо выполнить обратное преобразование DCT, upsampling и color.

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

Там нет никакой разницы в качестве между прогрессивной и последовательной

Нарезной батон. Подходит к борщу на ужин

В Школе редакторов есть преподаватель - Николай Товеровский. Жена часто просит его купить хлеб к ужину . На этом примере он объясняет разницу между “делать” и “сделать”.

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

Метод прогрессивного джипега - это способ делать и сделать одновременно. Его автор, Артемий Лебедев, описал суть метода одной картинкой:

Картинка из параграфа 167 Ководства студии Артемия Лебедева

По Лебедеву , надо стремиться к тому, чтобы в любой момент времени задание было готово на 100%. Вопрос лишь в степени детализации. Если есть время и возможность - добивайся совершенства сколько тебе влезет. Не хватает ресурсов на доработку - не беда, задание уже выполнено, то есть сделано.

Метод зацепил, но я никак не могла найти ему применение. Борщ готовится постепенно, прогружаясь как обычный джипег, и есть его можно только при 100% готовности. Ворота во дворе не хотят открываться до тех пор, пока я не откидаю от них 100% снега. Собаку нужно помыть двумя шампунями, вытереть полотенцем, расчесать и на 100% высушить феном, - только тогда она становится чистой.

Я страдала, но не прекращала попытки. На моё счастье, началась учёба в Школе редакторов. Первое же практическое задание дало возможность попрактиковаться в методе прогрессивного джипега.

Задание из курса “Управление и результаты”. Надо нарисовать двух осьминожек. Ножки осьминожек - мои навыки. У одной осьминожки ножек немного и они коротенькие - это я сегодня. У второй ножек больше и они длиннее - это я через год.

Для вдохновения нам дали две картинки:

www.tarifan.ru

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *