이미지 최적화

웹 페이지가 사진을 많이 싣기 시작하면서 용량의 무게중심이 글자에서 이미지로 옮겨 갔습니다. 문제는 이미지를 만드는 사람과 그것을 내보내는 사람이 다르다는 데 있었습니다. 디자이너는 인쇄에도 쓸 수 있게 긴 변 4000픽셀짜리 원본을 내주고, 그 파일이 손대지 않은 채 웹사이트에 올라가고, 사용자 화면에서는 폭 300픽셀 자리에 줄여서 그려집니다. 브라우저는 4000픽셀을 다 받은 다음 300픽셀로 축소합니다. 받는 데 쓴 시간의 대부분이 버려지는 셈입니다.

이게 사무실에서는 잘 안 보입니다. 회사 유선망에서는 2메가바이트짜리 사진도 눈 깜짝할 사이에 뜨지만, 지하철에서 데이터로 들어온 사용자 화면에서는 같은 페이지가 8초 동안 흰 화면입니다. 그래서 문제 제기가 개발팀이 아니라 광고를 돌리는 쪽에서 먼저 나오곤 합니다. 클릭은 샀는데 방문으로 집계되는 수가 절반이라는 식입니다.

웹 성능을 손볼 때는 재는 일이 먼저고, 재고 나면 가장 큰 덩어리로 이미지가 지목되는 일이 흔합니다. LCP는 화면에서 가장 큰 덩어리가 그려지기까지 걸린 시간을 재는 지표인데, 맨 위에 깔린 사진이 그 덩어리인 경우가 많습니다. 이미지 최적화는 그 자리를 겨냥한 기법입니다.

무거운 이미지를 찾아내고, 표시 크기에 맞춰 줄이고, 형식을 바꾸고, 그 과정을 자동으로 돌게 만드는 순서로 진행합니다.

1. 무엇이 무거운지 찾습니다. 브라우저 개발자 도구의 네트워크 탭에서 전송 용량 순으로 정렬하면 상위 열 개 중 몇 개가 이미지인지 바로 보입니다. 페이지 전체가 3메가바이트인데 그중 2.4메가바이트가 사진 넉 장이면 나머지는 볼 것도 없습니다.
2. 표시 크기에 맞춰 줄입니다. 폭 300픽셀 자리에 들어가는 이미지는 600픽셀이면 충분합니다. 화면 밀도가 높은 기기에서 흐려 보이지 않게 두 배까지만 잡아 두는 것이고, 4000픽셀은 어떤 화면에서도 쓰이지 않습니다.
3. 형식을 고릅니다. 같은 사진을 JPEG 대신 WebP 로 내보내면 보이는 차이 없이 용량이 30퍼센트 안팎 줄고, AVIF 는 더 줄어듭니다. 로고나 아이콘처럼 선과 면으로 된 그림은 사진 형식이 아니라 SVG 로 두는 편이 낫습니다.
4. 품질 값을 낮춥니다. 대부분의 도구가 0에서 100 사이 값을 받는데, 100 으로 저장된 사진을 75에서 80 으로 내리면 용량은 절반 가까이 떨어지고 눈으로는 구분하기 어렵습니다.
5. 나머지는 나중에 받게 미룹니다. 첫 화면에 보이지 않는 이미지는 스크롤이 그 자리에 닿을 때 받도록 지연 로딩을 겁니다. 이때 이미지가 들어갈 가로세로 크기를 미리 적어 둬야 나중에 도착한 사진이 읽던 문장을 아래로 밀어내지 않습니다. 화면이 밀린 정도를 재는 CLS가 이 실수에서 나빠집니다.
6. 사람 손에서 뗍니다. 빌드 과정이나 이미지 전용 서버가 업로드된 원본을 받아 크기와 형식을 자동으로 만들게 합니다.

이미지가 페이지 용량의 절반을 넘는 화면에서 가장 먼저 씁니다. 랜딩 페이지, 상품 목록, 사례 소개처럼 사진이 주인공인 화면이 여기 해당합니다.

반대로 효과가 거의 없는 화면도 분명합니다. 관리자 화면이나 설정 화면처럼 글자와 표로 된 페이지는 이미지를 아무리 줄여도 체감이 안 바뀝니다. 여기서는 보내는 데이터를 작게 만드는 압축이나, 한 번 만든 결과를 저장해 뒀다가 다음 요청에 그대로 내주는 캐싱이 맡을 몫이 더 큽니다.

서버가 첫 응답을 늦게 주는 경우도 한계입니다. 요청 뒤 첫 바이트가 돌아오기까지 걸린 시간인 TTFB가 1.5초라면 이미지를 아무리 줄여도 그 1.5초는 남습니다. 손댔는데 숫자가 안 움직이면 이쪽을 먼저 봅니다.

품질을 내리는 데는 합의가 필요합니다. 브랜드 색이나 제품 사진의 질감이 미묘하게 달라지는 선은 팀마다 다릅니다. 개발자가 용량만 보고 값을 낮춰 두면 디자이너가 나중에 발견하고 되돌립니다. 기준값은 처음 한 번 같이 정해 두고 그다음부터 자동으로 적용합니다.

"LCP 잡아먹는 게 히어로 이미지네요. 원본이 2.4메가바이트예요."

첫 화면 맨 위 사진 한 장이 로딩 시간의 대부분을 쓰고 있으니 그것부터 손보자는 말입니다.

"이거 WebP 로 바꾸고 리사이즈만 해도 절반은 빠질 것 같은데요."

형식 변환과 크기 조정이라는 손쉬운 두 단계만으로 목표에 근접한다는 판단입니다.

"이미지 최적화는 빌드에 붙여 두죠. 손으로 하면 다음 달에 원래대로 돌아와요."

일회성 작업으로 처리하지 말고 자동화하자는 제안입니다.

페이지덱이 새 요금제 소개 페이지를 열었을 때입니다. 민서가 스크린샷 여덟 장을 원본 그대로 올렸고 페이지 용량이 6메가바이트가 됐습니다. 현우가 광고 첫날 클릭 대비 방문이 유난히 적은 걸 보고 물었고, 태오가 모바일 회선을 흉내 내 재 보니 첫 화면까지 9초였습니다.

태오가 한 일은 크기를 1600픽셀로 줄이고 WebP 로 바꾸고 아래쪽 네 장을 지연 로딩으로 미룬 것뿐이었습니다. 용량은 6메가바이트에서 900킬로바이트가 됐고 첫 화면은 2초대로 들어왔습니다. 그날 회의에서는 이 작업을 업로드 시점에 자동으로 돌리기로 정했습니다. 사람 기억이 아니라 파이프라인이 처리해야 다음 페이지에서 같은 일을 안 겪기 때문입니다.

화질을 깎는 작업이라고 오해하는 경우가 가장 많습니다. 용량을 줄인다고 하니 그만큼 뭔가를 잃는다고 생각하기 쉽습니다. 실제로는 대부분의 절감이 사용자가 볼 수 없는 부분에서 나옵니다. 4000픽셀을 600픽셀로 줄여도 300픽셀 자리에 그려지는 화질은 그대로이고, 형식을 바꾸는 것도 같은 그림을 더 효율적으로 저장하는 일입니다. 이 오해를 그대로 두면 원본 업로드가 원칙으로 굳고, 모바일 사용자가 매번 쓰이지 않을 픽셀을 내려받습니다.

한 번 정리하면 끝나는 작업으로 보는 것도 흔합니다. 성능 개선 주간에 싹 정리하고 나면 숫자가 확 좋아지니 끝난 것처럼 느껴집니다. 하지만 이미지는 매주 새로 올라옵니다. 새 기능 배너, 블로그 삽화, 고객 사례 로고가 계속 쌓이고 그때마다 원본이 그대로 들어갑니다. 자동화를 걸어 두지 않으면 석 달 뒤에 다시 재 봤을 때 처음 상태로 돌아가 있습니다.