휴대전화는 어떤 이미지를 받을까?

작은 표시 칸이 다운로드 파일을 줄이지는 않습니다. 모든 방문자에게 같은 원본 크기 사진을 보내면 휴대전화도 불필요한 픽셀을 받습니다. 압축과 반응형 선택은 문제의 다른 부분을 해결합니다.

웹사이트 작업 안내는 준비 과정을, 이미지 전달 안내는 성능 진단과의 관계를 설명합니다. 이 실험은 점수를 결과로 삼지 않고 준비한 사진부터 실제 선택까지 추적합니다.

압축 전에 외부 이미지 편집기로 비율을 유지한 사본을 만들었습니다. Bitinz가 크기를 바꾼 것이 아닙니다. 2026-10-29에 로컬 엔진의 균형으로 처리했으며 크기, 바이트와 체크섬으로 후보를 식별합니다.

로컬 페이지는 srcset과 레이아웃에 맞는 sizes로 후보를 제공했습니다. 관측에는 뷰포트 폭, 픽셀 밀도와 선택 리소스를 기록합니다. 전체 페이지 로딩이나 모바일 네트워크 재현이 아닌 이미지 전송량입니다. 근거는 편집 방침에 있습니다.

여기서 후보 용량을 비교한 뒤 출처의 브라우저 기록을 보세요. 브라우저는 페이지가 제공한 파일 중에서만 고를 수 있습니다.

Bitinz · 1 KB는 1000바이트입니다.

각 행은 캐시를 끈 새로운 브라우저 환경에서 측정했습니다. 가장 넓은 고밀도 조건은 제공된 후보 사이의 간격이 커서 최대 이미지를 선택했습니다. 중간 후보를 추가해 시험할 가치가 있습니다. 브라우저는 목록에 있는 파일만 고를 수 있습니다.

원본 사진 세부

압축 사진 세부

작은 화면과 고밀도 화면에서 확인하세요. 가장 작은 후보라도 흐리면 적절하지 않고 큰 후보도 절감률이 좋아 보인다는 이유만으로 필요하지는 않습니다.

선택 기록은 명시한 환경의 관측입니다. 이후에는 캐시와 브라우저 판단이 영향을 줍니다. 재현하려면 새로운 브라우저 환경에서 표시 크기로 추측하지 말고 실제 요청 이미지를 확인하세요.

준비한 사본을 이미지 압축기로 처리하고 사이트나 콘텐츠 관리 시스템이 알맞은 후보를 제공하도록 하세요. 모든 화면을 큰 파일 하나로 지정하면 압축만으로 선택이 바뀌지는 않습니다.

sizes는 CSS 레이아웃에 맞추세요. 브라우저는 후보와 화면 밀도와 함께 그 힌트를 쓰며 파일명으로 의도를 읽지 않습니다. 레이아웃을 바꾼 뒤 선택 리소스를 확인하세요.

반복되는 게시 작업에서는 개발자 API로 준비된 파일을 압축할 수 있습니다. 크기 조정은 별도의 준비 단계입니다. 화질 가이드에서는 이미지를 교체하기 전에 세부 표현을 비교하는 방법을 설명합니다.

1. 01이미지 칸을 재고 비율을 유지할 후보 폭을 정합니다.
2. 02편집 가능한 원본을 보관하며 사본을 준비하고 압축합니다.
3. 03레이아웃에 맞는 sizes와 후보를 제공합니다.
4. 04여러 화면에서 선택 리소스와 표시 사진을 확인합니다.