Addy Osmani와 함께하는 스매싱 팟캐스트 에피소드 39: 이미지 최적화
게시 됨: 2022-03-10이 에피소드는 기업 웹사이트, 전자상거래 사이트, 모바일 앱, 화면 디스플레이 등 모든 플랫폼에서 강력한 콘텐츠 경험을 제공할 수 있도록 도와주는 Storyblok의 친애하는 친구의 도움을 받았습니다. 감사합니다!
오늘의 Smashing Podcast 에피소드에서는 이미지 최적화에 대해 이야기하고 있습니다. 2021년에는 퍼포먼스 이미지를 위해 어떤 단계를 따라야 할까요? 전문가인 Addy Osmani와 이야기를 나누었습니다.
메모 표시
- "이미지 최적화", Addy Osmani
- 트위터의 애디
- Addy의 개인 웹사이트
주간 업데이트
- :has, 네이티브 CSS 부모 선택기(및 기타)를 만나보세요
Adrian Bece가 작성 - 최근에 발견한 세 가지 프런트 엔드 감사 도구
저자 스테판 주디스 - 유용한 프론트 엔드 상용구 및 스타터 키트
코시마 미엘케가 쓴 - 잘 된 웹 디자인: 오디오 활용하기
저자 프레더릭 오브라이언 - CSS가 충분하지 않을 때: 액세스 가능한 구성 요소에 대한 JavaScript 요구 사항
저자 스테파니 에클스
성적 증명서
Drew McLellan: 그는 Google Chrome에서 작업하는 엔지니어링 관리자로, 그의 팀에서는 웹 속도를 빠르게 유지하는 데 도움이 되는 속도에 중점을 둡니다. 오픈 소스 커뮤니티에 헌신한 그의 과거 기여에는 Lighthouse, Workbox, Yeoman, Critical 및 to do NVC가 있습니다. 그래서 우리는 그가 웹 성능을 최적화하는 방법을 알고 있다는 것을 알고 있습니다. 그러나 그가 사무 오류로 인해 조연으로 오스카 여우주연상을 받고 싶어한다는 사실을 알고 계셨습니까? 멋진 친구들이여, Addy Osmani를 환영해주세요. 안녕하세요, 에디입니다. 잘 지내고 있나요?
Addy Osmani: 굉장 합니다.
Drew McLellan: 반갑 습니다. 저는 오늘 웹상의 이미지에 대해 이야기하고 싶었습니다. 지난 몇 년 동안 놀라울 정도로 많은 변화와 혁신이 있었던 영역이며 Smashing의 이미지 최적화에 관한 매우 포괄적인 책을 저술하셨습니다. “이제 이미지 최적화에 관한 책이 나올 때인가?”라는 생각을 하게 된 동기는 무엇인가요?
Addy Osmani: 좋은 질문입니다. 나는 이미지가 수십 년 동안 웹에서 꽤 중요한 부분을 차지했으며 우리의 두뇌가 텍스트보다 훨씬 빠르게 이미지를 해석할 수 있다는 것을 알고 있다고 생각합니다. 그러나 이 전반적인 주제는 시간이 지남에 따라 점점 더 흥미롭고 미묘한 차이가 나는 주제입니다. 그리고 저는 항상 사람들에게 이것이 아마도 제 세 번째 또는 네 번째 책일 것이라고 말합니다. 나는 의도적으로 책을 쓰기 시작하지 않았습니다.
Addy Osmani: 나는 이 책에서 이미지 최적화에 대한 기사를 쓰기 시작했고, 시간이 지남에 따라 우연히 그것에 관한 전체 책을 썼다는 것을 알게 되었습니다. 우리는 약 2년 동안 이 프로젝트를 진행했습니다. 그리고 그 당시에도 업계는 브라우저를 발전시키고 이미지와 이미지 형식을 중심으로 한 도구도 발전해 왔습니다.
Addy Osmani: 그래서 이 책을 쓰게 된 이유는 이러한 모든 변화를 파악하기가 어렵기 때문입니다. 그리고 저는 "나는 훌륭한 웹 시민이 될 것이고 내가 배운 모든 것을 한 곳에서 추적하여 다른 사람들이 그것을 활용할 수 있도록 노력할 것입니다."라고 생각했습니다.
Drew McLellan: 브라우저에서 많은 성능 최적화가 있는 영역 중 하나이며 빠르게 변화하는 환경입니다. 그렇죠? 현재의 모범 사례로 배운 기술에서 일부 기술 변화가 발생하고 실제로는 반패턴이며 해서는 안 된다는 것을 알게 됩니다. 그리고 지식을 계속 유지하고 올바른 기사를 읽고 올바른 내용을 배우고 2년 전의 것을 읽지 않았는지 확인하는 것은 매우 어렵습니다.
Drew McLellan: 그래서 권위 있는 출처에서 잘 연구된 한 권의 책에 모든 것을 모은다는 것은 정말 대단한 일입니다.
애디 오스마니: 네. 저자의 관점에서도 우리 편집 팀에게 가장 흥미로운 일이자 가장 스트레스를 주는 일 중 하나는 내가 한 챕터를 제출하고 완료되었다고 말하는 것이었습니다. 그리고 2주 후에 브라우저에서 무언가가 변경될 것입니다. 저는 "오, 잠깐만. 마지막 순간에 또 다른 변화를 주어야 합니다.”
Addy Osmani: 하지만 이미지 환경은 작년에도 상당히 많이 발전했습니다. 우리는 WebP 지원이 대부분의 최신 브라우저에서 마침내 결승선을 통과하는 것을 보았습니다. AVIF 이미지 지원은 Chrome에서 지원되며 Firefox, JPEG XL, 지연 로딩에 추가됩니다. 그리고 전반적으로 브라우저에서 웹의 이미지를 매우 구체적으로 사용하는 방법이 개선되었음을 확인했습니다. 그러나 다시 말하지만, 사람들이 맨 위에 유지해야 할 것이 많습니다.
Drew McLellan: 어떤 사람들은 이미지 최적화라는 주제를 꽤 냉정한 주제로 볼 수 있습니다. 우리 모두는 경력의 어느 시점에서 그래픽 소프트웨어에서 웹용으로 내보내는 방법을 배웁니다. 그리고 우리 중 일부는 내보낸 이미지를 가져와 ImageOptim과 같은 것을 통해 실행하는 습관을 가질 수 있습니다.
Drew McLellan: 따라서 사진 이미지일 때는 JPEG를 선택하고 그래픽 기반 이미지일 때는 PNG를 선택해야 하며, “알았어, 그것이다. 이미지 최적화를 알고 있습니다. 이제 끝입니다." 하지만 사실 그런 것들은 현시점에서 말뚝에 불과하지 않습니까?
Addy Osmani: 네, 그렇습니다. 아트 디렉션을 중요하게 생각하는지 여부에 따라 다른 컨텍스트에서도 보다 자세하고 선명한 이미지와 이미지를 표시하는 기능이 시간이 지남에 따라 진화했다고 생각합니다. 환경, 장치 제약, 네트워크 제약을 염두에 두고 최종 사용자에게 의도한 대로 이미지를 아름답게 보이게 하는 방법을 알아낼 필요가 있다는 것은 어려운 문제이며 많은 사람들이 여전히 알고 있는 것입니다. 와 싸우다.
Addy Osmani: 이미지에 대해 생각하고 "JPEG를 사용합시다" 또는 "PNG를 사용합시다"를 넘어 좀 더 세련된 해석을 얻을 때 이 가치에 몇 가지 차원이 있다고 생각합니다. 염두에두고. 첫 번째는 일반적으로 압축입니다. ImageOptim에 대해 언급하셨고 우리 중 많은 사람들이 이미지를 한 장소로 끌어다 놓고 뒤쪽에서 더 작은 것을 얻는 데 익숙합니다.
Addy Osmani: 이제 압축과 관련하여 우리는 일반적으로 다른 코덱에 대해 이야기하고 있습니다. 그리고 코덱은 일반적으로 파일을 인코딩하기 위한 인코더 구성 요소와 파일을 디코딩하고 압축 해제하기 위한 디코더 구성 요소가 있는 압축 기술입니다. 그리고 어떤 것을 사용하고 있는지 결정할 때 일반적으로 사용 중인 사진이나 이미지가 손실 압축 방식 또는 손실 감소 방식을 사용하여 접근하기에 괜찮은지 생각해야 합니다.
Addy Osmani: 사람들이 이러한 개념에 익숙하지 않은 경우를 대비하여 무손실 접근 방식은 압축 해제 시 맨 마지막에 정확히 동일한 파일을 재생하는 것입니다. 따라서 품질 측면에서 크게 손실되지 않습니다. 무손실은 팩스를 통해 이미지를 전송하는 것보다 훨씬 더 많습니다. 원본의 팩시밀리를 받았지만 원본 파일이 아닐 것입니다. 그곳에 다른 유물이 있을 수 있습니다. 미묘하게 다르게 보일 수 있습니다. 그러나 일반적으로 압축을 많이 할수록 일반적으로 더 많은 품질을 잃게 됩니다.
Addy Osmani: 그래서 이 모든 최신 이미지 코덱을 사용하여 사용 사례에 따라 비교적 적절한 파일 크기를 유지하면서 얼마나 많은 품질을 뽑아낼 수 있는지 확인하려고 합니다.
Drew McLellan: 기술적인 관점에서 보면 원본 이미지와 대상 파일 형식이 있습니다. 그러나 하나를 다른 것으로 바꾸는 과정은 논쟁의 여지가 있습니다. 준수하는 파일이 있는 한 이를 수행하는 방법은 다양한 구현을 가질 수 있는 코덱에 달려 있으며 일부는 다른 것보다 더 나을 것입니다.
Addy Osmani: 물론입니다. 전적으로. 그리고 다시 JPEG와 PNG로 시작했던 곳으로 돌아가서 사람들은 JPEG가 사진의 손실 압축을 위해 만들어졌다는 것을 알 수 있을 것이라고 생각합니다. 일반적으로 파일 뒷면에서 더 작은 파일을 얻을 수 있으며 때로는 다른 밴딩 아티팩트가 있을 수 있습니다. PNG는 원래 무손실 압축을 위해 만들어졌으며 사진이 아닌 이미지에서 꽤 잘 작동합니다.
Addy Osmani: 하지만 그 이후로 상황이 발전했습니다. 2010년 즈음, 우리는 JPEG와 PNG를 대체할 예정인 WebP에 대한 지원을 받기 시작했고 압축률에서 약간 앞섰습니다. 그러나 그 이후로 테이블에 있는 이미지 형식과 옵션의 수가 급증했습니다. 나는 상황이 일반적으로 좋은 방향으로 가고 있다고 생각합니다. 특히 AVIF 및 JPEG XL과 같은 최신 형식의 경우 더욱 그렇습니다. 하지만 우리가 여기까지 오기까지 시간이 좀 걸렸습니다. 모든 브라우저에서 WebP 지원을 받는 것조차 상당한 시간이 걸렸습니다.
Addy Osmani: 그리고 궁극적으로 개발자들이 그것을 요구했는지 확인하고, 이러한 최신 형식에서 더 나은 압축을 얻을 수 있기를 원하는 욕구, 브라우저 간에 좋은 호환성을 갖기를 원하는 욕구가 궁극적으로 영향을 미쳤다고 생각합니다. 이런 것들에 대해서도.
드류 맥렐런: 네. WebP는 형식 내에서 사용 가능한 무손실 및 손실 압축이 있을 뿐만 아니라 결과적으로 파일 크기가 훨씬 줄어들기 때문에 저에게 정말 흥미로운 것 같습니다. 그리고 좋은 브라우저 지원이 있으며 Google 및 Netflix와 같은 대기업과 다양한 대기업에서 채택하고 있습니다.
Drew McLellan: 하지만 업계에서 내 생각은 풀뿌리 수준에서 같은 종류의 수용을 보지 못한다는 것입니다. WebP는 여전히 그 날을 기다리고 있습니까?
Addy Osmani: WebP가 도래하고 있다고 생각합니다. 많은 사람들이 Safari 및 WebKit 지원이 구체화되기를 기다리고 있었고 마침내 구현했습니다. 그러나 새로운 이미지 형식에 대해 생각할 때 지원이 실제로 의미하는 바를 이해하는 것이 매우 중요합니다. 해당 이미지 디코딩을 위한 브라우저 지원이 있습니다. 또한 노드 환경에 있든 이미지 CDN에 있든 CMS에 있든 해당 이미지 형식을 사용할 수 있도록 하려면 정말 좋은 도구 지원이 필요합니다.
Addy Osmani: 몇 년 전 WebP가 처음 나왔을 때를 기억합니다. 얼리 어답터는 WebP 파일을 데스크탑에 저장한 다음 갑자기 “오, 잠깐만. 이것을 보려면 내 브라우저로 드래그해야 합니까?" 또는 "사용자가 WebP를 다운로드하는 경우 중단되어 무슨 일이 일어나고 있는지 궁금해할까요?"
Addy Osmani: 따라서 운영 체제 수준과 다른 컨텍스트 모두에서 이미지 형식에 대한 전체론적 지원이 있는지 확인하는 것은 이미지 형식이 도약하기 위해 정말 중요하다고 생각합니다. 또한 이미지를 제공하는 사람들이 이러한 사용 사례에 대해 조금 생각하는 것도 중요하므로 내가 파일을 저장하거나 다운로드할 때 일반적으로 사람들이 쉽게 공유할 수 있는 휴대용 형식으로 저장하려고 합니다. 그리고 이것이 적어도 iOS에서 iOS가 하이킹과 하이픈을 지원하는 곳이라고 생각합니다. 그리고 필요할 때 JPEG로 변환하면 사람들이 공유할 수 있습니다.
Addy Osmani: 따라서 더 나은 압축을 제공하는 동안 사용자가 손실을 입지 않도록 할 수 있는 사용 사례 유형을 고려하는 것이 중요하다고 생각합니다.
Drew McLellan: 상상할 수 있듯이 수십만 개의 이미지를 처리하는 슬라이드 공유 서비스가 있습니다. 그리고 제가 WebP를 보고 있을 때 아마 3년 전이었을 것입니다. 저는 주로 CDN 대역폭 비용을 줄이는 방법을 찾고 있었습니다. 왜냐하면 더 작은 파일을 제공하는 경우 더 적은 비용이 청구되기 때문입니다. 그러나 레거시 이미지 형식인 풀백 이미지도 여전히 필요했지만 계산에 따르면 전체 다른 이미지 세트를 저장하는 비용이 더 작은 파일을 제공하는 이점보다 큽니다. 이제 2021년입니다. 이 시점에서 재고해야 하는 결정입니까?
Addy Osmani: 저는 그것이 정말 중요한 고려 사항이라고 생각합니다. 때때로 이미지 전략에 접근하는 방법에 대해 이야기할 때 사람들에게 "이봐, 네. 5가지 다른 형식을 생성하기만 하면 무한대로 확장됩니다." 항상 그런 것은 아닙니다.
Addy Osmani: 스토리지를 염두에 두어야 할 때 사용자에게 서비스를 제공하는 데 가장 일반적인 것이 무엇인지 찾으려고 노력하는 경우가 있다는 점을 염두에 둘 가치가 있다고 생각합니다. 요즘은 사실 WebP가 그 공통분모로 고려해볼만하다고 말하고 싶습니다. 조건부로 사람들에게 다양한 형식을 제공하기 위해 사진 태그를 사용하는 데 익숙한 사람들의 경우 일반적으로 JPEG를 주요 대체 수단으로 사용합니다. 아주 오래된 브라우저를 사용하는 사람이 없는 한 요즘에는 대부분의 사용자를 대신하여 WebP를 실제로 사용하는 것이 괜찮을 수도 있습니다. 그리고 요즘에는 그런 일이 많이 줄어들고 있다고 생각합니다. 하지만 분명히 유연성이 있습니다.
Addy Osmani: 이제 앞으로 나아가고자 한다면 정말 효과가 있다고 생각되는 형식을 선택하라고 말하고 싶습니다. 필요에 따라 확장되고 유연한 방식으로 스토리지에 접근할 수 있다면 사람들이 해야 할 일은 JPEG XL을 고려하는 것입니다. 기술적으로 아직 브라우저에서 제공되지 않습니다. 그렇다면 JPEG XL은 손실 또는 무손실 사용 사례 또는 사진이 아닌 사용 사례의 많은 사진에 매우 좋은 옵션이 될 것입니다. 그리고 아마도 WebP V1보다 훨씬 나을 것입니다. 그래서 한 곳입니다.
Addy Osmani: 정말 낮은 비트 전송률로 이동해야 하는 경우 AVIF가 더 나을 것이라고 생각합니다. 아마도 당신은 대역폭에 대해 많은 관심을 가질 것입니다. 이미지 충실도에 대해 조금 덜 신경을 쓸 수도 있습니다. 그리고 그 비트 전송률에서 나는 그것이 다른 대안들보다 더 선명하게 보인다고 상상할 수 있었습니다. 그리고 JPEG XL이 나올 때까지 나는 당신의 분석을 살펴보고 당신이 AVIF를 제공할 수 있는지 이해하려고 노력할 것입니다. 그렇지 않으면 WebP에 집중할 것입니다. 당신이 분석 전문가라면 대부분의 사람들이 WebP를 제공받을 수 있고 WebP에서 염색체 샘플링이 완벽하지 않을 수 있는 곳인 광역 또는 텍스트 오버레이에 대해서는 조금 덜 신경을 쓸 것입니다. 그것은 확실히 기억할 가치가 있습니다.
Addy Osmani: 그래서 모든 사람에게 딱 맞는 사이즈는 없다는 것을 염두에 두려고 노력할 것입니다. 저는 개인적으로 요즘 이미지 CDN을 사용하기 때문에 스토리지 및 송신 및 대역폭 비용에 대해 조금 덜 걱정하고 있습니다. 그리고 개인적으로 Cloudinary를 사용하게 되어 기쁩니다. 우리는 내가 일하는 곳에서 다양한 이미지 CDN을 사용합니다. 하지만 이미지 파이프라인을 처리하는 유지 관리 비용에 대해 크게 걱정할 필요가 없다는 것을 알게 되었습니다. ,” 그것은 나를 위해 그것을 돌봐주는 것에 투자하는 좋은 이점이었습니다.
Addy Osmani: 그리고 제 사용 사례의 전체 비용은 괜찮았습니다. 그러나 그 규모에서 슬라이드 서비스를 실행하는 경우 반드시 선택 사항이 아닐 수도 있다고 충분히 상상할 수 있습니다.
드류 맥렐런: 네. 그래서 저는 이러한 미래의 형식 중 일부로 돌아오고 싶습니다. 그러나 나는 그것이 어떤 종류의 성능 도구, Lighthouse 또는 WebPageTests를 사용하여 우리 중 누군가가 이를 통해 사이트를 실행하는 경우 그것이 제안할 핵심 사항 중 하나가 이미지에 CDN을 사용한다는 것이기 때문에 파고들 가치가 있다고 생각합니다. 그리고 그것은 매우 큰 회사에서 할 수 있는 매우 현실적인 일입니다. 현실적이고 소규모 웹사이트와 앱을 구축하는 사람들의 손이 닿을 수 있는 범위 내에 있습니까? 아니면 실제로 그렇게 하기가 말처럼 쉬운가요?
Addy Osmani: 사람들이 물어야 할 질문은 "이미지를 사용하는 용도는 무엇입니까?"입니다. 이미지가 몇 개 없고 블로그를 만들고 추가하는 이미지가 비교적 단순하다면 수백, 수백, 수천 개의 이미지가 없는 경우 이 정도만 접근해도 괜찮을 것입니다. 빌드 시 몇 가지 NPM 패키지를 설치하는 매우 정적인 방식으로. 아마도 당신은 Sharp를 사용하고 있을 것입니다. 그리고 그것은 대부분 당신을 돌봐줍니다.
Addy Osmani: 여러 형식을 생성하는 데 도움이 되는 도구가 있습니다. 빌드 시간이 약간 증가하지만 실제로 많은 사람들에게 괜찮을 수 있습니다. 그리고 여러 기능을 활용할 수 있기를 원하는 사람들을 위해
Addy Osmani: 그리고 여러 형식을 활용할 수 있기를 원하는 사람들은 도구의 사소한 부분을 너무 많이 처리하고 싶지 않고 정말 풍부한 반응형 이미지나 스토리를 제자리에 넣을 수 있기를 원합니다. 이미지 CDN을 사용해보십시오. 저는 개인적으로 처음에는 비용 문제로 인해 개인 프로젝트에 사용하는 것에 대해 상당히 주저했지만, 시간이 지남에 따라 청구서를 살펴보니 실제로 이러한 문제를 해결하는 데 투자하는 시간을 절약할 수 있다는 것을 깨달았습니다. 과거에 이미지를 처리하기 위해 얼마나 많은 사용자 지정 스크립트를 작성해야 했는지 모르겠지만 한 달에 이러한 다양한 npm 패키지를 통해 디버깅하는 데 드는 최소한 이틀을 절약할 수 있다면 비용을 절감할 수 있다는 것을 깨달았습니다. 내가 절약하고 있는 시간을 잘 관리하고 있으니 괜찮습니다.
Addy Osmani: 하지만 100~1000개 또는 수백만 개의 이미지로 확장하는 경우 수익이 반드시 포함되어야 하거나 지불할 준비가 되어 있지 않은 경우에 대해 생각할 필요가 있습니다. 대체 전략. 그리고 저는 오늘날 우리가 사용할 수 있는 도구에 유연성이 충분하여 이러한 방향 중 하나로 갈 수 있다는 것은 운이 좋다고 생각합니다. 우리는 조금 더 관습적인 일을 하거나 스스로 해결하거나 우리 자신의 이미지 CDN 또는 약간 더 상업적인 무언가에 투자합니다. 그리고 우리는 일부 사용 사례의 경우 이미지 CDN을 사용할 수 있고 저렴하다고 말할 수 있는 위치에 있습니다.
Drew McLellan: 일종의 지침 원칙 중 하나는 항상 민첩하고 변화에 대비하는 것입니다. 그리고 이미지 CDN을 사용하여 이미지가 요청될 때 동적으로 이미지를 변환하는 것으로 시작할 수 있으며, 이것이 비용 측면에서 지속 가능하지 않은 지점에 도달하면 다른 솔루션을 살펴보고 코드 기반을 다음 상태로 만들 수 있습니다. 한 솔루션을 다른 솔루션으로 쉽게 대체할 수 있습니다. 일반적으로 어디에서나 타사 서비스에 의존하는 것이 좋은 원칙이라고 생각합니다. 그렇지 않습니까? 그래서 이러한 다가오는 이미지 형식, 당신은 JPEG XL을 언급했습니다. JPEG XL이란 무엇입니까? 어디에서 왔습니까? 그리고 그것은 우리에게 무엇을 합니까?
Addy Osmani: 훌륭한 질문입니다. 따라서 JPEG XL은 차세대 이미지 형식이며 범용으로 간주되며 JPEG 위원회의 코덱입니다. Google의 pic 형식과 Cloudinary의 FUIF 형식에 일부 뿌리를 두고 시작되었습니다. 수년 동안 이러한 노력에 의해 포함된 많은 형식이 있었지만 개별 부분의 합 그 이상이 되었으며 JPEG XL의 장점 중 일부는 고화질에 탁월하다는 것입니다. 이미지, 무손실에 정말 좋습니다. 프로그레시브 디코딩, 무손실 JPEG 트랜스코딩을 지원하며 소란과 로열티 프리도 있어 확실히 이점이 있습니다. 저는 JPEG XL이 잠재적으로 정말 강력한 후보가 될 수 있다고 생각합니다. 우리는 이전에 한 가지만 선택한다면 무엇을 사용하겠습니까?에 대해 이야기했습니다. 그리고 저는 JPEG XL이 그런 가능성을 가지고 있다고 생각합니다.
Addy Osmani: 나는 또한 너무 많은 약속을 하고 싶지 않습니다. 우리는 아직 브라우저 지원이 매우 초기 단계에 있습니다. 그래서 저는 우리가 실제로 얼마나 잘 정렬되고 사람들의 기대를 충족하는지 실제로 기다리고 보고 실험하고 평가해야 한다고 생각합니다. 현재로서는 Chrome이 지원 측면에서 가장 앞서 있다고 생각하지만 Mozilla 측과 다른 브라우저에서도 이에 대한 관심이 확실히 있어 JPEG XL의 미래가 기대됩니다. 그리고 우리가 말하면 사람들에게 더 짧은 기간의 관심은 무엇입니까? 물론 AVIF도 있습니다.
Drew McLellan: AVIF에 대해 말씀해 주십시오. 이것은 제가 잘 모르는 또 다른 것입니다.
Addy Osmani: 알겠습니다. 그래서 우리는 낮은 비트 전송률로 이동해야 하고 이미지 충실도보다 대역폭에 더 관심이 있는 경우 AVIF가 더 나은 후보일 수 있다는 점에 대해 조금 앞서 언급했습니다. 일반적으로 AVIF는 실제로 저충실도 높은 호소력 압축에서 선두를 달리고 있습니다. 그리고 JPEG XL은 중간에서 높은 충실도에서 탁월해야 하지만 형식 자체가 약간 다릅니다. 우리는 AVIF가 점점 더 좋은 브라우저 지원을 받는 위치에 있지만 한 걸음 물러나서 형식에 대해 조금 더 이야기하겠습니다. 따라서 AVIF 자체는 Alliance for Open Media에서 표준화한 AV1 비디오 코덱을 기반으로 하며, 앞서 이야기한 WebP를 통해 JPEG보다 상당한 압축 이점을 사람들에게 제공하려고 합니다. AVIF에서 얻을 수 있는 정확한 절감 효과는 콘텐츠와 품질 목표에 따라 다르지만 JPEG에 비해 50% 이상 절감할 수 있는 경우를 많이 보아왔습니다.
Addy Osmani: 좋은 기능이 많이 있으며 높은 동적 범위 및 넓은 색 영역, 필름 그레인 합성과 같은 새로운 기능에 대한 컨테이너 지원을 제공할 수 있습니다. 그리고 다시, 전방을 향하는 것에 대해 이야기하는 것과 유사하게 그림 태그의 좋은 점 중 하나는 사용자에게 지금 AVIF 파일을 제공할 수 있고 반드시 지원되지 않는 경우에도 WebP 또는 JPEG로 대체된다는 것입니다. . 그러나 Photoshop 웹용 저장에 대한 예제로 돌아가서 크기가 500킬로바이트인 JPEG를 사용하여 Photoshop 웹용 저장과 비슷한 품질로 촬영할 수 있으며 AVIF를 사용하면 다음과 같은 결과를 얻을 수 있습니다. 파일 크기가 약 90킬로바이트, 100킬로바이트인 지점에서 품질의 눈에 띄는 손실 없이 상당한 절감 효과를 얻을 수 있습니다.
Addy Osmani: 그리고 그것에 대한 좋은 점 중 하나는 이상적으로는 디테일이 풍부한 이미지에서 텍스처 손실이 많이 발생하지 않는다는 것입니다. 따라서 숲이나 캠핑 또는 그런 종류의 사진이 있는 경우 AVIF를 사용하면 여전히 풍부해 보일 것입니다. 그래서 저는 AVIF가 지향하는 방향에 대해 매우 흥분하고 있습니다. 도구 지원 측면에서 조금 더 많은 작업이 필요하다고 생각합니다. 그래서 나는 일전에 이것에 대해 트윗을 남겼습니다. 우리는 지금 AVIF를 사용할 수 있는 많은 옵션을 가지고 있습니다. 단일 이미지의 경우 Chrome의 다른 팀이 작성한 Squoosh, squoosh.app이 있습니다. Squoosh 작업에 대해 Surma와 Jake에게 감사합니다. Avif.io는 현재 AVIF를 사용하려는 사람들을 위한 여러 가지 좋은 옵션을 제공합니다. 어떤 기술 스택에 중점을 두든 Sharp는 AVIF도 지원합니다.
Addy Osmani: 하지만 일반적으로 Figma, Sketch, Photoshop 또는 다른 장소에서 우리가 이미지를 다루는 다른 장소에 대해 생각합니다. AVIF 지원은 개발자와 사용자가 실제로 착륙하고 집으로 돌아온 것처럼 느낄 수 있도록 유비쿼터스해야 하기 때문입니다. 그리고 현재 Chrome에서 AVIF 작업을 하고 있는 팀이 도구를 꽤 좋은 곳으로 가져갈 수 있도록 노력하고 있는 우리의 초점 영역 중 하나입니다.
Drew McLellan: 이제 HTML에 그림 요소가 포함되어 기존 이미지 태그에 비해 유연성이 높아졌습니다. 이미지 태그도 먼 길을 왔지만 그렇지 않습니까? 그러나 우리는 사진이 추가되는 것을 보았고 네이티브 비디오 태그와 거의 같은 시기에 HTML5 변경의 원래 배치에서 생각했습니다. 그리고 이것은 우리에게 여러 소스를 지정할 수 있는 기능을 제공합니다. 맞습니까?
Addy Osmani: 네, 맞습니다.
Drew McLellan: 따라서 다양한 이미지 형식을 나열할 수 있으며 브라우저는 지원하는 형식을 선택합니다. 따라서 이전 브라우저를 사용하는 사람들이 문제를 일으키지 않을까 걱정할 필요 없이 바로 실험적인 작업을 할 수 있습니다.
Addy Osmani: 물론입니다. 우리가 방향에 대해 생각하고 있는 사용 사례 외에 그림 태그를 사용하는 가장 좋은 이점 중 하나라고 생각합니다. 사람들에게 이미지를 제공하고 브라우저가 잠재적 소스 목록을 살펴보고 알도록 할 수 있다는 것입니다. 글쎄, 나는 내가 이해하는 목록의 첫 번째 것을 사용할 것입니다. 그렇지 않으면 대체하겠습니다. 이것은 사람들에게 정말 강력한 기능입니다. 동시에 우리가 여러 형식을 지원하려고 하고 해당 형식에 대해 다른 크기를 고려할 때 마크업의 정말 거대한 덩어리를 재생성하고 있다는 우려나 우려를 표현하는 사람들도 있다고 생각합니다. 갑자기 부피가 좀 커집니다.
Addy Osmani: 그렇다면 이러한 문제에 접근할 수 있는 다른 방법이 있습니까? 나는 이미지 CDN에서 사람들을 너무 많이 팔고 싶지 않고 그들이 스스로 설 수 있기를 바랍니다. 그러나 이것은 콘텐츠 협상이라는 아이디어가 실제로 흥미로운 경로를 제공할 수 있는 곳 중 하나입니다. 그래서 우리는 다양한 리소스를 생성하고 기본 설정, 바로 추가 HTML을 결정해야 하는 그림 태그에 대해 조금 이야기했습니다. 콘텐츠 협상을 통해 모든 작업을 서버에서 수행할 수 있습니다. 따라서 클라이언트는 Accept HTTP 헤더를 통해 MIME 유형 목록을 통해 미리 지원하는 형식을 서버에 알릴 수 있습니다. 그러면 서버는 궁극적인 리소스를 생성 및 관리하고 클라이언트에 보낼 리소스를 결정하는 모든 무거운 작업을 수행할 수 있습니다. 여기에서 강력한 기능 중 하나는 이미지 CDN을 사용하는 경우 단일 리소스를 가리킬 수 있다는 것입니다.
Addy Osmani: 그래서 아마도 우리가 강아지.JPEG와 같은 강아지 이미지를 가지고 있다면, 우리는 사람들에게 강아지.JPEG에 대한 URL을 줄 수 있고 그들의 브라우저가 WebP를 지원하거나 AVIF를 지원한다면 서버는 올바른 서비스를 제공하는 것에 대해 정말 똑똑해질 수 있습니다. 지원 방식에 따라 해당 사용자에게 이미지를 제공할 수 있지만, 그렇지 않으면 많은 추가 작업을 직접 수행할 필요 없이 대체할 수 있습니다. 저는 그것이 강력한 아이디어라고 생각합니다. 서버에서 할 수 있는 일이 많습니다. 우리는 때때로 모든 사람이 정말 강력한 네트워크 품질에 액세스할 수 있는 것은 아니라는 이야기를 합니다. 효과적인 연결 유형은 현재 위치에 따라 매우 다를 수 있습니다.
Addy Osmani: 실리콘 밸리에 살면서도 커피숍에서 호텔까지 걸어서 갈 수도 있고 차 안에 있을 수도 있고 Wi-Fi나 신호 품질이 좋지 않을 수 있습니다. 따라서 여기에서 다른 API에 액세스할 수 있습니다. Save-Data 클라이언트 힌트와 같은 다른 아이디어는 사용자가 데이터 절약을 선택한 경우 잠재적으로 더 작은 리소스로 사람들에게 서비스를 제공할 수 있다는 것입니다. 따라서 서버 측에서 할 수 있는 흥미로운 일이 많이 있으며 시장 경로를 수행하는 데 익숙한 사람들이 모든 유연성을 가질 수 있는 좋은 균형을 찾는 아이디어를 계속 추진해야 한다고 생각합니다. 약간 더 마법 같은 솔루션을 원하는 사람들에게도 몇 가지 옵션이 있습니다.
Drew McLellan: 이러한 종류의 데이터 보호기 접근 방식의 개념은 제가 당신의 책에서 처음 배운 것입니다. 제 말은, 그것이 꽤 흥미롭기 때문에 조금 더 들어가 보겠습니다. 따라서 브라우저가 데이터 사용량 감소 또는 배터리 부족 등으로 인해 감소된 데이터 경험을 원한다는 기본 설정 신호를 보낼 수 있다는 의미입니다.
Addy Osmani: 맞습니다. 정확히. 나는 평소보다 훨씬 더 많이 여행하게 될 그 이전이나 예전에 여행을 했고, 전 세계에서 내 네트워크 품질이 정말 열악하거나 정말 얼룩덜룩할 수 있는 상황이나 상황을 많이 경험했습니다. 웹 페이지를 만드는 것은 실망스럽거나 어려운 경험이 될 수 있습니다. 메뉴를 찾아보고 있는데 그곳에 있는 아름다운 음식 사진을 볼 수 없다면 갈 수 있는 곳으로 가거나, 잘 모르겠지만 대신 음식을 만들 수도 있습니다. 하지만 데이터 세이버의 흥미로운 점 중 하나는 사용자의 기본 설정에 대한 연결을 제공한다는 것입니다. 따라서 사용자로서 네트워크 연결에 어려움을 겪고 있음을 알고 있습니다. "알겠습니다. 브라우저에서 데이터 절약 모드를 선택하겠습니다."라고 말할 수 있습니다.
Addy Osmani: 그런 다음 개발자로서 이를 신호로 사용할 수 있습니다. "그래, 사용자는 약간 제한적입니다. 아마도 훨씬 더 작은 이미지나 훨씬 낮은 품질의 이미지를 검색할 것입니다." 그러나 그들은 여전히 일부 이미지를 볼 수 있습니다. 이는 훨씬 더 풍부한 것이 제공되기를 아주 오랫동안 기다리는 것보다 낫습니다. 이러한 유형의 신호의 다른 이점은 조건부로 미디어를 제공하는 데 사용할 수 있다는 것입니다. 따라서 해당 페이지에서 텍스트가 가장 중요한 경우가 있을 수 있습니다. 사용자가 제한된 환경에 있다는 것을 발견하면 해당 이미지를 끌 수 있습니다. 나는 이것에 대해 30초만 할애할 것이지만, 당신은 이 아이디어를 극도로 밀어붙일 수 있습니다. Save-Data로 할 수 있는 흥미로운 작업 중 일부는 JavaScript에서 구현된 매우 값비싼 기능을 끄는 것입니다.
Addy Osmani: 약간 더 선택적인 것으로 간주되는 특정 구성 요소가 있는 경우 경험을 향상시키기만 하면 해당 구성 요소를 모든 사용자에게 보낼 필요가 없을 수도 있습니다. 여전히 모든 사람에게 매우 핵심적이고 작고 빠른 경험을 제공할 수 있으며 더 빠른 연결 또는 장치를 가진 사람들을 위해 멋진 설탕 장식으로 레이어링하기만 하면 됩니다.
Drew McLellan: 잠재적으로 페이지 매김을 고려하여 100개가 아닌 10개의 결과를 한 페이지에 반환할 수 있습니다. 흥미롭고 흥미로운 기능이 많이 있습니다. 새 사이트를 준비하고, 모든 이미지를 최적화하고, 클라이언트에게 전달하고, 콘텐츠를 관리할 CMS를 제공하고, 모든 것을 최적화되지 않은 이미지. 다시 말하지만, 이미지 CDN은 이에 대한 정말 편리한 솔루션이 될 수 있지만 다른 솔루션이 있습니까? CMS가 서버에서 이를 지원하기 위해 수행할 수 있는 작업이 있습니까? 아니면 이미지 CDN이 아마도 아마도 잘 했어?
Addy Osmani: 모든 사람이 자신의 이미지를 최적화하도록 노력한 후 최소 6~7년 동안 우리가 발견한 것은 사진에 관련된 일부 사람들이 기술적으로 약간 더 정통하고 편안한 설정일 수 있는 어려운 문제라는 것입니다. 자체 도구를 만들거나 Lighthouse를 계속 실행하거나 다른 도구를 사용하여 개선할 기회가 있는지 알려주십시오. 더 최적화하거나 적절한 크기의 이미지를 제공할 기회가 있는지 파악하기 위해 Lighthouse와 같은 것을 지속적으로 사용하는 사람들을 보고 싶습니다. 업로드하는 리소스의 비용도 이해해야 합니다. 이것은 우리가 흔히 겪는 일이며 죄송합니다. 사람들을 너무 많이 부르지는 않겠지만 이것은 Google 블로그에서도 우리가 겪는 일입니다.
Addy Osmani: 2주마다 Google 블로그에 누군가가 20 또는 30MB의 매우 큰 애니메이션 GIF를 업로드하도록 할 것입니다. 그리고 나는 그들이 그것이 좋은 생각이 아니라는 것을 알 것으로 기대하지 않습니다. 그들은 기사를 멋지고 매우 매력적이며 대화식으로 보이게 하려고 노력하고 있습니다. 그러나 그러한 청중은 이동하여 도구를 실행하거나 ImageOptim을 사용하는 방법을 반드시 알지는 못할 것입니다. 또는 이러한 다른 도구를 제자리에 사용하고 문서화하여 확인해야 하는 것은 확실히 하나의 옵션입니다. 그러나 문제를 자동화할 수 있다는 것은 매우 매력적이며 기술적인 것이든 비기술적인 것이든 모든 CMS 사용자의 요구 사항의 균형을 유지하는 데 지속적으로 도움이 된다고 생각합니다. 사용자의 필요에 따라.
Addy Osmani: 그래서 이미지 CDN이 확실히 도움이 될 수 있다고 생각합니다. 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? 우리는 무엇을 할 수 있습니까?
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: 그래서 레시피 사이트에 가려고 할 때 레시피가 어떻게 보이는지 신경을 쓸 수 있으므로 레시피의 큰 영웅 이미지가 나에게 보이도록 하는 데 관심이 있습니다. 이제 LCP 요소는 시간이 지남에 따라 변경될 수 있습니다. 로드 초기에는 가장 큰 것이 제목일 가능성이 매우 높지만 페이지가 계속 로드되면서 실제로는 훨씬 더 큰 이미지나 일종의 포스터가 될 수 있습니다.
Addy Osmani: 따라서 가장 큰 내용이 포함된 페인트를 최적화하려고 할 때 할 수 있는 작업은 약 4가지입니다. 첫 번째는 가능한 한 빨리 주요 영웅 이미지를 요청하고 있는지 확인하는 것입니다. 일반적으로 이 페이지에는 중요한 여러 가지가 있습니다. 메인 페이지의 콘텐츠와 레이아웃을 렌더링할 수 있는지 확인하고 싶습니다.
Addy Osmani: 레이아웃의 경우 일반적으로 CSS에 대해 이야기하고 있습니다. 따라서 페이지에서 중요한 CSS, 인라인 CSS를 사용하고 있을 수 있으며 렌더링 차단을 피하고 싶지만 이미지와 관련하여 이상적으로는 해당 이미지를 일찍 요청해야 합니다. 아마도 오늘날 많은 사람들이 프레임워크에 의존하고 있다는 점을 감안할 때 브라우저가 페이지에서 가능한 한 빨리 해당 이미지를 발견할 수 있도록 하는 것과 관련이 있을 것입니다.
Addy Osmani: SSR, 서버 측 렌더링을 반드시 사용하고 있지 않다면 브라우저에서 JavaScript 번들, 구성 요소 번들 중 일부를 발견하기를 기다리고 있다면 영웅 이미지 또는 제품 이미지에 대한 구성 요소가 있는지 여부에 관계없이 브라우저가 이미지를 검색하기 전에 이러한 다양한 파일을 모두 가져오고, 구문 분석하고, 실행하고, 컴파일하고 실행하기 위해 기다려야 하는 경우 콘텐츠가 포함된 가장 큰 이미지가 검색되기까지 시간이 걸릴 수 있습니다.
Addy Osmani: 그렇다면 이제 이미지가 꽤 늦게 요청되는 위치에 있는 자신을 발견하면 link rel preload라는 브라우저 기능을 활용하여 브라우저가 해당 이미지를 조기에 발견할 수 있도록 할 수 있습니다. 가능한 한. 이제 예압은 정말 강력한 기능입니다. 신경을 많이 써야 하는 부분이기도 합니다. 요즘에는 키에 미리 로드를 권장한다는 소식을 듣게 되는 경우가 많습니다.
Addy Osmani: 주요 영웅 이미지, 주요 스크립트 및 주요 글꼴에 대한 사전 로드를 권장한다는 소식을 들었을 수도 있습니다. 그리고 그것은 당신이 올바른 순서로 물건을 배열하고 있는지 확인하기 위해 정말 크고 방대한 것이 됩니다. 따라서 LCP 이미지는 확실히 이를 염두에 둘 가치가 있는 핵심 위치 중 하나입니다.
Addy Osmani: 네 가지를 언급했듯이 다른 하나는 소스 세트와 효율적인 최신 이미지 형식을 사용하고 있는지 확인하는 것입니다. 나는 그 소스 세트가 정말 강력하다고 생각합니다. 나는 또한 때때로 사람들이 그것을 사용할 때 과도한 보상을 시도하고 각 가능한 해상도에 대해 10가지 다른 버전의 이미지를 배송하는 것을 봅니다. 우리는 적어도 일부 연구에서 사용자가 이미지 품질과 선명도 및 디테일의 차이점을 구별하기가 매우 어렵다는 것을 발견하는 경향이 있습니다. 따라서 장치 픽셀 비율 제한인 DPR 제한은 확실히 염두에 둘 가치가 있는 아이디어입니다.
Addy Osmani: 그리고 최신 이미지 형식의 경우 이전에 형식에 대해 이야기했지만 WebP, AVIF, JPEG XL을 고려하십시오. 픽셀 낭비를 피하십시오. 품질을 위한 좋은 전략을 세우는 것이 정말 중요합니다. 그리고 기본 화질도 가끔 너무 과할 때가 많다고 생각합니다. 그래서 비트 전송률을 낮추고 품질 설정을 낮추고 선명도를 유지하면서 사용자에게 얼마나 많은 것을 제공할 수 있는지 실험해 보겠습니다.
Addy Osmani: 그리고 로딩에 대해 이야기할 때 이미지 태그가 지난 몇 년 동안 지원하기 위해 진화한 또 다른 것 중 하나는 지연 로딩입니다. 따라서 로딩이 지연과 동일하면 이미지에 지연 로딩을 추가하기 위해 더 이상 JavaScript 라이브러리를 사용할 필요가 없습니다. 이미지에 드롭하면 됩니다. 그리고 크롬 브라우저와 Firefox에서는 타사 종속성을 사용할 필요 없이 해당 이미지를 지연 로드할 수 있습니다. 그리고 그것도 꽤 좋습니다.
Addy Osmani: 그래서 지연 로딩이 있습니다. 우리는 동기화 디코딩과 같은 다른 것들에 대한 지원을 가지고 있지만, 계속 진행하고 다른 두 가지 핵심 vitals 측정항목에 대해 매우 빠르게 이야기할 것입니다.
Drew McLellan: 가세요. 네.
Addy Osmani: 따라서 레이아웃 변경을 제거하십시오. 페이지를 뛰어다니는 것을 좋아하는 사람은 아무도 없습니다. 제 가장 큰 좌절 중 하나는 웹 페이지를 여는 것입니다. 클릭하고 싶은 버튼 위에 손가락을 갖다 대면, 갑자기 치수가 설정되지 않은 광고나 이미지가 뜬다. 그리고 그것은 정말 불쾌한 경험을 한다.
Addy Osmani: 따라서 누적 레이아웃 전환은 콘텐츠의 불안정성을 측정하려고 합니다. 그리고 대부분의 경우 레이아웃 변경을 추진하는 일반적인 사항은 치수가 설정되지 않은 페이지의 이미지 또는 기타 요소입니다. 사람들이 이미지 크기를 설정하는 것이 종종 간단한 곳 중 하나라고 생각합니다. 아마도 우리가 역사적으로 그렇게 많이 한 것은 아니지만 확실히 시간을 할애할 가치가 있는 것입니다. 등대와 같은 도구에서 치수가 필요한 페이지의 이미지 목록은 무엇입니까? 그래서 당신은 갈 수 있고 당신은 그들을 설정할 수 있습니다.
Drew McLellan: 반응형 웹 디자인이 하나의 주제가 되었을 때 우리는 모두 사이트를 살펴보고 이미지 크기를 없앴습니다. 그 작업을 수행하는 데 사용할 수 있는 도구가 필요하기 때문에 이미지에 높이 및 너비 속성이 없습니다. 하지만 지금은 나쁜 생각이죠, 그렇죠?
Addy Osmani: 오래된 것이 다시 새롭습니다. 이미지에 치수를 설정하는 것은 확실히 가치가 있다고 말하고 싶습니다. 광고, 안구 프레임, 크기가 잠재적으로 변경될 수 있는 동적 콘텐츠의 치수를 설정하는 것은 치수를 설정할 가치가 있습니다.
Addy Osmani: 그리고 정말 재미있는 경험을 구축하려는 사람들을 위해 잘못된 표현이 있습니다. 반응형 카드 등에 대해 더 많은 작업을 해야 할 수도 있는 정말 재미있는 레이아웃 경험이 있습니다. CSS 종횡비 또는 종횡비 상자를 사용하여 공간을 확보하는 것이 좋습니다. 레이아웃 변경을 피하려고 할 때 가능한 한 고정되도록 하기 위해 해당 이미지의 치수 설정을 보완할 수 있습니다.
Addy Osmani: 그리고 마지막으로 마지막 Core Web Vital은 첫 번째 입력 지연입니다. 이것은 사람들이 이미지와 관련하여 항상 생각하지 않는 것입니다. 따라서 페이지 로드 시 이미지가 사용자의 대역폭과 CPU를 차단하는 것이 실제로 가능합니다. 특히 매우 느린 연결이나 대역폭 포화로 이어질 수 있는 저가형 모바일 장치에서 다른 중요한 리소스가 로드되는 방식을 방해할 수 있습니다.
Addy Osmani: 따라서 첫 번째 입력 지연은 사이트의 상호 작용 및 응답성에 대한 사용자의 첫인상을 캡처하는 핵심 Web Vital 메트릭입니다. 따라서 메인 스레드 CPU 사용량을 줄임으로써 첫 번째 입력 지연도 최소화할 수 있습니다. 따라서 일반적으로 네트워크 경합을 유발할 수 있는 이미지를 피하십시오. 렌더링 차단이 아닙니다. 그러나 여전히 렌더링 성능에 간접적인 영향을 줄 수 있습니다.
Drew McLellan: 이미지의 렌더링 차단을 막기 위해 이미지로 할 수 있는 일이 있습니까? 어떻게 해서든 초기 단계에서 브라우저의 부하를 줄여 더 빠르게 상호 작용할 수 있습니까?
Addy Osmani: 저는 스크롤 없이 볼 수 있는 부분을 표시하기 위한 최적의 이미지 시퀀스를 올바르게 이해하는 것이 요즘 점점 더 중요해지고 있다고 생각합니다. 스크롤 없이 볼 수 있는 부분이 오버로드된 용어라는 것을 알고 있지만 사용자의 첫 번째 뷰 포트와 같습니다. 매우 자주 우리는 사용자가 즉시 보게 될 내용에 실제로 필요하지 않은 전체 톤의 리소스를 요청하려고 할 수 있습니다. 그 중 일부는 이미지입니다. 그리고 그것들은 페이지의 수명 주기에서 나중에 로드하기에 좋은 후보가 되는 경향이 있습니다. 그러나 초기에 전체 대기열과 같이 전체 이미지를 요청하는 경우 잠재적으로 영향을 미칠 수 있습니다.
드류 맥렐런: 네. 그래서, 제 말은, 당신은 우리가 역사적으로 자바스크립트 라이브러리가 해야 하는 지연 로딩 이미지를 언급했는데 고유한 단점이 있습니다. 제 생각에는 브라우저가 이미지 로딩을 중지하는 것이 거의 불가능한 역사적 방식으로 인해 이미지 로딩을 최적화하기 때문이라고 생각합니다. , 소스를 제공하지 않는 한. 그리고 소스를 제공하지 않고 나중에 JavaScript로 수정하려고 하면 해당 JavaScript가 실행되지 않으면 이미지가 표시되지 않습니다. 그래서 지연 로딩, 네이티브 지연 로딩이 그 모든 것에 대한 답입니다.
Addy Osmani: 네, 물론입니다. 그리고 저는 이것이 우리가 지난 1년 동안 네이티브 지연 로딩 경험을 여러 브라우저에서 개선하려고 노력한 곳이라고 생각합니다. 아시다시피, 이것은 우리가 무언가를 일찍 출시한 기능 중 하나이며 업계의 선구자들과 대화를 활용하여 "오, 이봐, 실제로 수동으로 설정하는 임계값은 얼마입니까? 지연 크기를 사용하거나 다른 JavaScript의 지연 로딩 라이브러리를 사용 중이라면?” 그런 다음 우리는 여러분이 기대하는 것에 조금 더 가까이 다가가기 위해 임계값을 조정했습니다.
Addy Osmani: 많은 경우에 네이티브 지연 로딩을 사용할 수 있습니다. 훨씬 더 세련된 것이 필요하거나 교차 관찰자 임계값, 브라우저가 요청하는 시점을 훨씬 더 많이 제어해야 하는 경우 일반적으로 이러한 경우 라이브러리를 사용하는 것이 좋습니다. , 90% 사용 사례를 해결하려고 하기 때문입니다. 그러나 10%는 여전히 유효합니다. 아직 조금 더 필요한 사람이 있을 수 있습니다. 그래서 대부분의 사람들에게 네이티브 지연 로딩이 가까운 미래에 충분히 좋을 것이라고 생각합니다.
Drew McLellan: 무엇보다도 무료입니다. 간단한 속성을 추가하면 이 모든 기능을 무료로 사용할 수 있습니다. 정말 좋습니다. 청취자가 할 수 있는 한 가지가 있다면, 다른 곳으로 가서 이미지 최적화를 개선하기 위해 사이트를 방문할 수 있습니까? 어디서부터 시작해야 합니까?
Addy Osmani: 시작하기에 좋은 곳은 이것이 귀하의 사이트에 얼마나 큰 문제인지 이해하는 것입니다. 나는 가서 등대를 확인하거나 속도 통찰력을 지불합니다. 가장 인기 있는 페이지에서 실행하고 결과를 확인하십시오. 할 일이 한두 가지뿐인 것처럼 보인다면 그것은 환상적입니다. 거기에 시간을 할애할 수도 있습니다.
Addy Osmani: 해야 할 일의 목록이 긴 경우 그 안에 있는 최고의 기회를 살펴보세요. "오, 이 일을 하면 몇 초를 절약할 수 있습니다 물건." 그리고 처음부터 거기에 에너지를 집중하세요.
Addy Osmani: 여기에서 이야기한 것처럼 최신 이미지 형식을 위한 도구는 시간이 지남에 따라 더 좋아졌습니다. 이미지 CDN은 확실히 고려할 가치가 있습니다. 그러나 그 외에도 취할 수 있는 작은 단계가 많이 있습니다. 때로는 사이트가 충분히 작은 경우 Squoosh에 가서 여는 것만으로도 몇 개의 이미지를 거기에 넣는 것이 좋은 출발점이 될 수 있습니다.
Drew McLellan: 확실한 조언입니다. 지금은 그것이 굉장한 출판물이라는 것을 압니다. 그러나 나는 당신에게 이 책을 출판한 것을 정말로 축하해야 합니다. 너무 포괄적이고 소화하기 쉽습니다. 정말 귀한 글이라고 생각합니다.
Drew McLellan: 그래서 저는 이미지 최적화에 대한 모든 것을 배웠습니다. 최근에 무엇을 배웠습니까, Addy?
Addy Osmani: 최근에 무엇을 배웠습니까? 사실, 여전히 이미지와 관련이 있는 약간 다른 주제에 대해, 그래서 제가 대학에서 석사 과정을 밟고 있을 때 컴퓨터 비전에 대해 정말 깊이 빠져들었고 이해하려고 노력했습니다. 어떻게 이미지의 다른 부분을 감지하고 그들과 함께 흥미로운 것들?
Addy Osmani: 그리고 제가 최근에 파고든 특정한 문제는 제가 아기였을 때 제 사진을 보고 있었다는 것입니다. 그리고 그 당시에는 부모님이 가져갈 많은 음식이 반드시 디지털 카메라에 있는 것은 아니었습니다. 그들은 폴라로이드였습니다. 해상도가 다소 낮은 이미지인 경우가 많습니다. 그리고 저는 그것들을 확장할 수 있는 방법을 원했습니다. 그래서 최근에 다시 이 문제를 파헤치기 시작했습니다. 그리고 브라우저에서 할 수 있는 일에 대해 더 많이 알게 되었습니다.
Addy Osmani: 그래서 저는 기계 학습, TensorFlow 사용, 기존 기술 사용, 상대적으로 저해상도 이미지 또는 일러스트레이션을 촬영한 다음 훨씬 더 높은 품질로 업스케일할 수 있는 몇 가지 작은 도구를 만들고 있습니다. 그래서 단순히 이미지를 늘리는 것보다 낫습니다. 실제로 자세히 채우는 것과 같습니다.
Addy Osmani: 그리고 그것은 일종의 재미였습니다. 저는 웹 어셈블리가 이제 브라우저 전반에 걸쳐 얼마나 안정적인지, 데스크톱 애플리케이션 사용 사례에 이러한 아이디어 중 일부를 얼마나 잘 사용할 수 있는지에 대해 많은 것을 배웠습니다. 정말 재미있었습니다. 그래서 최근에 많은 웹 어셈블리를 파헤쳤습니다. 멋지네요.
Drew McLellan: 웃기죠 ? 당신이 알고 있는 모든 것을 뒤집는 기술이 등장할 때. 우리는 항상 웹에서 이미지를 더 작게 만들 수 있다고 말했습니다. 하지만 작은 이미지만 있다면 더 크게 만들 수는 없습니다. 그것은 불가능합니다. 그러나 지금 우리는 많은 상황에서 그것을 가능하게 할 수 있는 기술을 가지고 있습니다. 정말 매력적입니다.
Drew McLellan: 청취자 여러분, Addie의 소식을 더 듣고 싶으시다면 @AddieOsmani인 Twitter에서 그를 찾고 AddyOsmani.com에서 링크된 그의 모든 프로젝트를 찾을 수 있습니다. "Image Optimization"이라는 책은 지금 Smashing에서 물리적 및 디지털 방식으로 사용할 수 있습니다. 오늘 함께해주셔서 감사합니다, Addy. 이별의 말이 있나요?
Addy Osmani: 이별의 말은 없나요? 나는 사람들과 공유할 역사의 작은 특징이 있습니다. Tim Berners-Lee는 1992년에 인터넷에 최초의 이미지를 업로드했습니다. 그것이 무엇인지 짐작할 수 있을지 모르겠지만 아마 놀라실 것입니다. 드류, 당신은 어떤 추측이 있습니까?
Drew McLellan: 고양이 같아요.
Addy Osmani: 고양이. 좋은 추측이지만 아닙니다. 이것은 CERN에 있었습니다. 그리고 그 이미지는 실제로 Les Horribles Cernettes라는 밴드의 것이었습니다. 이 밴드는 CERN 직원들이 결성한 패러디 팝 밴드였습니다. 그리고 그들이 할 음악은 두왑 음악 같다. 그리고 그들은 충돌기, 기이함, 액체 질소, 반물질에 관한 60년대 의상을 입고 사랑 노래를 불렀습니다.