병원 홈페이지가 모바일에서 느릴 때, 사진의 표시 크기와 전송 용량을 나눠 봅니다

병원 홈페이지의 사진을 화면에서 작게 줄였는데도 모바일이 느릴 수 있습니다. CSS로 보이는 크기만 줄이고 큰 원본을 그대로 내려받는 경우가 있기 때문입니다. 표시 크기, 선택된 이미지 파일, 실제 전송량을 나누어 확인해야 합니다. 사진을 작게 보이게 만든 것과 가볍게 전송한 것은 다른 작업입니다.

같은 사진이라도 기기에 맞는 파일을 보낼 수 있습니다

반응형 이미지는 화면과 기기에 맞는 이미지 후보를 브라우저가 선택하도록 돕는 방식입니다. srcset으로 후보를 제공하고 sizes로 표시될 너비에 관한 정보를 전달할 수 있습니다. sizes가 화면의 실제 CSS 크기를 대신 정하는 것은 아닙니다. web.dev 반응형 이미지 안내

따라서 '모바일에서는 가로 폭을 줄였다'는 설명만 받지 말고 개발자 도구에서 실제 선택된 파일과 내려받은 크기도 함께 봅니다. 같은 브라우저라도 화면 폭, 기기 픽셀 밀도, 캐시 상태에 따라 관찰 결과가 달라질 수 있습니다.

사진을 바꿀 때에는 필요한 디테일이 무엇인지 먼저 정합니다. 시설 전체 모습을 보여주는 사진과 작은 글자가 담긴 안내 이미지는 압축 후 확인해야 할 지점이 다릅니다. 용량 숫자만 줄이고 독자가 읽어야 할 정보가 사라지면 목적을 달성한 것이 아닙니다.

사진 네 장을 교체하는 가정 계산

기존 사진 4장이 각각 1,500KB이고 교체 후보가 각각 150KB라고 가정하겠습니다. 같은 단위를 기준으로 하면 사진 파일 합계는 6,000KB에서 600KB로 줄어듭니다. 감소량은 5,400KB이고 비율은 5,400 ÷ 6,000 × 100 = 90%입니다. 실제 병원 사이트를 측정한 결과가 아닙니다.

하지만 이미지 합계가 90% 줄었다고 페이지 로딩 시간이 90% 짧아진다고 말할 수는 없습니다. 서버 응답, 다른 파일, 네트워크 상태, 처리 순서도 영향을 주기 때문입니다. 전송량 계산과 사용자 체감 속도 측정은 따로 보고합니다.

교체 뒤에는 예상한 후보 파일이 실제로 선택되는지 확인합니다. 파일을 만들어 두었어도 페이지가 예전 원본 주소를 계속 참조하면 전송량은 그대로일 수 있습니다. 캐시 때문에 새 파일을 보지 못하는 경우도 구분해야 합니다.

첫 화면의 큰 사진을 모두 지연 로딩하지 않습니다

화면 아래에 있는 이미지의 로딩을 늦추는 방법과 첫 화면의 핵심 이미지를 늦추는 것은 다릅니다. web.dev는 LCP에 해당하는 이미지를 지연 로딩하면 불필요한 로딩 지연이 생길 수 있다고 설명합니다. LCP 최적화 안내

대표 이미지를 포함한 모든 이미지에 같은 설정을 일괄 적용하기보다 실제 측정에서 어떤 요소가 늦게 나타나는지 봅니다. 첫 화면의 중요한 이미지와 아래쪽 참고 사진의 역할을 나누면 개발 담당자에게 요청할 수정도 구체적입니다.

이 글의 회의 사진들도 크기와 구도가 다릅니다. 압축 정도를 비교할 때에는 사람과 사물의 구분이 필요한 수준으로 남는지 확인해야 합니다. 파일 크기는 낮을수록 무조건 좋은 점수처럼 취급하지 않습니다.

수정 전후를 같은 조건에서 비교합니다

점검표에는 기기 또는 화면 폭, 네트워크 조건, 캐시 상태, 확인한 URL, 선택된 파일, 전송량, 측정 시각을 적습니다. 한 번만 재서 달라진 값으로 결론내리기보다 같은 조건에서 반복해 변화가 재현되는지 봅니다.

기술 수정 후에는 사진의 설명도 유지됐는지 확인합니다. alt와 캡션의 구분처럼 의미 전달이 빠지지 않아야 합니다. 페이지가 빨라졌더라도 안내 이미지의 글씨가 읽히지 않거나 잘못된 사진이 표시되면 추가 수정이 필요합니다.

출처 확인일: 2026-10-26. 전송량 사례는 가정이며 특정 파일 형식이나 압축률이 모든 병원 홈페이지에 최적이라고 주장하는 글이 아닙니다.