다양한 이미지 최적화 기법에 관한 설문조사 응답자의 의견
이 게시물에는 Google 웹 DevRel에서 2019년 여름 이미지 최적화 기법 설문조사를 통해 받은 자유 형식의 의견이 나와 있습니다. 웹 기초사항 및 @ChromiumDev를 통해 응답을 요청했습니다. 이 설문조사는 이미지 최적화가 성능을 개선하는 비교적 쉬운 방법으로 보이지만 대부분의 사이트에서 이미지 최적화 권장사항을 따르지 않는 이유를 알아보기 위해 진행되었습니다. 설문조사 방법론에 결함이 있어 응답 데이터가 여기에 표시되지 않습니다.
잠재고객
- 웹 개발자인 경우 이 게시물에서 새로운 이미지 최적화 기법을 찾거나 다른 웹 개발자가 직면한 문제를 해결한 방법에 관한 세부정보와 각 기법의 비용, 이점, 제한사항을 알아볼 수 있습니다.
- 이미지 서비스 또는 이미지 CDN 제공업체인 경우 이 게시물이 새로운 시장 기회를 찾는 데 도움이 될 수 있습니다.
- 프레임워크, 빌드 도구 또는 CMS 개발자인 경우 이 게시물에서 구현할 새로운 기능에 대한 아이디어를 얻을 수 있습니다.
댓글
WebP
- "WebP는 좋지만 아직 완전히 준비되지 않았습니다. 또한 WordPress에서 WebP를 지원하지 않습니다. 가장 인기 있는 사진 편집 앱 중 하나인 Photoshop도 기본적으로 WebP를 지원하지 않습니다. 따라서 이미지 압축을 위해 서드 파티 앱이나 서비스를 사용할 수 없습니다."
- 'Safari에서 WebP를 사용할 수 있도록 합니다.'
- "Photoshop/Figma/Sketch에서 내보낼 수 있고 모든 브라우저에서 지원하는 경우 WebP를 사용하고 싶습니다." [참고: Sketch는 WebP를 지원합니다.]
- "차세대 형식 지정 솔루션이 있으면 좋겠어요."
- "브라우저 지원이 좋지 않은 경우 WebP를 너무 밀어붙이지 마세요. 스크린샷에 JPEG 대신 PNG가 필요한지 고려해 보세요."
- 'Google Docs에서는 WebP를 지원하지 않습니다.'
- 'WebP만 사용하고 싶지만 브라우저 호환성이 우려됩니다.'
- "먼저 브라우저 호환성을 수정하고 기존 브라우저를 업데이트하거나 기존 수정사항을 추가하세요. 그러면 사람들이 WebP와 같은 새로운 이미지 유형을 더 기꺼이 채택할 것입니다."
- '개발자가 아닌 사용자가 직접 처리하지 않아도 되도록 플러그인/테마 개발자가 WebP 및 기타 차세대 이미지 유형을 지원하도록 권장합니다.'
SVG 및 벡터 이미지
- "가능한 경우 (애니메이션이 적용된) SVG를 사용합니다. gatsby-image가 이 문제를 많이 해결했습니다. 하지만 그들이 해낸 작업을 자세히 살펴보면 일반 웹사이트에서 이미지를 제대로 사용하기 위해 이와 같은 작업을 해야 한다는 것은 완전히 비현실적입니다. 브라우저가 이 책임을 더 많이 맡아야 합니다.'
- "lottie.js로 SVG 애니메이션을 만드는 방법을 문서화할 수 있나요?"
- "로드 시간을 줄이기 위해 대부분의 경우 웹사이트에 크기가 작은 고해상도 JPEG 사진을 사용합니다. 또한 반응형 디자인의 품질을 제공하기 위해 필요한 경우 SVG를 사용합니다."
- "가능하면 사진 외의 모든 항목에 최적화된 벡터 그래픽을 사용합니다."
기타 이미지 형식
- "GIF 사용을 중지하도록 사용자에게 더 효과적으로 교육해야 합니다."
지연 로드
- '느린 로드와 같은 기능을 고려할 때는 사용자를 염두에 두세요. 많은 사용자에게 불편을 끼칠 수 있습니다.'
- 'lazy load 속성을 background-image와 함께 작동하도록 하세요.'
- '프레임워크는 기본적으로 더 나은 애셋 처리를 실행해야 합니다.'
- "오래전에 지연 로드에서 전환했습니다. 수백만 개의 이미지와 사이트가 '로드되지 않는다'는 사용자 신고가 접수되었습니다. Google팀에서 요약한 내용입니다. 기술 지식이 없는 사용자는 문제를 설명하기 어렵습니다.'
- "기존 기법을 사용하는 대신 지연 로드에 Intersection Observer API를 사용하는 방법을 더 잘 이해하고 싶습니다."
- "이 페이지가 도움이 됩니다.pwafire.org/developer/codelabs/progressive-loading"
배경 이미지
- "일반적으로 CSS에서 이미지를 배경으로 로드합니다."
- "
<img>
태그는 문제가 있으며 특히 사용자가 제출한 콘텐츠의 경우 세부적인 세부정보를 제어하기 어렵습니다.<div>
및 background-image 스타일을 훨씬 더 자주 사용합니다. 이렇게 하면 background-size, background-position을 사용할 수 있고 이미지를 마우스 오른쪽 버튼으로 저장하는 것을 방지할 수 있기 때문입니다."
투명성
- "2019년입니다. JPG에 알파 투명도가 없는 이유는 무엇인가요?"
- '투명한 배경이 필요한 경우에만 사진에 PNG를 사용합니다.'
저화질 이미지 자리표시자 (LQIP)
- "저희는 LQIPS를 사용합니다. LQIPS는 고화질 이미지를 너무 일찍 로드하지 않고도 방문자의 참여를 유도하는 훌륭한 기법입니다."
성능
- "최근 이미지와 관련된 성능 문제가 있었습니다. 사용자가 사이트에서 아래로 스크롤하면 썸네일이 포함된 다음 60개의 카드가 표시됩니다. 동일한 도메인의 연결 한도가 6개이므로 사용자가 계속 아래로 스크롤하면 썸네일과 다음 60개의 카드를 가져오기 위한 다음 AJAX 요청이 차단되었습니다."
- "HTTP/2를 사용하고 싶지만 대부분의 고객이 IE11을 사용합니다. 따라서 Google에서는 도메인 샤딩 / 다른 도메인에서 AJAX JSON 데이터 요청 로드를 모색하고 있습니다."
크기 조정
- "intrinsicsize를 사용해 죄송합니다. 높이/너비를 사용하는 것이 더 나을 것 같습니다."
- "크기를 줄이는 방법을 찾고 있습니다. 현재는 약 12개입니다."
- '이미지의 동적 크기 조절은 JS 없이는 정말 어렵고 불가능합니다.'
- "responsivebreakpoints.com과 같은 도구가 web.dev에 좋습니다."
고화질 이미지
- "DPI 품질을 저하시키지 않고 이미지를 압축하여 다운로드하는 방법은 무엇인가요?"
- "저희는 문서 관리 회사입니다. 저희 앱은 수백만 개의 고해상도 스캔 이미지(일반적으로 TIFF 또는 PDF)를 처리합니다."
- "불편하실 수 있습니다. 인쇄 형식에는 고해상도 img 파일이 필요하며 웹에 최적화되어야 합니다. 웹용으로 이미지 크기를 줄이는 것은 번거로운 작업이지만 저자가 인쇄 게시를 목적으로 하는 이미지에만 가벼운 파일을 제공하는 경우 문제가 됩니다. 아트워크가 포함된 원고 제출 요구사항에 대해 혼동스러운 메시지를 전달하게 됩니다. 그러면 이러한 자료를 처리하기 위한 복잡한 워크플로가 생성됩니다."
브라우저 기능
- "모든 이미지를 4가지 크기로 자르고 모든 마크업을 작성하는 데 시간이 많이 걸리므로 브라우저에서 [기본 제공] 기능으로 자동 반응형 src 자르기가 매우 유용할 것입니다. 큰 사진을 하나 업로드하고 간단한 picture 태그를 작성하면 브라우저에서 자동으로 여러 src 속성을 생성하는 것이 좋습니다."
- "개인적으로 반응형 이미지에 CSS로 이미지 너비를 설정할 때 (max-width: 100%; height auto 또는 height: width: 100%; height auto) 페이지 리플로우를 피하는 데 어려움을 겪고 있습니다. 특히 적응형 이미지/picture 태그의 아트 디렉션과 함께 사용하면 더욱 그렇습니다. 이를 방지하는 가장 좋은 방법은 고정 이미지 비율에 '음수 패딩 해킹'을 사용한 다음 이미지를 이 비율 상자 내에 배치하는 것입니다. 브라우저 지원/반응형 이미지 처리가 개선되면 정말 좋을 것 같습니다."
- '첫 번째 프레임만 가져와 GIF '자동재생'을 사용 중지하세요.'
CDN 및 이미지 서비스
- "Google에서 Cloudflare와 같은 무료 CDN을 제공해야 합니다."
- '다양한 제공업체를 통해 동적 확장과 CDN을 설정할 수 있는 도구가 더 있으면 좋겠습니다.'
- "과도하게 압축된 대형 이미지 하나만 있으면 추가 제작 비용 없이도 매우 괜찮은 솔루션이 됩니다. 모바일의 경우 너비가 약 1,000픽셀 (렌더링 너비 500픽셀)의 이미지가 필요하며, 이는 대형/데스크톱의 비레티나 디스플레이에도 필요한 크기입니다. 이미지 크기 조절 CDN은 이전에 사용해 봤지만 매우 나쁜 솔루션이라고 생각합니다. CMS에서 크기 조절을 처리해야 하며, 이를 설정하기에는 너무 복잡하므로 단일 솔루션이 현재로서는 좋은 타협안입니다."
- "CloudFlare는 사용자의 디스플레이에 가장 적합하도록 이미지 크기를 자동으로 조정합니다. 따라서 이미지가 사용자의 디스플레이를 기준으로 로드되므로 로드 시간을 절약할 수 있습니다. 예를 들어 사용자가 휴대전화를 사용하는 경우 데스크톱 크기의 배경이 로드되지 않습니다."
- "Cloudflare에서 설정 패널에서 체크박스를 선택하는 것 외에는 아무것도 하지 않아도 백그라운드에서 이 작업을 실행합니다."
- "다시 한번 말씀드리지만, srcset 등을 성공적으로 사용할 수 있는 유일한 이유는 Cloudinary의 편리함 때문입니다. 하지만 Cloudinary는 정말 빠르게 비용이 증가합니다. 이는 개발 환경에 큰 구멍이 있는 것 같습니다."
- "다양한 상황에서 다양한 가로세로 비율로 작동할 수 있도록 이미지를 스마트한 방식으로 쉽게 자동으로 자르는 방법이 필요합니다."
- "해상도, 품질, 압축을 거의 제어할 수 없는 Unsplash와 같은 다른 제공업체의 이미지도 사용합니다."
CMS, 플랫폼, 프레임워크
- "CMS를 사용하여 사이트를 구축할 때 이미지를 사용하는 가장 좋은 방법을 찾는 데 여전히 어려움을 겪고 있습니다. 작성자는 다양한 크기로 이미지를 구성하고 이미지가 축소되거나 크기 조절되지 않기를 기대하는 경향이 있습니다. 이미지에 max-width 또는 max-height를 설정해도 되는지 잘 모르겠습니다.'
- "지난 몇 개의 프로젝트에 gatsby-image를 사용해 왔으며 그 이후로 다른 도구를 사용해 본 적이 없습니다."
- "이미지는 최종 사용자가 CMS에 추가하므로 어려운 부분이 많습니다. 어떤 크기와 형식도 사용할 수 있으며, 이상적인 이미지 형식과 크기의 원본 이미지를 사용할 수 없는 경우도 있습니다."
- "YouTube 시스템은 셀프서비스이므로 이미지를 유지하기가 어렵습니다. 해결 방법이 해상도에 영향을 주지 않고 자동으로 이루어지지 않는 한 제어를 추가하기가 어렵습니다. 또한 모바일과 데스크톱에서 이미지가 올바르게 표시되지 않습니다."
- "저는 사람들이 사이트 (WordPress)를 최적화하도록 지원하고 있습니다. 이미지와 관련하여 가장 큰 문제는 WebP를 만들기 위해 CDN 또는 플러그인을 사용해야 한다는 점입니다. srcset/picture는 테마 개발자가 올바르게 코딩해야 합니다. 대부분의 지연 로드 플러그인이 느리게 로드되어 UX가 좋지 않습니다. 배경 이미지는 지연 로드하기 어렵습니다."
비용/이익
- "새로운 관행은 효과적이지만 사이트 개발 시간이 늘어납니다."
- "srcset 및 WebP와 같은 새로운 표준을 준수하지 않아 포춘지 선정 500대 기업에서 이를 채택하는 데 시간이 걸렸습니다. 이에 따라 많은 기업이 기존 웹사이트에 불필요한 개발 비용이라고 생각하여 변경에 반대했습니다. 성능 향상이 최종 사용자 (UX)에 의해 광범위하게 논의되거나 보고되지 않습니다. 오히려 웹에서 이미지를 저장하기가 다소 어려워질 수 있습니다."
- '여러 크기와 버전을 만들고 관리하는 데 비용이 많이 듭니다.'
- "서버에서 많은 공간을 차지합니다."
검색엔진 최적화
- "허용되는 이미지 품질과 파일 크기 간에 균형을 맞추기가 어렵습니다. 한편으로는 SEO 이점을 위해 로드 속도를 높이고 싶지만, 다른 한편으로는 품질이 낮은 이미지는 UI/UX를 저하시킵니다."
웹에서 이미지의 역할
- '웹에 너무 많은 정보가 있습니다. 서면 콘텐츠를 보완하지 않는 무의미한 이미지를 사용하지 마세요."
- "웹에 이미지가 없고 셀카를 ASCII 아트로 공유하던 시절을 아직 기억하시나요?"
도구, 안내, 표준, 권장사항: 불만사항 및 요청
- [한 참여자는 이 설문조사에 대한 답변으로 블로그 게시물을 작성했습니다.]
- '요구사항이 끊임없이 변경되는 것 같습니다. 웹 개발자로서 이미지를 저장하는 데 시간이 많이 걸리기 때문에 매우 불편합니다. 최선을 다해 최적화하고 사이트를 확인한 후 몇 개월이 지나면 Google에서 이미지를 더 압축하거나 다른 형식으로 전환해야 한다고 결정합니다. 이로 인해 Google은 고객에게 지속적으로 작동하는 최선의 솔루션을 제공하지 못하고 대신 고객과 Google 모두에게 비용이 많이 드는 작업을 하게 됩니다. 일부 중소기업 고객에게는 요구사항을 준수하기 위해 이미지를 계속 수정하고 다시 저장하는 데 드는 예산이 없습니다. 관리 패키지 내에서 이 작업을 수행할 예산이 없습니다. 기기별로 다른 이미지 크기를 호출하는 코드를 작성하는 데도 시간이 많이 소요됩니다. 장시간 일관되게 이미지를 저장하는 시스템을 개발하는 것이 좋을 것 같습니다."
- "예, Lighthouse에서 '요청 수는 낮게, 파일 크기는 작게 유지하기'가 잘못된 것 같습니다. 사이트가 HTTP1.x를 통해 제공되는 경우에는 맞지만, 사이트가 HTTP2를 통해 제공되는 경우에는 요청 수가 중요하지 않거나 동일한 호스트 이름에서 발생하는 경우 문제가 아닙니다. 라이트 웹사이트가 있지만 동일한 호스트 이름에서 HTTP2를 통해 총 35개 요청의 작은 WebP 파일 30개를 로드합니다. Lighthouse에서 이 문제를 '요청 수를 적게 유지하고 파일 크기를 작게 유지' 문제로 신고하고 있지만 속도가 매우 빠르고 동일한 호스트 이름의 HTTP2로 인해 요청 수가 문제가 되지 않습니다. 파일은 이미 작습니다 (대부분 1KB~2KB 미만). 스프라이트를 로드할 수 있지만 더 많은 CSS 계산을 실행해야 합니다. 따라서 Lighthouse의 '요청 수는 낮게, 파일 크기는 작게 유지하기' 보고서를 업데이트하여 동일한 호스트 이름을 통한 HTTP2를 고려하세요.'
- "사람들이 이미지를 압축하는 것을 잊어버리는 경우가 많았습니다."
- '교차 브라우저 동작은 예측할 수 없으므로 가장 간단한 솔루션이 가장 안전한 경우가 많습니다.'