태그 보관물: base64

base64

CSS 또는 HTML에 이미지를 data / base64로 포함시켜야합니까? 자동화 됨) 이처럼 : background:

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

이처럼 :

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

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

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

답변

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

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

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

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

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

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

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

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

답변

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

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

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

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

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

내 견해.

답변

좋은 습관이 아닙니다. 일부 브라우저는 데이터 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를 사용하면 보안 소프트웨어가 콘텐츠를 필터링하기가 더 어려워집니다.

답변

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

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

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

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

답변

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

답변

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

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

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

답변

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

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

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

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