Нотатки від команди про майстерність, формати та невеликі рішення, що стоять за добрим результатом.
Як одне зображення конвертується в браузері і що змінюється для кількох
Коли ви перетягуєте JPEG на сторінку, браузер читає файл у пам'ять, декодує стиснуті дані назад у сирі пікселі своїм вбудованим зчитувачем JPEG, малює ці пікселі на поверхні поза екраном і просить платформу записати їх назад як WebP. Кожен крок відбувається в браузері, на вашому обладнанні, тож жоден байт не перетинає мережу. У наших прогонах JPEG 17 КБ у 1024 на 768 завершується приблизно за 54 мілісекунди, а фото 116 КБ у 3840 на 2160 займає близько 550 мілісекунд. Коли ви конвертуєте кілька зображень одразу, робота переходить на наш сервер, який кодує їх разом і повертає одне завантаження, чиє посилання зникає приблизно за 2 години.
Що стається з EXIF і метаданими
Файли JPEG здатні тягати з собою справжні вантажі метаданих. EXIF записує модель камери, координати GPS, витримку й орієнтацію. Поля IPTC тримають авторські права й підпис. Пакети XMP ведуть історію правок, а профілі ICC покривають роботу з керуванням кольором. Тутешня конвертація не лишає з цього нічого. Підсумковий WebP, це чистий файл, що тримає лише видимі пікселі. Так поводяться будь-які інструменти зображень, що малюють через браузер, однаково в Chromium, Firefox і WebKit. Для більшості веб-публікацій скидання метаданих це плюс, воно зрізає кілька байтів і не дає GPS чи особистим даним витекти в публічне зображення. Якщо вам треба зберегти одне конкретне поле, зазвичай це орієнтація, поверніть фото заздалегідь або проженіть його через редактор, що розуміє метадані, до конвертації. Не покладайтеся на цей інструмент для архівної роботи, де початкові метадані зобов'язані вціліти цілими.
WebP проти JPEG: чим відрізняється стиснення
JPEG ріже зображення на блоки 8 на 8 і жене Дискретне Косинусне Перетворення, обертаючи просторову деталь у частотні дані, а потім сильніше квантує високі частоти. WebP позичає схему передбачення з відео VP8: кожен блок угадується за вже розібраними сусідами, і зберігається лише різниця, що лишилася. Це зазвичай лишає менше блокових артефактів за того ж розміру файлу, особливо на плавних градієнтах і тонах шкіри, де сітка JPEG може зринути видимою мозаїкою. На фото високої якості, вище q80, око рідко ловить різницю, але виграш у розмірі тримається твердо. За нижчої якості, нижче q60, відрив WebP росте, і характер артефакту змінюється: WebP розмазується у м'якше замилення, а JPEG показує свої фірмові блоки. Жоден не перемагає на кожному зображенні. Сильно текстуровані сюжети на кшталт листя часом тиснуться майже однаково в обох форматах.
Core Web Vitals і довід на користь WebP
Largest Contentful Paint, або LCP, міряє, наскільки швидко найбільший видимий елемент домальовується у вікні. На більшості маркетингових сторінок таким елементом служить головне фото. Google підтвердив, що Core Web Vitals виступають фактором ранжування в Пошуку. Коли головним іде JPEG на 300 КБ, він здатен виштовхнути LCP за поріг у 2,5 секунди на середньому мобільному з'єднанні. Переведіть те саме фото у WebP близько 180 КБ, і LCP може повернутися всередину зеленої зони без жодної іншої правки сторінки. Економія у 25 до 34 відсотків копиться на кожному зображенні сторінки. Сторінка з шістьма JPEG, що складаються в 1,2 МБ, здатна скинути 300 до 400 КБ після переходу на WebP, що прямо пришвидшує перше значуще малювання на повільних каналах. CDN, що підтримують узгодження вмісту, самі віддають WebP сумісним браузерам, тож мороки за кожним зображенням не лишається, щойно оригінали є.
Підтримка браузерів WebP у 2026 році й прогалини
На 2026 рік WebP читається в Chrome з версії 17, у Firefox з 65, в Edge з 18, в Opera з 11.10 і в Safari з версії 14 на iOS 14 і macOS Big Sur. За даними caniuse.com сукупне охоплення декодування WebP переступає 97 відсотків трафіку браузерів. Залишений клаптик, це здебільшого Internet Explorer 11, Safari 13 на macOS Catalina й довгий хвіст дуже старих браузерів Android. Для більшості публічних проєктів віддавати WebP усім безпечно. Коли потрібне повне охоплення, елемент picture в HTML дає перелічити джерело WebP і запасний JPEG в одному тезі, і браузер бере перший формат, що він уміє читати. CDN з оптимізацією зображень узгоджують формат самі за заголовком Accept, що шле браузер, тож ручної перевірки за кожним браузером при віддачі через них не треба.
Коли WebP застосовувати не варто
WebP, це правильний вибір для веб-віддачі сучасним браузерам, але в кількох частих місцях він вибір хибний. Друк вимагає кольору CMYK, який WebP не несе, тож JPEG і TIFF лишаються стандартом для друкарні. Поштові клієнти нерівні: Gmail і Apple Mail малюють WebP, а Outlook на Windows ні. Обмін файлами й маркетплейси теж різняться. Google Drive, Dropbox і GitHub показують WebP нормально, тоді як багато соцмайданчиків, фотобанків і систем e-commerce тиснуть вхідні зображення в JPEG усередині, що робить крок із WebP марним. Підтримка редакторів усе ще клаптикова: Lightroom, Capture One і Affinity Photo вміють відкривати WebP, але безліч плагінів і пресетів експорту за звичкою тягнуться до JPEG. Для будь-якого потоку, що проганяє зображення крізь сторонні системи поза вашим контролем, тримайте майстер-JPEG і конвертуйте у WebP лише на фінальному шарі віддачі.
