나는 그리스 몽키 사용자 스크립트의 출처를보고 있었고 CSS에서 다음을 발견했습니다.
.even { background: #fff url(data:image/gif;base64,R0lGODlhBgASALMAAOfn5+rq6uvr6+zs7O7u7vHx8fPz8/b29vj4+P39/f///wAAAAAAAAAAAAAAAAAAACwAAAAABgASAAAIMAAVCBxIsKDBgwgTDkzAsKGAhxARSJx4oKJFAxgzFtjIkYDHjwNCigxAsiSAkygDAgA7) repeat-x bottom}
greasemonkey 스크립트는 서버에서 호스팅하는 대신 소스 내에 가능한 모든 것을 번들로 제공하고 싶다는 것을 이해할 수 있습니다. 그러나 이전 에이 기술을 보지 못했기 때문에 그 사용을 고려했으며 여러 가지 이유로 매력적입니다.
- 페이지로드시 HTTP 요청의 양이 줄어들어 성능이 향상됩니다.
- CDN이 없으면 이미지와 함께 전송되는 쿠키를 통해 생성되는 트래픽 양이 줄어 듭니다.
- CSS 파일을 캐시 할 수 있습니다
- CSS 파일은 GZIPPED 일 수 있습니다
IE6 (예 :)에 배경 이미지 캐시에 문제가 있다고 생각하면 최악의 생각이 아닌 것 같습니다 …
그렇다면 이것이 좋은 습관인지 나쁜 습관입니까? 왜 그것을 사용하지 않습니까? 이미지를 base64로 인코딩하는 데 어떤 도구를 사용 하시겠습니까?
업데이트-테스트 결과
-
이미지 테스트 : http://fragged.org/dev/map-shot.jpg – 133.6Kb을
-
테스트 URL : http://fragged.org/dev/base64.html
-
전용 CSS 파일 :
http://fragged.org/dev/base64.css –
178.1Kb -
GZIP 인코딩 서버 측
-
클라이언트에 전송 된 결과 크기 (YSLOW 구성 요소 테스트) : 59.3Kb
-
클라이언트 브라우저로 전송 된 데이터 저장 : 74.3Kb
멋지지만 작은 이미지에는 약간 유용하지 않습니다.
업데이트 : Google의 소프트웨어 엔지니어 인 Bryan McQuade는 PageSpeed에서 일하면서 ChromeDevSummit 2013에서 표현한 CSS의 data : uris는 대화 중 중요 / 최소 CSS를 전달하기위한 렌더 차단 반 패턴으로 간주됩니다
#perfmatters: Instant mobile web apps
. 참조 http://developer.chrome.com/devsummit/sessions을 하고 명심 – 실제 슬라이드
답변
이미지와 스타일 정보를 별도로 캐시하려는 경우에는 좋지 않습니다. 또한 큰 이미지 또는 많은 수의 이미지를 CSS 파일로 인코딩하면 다운로드가 완료 될 때까지 스타일 정보없이 사이트를 떠나 파일을 다운로드하는 데 브라우저가 더 오래 걸립니다. 작은 이미지의 경우 자주 변경하지 않으려는 경우 훌륭한 솔루션입니다.
base64 인코딩을 생성하는 한 :
- http://b64.io/
- http://www.motobit.com/util/base64-decoder-encoder.asp (업로드)
- http://www.greywyvern.com/code/php/binary2base64 (아래에 작은 자습서가있는 링크에서)
답변
이 답변은 최신 정보가 아니므로 사용해서는 안됩니다.
1) 2017 년 모바일에서 평균 대기 시간이 훨씬 빨라졌습니다. https://opensignal.com/reports/2016/02/usa/state-of-the-mobile-network
2) HTTP2 멀티 플렉스
https://http2.github.io/faq/#why-is-http2-multiplexed
모바일 사이트에는 “데이터 URI”를 반드시 고려해야합니다. 셀룰러 네트워크를 통한 HTTP 액세스는 요청 / 응답 당 대기 시간이 길어집니다. 따라서 이미지를 CSS 또는 HTML 템플릿으로 데이터로 잼하는 것이 모바일 웹 앱에서 유용 할 수있는 사용 사례가 있습니다. 사례별로 사용량을 측정해야합니다. 데이터 URI가 모바일 웹 앱의 모든 곳에서 사용되어야한다고 주장하지 않습니다.
모바일 브라우저에는 캐시 할 수있는 파일의 총 크기에 제한이 있습니다. iOS 3.2의 한도는 꽤 낮았지만 (파일 당 25K) 최신 버전의 Mobile Safari에서는 더 커집니다 (100K). 따라서 데이터 URI를 포함 할 때 총 파일 크기를 주시하십시오.
http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/
답변
해당 이미지를 한 번만 참조하면 CSS 파일에 이미지를 포함시키는 데 문제가 없습니다. 그러나 둘 이상의 이미지를 사용하거나 CSS에서 여러 번 이미지를 참조해야하는 경우 단일 이미지 맵을 사용하는 대신 단일 이미지를자를 수 있습니다 ( CSS Sprites 참조 ).
답변
내가 제안 할 것 중 하나는 두 가지 별도의 스타일 시트를 갖는 것입니다. 하나는 일반 스타일 정의가 있고 다른 하나는 base64 인코딩의 이미지가 포함되어 있습니다.
물론 이미지 스타일 시트 앞에 기본 스타일 시트를 포함시켜야합니다.
이 방법을 사용하면 일반 스타일 시트를 최대한 빨리 문서에 다운로드하여 적용 할 수 있지만 동시에 HTTP 요청 감소 및 기타 데이터 이점으로 인한 이익을 얻을 수 있습니다.
답변
Base64는 GZipped 이후 이미지 크기에 약 10 %를 추가하지만 모바일에서 이점을 능가합니다. 반응 형 웹 디자인에는 전반적인 추세가 있으므로 적극 권장합니다.
또한 W3C는 모바일에이 접근 방식을 권장하며 레일에서 자산 파이프 라인을 사용하는 경우 이는 CSS 압축시 기본 기능입니다.
답변
비 편집 이미지에 대해 별도의 CSS 파일을 작성하라는 권장 사항에 동의하지 않습니다.
이미지가 UI 목적을위한 것으로 가정하면, 프리젠 테이션 레이어 스타일이며, 위에서 언급했듯이 모바일 UI를 수행하는 경우 모든 스타일을 단일 파일로 유지하여 한 번 캐시 할 수있는 것이 좋습니다.
답변
필자의 경우 CSS 이미지가 이미 포함되어 있기 때문에 관련 이미지 복사에 대해 걱정할 필요없이 CSS 스타일 시트를 적용 할 수 있습니다.