2019년 여름 이미지 최적화 설문조사 의견

다양한 이미지 최적화 기법에 대한 설문조사 응답자들의 의견

이 게시물에는 Google Web DevRel이 2019년 여름 이미지 최적화 기법 설문조사에서 받은 자유 형식 의견이 나열되어 있습니다. 응답은 웹 기초@ChromiumDev를 통해 요청되었습니다. 이 설문조사는 비교적 쉬운 방법으로 실적을 개선하는 것처럼 보이지만 대부분의 사이트가 이미지 최적화 권장사항을 따르지 않는 이유를 파악하기 위해 설문조사를 진행했습니다. 설문조사 방법에 결함이 있어 응답 데이터가 여기에 나열되지 않았습니다.

대상

  • 웹 개발자라면 이 게시물이 새로운 이미지 최적화 기법을 알아보거나, 다른 웹 개발자가 직면한 문제를 어떻게 해결했는지에 관한 세부정보와 각 기법의 비용, 이점, 제한사항을 알아볼 수 있습니다.
  • 이미지 서비스 또는 이미지 CDN 제공업체인 경우 이 게시물이 새로운 시장 기회를 찾는 데 도움이 될 수 있습니다.
  • 프레임워크, 빌드 도구 또는 CMS 개발자라면 이 게시물을 통해 구현할 새로운 기능에 관한 아이디어를 얻을 수 있습니다.

설명

WebP

  • "WebP가 마음에 들지만 아직 완전히 준비되지는 않았습니다. 게다가 WordPress는 WebP를 지원하지 않습니다. 가장 인기 있는 사진 편집 앱 중 하나인 Photoshop도 기본적으로 WebP를 지원하지 않습니다. 따라서 이미지 압축에 서드 파티 앱이나 서비스를 사용할 수 없습니다."
  • "Safari에서 WebP를 사용할 수 있게 합니다."
  • "Photoshop/Figma/Sketch에서 내보낼 수 있고 모든 브라우저에서 WebP를 지원하는 경우 WebP를 사용하고 싶습니다." [참고: Sketch는 WebP를 지원합니다.]
  • "차세대 포맷 솔루션은 유용할 것입니다."
  • "브라우저 지원 성능이 좋지 않으면 WebP를 너무 세게 푸시하지 말고 스크린샷을 위해 JPEG 대신 PNG가 필요한지 고려하세요."
  • 'Google Docs는 WebP를 지원하지 않습니다.'
  • "WebP를 배타적으로 사용하지만 브라우저 호환성이 우려됩니다."
  • "먼저 브라우저 호환성을 수정하고 기존 브라우저를 업데이트하거나 기존 수정사항을 추가하면 사람들이 WebP와 같은 새로운 이미지 유형을 채택할 가능성이 커집니다..."
  • "WebP 및 기타 차세대 이미지 유형에 대한 지원을 제공하는 것을 고려하도록 플러그인/테마 개발자에게 권고하여 비개발자가 이 이미지 유형을 다루지 않아도 되도록 하세요."

SVG 및 벡터 이미지

  • "저는 (애니메이션) SVG를 사용하고 있습니다. gatsby-image 이 문제를 많이 해결했습니다. 하지만 그 결과를 자세히 들여다보면 정상적인 웹사이트에서 이미지가 제대로 작동하도록 하기 위해 이와 같은 도구를 구축해야 한다는 것은 비현실적입니다. 브라우저는 이러한 책임을 더 많이 져야 합니다."
  • "lottie.js로 SVG 애니메이션을 만드는 방법을 문서화할 수 있나요?"
  • "저희는 로드 시간을 피하기 위해 대부분의 경우 웹사이트에서 크기가 작은 큰 해상도의 JPEG 사진을 사용하려고 합니다. 또한 필요한 경우 반응형 디자인의 품질을 제공하기 위해 SVG를 사용합니다."
  • "우리는 가능한 한 사진을 제외한 모든 사진에 최적화된 벡터 그래픽을 사용하려고 합니다."

기타 이미지 형식

  • "GIF 사용을 중단하도록 사람들에게 더 잘 교육해야 합니다."

지연 로드

  • "지연 로드와 같은 기능은 사용자를 성가시게 하므로 사용자를 염두에 두시기 바랍니다."
  • "지연 로드 속성이 배경 이미지와 호환되도록 해 주세요."
  • "프레임워크는 자산을 즉시 더 잘 처리할 수 있어야 합니다."
  • "우리는 오래전에 지연 로드에서 전환했습니다. 수백만 개의 이미지와 사이트가 '로드되지 않음'이라는 사용자 신고가 접수되었습니다. 저희 팀에서는 다음과 같이 요약했습니다. 기술 지식이 없는 사용자도 문제를 설명하기는 어렵습니다."
  • "저는 기존 기법보다는 지연 로드에 Intersection Observer API를 사용하는 방법을 더 잘 이해하고 싶습니다."
  • "pwafire.org/developer/codelabs/progressive-loading이 제게 적합합니다."

배경 이미지

  • "저는 보통 CSS에서 이미지를 배경으로 로드합니다."
  • "<img> 태그는 문제가 있으며, 특히 사용자가 제출한 콘텐츠에서 세부정보를 세밀하게 관리하기가 어렵습니다. <div> 및 배경 이미지 스타일 지정을 훨씬 더 자주 사용합니다. 배경 크기와 배경 위치를 사용하고 이미지를 마우스 오른쪽 버튼으로 클릭하여 저장하는 것을 막을 수 있기 때문입니다."

투명성

  • "2019년이야. JPG에 여전히 알파 투명도가 없는 이유는 무엇인가요?"
  • "투명 배경이 필요할 때만 사진에 PNG를 사용합니다."

저품질 이미지 자리표시자 (LQIP)

  • "LQIPS는 고품질 이미지를 미리 로드하지 않고도 방문자의 참여를 유도할 수 있는 훌륭한 기술입니다."

성능

  • "사실 최근에 이미지에 성능 문제가 발생했습니다. 사용자가 사이트에서 아래로 스크롤하면 썸네일이 포함된 다음 카드 60개가 표시됩니다. 동일한 도메인의 연결 제한 6개로 인해 썸네일은 차단되었으며, 사용자가 계속 아래로 스크롤하면 다음 AJAX 요청뿐만 아니라 다음 카드 60개를 가져올 수 있습니다."
  • "HTTP/2를 사용하고 싶지만 대부분의 고객이 IE11을 사용하고 있습니다. 따라서 도메인 샤딩 / 다른 도메인에서 AJAX JSON 데이터 요청을 로드하는 방법을 모색하고 있습니다."

사이즈

  • "고유 크기가라 죄송합니다. 높이/너비를 활용하는 것이 더 좋습니다."
  • "생성되는 크기를 줄일 방법을 찾고 있는데, 지금은 최대 12개입니다."
  • "JS가 없으면 이미지의 동적 크기 조절이 정말 어렵고 불가능합니다."
  • "responsivebreakpoints.com과 같은 도구는 web.dev에 적합합니다. ^^"

고화질 및 고해상도 이미지

  • "DPI 품질을 유지하면서 압축 이미지를 다운로드하려면 어떻게 해야 하나요?"
  • "저희는 문서 관리 회사입니다. 당사의 앱은 수백만 장의 고해상도 스캔 이미지(보통 TIFF 또는 PDF)를 처리합니다."
  • "번거로운 작업입니다. 고해상도 img 파일은 인쇄 형식에 필요하며 웹에 최적화되어야 합니다. 웹용 이미지의 크기를 줄이는 것은 번거로운 일입니다. 하지만 작성자가 인쇄물 게시용으로 고안된 이미지에 가벼운 파일만 제공하면 오히려 큰 진전이 될 수 있습니다. 아트워크와 원고를 제출해야 하는 요구사항에 관해 혼합된 메시지를 전달하게 됩니다. 그런 다음 이러한 재료를 가공하는 복잡한 워크플로를 밟게 됩니다."

브라우저 기능

  • "브라우저에서 자동 반응형 src 자르기를 [기본 제공] 기능으로 사용하면 매우 유용합니다. 모든 이미지를 4개의 크기로 자르고 모든 마크업을 작성하는 데 시간이 많이 걸리기 때문입니다. 큰 사진 한 장을 업로드하고 간단한 사진 태그를 작성할 수 있다면 브라우저에서 여러 src 속성을 자동으로 생성하므로 가장 좋은 기능이 될 것입니다."
  • "개인적으로 저는 CSS에서 반응형 이미지 (최대 너비: 100%, 높이 자동 또는 높이: 너비: 100%, 높이 자동)를 사용하는 이미지를 설정할 때 페이지 리플로우를 피하기가 어렵습니다. 특히 적응형 이미지/사진 태그의 아트 디렉션과 함께 사용하면 더욱 어렵습니다. 가장 좋은 방법은 고정된 이미지 비율로 '네거티브 패딩 해킹'을 사용하고 이 비율 상자 안에 이미지를 배치하는 것입니다. 브라우저 지원/반응형 이미지 처리를 개선하면 큰 도움이 될 것입니다."
  • "첫 번째 프레임만 가져와서 GIF '자동재생'을 사용 중지하세요."

CDN 및 이미지 서비스

  • "Google은 Cloudflare와 같은 무료 CDN을 제공해야 합니다."
  • "다른 제공업체를 통해 동적 확장과 CDN을 설정하기 위한 더 많은 도구가 있으면 좋을 것입니다."
  • "오버사이즈 과압축 이미지 1개는 추가 프로덕션 비용이 없는 매우 적절한 솔루션입니다. 모바일용 약 1,000픽셀 너비의 이미지 (500픽셀 렌더링 너비)가 필요하며 이는 레티나가 아닌 대형/데스크톱 디스플레이에 필요한 크기입니다. 과거에 이미지 크기를 조절한 CDN은 매우 나쁜 해결책이라고 생각합니다. CMS는 크기 조절을 처리해야 하는데, 설정이 너무 복잡하므로 현재로서는 하나만 사용하는 것이 좋습니다."
  • "CloudFlare는 이미지를 자동으로 조정하여 사용자의 디스플레이에 가장 잘 맞춥니다. 이미지가 사용자의 디스플레이를 기준으로 로드되기 때문에 로드 시간을 절약할 수 있습니다. 예를 들어 사용자가 휴대전화를 사용하는 경우 데스크톱 크기의 배경에서는 로드되지 않습니다."
  • "Cloudflare는 설정 패널에서 확인란을 선택하는 것 외에는 아무것도 하지 않아도 백그라운드에서 이 작업을 수행합니다."
  • "다시 한번 강조하지만, 제가 srcset 등을 성공적으로 사용할 수 있는 유일한 이유는 Cloudinary의 편의성 덕분입니다. 하지만 Cloudinary는 비용이 아주 빨라집니다. 개발 환경에 큰 허점이 된 것 같습니다."
  • "이미지가 다양한 상황에서 다양한 가로세로 비율로 작동하도록 스마트하게 자동으로 이미지를 자를 수 있는 방법이 필요합니다."
  • "저는 Unsplash와 같은 다른 제공업체의 이미지도 사용합니다. 이 이미지에서는 해상도, 품질, 압축에 대한 제어 기능이 매우 적습니다."

CMS, 플랫폼, 프레임워크

  • "저는 CMS를 사용해 사이트를 구축할 때 아직도 이미지를 사용하는 가장 좋은 방법이 무엇인지 찾는 데 어려움을 겪고 있습니다. 작성자는 다양한 크기로 이미지를 구성하며 이미지가 축소되거나 확장되지 않을 것으로 기대합니다. 이미지에 max-width 또는 max-height를 설정해도 되는지 확실하지 않습니다."
  • "최근 몇 개 프로젝트에서 gatsby-image를 사용해 본 적이 없고, 한 번도 뒤돌아본 적이 없습니다."
  • "이미지는 최종 사용자가 CMS에 입력할 때 까다로운 부분인 경우가 많으며, 모든 크기, 형식을 사용할 수 있으며, 이상적인 이미지 형식의 원본 이미지를 사용할 수도 있고, 필요한 경우 사용할 수 없습니다."
  • "Google 시스템은 해상도에 영향을 주지 않고 자동으로 작업이 진행되지 않으면 시스템이 셀프 서비스 추가 제어 기능을 사용하기 때문에 이미지를 관리하기가 어렵습니다. 또한 저희의 경우 이미지가 모바일과 데스크톱에서 올바르게 표시되지 않습니다.'
  • "저는 사람들이 사이트를 최적화하도록 돕습니다 (WordPress). 이미지에서 확인한 가장 큰 문제는 WebP를 만들기 위해 CDN이나 플러그인에 의존해야 한다는 것입니다. srcset/picture는 테마 개발자가 올바르게 코딩해야 합니다. 대부분의 지연 로드 플러그인은 느리게 로드되어 UX에 부정적인 영향을 미칩니다. 배경 이미지는 지연 로드가 어렵습니다."

비용/혜택

  • "새로운 방법은 효과적이지만 사이트의 개발 시간을 늘립니다."
  • "srcset 및 WebP와 같은 새로운 표준을 준수하지 않는 문제는 포춘지 선정 500대 기업에서 빠르게 채택해 왔습니다. 이 사실을 확인한 많은 회사들이 현재 웹사이트에 불필요한 개발 비용이 있다는 이유로 이번 변경에 거부해 왔습니다. 성능 향상은 최종 사용자 (UX)가 폭넓게 논의하거나 보고하지 않습니다. 파일이 있다면 웹에서 이미지를 저장하기가 조금 더 어려워집니다."
  • "여러 크기, 버전을 만들고 관리하는 데 비용이 많이 듭니다."
  • "서버 공간을 많이 차지합니다."

검색엔진 최적화

  • "허용되는 이미지 품질과 파일 크기 사이의 균형을 맞추기란 쉽지 않습니다. 한편으로는 검색엔진 최적화를 위해 빠른 로드를 원하지만, 품질이 낮은 이미지는 UI/UX에 부정적인 영향을 미칩니다."

웹에서 이미지의 역할

  • "웹에는 정보가 너무 많습니다. 작성된 내용을 돋보이게 하지 않는 쓸모없는 이미지 사용을 중단합니다."
  • "웹에 이미지가 없고 우리가 ASCII 아트로 셀카를 공유한 때를 기억하시나요?"

도구, 안내, 표준, 권장사항: 불만과 요청

  • [한 참가자가 이 설문조사에 대한 응답으로 블로그 게시물을 작성함]
  • "요구사항은 끊임없이 변화하는 것 같습니다. 웹 개발자는 이미지를 저장하는 데 애초에 시간이 많이 걸리기 때문에 대단히 좌절합니다. 우리는 최선을 다해 최적화하고 사이트를 확인한 다음 몇 개월 후 이미지를 훨씬 더 압축하거나 다른 형식으로 만들어야 한다고 판단했습니다. 이로 인해 고객에게 최상의 솔루션을 제공할 수 없으며 그 대신에 고객과 당사의 노력에 많은 비용이 듭니다. 일부 소규모 비즈니스 고객은 요구사항을 준수하기 위해 이미지를 계속 수정하고 다시 저장할 예산이 없습니다. 자체 관리 패키지 내에 이 작업을 수행할 예산이 없습니다. 기기마다 다른 이미지 크기를 호출하는 코드를 작성하는 것도 시간이 오래 걸립니다. 장기간에 걸쳐 일관적으로 유지되는 이미지를 저장하는 시스템을 고안하면 좋을 것 같습니다."
  • "예, Lighthouse에서 'Keep Request Counts Low and File Sizes Small'이 잘못된 것 같습니다. 사이트에서 HTTP1.x를 통해 제공하는 경우, 물론 같은 호스트 이름에서 발생하는 요청 수는 덜 중요하지 않거나 문제가 되지 않습니다. 라이트 웹사이트가 있지만 동일한 호스트 이름의 HTTP2를 통해 총 약 35개의 요청이 포함된 작은 WebP 파일 30개를 로드합니다. Lighthouse는 이 문제를 'Keep Request Counts Low and File Sizes Small' 문제로 보고하고 있습니다. 반면 이 문제는 매우 빠르며 동일한 호스트 이름에 HTTP2가 사용되기 때문에 요청 수가 문제가 되지 않습니다. 파일이 이미 작습니다 (대부분 1KB에서 2KB 이하). 스프라이트를 로드할 수 있지만 그러면 더 많은 CSS 컴퓨팅을 수행해야 합니다. 따라서 동일한 호스트 이름의 HTTP2를 고려하도록 Lighthouse의 'Keep Request Counts Low and File Sizes Small' 보고서를 업데이트하세요.'
  • "사람들이 이미지를 압축하는 것을 기억하는 것은 쉽지 않았습니다."
  • "교차 브라우저 행동을 예측할 수 없으므로 가장 간단한 솔루션이 가장 안전한 경우가 많습니다."