관심사2/디자인

웹사이트 이미지 용량 최적화 테크닉 간단 팁

MIRiyA☆ 2012. 6. 30. 02:22

(2016/05/02) 근 4년 전에 쓴 글이다보니 중간중간에 헛소리가 많이 있다. 쪽팔리지만 자체 성찰을 하고 기록을 남겨놓도록 하겠다. 

1. jQuery를 안쓰게 하면 유혈 사태가 벌어진다고 했는데, 요새는 jQuery는 악의 축 정도로 몰리고 있다. 안쓰는게 좋다. 

2. PHP에서 주석 따위를 지운다고 코딩된 결과물의 용량이 줄거나 그러진 않는다.


그냥 써야지 써야지 하다가 시간내서 한번 적어보는 최적화 팁이다.

웹 사이트의 로딩 속도를 측정해서, 어떤 요소가 로딩 속도를 저하시키는지 알아낸 다음, 해당 요소의 용량을 줄이는 식으로 최적화 하는 방법이다. 아마 중수 이상은 다들 알고 있을만한 부분이니 그냥 훑고 넘어가보자. 최적화 뭐 이런말 들어가니 왠지 개발스럽지만 이 글을 디자인 항목에 이 글을 적은 이유는, 포토샵에서 하는 일이라 그렇다. 디자이너 컴퓨터에 비주얼스튜디오나 이클립스가 설치되어있지 않은게 대부분이듯, 개발자 컴퓨터에도 포토샵이 거의 설치되어있지 않다. 여튼 이건 디자이너 일이라 생각하니 한번 훑어보자.




웹페이지 속도 측정


그냥 아무나 다 할 수 있는 방법이다. 일단 크롬 브라우저를 켜서, 원하는 웹페이지로 들어간다. 크롬이 설치되어있지 않다면 설치하자. 뭐라 토달지 말고 크롬은 그냥 설치 해라. 이 글 읽는 정도의 분들이라면 다들 나보다 잘하는 분들일테니 아마 대부분 크롬은 깔려있을 것이다.




위의 페이지는 주변에서 흔히 볼 수 있는 게시판형 웹사이트이다. CMS는 그누보드를 사용하고 있다.

크롬 켰으면 속도 측정을 원하는 페이지에서 F12를 눌러준다.




그럼 위와 같이 하단에 개발자 요소 검사 도구가 뜬다. 상단에서 Network 탭에 들어가자. 

그리고 Ctrl+Shift+F5를 눌러준다. 그럼 잠시 후 우측 타임라인에 뭔가 이상한 그래프 같은게 쭉쭉 그려진다. 




혹시 위와 같이 사이즈 부분에 from cache가 뜨면 캐싱된걸 불러온것이므로 결과값이 정확하지 않다. 

다시 Ctrl+Shift+F5를 눌러서 재시도하자. 




그리고 위의 Size를 눌러 크기순으로 정렬해준다. 

목록의 맨 아래에는 이 페이지를 로딩하는데 몇번의 HTML요청이 있었는지, 몇 kb의 데이터가 전송되었는지, 전부 로딩하는데 몇초가 걸렸는지 보여준다. 위 샘플을 보면 뭔가 내놓으라고 58번 요청을 했고, 총 350kb 정도가 전송되었으며, 로딩하는데 1.3초가 걸렸다는걸 알 수 있다. 이걸 줄여야된다. 이제 목록 맨 위로 올라가보자.




일단 용량 10kb 넘는것까지 한번 잘라봤다. 저놈들이 대부분의 로딩 시간을 잡아먹는 덩치큰 녀석이기 때문에, 이놈들의 덩치를 줄이는 방법을 알아보겠다. 


쭈욱 보면서 하나하나 설명해보자. 


# jQuery-1.4.2.min.js 이건 웹페이지에 이런저런 효과 주고 이런저런 도움 주는 jQuery라는거다.

혹시 웹개발자랑 유혈 난투극 벌이고 싶은 수퍼갑이라면 웹개발자에게 요구사항 전할때 "jQuery의 첫글자 소문자가 맘에 안들기 때문에 개발할때 jQuery는 사용하지 말아주세요."라고 말해보자. 여튼 이건 중간에 min이라는 글자가 의미하듯 이미 한번 압축이 되어있는거라 용량 줄일 여지가 크지 않다. 신경쓰지 말길.


# board.php 이건 게시판 코어 부분이다. 여기서 용량 줄이는건 개발자 몫이고, 뭐 각종 주석을 지운다던가, 코드를 최적화한다던가 하는 식으로 용량을 줄일 수 있다. 여튼 이것도 개발자 몫이니 신경쓰지 말자. 저 밑에 있는 wrest.js, common.js 이런것도 신경쓰지 말자.


# 2QjfPbkAbm 뭐야 이 거지같은 이름은;; 이름은 거지같은데 저건 그냥 아래와 같이 생긴 그림 파일이다. 이상, 위에 있는 저 js 파일, php파일 등을 제외한 파일들은 모두 그림 파일들을 두고 설명해보자.



위의 그림 파일(2QjfPbkAbm)이 용량이 29.73KB인데, 용량에 대해 감이 있는 사람이라면 이게 터무니 없이 큰 용량이라는걸 알 것이다.




무려 이 파일 용량이 70KB다;; 저 붉은 글자 따위가 뭔데 이 복잡한 사진 용량의 거의 절반을 먹는단 말인가.


이제부터 포토샵의 옵션을 적용하여 파일 크기를 최적화는 방법에 대해 알아보자.(위 이미지가 샘플 이미지이긴 하지만, 다음 블로그에 첨부할때 자동으로 JPG로 바뀌므로 저걸 받아서 연습하려 하진 말자. 연습용 그림이 필요하다면 온천지에 널린 다른 이미지를 선택하면 되지 않겠나..)



포토샵에서 열어보면 이런식으로 투명도가 적용되어있다. 여기서 P 글자는 투명도가 적용되어있지 않은데, 나머지 부분에는 투명도가 없다. 이 말은 투명도가 딱히 필요 없는 요소였다는 말도 된다. 따라서 그냥 흰 배경으로 저장했으면 용량을 더 아낄 수 있었다는 것이다.




포토샵에서 Ctrl+Alt+Shift+S를 누르면 나오는 Save for Web & Devices 화면인데, 각종 세팅을 바꿔가면서 용량을 비교해서 맘에드는 쪽으로 저장을 할 수 있는 아주 좋은 기능이다. 상단 왼쪽에 보면 오리지널, 옵티마이즈드, 2업, 4업 이런식으로 있는데, 오리지널은 저장 전의 이미지고, 옵티마이즈드는 최적화된 이미지, 2업은 오리지널과 최적화된 이미지 하나씩 같이 보여주는거, 4업은 오리지널 하나랑 최적화된 이미지를 세팅별로 3개까지 더 보여주는거다. 보통은 2업으로 세팅하고 사용한다.


상단 우측에 보면 GIF, JPEG, PNG-8, PNG-24, WBMP 뭐 이런식으로 세팅을 고를 수 있다. 디자이너분들이라면 다들 아시겠지만, 이 글은 초보자를 위한 강좌기 때문에 노인복지회관 어르신 포토샵 강좌에서만 나올법한 파일 확장자별 특징에 대해 짚고 넘어가겠다.



JPEG

우리가 흔히 카메라로 사진 찍으면 나오는 사진용 확장자다. 저장을 할 때 근처 유사한 색상의 픽셀을 뭉개서 저장하는 특징이 있는데, 이 뭉개기 덕분에 원본이 손실된다. 하지만 사람 눈이 그리 정밀하지 않기 때문에 어느정도 수준의 뭉개짐은 용인이 된다.



위는 용인되지 않을 정도로 아주 심하게 뭉갠 좋은 사례.

원본 이미지가 원래 654KB였는데, 퀄리티 0으로 맞추고 저장하면 용량 40KB면 떡을 친다.




이건 퀄리티 80 정도인데, 보면 오리지널이랑 거의 구분도 안간다. 654KB에서 291KB로 거의 반 이상 용량이 줄어든걸 볼 수 있다. JPG파일의 이미지 최적화는 이런식으로 한다. 사람 눈이 구분할 수 있는 범위이냐 아니냐 정도로 해서 퉁치는게 JPG파일. 이렇게 복잡한 이미지는 반드시 JPG 파일로 저장해야한다.




GIF

이건 8비트, 즉 256가지 색상만 표현할 수 있는 무손실 압축 포멧이다. 거기다가 애니메이션을 지원하기도 하고, 투명색을 지원하기도 한다. 아래의 이미지를 예로 들어보자.



뒷바탕이 투명이고, 사용한 색상이 몇개 안된다. 이 경우엔 보통 GIF로 저장하는게 정석이다. 요걸 JPEG로 저장할 경우 투명한 부분은 살리지도 못하거니와, 용량은 100KB가 넘어간다. 거기다가 JPEG 특유의 뭉갬까지 고려하면 장점이 전혀 없다. 용량이 작은것도 아니고, 이미지가 제대로 나오는것도 아니고. 하지만 투명 GIF로 저장하면 17KB의 적은 용량으로 위 모든 색상을 손실없이 표현하면서 적은 용량으로 보여줄 수 있다.


하지만 아래와 같은 경우에는 상황이 달라진다.




한쪽은 투명도가 있는 M글씨, 한쪽은 투명색에 그라데이션이 들어간 A글씨다.

이걸 GIF로 저장할 경우 아래와 같이 나온다.




그냥 이미지가 쓰레기가 되어버렸다. GIF는 이렇게 투명한 색을 단 한가지 색상으로 밖에 표현하지 못한다. 투명하면 투명한거고, 아니면 아닌거고.. 애매한 색을 표현하지 못하기 때문에 GIF는 이런 부분에서는 사용할 수 없다. 이런 경우 뒤에서 이야기할 PNG24로 저장해야한다.


그리고 PNG8의 경우 GIF와 동일하게 256색만을 표현하는데, 특성이 거의 같다고 보면 된다.




PNG24

이놈은 GIF처럼 무손실로 이미지를 보여주긴 하는데, 24비트, 즉 1677만 7216가지 색을 표현할 수 있는 방식이다. 여기 투명도가 들어가면 투명색까지 합쳐서 PNG 32비트로 저장된다. 그러니까, 투명도가 있고, 무손실로 보여줘야 하는데, 좀 고화질이 필요하다 싶으면 PNG24를 사용하면 된다. 위에 보여줬던 MA 글씨 같은건 PNG24로 저장하면 딱이다. 그리고 이 PNG24 외엔 저 디테일을 다 살릴 수 있는 대안도 없다. 


정말 화질로선 최고로 좋게 보여줄 수 있는데다가, 투명영역도 충실하게 보여줄 수 있는 PNG24는 거의 무적의 포멧으로 보이지만.. 약간의 단점이 있기 때문에 다른 포멧을 쓰기도 한다. 일단 GIF보다 용량이 큰 경우가 많다.



이런식으로 투명한 영역이 칼같이 떨어지는 이미지, 사용한 색상이 256색을 초과하지 않는 범위 안에서는 GIF를 사용하는게 좋다. 라고들 다들 알고 있는데..


디자이너들은 대부분 GIF가 PNG보다 용량이 작다고 생각하는데, 이게 실제로 변환을 시켜보면 PNG가 GIF보다 용량이 작은 경우가 아주 빈번하게 일어난다. 실제로 위의 이미지의 경우 GIF로 저장하면 용량이 17.5KB가 나오는데, PNG8의 경우 4.8KB, PNG24의 경우 10.8KB가 나온다. 256색 팔레트를 초과하지 않음에도 불구하고 GIF가 용량이 큰건 뭔가 알고리즘의 차이가 있는것 같다.


이쯤 가면 머리가 혼란스러워진다. 아놔 JPEG는 확실히 알겠는데 GIF, PNG8, PNG24 이거 다 어떻게 골라?

그냥 Ctrl+Alt+Shift+S 눌러서 Save for Web & Devices 창 띄우고, 각각 GIF, PNG8, PNG24 눌러가며 용량을 비교해봐라. 그 중 가장 적은 용량에 손상이 적은 포멧으로 저장하면 된다.



아, 추가로 한가지 더 말하자면 IE6에서는 반투명 PNG가 배경이 회색으로 렌더링되는 또라이같은 버그가 있다. 이 부분에 대해서는 그랜드마스터 정찬명님 블로그를 참조하자. 이 문제 때문에 아마 디자이너들이 의식적으로 PNG를 꺼리게 되지 않았나 싶다.





실전 최적화


뭐 여튼 PNG라고 용량 많이 나가는게 아니니까 직접 재보고 결정하라는게 내 할 말이고, 아까의 최적화 이슈로 넘어가자. 글이 뭔가 좀 이리갔다 저리갔다 하는데 간만에 블로그에 글쓰는거라 손이 안풀려서 그런가보다. 솔직히 몇시간동안 스샷 찍어가면서 글 쓰면 흐름을 놓치기가 쉽다.



자 이 이미지, 투명은 필요없었고, GIF든 PNG든 만만한거 하나 고르면 되겠다. Save for Web & Devices로 체크한 결과, 원본 PNG파일은 29.5KB, GIF 버전이 10.8KB, JPEG 퀄리티 80짜리가 16KB, PNG8 버전이 10.4KB, PNG24 버전이 18.5KB, PNG24 투명도 버전(PNG32)이 27.3KB 요렇게 나오더라. 둘 다 JPEG를 제외하곤 화질 차이가 눈꼽만큼도 없으므로 가장 용량이 작은 8비트 PNG로 저장하는게 용량면에서 낫다.

결과적으로 29.5KB의 원본 파일이 10.4KB로 줄어들었다. 거의 1/3으로 줄었다. 


이건 이정도로 하고, 다음 파일로 넘어가보자.



여러분들이 메모리 부족을 겪으므로.. 다시 목록을 갖고와보면.. 저 거지같은 2Q 어쩌고 파일을 방금 해치웠고, 0ldOos3NCC라는 이상한 파일을 보자. 이건 아래와 같은 애니메이션 들어간 GIF 파일이다.



이거 용량이 20.86KB인데, 이건 어떻게 더 줄일 수 있을까? GIF가 기본적으로 무손실 압축이긴 하지만 저렇게 사진을 배경으로 쓰고 있는 이상 이미 한번 256색 이내로 색상이 줄어들었다. 그래서 이걸 뭐 디더링 옵션을 Diffusion을 주나 Noise를 주나 용량에는 큰 변화가 없다. 이미 GIF 표현 한계 이내로 제한된 색상 팔레트에선 용량을 줄이려면 그냥 색을 제거하는게 더 낫다.



이런식으로 Perceptual을 Restrictive로 바꾸면 용량이 확 줄어드는걸 볼 수 있다. 기본 용량 20.86KB에서 저장하고 난 다음엔 9.65KB로 용량이 줄어든다. 거의 절반이다. 물론 잘 보면 색정보가 많이 빠진걸 알 수 있는데, 어차피 GIF 색상이 거지같은 이상 그리 크게 차이 나지 않는것 같아 그냥 써본다.


  


많이 차이가 나는가? 저기 왼쪽 위에 '조치원점 더비'라는 글자를 잘 보면 차이가 좀 나긴 한다.


요것도 됐고, 다음은 뭘까.



저기 뭔가 알록달록한 2042 어쩌고 JPG 파일이 보인다. 저것들 한번에 다 몰아서 최적화 해보자.


    


보여지는 사이즈가 보다시피 아주 작다. 근데 이 작은놈 하나하나가 방금 내가 최적화한 카페 더비 거대한 애니메이티드 GIF보다 크다는건 문제가 좀 있는 것이다. Save for Web & Devices 화면을 띄워보자.



좌상단부터 시계방향으로 오리지널, GIF, PNG24, PNG8이다. 넷다 화질 손실은 전혀 없다. GIF나 PNG8이나 8비트 256색 팔레트를 초과하지 않는 색상으로 이루어져있기 때문이다. 어이없게도 여기서 PNG24가 용량이 가장 적은걸 알 수 있다. 저게 시뮬레이션 결과라 정확하지 않을수도 있지만, 실제 저장 결과도 마찬가지였다. GIF로 저장한건 1.15KB, PNG8로 저장한게 1.18KB, PNG24로 저장한게 1.07KB가 나왔다. 결과적으로 PNG24로 저장하는게 가장 용량이 작은 셈이다.


좀 더 하드코어 튜닝을 하자면, 




이렇게 확대를 해서 쓸데없는 부분을 지워주면 용량 절약에 도움이 된다. 이게 원본이 JPG 파일인데, JPG 파일 압축률때문에 생긴 지저분한 흔적이 남아있어 용량을 먹는다. 그래서 우측과 같이 잡다한 부스러기를 직접 지워주었다. 용량의 경우 아주 눈꼽만큼 줄어든다.




아까랑 비교해서 약 0.05~0.1KB 정도 용량이 줄어든걸 알 수 있다. 이게 이미지가 작아서 별로 차이가 없지만, 큰 이미지로 가면 차이가 커질 것이다. 물론 용량대비 노동이 너무 많은건 인정. 그럼 여기서 좀 더 똑똑하게 줄이는 방법을 더 알아보자.




파일 포멧을 모두 PNG8로 선택하고, 컬러 팔레트를 32, 64, 128로 줘봤다. 오리지널은 좌상단에 있으니 비교해보자. 팔레트를 줄이니 용량이 정말 드라마틱하게 줄어든다. 특히 32컬러만 사용하자 414byte만 차지한다. 16컬러로 내리니 차이가 확 보여서 그건 못쓰겠고.. 일단 확대한번 해보자.




보면 32컬러의 경우 자주색 부분 색이 완전 뭉쳐버렸다. 저건 쓰면 안되겠고, PNG8 64컬러로 저장하면 550byte의 적은 용량으로 최적화 할 수 있다. 원래 용량 14.66KB에서 550byte라니 1/30 정도로 용량이 줄어들었다.




이건 다른 예. 아까는 색상이 좀 많았는데, 이번엔 색상이 한 톤으로 일정해서 비교차 올려봤다. 이번에도 PNG24 < PNG8 < GIF 순으로 용량이 커지는걸 볼 수 있다. 아까처럼 팔레트를 제한하면 어떻게 될까?




32컬러로 팔레트를 제한하니 이번에는 GIF의 용량이 PNG8보다 작아지는걸 볼 수 있다. 게다가 원본이랑 별로 차이도 없어보인다. 이런식으로 이미지 압축은 정말 캐바캐라는걸 알 수 있다. 이번엔 14.08KB에서 280byte로 최적화했다. 1/50배로 용량을 줄일 수 있었다.


여기 더해 컬러 테이블을 직접 골라서 쓰는 방법도 있지만, 그보다는 그냥 팔레트 숫자를 줄이면 포토샵이 알아서 해주니까 이쪽이 더 생산성 있는 방법이다.


이번 강좌에서 결과적으로 이미지들의 용량을 118.46KB에서 30.45KB로 줄일 수 있었다. 이게 정말 코딱지 킬로바이트만한 수준이지만 웹 서비스의 규모가 커질 수록 용량 최적화의 중요성이 커진다. 만약 어떤 서비스가 월 트래픽 10GB 제한 계정을 사용하고 있고, 방문자 수가 하루 5000명이라면 80KB를 줄이면  피같은 400MB 트래픽을 줄일 수 있다. 단순히 한 페이지 안에서만 이정도니 여러 페이지를 곱해보면 얼마나 커지겠는가?


물론 이런 자잘한것에 신경쓰느니 월 5000원 무제한 트래픽의 이미지 링크 계정을 사용한다던가, 전체 코드를 수정해서 용량을 최적화하는게 큰 그림으로 봤을 때 더 좋을 것이다. 하지만 디자이너는 디자인 그 이상의 것까지 신경쓰는 덕목이 필요하다고 생각한다.


여기서 더 나아가 CSS Image Sprite 기법이라던가, 선들을 죄다 CSS로 그려버리는 다른 최적화 방법도 있지만 이건 좀 더 개발에 가까운 부분이라 이 글에선 다루지 않고 이만 끝을 맺겠다. 부디 도움 많이 되었기를.