CSS 또는 HTML에 이미지를 data / base64로 포함시켜야합니까?


131

서버의 요청 수를 줄이기 위해 일부 이미지 (PNG & SVG)를 BASE64로 CSS에 직접 포함했습니다. (빌드 과정에서 자동화 됨)

이처럼 :

background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAFWHRTb2Z0d2FyZQBBZG etc...);

이것이 좋은 습관입니까? 이것을 피할 몇 가지 이유가 있습니까? 데이터 URL을 지원하지 않는 주요 브라우저가 있습니까?

보너스 질문 : CSS & JS 에서도이 작업을 수행하는 것이 합리적입니까?


1
더 이상 IE7을 사용하는 사람은 많지 않으며 모든 단점에는 관리 할 이미지 파일이 적은 좋은 장점이 있습니다! 즉, 나무 구성 요소에 대한 특수 선을 그릴 필요가있는 경우 작은 팔꿈치 이미지를 css 자체에 repeat-x 또는 repeat-y와 함께 포함하면 여분의 이미지 파일이 올바른 위치에 있는지 확인할 필요가 없습니다. 이 사용 사례의 오버 헤드)
DaveAlger

답변:


153

이것이 좋은 습관입니까? 이것을 피할 몇 가지 이유가 있습니까?

IE 호환성이 중요하지 않을 때 CSS 스프라이트와 같이 함께 사용되는 매우 작은 CSS 이미지에만 일반적으로 사용하는 것이 좋으며 요청 저장은 캐시 가능성보다 중요합니다.

다음과 같은 여러 가지 단점이 있습니다.

  • IE6 및 7에서는 전혀 작동하지 않습니다.

  • IE8 에서는 최대 32k 크기의 리소스에서만 작동합니다 . 이것은 base64 인코딩 후에 적용되는 제한입니다. 즉, 32768자를 넘지 않아야합니다.

  • 요청을 저장하지만 대신 HTML 페이지를 부풀립니다! 이미지를 캐시 할 수 없게 만듭니다. 포함하는 페이지 나 스타일 시트가로드 될 때마다로드됩니다.

  • Base64 인코딩은 이미지 크기를 33 % 증가시킵니다.

  • gzip으로 압축 된 리소스로 제공되는 경우 data:이미지는 거의 확실히 서버 리소스에 심각한 부담이 될 것입니다! 이미지는 일반적으로 압축에 CPU를 많이 사용하며 크기를 거의 줄이지 않습니다.


2
@meo 재미있는 포인트. 이미지는 일반적으로 이미 최적으로 압축되어 있기 때문에 이것이 gzip 성능에 좋지 않습니다. 이를 압축하면 한 자리수의 백분율 이득을 위해 끔찍한 CPU 공간이 필요합니다. JPG 파일을 gzipping하면 무슨 뜻인지 알 수 있습니다. 답변으로 편집하겠습니다
Pekka

1
압축 된 이미지를 압축하는 것은 좋은 방법이 아닙니다. 그러나 나는 그것이 아마도 base 64에서 더 효과적이라고 생각했습니다. 특히 소스에 둘 이상의 이미지가있을 때.
meo

2
@meo nope, 기본 패턴이 base64 표기법으로 표현되는 압축 이미지 데이터이기 때문에 어떤 상황에서도 base64에서 더 효과적이지 않습니다.
Pekka

1
@meo 아, 알겠습니다. IE에서는 전혀 작동하지 않으며 동일한 캐시 가능성 문제가 있습니다. 요청을 저장하지만 모든 페이지 요청의 크기가 커집니다. 일반적으로 모든 것을 하나의 CSS와 하나의 JS 파일로 압축하는 것이 훨씬 좋습니다.
Pekka

5
질문에서 알 수 있듯이 CSS 파일에 이미지를 포함시킬 때 HTML 페이지가 팽창 하지 않습니다 .
Daniel Beardsley

38

여기에 일반적인 대답은 합법적 인 이유 때문에 이것이 필요하지 않다는 것을 나타냅니다. 그러나 이들 모두는 최신 앱 동작 및 빌드 프로세스를 무시하는 것으로 보입니다.

폴더 이미지를 살펴보고이 폴더의 모든 이미지가 포함 된 단일 CSS를 생성하는 간단한 프로세스를 설계하는 것은 불가능하지 않으며 실제로는 쉽지 않습니다.

이 CSS는 완전히 캐시되며 서버로의 왕복을 대폭 줄입니다. 이는 @MemeDeveloper가 제안한 가장 큰 성능 히트 중 하나입니다.

물론 해킹입니다. 의심의 여지가 없습니다. 스프라이트와 동일합니다. 완벽한 세상에서, 그때까지는 필요하지 않을 것입니다.

  1. 쉽게 "매끄럽지 않은"여러 이미지가있는 페이지.
  2. 서버 왕복은 실제 병목 현상입니다 (모바일 생각).
  3. 속도 (밀리 초 수준)는 실제로 사용 사례에서 매우 중요합니다.
  4. IE5 및 IE6에 대해서는 신경 쓰지 않아도됩니다 (웹을 계속 진행하려면 원하는대로).

내 견해.


4
더 많은 관심을 끌기 위해 공감해야합니다. 다른 답변은 다소 쓸모가 없습니다. IE6에 대해 이야기하고 있지만 IE8은 요즘에는 쓸모가 없습니다. (그리고 감사합니다)
Hertzel Guinness

11

좋은 습관이 아닙니다. 일부 브라우저는 데이터 URI (예 : IE 6 및 7)를 지원하지 않거나 지원이 제한됩니다 (예 : IE8의 경우 32KB).

데이터 URI 단점에 대한 자세한 내용은이 Wikipedia 기사를 참조하십시오.

단점

  • 데이터 URI는 포함 문서 (예 : CSS 또는 HTML 파일)와 별도로 캐시되지 않으므로 포함 문서를 다시 다운로드 할 때마다 데이터가 다운로드됩니다.
  • 내용은 변경 될 때마다 다시 인코딩되고 다시 포함되어야합니다.
  • 버전 7 (2011 년 1 월 현재 시장의 약 15 %)을 통한 Internet Explorer는 지원이 부족합니다.
  • Internet Explorer 8은 데이터 URI를 최대 길이 인 32KB로 제한합니다.
  • 데이터는 간단한 스트림으로 포함되며 많은 처리 환경 (예 : 웹 브라우저)은 컨테이너 (예 : multipart/alternative또는 message/rfc822)를 사용하여 메타 데이터, 데이터 압축 또는 콘텐츠 협상과 같은 더 복잡한 작업을 지원하지 않을 수 있습니다 .
  • Base64로 인코딩 된 데이터 URI는 이진에 비해 1/3 크기가 큽니다. 그러나 HTTP 서버가 gzip을 사용하여 응답을 압축하면이 오버 헤드가 2-3 %로 줄어 듭니다.
  • 데이터 URI를 사용하면 보안 소프트웨어가 콘텐츠를 필터링하기가 더 어려워집니다.

3
모든 요청에 ​​CSS가 다시 다운로드됩니까? 그것은 새로운 것입니다! 또한 파일을 보관 한 적이 있다면 압축률이 2-3 %가 아님을 알게 될 것입니다! 내가 실수하지 않으면,이 기술이 yahoo.com에서 구현 된 것을 처음 보았습니다. ... 분명히 좋은 습관은 아닙니다!
StefanNch

@StefanNch 그것은 그것이 말하는 것이 아닙니다. 발췌에서 "문서 포함"은 css 파일을 나타냅니다.
Christophe

9

나는 한 달 동안 data-uri를 사용하고 있었고 스타일 시트가 절대적으로 막대했기 때문에 사용을 중단했습니다.

Data-uri는 IE6 / 7에서 작동 합니다 (그 브라우저에 mhtml 파일을 제공하면 됩니다).

data-uri를 사용하면 얻을 수있는 한 가지 이점은 점진적로드와 달리 스타일 시트를 다운로드하자마자 렌더링되는 배경 이미지라는 점입니다.

이 기술을 사용할 수 있다는 것은 좋은 일이지만 앞으로는 그 기술을 너무 많이 사용하지 않을 것입니다. 그래도 시도해 보는 것이 좋습니다.


3

CSS Sprite를 사용하여 이미지를 결합하고 요청을 저장하는 경향이 더 있습니다. 나는 base64 기술을 시도한 적이 없지만 IE6 및 IE7에서는 작동하지 않는 것 같습니다. 또한 이미지가 변경되면 CSS 파일이 여러 개인 경우를 제외하고 손실 된 전체를 다시 전달해야합니다.


나는 이미 스프라이트를 가지고 있는데, 그 방법으로 더 최적화 할 수 있는지 궁금합니다.
meo

2

나는 일반적인 모범 사례에 대해 전혀 모르지만 도움이된다면 그런 종류의 것을보고 싶지 않습니다. :)

웹 브라우저와 서버에는 많은 캐싱 기능이 내장되어 있으므로 서버가 클라이언트에게 이미지 파일을 캐시하도록 지시하는 것이 가장 좋을 것이라고 생각했을 것입니다. 페이지에 실제로 작은 이미지가 많이 있지 않으면 여러 요청의 오버 헤드가 그렇게 큰 것이라고 생각하지 않았을 것입니다. 브라우저는 일반적으로 동일한 연결을 사용하여 많은 파일을 요청하므로 새로운 네트워크 연결이 설정되지 않으므로 HTTP 헤더를 통한 트래픽의 양이 여러 요청에 대해 너무 걱정하지 않는 이미지 파일의 크기와 비교할 때가 아니라면 .

현재 서버에 너무 많은 요청이 있다고 생각하는 이유가 있습니까?


4
perf가 가장 먼저 시도하고 해결해야 할 사항에 관심이 있다면 요청 수는 가장 큰 성능 중 하나입니다. yahoo의 take developer.yahoo.com/performance/rules.html 참조 "구성 요소 수를 줄이면 페이지 렌더링에 필요한 HTTP 요청 수가 줄어 듭니다. 이것이 더 빠른 페이지의 핵심입니다."
MemeDeveloper 2016 년

0

웹 응용 프로그램의 일반적인 아이콘과 같이 매우 자주 사용되는 작은 이미지에 권장합니다.

  • Tiny, Base64 인코딩은 크기를 증가시키기 때문에
  • 초기로드 시간이 길어지기 때문에 종종 사용됩니다.

물론 이전 브라우저의 지원 문제를 염두에 두어야합니다. 또한 프레임 워크의 기능을 사용하여 이미지에 GWT의 ClientBundle과 같은 데이터 URL을 자동으로 인라인하거나 요소의 스타일에 직접 추가하는 대신 CSS 클래스를 사용하는 것이 좋습니다.

자세한 정보는 여기에 있습니다 : http://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.