Wastong Sukat ng Larawan sa Web

Sukatin ang pinakamalawak na sukat ng display ng imahe, doblehin para sa high density screens, at baguhin ang sukat ng iyong library sa numerong iyon. Ang paglalagay ng 4000 pixel na litrato sa 800 pixel na slot ay nangangahulugang nagda-download ang browser ng humigit-kumulang 25 beses na mas maraming pixel data kaysa sa kaya nitong ipakita, at pagkatapos ay itinatapon lamang ang natitira.

Sa koneksyon ng telepono, binabayaran ito ng bisita gamit ang oras at data. Ang wastong pagsusukat ng mga imahe ay kadalasang ang nag-iisang pinakamalaking paraan para mabawasan ang bigat ng page sa isang site, at kailangan lamang nito ng isang batch sa halip na muling pagdidisenyo.

Bakit napakalaki ng nagiging gastos sa sobrang laking mga imahe

Ang laki ng file ay sumasabay sa dami ng pixel, kaya ang pagbawas sa kalahati ng lapad at taas ay nag-aalis ng humigit-kumulang 75 porsyento ng data. Ang ugnayan ay quadratic sa halip na linear, kaya mabilis lumaki ang nasasayang.

Ang unang hilera ay ang karaniwang sitwasyon sa mga site kung saan direktang nag-a-upload ang mga editor mula sa camera. Nagda-download ang browser ng 4.2 MB, pinaliliit ito, at nagpapakita ng katumbas lamang ng isang 180 KB na file.

Paano sukatin ang totoong sukat ng display

I-right click ang imahe sa iyong live na page, piliin ang Inspect, at tingnan ang ipinapakitang sukat sa halip na ang intrinsic na sukat. Inuulat ng mga browser ang parehong numero, at ang agwat sa pagitan ng mga ito ang siyang nasasayang.

Suriin ang pinakamalapad na sitwasyon sa halip na ang karaniwan. Ang isang imahe sa loob ng column ng artikulo ay maaaring lumabas nang 700 pixels sa desktop at 380 sa telepono, kaya 700 ang mahalagang numero. Subukan sa pinakamalawak na window ng browser na makatotohanang ginagamit ng iyong mga bisita, dahil lumalaki ang isang full width banner kasabay ng viewport at nangangailangan ng ibang kalkulasyon.

Ang patakaran sa pagdodoble para sa mga high density screen

I-multiply ang lapad ng display sa 2 at huminto roon, dahil ang mga screen na lampas sa density na iyon ay hindi nagpapakita ng karagdagang pagbuti na mapapansin ng sinuman. Ang isang imahe na ipinapakita sa 700 pixels ay dapat i-export sa 1400.

Paminsan-minsang iminumungkahi ang pag-triple ngunit bihira itong kailangan. Ang pagkakaiba sa pagitan ng 2 at 3 beses na density ay hindi mapapansin sa normal na distansya ng pagtingin, habang ang file ay lumalaki nang higit sa kalahati. Ang mas matinding pag-compress sa 2 beses na density ay nagbibigay ng mas magandang resulta kaysa sa bahagyang pag-compress sa 3 beses, dahil itinatago ng mga sobrang pixel ang compression.

Karaniwang lapad ng display na dapat i-resize

• Imahe sa katawan ng artikulo: lumalabas nang humigit-kumulang 700 px, i-export sa 1400 px.
• Full width hero: lumalabas nang hanggang 1920 px, i-export sa 1920 px at i-compress nang mas mabuti.
• Half width feature: lumalabas nang humigit-kumulang 600 px, i-export sa 1200 px.
• Product grid thumbnail: lumalabas nang humigit-kumulang 300 px, i-export sa 600 px.
• Litrato ng may-akda o profile: lumalabas nang humigit-kumulang 80 px, i-export sa 160 px.
• Logo sa header: lumalabas nang humigit-kumulang 180 px, i-export sa 360 px o gumamit ng vector graphics.

Bakit eksepsiyon ang mga full width na imahe

Ang full width banner ay walang nakapirming laki ng display, kaya limitahan ito sa 1920 pixels at i-compress nang mas matindi sa halip na doblehin. Ang pagdodoble ng full width na imahe sa 3840 pixels ay lumilikha ng file na hindi makatwiran para sa anumang page.

Ang mga banner ay karaniwang tinitingnan mula sa malayo at naglalaman ng mas kaunting pinong detalye kaysa sa litrato ng produkto, na nangangahulugang hindi gaanong kapansin-pansin ang agresibong compression sa mga ito. Ang isang 1920 pixel banner sa kalidad na 70 sa WebP ay karaniwang nananatiling mababa sa 200 KB at mukhang tama sa bawat screen, habang ang 3840 pixel na bersyon ay hindi nagbibigay ng nakikitang pakinabang sa 4 na beses na bigat.

Paano ayusin ang isang buong library

Upang mai-resize nang tama ang isang umiiral na site, sundin ang 6 na hakbang na ito.

1. Ilista ang mga slot ng imahe sa iyong disenyo, na karaniwang 4 hanggang 6 na magkakahiwalay na sukat sa halip na dose-dosenang iba-iba.
2. Sukatin ang lapad ng display ng bawat slot gamit ang browser inspector sa isang live na page.
3. Doblehin ang bawat lapad upang makuha ang iyong sukat sa pag-export.
4. Ayusin ang library sa mga folder ayon sa slot, dahil ang isang batch ay naglalapat ng isang sukat sa bawat file sa loob nito.
5. I-resize ang bawat folder sa target na lapad nito, pagkatapos ay i-compress at i-convert sa parehong proseso.
6. Palitan ang mga file gamit ang parehong mga pangalan upang patuloy na gumana ang mga umiiral na page.

Ang pag-aayos sa mga folder ay ang hakbang na nagiging dahilan upang maging batch job ito. Karamihan sa mga site ay gumagamit ng mas kaunting magkakaibang sukat ng imahe kaysa sa inaakala nila, at ang pagpapangkat ayon sa slot ay nag-aalis ng pangangailangang asikasuhin ang bawat file nang paisa-isa.

Mga responsive na imahe at ang srcset attribute

Gamitin ang srcset upang mag-alok ng ilang sukat at hayaan ang browser na pumili ng tama para sa bawat device. Pagkatapos ay magda-download ang telepono ng 400 pixel na file habang ang desktop ay magda-download ng 1400 pixel na file mula sa parehong markup.

Gumawa ng 3 lapad bawat imahe, karaniwang 400, 800 at 1600 pixels, at ilista ang mga ito kasama ang kanilang mga pixel width upang makapili ang browser. Karamihan sa mga content system ay awtomatikong gumagawa nito sa pag-upload, kaya suriin kung ano na ang ginagawa ng iyong platform. Kung ginagawa na ito, ang pag-upload ng orihinal na may wastong sukat ay nagpapabuti pa rin sa bawat nalilikhang variant.

Laging i-resize bago mag-compress

Ang pag-resize muna ay nangangahulugang mas kaunti ang kailangang gawin ng compression, kaya mananatiling mataas ang kalidad habang nananatiling maliit ang file. Ang pag-compress muna at pag-resize pagkatapos ay nag-aalis ng detalye na itatapon mo lang din muli.

Nakaaapekto rin ang pagkakasunod-sunod sa hitsura ng resulta. Ang isang imaheng na-compress sa buong laki ay nagdadala ng mga artefact na nagiging mas kapansin-pansin kapag pinaliit ang imahe, dahil lumiliit din ang mga artefact kasabay nito. Ang pag-resize muna ay nagbibigay ng mas malinis na source para sa encoder at kapansin-pansing mas magandang resulta sa parehong laki ng file.

Ang epekto nito sa bilis ng page

Karaniwang nag-aalis ang wastong pagsusukat ng mga imahe ng 60 hanggang 90 porsyento ng bigat ng imahe sa isang site na hindi pa ito nagagawa. Ang pagbuti ay mas malaki kaysa sa anumang pagbabago ng format at karaniwang mas malaki kaysa sa lahat ng iba pang pinagsamang pag-optimize.

Nakasentro ang epekto sa mga bisitang gumagamit ng mobile, kung saan mas mabagal ang mga koneksyon at may bayad ang data. Direktang bumubuti ang Largest Contentful Paint, dahil ang sukat na iyon ay karaniwang nakadepende sa isang malaking imahe. Ang pagpasa sa audit na Properly size images sa Lighthouse ay madalas na nag-aalis din ng 2 o 3 kaugnay na babala nang sabay-sabay.

Huwag kailanman palakihin ang imahe para magkasya

Ang pagpapalaki ay nagdaragdag ng mga pixel na hindi nakuha ng camera, kaya nagiging malabo ang resulta at lumalaki ang file nang walang pakinabang. Laging ligtas ang pagpapaliit, habang ang pagpapalaki ay ang nag-iisang operasyon na talagang nagpapasama sa hitsura.

Kung saan ang orihinal na imahe ay mas maliit kaysa sa slot na kailangan nitong punan, ang mga tapat na opsyon ay gamitin ito sa natural nitong sukat, i-crop ang layout sa paligid nito, o palitan ang imahe. Ang pagpapalaki ng 600 pixel na litrato sa 1600 pixels ay lumilikha ng malabong file na 4 na beses ang bigat sa orihinal, na sabay na bumabagsak sa parehong kalidad at bilis.

Pagsusuri sa isang page para sa sobrang laking mga imahe

Buksan ang developer tools, pumunta sa tab na Network, i-filter ayon sa mga imahe at i-reload ang page. Ipinapakita ng listahan ang bawat imahe kasama ang transferred size nito, nakaayos mula sa pinakamalaki.

Ang anumang solong imahe na higit sa 500 KB ay dapat suriin, at ang anumang page kung saan ang kabuuang sukat ng mga imahe ay higit sa 2 MB ay may problema. Mag-hover sa ibabaw ng imahe sa Elements panel upang makita ang intrinsic at displayed sizes nito nang magkatabi. Ang malaking agwat sa pagitan ng 2 numero ay ang kahulugan ng hindi wastong sukat ng imahe, at makikita ito sa loob ng ilang segundo.

Pag-resize ng isang library sa isang batch

Itakda ang target na lapad nang isang beses at ilapat ito sa bawat file sa isang folder, sa halip na isa-isahing i-resize ang mga imahe. Ang isang library ng ilang daang imahe ay nare-resize sa loob ng ilang minuto kapag pinagsama-sama ang gawain.

Maglagay ng hanggang 500 file nang sabay-sabay, o direktang mag-drag ng ZIP archive, at itakda ang target na lapad, format, at compression para sa buong grupo. Tumatakbo ang lahat sa loob ng iyong browser sa sarili mong processor, kaya ang mga client site, staging assets, at hindi pa nai-publish na galleries ay hindi kailanman nakakarating sa isang server. Walang ina-upload, na nangangahulugang ang buong pag-resize ng library ay nangyayari nang walang kahit isang file na dumadaan sa network.