Smashing Podcast Episode 39 z Addy Osmani: Optymalizacja obrazu

Ten odcinek został życzliwie poparty przez naszych drogich przyjaciół ze Storyblok, którzy pomagają ludziom dostarczać treści na dowolnej platformie: firmowych stronach internetowych, witrynach e-commerce, aplikacjach mobilnych i ekranach. Dziękuję Ci!

W dzisiejszym odcinku Smashing Podcast mówimy o optymalizacji obrazu. Jakie kroki powinniśmy wykonać, aby uzyskać wydajne obrazy w 2021 roku? Aby się tego dowiedzieć, rozmawiałem z ekspertem Addy Osmani.

Pokaż notatki

• „Optymalizacja obrazu”, Addy Osmani
• Addy na Twitterze
• Osobista witryna Addy

Cotygodniowa aktualizacja

• Poznaj :has, natywny selektor nadrzędny CSS (i nie tylko)
  napisany przez Adriana Bece
• Trzy narzędzia do audytu front-end, które niedawno odkryłem
  napisany przez Stefana Judis
• Przydatne płyty kotłowe front-end i zestawy startowe
  napisany przez Cosimę Mielke
• Dobrze zrobione projektowanie stron internetowych: wykorzystanie dźwięku
  napisany przez Fredericka O'Brien
• Kiedy CSS nie wystarczy: Wymagania JavaScript dla dostępnych komponentów
  napisany przez Stephanie Eckles

Transkrypcja

Drew McLellan: Jest menedżerem ds. inżynierii pracującym nad Google Chrome, gdzie jego zespół skupia się na szybkości, pomagając w utrzymaniu szybkości internetu. Oddany społeczności open source, jego wcześniejsze wkłady obejmują Lighthouse, Workbox, Yeoman, Critical i do NVC. Wiemy więc, że zna się na optymalizacji pod kątem wydajności sieci. Ale czy wiesz, że z powodu błędu pisarskiego chce zdobyć Oscara dla najlepszej aktorki drugoplanowej? Moi miażdżący przyjaciele, witajcie Addy Osmani. Cześć Addy. Jak się masz?

Addy Osmani: Rozwalam.

Drew McLellan: Dobrze to słyszeć. Chciałem dziś z wami porozmawiać o obrazach w sieci. Jest to obszar, w którym w ciągu ostatnich kilku lat zaszło zaskakująco dużo zmian i innowacji, a Ty właśnie napisałeś bardzo obszerną książkę o optymalizacji obrazu dla Smashing. Jaka była motywacja do myślenia w tym czasie: „Nadszedł czas na książkę o optymalizacji obrazu?”

Addy Osmani: To świetne pytanie. Myślę, że wiemy, że obrazy od dziesięcioleci są kluczową częścią sieci i że nasze mózgi są w stanie interpretować obrazy znacznie szybciej niż tekst. Ale ten ogólny temat staje się z czasem coraz bardziej interesujący i zniuansowany. I zawsze mówię ludziom, że to chyba moja trzecia lub czwarta książka. Nigdy celowo nie zamierzałem napisać książki.

Addy Osmani: Zacząłem tę książkę od pisania artykułu o optymalizacji obrazu, a potem z czasem odkryłem, że przypadkowo napisałem o tym całą książkę. Pracowaliśmy nad tym projektem od około dwóch lat. I nawet w tym czasie branża ewoluowała w zakresie przeglądarek, a narzędzia związane z obrazami i formatami graficznymi ewoluowały.

Addy Osmani: Napisałem więc tę książkę, ponieważ trudno mi było utrzymać się na szczycie wszystkich tych zmian. Pomyślałem: „Będę dobrym obywatelem sieci i spróbuję śledzić wszystko, czego się nauczyłem w jednym miejscu, aby wszyscy inni mogli z tego skorzystać”.

Drew McLellan: Myślę, że to jeden z tych obszarów, z dużą optymalizacją wydajności w przeglądarce, to szybko zmieniający się krajobraz, prawda? Tam, gdzie technika, której się nauczyłeś jako aktualna i będąca najlepszą praktyką, następuje pewna zmiana technologiczna, a potem okazuje się, że jest to właściwie anty-wzorzec i nie powinieneś tego robić. A próba podtrzymywania wiedzy i upewnienia się, że czytasz właściwe artykuły i uczysz się właściwych rzeczy, a nie czytasz czegoś sprzed dwóch lat, jest dość trudne.

Drew McLellan: Tak więc zebranie tego wszystkiego w jednej dobrze zbadanej książce z wiarygodnego źródła jest naprawdę niesamowite.

Addy Osmani: Tak. Nawet z punktu widzenia autora, jedną z najciekawszych i być może jedną z najbardziej stresujących rzeczy dla naszej redakcji było to, że oddałem rozdział i powiedziałem, że zostało to zrobione. A potem, dwa tygodnie później, coś się zmieniło w przeglądarce, a ja na to: „Och, czekaj. W ostatniej chwili muszę dokonać kolejnej zmiany.

Addy Osmani: Ale krajobraz obrazów bardzo ewoluował, nawet w ciągu ostatniego roku. Widzieliśmy, jak obsługa WebP w końcu dotarła do mety w większości nowoczesnych przeglądarek. Obsługa obrazów AVIF jest dostępna w Chrome, w Firefox, JPEG XL, leniwe ładowanie. Poza tym zaobserwowaliśmy ulepszenia w sposobie, w jaki można całkiem konkretnie używać obrazów w sieci w przeglądarkach. Ale znowu, dużo dla ludzi do utrzymania.

Drew McLellan: Niektórzy ludzie mogą postrzegać optymalizację obrazu jako dość stateczny temat. Wszyscy w pewnym momencie naszej kariery nauczyliśmy się eksportować do sieci z naszego oprogramowania graficznego. Niektórzy z nas mogą mieć zwyczaj robienia eksportowanych obrazów i przeglądania ich przez coś takiego jak ImageOptim.

Drew McLellan: Możemy więc wiedzieć, że powinniśmy wybrać JPEG, gdy jest to obraz fotograficzny, a PNG, gdy jest to obraz oparty na grafice i pomyśleć: „Ok, to jest to. Znam się na optymalizacji obrazu, gotowe.” Ale tak naprawdę te rzeczy to tylko stawki przy stole, nieprawdaż w tym momencie?

Addy Osmani: Tak, są. Myślę, że nasza zdolność do wyświetlania bardziej szczegółowych, bardziej wyrazistych obrazów i obrazów nawet w innym kontekście, w zależności od tego, czy zależy Ci na kierunku artystycznym, czy nie, ewoluowała z biegiem czasu. Myślę, że potrzeba wymyślenia, w jaki sposób można sprawić, by te obrazy wyglądały tak pięknie, jak zamierzone dla użytkowników końcowych, pamiętając o ich środowisku, ograniczeniach urządzeń, ograniczeniach sieci, jest trudnym problemem i czymś, o czym wciąż wiele osób wiem borykają się z.

Addy Osmani: A więc, jeśli chodzi o myślenie o obrazach i uzyskanie nieco bardziej wyrafinowanego podejścia do tego, poza „Hej, użyjmy JPEG” lub „Użyjmy PNG”, myślę, że jest kilka wymiarów tej wartości pamiętając. Pierwszy to po prostu ogólnie kompresja. Wspomniałeś o ImageOptim i wielu z nas jest przyzwyczajonych do przeciągania obrazu w miejsce i robienia z niego czegoś mniejszego.

Addy Osmani: Jeśli chodzi o kompresję, zwykle mówimy o różnych kodekach. A kodeki to technologia kompresji, która zwykle zawiera składnik kodera do kodowania plików i składnik dekodera do ich dekodowania i dekompresji. A kiedy zaczynasz decydować, czy czegoś używasz, zazwyczaj musisz zastanowić się, czy zdjęcia lub obrazy, których używasz, są w porządku, abyś mógł zastosować podejście oparte na stratnej kompresji lub podejście bez strat.

Addy Osmani: Na wypadek, gdyby ludzie nie byli tak zaznajomieni z tymi koncepcjami, podejście bezstratne to takie, w którym odtwarzasz dokładnie ten sam plik na samym końcu po dekompresji. Więc tak naprawdę nie tracisz dużo na jakości. Bezstratny to o wiele więcej niż przesyłanie obrazu przez faks. Otrzymasz faksymile oryginału i nie będzie to oryginalny plik. Mogą tam znajdować się różne artefakty. To może wyglądać nieco inaczej. Ale ogólnie rzecz biorąc, im więcej kompresujesz, tym więcej jakości zazwyczaj tracisz.

Addy Osmani: W przypadku wszystkich tych nowoczesnych kodeków obrazu próbują zobaczyć, jak wiele jakości można wycisnąć, zachowując stosunkowo przyzwoity rozmiar pliku, w zależności od przypadku użycia.

Drew McLellan: Tak naprawdę, z technologicznego punktu widzenia, masz obraz źródłowy, a następnie docelowy format pliku. Ale proces zamiany jednego w drugiego jest otwarty na debatę. Tak długo, jak masz zgodny plik, sposób, w jaki to robisz, zależy od kodeka, który może mieć wiele różnych implementacji, a niektóre będą lepsze od innych.

Addy Osmani: Absolutnie. Absolutnie. I myślę, że znowu, wracając do miejsca, w którym zaczęliśmy od JPEG i PNG, ludzie mogą wiedzieć, że JPEG został stworzony do stratnej kompresji zdjęć. Zwykle dostajesz mniejszy plik z tyłu i czasami może mieć różne artefakty pasowania. PNG został pierwotnie stworzony do kompresji bezstratnej, całkiem dobrze radzi sobie z obrazami nie fotograficznymi.

Addy Osmani: Ale od tego czasu wszystko ewoluowało. Około 2010 roku zaczęliśmy otrzymywać wsparcie dla WebP, które miało zastąpić JPEG i PNG i nieco je pobić w kompresji. Ale od tego czasu liczba formatów i opcji graficznych na stole po prostu gwałtownie wzrosła. Myślę, że generalnie wszystko idzie w dobrym kierunku, zwłaszcza w przypadku nowoczesnych formatów, takich jak AVIF i JPEG XL. Ale dotarcie tutaj zajęło nam trochę czasu. Nawet uzyskanie obsługi WebP we wszystkich przeglądarkach zajęło trochę czasu.

Addy Osmani: I myślę, że ostatecznie to, co ją przekonało, to upewnienie się, że programiści o to prosili, mieli apetyt na uzyskanie lepszej kompresji z tych nowoczesnych formatów i chęć posiadania dobrej kompatybilności między przeglądarkami za te rzeczy też.

Drew McLellan: Tak. WebP wydaje mi się naprawdę interesujący, ponieważ oprócz bezstratnej i stratnej kompresji dostępnej w ramach tego formatu, mamy oczywiście znacznie zmniejszony rozmiar pliku. Jest też dobra obsługa przeglądarek i widzimy adopcję ze strony dużych firm, takich jak Google i Netflix, oraz różnych dużych firm.

Drew McLellan: Ale moje postrzeganie w branży jest takie, że nie widzimy tego samego rodzaju akceptacji na poziomie podstawowym. Czy WebP wciąż czeka na swój dzień?

Addy Osmani: Myślę, że powiedziałbym, że nadchodzi WebP. Wielu ludzi czekało na materializację wsparcia Safari i WebKit, i w końcu to mamy. Ale kiedy myślimy o nowych formatach graficznych, bardzo ważne jest, abyśmy zrozumieli, co właściwie oznacza wsparcie. Istnieje obsługa przeglądarki do dekodowania tych obrazów. Potrzebujemy również naprawdę dobrego wsparcia narzędzi, aby niezależnie od tego, czy jesteś w środowisku węzłów, CDN obrazu, jeśli jesteś w CMS, masz możliwość korzystania z tych formatów obrazu.

Addy Osmani: Pamiętam, jak wiele lat temu pojawił się WebP. Pierwsi użytkownicy mieli ten problem, że zapisywałeś plik WebP na pulpicie, a potem nagle: „Och, czekaj. Czy muszę przeciągnąć to do przeglądarki, aby go wyświetlić?” lub „Jeśli moi użytkownicy pobierają WebP, czy utkną i będą się zastanawiać, co się dzieje?”

Addy Osmani: Tak więc upewnienie się, że jest dość całościowe wsparcie dla formatu obrazu zarówno na poziomie systemu operacyjnego, jak iw innym kontekście, jest naprawdę ważne, jak sądzę, aby format obrazu wystartował. Ważne jest również, aby ludzie, którzy udostępniają obrazy, zastanowili się trochę nad tymi przypadkami użycia, tak aby podczas zapisywania lub pobierania pliku próbowałeś umieścić go w formacie przenośnym, który ludzie mogą łatwo udostępniać. I myślę, że tutaj, przynajmniej na iOS, iOS ma wsparcie dla podwyżki i myślnika. A konwertowanie rzeczy do plików JPEG, gdy jest to konieczne, pozwala ludziom się nimi dzielić.

Addy Osmani: Myślę więc, że ważne jest przemyślenie tego typu przypadków użycia, w których możemy upewnić się, że użytkownicy nie tracą, podczas gdy my zapewniamy im lepszą kompresję.

Drew McLellan: Prowadzę usługę udostępniania slajdów, która, jak możesz sobie wyobrazić, obsługuje setki tysięcy obrazów. Kiedy patrzyłem na WebP, a było to prawdopodobnie trzy lata temu, szukałem przede wszystkim sposobu na zmniejszenie kosztów przepustowości CDN, ponieważ jeśli obsługujesz mniejszy plik, płacisz mniej za jego obsługę. Ale chociaż nadal potrzebowałem pełnego obrazu, również starszego formatu obrazu, moje obliczenia wykazały, że koszt przechowywania całego innego zestawu obrazów przewyższa korzyści z obsługi mniejszego pliku. Mamy więc rok 2021. Czy to jest decyzja, którą powinienem ponownie rozważyć w tym momencie?

Addy Osmani: Myślę, że to naprawdę ważna uwaga. Czasami, kiedy mówimy o tym, jak powinieneś podchodzić do swojej strategii wizerunkowej, bardzo łatwo jest dać ludziom odpowiedź na wysokim poziomie: „Hej, tak. Po prostu wygeneruj pięć różnych formatów, a to będzie po prostu skalowane w nieskończoność”. I nie zawsze tak jest.

Addy Osmani: Myślę, że kiedy trzeba pamiętać o pamięci masowej, warto czasem spróbować znaleźć najlepszy, najczęstszy mianownik służący do obsługi użytkowników. W dzisiejszych czasach powiedziałbym, że WebP jest wart rozważenia jako wspólny mianownik. W przypadku osób, które były przyzwyczajone do używania tagu obrazu do warunkowego obsługiwania różnych formatów, zwykle jako główną rezerwę używa się pliku JPEG. Może w dzisiejszych czasach jest w porządku, aby faktycznie używać WebP jako rozwiązania awaryjnego dla większości użytkowników, chyba że masz ludzi, którzy korzystają z bardzo, bardzo starych przeglądarek. I myślę, że ostatnio widzimy tego znacznie mniej. Ale na pewno masz tam pewną elastyczność.

Addy Osmani: Teraz, jeśli starasz się być zwrócony do przodu, powiedziałbym, że wybierz jeden format, który według Ciebie działa naprawdę dobrze. Jeśli możesz podejść do przechowywania w sposób, który skaluje się i jest elastyczny w stosunku do twoich potrzeb, powiedziałbym, że ludzie powinni rozważyć JPEG XL. Technicznie nie jest jeszcze dostępny w przeglądarce. Kiedy tak się dzieje, JPEG XL powinien być całkiem świetną opcją dla wielu zdjęć w stratnych lub bezstratnych przypadkach użycia lub w przypadkach innych niż zdjęcia. I prawdopodobnie będzie znacznie lepiej niż WebP V1. Więc to jest jedno miejsce.

Addy Osmani: Myślę, że AVIF prawdopodobnie będzie lepszy, jeśli potrzebujesz naprawdę niskich przepływności. Może bardzo zależy Ci na przepustowości. Może trochę mniej dbasz o wierność obrazu. I przy tych szybkościach transmisji mógłbym sobie wyobrazić, że wygląda to wyraźniej niż niektóre alternatywy. A dopóki nie będziemy mieli JPEG XL, spróbuję przyjrzeć się twoim analizom i zrozumieć, czy możesz obsługiwać AVIF. W przeciwnym razie skupiłbym się na tym WebP. Gdybyś był analitykiem, myślę, że większość ludzi można obsłużyć WebP, a trochę mniej przejmujesz się szeroką gamą lub nakładkami tekstowymi, miejscami, w których próbkowanie chromosomów może nie być idealne w WebP. Z pewnością warto o tym pamiętać.

Addy Osmani: Staram się więc pamiętać, że nie będzie jednego rozmiaru dla wszystkich. Osobiście w dzisiejszych czasach martwię się trochę mniej o koszty przechowywania, ruchu wychodzącego i przepustowości, tylko dlatego, że używam obrazu CDN. I cieszę się, że osobiście używam Cloudinary. W miejscu, w którym pracuję, używamy wielu różnych sieci CDN z obrazami. Ale odkryłem, że nie muszę się tak bardzo martwić o koszty konserwacji związane z obsługą potoków obrazów, radzenie sobie z tym, w jaki sposób mam obsługiwać, np. „Och, hej, oto jeszcze inny format obrazu lub nowe typy awaryjne lub nowe internetowe interfejsy API ”, to była miła korzyść z inwestowania w coś, co po prostu dba o to za mnie.

Addy Osmani: A potem ogólny koszt moich przypadków użycia był w porządku. Ale mogę sobie całkowicie wyobrazić, że jeśli prowadzisz usługę slajdów na taką skalę, niekoniecznie jest to opcja.

Drew McLellan: Tak. Dlatego chcę wrócić do niektórych z nadchodzących przyszłych formatów. Ale myślę, że warto się w to zagłębić, ponieważ w przypadku jakichkolwiek narzędzi zwiększających wydajność, Lighthouse lub WebPageTests, jeśli ktoś z nas prowadzi przez nie nasze witryny, jedną z kluczowych rzeczy, które zasugeruje, jest użycie sieci CDN dla obrazów. A to bardzo realistyczna rzecz dla bardzo dużych firm. Czy jest to realistyczne i dostępne dla osób tworzących mniejsze strony internetowe i aplikacje, czy rzeczywiście jest to tak łatwe, jak się wydaje?

Addy Osmani: Myślę, że pytanie, które ludzie powinni zadać, brzmi: „Do czego używasz obrazów?” Jeśli masz tylko kilka obrazów, jeśli tworzysz blog, a obrazy, które dodajesz, są stosunkowo proste, nie masz setek, setek lub tysięcy obrazów, możesz być w porządku, podchodząc do tego w czasie kompilacji, w bardzo statyczny sposób, gdzie instalujesz kilka pakietów NPM. Może po prostu używasz Sharpa. I to w dużej mierze troszczy się o ciebie.

Addy Osmani: Istnieją narzędzia, które mogą pomóc w generowaniu wielu formatów. To trochę wydłuża czas budowania, ale dla wielu osób może to być w porządku. A potem dla ludzi, którzy chcą mieć możliwość wykorzystania wielu

Addy Osmani: A dla ludzi, którzy chcą mieć możliwość korzystania z wielu formatów, nie chcą zajmować się tak wieloma drobiazgami narzędzi i chcą mieć naprawdę bogaty, responsywny obraz lub historię, ja powiedziałbym wypróbuj obraz CDN. Osobiście byłem dość powściągliwy, jeśli chodzi o używanie go do osobistych projektów ze względu na obawy związane z kosztami, a potem z czasem, gdy spojrzałem na moje rozliczenia, w rzeczywistości zdałem sobie sprawę, że oszczędza mi to czasu, który w przeciwnym razie sam zainwestowałbym w rozwiązanie tych problemów. Nie wiem, ile w przeszłości musiałeś pisać niestandardowe skrypty do obsługi obrazów, ale zdałem sobie sprawę, że jeśli uda mi się zaoszczędzić przynajmniej kilka dni na debugowaniu przez te różne pakiety npm miesięcznie, to koszty troszcz się o czas, który oszczędzam, więc jest w porządku.

Addy Osmani: Ale może to być coś, w przypadku gdy skalujesz do setek z tysięcy lub milionów obrazów i nie jest to coś, co jest koniecznie pokrywane z twoich przychodów lub nie jest to coś, za co jesteś gotów zapłacić, musisz pomyśleć o strategie alternatywne. Myślę, że mamy szczęście, że dysponujemy wystarczającą elastycznością narzędzi, które są dla nas dzisiaj dostępne, aby móc podążać w jednym z tych kierunków, w którym robimy coś bardziej niestandardowego, zajmujemy się tym sami lub toczymy własny wizerunek CDN lub inwestujemy w coś bardziej komercyjnego. I jesteśmy w miejscu, w którym powiedziałbym, że w niektórych przypadkach można użyć obrazu CDN i jest on niedrogi.

Drew McLellan: Myślę, że jedną z głównych zasad jest zawsze po prostu być zwinny i być przygotowanym na zmiany. I możesz zacząć używać obrazu CDN do dynamicznej konwersji obrazów zgodnie z wymaganiami, a jeśli dojdzie do punktu, w którym nie będzie to opłacalne, możesz spojrzeć na inne rozwiązanie i ustawić bazę kodu w stanie gdzie łatwo będzie zastąpić jedno rozwiązanie innym. Myślę, że ogólnie i wszędzie, gdzie polegasz na usługach zewnętrznych, jest to dobra zasada, prawda? A więc o tych nadchodzących formatach graficznych wspomniałeś o JPEG XL. Co to jest JPEG XL? Skąd to pochodzi? A co to dla nas robi?

Addy Osmani: To doskonałe pytanie. Tak więc JPEG XL jest formatem obrazu nowej generacji, ma być ogólnego przeznaczenia i jest to kodek z komisji JPEG. Zaczęło się od pewnych korzeni w formacie zdjęć Google, a następnie w formacie FUIF firmy Cloudinary. Przez lata było wiele formatów, które zostały w pewnym sensie podporządkowane temu wysiłkowi, ale stało się to znacznie więcej niż tylko sumą jego poszczególnych części, a niektóre z zalet JPEG XL są świetne do uzyskania wysokiej wierności obrazy, naprawdę dobre dla bezstratnych, ma wsparcie dla progresywnego dekodowania, bezstratnego transkodowania JPEG, a także jest trochę zamieszania i wolny od opłat licencyjnych, co jest zdecydowanie zaletą. Myślę, że JPEG XL mógłby być naprawdę mocnym kandydatem. Rozmawialiśmy wcześniej, jeśli miałbyś wybrać jeden, czego byś użył? I myślę, że JPEG XL ma potencjał, by nim być.

Addy Osmani: Nie chcę przesadzać, wciąż jesteśmy na bardzo wczesnym etapie obsługi przeglądarek. Myślę więc, że naprawdę powinniśmy poczekać i zobaczyć, poeksperymentować i ocenić, jak dobrze sprawdza się w praktyce i spełnia oczekiwania ludzi, ale widzę duży potencjał w JPEG XL zarówno w przypadku stratnych, jak i bezstratnych przypadków. W tej chwili wierzę, że Chrome jest prawdopodobnie najdalej wysunięty pod względem wsparcia, ale zauważyłem również zdecydowanie zainteresowanie ze strony Mozilli i innych przeglądarek, więc jestem podekscytowany przyszłością z JPEG XL. A gdybyśmy mieli powiedzieć, czym jest jeszcze krótszy termin zainteresowania ludzi? Oczywiście jest też AVIF.

Drew McLellan: Opowiedz nam o AVIF, to kolejna, której nie znam.

Addy Osmani: OK. Wspomnieliśmy więc nieco wcześniej, że AVIF może być lepszym kandydatem, jeśli musisz przejść do niskich przepływności i zależy ci bardziej na przepustowości niż wierności obrazu, jako ogólna zasada, AVIF naprawdę zajmuje czołową pozycję w kompresji o niskiej wierności i wysokiej atrakcyjności. I JPEG XL, powinien wyróżniać się w średniej i wysokiej wierności, ale są to nieco inne formaty same w sobie. Jesteśmy w miejscu, w którym AVIF ma coraz lepszą obsługę przeglądarek, ale pozwól, że cofnę się o krok i powiem trochę więcej o formacie. Tak więc sam AVIF jest oparty na kodeku wideo AV1, który został ustandaryzowany przez Alliance for Open Media i stara się zapewnić ludziom znaczny wzrost kompresji w porównaniu z JPEG, w porównaniu z WebP, o którym mówiliśmy wcześniej. I chociaż dokładne oszczędności, jakie możesz uzyskać dzięki AVIF, będą zależeć od treści i celów jakościowych, widzieliśmy wiele przypadków, w których może zaoferować ponad 50% oszczędności w porównaniu z JPEG.

Addy Osmani: Ma wiele dobrych funkcji, jest w stanie zapewnić obsługę kontenerów dla nowych funkcji, takich jak wysoki zakres dynamiki i szeroka gama kolorów, synteza ziarna filmu. I znowu, podobnie jak w przypadku mówienia do przodu, jedną z fajnych rzeczy związanych z tagiem obrazu jest to, że możesz teraz udostępniać użytkownikom pliki AVIF i nadal będą one wracać do twojego WebP lub JPEG w przypadkach, gdy niekoniecznie są obsługiwane . Ale wracając do twojego przykładu z Photoshop Save For Web, możesz wziąć plik JPEG o rozmiarze 500 kilobajtów, spróbować sfotografować z podobną jakością do Photoshop Save For Web, a z AVIF powiedziałbym, że prawdopodobnie będziesz w stanie uzyskać punkt, w którym ten rozmiar pliku wynosi około 90 kilobajtów, 100 kilobajtów, a więc całkiem spore oszczędności bez rzeczywistej zauważalnej utraty jakości.

Addy Osmani: I jedną z fajnych rzeczy w tym jest to, że idealnie nie będzie widać tak dużej utraty tekstury na żadnych obrazach, które mają bogate szczegóły. Więc jeśli masz zdjęcia lasów, kempingów lub innych tego typu rzeczy, nadal powinny wyglądać naprawdę bogato dzięki AVIF. Jestem więc bardzo podekscytowany kierunkiem, jaki ma AVIF. Myślę, że wymaga trochę więcej pracy, jeśli chodzi o wsparcie oprzyrządowania. Więc niedawno napisałem o tym na Twitterze, mamy teraz kilka opcji używania AVIF, dla pojedynczych obrazów mamy Squoosh, squoosh.app, który jest napisany przez inny zespół w Chrome, więc krzycz do Surmy i Jake'a za pracę nad Squooshem. Avif.io ma wiele dobrych opcji dla osób, które dzisiaj próbują używać AVIF, niezależnie od tego, na jakim stosie technologicznym się skupiają, Sharp również obsługuje AVIF.

Addy Osmani: Ale generalnie myślisz o innych miejscach, w których mamy do czynienia z obrazami, czy to w Figmie, w Sketchu, w Photoshopie czy w innych miejscach, i powiedziałbym, że nadal musimy trochę popracować w zakresie Wsparcie AVIF jest tam, ponieważ musi być wszechobecne dla programistów i użytkowników, aby naprawdę poczuć, że wylądował i wrócił do domu. I to jest jeden z obszarów, na których skupiamy się w zespołach pracujących obecnie nad AVIF w Chrome, starając się upewnić, że możemy dostarczyć narzędzia w całkiem dobre miejsce.

Drew McLellan: Mamy więc HTML, element obrazu, który daje nam większą elastyczność w porównaniu z tradycyjnym tagiem obrazu. Chociaż tag obrazu również przeszedł długą drogę, prawda? Ale widzieliśmy dodawane zdjęcie, było to mniej więcej w tym samym czasie, co natywny tag wideo, myślę, że w tego rodzaju oryginalnej partii zmian HTML5. A to daje nam możliwość określenia wielu źródeł, czy to prawda?

Addy Osmani: Tak, zgadza się.

Drew McLellan: Możesz więc wymieniać różne formaty obrazów, a przeglądarka wybierze ten, który obsługuje, co pozwala nam od razu eksperymentować, nie martwiąc się zbytnio o to, że ludzie ze starszymi przeglądarkami nie psują rzeczy.

Addy Osmani: Absolutnie. Myślę, że jest to jedna z najmilszych zalet używania tagu obrazu poza przypadkami użycia, w których myślimy o naszym kierunku, po prostu będąc w stanie podać ludziom obraz i poprosić przeglądarkę o przejrzenie listy potencjalnych źródeł i zobaczenie, okej, cóż, użyję pierwszego z tej listy, który rozumiem, w przeciwnym razie cofnę się, to naprawdę potężna zdolność dla ludzi. Myślę, że w tym samym czasie słyszałem też, jak niektórzy wyrażają pewne obawy lub obawy, że teraz odtwarzamy naprawdę ogromne plamy znaczników, gdy próbujemy obsługiwać wiele formatów i bierzesz pod uwagę różne rozmiary dla tych formatów i nagle robi się trochę nieporęczna.

Addy Osmani: Czy istnieją inne sposoby podejścia do tych problemów? Nie chcę sprzedawać ludziom za dużo na CDN-ach z wizerunkiem, chcę, żeby stali sami. Ale jest to jedno z tych miejsc, w których pomysł zwany negocjacjami treści może zaoferować ciekawą ścieżkę. Porozmawialiśmy więc trochę o tagu obrazu, w którym musisz wygenerować kilka różnych zasobów i zdecydować o kolejności preferencji, prawo, dodatkowy kod HTML. Przy negocjacjach treści mówi się, że wykonajmy całą tę pracę na serwerze. Tak więc klienci mogą z góry poinformować serwer, jakie formaty obsługuje, za pomocą listy typów MIME za pomocą nagłówka HTTP Accept. Następnie serwer może wykonać całą ciężką pracę polegającą na generowaniu ostatecznych zasobów i zarządzaniu nimi oraz decydowaniu, które z nich wysłać do klientów. Jedną z potężnych rzeczy jest to, że jeśli używasz obrazu CDN, możesz wskazać pojedynczy zasób.

Addy Osmani: Więc może, jeśli mamy obraz szczeniaka, taki jak szczeniak.JPEG, moglibyśmy dać ludziom adres URL do szczeniaka.JPEG, a jeśli ich przeglądarka obsługuje WebP lub obsługuje AVIF, serwer może naprawdę sprytnie obsługiwać prawidłowe obraz dla tych użytkowników w zależności od tego, jak wygląda ich wsparcie, ale w przeciwnym razie wycofaj się bez konieczności samodzielnego wykonywania mnóstwa dodatkowej pracy. Myślę, że to potężny pomysł. Jest wiele rzeczy, które możesz zrobić na serwerze, czasami mówimy o tym, że nie każdy ma dostęp do naprawdę dobrej jakości sieci, Twój efektywny typ połączenia może być naprawdę różny w zależności od tego, gdzie jesteś.

Addy Osmani: Nawet mieszkając w Dolinie Krzemowej, mógłbym chodzić z kawiarni do hotelu lub być w samochodzie, a jakość mojego Wi-Fi lub sygnału może nie być tak dobra. W tym miejscu masz dostęp do innych interfejsów API, innych pomysłów, takich jak wskazówka klienta Save-Data, dotycząca potencjalnej możliwości obsługi ludzi nawet o mniejszych zasobach, jeśli użytkownik zdecydował się na oszczędzanie danych. Jest więc wiele interesujących rzeczy, które moglibyśmy zrobić po stronie serwera i myślę, że powinniśmy dalej forsować te pomysły, aby znaleźć dobrą równowagę, w której ludzie, którzy czują się komfortowo na ścieżce rynkowej, będą mieli pełną elastyczność, aby to zrobić a osoby, które chcą nieco bardziej magicznego rozwiązania, również mają kilka opcji.

Drew McLellan: Pomysł na tego rodzaju podejście do oszczędzania danych był czymś, o czym dowiedziałem się po raz pierwszy z twojej książki. To znaczy, przejdźmy do tego trochę bardziej, ponieważ to jest całkiem interesujące. Mówisz więc o tym, że przeglądarka może zasygnalizować preferencję, aby uzyskać zmniejszoną jakość danych, ponieważ może jest na połączeniu z pomiarem lub ma niski poziom naładowania baterii lub coś takiego.

Addy Osmani: Dokładnie. Dokładnie tak. Podróżowałem w normalnych czasach lub w czasach wcześniejszych, kiedy podróżowaliśmy dużo więcej, doświadczyłem wielu miejsc na świecie lub sytuacji, w których jakość mojej sieci może być naprawdę słaba lub bardzo nierówna, a więc nawet otwieranie w górę strony internetowej może być frustrującym lub trudnym doświadczeniem. Mogę przeglądać menu i jeśli nie widzę zdjęć pięknego jedzenia, które mają do dyspozycji, mogę pójść gdzieś, gdzie mogę, albo mogę, nie wiem, zrobić sobie zamiast tego coś do jedzenia. Ale myślę, że jedną z interesujących rzeczy w oszczędzaniu danych jest to, że daje ci połączenie z powrotem do preferencji użytkownika. Jeśli więc jako użytkownik, wiem, że mam problemy z połączeniem sieciowym. Mogę powiedzieć: „Dobrze, włączę tryb oszczędzania danych w mojej przeglądarce”.

Addy Osmani: A potem możesz użyć tego jako programisty jako sygnału do powiedzenia: „Ok, cóż, użytkownik jest trochę ograniczony, może przeszukamy go znacznie mniejszymi obrazami lub obrazami o znacznie niższej jakości”. Ale nadal mogą w ogóle zobaczyć niektóre obrazy, co jest lepsze niż czekanie przez bardzo długi czas na coś znacznie bogatszego. Inne zalety tego typu sygnałów to możliwość ich wykorzystania do warunkowego udostępniania multimediów. Więc może są przypadki, w których tekst jest najważniejszy na tej stronie, może możesz wyłączyć te obrazy, jeśli odkryjesz, że użytkownicy znajdują się w ograniczonym środowisku. Poświęcę na to tylko 30 sekund, ale naprawdę możesz posunąć ten pomysł do skrajności. Niektóre z interesujących rzeczy, które możesz zrobić z Save-Data, to być może nawet wyłączenie bardzo kosztownych funkcji zaimplementowanych w JavaScript.

Addy Osmani: Jeśli masz pewne komponenty, które są uważane za nieco bardziej opcjonalne, może niekoniecznie muszą one być wysyłane do wszystkich użytkowników, jeśli tylko poprawiają wrażenia. Nadal możesz służyć każdemu bardzo podstawowemu, małemu, szybkiemu doświadczeniu, a następnie po prostu nałożyć go z ładnym lukrem dla osób, które mają szybsze połączenie lub urządzenie.

Drew McLellan: Potencjalnie, myślę, że może to mieć wpływ na paginację i możesz zwrócić 10 wyników na stronie zamiast 100 i tego typu rzeczy. Jest tam mnóstwo interesujących, interesujących możliwości. Myślę, że wszyscy jesteśmy zaznajomieni z frustrującym procesem przygotowania nowej witryny, optymalizacji wszystkich obrazów, przekazania ich klientowi, udostępnienia mu CMS do zarządzania treścią i stwierdzenia, że ​​po prostu zastępują wszystko źle zoptymalizowane obrazy. Mam na myśli, znowu, obraz CDN, jak sądzę, byłby naprawdę wygodnym rozwiązaniem, ale czy istnieją inne rozwiązania, czy są rzeczy, które CMS może robić na serwerze, aby w tym pomóc, czy też obraz CDN jest prawdopodobnie tak trzymać?

Addy Osmani: Myślę, że to, co odkryliśmy po prawdopodobnie co najmniej sześciu lub siedmiu latach prób zmuszenia wszystkich do zoptymalizowania swoich obrazów, to to, że jest to trudny problem, ponieważ niektórzy ludzie zaangażowani w obraz mogą być nieco bardziej obeznani technicznie i być może wygodniejsi w ustawieniach tworzyć własne narzędzia lub uruchamiać latarnię morską lub wypróbowywać inne narzędzia, aby poinformować ich, czy istnieją możliwości poprawy. Chciałbym, aby ludzie konsekwentnie używali rzeczy takich jak Lighthouse do łapania, jeśli masz możliwość dalszej optymalizacji lub wyświetlania obrazów o odpowiednim rozmiarze, ale poza tym czasami napotykamy przypadki użycia, w których osoby przesyłające obrazy mogą nie koniecznie rozumieją nawet koszt przesyłanych zasobów. To jest często coś, na co się natykamy, i przepraszam, nie będę za bardzo wzywać ludzi, ale jest to coś, na co natrafiamy nawet z blogiem Google.

Addy Osmani: Co kilka tygodni na blogu Google ktoś przesyła bardzo duży animowany GIF o wielkości 20 lub 30 megabajtów. I nie oczekuję, że będą wiedzieć, że to nie jest dobry pomysł, starają się, aby artykuł wyglądał fajnie, bardzo angażująco i interaktywnie, ale ci odbiorcy niekoniecznie będą wiedzieć, jak korzystać z narzędzi lub korzystać z ImageOptim lub użycie któregokolwiek z tych innych narzędzi na miejscu i udokumentowanie dla nich, że powinni je sprawdzić, jest z pewnością jedną z opcji. Jednak możliwość zautomatyzowania tego problemu jest moim zdaniem bardzo przekonująca i pomaga nam konsekwentnie dotrzeć do miejsca, w którym mamy nadzieję równoważyć potrzeby wszystkich naszych użytkowników systemów CMS, zarówno technicznych, jak i nietechnicznych. jako potrzeby naszych użytkowników.

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: Więc jeśli próbuję wejść na stronę z przepisami, może mnie obchodzić, jak ten przepis wygląda, więc dbamy o to, aby ten wielki bohater przepisu był dla mnie widoczny. Teraz element LCP może się zmieniać w czasie. Bardzo możliwe, że na początku ładowania największą rzeczą może być nagłówek, ale w miarę wczytywania strony może w rzeczywistości stać się znacznie większym obrazem lub jakimś plakatem.

Addy Osmani: Kiedy próbujesz zoptymalizować największą zawartość treści, możesz zrobić około czterech rzeczy. Pierwszą rzeczą jest upewnienie się, że prosisz o wizerunek kluczowego bohatera tak wcześnie, jak to możliwe. Generalnie na stronie mamy kilka rzeczy, które są ważne. Chcemy mieć pewność, że potrafimy renderować treść i układ strony głównej.

Addy Osmani: W przypadku układu zazwyczaj mówimy o CSS. Więc możesz używać krytycznego CSS, wbudowanego CSS na swoich stronach, chcesz uniknąć rzeczy, które blokują renderowanie, ale jeśli chodzi o obraz, najlepiej byłoby poprosić o ten obraz wcześnie. Może oznacza to po prostu upewnienie się, że przeglądarka może wykryć ten obraz tak wcześnie, jak to możliwe, biorąc pod uwagę, że wielu z nas obecnie polega na frameworkach.

Addy Osmani: Jeśli niekoniecznie korzystasz z SSR, renderowania po stronie serwera, jeśli czekasz w przeglądarce, aby odkryć niektóre pakiety JavaScript, pakiety komponentów, niezależnie od tego, czy masz komponent do obrazu bohatera, czy obrazu produktu, jeśli przeglądarka musi czekać na pobranie, przeanalizowanie, wykonanie, skompilowanie i wykonanie wszystkich tych różnych plików, zanim będzie mogła wykryć obraz, może to oznaczać, że Twój największy obraz z treścią zajmie trochę czasu, zanim zostanie wykryty.

Addy Osmani: Teraz, jeśli tak jest, jeśli znajdziesz się w miejscu, w którym żądanie obrazu pojawia się dość późno, możesz skorzystać z funkcji przeglądarki o nazwie link rel preload, aby upewnić się, że przeglądarka może wykryć ten obraz tak wcześnie jak to możliwe. Teraz wstępne ładowanie to naprawdę potężna funkcja. Jest to również taki, o który trzeba bardzo uważać. W dzisiejszych czasach bardzo łatwo jest dostać się do miejsca, w którym być może słyszysz, że zalecamy wstępne ładowanie klucza-

Addy Osmani: Być może słyszysz, że zalecamy wstępne ładowanie obrazu głównego bohatera, a także skryptów i czcionek. I staje się po prostu naprawdę wielką, masywną próbą upewnienia się, że sekwencjonujesz rzeczy we właściwej kolejności. Tak więc obrazy LCP są zdecydowanie jednym z kluczowych miejsc, o których warto pamiętać.

Addy Osmani: Po drugie, jak wspomniałem o czterech rzeczach, drugą rzeczą jest upewnienie się, że używasz zestawu źródłowego i wydajnego nowoczesnego formatu obrazu. Myślę, że ten zestaw źródłowy jest naprawdę potężny. Widzę też, że czasami, gdy ludzie go używają, będą próbowali nadmiernie skompensować i być może wyślą tam 10 różnych wersji obrazów dla każdej możliwej rozdzielczości. Mamy tendencję do odkrywania, przynajmniej w niektórych badaniach, że poza trzema obrazami, użytkownikom naprawdę trudno jest powiedzieć, jakie są różnice w jakości obrazu, ostrości i szczegółowości. Tak więc capping DPR, ograniczanie współczynnika pikseli urządzenia, jest z pewnością pomysłem, o którym warto pamiętać.

Addy Osmani: A w przypadku nowoczesnych formatów obrazu rozmawialiśmy wcześniej o formatach, ale rozważmy WebP, AVIF, JPEG XL. Unikaj marnowania pikseli. To naprawdę ważne, aby mieć dobrą strategię dotyczącą jakości. I myślę, że jest wiele przypadków, w których nawet domyślna jakość może być czasami za duża. Dlatego poeksperymentowałbym z próbą obniżenia szybkości transmisji, obniżenia ustawień jakości i sprawdzenia, jak daleko możesz posunąć się dla swoich użytkowników, zachowując ostrość.

Addy Osmani: A kiedy mówimy o ładowaniu, jedną z innych rzeczy, które tag obrazu ewoluował, aby wspierać w ciągu ostatnich kilku lat, jest leniwe ładowanie. Dzięki temu, że ładowanie równa się leniwe, nie musisz już koniecznie używać biblioteki JavaScript, aby dodać leniwe ładowanie do swoich obrazów. Po prostu upuść to na swój obraz. A w przeglądarkach Chromium i Firefoksie będziesz mógł leniwie ładować te obrazy bez konieczności korzystania z zależności innych firm. I to też jest całkiem miłe.

Addy Osmani: Więc mamy leniwe ładowanie na miejscu. Mamy wsparcie dla innych rzeczy, takich jak dekodowanie synchronizacji, ale zamierzam kontynuować i mówić bardzo szybko o pozostałych dwóch podstawowych wskaźnikach kluczowych.

Drew McLellan: Zrób to, tak.

Addy Osmani: Więc pozbądź się zmian w układzie. Nikt nie lubi, jak rzeczy skaczą po ich stronach. Czuję, że jedną z moich największych frustracji jest otwieranie strony internetowej. Najeżdżam palcem na przycisk, który chcę kliknąć, a potem nagle pojawia się kilka reklam lub obrazów bez ustawionych wymiarów lub innych rzeczy. I powoduje to naprawdę nieprzyjemne wrażenia.

Addy Osmani: Tak więc skumulowana zmiana układu próbuje zmierzyć niestabilność treści. Często zdarza się, że typowe rzeczy, które powodują zmiany układu, to obrazy lub inne elementy na stronie, które po prostu nie mają ustawionego wymiaru. Myślę, że to jedno z tych miejsc, w których często łatwo jest ustalić wymiary obrazu. Może nie jest to coś, co historycznie robiliśmy tak często, ale z pewnością jest to coś, nad czym warto poświęcić swój czas. W narzędziach takich jak latarnia morska spróbuje pomóc Ci zbierać, na przykład jaka jest lista obrazów na Twojej stronie, które wymagają wymiarów? Więc możesz iść i możesz je ustawić.

Drew McLellan: Chciałem powiedzieć, że to naprawdę interesująca sprawa, ponieważ kiedy responsywne projektowanie stron internetowych stało się rzeczą, wszyscy przejrzeliśmy nasze witryny i usunęliśmy wymiary obrazu, ponieważ narzędzia, które mieliśmy do dyspozycji, aby wykonać tę pracę, wymagały tego. nie mają atrybutów wysokości i szerokości na naszych obrazach. Ale to teraz zły pomysł, prawda?

Addy Osmani: Co stare jest znowu nowe. Powiedziałbym, że zdecydowanie warto ustawić wymiary na swoich obrazach. Ustaw wymiary reklam, oprawek oczu, wszystkiego, co jest treścią dynamiczną, która potencjalnie może zmienić rozmiar, warto ustawić wymiary.

Addy Osmani: A dla ludzi, którzy budują naprawdę zabawne doświadczenia na zewnątrz, jest niewłaściwa fraza, naprawdę zabawne doświadczenia związane z układem, w których być może będziesz musiał trochę popracować nad responsywnymi kartami i tym podobnymi; Rozważałbym użycie pól proporcji CSS lub proporcji, aby zarezerwować miejsce. A to może być uzupełnieniem ustawiania wymiarów na tych obrazach, aby upewnić się, że wszystko jest tak stałe, jak to możliwe, gdy próbujesz uniknąć przesunięć układu.

Addy Osmani: I wreszcie ostatni Core Web Vital to pierwsze opóźnienie wejścia. To jest coś, o czym ludzie niekoniecznie zawsze myślą, jeśli chodzi o obrazy. W rzeczywistości obrazy mogą blokować przepustowość użytkownika i procesor podczas ładowania strony. Mogą przeszkadzać w ładowaniu innych krytycznych zasobów, w szczególności w przypadku naprawdę wolnych połączeń lub urządzeń mobilnych niższej klasy, co może prowadzić do nasycenia przepustowości.

Addy Osmani: Tak więc pierwsze opóźnienie wejścia jest podstawowym wskaźnikiem Web Vital, który rejestruje pierwsze wrażenie interaktywności i responsywności witryny. I tak, zmniejszając użycie procesora głównego wątku, twoje pierwsze opóźnienie wejściowe może być również zminimalizowane. Tak więc generalnie unikaj obrazów, które mogą powodować rywalizację w sieci. Nie blokują renderowania. Ale nadal mogą pośrednio wpływać na wydajność renderowania.

Drew McLellan: Czy jest coś, co możemy zrobić z obrazami, aby zapobiec blokowaniu renderowania? Czy możemy jakoś odciążyć przeglądarkę w tej początkowej fazie, aby umożliwić nam szybszą interakcję?

Addy Osmani: Myślę, że w dzisiejszych czasach coraz większe znaczenie ma dobre zrozumienie właściwej, optymalnej sekwencji obrazów do wyświetlania czegoś powyżej części zagięcia. Wiem, że nad zakładką jest przeładowany termin, ale jak w pierwszym widoku użytkownika. Bardzo często możemy skończyć na próbie zażądania całej masy zasobów, niektóre z nich to obrazy, które nie są tak naprawdę potrzebne do tego, co użytkownik natychmiast zobaczy. A te są świetnymi kandydatami do załadowania na późniejszym etapie cyklu życia strony, świetne rzeczy do leniwego ładowania na miejscu. Ale jeśli bardzo wcześnie prosisz o całą masę obrazów, na przykład całą kolejkę rzeczy, mogą one potencjalnie mieć wpływ.

Drew McLellan: Tak. Mam na myśli to, że wspomniałeś o leniwym ładowaniu obrazów, które historycznie wymagaliśmy od biblioteki JavaScript, która, jak sądzę, ma swoje wady, z powodu historycznych sposobów, w jakie przeglądarki optymalizują ładowanie obrazów, gdzie prawie niemożliwe jest powstrzymanie ich wczytywania obrazów , chyba że po prostu nie podasz mu źródła. A jeśli nie podasz mu źródła, a potem spróbujesz go poprawić za pomocą JavaScript, jeśli ten JavaScript nie zadziała, nie otrzymasz żadnych obrazów. Lazy loading, lazy loading natywne jest odpowiedzią na to wszystko.

Addy Osmani: Tak, absolutnie. I myślę, że jest to miejsce, w którym staraliśmy się poprawić w różnych przeglądarkach, natywne leniwe ładowanie w ciągu ostatniego roku. Jak wiecie, jest to jedna z tych funkcji, w których wysłaliśmy coś wcześnie i jesteśmy w stanie wykorzystać rozmowy z liderami myśli w branży, aby zrozumieć, jak: „Och, hej, jakie progi tak naprawdę ustawiasz ręcznie jeśli używasz leniwych rozmiarów lub używasz innych leniwych bibliotek ładujących JavaScript? A potem dostroiliśmy nasze progi, aby spróbować znaleźć się nieco bliżej tego, czego się spodziewasz.

Addy Osmani: W wielu przypadkach możesz po prostu użyć natywnego lazy loading. Jeśli potrzebujesz czegoś o wiele bardziej wyrafinowanego, jeśli potrzebujesz dużo większej kontroli nad możliwością ustawienia progów obserwatora skrzyżowania, punktu, w którym przeglądarka będzie żądać rzeczy, generalnie sugerujemy, aby w takich przypadkach skorzystać z biblioteki , tylko dlatego, że próbujemy rozwiązać problem użycia 90%. Ale 10% jest nadal ważne. Mogą być ludzie, którzy wciąż potrzebują czegoś więcej. Mam więc nadzieję, że dla większości ludzi leniwe ładowanie natywne będzie wystarczająco dobre w przewidywalnej przyszłości.

Drew McLellan: Przede wszystkim to nic nie kosztuje. Prosty atrybut do dodania, a całą tę funkcjonalność otrzymujesz za darmo, co jest świetne. Gdyby była jedna rzecz, którą nasz słuchacz mógłby zrobić, odejść i zrobić na swojej stronie, aby poprawić optymalizację obrazu, co by to było? Od czego powinni zacząć?

Addy Osmani: Dobrym punktem wyjścia jest zrozumienie, jak dużym problemem jest to dla Twojej witryny. Poszedłem i sprawdziłem albo latarnię morską, albo statystyki dotyczące prędkości. Uruchom go na kilku swoich najpopularniejszych stronach i zobacz, co z niego wyjdzie. Jeśli wygląda na to, że masz tylko jedną lub dwie małe rzeczy do zrobienia, to fantastycznie. Może mógłbyś tam poświęcić trochę czasu.

Addy Osmani: Jeśli masz długą listę rzeczy do zrobienia, może spójrz na największe możliwości, jakie masz tam, rzeczy, które mówią: „Och, hej, możesz zaoszczędzić wiele sekund, gdybyś zrobił to rzecz." I na początek skoncentruj tam swoją energię.

Addy Osmani: Jak już tutaj mówiliśmy, narzędzia do nowoczesnych formatów graficznych z biegiem czasu stawały się coraz lepsze. Wizerunkowe CDN z pewnością mogą być warte rozważenia. Ale poza tym jest wiele małych kroków, które możesz wykonać. Czasami, jeśli jest to wystarczająco mała witryna, nawet po prostu otwierając Squoosh, umieszczenie w niej kilku obrazów może być świetnym punktem wyjścia.

Drew McLellan: To dobra rada. Teraz wiem, że to świetna publikacja, ale naprawdę muszę ci pogratulować książki. Jest po prostu tak obszerny i naprawdę łatwy do strawienia. Myślę, że to naprawdę wartościowa lektura.

Drew McLellan: Więc nauczyłem się wszystkiego o optymalizacji obrazu. Czego się ostatnio dowiedziałeś, Addy?

Addy Osmani: O czym ostatnio się dowiedziałem? Właściwie, na nieco inny temat, który wciąż ma związek z obrazami, więc kiedy robiłem magisterkę na studiach, naprawdę zagłębiłem się w wizję komputerową i próbowałem zrozumieć, jak możemy wykryć różne części obrazu i zrobić dzikie i ciekawe rzeczy z nimi?

Addy Osmani: A specyficznym problemem, nad którym ostatnio się zagłębiałem, jest to, że oglądałem swoje zdjęcia, kiedy byłem niemowlakiem lub dzieckiem. W tamtych czasach dużo jedzenia, które moi rodzice brali, niekoniecznie pochodziło z aparatów cyfrowych. To były polaroidy. Często są to obrazy o nieco niskiej rozdzielczości. I chciałem mieć sposób na zwiększenie ich skali. I tak zacząłem ostatnio ponownie zagłębiać się w ten problem. Dzięki temu dowiedziałem się dużo więcej o tym, co mogę zrobić w przeglądarce.

Addy Osmani: Opracowałem więc kilka małych narzędzi, które za pomocą uczenia maszynowego, TensorFlow i istniejących technologii pozwalają wykonać obraz lub ilustrację o stosunkowo niskiej rozdzielczości, a następnie przeskalować je do znacznie wyższej jakości. Więc jest to lepsze niż zwykłe rozciąganie obrazu. To tak, jakby wypełniać szczegóły.

Addy Osmani: I to była dobra zabawa. Wiele się nauczyłem o tym, jak stabilny jest teraz montaż sieciowy w różnych przeglądarkach, jak dobrze można wykorzystać niektóre z tych pomysłów w przypadku zastosowań aplikacji komputerowych. I to było naprawdę zabawne. Tak więc ostatnio zagłębiałem się w wiele zespołów webowych. I to było fajne.

Drew McLellan: To zabawne, prawda? Kiedy pojawia się technologia, która stawia wszystko, co wiesz, na głowie. Zawsze mówiliśmy, że w sieci możemy zmniejszać obrazy. Ale jeśli mamy tylko mały obraz, nie możemy go powiększyć. To po prostu niemożliwe. Ale teraz mamy technologię, która w wielu okolicznościach może to umożliwić. To naprawdę fascynujące.

Drew McLellan: Jeśli, drogi słuchaczu, chciałbyś usłyszeć więcej o Addie, możesz znaleźć go na Twitterze, gdzie jest @AddieOsmani i znaleźć wszystkie jego projekty połączone z AddyOsmani.com. Książka „Optymalizacja obrazu” jest już dostępna fizycznie i cyfrowo w Smashing na smashingmagazine.com. Dzięki za przyłączenie się do nas dzisiaj, Addy. Czy masz jakieś pożegnalne słowa?

Addy Osmani: Jakieś słowa pożegnalne? Mam trochę dziwactwa z historii, którym podzielę się z ludźmi. Tim Berners-Lee przesłał pierwsze zdjęcie do internetu w 1992 roku. Nie jestem pewien, czy możesz zgadnąć, co to było, ale prawdopodobnie będziesz zaskoczony. Drew, masz jakieś domysły?

Drew McLellan: Zgaduję, że to kot.

Addy Osmani: Kot. To dobre przypuszczenie, ale nie. To było w CERN. A obraz przedstawiał właściwie zespół o nazwie Les Horribles Cernettes, który był parodią popową grupą utworzoną przez grupę pracowników CERN-u. A muzyka, którą grają, jest jak muzyka doo-wop. I śpiewali piosenki miłosne o zderzaczach, dziwactwach, ciekłym azocie i antymaterii w strojach z lat sześćdziesiątych, które uważałam za cudowne i przypadkowe.