아카이빙: https://hyeonseok.com/soojung/dev/2017/02/20/811.html

Base64 인코딩과 성능

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

Base64로 인코딩하면 기본적으로 용량이 늘어나기 때문에 큰 이미지에는 적용하면 손해

HTTP 요청 헤더 크기를 크게 넘어가지 않게 대략 1000 바이트 미만의 미지들에만 적용하는게 좋다.

크기가 아주 작은 반투명 배경 이미지 같은 경우는 이미지 파일보다 base64 인코딩해서 CSS에 포함시키는게 더 좋다.

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

-> CSS 스프라이트에 추가한 아이콘들을 삭제하고 다시 구성하는 것보다 얼마되지 않은 용량이니 그냥 추가하여 넣는게 편집상 편하기 때문에 넣는다는 의미인 것 같다.

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

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

참고:
https://gist.github.com/hyeonseok/c55f0c887fec3e3dcb93
https://csswizardry.com/2017/02/base64-encoding-and-performance/
https://csswizardry.com/2017/02/base64-encoding-and-performance-part-2/