[Перевод] Прогрессивная загрузка изображений с использованием параллельных потоков

Оригинальный адрес:Parallel streaming of progressive images

Оригинальный автор:Andrew Galloni, Корнел Лесинский.

Перевод с:Программа перевода самородков

Постоянная ссылка на эту статью:GitHub.com/rare earth/gold-no…

Переводчик:twang1727

Корректор:suhanyujie

Технология прогрессивного рендеринга изображений и мультиплексирования HTTP / 2 существует уже некоторое время, но теперь мы объединим их по-новому, чтобы получить большую мощность. Cloudflare использует прогрессивный поток,Загрузка изображения может быть сокращена вдвое, а браузер может начать рендеринг страницы быстрее..

видео:crates.life/eat-test/com…

Сервер, устанавливающий соединение HTTP/1.1, не имеет права решать, в каком порядке отправляются ресурсы клиенту, ответ, как неделимое целое, отправляется именно в том порядке, который запрашивает браузер. Улучшение HTTP/2 в этой области заключается в добавлении мультиплексирования и приоритизации, что позволяет серверу решать, какие данные отправлять и когда их отправлять. Мы используем эти новые функции HTTP/2, чтобы улучшить воспринимаемую скорость загрузки прогрессивных изображений, отдавая приоритет наиболее важным фрагментам данных изображения.

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

Что такое прогрессивный рендеринг изображений?

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

Эта функция полезна для формата JPEG, так как для предварительного просмотра изображения требуется всего 10–15 % данных, а при загрузке 50 % данных изображение выглядит почти таким же четким, как при получении всего файла. Изображения в формате Progressive JPEG имеют те же данные, что и обычные изображения, но сортируются более простым способом, поэтому прогрессивный рендеринг не увеличивает размер файла. Это возможно, потому что JPEG не хранит изображения в пикселях. Он использует частотные коэффициенты для представления изображений, таких как ряд предопределенных шаблонов, которые можно смешивать в любом порядке для восстановления исходного изображения. Внутренности JPEG довольно интересны, вы можете получить это от моеговыступление на конференции performance.now()выучить больше.

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

Прогрессивная потоковая передача HTTP/2

Но есть проблема. Веб-сайты будут иметь более одного изображения (иногда сотни изображений). Прогрессивный рендеринг не очень помогает, когда сервер передает изображения одно за другим в необработанном виде, потому что в целом изображения по-прежнему загружаются последовательно:

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

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

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

Концепция постепенной загрузки изображений в параллельных потоках так же стара, как сам HTTP/2, но она требует специальной обработки со стороны базовых компонентов веб-сервера, поэтому до сих пор этот метод не использовался в больших масштабах.

как мы улучшаемHTTP/2 приоритет, мы поняли, что его также можно использовать для улучшения этой функции. Файлы изображений в целом не имеют ни высокого, ни низкого приоритета. Каждый файл имеет разный приоритет, и динамическая настройка приоритета дает нам желаемое поведение:

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

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

Остальные данные изображения имеют низкий приоритет. Браузеры могут принять это для улучшения качества изображения, когда это не имеет значения, потому что страница полностью пригодна для использования.
Чтобы понять точный объем данных, которые должны быть переданы на каждом этапе, вам нужно понять структуру файла изображения, но позволяет сетевому серверу анализировать ответ изображения, а жестко запрограммированный формат, основанный на поведении, будет выглядеть очень странно на уровень протокола. И этот вопрос в качестве приоритета для решения динамических изменений, мы можем элегантно отделить от базовой информации о кодировании сети и формате изображения. Мы можем использовать Worker или инструменты обработки изображений для анализа изображений в очереди и соответствующего изменения приоритета HTTP/2 сервера управления.

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

водопадная диаграмма

Следующее изWebPageTestРезультирующая каскадная диаграмма, показывающая сравнение простых ответов HTTP/2 и прогрессивной потоковой передачи. Файлы в обоих случаях одинаковые, количество передаваемых данных одинаковое, общее время загрузки страницы одинаковое (в пределах погрешности измерения). На рисунке синие фрагменты указывают на то, что данные передаются, а зеленые — на ожидание запросов.

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

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

Метрики по сравнению с другими методами

Существуют и другие методы, используемые для более быстрого предварительного просмотра изображений, такие как размещение изображений низкого качества (LQIP), но они имеют некоторые недостатки. Они добавляют ненужные данные в заполнители и часто мешают предварительному сканированию браузера и задерживают загрузку полного изображения, поскольку замена предварительного просмотра на полное изображение зависит от JavaScript.

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

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

Получите максимум от прогрессивного рендеринга

Избегайте эффектов повреждения JavaScript. Скрыть картинку доonloadСценарии, которые не отображаются до тех пор, пока не произойдет событие (используя затухание и т. д.), сделают недействительным прогрессивный рендеринг. Прогрессивный рендеринг использует традиционные<img>Элемент работает лучше всего.

Подходит ли только JPEG?

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

Отправка заголовков изображений в первую очередь (включая размер изображения) работает для всех форматов.

Преимущества прогрессивного рендеринга JPEG (поддержка всех браузеров) и JPEG 2000 (поддержка Safari) уникальны. GIF и PNG имеют шахматный рисунок, но эти узоры сопровождаются сжатием и плохими учениками. WebP не поддерживает прогрессивный рендеринг. Это создает дилемму: WebP обычно меньше, чем JPEG того же качества на 20-30%, но прогрессивный JPEGвыглядитЗагружается на 50% быстрее. Некоторые форматы изображений следующего поколения поддерживают прогрессивный рендеринг лучше, чем JPEG, и лучшее сжатие, чем WebP, но браузеры пока не поддерживают эти форматы. Тем временем вы можете выбирать между экономичным WebP и более удобным для восприятия прогрессивным JPEG, изменив настройки полировки на панели Cloudflare.

Пользовательские заголовки для экспериментов

Мы также поддерживаем настраиваемые заголовки HTTP для экспериментов, чтобы оптимизировать потоковую передачу других ресурсов на сайте. Например, вы можете сделать так, чтобы наши серверы сначала отправляли первый кадр анимированного GIF, а остальные задерживали. Или вы можете сделать это в HTML-документе<body>Загрузите сначала перед загрузкой<head>ресурсы, указанные в тегах.

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

cf-priority-change: <offset in bytes>:<priority>/<concurrency>, ...

Например, для этого мы используем прогрессивный JPEG (рабочий фрагмент JavaScript In):

let headers = new Headers(response.headers);
headers.set("cf-priority", "30/0");
headers.set("cf-priority-change", "512:20/1, 15000:10/n");
return new Response(response.body, {headers});

Он скажет серверу использовать 30 в качестве приоритета при отправке первых 512 байтов в начале. Затем переключитесь на приоритет 20 и некоторую степень параллелизма (/1) и, наконец, когда 15000 байт файла будут отправлены, переключитесь на низкоприоритетный высокий параллелизм (/n), чтобы отправить остальную часть файла.

Мы пытаемся разбить фрейм HTTP/2, чтобы он соответствовал указанному смещению в заголовке, тем самым максимально быстро изменив приоритет отправки. Однако приоритизация не гарантирует, что данные в разных потоках будут мультиплексированы именно так, как указано, поскольку сервер применяет приоритизацию только тогда, когда несколько потоков должны отправлять данные одновременно. Если некоторые запросы поступают раньше из вышестоящего браузера или кэша, сервер может отправить их немедленно, не дожидаясь других запросов.

Попробуйте!

Вы можете использовать наш польский инструмент для преобразования ваших изображений в прогрессивный JPEG. ПрисоединяйсяbetaЭлегантно использовать параллельные потоки.

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

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.