언제부턴가 아이콘이나 자잘한 이미지들은 base64로 인코딩해서 CSS에 data-uri로 넣는 방법을 즐겨쓰고 있었다. 성능 측면에서 좋은 방법이 아니라는 것은 알지만 장단점을 저울질 해 볼때 내가 만드는 결과물에서는 장점이 더 크다고 생각했기 때문에 약간은 조심하면서 사용하고 있었다.

오늘 base64의 문제점에 대해서 자세히 다룬 글을 봤다. 단점을 좀 극단적으로 부각하기는 했지만 알아두면 좋은 내용들이 잘 정리되어 있다. 두번째 글에서는 데이터를 실측해서 어느정도의 차이가 있는지 더 다양한 관점으로 설명하고 있다.

• 기본적으로 CSS가 수백KB가 되는 것은 문제가 있다.
• Base64로 인코딩된 이미지를 포함한 CSS는 gzip압축률도 더 떨어진다(75% vs 90%).
• 이미지는 랜더링을 막지 않지만 CSS는 랜더링을 막는다. 이미지를 CSS에 넣는 것은 전반적인 랜더링 속도를 늦춘다.
• 브라우저는 점점 똑똑해지고 필요하지 않은 자원을 알아서 걸러내지만 CSS에 합쳐진 이미지는 무조건 다 다운받게 된다.
• 폰트 빨리 뜨게 하려고도 많이 하는데 결국 전체적인 랜더링이 느러진다.
• 폰트나 이미지는 잘 변경되지 않는데 CSS에 포함됨으로써 캐시 가능성도 떨어뜨린다.
• DOMContentLoaded 이벤트는 크게 차이 없지만 그 이후 발생하는 이벤트들은 전반적으로 CSS에 이미지가 포함될 경우 현저히 떨어진다.
• 이미지를 분리해서 프리로드 시킬경우 훨씬 빨리 디코딩 된다.

내가 언제부터 base64 이미지를 사용하기 시작했는지 곰곰히 생각해봤다. 이미지를 수동으로 FTP를 이용해서 배포해야했던 적이 있었는데 그때 하도 짜증이 나서 그때부터 CSS에 이미지를 포함시키기 시작했었다. 그 이후로도 회사이름에 걸맞지 않게 그 행태는 계속 지속됐고 이미지를 자동으로 압축해서 base64로 인코딩하는 스크립트도 만들고 이게 더 편해져서 계속 써왔던 것 같다.

Base64로 인코딩하면 기본적으로 용량이 늘어나기 때문에 큰이미지에는 적용하면 오히려 손해다. HTTP 요청 헤더 크기를 크게 넘어가지 않게 대략 1000 바이트 미만의 이미지들에만 적용해왔다. 크기가 아주 작은 반투명 배경 이미지 같은 경우는 이미지 파일보다 base64 인코딩해서 CSS에 포함시키는게 더 좋다고 생각한다.

스프라이트 이미지 관리 측면에서도 덩치큰 한장짜리 복잡한 스프라이트 이미지보다 base64로 인코딩 하는 것이 삭제나 수정이 수월하다. 보통 오래된 스프라이트 이미지는 각 이미지의 사용처가 불분명해서 삭제는 거의 못하고 추가만 하는 경우를 흔치 않게 볼 수 있다. CSS에 넣게되면 셀렉터 정보가 있기 때문에 사용처를 보다 명확하게 알 수 있다.

하지만 스프라이트 이미지 보다 base64로 인코딩하는 것이 일반적으로 좋다는 말은 아니다. 대부분의 경우에는 스프라이트 이미지가 성능 측면에서 확실한 강점을 가지고 있기 때문에 base64를 선택해야 하는 경우는 소규모 사이트나 스프라이트 할 수 없는 작은 배경 이미지 같이 특수한 경우에 해당한다. 스프라이트 이미지 관리가 문제가 된다면 다양한 스프라이트 이미지 관리 툴을 도입하는 것이 우선일 것이다(정봉겸님 지적 감사합니다).

어느 기술이든 과유불급이다. 저 글에서는 base64는 절대 쓰면 안되는 것 처럼 표현되어 있는데 너무 과하게 쓰면 그렇겠지만 장단점을 잘 파악하고 적재적소에 잘 사용한다면 base64 인코딩도 그렇게 나쁜 것만은 아니다.