Аптымізацыя графікі для web

  1. Як вызначыць якое малюнак паказаць
  2. Складанасць і колькасць кода
  3. аўтаматызацыя працэсу
  4. ад перакладчыка

Гэта пераклад артыкула Image Optimization аўтара Estelle Weyl .

Напэўна, кожны вэб-распрацоўшчык ведае, што калі гаворка заходзіць пра прадукцыйнасці і выгодзе ипользования (UX) кожнае малюнак на старонцы мае вялікае значэнне: першыя плён у аптымізацыі web-старонак можа прынесці менавіта праца з малюнкамі. Выкарыстанне методык сціску малюнкаў без страт якасці дазваляе знізіць сумарны памер старонкі не нанесці шкоду карыстацкаму досведу (UX) работы з такімі старонкамі, тым самым, паляпшаючы прадукцыйнасць і павялічваючы канверсію. Існуе шмат метадаў для вызначэння таго, якія малюнкі падтрымліваюцца, і вам застаецца толькі падрыхтаваць "правільныя" малюнкі і аддаць іх карыстальніку. Стварэнне аптымальных малюнкаў для ўсіх карыстальнікаў на ўсіх тыпах прылад павінна стаць мэтай ўсіх распрацоўнікаў (даступнасць павінна стаць яшчэ адной мэтай, але зараз не пра гэта).

Як вызначыць якое малюнак паказаць

Існуе некалькі методык для адлюстравання патрэбнага выявы, напрыклад, медыя запыты пры выкарыстанні фонавых малюнкаў, або выкарыстанне элементаў <picture> і <source> сумесна з srcset.
Выкарыстоўваючы CSS @media queries можна адлюстроўваць розныя фонавыя малюнкі ў залежнасці ад памеру акна прагляду або шчыльнасці пікселяў на прыладзе карыстальніка.

Напрыклад, вы можаце паказаць малюнак lowres.jpg для старых наўтбукаў і hires.jpeg для iPad Pro:

1
2
3
4
5
6
7
8
9
header {
background-image: url (img / hires_header.jpg);
}

@media only screen and (min-device-pixel-ratio: 2) and (min-width: 1024px) {
header {
background-image: url (img / hires_header.jpg);
}
}

А як быць з звычайнымі малюнкамі пярэдняга плана?

методыка адаптыўных изоражений яшчэ з 2013 года была заснавана на тым, што SVG мае сваю свобственную шырыню і вышыню кантэйнера, і медиавыражения ў іх адштурхваюцца ад гэтых памераў, а не ад памераў акна браўзэра (viewport).
На шчасце, бягучая падтрымка браўзэрамі тэга <picture> і srcset дазваляюць не выкарыстоўваць ужо гэты хак.

Основоной праблемай у малюнках пярэдняга плана з'яўляецца тое, што браўзэр мае інфармацыю аб памеры экрана (viewport) і шчыльнасці пікселяў на экране, але паняцця не мае аб памеры загружанага малюнка і таго, як яно суадносіцца з памерам экрана. Але, распрацоўшчык ведае і можа паказваць іх.

Падобна медиазапросам пры дапамозе тэгаў <picture, <source> і атрыбуту srcset распрацоўшчык можа дыктаваць браўзэру якія малюнкі адлюстроўваць для таго ці іншага памеру экрана або шчыльнасці пікселяў.

1
2
3
4
5
6
<Picture>
<Source srcset = "small_lowres.jpg, small_highres.jpg 2x" media = "(max-width: 768px)">
<Source srcset = "default.jpg, default_highres.jpg 2x">
<Source srcset = "large_lowres.jpg, large_highres.jpg 2x" media = "(min-width: 1024px)">
<Img src = "default.jpg" alt = "image descriptor">
</ Picture>

Заўвага! Заўсёды выкарыстоўвайце па змаўчанні тэг <img> ўнутры кожнага <picture>, а таксама атрыбут alt для тэга.

Вы можаце выкарыстоўваць проста тэг <img> без выкарыстання <picture> і ў тэгу img ўказаць атрыбуты srcset з наборам изоражений і sizes для апісання вобласці іх прымянення.

1
2
3
4
5
6
7
8
<Img src = "default.jpg"
srcset = "large.jpg 1024w,
medium.jpg 768w,
default.jpg 420w "
sizes = "(min-width: 1024px) 1024px,
(Min-width: 768px) 90vw,
100vw "
alt = "image descriptor" />

Мы таксама можам адлюстроўваць розныя тыпы малюнкаў выкарыстоўваючы атрыбут type:

1
2
3
4
5
6
<Picture>
<Source srcset = "photo.jxr" type = "image / vnd.ms-photo">
<Source srcset = "photo.jp2" type = "image / jp2">
<Source srcset = "photo.webp" type = "image / webp">
<Img srcset = "photo.jpg" alt = "My beautiful face">
</ Picture>

Калі вас здзіўляе код вышэй, JPEG-XR стары MIME image / vnd.ms-photo для Windows Media Photo, прапрыетарны фармат малюнкаў ад Microsoft, які падтрымліваецца IE8 і вышэй, уключаючы Microsoft Edge. jp2 - гэта пашырэнне для фармату JPEG 2000, які падтрымліваецца браўзэрам Safari. WebP - гэта фармат изоюражений з выкарыстаннем кампрэсіі без страт якасці і падтрымліваецца на дадзены момант браўзэрамі Chrome і Opera. А Firefox будзе падтрымліваць фарматы графікі, як PNG-A, SVG, GIF і JPEG (як у кодзе вышэй).

Chrome - WebP
IE 9+ / Edge - JPEG-XR
Opera - WebP
Safari - JPEG-2000

Для Firefox і IE8 трэба прадугледзець запасны варыянт у выглядзе малюнкаў JPEG ці PNG. І хоць Safari і Firefox эксперыментуюць з падтрымкай WebP малюнкаў, пакуль няма ўпэўненасці ў тым, што такая падтрымка неўзабаве з'явіцца. У любым выпадку, можна праверыць падтрымку на сайце Can I Use .

Для больш дэталёвага вывучэння магчымасцяў ёсць добрыя онлайн падручнікі для медиавыражений , тэга <picture> і srcset .

Складанасць і колькасць кода

Асноўны пролемой ў такім рашэнні (глядзі код вышэй), гэта вялікая колькасць кода, які необъодимо напісаць для таго, каб пакрыць як мага больш варыянтаў памераў экранаў і шчыльнасцяў пікселяў. Расставіць кантрольныя кропкі для кожнага дазволу безумоўна можна, але гэта складана, і вы врядлі хацелі б гэтым займацца ўручную. На шчасце, для напісання такіх умоў можна і трэба аўтаматызаваць.

Аптымальным рашэннем у тым выпадку будзе генерацыя кода на боку сервера пад тры з чатырох асноўных крытэрыяў, такіх як: памер акна (viewport), шчыльнасць пікселяў, падтрымка кліентам фармату выявы і стаўленне памеру малюнка да памеру экрана. Чаму тры з чатырох? Вы заўсёды можаце выкарыстоўваць усе перавагі разумення браўзэрам sourcesets, але вы не выкарыстоўваеце ўсе камбінацыі, а толькі некаторыя з іх.

Калі ваш DOM фарміруецца ў браўзэры толькі на кліенцкім боку пры дапамозе JavaScript, напрыклад, як у React прыкладанняў, маючы інфармацыю аб кліенцкім прыладзе вы можаце запытаць правільнае малюнак, але карыстальнікі будуць нейкі час бачыць часткова загружаны экран (у той час, пакуль апрацоўваецца код на кліенце).

У тым выпадку, калі вы не генерируете ўвесь HTML на баку кліента, падмена шляху да выявы таксама не будзе аптымальным рашэннем, так як падчас парсінга дакумента браўзэр пачне спампоўваць арыгінальнае малюнак, а затым, калі адпрацуе JavaScript, браўзэр прыступіць да запампоўкі іншага, больш аптымальнага для яго, малюнка.

І калі вы з'яўляецеся прыхільнікам прагрэсіўнага улушения, вы павінны разумець, што зыходны малюнак будзе загружана ў любым выпадку пасля таго як HTML дакумента будзе прааналізаваны.

На жаль, падказкі, якія адпраўляюцца на сервер з інфармацыяй пра шчыльнасць пікселяў экрана або падтрымкай WebP, у выглядзе загалоўкаў HTTP запытаў былі рэалізаваны толькі ў Blink (Chrome і Opera). Калі вы маеце інфармацыю аб дазволе і памеры экрана карыстальніка вы можаце аўтаматычна аддаваць правільныя малюнка выкарыстоўваючы прагрэсіўнае паляпшэнне на боку сервера. Пры дапамозе такіх загалоўкаў мы можам вызначыць падтрымку фармату выявы WebP (Chrome і Opera падтрымліваюць такія тыпы загалоўкаў), дазвол і памер акна прылады кліента. У Instart Logic у нас ёсць скрыпт пад назвай Nanovisor, які паўтарае функцыянальнасць HTTP загалоўкаў для браўзэраў, якія не падтрымліваюць гэтую тэхналогію, што дазваляе нам адпраўляць кліенту аптымізаваныя выявы.

Вы можаце таксама аналізаваць радок загловка UserAgent разам з некаторай дадатковай інфармацыяй для таго, каб вызначыць тып падтрымоўваных графічных файлаў у канкрэтнага карыстальніка. Даведаўшыся гэта, вы можаце падмяніць пашырэнне файла або можаце аддаць малюнак патрэбнага фармату але з "няправільным" пашырэннем. Напрыклад, калі карыстальнік запытаў файл foo.jpg мы можам отдеть яму патрэбны тып файла, пад ўсё тым жа імем foo.jpg. У Instart Logic мы аддаём карыстальнікам WebP для Chrome і Opera, і JPEG-XR для Edge без змены імя файла, мы проста заўсёды выкарыстоўваем .jpg ў канцы імя файла. Мы карыстаемся тым фактам, што ўсе браўзэры карэктна адлюстроўваюць выявы кіруючыся MIME не звяртаючы ўвагі на пашырэнне файлаў. Такім чынам, мы можаце ствараць адну і тую ж разметку html для розных браўзэраў, а з боку сервера аддаваць кажому браўзэру патрэбнае малюнак.

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

аўтаматызацыя працэсу

З з'яўленнем такой магчымасці ў браўзэраў мы можам аддаваць карыстачу індывідуальна настроеныя малюнка. І ў вышэй мы даведаліся пра тое, як паведаміць браўзэру пра тое, якое малюнак і якога памеру выкарыстоўваць. Тым не менш, нам па-ранейшаму неабходна генераваць малюнка рознага памеру і тыпу, падбіраючы, пры гэтым, найлепшую ступень сціску. Пытанне цяпер складалася ў тым, якім чынам стварыць усе гэтыя выявы.

Працэс аптымізацыі малюнкаў, змены іх памераў і канвертавання ў розныя фарматы падтрымліваюцца тым ці іншым браўзэрам, павінен быць аўтаматызаваны. І пажадана пры канвертацыі малюнкаў дасягаць найвышэйшай ступені сціску для кожнага апрацоўванага малюнка.

Працэс аптымізацыі малюнкаў можа займаць шмат часу, асабліва для сайтаў з дынамічным змесцівам, дзе колькасць можа вылічацца тысячамі, сотнямі тысяч ці нават мільёнамі малюнкаў з рознымі памерамі і тыпамі. І ў гэтым выпадку можа дапамагчы праграмнае забеспячэнне, напрыклад, ImageMagick. ImageMagick дазваляе канвертаваць выявы ў розныя фарматы, такія як: PNG, JPEG, JPEG-2000, GIF і нават WebP. Поддеривается яшчэ мноства фарматаў і канвертаваць выявы можна выкарыстоўваючы камандную радок:

1
convert myImg.jpg -quality 78 -define webp: lossless = true myImg.webp

Прыведзеная вышэй каманда захавае копію малюнка myImg.jpg ў фармаце WebP, пры гэтым канвертаванне будзе ажыццёўлена без бачных страт да якасці 78%.
Гэтак жа, пры дапамозе ImageMagic вы можаце змяніць памер малюнка выкарыстоўваючы сцяг -resize

1
convert myImg.jpg -quality 78 -resize 50% myImg.webp

Прыведзеная вышэй каманда створыць новы файл у фармаце WebP памерам 50% ад арыгінальнага малюнка (myImg.jpg) і якасцю 78%.

Пры дапамозе каманднага радка можна аўтаматычна ствараць выявы ў патрэбных вам памерах і якасці. Цяжкасці можа выклікаць толькі вызначэнне аптымальнага якасці малюнка і ступені сціску. І гэты крок, магчыма, прійдется выконваць уручную.

Задача пошуку аптымальнага якасці для кожнага малюнка будзе займаць вельмі шмат часу або патрабаваць выкарыстання вялікай колькасці людзей. Таму, большасць інструментаў для пераўтварэння малюнкаў памяншаюць памер файла за кошт пагаршэння якасці малюнка, выкарыстоўваючы агульны каэфіцыент сціску. Напрыклад, калі я аптымізаваў малюнка для свайго сайта з некалькімі малюнкамі, я індывідуальна падабраў степерь сціску для іх у межах ад 35% да 88%. Для галерэй і іншых праектаў з мноствамі малюнкаў я выкарыстаў Adobe Fireworks для аўтаматызацыі працэсу канвертацыі і захоўваў ўсе выявы з якасцю 78%. Большасць праграм для аўтаматызацыі аптымізацыі захоўваюць выявы з якасцю каля 80%. Грунтуючыся на сваім вопыце я выбіраю звычайна якасць 78%. Тым не менш, няма нейкага магичесого універсальнага колькасці для выбару качетсва малюнка.

Узровень сціску моцна залежыць ад таго, што намалявана на малюнку і, у цэлым, залежыць ад узроўню дэталізацыі. І ў залежнасці ад утрымання трэба выстаўляць степерь сціску. Чым больш дэталізавана малюнак, тым ніжэй павінна быць степерь сціску (у раёне 90%), у той час як малюнкі з меншай колькасцю дэталізаваных участкаў будуць выдатна выглядаць нават пры якасці ніжэй за 50%.

Не выключаецца і аўтаматызаваная налада якасці малюнка. Так, платформа Instart Logic's выкарыстоўвае камп'ютэрнае зрок і машыннае навучанне для кантэнтнай-залежнай аптымізацыі малюнкаў. Выявы аптымізуюцца з улікам памераў і магчымасцяў браўзэра, якасці інтэрнэт злучэння і аптымальных каэфіцыентаў сціску выявы без бачных страт якасці. Працэс аўтаматызаванай аптымізацыі якасці малюнка, то што мы называем "SmartVision", будуецца на аснове алгарытмічнага падыходу і машыннага навучання для атрымання адаптыўных налад для кожнага малюнка паасобку з найлепшымі спалучэннямі якасці малюнка і яго вагі. Ўдасканаленыя алгарытмы камп'ютэрнага гледжання дазваляюць павялічыць адсотак сціску выявы без бачных страт якасці. Parvez Ahammad у сваім артыкуле яшчэ ў 2014 годзе апісаў гэтыя алгарытмы .

За апошнія 6 гадоў браўзэры сталі працаваць хутчэй, але разам з тым, вырасла сярэдні час загрузкі сайта. І віной таму, у тым ліку, памер малюнкаў. Сучасныя сродкі дазваляюць часткова вырашыць гэтую праблему. Таму, добрым тонам будзе, калі вы станеце вылучаць час на аптымізацыю малюнкаў.

ад перакладчыка

У 2015 годзе я апублікаваў артыкул webp - ужо пара? , У якой апісаў магчымасці адносна новага на той момант фармату выявы WebP. Праз больш чым паўтара года падтрымкай фармату WebP ўсё яшчэ могуць пахваліцца толькі Chrome і Opera. Але, выкарыстанне гэтага фармату на некалькіх буйных праектах у AlterEGO зарэкамендавала сябе вельмі станоўча. Мы знізілі спажыванне трафіку, загрузку канала і хуткасць загрузкі старонак сайта. Пры гэтым, малюнка не страцілі ў якасці. А гэта вельмі важна, напрыклад, для інтэрнэт крам, дзе ад якасці малюнка наўпрост могуць залежаць продажу.

Асноўнай праблемай, з якой нам давялося сутыкнуцца пры выкарыстанні аптымізаваных малюнкаў стала праблема прадукцыйнасці. Вялікі аб'ём графічных файлаў (фота для тавараў) і пастаянныя абнаўлення фото не дазвалялі выконваць прегенерацию. Больш за тое, выкарыстанне аптымальнага памеру малюнка (у залежнасці ад шчыльнасці пікселяў экрана і памераў viewport) зрабіла абавязковым ўмова генерацыі малюнка "па запыце". Г.зн. на лета. Прапанаванае ў маім артыкуле рашэнне з выкарыстоўвання php і бібліятэкі Imagick для змены памераў і фармату малюнкаў аказалася бескарысным. Час генерацыі малюнка было занадта вялікім і яно яшчэ больш павялічвалася з павелічэннем колькасці запытаў. Праблему атрымалася вырашыць пры дапамозе модуля PageSpeed для NGINX і арганізацыі кэшавання і захавання згенераваных малюнкаў на дыск. Нам удалося дамагчыся максімальнага часу генерацыі малюнкаў у раёне 500мс пры сярэднім часу паўторнай аддачы малюнка за 25-30мс. Але, гэта тэма для асобнага артыкула.

Чаму тры з чатырох?