data URL vs Image file :: 마이구미

이 글은 data URL 과 Image file 을 비교하는 글이 된다.

data URL에 집중했다는 점을 참고바란다.

이전에 작성된 메모리 캐시와 디스크 캐시에 대한 글을 보고 오면 좋다.

메모리 캐시 vs 디스크 캐시 - http://mygumi.tistory.com/275

* 2018.05.01 수정

이미지를 화면에 표시하는 방법에는 크게 2가지가 있다.

data url 형태와 일반적인 image file 이다.

// data url
<img src="data:image/png;base64, ....."/>

// image file
<img src="./1.png">

data URL 방식의 가장 장점은 다음과 같다.

• 스프라이트 이미지처럼 HTTP 요청을 절약할 수 있다.
• HTML 파일로 관리할 수 있다.

알려진 단점은 다음과 같다.

• 캐시되지 않아 매번 불러와야한다.
• 기존 파일보다 용량이 30% 커진다.
• 일부 브라우저에서 제한 및 지원되지 않는다.

본인은 단점 중 2가지에 의문을 가진다.

캐시되지 않는다는 것과 용량이 30%씩이나 커진다는 것이다.

먼저 캐시되지 않는다는 점의 의문은 다음과 같다.

data URL 의 경우 대부분 메모리 캐시로부터 가져오는 것을 볼 수 있다.

그렇다면 캐시가 되지 않는다는 말은 무엇인가?

본인의 생각으로 이것은 디스크 캐시를 기준으로 의미하는 것 같다.

위에서 명시한 이전 글을 읽어보면 무슨 의미인지 알 것이다. 그래도 혹시나.. 관련 내용의 그림은 다음과 같다. (이전 글을 참고하자)

하지만 본인은 디스크 캐시가 되지 않아도 크게 상관없다고 생각하여 다음과 같이 테스트를 실행했다.

(물론 메모리 캐시는 용량이 작다는 점이 있지만, 여기서는 고려하지 않는다고 가정한다.)

dataURL, image 파일 2가지 방식을 각각 탭 또는 윈도우 창 단위로 실행한다.

image 파일의 경우 탭 또는 윈도우 창 관계없이 캐시된 이미지 파일을 사용하는 것을 확인할 수 있다.

첫번째 개발자 도구는 첫 로딩으로 인해 이미지 파일을 가져오는 모습이다.

두번째는 탭 형식으로 브라우저 창을 만들었고, 그 결과 캐시된 이미지를 가져오는 모습을 볼 수 있다.

세번째는 새로운 윈도우 창을 통해 브라우저 창을 만들었고, 그 결과 캐시된 이미지를 가져오는 모습을 볼 수 있다.

결론적으로 새로운 탭 또는 윈도우에 상관없이 캐시된 이미지를 불러온다.

dataURL 의 경우에는 하나의 탭에서 첫 로딩 후 새로고침 결과 로딩속도가 줄어든 것을 볼 수 있다.

하지만  새로운 탭 또는 윈도우에서는 첫 로딩과 같은 로딩속도를 가지는 것을 볼 수 있다.

즉, dataURL 은 일반적인 메모리처럼 휘발성을 보이고, 같은 메모리 영역에 한하여 캐시하는 것으로 볼 수 있다.

결론적으로 여기서 "dataURL 은 캐시되지 않는다" 의 캐시의 기준은 image 파일과 같은 형태에 가까운 것으로 보인다.

단순히 캐시되지 않는다라는 말은 전체적으로는 납득하기 어렵다고 생각한다.

위와 같은 상황의 설명이 필요하다고본다.

이번에는 용량이 커진다는 점을 확인해보자.

기존 파일에 비해 30% 또는 1/3 커진다는 말과, 더 나아가 압축률 또한 낮아진다고 언급된다.

하지만 다음 그림처럼 Image file 과 data URL 은 base64 인코딩 여부의 차이이다.

최종적으로 화면에 표시하기 위해 RGB 형태로 디코딩 작업을 하게 된다.

용량이 30% 또는 1/3 씩이나 커지는 것은 과장된 표현이다.

오래된 글이지만, 아직까지 좋은 평을 받고 있는 글을 참고하면 그것은 잘못된 사실이라는 것을 알 수 있다. ( 참고 링크)

하지만 위와 같이 base64 인코딩의 추가적인 작업으로 인해 용량이 아닌 메모리 및 처리시간 등으로 인한 성능 저하는 단점이라고 볼 수 있다. 

결국 모든 기술은 서로 비교할 수 없듯이, 정확히 이해하고 상황과 목적에 따라 판단하면 된다.

쓰지 말아야할 기술은 없다.