본문으로 바로가기

데이타 URI 스킨(Data-URI scheme)으로 블로그 이미지 교체하기를 해보겠습니다.


가끔 codepen에서 코드를 찾다보면 배경을 괴상망측한 아스트랄한코드를 배경으로 쓰는 사람들이 있습니다

바로 이거죠!


<img src="https://t1.daumcdn.net/cfile/tistory/2158934B56E764F334" alt="휘인.jpg" />

근데 열어보면 이런 이미지가 나옵니다. 마우스 우클릭해서 소스보기를 해보세요.

휘인.jpg


이것은 원본사진입니다. 두개가 똑같습니다.


Data-URI scheme.txt



코드를 펼쳐보면 보이지도 않습니다. 한글 파일로 6페이지가 넘습니다.

원래사진이 흐린거지 다운로드해보면 원본파일과 크기 용량 모두 같습니다.


보통 우리가 알고 있는 이미지를 불러 올때는 서버나 공간에 파일을 올려두고

<img src="파일경로">

경로를 입력해서 이미지를 표시하는게 우리가 일반적으로 알고있는 이미지를 표현하는 방법인데


위 방법은 이미지를 html코드로 작성해서 읽어서 표현합니다!!!!!

code=이미지인 셈이죠. 별도의 파일없이!! 코드만으로도 표현이 가능합니다.


단, 이미지의 크기가 클수록 코드가 엄청 늘어나겠죠? 


이게 바로 데이타 URI 스킴(Data-URI scheme) 이였습니다.


Data URI는 RFC 2397에서 정의되었으며, 외부 파일을 웹페이지에 인라인으로 넣기 위해서 사용 합니다.

 형식은 data:[<MIME-type>][;charset=<encoding>][;base64],<data>이며

base64로 인코딩을 하며 이미지 뿐만아니라 문서, 파일, 동영상, 플래쉬, GIF 심지어 웹폰트도 변환이 가능합니다.


장점은 페이지를 로드 할 때 따로 파일을 별도로 부르는 것이 아니고 HTML에 포함 되어 있기 때문에

HTTP header나 TCP 패킷 크기가 맞지 않아서 발생하는 overhead가 발생하지 않습니다. 

결과적으로 네트워크 Request 가 줄어들게 됩니다.


단점도 물론 있습니다. HTML에 있다보니 브라우저 캐시가 되지 않습니다.

페이지를 열 때 마다 읽어버립니다.( 배경 이미지를 하면 안좋겠죠??)

base-64로 인코딩이 되면서 헤더에 814바이트가 추가되고 크기가 약1.37배정도 증가하게 됩니다.

그래서 600Byte가 넘어가는 이미지는 손해하지만 요즘은 gzip압축을 하기 때문에 큰차이는 없다고 합니다.

이게 아주 오래전부터 나온 기술이지만 그당시는 브라우저가 따라가지 못해서 활성화는 되지 않았던 것 같습니다.


인터넷익스플로우 파이어폭스 사파리 크롬 오페라

IE7이하 미지원 IE8 일부지원

지원

지원

지원 지원


IE8도 지원을 하지만 32KB가 넘는 파일는 못읽는다고 합니다.

모바일에서 외부파일인 바이너리 경로를 사용하는 것보다

데이타 URI를 사용하면 6배나 느리다라는 기사가 있긴한데..


확인해보니 안드로이드 2.3이하의 환경 그리고 IOS5이하에서 급격히 느림이 발생하는데

그이상에는 읽는 속도는 차이가 없는 것 같다 차이가 나긴하지만

이제는 스마트폰이 발전해 원래 빠르게 읽기 때문에

지금 현재 안드로이드는 6.0 마시멜로과 아이폰은 iOS 9가 출시되었습니다.


아무튼 지금은 대부분의 브라우저에서 지원을 하기 때문에 큰문제가 없어보입니다.


특히 예전부터 많은 이들이 웹폰트에 사용 하는 것으로 방식인데,

크기가 큰 웹폰트를 가져오면서 시간이 걸리므로 블로그 전체 글꼴이 한번에 열자마자 안바뀌고

로딩이 진행되면서 수차례 글꼴이 뒤틀리는 현상 FOUC가 발생하는 것을

줄이기 위해 많이 사용한다고 합니다.


FOUC 방지 처리가 되지 않은 블로그 스킨에서

ctrl + shift + delete 키를 누르고 웹 페이지 캐시를 삭제한다음

새로고침(F5)를 했을때 해당 현상이 발생한다면 FOUC 방지처리나

데이타 URI 스킴(Data-URI scheme)으로 로드한다면 해당 현상을 줄일 수 있겠죠?!


요즘은 쉽게 인코딩을 해주는 사이트들이 많습니다.


여기는 간편하지만 용량제한이 있으며

http://www.abluestar.com/utilities/encode_base64/index.php

https://dopiaza.org/tools/datauri/index.php

여기서는 주로 웹폰트를 Data-URI로 인코딩을 해줍니다.

http://www.fontsquirrel.com/tools/webfont-generator


저도 전체적인 블로그의 이미지를 교체했습니다.

배경이나 로고나 footer 부분이나 전체적인 틀부분은 건들이지 않고


소셜 공유 및 구독 아이콘등 조그만한 아이콘들은 Request를 줄이기 위해 변환했습니다.



이런식으로 말이죠. 대부분 1kB 이하의 이미지 파일들을 인코딩했습니다!


저게 조그만 파일이 커도 겉잡을수 코드 길이가 늘어납니다!! 20KB가 한글 문서 약 12장

배경 이미지 사이즈가 약 100KB니깐 HTML 소스 코드의 길이가 60장이 넘어가겠죠;;;;;;;;;;;;


페이지 테스트를 해보았습니다.



애드센스 때문에 + - 2~3 정도 차이는 있지만


기존에 평균 requests 가 78 정도 였는데

거의 10개가 낮아졌습니다. 68입니다!

request가 줄면 확실히 페이지 로드하는데 속도가 빨라지겠죠??



암튼.. 2차도메인(http://cocosoft.kr)을 사용하기 때문에 아이디.tistory.com 사용하시는 분들보다

서버 응답시간이 짧게는 3초에서 5초~6초 까지 발생 할 수 밖에 없습니다. ㅠ

(1차 도메인을 사용하시는 분들보다 3초 느리게 페이지가 열립니다.)


블로그 2차 도메인의 단점이기도 하죠.

그렇기 때문에 ㅠ 최대한 페이지 로드를 줄이기 위해서 노력하다 보니 여기까지 오게 되었네요.


더이상 줄이는 것은 한계인 것 같고!! 암튼 이런 방법도 있구나 하고 알면 좋을 것 같네요!!!

위에 인코딩 사이트를 이용해서 웹폰트 까지는 아니더라도

조그만한 아이콘등은 교체 해보시는 것도 좋습니다^^