왜 이미지 최적화를 해야 할까?
일반적인 페이지에서 대부분의 자바스크립트 파일을 제외하고 바이트는 이미지가 차지한다고 해도 과언이 아니다. 사실 이미지 최적화를 하지 않았다면, 자바스크립트를 전부 합쳐도 이미지가 합도적으로 큰 용량을 차지할 것이다. 우리가 개발자 도구를 이용해서 보이는 이미지 크기는 이미 최적화된 크기임을 감안하자.
그래서 이미지를 최적화해야 한다. 그래야 바이트를 최대한 절약할 수 있고, 사이트의 성능 또한 향상할 수 있다. 또한 브라우저가 다운로드해야 하는 바이트가 줄어들고, 클라이언트의 대역폭에도 여유가 생기며, 콘텐츠를 더 빨리 다운로드하여 화면에 렌더링 할 수 있다.
서버의 저장 공간이 적게 필요하게 된다. 이는 비용 절감으로도 연결될 수 있는 부분이다.
반대로 이미지가 크다면, 웹 페이지를 느리게 하여 최적의 사용자 경험을 제공해 줄 수 없다. 실제 사이트 방문자의 약 40%는 3초 안에 웹페이지가 로딩되지 않는다면 방문자는 떠난다고 한다. 웹 페이지의 로딩 속도는 웹 페이지의 크기가 직접 영향을 미친다고 하니, 페이지 크기 중에 큰 영향이 있는 이미지 최적화에 가볍게 볼 수 없는 것이다. 참고로 모바일 장치에서도 페이지 로딩 시간이 중요하다. 구글의 SEO 순위를 결정할 때 모바일 응답성을 고려하기 때문이다.(얼마나 이것이 SEO에 영향을 미치는지는 알 수 없다. 하지만 이미 많은 검증 사이트에서 몇 백만 개의 도메인을 분석해서 얻을 결론이니, 더 빠른 사이트가 Google에서는 더 도움이 된다는 것은 확신할 수 있다.)
웹 호스팅 비용 또한 문제가 된다. 웹 호스팅 시 페이지의 크기가 커서 대역폭을 많이 사용한다면, 호스팅 비용 또한 증가할 수밖에 없다.
어떻게 해야 하는가?
뭐 당연한 말이겠지만, 웹에서의 다양한 요소들의 균형을 유지하는 것이 중요하다. 이미지가 텍스트만으로는 불가능한 정보를 전달하는데 도움이 된다고 많이 사용한다면 페이지의 로드 속도는 상당히 느려진다. 그래서 우리는 이미지를 500KB의 권장 크기로 압축하거나 크기를 조정하는 것이 좋다. 압축에 대해서는 이미 수많은 알고리즘과 기술들이 나와있으며, 자바스크립트의 경우 Jimp나 Sharp 라이브러리를 사용해서 이미지를 다루는 경우가 많다. 특히 Jimp는 타입 스크립트를 공식적으로 지원해 주기 때문에 사용하기가 무척 편리하다.
아무튼 라이브러리 얘기는 나중으로 미루고 조금 더 원론적인 이야기를 해보도록 하자. 이미지 크기를 줄이는 방법에 대해서 말이다.
* 구글에서 말하는 세 가지
1. 불필요한 이미지 리소스를 제거한다.
2. 최대한 CSS3를 활용한다.
3. 이미지에서 인코딩 텍스트 대신 웹 글꼴을 사용한다.
1. 불필요한 이미지 리소스를 제거
가장 간단한 방법은 이미지 리소스를 줄이는 일이다. 불필요한 이미지 리소스를 제거하는 것은 항상 최고의 최적화 전략이다. 적절한 곳에만 이미지를 배치하는 것이 더 좋은 효과를 낼 수도 있는 일이다.
2. CSS 활용 - Image Sprites
이미지 스프라이트(Image Sprites)란, 여러 개의 이미지를 독립적으로 사용하지 않고 단일 이미지로 결합한 다음 CSS를 적용해서 필요에 따라 개별 이미지로 사용(표시)하는 것이다. 예제를 보면서 익히는 게 더 편하다.
예제 - https://www.w3schools.com/css/tryit.asp?filename=trycss_sprites_img
예제를 보면 두 개의 이미지를 별도로 사용하는 대신 단일 이미지("img_navsprites.gif")로 사용한다. 이런 방식을 이용하면, 서버 요청 수가 줄어들고(하나의 이미지만 요청하기 때문) 대역폭도 절약된다.
이미지 스프라이트뿐만 아니라, CSS3 효과를 가능한 많이 사용하는 것은 이미지 최적화에 큰 도움이 된다. 예를 들어 공백을 자르고 css를 사용해서 여백을 제공하여 다시 공백을 다시 작성하는 방법이다.
3. 이미지에서 인코딩 텍스트 대신 웹 글꼴 사용
웹 글꼴(Web Fonts)이란 개인 컴퓨터에 설치되어 있지 않고 웹 서버에서 로드해야 하는 글꼴을 말한다. 이미지 내에서 인코딩 텍스트를 찾는다면 그 이유에 대해서 다시 한번 생각해 보자. 굳이 이미지 용량을 늘리면서 그걸 사용해야 하는 이유가 없다. 왜냐하면 형편없는 사용자 환경을 제공하기 때문이다. 텍스트를 선택, 검색, 확대, 축소도 할 수 없으며 액세스 할 수도 없고 DPI가 높은 기기에는 익숙하지도 않다.
반면 웹 글꼴은 이미지 최적화를 떠나서 일관된 브랜딩을 달성할 수 있으며, 더 나은 사용자 경험을 제공해 준다. 확장 가능하며, 확대, 축소가 가능하고 DPI에 친숙하다. 즉 해상도에 상관없이 데스크톱, 태블릿 및 휴대폰에서 쉽게 표시할 수 있는 것이다.
Vector vs Raster Images
갑자기 백터(Vector)와 래스터 이미지(Raster Images, 비트맵 이미지라고도 한다.)가 나와서 당황할 수도 있겠지만, 이미지 최적화에서는 이미지가 실제로 원하는 효과를 실현하는데 적절한 형식을 선택하는 것도 중요하다. 백터와 래스터는 이미지 파일에 있는 두 가지 주요 유형이다.
백터 이미지는 한 점에서 다른 점으로 선과 도형을 형성하는 수학적 계산이다. 백터 그래픽을 확대하면 수학 공식은 동일하게 유지되어 크기에 상관없이 동일한 시각적 그래픽을 렌더링 한다. 그래서 백터 그래픽은 품질 저항 없이 모든 크기로 확장할 수 있는 것이다.
반면 레스터 이미지는 사각형 그리드(rectangular grid) 내에서 각 픽셀 개별 값을 인코딩함으로써 이미지를 나타낸다. 따라서 그 이미지에는 특정 개수의 픽셀이 존재하며, 픽셀 수를 변경하지 않고 이미지 파일을 확대하면 이미지는 흐리게 보인다. 그렇다고 픽셀을 추가하더라도 파일을 확대하면 이미지 전체에 픽셀이 무작위로 추가되므로 좋은 결과를 얻지 못한다.
1. 백터 이미지는 기하학적 모양으로 구성된 이미지에 적합하다.
2. 백터 이미지는 확대/축소되고 해상도에 독립적이다. 래스터 이미지는 이를 지원하지 않는다.
3. 래스터 이미지는 불규칙적인 모양과 세부 사항이 많은 복잡한 장면에 사용해야 한다.
고해상도 화면의 영향
먼저 픽셀에 대해서 알아야 한다. 픽셀(Pixels)은 CSS pixels과 physical pixels 두 가지로 나눌 수 있다. CSS pixels에는 여러 Physical pixels이 포함될 수 있으며, Physical pixels이 많을수록 화면에 표시되는 내용이 더 세밀하다.
위 그림을 보면 Low Density일 때는 10 physical pixels, Medium Density일때는 20 physical pixels, High Density일때는 40 physical pixels로 표현할 수 있다.
여기서 우리는 레스터 이미지의 문제를 알 수 있다. 픽셀 단위로 이미지 데이터를 인코딩하기 때문에 이미지 파일의 크기가 커지고 있기 때문이다.
| 화면 해상도 | 총 픽셀 수 | 압축되지 않는 파일 크기(픽셀당 4바이트) |
| 1x | 100 x 100 = 10,000 | 40,000 바이트 |
| 2x | 100 x 100 x 4 = 40,000 | 160,000 바이트 |
| 3x | 100 x 100 x 9 = 90,000 | 360,000 바이트 |
해상도를 늘리면 가로의 픽셀 수와 세로의 픽셀 수가 늘어나므로(2*2, 3*3), 화면은 단순하게 해상도만큼 픽셀 수를 늘리지 않고 그 이상으로 늘리고 있다.
여기서 우리는 고해상도 이미지에 대해서 한 번 더 생각해 봐야 한다. 고해상도 화면은 분명 아름다운 이미지를 제공할 수 있다. 그래서 필요하다면 가급적 해상도에 독립적이고 선명한 결과를 제공하는 백터 이미지를 사용하는 것이 좋다. 레스터 이미지가 필요한 경우에는 jpg라면 jpegtran 또는 jpegoptim, png라면 OptiPng, Pngout 등을 이용하여 최적화하면 된다.
백터 이미지 최적화
- SVG는 XML 기반 이미지 형식이다.
- SVG 파일은 축소하여 크기를 줄여야 한다.
- SVG 파일은 GZIP으로 압축해야 한다.
모든 최신 브라우저는 SVG(Scalable Vector Graphics)를 지원한다. 이는 2차원 그래픽을 위한 XML 기반 이미지 형식이다. 아래 예가 있다.
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 17.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
<svg version="1.2" baseProfile="tiny" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
x="0px" y="0px" viewBox="0 0 612 792" xml:space="preserve">
<g id="XMLID_1_">
<g>
<circle fill="red" stroke="black" stroke-width="2" stroke-miterlimit="10" cx="50" cy="50" r="40"/>
</g>
</g>
</svg>브라우저에 자산을 렌더링 하는 데 흔히 불필요한 레이어 정보, 주석 및 XML 네임스페이스 같은 많은 양의 메타데이터가 들어 있기 때문에 항상 svgo와 같은 도구를 실행하여 파일을 최소화하는 것이 좋다. 또한 SVG가 XML 기반 형식이므로 GZIP 압축을 적용하여 전송 크기를 줄일 수도 있다.
래스터 이미지 최적화
래스터 이미지는 단순하게 개별 '픽셀'로 구성된 2차원 그리드이다. 예를 들어, 100x100픽셀 이미지는 10,000픽셀로 구성된 시퀀스이다. 각 픽셀은 'RGBA' 값을 저장한다. 즉, (R)은 빨간색 채널이고, (G)는 녹색 채널이고, (B)는 파란색 채널이며 (A)는 알파(투명도) 채널이다.
내부적으로 브라우저는 각 채널에 대해 256개 값(음영)을 할당하며, 이러한 값은 채널당 8비트(2 ^ 8 = 256), 픽셀당 4바이트(4개 채널 x 8비트 = 32비트 = 4바이트)로 변환된다. 따라서 그리드의 크기를 알면 파일 크기를 쉽게 계산할 수 있다.
- 100 x 100px 이미지는 10,000픽셀로 구성
- 10,000픽셀 x 4바이트 = 40,000바이트
- 40,000바이트 / 1024 = 39KB
-------------------------------------------------
...
- 500 x 500px 이미지는 977KB
- 800 x 800px 이미지는 2500KB
cf) 서버에서 클라이언트로 데이터를 전송하는 데 사용되는 이미지는 이미지 형식에 관계없이, 브라우저에서 이미지를 디코딩할 때 각 픽셀은 항상 메모리에서 4 Bytes를 차지한다.
이미지 크기가 클수록 파일 크기 또한 폭발적으로 커지고 있다. 당연히 이런 이미지를 다운로드하는 비용 또한 많이 들 수밖에 없다. 다행히도(?) 지금까지 설명한 것은 '압축되지 않은' 이미지 형식이다. 이미지 파일 크기를 줄여보자.
가장 간단한 전략은 이미지의 '비트 깊이(bit-depth)'를 줄이는 것이다. 현재 채널당 8비트이지만, 저 작은 색상 팔레트(palette)로 줄여서, 기존에 8비트-채널당 256개의 값을 제공-총 16,777,216(256^3) 색을 제공했다면, 팔레트를 예를 들어 256색으로 줄이는 것이다. 그러면 RGB 채널에 총 8비트만 필요하게 되므로 픽셀당 2바이트를 절감할 수 있다.
3개의 채널(RGB, 8비트, 2^8) + 1개의 채널(A, 8비트, 2^8) = 16비트 =2바이트
원래 픽셀당 4바이트 형식에 비해 압축을 통해 50%의 절감 효과를 얻은 것이다.
두번째 전략은 '델타 인코딩(Delta Encoding)'을 적용하는 것이다. 델타 인코딩이란, 델타 압축이라고도 불리며 전체 파일이 아닌 순차적 데이터 간의 차이(=Delta, =Diffs) 형태로 데이터를 저장하거나 전송하는 방법이다. 차이가 작은 경우 데이터의 중복성을 크게 줄여주는 효과가 있다.
* 델타 인코딩
일반적인 예 - 2, 4, 6, 9, 7 => 델타 인코딩 적용 시 => 2, 2, 2, 3, -2를 저장
=> 분산(범위)를 감소시켜 동일한 데이터에 대한 비트 사용을 낮춰준다.
우리가 사용하는 특히 사진과 같은 이미지는 유사한 많은 인근 픽셀을 가진다(ex 하늘 사진). 압축 프로그램이 각 픽셀에 대한 개별 값을 저장하는 대신 델타 인코딩을 사용하여 인근 픽셀 간의 차이를 저장하는 것이다. 이 경우 인근 픽셀이 동일하다면 델타가 '0'이고, 단일 비트로 저장하게 된다.
이외에도 이미지 압축과 관련된 기술과 알고리즘은 많이 있고 현재에도 논의되고 있는 주제이니, 관심이 있다면 나중에 더 찾아보도록 하자.
무손실 이미지 압축과 손실 이미지 압축
이미지 최적화는 손실이 있는 압축과 무손실 압축으로 구성된 기능이다. 말만 봐서는 당연히 무손실 압축이 좋을 거 같지만, 인간의 눈의 특성상 손실이 있는 압축 또한 좋은 방법이 될 수 있다. 그래서 종종 이미지 파일 크기를 줄이기 위해 각 필셀에 대한 일부 정보를 삭제할 수 있는 것이다. 또한 손실 이미지 압축을 무손실 이미지 압축보다 많이 사용하는 이유는 손실 압축을 사용했을 경우, 무손실 압축보다 데이터 감소량이 훨씬 높기 때문이다.
이미지 최적화 파이프라인은 아래와 같다.
1. 이미지가 일부 픽셀 데이터를 제거하는 '손실이 있는' 필터로 처리
2. 이미지가 필셀 데이터를 압축하는 '무손실' 필터로 처리
1번 항복은 선택 항목이며 정확한 알고리즘은 특정 이미지 형식에 따라 결정되지만, 모든 이미지가 크기를 줄이기 위해 손실이 있는 압축 단계를 거칠 수 있음을 이해하는 것이 중요하다.
그렇다면 손실 최적화와 무손실 최적화에 대한 '최적'이 있을까? 정답부터 말씀드리면 없다. 손실이 있는 압축으로 인해 발생하는 아티팩트 및 파일 크기와 콘텐츠 사이의 균형점은 개발자만의 기준에 따라 달라진다. 복잡한 세부 사항을 완벽하게 전달하기 위해 손실이 있는 최적화를 건너뛸 수 있으며, 이미지 크기를 줄이기 위해 공격적인 손실이 있는 최적화를 사용할 수 있는 것이다. 스스로 판단하고 상황을 고려해야 하는 것이다. 다만, 이미지 품질을 낮추는 것을 두려워하지 말자. 시각적인 결과는 대개 매우 좋으며 파일 크기도 많이 절감할 수 있다.
참고로 손실 압축은 멀티미디어 데이터(오디오, 비디오, 이미지)를 압축하는데 일반적으로 사용되며, 반대로 은행 기록, 텍스트 상품 및 데이터 파일에는 일반적으로 무손실 압축이 필요하다.
올바른 이미지 형식 선택
구글에서 말하는 이미지 최적화 체크리스트
- 벡터 형식 선호: 벡터 이미지는 해상도 및 배율에 독립적이므로, 여러 기기 및 고해상도 환경에 가장 적합합니다.
- SVG 자산 최소화 및 압축: 대부분의 그리기 애플리케이션에서 생성하는 XML 마크업에는 불필요한 메타데이터가 들어 있는 경우가 많습니다. 이러한 메타데이터는 삭제할 수 있습니다. 서버가 SVG 자산에 대해 GZIP 압축을 적용하도록 구성되었는지 확인하세요.
- 최적의 래스터 이미지 형식 선택: 기능적인 요구사항을 확인하고 각각의 특정 자산에 맞는 형식을 선택합니다.
- 래스터 형식에 최적화된 품질 설정 실험: '품질' 설정을 낮추는 것을 두려워하지 마세요. 결과가 매우 좋은 경우가 많으며 바이트 절감 효과는 상당합니다.
- 불필요한 이미지 메타데이터 삭제: 많은 래스터 이미지에는 위치정보, 카메라 정보 등 자산과 관련하여 불필요한 메타데이터가 들어 있습니다. 적합한 도구를 사용하여 이러한 데이터를 삭제하세요.
- 배율이 조정된 이미지 제공: 서버의 이미지 크기를 조정하고 '표시' 크기를 이미지의 '실제' 크기와 최대한 가깝게 하세요. 특히 대규모 자산의 경우 크기 조절을 하면 높은 오버헤드를 초래하므로 주의해야 합니다.
- 자동화, 자동화, 자동화: 자동화된 도구 및 인프라에 투자하여 모든 이미지 자산이 항상 최적화되도록 하세요.
참고 자료
Page Weight: https://httparchive.org/reports/page-weight
Image Sprites: https://www.w3schools.com/css/css_image_sprites.asp
DCT(손실 압축 알고리즘): https://en.wikipedia.org/wiki/Discrete_cosine_transform
'도구, 기술, 이론 > 이론' 카테고리의 다른 글
| 모놀리식 아키텍처와 마이크로 서비스 아키텍처의 장점과 단점 (0) | 2020.08.17 |
|---|---|
| [클린 아키텍처] 업무 규칙 (0) | 2020.02.14 |
| [클린 아키텍처] 컴포넌트 응집도와 세 가지 원칙 (0) | 2020.02.13 |
| 트렁크 기반 개발(Trunk-Based Development) (0) | 2020.02.11 |
| 소프트웨어 설계 원칙 - SOLID (0) | 2020.01.25 |