Addy Osmani ile Çarpıcı Podcast 39. Bölüm: Görüntü Optimizasyonu

Bu bölüm, insanların herhangi bir platformda güçlü içerik deneyimleri sunmasına yardımcı olan Storyblok'taki sevgili arkadaşlarımız tarafından desteklendi: Kurumsal web siteleri, e-ticaret siteleri, mobil uygulamalar ve ekran görüntüleri. Teşekkür ederim!

Smashing Podcast'in bugünkü bölümünde, görüntü optimizasyonundan bahsediyoruz. 2021'de performanslı görüntüler için hangi adımları izlemeliyiz? Öğrenmek için uzman Addy Osmani ile konuştum.

Notları göster

• "Görüntü Optimizasyonu" Addy Osmani
• Twitter'da Addy
• Addy'nin kişisel web sitesi

Haftalık güncelleme

• Meet :has, Yerel bir CSS Üst Seçici (Ve Daha Fazlası)
  Adrian Bece tarafından yazıldı.
• Yakın Zamanda Keşfettiğim Üç Ön Uç Denetim Aracı
  Stefan Judis'in yazdığı
• Kullanışlı Ön Uç Kazan Plakaları ve Başlangıç ​​Kitleri
  Cosima Mielke tarafından yazıldı.
• Web Tasarımı İyi Yapıldı: Sesten Yararlanmak
  Frederick O'Brien'ın yazdığı
• CSS Yeterli Olmadığında: Erişilebilir Bileşenler İçin JavaScript Gereksinimleri
  Stephanie Eckles tarafından yazıldı.

Transcript

Drew McLellan: Ekibinin hıza odaklandığı ve web'in hızlı kalmasına yardımcı olduğu Google Chrome üzerinde çalışan bir mühendislik yöneticisidir. Açık kaynak topluluğuna adanmış, geçmişte yaptığı katkılar arasında Lighthouse, Workbox, Yeoman, Critical ve NVC yapmak yer alıyor. Bu nedenle, web performansını optimize etme yolunu bildiğini biliyoruz. Ama bir yazım hatası nedeniyle yardımcı rolde en iyi kadın oyuncu Oscar'ını kazanmak istediğini biliyor muydunuz? Ezici dostlarım, lütfen Addy Osmani'ye hoş geldiniz. Merhaba, Addy. Nasılsınız?

Addy Osmani: Eziyorum.

Drew McLellan: Bunu duymak güzel. Bugün sizinle internetteki görseller hakkında konuşmak istedim. Bu, son birkaç yılda şaşırtıcı miktarda değişiklik ve yeniliğin olduğu bir alandır ve Smashing için görüntü optimizasyonu hakkında çok kapsamlı bir kitap yazdınız. Şu anda “Görüntü optimizasyonu üzerine bir kitap yazmanın zamanı geldi mi?” diye düşünme motivasyonu neydi?

Addy Osmani: Bu harika bir soru. Görüntülerin onlarca yıldır web'in oldukça önemli bir parçası olduğunu ve beynimizin görüntüleri metinden çok daha hızlı yorumlayabildiğini biliyoruz. Ancak bu genel konu, zaman içinde giderek daha ilginç ve daha nüanslı olmaya devam eden bir konu. Ve insanlara her zaman bunun muhtemelen üçüncü veya dördüncü kitabım olduğunu söylerim. Hiçbir zaman kasıtlı olarak bir kitap yazmak için yola çıkmadım.

Addy Osmani: Bu kitaba görüntü optimizasyonu hakkında bir makale yazarak başladım ve zamanla yanlışlıkla bu konuda bir kitap yazdığımı fark ettim. Yaklaşık iki yıldır bu proje üzerinde çalışıyorduk. Ve o zaman bile, endüstri tarayıcıları geliştiriyor ve görüntüler ve görüntü formatları etrafında araçlar gelişiyor.

Addy Osmani: Ve bu kitabı yazdım çünkü kendimi tüm bu değişikliklerin üstünde kalmayı zor buldum. Ve düşündüm ki, "İyi bir web vatandaşı olacağım ve öğrendiğim her şeyi tek bir yerde takip etmeye çalışacağım, böylece diğer herkes bundan faydalanabilir."

Drew McLellan: Tarayıcıda pek çok performans optimizasyonu ile bence bu alanlardan biri, hızla değişen bir manzara, değil mi? Güncel ve en iyi uygulama olarak öğrendiğiniz bir teknikte, bir miktar teknoloji kayması meydana gelir ve sonra bunun aslında bir anti-kalıp olduğunu anlarsınız ve bunu yapmamalısınız. Ve bilginizi yüksek tutmaya çalışmak ve doğru makaleleri okuyup doğru şeyleri öğrendiğinizden ve iki yıl öncesinden bir şey okumadığınızdan emin olmak oldukça zor.

Drew McLellan: Bu yüzden, hepsini yetkili bir kaynaktan, iyi araştırılmış tek bir kitapta toplamak gerçekten muazzam.

Addy Osmani: Evet. Bir yazarın bakış açısından bile, editör ekibimiz için en ilginç şeylerden biri ve belki de en stresli şeylerden biri, bir bölüm verip bunun yapıldığını söylemekti. Ve iki hafta sonra, tarayıcıda bir şeyler değişecekti ve ben "Oh, bekle. Bir son dakika değişikliği daha yapmam gerekiyor."

Addy Osmani: Ama görüntü manzarası, geçen yıl bile oldukça gelişti. WebP desteğinin nihayet modern tarayıcıların çoğunda bitiş çizgisini geçtiğini gördük. AVIF görüntü desteği Chrome'da, Firefox'a geliyor, JPEG XL, tembel yükleme. Genel olarak, web'deki görüntüleri tarayıcılarda oldukça somut bir şekilde nasıl kullanabileceğinize ilişkin geliştirmeler gördük. Ama yine de, insanların üstesinden gelmesi gereken çok şey var.

Drew McLellan: Bazı insanlar görüntü optimizasyonu konusunu oldukça ağırbaşlı bir konu olarak görebilir. Hepimiz, kariyerimizin bir noktasında, grafik yazılımımızdan web için nasıl dışa aktarılacağını öğrenmişizdir. Ve bazılarımız, dışa aktarılan bu görüntüleri alıp onları ImageOptim gibi bir şeyle çalıştırma alışkanlığına sahip olabilir.

Drew McLellan: Bu nedenle, fotoğrafik bir görüntü olduğunda bir JPEG ve grafik tabanlı bir görüntü olduğunda bir PNG seçmemiz gerektiğini biliyor olabiliriz ve “Tamam, bu kadar. Görüntü optimizasyonunu biliyorum, işim bitti.” Ama gerçekten, bunlar sadece masa bahisleri, değil mi, bu noktada?

Addy Osmani: Evet, öyleler. Sanat yönetmenliğini önemseyip önemsememenize bağlı olarak, farklı bir bağlamda bile daha ayrıntılı, daha net görüntüler ve görüntüler gösterebilme yeteneğimizin zaman içinde geliştiğini düşünüyorum. Ortamlarını, cihaz kısıtlamalarını, ağ kısıtlamalarını göz önünde bulundurarak, bu görüntülerin son kullanıcılarınız için amaçlandığı kadar güzel görünmesini nasıl sağlayabileceğinizi bulma ihtiyacının zor bir problem olduğunu ve birçok insanı hala tanıdığım bir şey olduğunu düşünüyorum. ile mücadele.

Addy Osmani: Ve iş, görseller hakkında düşünmeye ve "Hey, hadi bir JPEG kullanalım" veya "Hadi bir PNG kullanalım"ın ötesinde biraz daha rafine bir yaklaşıma gelince, bence bu değerin birkaç boyutu var. Aklında tut. Birincisi sadece genel olarak sıkıştırmadır. ImageOptim'den bahsettiniz ve çoğumuz bir görüntüyü bir yere sürükleyip arkasından daha küçük bir şey almaya alışkınız.

Addy Osmani: Şimdi, sıkıştırma söz konusu olduğunda, genellikle farklı kodlayıcılardan bahsediyoruz. Codec'ler, genellikle dosyaları kodlamak için bir kodlayıcı bileşenine ve bunların kodunu çözmek ve sıkıştırmasını açmak için bir kod çözücü bileşenine sahip olan bir sıkıştırma teknolojisidir. Ve bir şey kullanıp kullanmadığınıza karar verdiğinizde, genellikle kullandığınız fotoğrafların veya görüntülerin kayıplı bir sıkıştırma yaklaşımı veya kayıpsız bir yaklaşım kullanarak yaklaşmanız için uygun olup olmadığını düşünmeniz gerekir.

Addy Osmani: İnsanların bu kavramlara gerçekten aşina olmaması durumunda, kayıpsız bir yaklaşım, aynı dosyayı açmanın ardından en sonunda yeniden oluşturduğunuz bir yaklaşımdır. Yani kalite yolunda pek bir şey kaybetmiyorsunuz. Kayıpsız, görüntünüzü bir faks makinesinden geçirmekten çok daha fazlasıdır. Orijinalin bir faksını alırsınız ve bu orijinal dosya olmayacaktır. Orada bazı farklı eserler olabilir. Biraz farklı görünebilir. Ancak genel anlamda, ne kadar çok sıkıştırırsanız, tipik olarak o kadar çok kalite kaybedersiniz.

Addy Osmani: Ve tüm bu modern görüntü kodekleriyle, kullanım durumuna bağlı olarak nispeten iyi bir dosya boyutunu korurken ne kadar kaliteyi sıkıştırabileceğinizi görmeye çalışıyorlar.

Drew McLellan: Yani gerçekten, teknoloji açısından, bir kaynak görüntünüz var ve ardından hedef dosya biçiminiz var. Ancak birinin diğerine dönüşme süreci tartışmaya açıktır. Uyumlu bir dosyanız olduğu sürece, bunu nasıl yapacağınız çok sayıda farklı uygulamaya sahip olabilen bir codec bileşenine bağlıdır ve bazıları diğerlerinden daha iyi olacaktır.

Addy Osmani: Kesinlikle. Kesinlikle. Ve yine JPEG ve PNG ile başladığımız yere dönersek, insanlar JPEG'in fotoğrafların kayıplı bir şekilde sıkıştırılması için yaratıldığını biliyor olabilirler. Genellikle arkasından daha küçük bir dosya alırsınız ve bazen farklı bantlama artefaktları olabilir. PNG, orijinal olarak kayıpsız bir sıkıştırma için yaratılmıştır, fotoğrafik olmayan görüntülerde oldukça başarılıdır.

Addy Osmani: Ama o zamandan beri işler gelişti. 2010 civarında, JPEG ve PNG'nin yerini alması beklenen ve sıkıştırmada onları biraz geride bırakan WebP için destek almaya başladık. Ancak tablodaki görüntü biçimlerinin ve seçeneklerin sayısı o zamandan beri hızla arttı. Özellikle AVIF ve JPEG XL gibi modern formatlarda işlerin genel olarak iyi bir yöne gittiğini düşünüyorum. Ama buraya gelmemiz biraz zaman aldı. Tüm tarayıcılarda WebP desteği almak bile oldukça zaman aldı.

Addy Osmani: Ve bence sonuçta, geliştiricilerin bunu talep ettiğinden, bu modern formatlardan daha iyi sıkıştırma elde edebilmek için bir iştahları olduğundan ve yalnızca tarayıcılar arasında iyi bir uyumluluğa sahip olma arzusu olduğundan emin olmak onu salladı. bu işler için de.

Drew McLellan: Evet. WebP benim için gerçekten ilginç görünüyor, çünkü format içinde kayıpsız ve kayıplı sıkıştırmaya sahip olmanın yanı sıra, sonuç olarak açıkçası çok daha küçük bir dosya boyutuna sahibiz. İyi bir tarayıcı desteği var ve Google ve Netflix gibi büyük şirketler ile çeşitli büyük şirketler tarafından benimsendiğini görüyoruz.

Drew McLellan: Ancak sektördeki algım, taban düzeyinde aynı türden bir alım görmediğimiz yönünde. WebP hala gününün gelmesini mi bekliyor?

Addy Osmani: Sanırım WebP'nin geldiğini söyleyebilirim. Pek çok kişi Safari ve WebKit desteğinin gerçekleşmesini bekliyordu ve sonunda buna kavuştuk. Ancak yeni görüntü formatlarını düşündüğümüzde, desteğin gerçekte ne anlama geldiğini anlamamız çok önemlidir. Bu görüntülerin kodunu çözmek için tarayıcı desteği var. Ayrıca, gerçekten iyi bir araç desteğine ihtiyacımız var, böylece ister bir düğüm ortamında, ister görüntü CDN'sinde olun, ister bir CMS'de olun, bu görüntü biçimlerini kullanma becerisine sahip olursunuz.

Addy Osmani: Yıllar önce WebP'nin ilk çıktığı zamanı hatırlıyorum. İlk benimseyenler, WebP dosyanızı masaüstünüze kaydetmeniz ve ardından aniden “Ah, bekleyin. Bunu görüntülemek için tarayıcıma sürüklemem gerekiyor mu?” veya “Kullanıcılarım WebP'yi indiriyorsa, takılıp kalacaklar ve neler olduğunu merak edecekler mi?”

Addy Osmani: Bu nedenle, hem işletim sistemi düzeyinde hem de diğer bağlamda görüntü formatı için oldukça bütünsel bir desteğin olduğundan emin olmak, bence, bir görüntü formatının başarılı olması için gerçekten önemli. Görüntüleri sunan kişilerin bu kullanım durumları hakkında biraz düşünmeleri de önemlidir, böylece bir dosyayı kaydediyor veya indiriyorsam, onu insanların genellikle kolayca paylaşabileceği taşınabilir bir biçime koymaya çalışıyorsunuz. Ve bence burası, en azından iOS'ta iOS'un bir zam ve kısa çizgi için desteği aldığı yer. Ve gerektiğinde şeyleri JPEG'e dönüştürmek, insanların bunları paylaşmasına izin verir.

Addy Osmani: Dolayısıyla, kullanıcılara daha iyi sıkıştırma sunarken kaybetmemelerini sağlayabileceğimiz bu tür kullanım durumları üzerinde düşünmek bence önemli.

Drew McLellan: Çalıştırdığım ve tahmin edebileceğiniz gibi yüz binlerce görüntüyle ilgilenen bir slayt paylaşım hizmetim var. WebP'ye bakarken ve bu muhtemelen üç yıl önceydi, öncelikle CDN bant genişliği maliyetlerini düşürmenin bir yolunu arıyordum, çünkü daha küçük bir dosya sunuyorsanız, onu sunmak için daha az ücret alıyorsunuz. Ancak yine de eski bir görüntü formatı olan tam bir görüntüye ihtiyacım olsa da, hesaplamalarım, başka bir görüntü setinin tamamını depolama maliyetinin, daha küçük bir dosya sunmanın yararlarından daha ağır bastığını gösterdi. Yani 2021 yılındayız. Bu, bu noktada yeniden düşünmem gereken bir karar mı?

Addy Osmani: Bence bu gerçekten önemli bir düşünce. Bazen, imaj stratejinize nasıl yaklaşmanız gerektiği hakkında konuştuğumuzda, insanlara yüksek seviyeli bir cevap vermek çok kolaydır, “Hey, evet. Sadece beş farklı format oluşturun ve bu sonsuz bir şekilde ölçeklenecektir.” Ve bu her zaman böyle değildir.

Addy Osmani: Depolamayı aklınızda tutmanız gerektiğinde, bazen kullanıcılarınıza hizmet etmek için en iyi, en yaygın paydanın ne olduğunu bulmaya çalışmanın akılda tutulması gerektiğini düşünüyorum. Bugünlerde aslında WebP'nin bu ortak payda olarak değerlendirilmeye değer olduğunu söyleyebilirim. İnsanlara farklı biçimleri koşullu olarak sunmak için resim etiketini kullanmaya alışmış kişiler için, ana yedeğiniz olarak genellikle bir JPEG kullanırsınız. Belki de bu günlerde, çok çok eski tarayıcılarda olan insanlar olmadıkça, çoğu kullanıcı için yedeğiniz olarak WebP'yi kullanmak sorun değil. Ve sanırım bu günlerde bunu çok daha az görüyoruz. Ama orada kesinlikle biraz esnekliğin var.

Addy Osmani: Şimdi, ileriye dönük olmaya çalışıyorsanız, gerçekten iyi çalıştığını düşündüğünüz bir format seçin derim. Depolamaya ihtiyaçlarınıza göre ölçeklenen ve esnek bir şekilde yaklaşabilirseniz, insanların yapması gerektiğini söyleyeceğim şey JPEG XL'yi düşünmektir. Henüz bir tarayıcıda teknik olarak gönderilmiyor. Bunu yaptığında, JPEG XL, kayıplı veya kayıpsız kullanım durumlarında veya fotoğraf dışı kullanım durumlarında çok sayıda fotoğraf için oldukça harika bir seçenek olmalıdır. Ve muhtemelen WebP V1'den çok daha iyi olacak. Yani bir yer.

Addy Osmani: Gerçekten düşük bit hızlarına gitmeniz gerekiyorsa, AVIF'in muhtemelen daha iyi olacağını düşünüyorum. Belki de bant genişliğine çok önem veriyorsunuz. Belki de görüntü doğruluğuna biraz daha az önem veriyorsunuz. Ve bu bit hızlarında, bazı alternatiflerden daha canlı göründüğünü hayal edebiliyorum. Ve elimizde JPEG XL olana kadar, analizlerinize bir göz atmaya ve AVIF sunmanızın mümkün olup olmadığını anlamaya çalışırdım. Aksi takdirde, o WebP'ye odaklanırdım. Analitik olsaydınız, sanırım çoğu insana WebP sunulabilir ve geniş gamut veya metin bindirmeleri, kromozom örneklemenin WebP'de mükemmel olmayabileceği yerler hakkında biraz daha az umursuyorsunuz. Bu kesinlikle akılda tutulmaya değer bir şey.

Addy Osmani: Bu yüzden herkese uyan tek bir beden olmayacağını akılda tutmaya çalışırdım. Ben şahsen bu günlerde, sadece bir imaj CDN'si kullandığım için depolama, çıkış ve bant genişliği maliyetleri konusunda biraz daha az endişeleniyorum. Ve kişisel olarak Cloudinary kullandığımı söylemekten mutluyum. Çalıştığım yerde birçok farklı görüntü CDN'si kullanıyoruz. Ancak, görüntü ardışık düzenleriyle uğraşmanın bakım maliyetleri hakkında çok fazla endişelenmeme gerek olmadığını, "Oh, hey, işte başka bir görüntü formatı veya yeni türde yedekler veya yeni web API'leri" gibi nasıl destekleyeceğimle uğraşmama gerek olmadığını fark ettim. ” Bu, benim için sadece onunla ilgilenen bir şeye yatırım yapmak için güzel bir avantaj oldu.

Addy Osmani: Ve sonra kullanım durumlarım için toplam maliyet tamam oldu. Ancak, bu ölçekte bir slayt hizmeti çalıştırıyorsanız, bunun da bir seçenek olmayabileceğini tamamen hayal edebiliyorum.

Drew McLellan: Evet. Bu yüzden gelecekteki bu formatlardan bazılarına geri dönmek istiyorum. Ancak bence bu araştırmaya değer, çünkü herhangi bir tür performans aracıyla, Lighthouse veya WebPageTests ile, herhangi birimiz sitelerimizi bunun üzerinden çalıştırırsa, önereceği en önemli şeylerden biri, görüntüler için bir CDN kullanmamızdır. Ve bu çok büyük şirketler için çok gerçekçi bir şey. Gerçekçi mi ve daha küçük web siteleri ve uygulamalar oluşturan insanların erişebileceği bir yerde mi, yoksa yapması göründüğü kadar kolay mı?

Addy Osmani: Bence insanların sorması gereken soru, "Görüntüleri ne için kullanıyorsunuz?" Yalnızca birkaç görseliniz varsa, bir blog oluşturuyorsanız ve eklediğiniz görseller nispeten basitse, yüzlerce, yüzlerce veya binlerce görseliniz yoksa, sadece buna yaklaşmanız sorun olmayabilir. derleme zamanında, çok statik bir şekilde, birkaç NPM paketi kurduğunuz yerde. Belki de sadece Sharp kullanıyorsunuzdur. Ve bu çoğunlukla seninle ilgilenir.

Addy Osmani: Birden çok format oluşturmanıza yardımcı olabilecek araçlar var. Oluşturma sürenizi biraz artırır, ancak bu aslında birçok insan için iyi olabilir. Ve sonra birden fazla avantajdan yararlanmak isteyen insanlar için-

Addy Osmani: Ve sonra, birden fazla formattan yararlanmak isteyen insanlar için, takım ayrıntılarının çoğuyla uğraşmak istemiyorlar ve gerçekten zengin bir duyarlı görüntü veya hikaye elde edebilmek istiyorlar. bir görüntü CDN'sini deneyin derim. Şahsen, başlangıçta maliyet endişeleri için kişisel projeler için kullanma konusunda oldukça çekingendim ve daha sonra faturama bir göz attığımda, aslında, aksi takdirde bu sorunları kendim çözmeye yatırım yapacağımın bana zaman kazandırdığını fark ettim. Geçmişte resimlerinizle uğraşmak için özel komut dosyaları yazmak için ne kadar ihtiyacınız olduğunu bilmiyorum ama fark ettim ki, kendimi bu farklı npm paketleriyle ayda en az birkaç gün hata ayıklamadan kurtarabilirsem, sonra maliyetler Bir nevi biriktirdiğim zamana dikkat et ve bu yüzden sorun değil.

Addy Osmani: Ancak bu, 1000'lerin 100'lerine veya milyonlarca görüntüye ölçekleniyorsanız ve bu mutlaka gelirinizin kapsadığı bir şey değilse veya ödemeye hazır olduğunuz bir şey değilse, üzerinde düşünmeniz gereken bir şey olabilir. alternatif stratejiler. Ve bence, bugün bize sunulan araçlarla, bu yönlerden herhangi birine gidebilmek için yeterli esnekliğe sahip olduğumuz için şanslıyız, burada biraz daha özel bir şey yapıyoruz, kendimiz hallediyoruz veya yuvarlanıyoruz kendi imaj CDN'miz veya biraz daha ticari bir şeye yatırım yapıyoruz. Ve bazı kullanım durumları için evet diyebileceğim bir yerdeyiz, evet bir görüntü CDN'si kullanabilirsiniz ve bu ekonomiktir.

Drew McLellan: Sanırım, yol gösterici ilkelerden biri her zaman çevik olmak ve değişime hazırlıklı olmaktır. Ve görüntülerinizi istendiğinde sizin için dinamik olarak dönüştürmek için bir görüntü CDN'si kullanmaya başlayabilirsiniz ve bu, maliyet açısından sürdürülebilir olmadığı bir noktaya gelirse, başka bir çözüme bakabilir ve kod tabanınızı bir duruma getirebilirsiniz. bir çözümü diğeriyle ikame etmenin kolay olacağı yer. Bence genel olarak ve üçüncü taraf bir hizmete güvendiğiniz her yerde, bu iyi bir ilkedir, değil mi? Bu yaklaşan görüntü formatları, JPEG XL'den bahsettiniz. JPEG XL nedir? Nereden geldi? Ve bizim için ne yapar?

Addy Osmani: Bu harika bir soru. Yani JPEG XL yeni nesil bir görüntü formatıdır, genel amaçlı olması gerekir ve JPEG komitesinden bir kodlayıcıdır. Google'ın resim biçimindeki bazı köklerle ve ardından Cloudinary'nin FUIF biçiminde başladı. Yıllar boyunca bu çabanın bir nevi kapsadığı pek çok format olmuştur, ancak bu, tek tek parçalarının toplamından çok daha fazlası haline geldi ve JPEG XL'in bazı faydaları, yüksek doğruluk için harika olmasıdır. görüntüler, kayıpsız için gerçekten iyi, aşamalı kod çözme, kayıpsız JPEG kod dönüştürme desteği var ve aynı zamanda bir tür yaygara ve telifsiz, bu kesinlikle bir avantaj. JPEG XL'nin potansiyel olarak gerçekten güçlü bir aday olabileceğini düşünüyorum. Daha önce konuşuyorduk, sadece birini seçecek olsaydın ne kullanırdın? Ve bence JPEG XL'nin o olma potansiyeli var.

Addy Osmani: Ayrıca fazla söz vermek istemiyorum, tarayıcı desteği konusunda henüz çok erkendeyiz. Bu yüzden gerçekten bekleyip görmemiz, denememiz ve pratikte ne kadar iyi olduğunu ve insanların beklentilerini karşıladığını değerlendirmemiz gerektiğini düşünüyorum ama hem kayıplı hem de kayıpsız durumlar için JPEG XL ile çok fazla potansiyel görüyorum. Şu anda, Chrome'un destek açısından muhtemelen en ileride olduğuna inanıyorum, ancak Mozilla tarafının ve diğer tarayıcıların buna kesinlikle ilgi gösterdiğini gördüm, bu yüzden JPEG XL ile gelecek için heyecanlıyım. Ve eğer insanlar için daha kısa vadeli ilginin ne olduğunu söyleyecek olursak? Bir de AVIF var tabii.

Drew McLellan: Bize AVIF'den bahset, bu da aşina olmadığım başka bir şey.

Addy Osmani: Tamam. Bu nedenle, düşük bit hızlarına gitmeniz gerekiyorsa ve bant genişliğine görüntü doğruluğundan daha fazla önem veriyorsanız, AVIF'in belki daha iyi bir aday olabileceğinden biraz daha önce bahsettik, genel bir ilke olarak, AVIF gerçekten düşük doğrulukta yüksek çekicilik sıkıştırmasında başı çekiyor. Ve JPEG XL, orta ila yüksek doğrulukta mükemmel olmalıdır, ancak kendi haklarında biraz farklı biçimlerdir. AVIF'in giderek daha iyi tarayıcı desteğine sahip olduğu bir noktadayız, ancak bir adım geri atıp format hakkında biraz daha konuşmama izin verin. Dolayısıyla AVIF'in kendisi, Alliance for Open Media tarafından standartlaştırılmış AV1 video codec bileşenine dayanmaktadır ve insanlara daha önce bahsettiğimiz WebP üzerinden JPEG üzerinden önemli sıkıştırma kazanımları sağlamaya çalışır. AVIF'ten elde edebileceğiniz tam tasarruf, içeriğe ve kalite hedeflerinize bağlı olsa da, JPEG'e kıyasla %50'nin üzerinde tasarruf sağlayabildiği birçok durum gördük.

Addy Osmani: Pek çok iyi özelliği var, size yüksek dinamik aralık ve geniş renk gamları, film gren sentezi gibi yeni özellikler için kap desteği sağlayabiliyor. Ve yine, ileriye dönük olmaktan bahsetmeye benzer şekilde, resim etiketiyle ilgili güzel şeylerden biri, kullanıcılara AVIF dosyalarını şu anda sunabilmeniz ve mutlaka desteklenmediği durumlarda yine de WebP'nize veya JPEG'inize geri dönecek olmasıdır. . Ancak Photoshop Save For Web ile ilgili örneğinize geri dönersek, 500 kilobayt boyutunda bir JPEG alabilir, Photoshop Save For Web ile benzer kalitede çekim yapmayı deneyebilirsiniz ve AVIF ile muhtemelen bu dosya boyutunun yaklaşık 90 kilobayt olduğu nokta, 100 kilobayt yani kayda değer bir kalite kaybı olmadan oldukça fazla tasarruf.

Addy Osmani: Ve bununla ilgili güzel şeylerden biri, ideal olarak zengin ayrıntılara sahip hiçbir görüntüde doku kaybı görmeyeceksiniz. Bu nedenle, orman, kamp veya bu tür şeylerden herhangi birine ait fotoğraflarınız varsa, yine de AVIF ile gerçekten zengin görünmeleri gerekir. Bu yüzden AVIF'in sahip olduğu yön konusunda oldukça heyecanlıyım. Takım desteği açısından biraz daha çalışmaya ihtiyacı olduğunu düşünüyorum. Geçen gün bununla ilgili bir tweet attım, şu anda AVIF kullanmak için bir dizi seçeneğimiz var, tek görüntüler için Squoosh, squoosh.app, Chrome'da başka bir ekip tarafından yazılmış, bu yüzden bağırın Squoosh üzerinde çalıştıkları için Surma ve Jake'e. Avif.io, hangi teknoloji yığınına odaklandıklarına bakılmaksızın, bugün AVIF'i kullanmaya çalışan kişiler için bir dizi iyi seçeneğe sahiptir, Sharp da AVIF'i destekler.

Addy Osmani: Ama sonra genel olarak, ister Figma'da, ister Sketch'te, ister Photoshop'ta veya başka yerlerde olsun, görüntülerle uğraştığımız diğer yerleri düşünürsünüz ve ben hala biraz çalışmamız gerektiğini söyleyebilirim. AVIF orada destek veriyor, çünkü geliştiricilerin ve kullanıcıların gerçekten indiğini ve eve geldiğini hissetmeleri için her yerde olması gerekiyor. Ve şu anda Chrome'da AVIF üzerinde çalışan ve takımları oldukça iyi bir yere getirebileceğimizden emin olmaya çalışan ekiplerle birlikte odaklandığımız alanlardan biri de bu.

Drew McLellan: Böylece, geleneksel resim etiketine göre bize daha fazla esneklik sağlayan resim öğesi olan HTML'ye sahibiz. Resim etiketi de epey yol kat etmiş olsa da, değil mi? Ancak resmin eklendiğini gördük, yerel video etiketiyle aynı zamandaydı, sanırım bu tür orijinal HTML5 değişiklikleri grubunda. Bu da bize birden fazla kaynak belirleme yeteneği veriyor, değil mi?

Addy Osmani: Evet, doğru.

Drew McLellan: Böylece farklı görüntü formatlarını listeleyebilirsiniz ve tarayıcı desteklediğini seçecektir ve bu, eski tarayıcıları olan insanlar için işleri bozma konusunda çok fazla endişelenmemize gerek kalmadan hemen oldukça deneysel olmamızı sağlar.

Addy Osmani: Kesinlikle. Bence bu, yönümüzü düşündüğümüz kullanım durumlarının dışında resim etiketini kullanmanın en güzel faydalarından biri, sadece insanlara bir resim sunabilmek ve tarayıcının potansiyel kaynaklar listesinden geçmesini ve görmesini sağlamak, tamam, Pekala, o listede anladığım ilkini kullanacağım, yoksa geri döneceğim, bu millet için gerçekten güçlü bir yetenek. Aynı zamanda, bazı insanların, biz birden fazla formatı desteklemeye çalışırken ve siz bu formatlar için farklı boyutları hesaba katarken, gerçekten çok büyük işaretleme blokları oluşturduğumuza dair bazı endişelerini veya endişelerini dile getirdiklerini duydum. aniden biraz hantallaşıyor.

Addy Osmani: Peki bu sorunlara yaklaşmanın başka yolları var mı? İnsanları görüntü CDN'lerinde çok fazla satmak istemiyorum, kendi başlarına durmalarını istiyorum. Ancak burası, içerik müzakeresi adı verilen bir fikrin size gerçekten ilginç bir yol sunabileceği yerlerden biri. Bu yüzden, bir sürü farklı kaynak oluşturmanız ve tercih sırasına, doğru, ekstra HTML'ye karar vermeniz gereken resim etiketi hakkında biraz konuştuk. İçerik görüşmesinde, tüm bu işleri sunucuda yapalım diyor. Böylece istemciler, Kabul HTTP başlığı aracılığıyla MIME türleri listesi aracılığıyla sunucuya hangi biçimleri desteklediğini önceden söyleyebilir. Daha sonra sunucu, nihai kaynakları oluşturma ve yönetme ve hangilerinin istemcilere gönderileceğine karar verme gibi tüm ağır işleri yapabilir. Ve buradaki güçlü şeylerden biri, bir görüntü CDN'si kullanıyorsanız, tek bir kaynağa işaret edebilirsiniz.

Addy Osmani: Yani, eğer elimizde yavrusu, JPEG gibi bir köpek yavrusu resmimiz varsa, insanlara yavru.JPEG'in bir URL'sini verebiliriz ve eğer tarayıcıları WebP'yi veya bir AVIF'i destekliyorsa, sunucu sağdan hizmet verme konusunda gerçekten akıllı olabilir. desteklerinin nasıl göründüğüne bağlı olarak bu kullanıcılara görüntü verin, ancak aksi takdirde kendiniz bir ton ekstra iş yapmanıza gerek kalmadan geri çekilin. Şimdi, bunun güçlü bir fikir olduğunu düşünüyorum. Sunucuda yapabileceğiniz çok şey var, bazen herkesin gerçekten güçlü ağ kalitesine nasıl erişemediğinden bahsediyoruz, etkili bağlantı türünüz nerede olduğunuza bağlı olarak gerçekten farklı olabilir.

Addy Osmani: Silikon Vadisi'nde yaşasam bile bir kafeden otele yürüyor olabilirim ya da arabada olabilirim ve wifi bağlantımın veya sinyalimin kalitesi o kadar iyi olmayabilir. Bu nedenle, diğer API'lere, kullanıcı veri tasarrufunu seçtiyse, insanlara daha küçük boyutlu kaynaklarda bile hizmet verebilme potansiyeline ilişkin Save-Data istemci ipucu gibi diğer fikirlere buradan erişebilirsiniz. Bu yüzden sunucu tarafında yapabileceğimiz pek çok ilginç şey var ve bence piyasa yolunu yapmakta rahat olan insanların bunu yapmak için tüm esnekliğe sahip olduğu güzel bir denge bulma fikirlerini zorlamaya devam etmeliyiz. ve biraz daha sihirli bir çözüm isteyenlerin de birkaç seçeneği var.

Drew McLellan: Bu tür bir veri tasarrufu yaklaşımı kavramı ilk olarak kitabınızdan öğrendiğim bir şeydi. Demek istediğim, hadi buna biraz daha girelim çünkü bu oldukça ilginç. Yani, tarayıcının, belki de ölçülü bir bağlantıda olduğu veya düşük pili olduğu veya başka bir şey olduğu için azaltılmış bir veri deneyimi istemek için bir tercih sinyali verebildiğinden bahsediyorsunuz.

Addy Osmani: Aynen. Kesinlikle. Çok daha fazla seyahat edeceğimiz normal zamanlarda veya önceki zamanlarda seyahat ediyordum, dünyada birçok yer veya ağ kalitemin gerçekten düşük veya gerçekten sivilceli olabileceği durumlar yaşadım ve hatta açılış bir web sayfasını açmak sinir bozucu veya zor bir deneyim olabilir. Bir menüye bakıyor olabilirim ve ellerindeki güzel yemeklerin resimlerini göremezsem, gidebileceğim bir yere gidebilirim ya da bilmiyorum, bunun yerine kendime yemek yapabilirim. Ancak veri tasarrufuyla ilgili ilginç şeylerden birinin, kullanıcının tercihlerinin ne olduğu konusunda size bir bağlantı sağlaması olduğunu düşünüyorum. Yani bir kullanıcı olarak ağ bağlantımla ilgili sorun yaşadığımı biliyorum. "Tamam, peki, tarayıcımda veri tasarrufu modunu seçeceğim" diyebilirim.

Addy Osmani: Ve sonra bunu bir geliştirici olarak, "Tamam, peki, kullanıcı biraz kısıtlı, belki onları çok daha küçük resimlerde veya çok daha düşük kalitede resimlerde gezineceğiz" demek için bir sinyal olarak kullanabilirsiniz. Ama yine de bazı görüntüler görebiliyorlar, bu da çok daha zengin bir şeyin sunulması için çok uzun bir süre beklemekten daha iyi. Bu tür sinyallerin diğer faydaları, bunları koşullu olarak medya sunmak için kullanabilmenizdir. Belki o sayfada metnin en önemli şey olduğu durumlar olabilir, belki de kullanıcıların kısıtlı bir ortamda olduğunu keşfederseniz bu resimleri kapatabilirsiniz. Bunun için yalnızca 30 saniye harcayacağım, ancak bu fikri gerçekten aşırı uçlara itebilirsiniz. Save-Data ile yapabileceğiniz ilginç şeylerden bazıları, belki de JavaScript'te uygulanan çok maliyetli özellikleri kapatmaktır.

Addy Osmani: Biraz daha isteğe bağlı olarak kabul edilen belirli bileşenleriniz varsa, yalnızca deneyimi geliştiriyorlarsa, bunların tüm kullanıcılara gönderilmesi gerekmeyebilir. Yine de herkese çok temel, küçük, hızlı bir deneyim sunabilir ve ardından daha hızlı bir bağlantısı veya aygıtı olan insanlar için güzel bir buzlanma ile katmanlayabilirsiniz.

Drew McLellan: Potansiyel olarak, sayfa numaralandırmayı hesaba katabilir ve bir sayfada 100 yerine 10 sonuç ve bu tür şeyler döndürebilirsiniz. Çok ilginç, ilginç yetenekler var. Sanırım hepimiz yeni bir site hazırlamanın, tüm resimlerinizi optimize etmenin, müşteriye teslim etmenin, içeriği yönetmeleri için onlara bir CMS vermenin ve her şeyi yenileriyle değiştirdiklerini bulmanın sinir bozucu sürecine aşinayız. kötü optimize edilmiş görüntüler. Demek istediğim, yine, bir görüntü CDN'si, sanırım, bunun için gerçekten uygun bir çözüm olurdu, ancak başka çözümler var mı, buna yardımcı olmak için CMS'nin sunucuda yapabileceği şeyler var mı, yoksa bir görüntü CDN'si mi? Gitme zamanı?

Addy Osmani: Sanırım en az altı ya da yedi yıl boyunca herkesin görüntülerini optimize etmesini sağlamaya çalıştıktan sonra keşfettiğimiz şey, resimde yer alan bazı kişilerin teknik açıdan biraz daha bilgili ve belki de rahat bir ortam olabileceği zor bir sorun olduğudur. Kendi araçlarını oluşturmak veya Lighthouse'u çalıştırmak ve çalıştırmak veya iyileştirme fırsatları olup olmadığını bildirmek için diğer araçları denemek. Daha fazla optimize etme veya doğru boyutta görseller sunma fırsatınız varsa, insanların sürekli olarak Deniz Feneri gibi şeyleri kullandıklarını görmek isterim, ancak bunun ötesinde, bazen görsel yükleyen kişilerin kullanamadığı durumlarla karşılaşıyoruz. hatta yükledikleri kaynakların maliyetini mutlaka anlayın. Bu genellikle karşılaştığımız bir şeydir ve özür dilerim, insanları çok fazla aramayacağım, ancak bu, Google blogunda bile karşılaştığımız bir şey.

Addy Osmani: Google blogunda her birkaç haftada bir, birilerinin 20 veya 30 megabaytlık çok büyük bir animasyonlu GIF yüklemesini sağlayacağız. Ve onların bunun iyi bir fikir olmadığını bilmelerini beklemiyorum, makaleyi havalı, çok ilgi çekici ve etkileşimli göstermeye çalışıyorlar, ancak bu izleyicilerin gidip araçları çalıştırmayı veya ImageOptim'i kullanmayı bilmeleri gerekmiyor. veya bu diğer araçlardan herhangi birini yerinde kullanmak ve kontrol etmeleri için onlar için belgelemek kesinlikle bir seçenektir. Ancak sorunu otomatik hale getirebilmek bence çok zorlayıcı ve teknik veya teknik olmayan tüm CMS kullanıcılarımızın ihtiyaçlarını da umarız dengelediğimiz bir yere sürekli olarak ulaşmamıza yardımcı oluyor. kullanıcılarımızın ihtiyaçları olarak.

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? What can we do?

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: Yani bir yemek tarifi sitesine girmeye çalışıyorsam, o tarifin nasıl göründüğüne önem verebilirim ve bu yüzden tarifin o büyük kahraman görüntüsünün benim için görünür olmasını önemsiyoruz. Şimdi, LCP öğesi zamanla değişebilir. Yüklemenin başlarında, en büyük şeyin bir başlık olması çok olasıdır, ancak sayfa yüklenmeye devam ettikçe, aslında çok daha büyük bir resim veya bir tür poster olabilir.

Addy Osmani: Dolayısıyla, en geniş içerikli boyayı optimize etmeye çalıştığınızda yapabileceğiniz yaklaşık dört şey var. İlk şey, anahtar kahraman imajınızı mümkün olduğunca erken talep ettiğinizden emin olmaktır. Genel olarak, sayfada önemli olan birkaç şeye sahibiz. Ana sayfanın içeriğini ve düzenini oluşturabileceğimizden emin olmak istiyoruz.

Addy Osmani: Düzen için genellikle CSS'den bahsediyoruz. Bu nedenle, sayfalarınızda kritik CSS, satır içi CSS kullanıyor olabilirsiniz, oluşturmayı engelleyen şeylerden kaçınmak istiyorsunuz, ancak daha sonra görüntünüze gelince, ideal olarak o görüntüyü erken talep etmelisiniz. Belki de bu, bugünlerde çoğumuzun çerçevelere güvendiği göz önüne alındığında, tarayıcının bu resmi sayfada mümkün olduğunca erken keşfedebildiğinden emin olmayı içerir.

Addy Osmani: SSR, sunucu tarafı oluşturma kullanmıyorsanız, tarayıcıda bazı JavaScript paketlerinizi, bileşenleriniz için paketleri keşfetmeyi bekliyorsanız, kahraman resminiz veya ürün resminiz için bir bileşeniniz olsun, tarayıcının görüntüyü keşfetmeden önce tüm bu farklı dosyaları getirmeyi, ayrıştırmayı, yürütmeyi, derlemeyi ve yürütmeyi beklemesi gerekiyorsa, bu, en büyük içerikli görüntünüzün keşfedilmesi biraz zaman alacağı anlamına gelebilir.

Addy Osmani: Şimdi, durum buysa, kendinizi görüntünün oldukça geç talep edildiği bir yerde bulursanız, tarayıcının o görüntüyü erkenden keşfetmesini sağlamak için link rel preload adlı bir tarayıcı özelliğinden yararlanabilirsiniz. olabildiğince. Şimdi, ön yükleme gerçekten güçlü bir yetenek. Aynı zamanda çok dikkat etmeniz gereken bir durum. Bu günlerde, anahtarınız için önyükleme önerdiğimizi duyduğunuz bir yere gitmek çok kolay.

Addy Osmani: Belki de anahtar kahraman resminiz, anahtar komut dosyalarınız ve anahtar yazı tipleriniz için önyükleme önerdiğimizi duymuşsunuzdur. Ve işleri doğru sırada sıraladığınızdan emin olmak için gerçekten çok büyük, devasa hale geliyor. Dolayısıyla LCP görüntüleri, bunun için kesinlikle akılda tutulması gereken önemli bir yerdir.

Addy Osmani: Diğer şey, bahsettiğim dört şey, diğeri ise kaynak seti ve verimli bir modern görüntü formatı kullandığınızdan emin olun. Bu kaynak kümesinin gerçekten güçlü olduğunu düşünüyorum. Ayrıca bazen insanlar onu kullanırken, aşırı telafi etmeye çalışacaklarını ve belki de her olası çözünürlük için oraya 10 farklı görüntü sürümü göndereceklerini görüyorum. En azından bazı araştırmalarda, görsellerle üçün ötesinde, kullanıcıların görüntü kalitesi, keskinlik ve ayrıntı için farklılıkların ne olduğunu söylemekte gerçekten zorlandıklarını bulma eğilimindeyiz. Bu nedenle DPR sınırlaması, cihaz piksel oranı sınırlaması kesinlikle akılda tutulmaya değer bir fikirdir.

Addy Osmani: Ve modern görüntü formatları için daha önce formatlardan bahsetmiştik ama WebP'nizi, AVIF'inizi, JPEG XL'nizi düşünün. Piksel israfından kaçının. Kalite için yerinde iyi bir stratejiye sahip olmak gerçekten önemlidir. Ve varsayılan kalitenin bile bazen çok fazla olabileceği birçok durum olduğunu düşünüyorum. Bu yüzden, bit hızınızı düşürmeye, kalite ayarlarınızı düşürmeye ve keskinliği korurken kullanıcılarınız için ne kadar ileri gidebileceğinizi görmeye çalışırdım.

Addy Osmani: Yükleme hakkında konuştuğumuzda, resim etiketinin son birkaç yılda desteklemek için geliştirdiği diğer şeylerden biri de tembel yükleme. Bu nedenle, yükleme tembelliğe eşittir, artık resimlerinize tembel yükleme eklemek için mutlaka bir JavaScript kitaplığı kullanmanıza gerek yoktur. Bunu sadece resminize bırakın. Ayrıca krom tarayıcılarda ve Firefox'ta, herhangi bir üçüncü taraf bağımlılığı kullanmanıza gerek kalmadan bu görüntüleri tembelce yükleyebilirsiniz. Ve bu da oldukça hoş.

Addy Osmani: Yani, tembel yükleme yapıyoruz. Senkron kod çözme gibi başka şeyler için desteğimiz var, ancak işleri devam ettireceğim ve diğer iki temel hayati ölçüt hakkında çok hızlı konuşacağım.

Drew McLellan: Devam et, evet.

Addy Osmani: Öyleyse, düzen değişikliklerinden kurtulun. Kimse sayfalarında zıplayan şeylerden hoşlanmaz. En büyük hayal kırıklıklarımdan biri bir web sayfası açmak gibi hissediyorum. Parmağımı tıklamak istediğim bir düğmenin üzerine getiriyorum ve sonra aniden boyut seti veya başka şeyler olmayan bir sürü reklam veya resim beliriyor. Ve bu gerçekten tatsız bir deneyime neden oluyor.

Addy Osmani: Yani kümülatif düzen kayması, içeriğin kararsızlığını ölçmeye çalışıyor. Ve çoğu zaman, mizanpaj değişikliğinizi zorlayan yaygın şeyler, sayfanızdaki boyut seti olmayan resimler veya diğer öğelerdir. Bence bu, insanların görüntü boyutlarını ayarlamasının genellikle kolay olduğu yerlerden biri. Belki de tarihsel olarak çok fazla yaptığımız bir şey değil, ama kesinlikle zaman ayırmaya değer bir şey. Deniz feneri gibi araçlarda toplamanıza yardımcı olmaya çalışacak, sayfanızda boyut gerektiren resimlerin listesi nedir? Böylece gidebilir ve onları ayarlayabilirsiniz.

Drew McLellan: Bu gerçekten ilginç bir nokta diyecektim, çünkü duyarlı web tasarımı bir şey haline geldiğinde, hepimiz sitelerimizi inceledik ve görüntü boyutlarını çıkardık çünkü bu işi yapmak için elimizdeki araçlar bizim yapmamamızı gerektiriyordu. resimlerimizde yükseklik ve genişlik özelliklerine sahip olun. Ama bu kötü bir fikir, değil mi?

Addy Osmani: Eski olan yine yenidir. Resimlerinize kesinlikle boyut ayarlamaya değer olduğunu söyleyebilirim. Reklamlarınızda, göz çerçevelerinizde, boyutu değişebilecek dinamik içerik olan her şeyde boyutlar belirleyin, boyutları ayarlamaya değer.

Addy Osmani: Ve orada gerçekten eğlenceli bir deneyim inşa eden insanlar için, yanlış ifade, gerçekten eğlenceli düzen deneyimleri var, belki de duyarlı kartlar ve benzerleri üzerinde biraz daha çalışmanız gerekiyor; Alanınızı ayırmak için CSS en boy oranı veya en boy oranı kutuları kullanmayı düşünürdüm. Ve bu, yerleşim değişikliklerinizden kaçınmaya çalışırken işlerin olabildiğince sabit olduğundan emin olmak için bu görüntülerdeki boyutların ayarlanmasını da tamamlayabilir.

Addy Osmani: Ve son olarak, son olarak Core Web Vital ilk giriş gecikmesidir. Bu, konu görseller olduğunda insanların her zaman düşünmediği bir şeydir. Bu nedenle, sayfa yükünde görüntülerin bir kullanıcının bant genişliğini ve CPU'sunu engellemesi aslında mümkündür. Özellikle gerçekten yavaş bağlantılarda veya bant genişliği doygunluğuna yol açabilecek alt uç mobil cihazlarda diğer kritik kaynakların nasıl yüklendiğini engelleyebilirler.

Addy Osmani: İlk giriş gecikmesi, kullanıcıların bir sitenin etkileşimi ve yanıt verebilirliğine ilişkin ilk izlenimini yakalayan Temel Web Hayati ölçümüdür. Ve böylece ana iş parçacığı CPU kullanımını azaltarak, ilk giriş gecikmeniz de bir nevi en aza indirilebilir. Yani genel olarak, ağ çekişmesine neden olabilecek görüntülerden kaçının. Render engelleme değiller. Ancak yine de oluşturma performansınızı dolaylı olarak etkileyebilirler.

Drew McLellan: Oluşturma engellemelerini durdurmak için resimlerle yapabileceğimiz herhangi bir şey var mı? Daha hızlı etkileşimli olmamızı sağlamak için bu ilk aşamada tarayıcının yükünü bir şekilde kaldırabilir miyiz?

Addy Osmani: Ekranın üst kısmındaki bir şeyi görüntülemek için doğru optimal görüntü dizisini iyi anlamanın bugünlerde giderek daha önemli hale geldiğini düşünüyorum. Ekranın üst kısmının aşırı yüklenmiş bir terim olduğunu biliyorum, ancak kullanıcının ilk görüntüleme bağlantı noktasında olduğu gibi. Çoğu zaman, kullanıcının hemen göreceği şey için gerçekten gerekli olmayan, bazıları resim olan bir ton kaynak talep etmeye çalışabiliriz. Ve bunlar, sayfanın yaşam döngüsünde daha sonra yüklemek için harika adaylar, tembelce yüklenecek harika şeyler olma eğilimindedir. Ancak, çok erken bir şey kuyruğu gibi, çok sayıda görüntü talep ediyorsanız, bunların potansiyel olarak bir etkisi olabilir.

Drew McLellan: Evet. Yani, demek istediğim, geçmişte bir JavaScript kitaplığına ihtiyaç duyduğumuz tembel yükleme görsellerinden bahsetmiştiniz, sanırım tarayıcıların görsel yüklemeyi optimize etmelerinin tarihsel yolları nedeniyle, bunun da kendi aksilikleri var, burada onları görsel yüklemeyi durdurmanın neredeyse imkansız olduğu yerler. , sadece bir kaynak vermedikçe. Ve ona bir kaynak vermezseniz ve ardından JavaScript ile düzeltmeye çalışırsanız, o JavaScript çalışmazsa, görüntü alamazsınız. Yani tembel yükleme, yerel tembel yükleme tüm bunlara bir cevaptır.

Addy Osmani: Evet, kesinlikle. Ve bence burası, geçen yıl boyunca yerel tembel yükleme deneyimi olan tarayıcılar arasında geliştirmeye çalıştığımız bir yer. Bildiğiniz gibi bu, bir şeyi erken gönderdiğimiz özelliklerden biri ve sektördeki düşünce liderleriyle yaptığımız konuşmalardan yararlanarak "Ah, hey, aslında manuel olarak belirlediğiniz eşikler neler? tembel boyutlar mı yoksa diğer JavaScript'in tembel yükleme kitaplıklarını mı kullanıyorsanız?" Ardından, olmasını beklediğiniz şeye biraz daha yakın bir yere ulaşmaya çalışmak için eşiklerimizi ayarladık.

Addy Osmani: Pek çok durumda, yerel tembel yüklemeyi kullanabilirsiniz. Çok daha rafine bir şeye ihtiyacınız varsa, kesişim gözlemci eşiklerini, tarayıcının ne zaman bir şey talep edeceği noktasını ayarlayabilmek için çok daha fazla kontrole ihtiyacınız varsa, genellikle bu durumlarda bir kitaplık kullanmanızı ve kullanmanızı öneririz. , çünkü %90 kullanım durumu için çözmeye çalışıyoruz. Ama %10 hala geçerli. Hala biraz daha fazlasına ihtiyacı olan insanlar olabilir. Bu yüzden çoğu insan için yerel tembel yüklemenin öngörülebilir gelecek için yeterince iyi olacağını umuyorum.

Drew McLellan: En önemlisi ücretsiz. Eklemek için basit bir özellik ve tüm bu işlevselliğe ücretsiz sahip oluyorsunuz, bu harika. Dinleyicimizin yapabileceği bir şey olsaydı, gidip sitelerinde görüntü optimizasyonunu iyileştirmek için yapabileceği bir şey olsaydı, bu ne olurdu? Nereden başlamalılar?

Addy Osmani: Bunun siteniz için ne kadar büyük bir sorun olduğunu anlamak iyi bir başlangıç ​​noktasıdır. Gidip deniz fenerini kontrol eder ya da hız analizlerini öderdim. Gidin ve en popüler sayfalarınızdan birkaçında çalıştırın ve ne çıktığını görün. Yapacak sadece bir veya iki küçük işiniz var gibi görünüyorsa, bu harika. Belki biraz zaman ayırabilirsin.

Addy Osmani: Yapmanız gereken uzun bir liste varsa, belki orada sahip olduğunuz en yüksek fırsatlara bir göz atın, "Oh, hey, bunu yaparsan birkaç saniye kazanabilirsin" diyen şeyler. şey." Ve başlamak için enerjinizi oraya odaklayın.

Addy Osmani: Burada bahsettiğimiz gibi, modern görüntü formatları için araçlar zamanla daha iyi hale geldi. Resim CDN'leri kesinlikle dikkate alınmaya değer olabilir. Ancak bunun ötesinde, atabileceğiniz birçok küçük adım var. Bazen yeterince küçük bir siteyse, Squoosh'a gidip birkaç görselinizi oraya yerleştirmek bile harika bir başlangıç ​​noktası olabilir.

Drew McLellan: Bu sağlam bir tavsiye. Şimdi bunun harika bir yayın olduğunu biliyorum, ama sizi kitap için gerçekten tebrik etmeliyim. Sadece çok kapsamlı ve sindirimi gerçekten kolay. Gerçekten değerli bir okuma olduğunu düşünüyorum.

Drew McLellan: Görüntü optimizasyonu hakkında her şeyi öğreniyorum. Son zamanlarda ne öğreniyorsun Addy?

Addy Osmani: Son zamanlarda ne öğreniyorum? Aslında, hala görüntülerle ilgili olan biraz farklı bir konuda, bu yüzden üniversitede yüksek lisansımı yaparken, bilgisayar vizyonuna gerçekten derinden daldım ve bir görüntünün farklı kısımlarını nasıl tespit edip vahşi ve onlarla ilginç şeyler?

Addy Osmani: Son zamanlarda araştırdığım özel bir sorun da, bebek ya da çocukken çekilmiş fotoğraflarıma bakıyor olmam. Ve o zamanlar, ailemin alacağı yiyeceklerin çoğu mutlaka dijital kameralarda değildi. Onlar Polaroid'di. Genellikle biraz düşük çözünürlüklü görüntülerdir. Ve bunları büyütebilmenin bir yolunu istedim. Ve böylece son zamanlarda bu sorunu tekrar kazmaya başladım. Ve tarayıcıda neler yapabileceğim hakkında daha çok şey öğrenmemi sağladı.

Addy Osmani: Bu yüzden, makine öğrenimini kullanarak, TensorFlow'u kullanarak, mevcut teknolojileri kullanarak, nispeten düşük çözünürlüklü bir görüntü veya illüstrasyon almanızı ve ardından bunları çok daha kaliteli bir şeye yükseltmenizi sağlayan bazı küçük araçlar geliştiriyorum. Böylece, sadece görüntüyü uzatmaktan daha iyidir. Aslında ayrıntılı olarak doldurmak gibi.

Addy Osmani: Ve bu biraz eğlenceli oldu. Web derlemesinin artık tarayıcılarda ne kadar kararlı olduğu, bu fikirlerin bazılarını masaüstü uygulaması kullanım durumları için ne kadar iyi kullanabileceğiniz hakkında çok şey öğreniyorum. Ve bu gerçekten eğlenceli oldu. Bu yüzden son zamanlarda çok fazla web derlemesine giriyorum. Ve bu harika oldu.

Drew McLellan: Komik, değil mi? Bir teknoloji geldiğinde bildiğiniz her şeyi alt üst eder. Web'de her zaman görüntüleri küçültebileceğimizi söyledik. Ama elimizde sadece küçük bir görüntü varsa, onu büyütemeyiz. Bu imkansız. Ama şimdi, birçok koşulda bunu mümkün kılabilecek teknolojiye sahibiz. Gerçekten büyüleyici.

Drew McLellan: Sevgili dinleyici, Addie'den daha fazlasını duymak istiyorsanız, onu @AddieOsmani olduğu Twitter'da bulabilir ve tüm projelerini AddyOsmani.com'dan bulabilirsiniz. “Görüntü Optimizasyonu” kitabı şu anda smashingmagazine.com'da hem fiziksel hem de dijital olarak Smashing'den temin edilebilir. Bugün bize katıldığın için teşekkürler Addy. Ayrılık sözleriniz var mı?

Addy Osmani: Herhangi bir ayrılık sözü var mı? İnsanlarla paylaşacağım tarihten küçük bir tuhaflığım var. Tim Berners-Lee ilk resmi 1992'de internete yükledi. Ne olduğunu tahmin edebilir misiniz bilmiyorum ama muhtemelen şaşıracaksınız. Drew, tahminin var mı?

Drew McLellan: Sanırım bir kedi.

Addy Osmani: Bir kedi. İyi bir tahmin ama hayır. Bu CERN'deydi. Görüntü aslında Les Horribles Cernettes adlı, bir grup CERN çalışanının oluşturduğu parodi pop grubu olan bir gruba aitti. Ve yapacakları müzik doo-wop müziği gibidir. Ve çarpıştırıcılar, tuhaflıklar, sıvı nitrojen ve anti-madde hakkında altmışlı yılların kıyafetlerini giyen aşk şarkıları söylerlerdi, ki bunu harika ve rastgele buldum.