Smashing Podcast Episode 39 Dengan Addy Osmani: Pengoptimalan Gambar

Episode ini telah didukung dengan baik oleh teman-teman terkasih kami di Storyblok yang membantu orang-orang memberikan pengalaman konten yang kuat di platform apa pun: Situs web perusahaan, situs e-niaga, aplikasi seluler, dan tampilan layar. Terima kasih!

Dalam episode Smashing Podcast hari ini, kita berbicara tentang pengoptimalan gambar. Langkah apa yang harus kita ikuti untuk mendapatkan gambar yang berkinerja baik di tahun 2021? Saya berbicara dengan ahli Addy Osmani untuk mencari tahu.

Tampilkan Catatan

• “Optimasi Gambar,” Addy Osmani
• Addy di Twitter
• Situs web pribadi Addy

Update mingguan

• Temui :has, Pemilih Induk CSS Asli (Dan Lainnya)
  ditulis oleh Adrian Bece
• Tiga Alat Audit Front-End yang Saya Temukan Baru-baru ini
  ditulis oleh Stefan Judis
• Boilerplate dan Starter Kit Ujung Depan yang Berguna
  ditulis oleh Cosima Mielke
• Desain Web Dilakukan dengan Baik: Memanfaatkan Audio
  ditulis oleh Frederick O'Brien
• Ketika CSS Tidak Cukup: Persyaratan JavaScript Untuk Komponen yang Dapat Diakses
  ditulis oleh Stephanie Eckles

Salinan

Drew McLellan: Dia adalah manajer teknik yang bekerja di Google Chrome, di mana timnya berfokus pada kecepatan, membantu menjaga web tetap cepat. Dikhususkan untuk komunitas open source, kontribusi masa lalunya termasuk Lighthouse, Workbox, Yeoman, Critical, dan untuk melakukan NVC. Jadi kami tahu dia tahu cara mengoptimalkan kinerja web. Tapi tahukah Anda bahwa dia ingin memenangkan Oscar untuk aktris terbaik dalam peran pendukung karena kesalahan administrasi? Teman-temanku yang hebat, tolong sambut Addy Osmani. Hai, Adi. Apa kabar?

Addy Osmani: Saya hebat.

Drew McLellan: Senang mendengarnya. Saya ingin berbicara dengan Anda hari ini tentang gambar di web. Ini adalah area di mana ada banyak perubahan dan inovasi yang mengejutkan selama beberapa tahun terakhir, dan Anda baru saja menulis buku yang sangat komprehensif tentang pengoptimalan gambar untuk Smashing. Apa motivasi untuk berpikir saat ini, “Sekarang saatnya untuk buku tentang pengoptimalan gambar?”

Addy Osmani: Itu pertanyaan yang bagus. Saya pikir kita tahu bahwa gambar telah menjadi bagian penting dari web selama beberapa dekade dan otak kita mampu menafsirkan gambar jauh lebih cepat daripada teks. Tetapi topik keseluruhan ini adalah topik yang terus menjadi semakin menarik dan lebih bernuansa dari waktu ke waktu. Dan saya selalu memberi tahu orang-orang bahwa ini mungkin, menurut saya, buku ketiga atau keempat saya. Saya tidak pernah berniat untuk menulis buku.

Addy Osmani: Saya memulai buku ini dengan menulis sebuah artikel tentang pengoptimalan gambar, dan kemudian seiring waktu saya menemukan bahwa saya tidak sengaja menulis seluruh buku tentang itu. Kami mengerjakan proyek ini selama sekitar dua tahun sekarang. Dan bahkan pada saat itu, industri telah berkembang browser dan alat-alat di sekitar gambar dan format gambar telah berkembang.

Addy Osmani: Jadi saya menulis buku ini karena saya merasa sulit untuk tetap berada di atas semua perubahan ini. Dan saya berpikir, "Saya akan menjadi warga web yang baik dan mencoba melacak semua yang telah saya pelajari di satu tempat sehingga semua orang dapat memanfaatkannya."

Drew McLellan: Ini adalah salah satu area itu, saya pikir, dengan banyak pengoptimalan kinerja di browser, ini adalah lanskap yang berubah dengan cepat, bukan? Di mana teknik yang telah Anda pelajari saat ini dan menjadi praktik terbaik, beberapa perubahan teknologi terjadi, dan kemudian Anda menemukan itu sebenarnya anti-pola dan Anda tidak boleh melakukannya. Dan mencoba untuk menjaga pengetahuan Anda dan memastikan bahwa Anda membaca artikel yang tepat dan mempelajari hal yang benar dan Anda tidak membaca sesuatu dari dua tahun lalu cukup sulit.

Drew McLellan: Jadi, mengumpulkan semuanya dalam satu buku yang diteliti dengan baik dari sumber yang otoritatif benar-benar luar biasa.

Addy Osmani: Ya. Bahkan dari sudut pandang seorang penulis, salah satu hal yang paling menarik dan mungkin salah satu hal yang paling menegangkan bagi tim editorial kami adalah saya akan menyerahkan sebuah bab dan mengatakan bahwa itu sudah selesai. Dan kemudian dua minggu kemudian, sesuatu akan berubah di browser, dan saya akan seperti, “Oh, tunggu. Saya harus membuat perubahan di menit terakhir.”

Addy Osmani: Tapi lanskap gambar telah berkembang cukup banyak, bahkan dalam satu tahun terakhir. Kami telah melihat dukungan WebP akhirnya mencapai garis akhir di sebagian besar browser modern. Dukungan gambar AVIF ada di Chrome, datang ke Firefox, JPEG XL, pemuatan lambat. Dan secara keseluruhan, kami telah melihat peningkatan dalam cara Anda dapat menggunakan gambar di web dengan cukup konkret di browser. Tetapi sekali lagi, banyak yang harus diperhatikan orang.

Drew McLellan: Beberapa orang mungkin melihat subjek pengoptimalan gambar sebagai topik yang cukup tenang. Kita semua, pada titik tertentu dalam karir kita, belajar, bagaimana mengekspor untuk web dari perangkat lunak grafis kita. Dan beberapa dari kita mungkin memiliki kebiasaan mengambil gambar yang diekspor tersebut dan menjalankannya melalui sesuatu seperti ImageOptim.

Drew McLellan: Jadi kita mungkin tahu bahwa kita harus memilih JPEG ketika itu adalah gambar fotografi dan PNG ketika itu adalah gambar berbasis grafik dan berpikir bahwa, “Oke, itu dia. Saya tahu pengoptimalan gambar, saya sudah selesai.” Tapi sungguh, hal-hal itu hanya taruhan meja, bukan, pada saat ini?

Addy Osmani: Ya, benar. Saya pikir karena kemampuan kita untuk menampilkan gambar dan gambar yang lebih detail dan lebih tajam bahkan dalam konteks yang berbeda, tergantung pada apakah Anda peduli dengan arah seni atau tidak, telah berkembang seiring waktu. Saya pikir kebutuhan untuk mencari tahu bagaimana Anda bisa mendapatkan gambar-gambar itu tampak seindah yang dimaksudkan untuk pengguna akhir Anda, dengan mengingat lingkungan mereka, kendala perangkat mereka, kendala jaringan mereka adalah masalah yang sulit dan sesuatu yang saya tahu banyak orang masih berjuang dengan.

Addy Osmani: Jadi ketika memikirkan tentang gambar dan mendapatkan pandangan yang sedikit lebih halus tentang ini lebih dari sekadar, "Hei, mari kita gunakan JPEG," atau "Mari kita gunakan PNG," saya pikir ada beberapa dimensi untuk nilai ini mengingat. Yang pertama hanya umumnya kompresi. Anda menyebutkan ImageOptim, dan banyak dari kita terbiasa hanya menyeret gambar ke suatu tempat dan mendapatkan sesuatu yang lebih kecil dari belakangnya.

Addy Osmani: Sekarang, ketika datang ke kompresi, kita biasanya berbicara tentang codec yang berbeda. Dan codec adalah teknologi kompresi yang biasanya memiliki komponen encoder untuk menyandikan file dan komponen dekoder untuk mendekode dan mendekompresinya. Dan ketika Anda memutuskan apakah Anda akan menggunakan sesuatu, biasanya Anda perlu memikirkan apakah foto atau gambar yang Anda gunakan baik-baik saja untuk didekati menggunakan pendekatan kompresi lossy atau pendekatan loss less.

Addy Osmani: Kalau-kalau orang tidak begitu akrab dengan konsep-konsep itu, pendekatan lossless adalah pendekatan di mana Anda mereproduksi file yang sama persis di akhir setelah dekompresi. Jadi Anda tidak benar-benar kehilangan banyak kualitas. Lossless lebih banyak menempatkan gambar Anda melalui mesin faks. Anda mendapatkan faksimili yang asli, dan itu tidak akan menjadi file asli. Mungkin ada beberapa artefak yang berbeda di tempat di sana. Mungkin terlihat agak berbeda. Tetapi secara umum, semakin banyak Anda mengompres, semakin banyak kualitas yang biasanya Anda hilangkan.

Addy Osmani: Dan dengan semua codec gambar modern ini, mereka mencoba melihat seberapa banyak kualitas yang dapat Anda peras sambil tetap mempertahankan ukuran file yang relatif layak, tergantung pada kasus penggunaan.

Drew McLellan: Jadi sebenarnya, dari sudut pandang teknologi, Anda memiliki gambar sumber dan kemudian Anda memiliki format file tujuan. Tetapi proses mengubah satu menjadi yang lain terbuka untuk diperdebatkan. Selama Anda memiliki file yang sesuai, cara Anda melakukannya tergantung pada codec yang dapat memiliki banyak implementasi berbeda, dan beberapa akan lebih baik daripada yang lain.

Addy Osmani: Tentu saja. Sangat. Dan saya pikir, sekali lagi, kembali ke tempat kita mulai dengan JPEG dan PNG, orang-orang mungkin tahu bahwa JPEG dibuat untuk kompresi foto yang hilang. Anda biasanya mendapatkan file yang lebih kecil dari belakangnya, dan terkadang memiliki artefak pita yang berbeda. PNG awalnya dibuat untuk kompresi lossless, cukup baik pada gambar non-fotografi.

Addy Osmani: Tapi sejak itu, banyak hal telah berevolusi. Sekitar tahun 2010, kami mulai mendapatkan dukungan untuk WebP, yang seharusnya menggantikan JPEG dan PNG dan sedikit mengalahkannya dalam hal kompresi. Tetapi jumlah format dan opsi gambar di atas meja baru saja meroket sejak saat itu. Saya pikir semuanya menuju ke arah yang baik, terutama dengan format modern seperti AVIF dan JPEG XL. Tapi butuh beberapa saat bagi kita untuk sampai ke sini. Bahkan mendapatkan dukungan WebP di semua browser membutuhkan waktu yang cukup lama.

Addy Osmani: Dan saya pikir pada akhirnya apa yang mempengaruhinya adalah memastikan bahwa pengembang telah memintanya, mereka memiliki keinginan untuk bisa mendapatkan kompresi yang lebih baik dari format modern ini, dan keinginan untuk hanya memiliki kompatibilitas yang baik di seluruh browser untuk hal-hal ini juga.

Drew McLellan: Ya. WebP tampaknya sangat menarik bagi saya, karena selain memiliki kompresi lossless dan lossy yang tersedia dalam format, kami jelas memiliki ukuran file yang jauh lebih kecil sebagai hasilnya. Dan ada dukungan browser yang bagus, dan kami melihat adopsi dari perusahaan besar seperti Google dan Netflix dan berbagai perusahaan besar.

Drew McLellan: Tapi persepsi saya di industri ini adalah bahwa kita tidak melihat penyerapan yang sama di tingkat akar rumput. Apakah WebP masih menunggu harinya?

Addy Osmani: Saya pikir saya akan mengatakan bahwa WebP akan tiba. Banyak orang telah menunggu dukungan Safari dan WebKit terwujud, dan akhirnya kami mendapatkannya. Namun ketika kita memikirkan tentang format gambar baru, sangat penting bagi kita untuk memahami apa yang sebenarnya dimaksud dengan dukungan. Ada dukungan browser untuk mendekode gambar-gambar itu. Kami juga membutuhkan dukungan alat yang sangat baik sehingga apakah Anda berada di lingkungan node, CDN gambar, jika Anda berada di CMS, Anda memiliki kemampuan untuk menggunakan format gambar tersebut.

Addy Osmani: Saya ingat bertahun-tahun yang lalu ketika WebP pertama kali keluar. Pengadopsi awal memiliki masalah Anda akan menyimpan file WebP Anda ke desktop Anda, dan kemudian tiba-tiba, “Oh, tunggu. Apakah saya perlu menyeret ini ke browser saya untuk melihatnya?,” atau, “Jika pengguna saya mengunduh WebP, apakah mereka akan terjebak dan bertanya-tanya apa yang terjadi?”

Addy Osmani: Jadi, memastikan bahwa ada dukungan yang cukup holistik untuk format gambar baik di tingkat sistem operasi maupun dalam konteks lain, menurut saya, sangat penting agar format gambar dapat berkembang. Penting juga bagi orang yang menyajikan gambar untuk memikirkan kasus penggunaan ini sedikit sehingga, jika saya menyimpan atau mengunduh file, Anda mencoba memasukkannya ke dalam format portabel yang biasanya dapat dibagikan orang dengan mudah. Dan saya pikir di sinilah, setidaknya di iOS, iOS mendapat dukungan untuk kenaikan dan tanda hubung. Dan mengonversi berbagai hal ke JPEG bila perlu memungkinkan orang untuk membagikannya.

Addy Osmani: Jadi memikirkan jenis kasus penggunaan di mana kami dapat memastikan bahwa pengguna tidak kehilangan saat kami memberikan kompresi yang lebih baik kepada mereka adalah penting, menurut saya.

Drew McLellan: Saya memiliki layanan berbagi slide yang saya jalankan, seperti yang dapat Anda bayangkan, menangani ratusan ribu gambar. Dan ketika saya melihat WebP, dan ini mungkin mungkin tiga tahun yang lalu, saya terutama mencari cara untuk mengurangi biaya bandwidth CDN, karena jika Anda menyajikan file yang lebih kecil, Anda dikenakan biaya lebih sedikit untuk menyajikannya. Tetapi sementara saya masih membutuhkan gambar fullback, format gambar lama juga, perhitungan saya menunjukkan bahwa biaya menyimpan keseluruhan kumpulan gambar lainnya lebih besar daripada manfaat menyajikan file yang lebih kecil. Jadi di sinilah kita pada tahun 2021. Apakah itu keputusan yang harus saya pertimbangkan kembali saat ini?

Addy Osmani: Saya pikir itu pertimbangan yang sangat penting. Kadang-kadang, ketika kita berbicara tentang bagaimana Anda harus mendekati strategi citra Anda, sangat mudah untuk memberikan jawaban tingkat tinggi kepada orang-orang, “Hei, ya. Buat saja lima format berbeda, dan itu akan diskalakan tanpa batas.” Dan tidak selalu demikian.

Addy Osmani: Saya pikir ketika Anda harus mengingat penyimpanan, terkadang mencoba menemukan apa yang terbaik, penyebut paling umum untuk melayani pengguna Anda patut diingat. Hari-hari ini, saya benar-benar akan mengatakan bahwa WebP layak dipertimbangkan sebagai penyebut umum itu. Untuk orang-orang yang telah terbiasa menggunakan tag gambar untuk menyajikan format berbeda secara kondisional kepada orang-orang, biasanya Anda akan menggunakan JPEG sebagai cadangan utama Anda. Mungkin tidak apa-apa hari ini untuk benar-benar menggunakan WebP sebagai cadangan Anda untuk sebagian besar pengguna, kecuali jika Anda memiliki orang-orang yang menggunakan browser yang sangat, sangat tua. Dan saya pikir kita melihat lebih sedikit dari itu akhir-akhir ini. Tetapi Anda pasti memiliki fleksibilitas di sana.

Addy Osmani: Sekarang, jika Anda mencoba untuk menghadap ke depan, saya akan mengatakan pilih satu format yang menurut Anda bekerja dengan sangat baik. Jika Anda dapat mendekati penyimpanan dengan cara yang skala dan fleksibel untuk kebutuhan Anda, apa yang saya katakan orang harus lakukan adalah mempertimbangkan JPEG XL. Secara teknis belum dikirim di browser. Ketika itu terjadi, JPEG XL harus menjadi pilihan yang cukup bagus untuk banyak foto dalam kasus penggunaan lossy atau lossless atau untuk kasus penggunaan non-foto juga. Dan itu mungkin akan jauh lebih baik daripada WebP V1. Jadi itu satu tempat.

Addy Osmani: Saya pikir AVIF mungkin akan lebih baik jika Anda perlu menggunakan bit rate yang sangat rendah. Mungkin Anda sangat peduli dengan bandwidth. Mungkin Anda sedikit kurang peduli tentang kesetiaan gambar. Dan pada kecepatan bit itu, saya bisa membayangkannya terlihat lebih tajam daripada beberapa alternatif. Dan sampai kami memiliki JPEG XL, saya akan mencoba melihat analytics Anda dan memahami apakah mungkin bagi Anda untuk melayani AVIF. Kalau tidak, saya akan fokus pada WebP itu. Jika Anda seorang analitik, saya kira kebanyakan orang dapat dilayani WebP dan Anda tidak terlalu peduli tentang gamut lebar atau hamparan teks, tempat pengambilan sampel kromosom mungkin tidak sempurna di WebP. Itu tentu sesuatu yang perlu diingat.

Addy Osmani: Jadi saya akan mencoba untuk mengingat bahwa tidak akan ada satu ukuran yang cocok untuk semua orang. Saya pribadi, akhir-akhir ini, sedikit khawatir tentang penyimpanan dan jalan keluar dan biaya bandwidth, hanya karena saya menggunakan CDN gambar. Dan saya senang mengatakan bahwa saya menggunakan Cloudinary secara pribadi. Kami menggunakan banyak CDN gambar yang berbeda di tempat saya bekerja. Tetapi saya menemukan bahwa tidak perlu terlalu khawatir tentang biaya pemeliharaan untuk menangani saluran gambar, berurusan dengan bagaimana saya akan mendukung seperti, “Oh, hei, ini format gambar lain atau jenis fallback baru atau API web baru ,” itu adalah manfaat yang bagus untuk berinvestasi dalam sesuatu yang hanya mengurusnya untuk saya.

Addy Osmani: Dan kemudian biaya keseluruhan untuk kasus penggunaan saya baik-baik saja. Tapi saya benar-benar dapat membayangkan bahwa jika Anda menjalankan layanan slide pada skala itu, itu mungkin juga bukan pilihan.

Drew McLellan: Ya. Jadi saya ingin kembali ke beberapa format mendatang yang akan datang. Tapi saya pikir itu layak untuk digali, karena dengan alat kinerja apa pun, Lighthouse, atau WebPageTests, jika ada di antara kita yang menjalankan situs kita melaluinya, salah satu hal utama yang akan disarankan adalah kita menggunakan CDN untuk gambar. Dan itu adalah hal yang sangat realistis untuk dilakukan bagi perusahaan yang sangat besar. Apakah itu realistis dan dalam jangkauan orang-orang yang membuat situs web dan aplikasi yang lebih kecil, atau apakah itu sebenarnya semudah kedengarannya?

Addy Osmani: Saya pikir pertanyaan yang harus diajukan orang adalah, “Untuk apa Anda menggunakan gambar?” Jika Anda hanya memiliki beberapa gambar, jika Anda sedang membangun sebuah blog dan gambar yang Anda tambahkan relatif sederhana, Anda tidak memiliki ratusan dan ratusan atau ribuan ribu gambar, Anda mungkin baik-baik saja dengan mendekati ini pada waktu pembuatan, dengan cara yang sangat statis, di mana Anda menginstal beberapa paket NPM. Mungkin Anda hanya menggunakan Sharp. Dan itu mengurus Anda untuk sebagian besar.

Addy Osmani: Ada alat yang dapat membantu Anda menghasilkan banyak format. Itu memang sedikit meningkatkan waktu pembuatan Anda, tetapi itu mungkin baik-baik saja untuk banyak orang. Dan kemudian untuk orang-orang yang ingin dapat memanfaatkan multi-

Addy Osmani: Dan kemudian bagi orang-orang yang ingin dapat memanfaatkan berbagai format, mereka tidak ingin berurusan dengan banyak hal kecil dan ingin bisa mendapatkan gambar atau cerita responsif yang sangat kaya, saya akan mengatakan mencoba CDN gambar. Saya pribadi cukup segan menggunakannya untuk proyek pribadi karena masalah biaya pada awalnya, dan kemudian seiring waktu ketika saya melihat tagihan saya, saya benar-benar menyadari bahwa ini menghemat waktu saya yang seharusnya saya investasikan untuk mengatasi masalah ini sendiri. Saya tidak tahu berapa banyak Anda harus menulis skrip khusus untuk menangani gambar Anda di masa lalu, tetapi saya menyadari jika saya dapat menyelamatkan diri saya sendiri setidaknya beberapa hari untuk men-debug melalui paket npm yang berbeda ini sebulan, maka biayanya jenis mengurus waktu saya menabung dan jadi tidak apa-apa.

Addy Osmani: Tapi itu bisa menjadi sesuatu di mana jika Anda menskalakan ke 100-an dari 1000-an atau jutaan gambar dan itu bukan sesuatu yang harus ditanggung oleh pendapatan Anda atau bukan sesuatu yang Anda siap bayar, Anda perlu memikirkannya strategi alternatif. Dan saya pikir kami beruntung bahwa kami memiliki cukup fleksibilitas dengan alat yang tersedia bagi kami hari ini untuk dapat pergi ke salah satu dari arah itu, di mana kami melakukan sesuatu yang sedikit lebih seperti kebiasaan, kami menanganinya sendiri atau berguling CDN gambar kita sendiri atau kita berinvestasi dalam sesuatu yang sedikit lebih komersial. Dan kami berada di tempat di mana saya akan mengatakan bahwa untuk beberapa kasus penggunaan, ya Anda dapat menggunakan CDN gambar dan harganya terjangkau.

Drew McLellan: Saya rasa, salah satu prinsip panduan adalah selalu gesit dan bersiap untuk perubahan. Dan Anda mungkin mulai menggunakan CDN gambar untuk secara dinamis mengonversi gambar untuk Anda seperti yang diminta, dan jika itu sampai pada titik di mana itu tidak berkelanjutan dari segi biaya, Anda dapat melihat solusi lain dan memiliki basis kode Anda dalam keadaan di mana akan mudah untuk mengganti satu solusi dengan yang lain. Saya pikir secara umum dan di mana pun Anda mengandalkan layanan pihak ketiga, itu prinsip yang baik untuk dimiliki bukan? Jadi format gambar yang akan datang ini, Anda menyebutkan JPEG XL. Apa itu JPEG XL? Dari mana asalnya? Dan apa manfaatnya bagi kita?

Addy Osmani: Itu pertanyaan yang bagus. Jadi JPEG XL adalah format gambar generasi berikutnya, seharusnya untuk tujuan umum dan merupakan codec dari komite JPEG. Ini dimulai dengan beberapa akar dalam format pic Google dan kemudian format FUIF Cloudinary. Ada banyak format selama bertahun-tahun yang telah dimasukkan oleh upaya ini, tetapi ini menjadi lebih dari sekadar jenis jumlah dari bagian-bagian individualnya dan beberapa manfaat JPEG XL adalah bagus untuk kesetiaan yang tinggi. gambar, sangat bagus untuk lossless, mendapat dukungan untuk decoding progresif, transcoding JPEG lossless, dan juga agak rewel dan bebas royalti, yang jelas merupakan keuntungan. Saya pikir JPEG XL berpotensi menjadi kandidat yang sangat kuat. Kami berbicara sebelumnya tentang, jika Anda hanya memilih satu, apa yang akan Anda gunakan? Dan saya pikir JPEG XL punya potensi untuk itu.

Addy Osmani: Saya juga tidak ingin terlalu berjanji, kami masih sangat awal dengan dukungan browser. Jadi saya pikir kita harus benar-benar menunggu dan melihat, bereksperimen dan mengevaluasi seberapa baik itu sejalan dalam praktik dan memenuhi harapan orang, tetapi saya melihat banyak potensi dengan JPEG XL untuk kasus lossy dan lossless. Saat ini, saya percaya bahwa Chrome mungkin adalah yang terjauh dalam hal dukungan, tetapi saya juga melihat minat yang pasti dari pihak Mozilla dan browser lain dalam hal ini, jadi saya bersemangat tentang masa depan dengan JPEG XL. Dan jika kita harus mengatakan, apa yang menarik bagi orang-orang dengan jangka waktu yang lebih pendek? Tentu saja ada AVIF juga.

Drew McLellan: Ceritakan tentang AVIF, ini adalah satu lagi yang saya tidak kenal.

Addy Osmani: Oke. Jadi kami telah menyebutkan sedikit sebelumnya tentang AVIF yang mungkin menjadi kandidat yang lebih baik jika Anda perlu menggunakan bit rate rendah dan Anda lebih mementingkan bandwidth daripada fidelitas gambar, sebagai prinsip umum, AVIF benar-benar memimpin dalam kompresi daya tarik tinggi dengan fidelitas rendah. Dan JPEG XL, itu harus unggul dalam kesetiaan sedang hingga tinggi, tetapi mereka memiliki format yang sedikit berbeda dalam hak mereka sendiri. Kami berada di tempat di mana AVIF mendapatkan dukungan browser yang semakin baik, tetapi izinkan saya mundur selangkah dan berbicara lebih banyak tentang formatnya. Jadi AVIF sendiri didasarkan pada codec video AV1, yang telah distandarisasi oleh Alliance for Open Media, dan mencoba membuat orang memperoleh peningkatan kompresi yang signifikan melalui JPEG, melalui WebP, yang telah kita bicarakan sebelumnya. Dan meskipun penghematan tepat yang dapat Anda peroleh dari AVIF akan bergantung pada konten dan target kualitas Anda, kami telah melihat banyak kasus di mana AVIF dapat menawarkan penghematan lebih dari 50% dibandingkan dengan JPEG.

Addy Osmani: Ini memiliki banyak fitur bagus, mampu memberi Anda dukungan wadah untuk fitur baru seperti rentang dinamis tinggi dan gamut warna lebar, sintesis butiran film. Dan sekali lagi, mirip dengan berbicara tentang menghadap ke depan, salah satu hal yang menyenangkan tentang tag gambar adalah Anda dapat menyajikan file AVIF kepada pengguna sekarang dan masih akan kembali ke WebP atau JPEG Anda jika belum tentu didukung . Tetapi kembali ke contoh Anda tentang Photoshop Save For Web, Anda dapat mengambil JPEG berukuran 500 kilobyte, mencoba memotret dengan kualitas yang mirip dengan Photoshop Save For Web dan dengan AVIF saya akan mengatakan bahwa Anda mungkin dapat memperoleh titik di mana ukuran file itu sekitar 90 kilobyte, 100 kilobyte sehingga cukup banyak penghematan tanpa penurunan kualitas yang nyata.

Addy Osmani: Dan salah satu hal yang menyenangkan tentang itu adalah Anda idealnya tidak akan melihat banyak kehilangan tekstur pada gambar apa pun yang memiliki detail yang kaya. Jadi, jika Anda memiliki foto hutan atau berkemah atau hal-hal semacam itu, foto-foto itu akan tetap terlihat sangat kaya dengan AVIF. Jadi saya cukup bersemangat tentang arah yang dimiliki AVIF. Saya pikir itu perlu sedikit lebih banyak pekerjaan dalam hal dukungan perkakas. Jadi saya menjatuhkan tweet tentang ini beberapa hari yang lalu, kami memiliki sejumlah opsi untuk menggunakan AVIF sekarang, untuk satu gambar kami memiliki Squoosh, squoosh.app, yang ditulis oleh tim lain di Chrome, jadi berteriaklah ke Surma dan Jake untuk mengerjakan Squoosh. Avif.io memiliki sejumlah opsi bagus untuk orang-orang yang mencoba menggunakan AVIF hari ini, terlepas dari tumpukan teknologi apa yang mereka fokuskan, Sharp juga mendukung AVIF.

Addy Osmani: Tapi kemudian secara umum Anda berpikir tentang tempat lain di mana kita berurusan dengan gambar, apakah itu di Figma atau di Sketch atau di Photoshop atau di tempat lain, dan saya akan mengatakan bahwa kita masih perlu melakukan sedikit pekerjaan dalam hal Dukungan AVIF di sana, karena itu perlu ada di mana-mana bagi pengembang dan pengguna untuk benar-benar merasa seperti mendarat dan pulang. Dan itulah salah satu area fokus bagi kami dengan tim yang mengerjakan AVIF di Chrome saat ini, mencoba memastikan bahwa kami bisa mendapatkan peralatan di tempat yang cukup bagus.

Drew McLellan: Jadi kami memiliki HTML, elemen gambar sekarang, yang memberi kami lebih banyak fleksibilitas dibandingkan tag gambar tradisional. Meskipun tag gambar juga telah berkembang jauh, bukan? Tapi kami melihat gambar ditambahkan, itu sekitar waktu yang sama dengan tag video asli, saya pikir dalam kumpulan HTML5 asli semacam itu berubah. Dan ini memberi kita kemampuan untuk menentukan banyak sumber, benar?

Addy Osmani: Ya, benar.

Drew McLellan: Jadi Anda dapat membuat daftar format gambar yang berbeda dan browser akan memilih salah satu yang didukungnya, dan itu memungkinkan kami untuk langsung bereksperimen tanpa perlu terlalu khawatir tentang merusak sesuatu untuk orang-orang dengan browser yang lebih lama.

Addy Osmani: Tentu saja. Saya pikir itu salah satu manfaat terbaik menggunakan tag gambar di luar kasus penggunaan di mana kita memikirkan arah kita, hanya bisa menyajikan gambar kepada orang-orang dan membuat browser menelusuri daftar sumber potensial dan melihat, oke, baik, saya akan menggunakan yang pertama dalam daftar yang saya mengerti kalau tidak saya akan mundur, itu kemampuan yang sangat kuat untuk orang-orang. Saya pikir pada saat yang sama, saya juga mendengar beberapa orang mengungkapkan kekhawatiran atau kekhawatiran bahwa kami membuat kembali gumpalan markup yang sangat besar sekarang ketika kami mencoba untuk mendukung berbagai format dan Anda memperhitungkan ukuran yang berbeda untuk format tersebut dan tiba-tiba menjadi sedikit besar.

Addy Osmani: Jadi, apakah ada cara lain untuk mengatasi masalah itu? Saya tidak ingin menjual orang terlalu banyak pada CDN gambar, saya ingin mereka berdiri sendiri. Tapi ini adalah salah satu tempat di mana ide yang disebut negosiasi konten benar-benar dapat menawarkan Anda jalan yang menarik. Jadi, kami telah berbicara sedikit tentang tag gambar di mana Anda harus menghasilkan banyak sumber daya yang berbeda dan memutuskan urutan preferensi, benar, HTML ekstra. Dengan negosiasi konten, apa yang dikatakannya adalah mari kita lakukan semua pekerjaan itu di server. Jadi klien dapat memberi tahu server format apa yang didukungnya di depan melalui daftar tipe MIME melalui header Terima HTTP. Kemudian server dapat melakukan semua pekerjaan berat untuk menghasilkan dan mengelola sumber daya utama dan memutuskan mana yang akan dikirim ke klien. Dan salah satu hal yang kuat di sini adalah jika Anda menggunakan CDN gambar, Anda dapat menunjuk ke satu sumber daya.

Addy Osmani: Jadi mungkin jika kita memiliki gambar anak anjing seperti puppy.JPEG, kita dapat memberikan URL ke puppy.JPEG kepada orang-orang dan jika browser mereka mendukung WebP atau mendukung AVIF, server dapat menjadi sangat pintar dalam menyajikan ke kanan gambar ke pengguna tersebut tergantung pada seperti apa dukungan mereka, tetapi sebaliknya mundur tanpa Anda perlu melakukan banyak pekerjaan ekstra sendiri. Sekarang, saya pikir itu ide yang kuat. Ada banyak hal yang dapat Anda lakukan di server, terkadang kita berbicara tentang bagaimana tidak semua orang memiliki akses ke kualitas jaringan yang sangat kuat, jenis koneksi efektif Anda bisa sangat berbeda tergantung di mana Anda berada.

Addy Osmani: Bahkan tinggal di Silicon Valley, saya bisa berjalan dari kedai kopi ke hotel atau saya bisa berada di dalam mobil dan kualitas wifi saya atau sinyal saya mungkin tidak terlalu bagus. Jadi, di sinilah Anda mendapatkan akses ke API lain, ide lain seperti klien Simpan-Data mengisyaratkan untuk berpotensi dapat melayani orang-orang dengan sumber daya berukuran lebih kecil, jika pengguna telah memilih untuk menghemat data. Jadi ada banyak hal menarik yang bisa kita lakukan di sisi server dan saya pikir kita harus terus mendorong ide-ide ini untuk menemukan keseimbangan yang bagus di mana orang-orang yang merasa nyaman dengan melakukan jalur pasar memiliki semua fleksibilitas untuk melakukannya. dan orang-orang yang menginginkan solusi yang sedikit lebih ajaib juga memiliki beberapa pilihan.

Drew McLellan: Konsep pendekatan penghemat data semacam ini adalah sesuatu yang saya pelajari pertama kali dari buku Anda. Maksud saya, mari kita bahas lebih jauh karena itu cukup menarik. Jadi Anda berbicara tentang browser yang dapat memberi sinyal preferensi untuk menginginkan pengalaman data yang dikurangi kembali karena mungkin itu pada koneksi terukur atau memiliki baterai rendah atau sesuatu.

Addy Osmani: Tepat sekali. Tepat. Saya telah bepergian di waktu normal atau sebelumnya ketika kami akan bepergian lebih banyak, saya telah mengalami banyak tempat di dunia atau situasi di mana kualitas jaringan saya mungkin sangat buruk atau sangat buruk, dan bahkan pembukaan membuat halaman web bisa menjadi pengalaman yang membuat frustrasi atau sulit. Saya mungkin sedang mencari menu dan jika saya tidak dapat melihat gambar makanan indah yang mereka sediakan, saya mungkin akan pergi ke suatu tempat di mana saya bisa, atau saya mungkin, saya tidak tahu, membuat makanan untuk diri saya sendiri. Tapi saya pikir salah satu hal menarik tentang penghemat data adalah memberikan Anda koneksi kembali ke preferensi pengguna. Jadi jika sebagai pengguna, saya tahu bahwa saya mengalami kesulitan dengan koneksi jaringan saya. Saya dapat mengatakan, "Oke, saya akan memilih mode penghemat data di browser saya."

Addy Osmani: Dan kemudian Anda dapat menggunakannya sebagai pengembang sebagai sinyal untuk mengatakan, "Oke, well, pengguna sedikit terkendala, mungkin kami akan menelusuri mereka ke gambar yang jauh lebih kecil atau gambar dengan kualitas yang jauh lebih rendah." Tapi mereka masih bisa melihat beberapa gambar sama sekali, yang lebih baik daripada mereka menunggu waktu yang sangat lama untuk sesuatu yang jauh lebih kaya untuk disajikan. Manfaat lain dari jenis sinyal ini adalah Anda dapat menggunakannya untuk media penyajian bersyarat. Jadi mungkin ada kasus di mana teks adalah hal terpenting di halaman itu, mungkin Anda dapat menonaktifkan gambar tersebut jika Anda menemukan bahwa pengguna berada dalam semacam lingkungan yang dibatasi. Saya hanya akan menghabiskan 30 detik untuk ini, tetapi Anda benar-benar dapat mendorong ide ini hingga ekstrem. Beberapa hal menarik yang dapat Anda lakukan dengan Save-Data bahkan mungkin mematikan fitur yang sangat mahal yang diimplementasikan dalam JavaScript.

Addy Osmani: Jika Anda memiliki komponen tertentu yang dianggap sedikit lebih opsional, mungkin komponen tersebut tidak perlu dikirimkan ke semua pengguna jika hanya meningkatkan pengalaman. Anda masih dapat memberikan pengalaman yang sangat inti, kecil, dan cepat kepada semua orang, dan kemudian melapisinya dengan frosting yang bagus untuk orang-orang yang memiliki koneksi atau perangkat yang lebih cepat.

Drew McLellan: Mungkin, saya kira itu bisa menjadi faktor dalam pagination dan Anda bisa mengembalikan 10 hasil pada halaman daripada 100 dan hal-hal semacam itu juga. Begitu banyak kemampuan menarik dan menarik di sana. Saya rasa kita semua sudah familiar dengan proses frustasi dalam menyiapkan situs baru, mengoptimalkan semua gambar Anda, menyerahkannya kepada klien, memberi mereka CMS untuk mengelola konten dan menemukan bahwa mereka hanya mengganti semuanya dengan gambar yang dioptimalkan dengan buruk. Maksud saya, sekali lagi, CDN gambar, saya kira, akan menjadi solusi yang sangat nyaman untuk itu tetapi apakah ada solusi lain, apakah ada hal-hal yang dapat dilakukan CMS di server untuk membantu dengan itu atau apakah CDN gambar hanya mungkin jalan untuk pergi?

Addy Osmani: Saya pikir apa yang kami temukan setelah mungkin setidaknya enam atau tujuh tahun mencoba untuk membuat semua orang mengoptimalkan gambar mereka adalah masalah sulit di mana beberapa orang yang terlibat dalam gambar mungkin sedikit lebih paham secara teknis dan mungkin pengaturan yang nyaman menyiapkan peralatan mereka sendiri atau pergi dan menjalankan Lighthouse atau mencoba alat lain untuk memberi tahu mereka apakah ada peluang untuk meningkatkan. Saya ingin melihat orang-orang secara konsisten menggunakan hal-hal seperti Mercusuar untuk menangkap jika Anda memiliki kesempatan untuk mengoptimalkan lebih lanjut atau menyajikan gambar dengan ukuran yang tepat, tetapi di luar itu, terkadang kami mengalami kasus penggunaan di mana orang yang mengunggah gambar mungkin tidak bahkan harus memahami biaya sumber daya yang mereka unggah. Ini biasanya sesuatu yang kita alami, dan saya akan minta maaf, saya tidak akan memanggil orang terlalu banyak, tapi ini adalah sesuatu yang kita temui bahkan dengan blog Google.

Addy Osmani: Setiap beberapa minggu di blog Google, kami akan meminta seseorang mengunggah GIF animasi berukuran 20 atau 30 megabyte yang sangat besar. Dan saya tidak berharap mereka tahu bahwa itu bukan ide yang baik, mereka mencoba membuat artikel terlihat keren dan sangat menarik dan interaktif, tetapi audiens tersebut belum tentu tahu untuk pergi dan menjalankan alat atau menggunakan ImageOptim atau menggunakan salah satu dari alat-alat lain ini dan mendokumentasikannya, sehingga mereka harus memeriksanya, tentu saja merupakan salah satu pilihan. Namun mampu mengotomatisasi masalah, menurut saya sangat menarik dan membantu kami secara konsisten mencapai tempat di mana kami berharap dapat menyeimbangkan kebutuhan semua pengguna CMS kami, baik itu teknis maupun non-teknis, juga sebagai kebutuhan pengguna kami.

Addy Osmani: So I think the image CDNs can definitely play a role in helping out here. Ultimately, the thing that's important is making sure you have a solution in place between people, stakeholders who might be uploading those images, and what gets served down to users. If it's an image CDN, if it's something you've rolled yourself, if it's a built step, just needs to be something in place to make sure that you are not serving down something that's very, very large and inefficient.

Drew McLellan: Talking about animated GIFs, they're surprisingly popular. They're fun, we love them, but they're also huge. And really, it's a case where a file format that was not designed for video is being used for video. Is there a solution to that with any of these image formats? Apa yang bisa kita lakukan?

Addy Osmani: Oh, gosh. The history of GIFs is fascinating. We saw a lot of the formats we know and love or have been around for a while were originated in the late '80s to early '90s, and the GIF is one of those. It was created in 1987. I'm about as old as the GIF.

Addy Osmani: As you mentioned, it wasn't originally created necessarily for use case. I think it was Netscape Navigator which in mid '90s maybe added support for looping GIFs and giving us this kind of crazy fun way to do memes and the like, but GIFs have got so many weaknesses. They're kind of limited in many cases to a very finite color palette; 256 colors, in many cases. They're a bitmapped raster format with pixel value stored in image files.

Addy Osmani: They're very inefficient, for a number of reasons. And you mentioned that they're also quite large. I think that we've gotten into this place of thinking that if we want a short segment of video or animation that's going to be looping, the GIF is the thing that we have to use. And that's just not the case.

Addy Osmani: While we do see that there are modern image formats that have support for animation, I think that the most basic thing you can do these days is make sure you're serving a video down instead of a GIF. Muted auto-play videos combined with HD64, HD65, whatever video you're going to use, can be really powerful, and significantly smaller for use cases where you need to be showing a sequence of images.

Addy Osmani: There are options for this. AVIF has got image sequences in there, potentially. Other formats have explored these ideas as well. But I think that one thing you can do is, if you're using GIFs today, or you have users who are slightly less technical who are using GIFs today, try to see if you can give them tools that will allow them to export a video instead, or if your pipeline can take care of that for them, that's even better.

Addy Osmani: I have plenty of conversations with CMS providers where you do see people uploading GIFs. They don't know the difference between a video and a GIF file. But if you can just, whether it's with an image CDN or via some built process, change the file over to a more efficient format, that would be great.

Drew McLellan: We talked briefly about tools like ImageOptim that manage to strip out information from the files to give us the same quality of result with a smaller file size. I'm presuming that's because the file formats that we commonly deal with weren't optimized for delivery over the Web in the first place, so they're doing that step of removing anything that isn't useful for serving on the Web. Do these new formats take that into consideration already? Is something like ImageOptim a tool that just won't be required with these newer formats?

Addy Osmani: I'm anticipating that some of the older formats… Things that have been around for a while, take a while to phase out or to evolve into something else. And so I can see tools like ImageOptim continuing to be useful. Now, what are modern image formats doing that are much better? Well, I would say that they're taking into account quite a few things.

Addy Osmani: They're taking into account, are there aspects of the picture that the human eye can't necessarily make out a difference around? When I'm playing around with different quality settings or different codecs, I'm always looking for that point where if I take the quality down low enough, I'm going to see banding artifacts. I'm going to see lots of weird looking squares around my buildings or the details of my picture.

Addy Osmani: But once those start to disappear, I really need to start zooming in to the image and making comparisons across these different formats. And if users are unlikely to do that, then I think that there are good questions around is that point of quality good enough? I think that modern image formats are pretty good at being able to help you navigate, filtering out some of those details pretty well. Keeping in mind what are the needs of color, because obviously we've got white gamut as a thing right now as well.

Addy Osmani: Some people might be okay with an amount of changing your color palette versus not, depending on the type of images that you have available, but definitely I see modern formats trying to be resilient against things like generational loss as well. Generational loss is this idea that… We mentioned memes earlier. A common problem on the Web today is you'll find a meme, whether it's on Facebook or Instagram or Reddit or wherever else, you'll save it, and maybe you'll share it around with a friend. Maybe they'll upload it somewhere else. And you suddenly have this terrible kind of copy machine or fax effect of the quality of that image getting worse and worse and worse over time.

Addy Osmani: And so when I see something get reshared that I may have seen three months ago, now it might not be really, really bad quality. You can still make out some of the details, but image formats, being able to keep that in mind and work around those types of problems, I think are really interesting.

Addy Osmani: I know that JPEG XL was trying to keep this idea of generational loss in mind as well. So there's plenty of things that modern codecs and formats are trying to do to evolve for our needs, even if they're very meme focused.

Drew McLellan: Let's say you've inherited a project that has all sorts of images on it. What would be the best way to assess the state of that project in terms of image optimization? Are there tools or anything that would help there?

Addy Osmani: I think that it depends on how much time you've got to sink into the problem. There are very basic things people can try doing, like obviously batch converting those images over to more modern formats at the recommended default quality and do an eyeball check on how well they're doing compared to the original.

Addy Osmani: If you're able to invest a little bit more time, there are plenty of tools and techniques like DSSIM and other ways of being able to compare what the perceptual quality differences are between different types of images that have been converted. And you can use that as a kind of data-driven approach to deciding, if I'm going to batch convert all of my old images to WebP, what is the quality setting that I should be relying on? If I'm going to be doing it for AVIF or JPEG XL, what is the quality setting that I should be relying on?

Addy Osmani: I think that there's plenty of tools people have available. It really just depends on your time sink that's possible. Other things that you can do, again, going back to the image CDN aspect, if you don't have a lot of time and you're comfortable with the cost of an image CDN, you can just bulk upload all of those images. And there are CDNs that support this idea of automatic quality setting. I think in Cloudinary it's q_auto, or something like that.

Addy Osmani: But the basic idea there is they will do a scan of the image, try to get a sense of the type of content that's in there, and automatically decide on the right level of quality that you should be using for the images that are getting served down to users. And so you do have some tooling options that are available here, for sure.

Drew McLellan: I mean, you mentioned batch processing of images. Presumably you're into the area of that generational loss that you're talking about, when you do that. When you take an already compressed JPEG and then convert it to a WebP, for example, you risk some loss of quality. Is batch converting a viable strategy or does that generational loss come too much into play if you care about the pristine look of the images?

Addy Osmani: I think it depends on how much you're factoring in your levels of comfort with lossy versus lossless, and your use case. If my use case is that I've inherited a project where the project in question is all of my family's photos from the last 20 years, I may not be very comfortable with there being too much quality loss in those images, and maybe I'm okay with spending a little bit more money on storage if the quality can remain mostly the same, just using a more modern format.

Addy Osmani: If those are images for a product catalog or any commerce site, I think that you do need to keep in mind what your use case is. Are users going to require being able to see these images with a certain level of detail? And if that's the case, you need to make those trade-offs in mind when you're choosing the right format, when you're choosing the right quality.

Addy Osmani: So I think that batch is still okay. To give you a concrete idea of one way of seeing people approach this at scale, sometimes people will take a smaller sample of the images from that big collection that they've inherited, and they'll try out a more serious set of experiments with just that set. And if they're able to land on an approach that works well for the sample, they'll just apply it to the whole batch. And I've seen that work to varying degrees of success.

Drew McLellan: So optimizing file size is just sort of one point on the overall image optimization landscape. And I'd like to get on to talking about what we can do in our browsers to optimize the way the images are used, which we'll do after a quick word from this episode sponsor.

Drew McLellan: So we've optimized and compressed our large files, but now we need to think about a strategy for using those in the browser. The good old faithful image tag has gained some new powers in recent times, hasn't it?

Addy Osmani: Yeah, it has. And maybe it's useful for folks… I know that a lot of people that ask me about images these days also ask me to frame it in terms of metrics and the Core Web Vitals. Would it be useful for me to talk about what the Core Web Vitals are and maybe frame some of those ideas in those current terms?

Drew McLellan: Absolutely, because Core Web Vitals is a sort of initiative from Google, isn't it, that we've seen more recently? We're told that it factors into search ranking potentially at some level. What does Core Web Vitals actually mean for us in terms of images?

Addy Osmani: Great question. As you mentioned, Core Web Vitals is an initiative by Google, and it's all about trying to share unified guidance for quality signals. That can be pretty key to delivering a great user experience on the Web. And it is part of a set of page experience signals Google Search may be evaluating for ranking purposes, but they can impact the Core Web Vitals in a number of ways.

Addy Osmani: Now, before I talk about what those ways are, I should probably say, what are the Core Web Vitals metrics? There's currently three metrics that are in the Core Web Vitals. There's largest contentful paint, there's cumulative layout shift, and there's first input delay. Now, in a lot of modern Web experiences we find that images tend to be one of the largest visible elements on the page. We see a lot of product pages where we have a big image that's the main product item image. We see images in carousels, in stories and in banners.

Addy Osmani: Now, largest contentful paint, or LCP, is a Core Web Vitals metric that tries to measure when the largest contentful element, whether it's an image text or something else, is in a user's viewport, such that we're able to tell when that image becomes visible. And that really allows a browser to determine when the main content of the page has really finished rendering.

Addy Osmani: Jadi, jika saya mencoba membuka situs resep, saya mungkin peduli dengan tampilan resep itu, jadi kami peduli untuk memastikan bahwa gambar pahlawan besar dari resep itu terlihat oleh saya. Sekarang, elemen LCP dapat berubah seiring waktu. Sangat mungkin bahwa di awal pemuatan, hal terbesar mungkin adalah heading, tetapi saat halaman terus dimuat, itu mungkin benar-benar menjadi gambar yang jauh lebih besar atau semacam poster.

Addy Osmani: Jadi ketika Anda mencoba untuk mengoptimalkan cat konten terbesar, ada sekitar empat hal yang dapat Anda lakukan. Hal pertama adalah memastikan bahwa Anda meminta gambar pahlawan utama Anda sedini mungkin. Umumnya, kami memiliki sejumlah hal yang penting di halaman. Kami ingin memastikan bahwa kami dapat merender konten dan tata letak halaman utama.

Addy Osmani: Untuk tata letak, biasanya kita berbicara tentang CSS. Jadi, Anda mungkin menggunakan CSS kritis, CSS sebaris, di halaman Anda, ingin menghindari hal-hal yang membuat pemblokiran perenderan, tetapi ketika menyangkut gambar Anda, idealnya Anda harus meminta gambar itu lebih awal. Mungkin itu melibatkan hanya memastikan bahwa browser dapat menemukan gambar itu sedini mungkin di halaman, mengingat banyak dari kita saat ini mengandalkan kerangka kerja.

Addy Osmani: Jika Anda tidak perlu menggunakan SSR, rendering sisi server, jika Anda menunggu di browser untuk menemukan beberapa bundel JavaScript Anda, bundel untuk komponen Anda, apakah Anda memiliki komponen untuk gambar pahlawan atau gambar produk Anda, jika browser harus menunggu untuk mengambil, mengurai, mengeksekusi, mengkompilasi, dan mengeksekusi semua file yang berbeda ini sebelum dapat menemukan gambar, itu mungkin berarti bahwa gambar konten terbesar Anda akan memakan waktu lama sebelum dapat ditemukan.

Addy Osmani: Sekarang, jika itu masalahnya, jika Anda menemukan diri Anda berada di tempat di mana gambar diminta sangat terlambat, Anda dapat memanfaatkan fitur browser yang disebut link rel preload untuk memastikan bahwa browser dapat menemukan gambar itu sedini mungkin. mungkin. Sekarang, preload adalah kemampuan yang sangat kuat. Itu juga salah satu yang perlu Anda perhatikan. Saat ini, sangat mudah untuk mencapai tempat yang mungkin Anda dengar bahwa kami merekomendasikan pramuat untuk kunci Anda-

Addy Osmani: Mungkin Anda mendengar bahwa kami merekomendasikan pramuat untuk gambar pahlawan utama Anda, serta skrip kunci Anda, serta font utama Anda. Dan itu menjadi sangat besar, sangat besar untuk memastikan bahwa Anda mengurutkan hal-hal dalam urutan yang benar. Jadi gambar LCP jelas merupakan salah satu tempat utama yang perlu diingat untuk ini.

Addy Osmani: Hal lain, seperti yang saya sebutkan empat hal, hal lainnya adalah pastikan Anda menggunakan set sumber dan format gambar modern yang efisien. Saya pikir set sumber itu sangat kuat. Saya juga melihat kadang-kadang ketika orang menggunakannya, mereka akan mencoba untuk memberikan kompensasi yang berlebihan dan mungkin akan mengirimkan 10 versi gambar yang berbeda di sana untuk setiap kemungkinan resolusi. Kami cenderung menemukan, setidaknya dalam beberapa penelitian, bahwa di luar tiga gambar, pengguna mengalami kesulitan untuk mengetahui perbedaan kualitas gambar dan ketajaman dan detail. Jadi pembatasan DPR, pembatasan rasio piksel perangkat, tentu saja merupakan ide yang patut diingat.

Addy Osmani: Dan kemudian untuk format gambar modern, kami berbicara tentang format sebelumnya, tetapi pertimbangkan WebP Anda, AVIF Anda, JPEG XL Anda. Hindari pemborosan piksel. Sangat penting untuk memiliki strategi yang baik untuk kualitas. Dan saya pikir ada banyak kasus di mana bahkan kualitas default terkadang terlalu banyak. Jadi saya akan bereksperimen dengan mencoba menurunkan bit rate Anda, menurunkan pengaturan kualitas Anda, dan melihat seberapa jauh Anda dapat mengambil sesuatu untuk pengguna Anda sambil mempertahankan ketajaman.

Addy Osmani: Dan kemudian ketika kita berbicara tentang pemuatan, salah satu hal lain yang telah dikembangkan oleh tag gambar untuk mendukungnya selama beberapa tahun terakhir adalah pemuatan yang lambat. Jadi dengan loading sama lazy, Anda tidak perlu lagi menggunakan library JavaScript untuk menambahkan lazy loading ke gambar Anda. Anda hanya menjatuhkan itu ke gambar Anda. Dan di browser chromium dan Firefox, Anda dapat dengan malas memuat gambar-gambar itu tanpa perlu menggunakan dependensi pihak ketiga. Dan itu juga cukup bagus.

Addy Osmani: Jadi, kami memiliki lazy loading. Kami mendapat dukungan untuk hal-hal lain seperti decoding sinkronisasi, tetapi saya akan terus melanjutkan dan berbicara dengan sangat cepat tentang dua metrik vital inti lainnya.

Drew McLellan: Lakukan , ya.

Addy Osmani: Jadi, singkirkan perubahan tata letak. Tidak ada yang suka hal-hal yang melompat-lompat di halaman mereka. Saya merasa, salah satu frustrasi terbesar saya adalah saya membuka halaman web. Saya mengarahkan jari saya ke tombol yang ingin saya klik, dan kemudian tiba-tiba sekelompok iklan atau gambar tanpa set dimensi atau hal-hal lain muncul. Dan itu menyebabkan pengalaman yang sangat tidak menyenangkan.

Addy Osmani: Jadi pergeseran tata letak kumulatif mencoba mengukur ketidakstabilan konten. Dan sering kali, hal umum yang mendorong perubahan tata letak Anda adalah gambar atau elemen lain di halaman Anda yang tidak memiliki set dimensi. Saya pikir itu adalah salah satu tempat di mana seringkali orang mudah mengatur dimensi gambar. Mungkin itu bukan sesuatu yang secara historis telah kami lakukan, tetapi tentu saja sesuatu yang layak untuk menghabiskan waktu Anda. Dalam alat seperti mercusuar akan mencoba membantu Anda mengumpulkan, seperti apa daftar gambar di halaman Anda yang membutuhkan dimensi? Jadi Anda bisa pergi dan Anda bisa mengaturnya.

Drew McLellan: Saya akan mengatakan, itu poin yang sangat menarik karena ketika desain web responsif menjadi suatu hal, kami semua menelusuri situs kami dan menghapus dimensi gambar karena alat yang kami miliki untuk membuat pekerjaan itu mengharuskan kami melakukannya. 't memiliki atribut tinggi dan lebar pada gambar kami. Tapi itu ide yang buruk sekarang, bukan?

Addy Osmani: Yang lama baru lagi. Saya akan mengatakan bahwa itu pasti layak untuk mengatur dimensi pada gambar Anda. Tetapkan dimensi pada iklan Anda, bingkai mata Anda, apa pun yang merupakan konten dinamis yang berpotensi berubah ukuran, layak untuk menetapkan dimensi.

Addy Osmani: Dan untuk orang-orang yang membangun pengalaman yang sangat menyenangkan di luar sana, ada ungkapan yang salah, pengalaman tata letak yang sangat menyenangkan di mana mungkin Anda perlu melakukan lebih banyak pekerjaan pada kartu responsif dan sejenisnya; Saya akan mempertimbangkan untuk menggunakan rasio aspek CSS atau kotak rasio aspek untuk memesan ruang Anda. Dan itu dapat melengkapi dimensi pengaturan pada gambar-gambar itu juga untuk memastikan bahwa segala sesuatunya diperbaiki mungkin ketika Anda mencoba untuk menghindari pergeseran tata letak Anda.

Addy Osmani: Dan kemudian, akhirnya Core Web Vital terakhir adalah penundaan input pertama. Ini adalah sesuatu yang orang tidak selalu pikirkan tentang gambar. Jadi sebenarnya mungkin saja gambar memblokir bandwidth dan CPU pengguna saat memuat halaman. Mereka dapat menghalangi bagaimana sumber daya penting lainnya dimuat, khususnya pada koneksi yang sangat lambat atau pada perangkat seluler kelas bawah yang dapat menyebabkan saturasi bandwidth.

Addy Osmani: Jadi, penundaan input pertama adalah metrik Core Web Vital yang menangkap, kesan pertama pengguna tentang interaktivitas dan daya tanggap situs. Jadi dengan mengurangi penggunaan CPU utas utama, penundaan input pertama Anda juga dapat diminimalkan. Jadi secara umum di sana, hindari gambar yang dapat menyebabkan pertikaian jaringan. Mereka tidak membuat pemblokiran. Tetapi mereka masih dapat secara tidak langsung memengaruhi kinerja rendering Anda.

Drew McLellan: Apakah ada yang bisa kita lakukan dengan gambar untuk menghentikannya membuat pemblokiran? Bisakah kita melepas browser pada fase awal itu untuk memungkinkan kita menjadi interaktif lebih cepat?

Addy Osmani: Saya pikir semakin penting akhir-akhir ini untuk memiliki pemahaman yang baik tentang urutan gambar optimal yang tepat untuk menampilkan sesuatu di paro atas. Saya tahu bahwa paruh atas adalah istilah yang kelebihan beban, tetapi seperti di port tampilan pertama pengguna. Sangat sering kami akhirnya mencoba meminta banyak sumber daya, beberapa di antaranya berupa gambar, yang sebenarnya tidak diperlukan untuk apa yang akan segera dilihat pengguna. Dan itu cenderung menjadi kandidat yang bagus untuk dimuat nanti dalam siklus hidup halaman, hal-hal hebat untuk dimuat dengan malas di tempat. Tetapi jika Anda meminta banyak gambar, seperti antrean banyak hal sejak awal, itu berpotensi berdampak.

Drew McLellan: Ya. Jadi, maksud saya, Anda menyebutkan lambat memuat gambar yang secara historis kami memerlukan perpustakaan JavaScript untuk melakukannya, yang memiliki kemundurannya sendiri, saya pikir, karena cara historis browser mengoptimalkan pemuatan gambar, di mana hampir tidak mungkin untuk menghentikannya memuat gambar , kecuali jika Anda tidak memberikan sumbernya. Dan jika Anda tidak memberikan sumbernya dan kemudian mencoba dan memperbaikinya dengan JavaScript setelahnya, jika JavaScript itu tidak berjalan, Anda tidak akan mendapatkan gambar. Jadi lazy loading, lazy loading asli adalah jawaban untuk semua itu.

Addy Osmani: Ya, tentu saja. Dan saya pikir ini adalah tempat di mana kami telah mencoba untuk meningkatkan di seluruh browser, pengalaman pemuatan lambat asli selama setahun terakhir. Seperti yang Anda ketahui, ini adalah salah satu fitur di mana kami mengirimkan sesuatu lebih awal dan kami dapat memanfaatkan percakapan dengan para pemimpin pemikiran di industri untuk memahami seperti, “Oh, hei, apa ambang batas yang sebenarnya Anda tetapkan secara manual jika Anda menggunakan ukuran malas atau Anda menggunakan perpustakaan pemuatan lambat JavaScript lainnya?” Dan kemudian kami menyetel ambang batas kami untuk mencoba mencapai tempat yang sedikit lebih dekat dengan apa yang Anda harapkan.

Addy Osmani: Jadi dalam banyak kasus, Anda bisa menggunakan pemuatan malas asli. Jika Anda membutuhkan sesuatu yang jauh lebih halus, jika Anda membutuhkan lebih banyak kontrol untuk dapat mengatur ambang batas pengamat persimpangan, titik ketika browser akan meminta sesuatu, kami biasanya menyarankan, pergi dan gunakan perpustakaan dalam kasus tersebut , hanya karena kami mencoba memecahkan kasus penggunaan 90%. Tapi 10% masih berlaku. Mungkin ada orang yang masih membutuhkan sedikit lebih banyak. Jadi, bagi kebanyakan orang, saya berharap pemuatan malas bawaan akan cukup baik di masa mendatang.

Drew McLellan: Yang terpenting, ini gratis. Atribut sederhana untuk ditambahkan, dan Anda mendapatkan semua fungsi ini secara gratis, yang sangat bagus. Jika ada satu hal yang pendengar kami dapat lakukan, pergi dan lakukan ke situs mereka untuk meningkatkan pengoptimalan gambar mereka, apakah itu? Di mana mereka harus mulai?

Addy Osmani: Tempat yang baik untuk memulai adalah memahami seberapa besar masalah ini untuk situs Anda. Saya akan pergi dan memeriksa mercusuar atau membayar wawasan kecepatan. Pergi dan jalankan di beberapa halaman Anda yang paling populer dan lihat saja apa yang keluar. Jika sepertinya Anda hanya memiliki satu atau dua hal kecil yang harus dilakukan, itu luar biasa. Mungkin Anda bisa meluangkan waktu di sana.

Addy Osmani: Jika ada banyak hal yang harus Anda lakukan, mungkin lihat peluang tertinggi yang Anda miliki di sana, hal-hal yang mengatakan, “Oh, hei, Anda dapat menghemat beberapa detik jika Anda melakukan yang satu ini. hal." Dan fokuskan energi Anda di sana untuk memulai.

Addy Osmani: Seperti yang telah kita bicarakan di sini, perkakas untuk format gambar modern menjadi lebih baik dari waktu ke waktu. CDN gambar pasti layak untuk dipertimbangkan. Tapi di luar itu, ada banyak langkah kecil yang bisa Anda ambil. Terkadang jika itu adalah situs yang cukup kecil, bahkan hanya membuka dan membuka Squoosh, meletakkan beberapa gambar Anda di sana bisa menjadi titik awal yang bagus.

Drew McLellan: Itu saran yang bagus. Sekarang saya tahu ini adalah publikasi yang luar biasa, tetapi saya benar-benar harus memberi selamat kepada Anda atas buku itu. Ini sangat komprehensif dan sangat mudah dicerna. Saya pikir itu bacaan yang sangat berharga.

Drew McLellan: Jadi saya telah mempelajari semua tentang pengoptimalan gambar. Apa yang kamu pelajari akhir-akhir ini, Addy?

Addy Osmani: Apa yang saya pelajari akhir-akhir ini? Sebenarnya, pada topik yang sedikit berbeda yang masih berkaitan dengan gambar, jadi ketika saya melakukan master saya di perguruan tinggi, saya benar-benar mendalami visi komputer dan mencoba memahami, bagaimana kita dapat mendeteksi bagian yang berbeda dari suatu gambar dan melakukan liar dan hal-hal menarik dengan mereka?

Addy Osmani: Dan masalah khusus yang telah saya gali baru-baru ini adalah saya telah melihat foto-foto diri saya ketika saya masih bayi atau anak-anak. Dan saat itu, banyak makanan yang akan diambil orang tua saya tidak harus di kamera digital. Mereka adalah Polaroid. Mereka sering kali berupa gambar beresolusi agak rendah. Dan saya ingin cara untuk dapat meningkatkannya. Jadi saya mulai menggali masalah ini lagi baru-baru ini. Dan itu membuat saya belajar lebih banyak tentang apa yang dapat saya lakukan di browser.

Addy Osmani: Jadi saya telah membuat beberapa alat kecil yang memungkinkan Anda, menggunakan pembelajaran mesin, menggunakan TensorFlow, menggunakan teknologi yang ada, mengambil gambar atau ilustrasi dengan resolusi yang relatif rendah, lalu meningkatkannya ke sesuatu yang kualitasnya jauh lebih tinggi. Jadi itu lebih baik daripada sekadar merentangkan gambar. Ini seperti benar-benar mengisi secara detail.

Addy Osmani: Dan itu menyenangkan. Saya telah belajar banyak tentang seberapa stabil perakitan web sekarang di seluruh browser, seberapa baik Anda dapat menggunakan beberapa ide ini untuk kasus penggunaan aplikasi desktop. Dan itu sangat menyenangkan. Jadi saya telah menggali banyak perakitan web baru-baru ini. Dan itu keren.

Drew McLellan: Lucu, bukan? Ketika sebuah teknologi datang, itu mengubah semua yang Anda ketahui. Kami selalu mengatakan bahwa di web, kami dapat membuat gambar lebih kecil. Tapi jika kita hanya punya gambar kecil, kita tidak bisa membuatnya lebih besar. Itu tidak mungkin. Tetapi sekarang kami memiliki teknologi yang, dalam banyak situasi, memungkinkan hal itu. Ini benar-benar menarik.

Drew McLellan: Jika Anda, pendengar yang baik, ingin mendengar lebih banyak dari Addie, Anda dapat menemukannya di Twitter di mana dia adalah @AddieOsmani dan temukan semua proyeknya ditautkan dari AddyOsmani.com. Buku "Pengoptimalan Gambar" tersedia baik secara fisik maupun digital dari Smashing sekarang di smashingmagazine.com. Terima kasih telah bergabung dengan kami hari ini, Addy. Apakah Anda memiliki kata-kata perpisahan?

Addy Osmani: Ada kata perpisahan? Saya memiliki sedikit kekhasan dari sejarah yang akan saya bagikan kepada orang-orang. Tim Berners-Lee mengunggah gambar pertama ke internet pada tahun 1992. Saya tidak yakin apakah Anda dapat menebak apa itu, tetapi Anda mungkin akan terkejut. Drew, apakah Anda punya tebakan?

Drew McLellan: Saya menebak seekor kucing.

Addy Osmani: Seekor kucing. Ini tebakan yang bagus, tapi tidak. Ini di CERN. Dan gambar itu sebenarnya dari sebuah band bernama Les Horribles Cernettes, yang merupakan band pop parodi yang dibentuk oleh sekelompok karyawan CERN. Dan musik yang akan mereka lakukan adalah seperti musik doo-wop. Dan mereka akan menyanyikan lagu-lagu cinta tentang colliders dan quirks dan nitrogen cair dan anti-materi mengenakan pakaian tahun enam puluhan, yang menurut saya indah dan acak.