When to Use Base64 Encoded Images (And When Not To)

3년 전, 저는 저희 팀의 주니어 개발자가 우리 React 애플리케이션의 모든 구성 요소에 Base64 인코딩된 이미지를 추가하는 것을 지켜보았습니다. "더 빠른데!"라며 그가 찾은 기사를 가리키며 주장했습니다. 그 기사는 인라인 이미지가 HTTP 요청을 없애준다고 주장했습니다. 2주 후, 우리의 번들 크기는 8.7MB로 불어났고, 초기 페이지 로드는 3G에서 14초가 걸렸으며, CDN 비용은 신비롭게도 세 배로 증가했습니다. 그 값비싼 실수는 저에게 소중한 교훈을 주었습니다: Base64 인코딩은 이론상으로는 훌륭해 보이는 도구 중 하나지만 잘못 적용되면 부담이 됩니다.

저는 사라 첸이며, 지난 12년 동안 성능 엔지니어로서 스크래피 스타트업부터 포춘 500 기업까지 다양한 회사에서 일을 해왔습니다. 5천만 명의 월간 사용자를 지원하는 전자상거래 플랫폼부터, 아무도 최적화가 필요하다고 생각하지 않았던 내부 대시보드까지 모든 것을 최적화했습니다(사실은 필요했습니다). 그 동안, 저는 Base64 인코딩이 훌륭하게 사용되는 것을 보았고, 그것이 애플리케이션 성능을 파괴하는 것도 보았습니다. 차이는 항상 그것이 어떻게 작동하는지를 이해하는 것뿐만 아니라, 실제로 언제 사용하는 것이 의미가 있는지를 이해하는 데 달려 있습니다.

이 기사는 제가 시작할 때 가졌으면 했던 정신적 틀을 제공하려는 시도입니다. 우리는 Base64 인코딩의 기술적 현실을 파고들고, 그것이 빛나는 특정 시나리오를 탐구하며, 더 중요한 것은 그것이 실제로 해로운 상황을 식별할 것입니다. 끝나면, "더 빠르다고 들었다"는 이상의 실제적이고 측정 가능한 이유를 갖게 될 것입니다.

기술적 현실: Base64가 실제로 당신의 이미지에 미치는 영향

많은 개발자들이 간과하는 불편한 진실부터 시작하겠습니다: Base64 인코딩은 당신의 이미지를 대략 33% 더 크게 만듭니다. 가끔이 아닙니다. 항상입니다. 이는 버그나 구현 세부 사항이 아닙니다—기본적인 수학입니다.

바이너리 이미지 데이터를 Base64로 인코딩하면, 8비트 바이트를 안전한 ASCII 하위 집합의 6비트 문자로 변환하게 됩니다. 세 개의 바이너리 데이터는 네 개의 Base64 문자로 변환됩니다. 이것이 33% 오버헤드의 원인입니다: 4/3 = 1.33. 30KB JPEG는 40KB Base64 문자열로 변환됩니다. 100KB PNG는 133KB로 증가합니다. 이 크기 증가는 압축 전, 네트워크 전송 전, 그 외 어떤 일이 발생하기 전의 일입니다.

여기 Base64로 이미지를 인코딩할 때 실제로 발생하는 일이 있습니다. 원래 바이너리 파일—예를 들어, 45KB의 제품 사진—은 원시 바이트로 읽혀집니다. 각 바이트는 0에서 255까지의 숫자입니다. 인코딩 알고리즘은 이러한 바이트를 세 개씩 그룹으로 묶어(총 24비트) 네 개의 6비트 청크로 분할합니다. 각 6비트 청크는 64개의 안전한 ASCII 문자(A-Z, a-z, 0-9, +, /) 중 하나에 매핑됩니다. 결과는 이렇게 생긴 긴 문자열입니다: "/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a..."

이 문자열은 이제 HTML, CSS 또는 JavaScript에 직접 삽입하기에 안전합니다. 그것이 이점입니다. 하지만 그런 안전을 얻기 위해 크기를 지불해야 합니다. 그리고 크기는 대부분의 개발자들이 깨닫는 것보다 더 중요합니다, 특히 모든 킬로바이트가 실제 밀리초 단위의 로드 시간으로 변환되는 모바일 네트워크에서는요.

두 번째 기술적 현실: Base64 문자열은 바이너리 데이터만큼 효과적으로 압축할 수 없습니다. HTTP를 통해 정규 JPEG를 gzip 압축으로 제공하면, 15-20%의 크기 감소를 볼 수 있습니다. 같은 JPEG의 Base64 인코딩 버전을 gzip으로 압축하면, 5-10% 정도의 감소를 볼 수 있습니다. 인코딩 과정은 압축이 덜 되는 패턴을 만듭니다. 따라서 당신의 33% 크기 페널티는 압축이 고려될 경우 종종 40-45% 페널티가 됩니다.

작년에 10KB에서 200KB까지의 500개의 제품 이미지 데이터셋을 사용하여 이 테스트를 수행했습니다. Base64 인코딩과 gzip 압축 후의 평균 크기 증가율은 37%였습니다. 5KB 이하의 이미지에서는 페널티가 42%에 가까웠습니다. 100KB 이상의 이미지에서는 여전히 35%였습니다. 수학을 피할 수는 없습니다.

진정한 이점: HTTP 요청 제거하기

그렇다면 왜 누군가는 Base64 인코딩을 사용할까요? 특정 상황에서는 HTTP 요청을 없애는 것이 크기 페널티보다 더 가치 있기 때문입니다. 이 사실이 실제로 언제 참인지 정확히 말씀드리겠습니다.

"Base64 인코딩은 HTTP 요청을 제거하지 않습니다—단지 JavaScript 번들 안에 숨겨져서 성능에 훨씬 최적화하기 힘든 방식으로 피해를 줍니다."

모든 HTTP 요청에는 오버헤드가 있습니다. 브라우저는 DNS 조회를 수행해야 하고(캐시되지 않은 경우), TCP 연결을 설정하고, TLS 핸드셰이크를 수행해야 하며(HTTPS의 경우), 요청 헤더를 전송하고, 서버의 응답을 기다리고, 응답 헤더를 받고, 마지막으로 콘텐츠를 다운로드해야 합니다. HTTP/1.1의 경우, 이 오버헤드는 상당합니다—좋은 연결에서는 일반적으로 100-300ms, 높은 대기 시간의 모바일 네트워크에서는 500-1000ms입니다.

작은 이미지를 Base64로 인라인하면, 이 모든 것을 제거합니다. 이미지 데이터는 이를 포함하는 HTML, CSS 또는 JavaScript 파일과 함께 도착합니다. 별도의 요청이 없고, 추가 왕복이 없으며, 연결 오버헤드가 없습니다. 작은 이미지—아이콘, 작은 로고, UI 요소의 경우—이는 특히 고대기 시간 연결에서 더 빠른 렌더링을 초래할 수 있습니다.

저는 23개의 작은 아이콘(각각 평균 2.1KB)을 개별 PNG 파일로 로드한 대시보드 애플리케이션에서 이 효과를 측정했습니다. 300ms 대기 시간을 가진 3G 연결을 시뮬레이션한 결과, 모든 아이콘을 로드하는 총 시간은 연결 오버헤드와 브라우저 요청 대기 때문에 4.7초가 걸렸습니다. 이를 Base64로 변환하여 CSS에 인라인 처리한 후, 같은 아이콘이 스타일시트 다운로드의 일부분으로 1.2초에 로드되었습니다. 이는 33% 크기 증가에도 불구하고 3.5초의 개선 효과를 가져왔습니다.

하지만 중요한 세부사항이 있습니다: 이 이점은 HTTP 요청의 오버헤드가 추가 바이트의 비용을 초과할 때만 존재합니다. 2KB 아이콘의 경우, 667바이트의 Base64 오버헤드는 300ms의 대기 시간에 비해 사소합니다. 200KB 이미지의 경우, 66KB 오버헤드는 파괴적이며, 어떤 대기 시간 절약으로도 보상할 수 없습니다.

교차점은 다양한 네트워크 조건에서의 제 테스트를 기반으로 4KB와 10KB 사이 어딘가에 있습니다. 4KB 이하에서는 Base64 인코딩이 종종 이깁니다. 10KB 이상에서는 거의 항상 집니다. 4KB와 10KB 사이에서는 특정 대기 시간 프로필과 캐싱 전략에 따라 달라집니다.

중요한 사용 사례: 작은 UI 요소를 위한 데이터 URI

Base64 인코딩의 가장 합법적인 사용은 초기 렌더링에 중요한 작은 UI 요소입니다. 아이콘, 작은 로고, 로딩 스피너 및 사용자가 즉시 볼 필요가 있는 필수 그래픽에 대해 이야기하고 있습니다.

저는 금융 서비스 회사에서 일한 프로젝트에서, 페이지의 상단에 나타나는 15개의 작은 아이콘이 있는 대시보드를 가진 경험이 있습니다. 이 아이콘들은 핵심 내비게이션의 일부였으며, 페이지 로드의 첫 1.5초 이내에 보이도록 해야 했습니다(우리의 성능 예산). 각 아이콘은 약 1.8KB의 SVG 파일이었습니다.

우리는 세 가지 옵션이 있었습니다: 별도의 파일로 제공할 것인지, 스프라이트 시트로 결합할 것인지, 아니면 Base64 데이터 URI로 인라인 할 것인지. 우리는 WebPageTest를 사용하여 50가지 네트워크 프로필에서 모든 세 가지 접근 방식을 테스트했습니다. 결과는 분명했습니다: 크리티컬 CSS에 포함된 Base64 데이터 URI는 Speed Index를 평균 0.4초 줄였으며, 가장 큰 개선은 고대기 시간의 모바일 연결에서 이루어졌습니다.

이 작업이 성립된 주요 요소는 크기(각 2KB 이하), 중대성(첫 렌더링에 필요), 빈도(모든 페이지에서 사용됨)였습니다. 이 요소 중 하나라도 다르다면 결정이 달라졌을 것입니다.