Готуємо WebP правильно

WebPХабр вже насичений статтями на тему «нового» формату зображень WebP (опис, порівняння з JPEG2000, порівняння з BPG використання, підключення на сайті). На жаль, відкритими залишаються питання: як правильно підключити WebP на сайті, щоб «все працювало», і наскільки він краще (менше) PNG/JPEG. У цій замітці я буду відповідати на обидва питання.

Припускаю, що ви вже в курсі оптимізації зображень, вмієте конвертувати зображення в WebP, розумієте різницю між використанням JPEG і PNG на сайті, знаєте інструменти ExifTool, jpegtran, mozjpeg JPEGrescan, optipng, pngcrush, pngwolf, zopflipng і TruePNG а також розрізняєте пастеризацію молока і постеризацию зображень.

Якщо так — то переходимо до суті.

Плюси WebP
У всіх джерелах згадується істотне зменшення розміру зображень, PNG, JPEG, якщо їх перекодувати в WebP. При цьому перекодування повинно виконуватися із збереженням якості. У Irie.рф вже три роки використовується автоматична оптимізація зображень без втрат і з незначними втратами (2 режими). Це дозволяє досить точно порівняти, коли WebP виграє в порівнянні з вже оптимізованими PNG (проганяється через TruePNG, pngwolf і zopflipng) і JPEG (ExifTool, mozjpeg, переклад в png), а коли ні.

На тестовій вибірці з 13 тисяч зображень WebP показав виграш щодо вже оптимізованих PNG і JPEG файлів на 31% (580 Мб проти 837 Мб). WebP-файли приблизно на третину менше вже оптимізованих аналогів JPEG і PNG. Тут потрібно обмовитися, що переклад PNG WebP виконується без втрат (lossless), а переклад в JPEG виконується з мінімальними втратами (якість 100), це дозволяє в автоматичному режимі відвантажувати WebP для всіх браузерів, які його розуміють, без побоювань щось «поламати» у клієнтів.

У переважній більшості випадків виграш WebP щодо вже оптимізованих JPEG (mozjpeg) становив не більше 10%. Винятки були в тих випадках, коли з JPEG-файлів можна було безпечно вирізати EXIF-дані (зокрема, панелі), і переведення їх у WebP давав суттєвий виграш. Тому якщо ви створюєте JPEG відразу за «нормального» сценарієм, то в більшості випадків суттєвого виграшу не передбачається. PNG-файли навіть після оптимізації відносно непогано (30%) «втрачають у вазі», якщо перевести їх в WebP.

Що важливіше, щодо всіх оптимізованих зображень тільки у 10% випадків (так, вибірка з 13000 зображень — це було тільки 10% всіх оптимізованих зображень) WebP «без втрат» давав виграш в розмірі. Для решти 90% виграшу не було (з них 75% — це JPEG файли). Цифри ще можуть бути обумовлені жорстким підходом до оптимізації зображень без втрат: можливо, тонка настройка WebP з «невеликими» втратами якості дасть візуально «той же результат», але буде менше за розміром. На жаль, в автоматичному режимі оцінити всі 130 тисяч зображень, щоб зрозуміти, наскільки в кожному конкретному випадку стиснення з втратами може бути краще, не представляється можливим. Самі зображення не представляють якої-небудь закономірності: це фонові картинки і галереї сотень сайтів.

Для довідки, переклад PNG WebP
cwebp -quiet -pass 10 -alpha_method 1 -alpha_filter best -m 6 -mt -lossless
Переклад JPEG в WebP
cwebp -quiet -pass 10 -alpha_method 1 -alpha_filter best -m 6 -mt -q 100
Чудовою ілюстрацією є зображення до статті. Вихідний PNG займав 15,6 Кб. Після оптимізації та постеризації — 12,5 Кб. lossless webp з нього — 8 Кб.

Реальне використання WebP
Якщо ви вже навчилися правильно конвертувати або зберігати зображення в WebP (тема для окремої статті), то залишається проблема підключення WebP на сайті, що вже піднімалася тут (гра варта свічок, бо Chrome браузери вже становлять понад 2/3 ринку). На стороні браузера можливі варіанти з JavaScript (використання тега noscript, ymatuhin):

<script async src="simple-webp.min.js">
<noscript data-webp>
<img src="example.png" alt="">
</noscript>
І HTML5 (використання picture, pepelsbey):

<picture>
<source srcset="opera.webp" type="image/webp">
<img src="opera.jpg" alt="The Oslo Opera House">
</picture>
Другий варіант, в цілому, надійніше (хоча може покривати менше браузерів).

Також можливий «куленепробивний» серверний варіант, який читає заголовок
Accept
браузера і відвантажує відповідне зображення (всі WebP зображення потрібно зберегти з розширенням .webp до аналогів) браузеру, який їх підтримує (зміни в клієнтському коді не потрібно). Найпростіший варіант для nginx виглядає приблизно так:

map $http_accept $x_airee_webp {
~*webp '.webp';
default ";
}

try_files $uri$x_airee_webp @404
Більш точні варіанти (з правильною підтримкою Vary і Cache-Control) підтримує в актуальному стані Ilya Grigorik в проекті webp-detect (для всіх основних веб-серверів).

Думки до обговорення
Резюмуючи практичний досвід використання WebP: це має сенс робити, особливо для мобільних браузерів (для них можна відвантажувати зображення в «поганому» як і реально виграти під час завантаження сторінки). Але для початку потрібно налаштувати весь стек оптимізації зображень «звичайними» способами: це дасть суттєвий виграш для всіх користувачів. Після цього підтримка WebP у ваших проектах може бути реалізована буквально в два кліка» (конфігурація nginx + конвертація в процесі оптимізації).

Також, на мій погляд, використання WebP здатне творити чудеса» при точкової оптимізації деяких типів зображень (з якими погано справляються як JPEG, так і PNG) — наприклад, велику кількість дрібних деталей на тлі великих однорідних областей. І якщо підбирати параметри оптимізації в автоматичному режимі для таких типів зображень — це буде дуже здорово.

Міркування з приводу «подвоєння» розміру зображень на диску я рахуючи несуттєвими: якщо записувати WebP тільки в тих випадках, коли файл менше за розміром, і провести оптимізацію всіх зображень, то вони будуть займати ще менше місця. І переклад PNG зображень у WebP істотно (мінімум, на порядок) менш вибагливий, ніж оптимізація PNG (з перебором варіантів стиснення).

Буду радий побачити ваші міркування і прикладної досвід використання зображень у форматі WebP.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.