Image Compression for Web Developers

HTML5 Rocks

개요

이미지가 웹 페이지의 가장 큰 부분을 차지하게 되면서 빠르게 로딩되고 응답하는 사이트를 위해 이미지 크기와 품질을 적극적으로 컨트롤하는 것이 웹 개발자에게 매우 중요해졌습니다. 이것은 공짜로 되는게 아닙니다. 대부분의 경우 '충분히 좋도록' 자동화할 수 있지만 최고의 결과를 위해서는 사람이 눈으로 품질의 수준을 확인하여야 합니다. 이 글은 사이트의 이미지 압축에 대한 이슈들을 이해하고 이를 잘 다루기 위한 기법들과 방식, 이유들을 제공할 것입니다.

나는 쉬어야겠어.

요약 : 이미지 압축의 체크리스트

  1. 이미지를 괜찮게 보이는 가장 낮은 품질, 올바른 포맷으로 압축하라.
    1. 모든 이미지에 대해 압축 품질을 가능한만큼 직접 튜닝하라.
    2. 나머지는 가장 높은 성능을 얻기 위해 최적화를 자동화하라.
  2. 요구되는 모든 이미지에 대해 WebP의 사용을 확인하라.
  3. 페이지의 로딩타임에 대한 사용자 인식을 개선하기 위해 Progressive 옵션으로 이미지를 저장하자
  4. 더 나은 압축이나 투명 처리를 위해 다른 흥미로운 방법들을 조사하자. 사고의 틀을 벗어나자!

왜 작은 것이 좋은가

쉽게 말해 더 큰 페이지는 더 많은 로딩 시간이 소요됩니다. 연구된 바에 따르면 느린 사이트의 사용자는 사이트에 더 짧게 머물고 더 클릭을 덜하게 되며 광고를 덜 클릭하고 소비하는 모습을 보였습니다. AutoAnything 같은 작은 사이트는 로딩 시간을 반으로 줄여 13%의 매출 신장을 이뤘습니다. 그리고 아마존 같은 거대 사이트는 100 밀리초가 느려질 때마다, 1%의 매출 하락을 경험하였습니다. 그리고 즉시 로딩되도록 만든 웹사이트들로 완전한 자금 조달의 성공에 기반한 2012년 대선 활동은 잊혀지지 않습니다.

사용자가 웹사이트를 다운로드하는데 비용을 지불하는 것이 무엇이 나쁜가.

데스크톱 사용자들을 위해 페이지들이 커지면서 실행 성능을 떨어뜨리는 동안 팽창된 페이지들의 가장 큰 피해자는 역시 모바일 사용자입니다. 1MB 페이지는 단지 아주 오랫동안 로딩뿐만이 아니라 끔찍한 휴대폰 청구서의 충격도 줄 것입니다.

모바일을 위한 대부분의 '무제한' 데이터 제도조차도 진정한 '무제한 무료'는 아닙니다. 그것들 대부분은 2GB 정도를 충전하는 정액제고 이를 넘어서면 더 많은 비용을 사용합니다. 아래 AT-T 연구 결과가 강조한 것과 같이 "무제한"과 같은 형태의 요금제가 없는 세계의 여러 곳에서 다운로드 비용 정보가 사용자에게 심각한 영향을 미치는 것에 대해서는 말할 필요도 없을 것입니다.

모바일 데이터 트래픽 비용 문제는 오늘날 모바일 장비 상의 서비스에 심각한 방해 요소입니다.

흥미로운 것은 통신사가 결제 정보를 제공하지 않을 때에도 사용자는 결제 방식을 이해하려고 노력한다는 점입니다. 연결 표시등, 청구서 상의 표시 정보 및 데이터 트래픽 결제에 대한 이전의 경험에 기반하여 사람들은 그들의 모바일 브라우징 사용 패턴에 영향을 미치는 인식 가능한 결제 모델을 구축합니다.

mobiforge은 비용면에서 전체 인수를 넣어 더 많은 컨텍스트를 제공했습니다.

AT-T는 특정 국가에서 로밍 데이터를 사용할 떄 1MB당 $19.97씩 과금합니다. Guy의 스프레드쉬트에서 몇 가지 예시를 뽑고 AT-T 로밍 요금을 적용해본 결과처럼 1pictureaday.com가 정말로 $178의 가치가 있다고 생각합니까? 당신이 $44를 내고 thenextweb.com 혹은 $65에 vogue.co.uk를 정말로 방문해야 할까요? 차라리 microsoft.com에 접속하는데 드는 $17은 상대적으로 저렴합니다.

이와 같이 무거운 페이지는 로밍 사용자에게 더 중요한 일들을 위해 금지되어야 합니다.

큰 이미지가 가장 큰 문제입니다.

우리는 그림 한장이 말 그대로 수천 단어의 비용을 소요하여 모바일에 악영향을 미치는 용량이 이미지들로부터 가장 크게 증가하는 것을 확인할 수 있습니다.
일반적으로 성능에 문제를 만들어낸 장본인은 적합하지 않은 이미지 포맷입니다. 이미지들이 너무 커지거나 충분히 압축되지 않거나 너무 높게 품질을 설정하는 방법들이 모두 사이트 로딩에 바로 영향을 줄 정도로 이 이미지들을 부풀려지고 너무 커지도록 만들어 버립니다. 옳은 압축 방법을 취하는 것은 안보이는 영역도 어떻게 돌아가는지 알 수 있도록 하여 가장 좋을 결과에 도달할 수 있도록 만들어 냅니다.

압축 알고리즘의 유형

대개 이미지 압축은 손실과 무손실 단계의 2개 스테이지로 이루어집니다. 손실 압축 알고리즘은 역-압축으로도 복구되지 않는, 정보가 손실된 것처럼 입력 스트림을 수정할 것입니다. 대다수의 이미지 손실 압축 알고리즘들이 처리 과정에서 우리가 실제로는 볼 수 없는 몇몇 정보를 제거해서 바이트수를 줄이는 장점을 취하고 있습니다. 예를 들어 이미지 색상의 제한이 있습니다. (적은 색상은 작은 데이터를 의미합니다.) 일반적으로 여러분이 손실 압축을 지원하는 포맷으로 이미지를 저장할 때 "품질 수준"이 이미지에서 무엇인지 물어볼 수도 있습니다. 실질적으로 이미지 품질과 파일 크기를 보상교환하는 스칼라 값을 무엇으로 할 지 선택할 수 있습니다. 품질 수준이 충분이 높으면서 파일 사이즈가 가능한 작은 것 처럼 이미지를 위한 중요한 부분이 있다는 것은 깨닫는 것이 바로 웹 개발자가 가져야 할 요령입니다.

0.123, 1.2345, 21.2165, 21.999, 12.123
0,0,20,20,10
Figure 1 - 손실 압축의 예. 가장 작은 10 단위의 값으로 양자화되었습니다. 이에 대한 역변환은 할 수 없습니다.

무손실 변형은 데이터가 일단 압축이 풀어진 정확한 상태로 복원되어 적용됩니다. 일반적인 압축 알고리즘은 원본 스트림이 정밀성이나 정보의 손실없이 즉시 복구되도록 합니다. 이미지에서 가장 인기 있는 무손실 코덱은 LZ77, RLE산술 인코딩을 포함합니다. 무손실 압축 알고리즘은 항상 데이터 크기를 줄이기 위한 정보 이론과 발버둥치며 보통 컨텐츠로부터 데이터의 마지막 몇 퍼센트를 뜯어내는 압축의 근간입니다.

aaaaabbbbbcccddddeeeeffffaaaaabb
a5b4c2d4e4f4a5bb0
Figure 2 - 무손실 압축의 예. run length에 따른 기호로 값의 연속으로 인코딩되었다. 본래의 스트림으로 복구할 수 있습니다. 만약 run의 길이가 <= 2개의 문자라면 심볼은 단독으로 남겨진 것임을 이해하여야 합니다. 스트림의 마지막은 'bb'로 끝나는 것을 확인할 수 있습니다.

이미지 포맷들

이미지 포맷은 전통적으로 다양한 손실 + 무손실 알고리즘의 연결로 압축효율을 높여왔습니다. 웹 브라우저에 적합한 포맷은 여러가지가 있고 각기 다른 기능과 성능의 균형을 가지고 있습니다. 명확하게 얘기하면 (현재) 웹에서 "모든 것을 위한 하나의" 포맷은 존재하지 않습니다. 이미지의 다른 형식들은 이미지가 어떠한 타입인지, 브라우저가 지원하는 것은 어떤 것인지 페이지가 필요한 것은 어떤 것인지에 따라 다른 포맷으로 인코딩되어야 합니다.

전통적으로는 웹 개발자를 위한 이미지 포맷을 선택하기 위한 3가지 결정 사항이 존재합니다.

  • 투명도가 필요한가?
  • 애니메이션이 필요한가?
  • 고품질의 데이터가 필요한가?

'레나(Lena)'는 이미지 압축 알고리즘 비교와 평가에 사용되는 기본 이미지입니다.

PNG는 투명도와 무손실 압축을 지원하는 간단한 포맷입니다. 여러분은 이미지에 알파 채널을 지정할 수 있고, 투명한 영역을 표시할 수 있으며 무손실을 가능하게 하는 Deflate 압축 옵션을 데이터에 사용할지를 정의할 수 있습니다. (Deflate는 LZ77Huffman), 2가지 무손실 압축의 조합으로 이루어져 있습니다.) 무손실 압축이기 때문에 이미지의 품질은 소스 이미지와 동일하지만 이때문에 이미지가 작아질 수록 파일 사이즈는 커지게 되는 문제가 있습니다.

GIF는 투명도와 alongside 애니메이션을 지원하는 또 다른 포맷입니다. ( ‘인터넷의 고양이’ 같은 것...을 위한 직접적 근거) GIF 포맷은 손실이 일어나는 팔레트화 단계 (이미지 전체를 단 256개의 색상으로 제한)를 지나 LZW 압축기를 통하는 2가지 압축 스테이지를 포함하고 있습니다. 최종적으로 LZW로부터 높은 압축률을 뽑아내기 위한 양자화 과정은 더 높은 압축률을 위해 이미지 색상을 단 256개로 줄이는 공격적인 품질 저하를 만들어냅니다.

Colt McAnlis says:
최근, 최첨단 압축기술들은 여러개의 코딩 단계를 통해 크나큰 승리를 거두었습니다. 단일 스테이지는 이어지는 스테이지가 단독의 데이터 스트림 원본보다 더 낫게 압축할 수 있도록 데이터 스트림을 수정할 수 있습니다. 7zip Chain과 함께 LZ dictionary encoding 같은 유명한 인코더들은 Markov Chain 알고리즘에 의해 효율적으로 사용되는 감소된 심볼 세트를 생성합니다.

또한 예를 들어 여러분은 데이터를 압축하기 위해 GPU 형식으로 된 기존의 최상위 무손실 압축 알고리즘의 손실 포맷까지도 적용할 수도 있습니다. 가장 큰 승리는 올바른 방법의 알고리즘 결합으로부터 온 것입니다.

만약 당신이 투명도나 애니메이션이 필요하지 않다면 JPG는 최고의 포맷입니다. JPG는 고품질의 사진 데이터를 압축을 보편적으로 다루기 위해 디자인되었습니다만 어플리케이션에서 필요로하는 압축 품질 대 이미지 사이즈의 균형을 조절할 수 있도록 하는 손실 압축 옵션의 집합을 제공합니다.

만약 여러분이 '하나로 전부를' 처리할 수 있는 이미지 포맷을 찾고 있다면 WebP가 여러분의 레이더에 포착될 것입니다. 이 포맷은 우수한 압축 품질/크기뿐만 아니라 투명도와 애니메이션도 자랑할만 합니다. 이것은 손실과 무손실 압축을 둘 다 조합하고 있고 JPG와 유사하게 품질 수준 대 파일 사이즈를 정의하는 것을 가능하게 합니다. 물론 이 새로운 이미지 포맷은 아직 모든 브라우저에 적용되어 있지는 않으므로, 현재 사용성 이슈때문에 이를 적용하고자 하는 웹 개발자들은 초기 작업 단계에 머물러 있습니다. JPG에 비해 30% 작고 비례하여 증가하는 서버측 적용은 어떤 사이트라도 이미지 크기 문제들을 처리할 수 있는 지배적인 포맷임을 증명합니다.

압축률 무손실 손실 투명도 애니메이션
PNG Good Yes No Full No
GIF OK Yes Yes Binary Yes
JPG Good Yes Yes No No
WebP Great Yes Yes Full Yes
Figure 3 - 브라우저의 지원 포맷별 기능

품질과 사이즈의 상호교환

품질이 조절 가능한 이미지 형식은 직접 품질을 설정하여 최소의 파일 크기를 얻는 것이 가장 좋은 방법입니다. 구글 웹마스터가 이미지에 대한 품질을 시험하는 몇가지 방법과 어떻게 적당한 인지 시험을 수행할 수 있는지에 대한 훌륭한 비디오를 보여줍니다.

또한 imgmin 프로젝트는 일반적으로 75에서 100 사이의 JPG 압축 품질을 사용자가 인지하는데는 작은 차이만 존재한다는 점을 지적하고 있습니다.

평균적인 JPEG는 100-75의 *명백한* 품질에서는 아주 작고 거의 표시나지 않은 차이점만이 존재하지만 각 단계가 내려감에 따라 명시적인 파일 크기의 차이를 보입니다. 이것은 많은 이미지가 일반적인 뷰어에서 75의 품질에서 괜찮게 보이지만 95의 품질보다 절반정도의 크기를 가진다는 것을 의미합니다. 75 이하로 품질이 떨어질수록 파일 크기의 감소와 시각적인 차이는 인지할 수 있을 만큼 커집니다.

다음에서 대부분의 커다란 웹사이트가 대부분의 그들의 JPG 이미지에 대해 품질을 75 근처에서 설정하는 것을 확인할 수 있습니다.

사이트 JPG 품질
구글 섬네일 이미지 74-76
페이스북 풀사이즈 이미지 85
야후 전면 JPEGs 69-91
유투브 전면 JPEGs 70-82
위키피디아 이미지 80
윈도우즈 라이브 배경화면 82
트위터 사용자 JPG 이미지 30-100
Figure 4 - 최상위 웹사이트들에서 사용되는 평균적인 JPG 품질 수준

여러분의 페이지 내에 있는 각 이미지 설정의 사용자 정의를 통해 최고 품질 수준에서 최고의 효율을 취할 수 있는 품질과 크기 간 상호교환의 균형을 잡을 수 있습니다. 이 거대한 사이트들은 이미지의 과잉 보유하는 경향이 있고 각 이미지에 대해 직접 최적화하는 방안을 가지고 있지 않으며 따라서 사용자 정의 및 이미지 단위의 품질 수준 조정은 거의 불가능합니다. 일부 개발자들은 보다 자동화된 접근을 통해 이 인코딩 형식을 취하고 종종 아티스트의 결과를 가지고 와서 그들 자신의 경험을 토대로 빌드 단계에서 이미지에 대한 인코딩 처리를 수행합니다. 이 설치 유형은 웹 개발자들의 대다수를 도울 수 있는 사용자화 및 자동화 사이의 좋은 중간 형태에 적합합니다. 또한 여러분은 가능한한 최고 품질의 JPG 압축 수준을 자동으로 설정하는 MiniJPG와 같은 앱들을 적용할 수도 있습니다.

개발자들이 이미지 용량를 줄이기 위해 사용하는 꽤나 과감한 접근은 SVG 파일로 단순화한 아이콘과 이미지를 통해 용량을 줄이고 그것들을 클라이언트에서 디스플레이하기 전에 래스터화할 수 있도록 하는 것입니다. 이 처리 형태는 클라이언트 성능과 파일 크기를 교환하여 전송 시의 비트량을 절감하지만 렌더링하는 동안 이미지를 재구성하기 위해 클라이언트측의 부하를 발생합니다. SVG 이미지와 같은 포맷은 파일 내에 정의된 형태 정보를 이용하여 출력 이미지의 특정 해상도로 최종 이미지가 절차적으로 생성된 다른 파일 형식과 꽤 차이가 있습니다. SVG 이미지가 로딩되면 그것은 디스플레이되기 전에 래스터 포맷(비트맵 같은 픽셀의 2차원 배열)으로 변환됩니다.

벡터 이미지의 비교.
Figure 5 - 래스터 이미지(좌측)을 벡터 이미지(우측)의 비교 예시. 벡터 이미지가 훨씬 단순하고 픽셀 단위의 상세함이 덜하다는 것에 주목하세요. 이것은 포맷 형식 자체가 높은 품질의 데이터 생성을 할 수 없기 때문입니다.

SVG가 여러분으로 하여금 원본 데이터의 크기에 상관없이 아주 작은 메모리 공간에 이미지의 '설명'을 저장할 수 있으며 해상도 독립적인 고품질의 이미지를 클라이언트에서 생성할 있는 파일 포맷이라 생각해봅시다. SVG 포맷의 제한 사항들 중 하나는 화면에 색상들을 어떻게 생성하는지에 대해 정의하기 위한 기본 형태의 집합만을 사용하여 확실한 이미지 품질의 형식을 표현할 수 있으며 이것이 벡터 이미지는 단순화를 의도한다고 말할 수 있다. 예를 들어 대초원의 풀밭은 너무 많고 복잡한 형태를 필요로 하여 압축을 통해 줄일 수 없을 것이다. 래스터 이미지는 사진이나 고밀도의 정보로 구성된 다른 이미지들을 위해 가장 훌륭하게 사용할 수 있다면 벡터 이미지들은 로고나 단순한 이미지 패턴들 같은 것에 좋습니다.

이미지 품질 및 사이즈와 다양한 화면 해상도.

개발자가 직면하고있는 큰 과제 중 하나는 만들어진 이미지의 크기에 대한 모니터 화소의 크기입니다. 데스크톱의 웹 사이트를 위한 이미지 콘텐츠를 만드는 경우 큰 데스크탑 해상도 모니터에 보이도록 이미지의 크기와 품질 수준을 맞출 수 있는 괜찮은 기회가 있습니다. 그러나 모바일 디바이스는 그들의 화면 크기가 훨씬 작고 연결은 더 비싸다는 문제가 있습니다. 따라서 사용자들은 그들이 보거나 필요한 크기보다 더 큰 이미지를 받을 수 있습니다.

이 이슈를 가늠할 수 있는 몇가지 방법이 있습니다.

한가지 해결 방법은 이미지를 오프라인에서 필요한 각 해상도에 맞춰 미리 연산하는 것입니다. 대부분의 정적 웹사이트들은 이것을 오프라인 빌드 단계에서 쉽게 생성할 수 있으며 아마도 Grunt와 같은 툴체인을 이용하여 이미지를 리사이징할 수 있습니다. 이러한 기법의 이점은 이미지들이 그들의 네이티브 장비 해상도에 따라 적합하게 캐시되며 로딩 시간이나 정보를 얻기 위해 클라이언트에 송신하는 비용이 없다는 점입니다. 그러나 부정적인 면은 데이터셋과 의도하는 사용자에게 정보를 보내는 추가적인 로직이 기하급수적으로 증가하는 것을 관리하는 것이 미칠 것 같다는 점입니다.

Addy Osmani says:
만약 Grunt를 이용하여 이 컨텐츠를 생성하는데 흥미가 있다면, 빌드의 일부로써 ImageMagick을 이용하여 미리 연산된 이미지 생성 자동화에 대한 grunt-responsive-images을 추천합니다.

Node나 Express와 밀접한 사람들을 위한 대체재로 express-processimage가 사용하거나 이미지를 생성하기 위한 ImageMagick을 호출하는 스크립트를 함께 넣을 수 있다.

그러나 이러한 접근 방식에서 아직 풀리지 않은 이슈 중의 하나는 여러분의 데이터셋의 증가를 관리하는 좋은 방법을 찾는 것입니다. 논리적으로 srcset가 이 문제를 해결해 줄것이라 기대합니다. (알다시피 WebKit은 이미 있고 블링크는 구현 중이며 파이어폭스는 iOS가 남았습니다.)

한편, srcset를 위한 polyfill을 사용하는 것도 간극을 줄이는 방법 중의 하나입니다.

또다른 접근 방법high-DPI의 모바일 장비들의 범람을 고려하여, 이미지의 품질, 이미지의 크기와 이미지 리사이즈를 위한 클라이언트 비용에 대한 게임을 포함하는 것입니다. 효과적으로는 여러분은 여러분의 이미지를 2배의 해상도(확대 처리)로 저장할 수 있지만 그것을 손실 포맷으로 출력하면 (높은 압축률을 보이는) 아주 낮은 품질 옵션을 선택해야 합니다. 여기서의 의도는 그러한 고해상도 이미지를 압축해서 압축된 저해상도 이미지보다 작은 크기로 만드는 품질 수준을 고르는 것입니다.

클라이언트에서 여러분은 (현재 이미지의 사이즈보다 더 작지만 확대되어 있는) 이미지의 목적 크기를 설정할 수 있습니다. 웹브라우저는 의도된 해상도로 이미지를 축소할 것이고 낮은 품질의 압축 데이터로부터 흐림 효과 처리를 통해 다양한 화면 해상도에 쉽게 맞출 수 있으며 품질의 저하를 명백하게 나타내지 않을 것입니다.

이미지 크기, 사용자 인지와 로딩 시간

결론을 보면 유일한 문제는 사이트가 사용자에 빨리 로드되며 나타나는 것입니다. 빨리 표시될수록 더 빠르다는 것이고 체감 성능은 실제 속도보다 중요합니다.

웹에서 이미지를 디스플레이하는데는 2가지 지배적인 방식이 있습니다.

  1. 전체 이미지가 다운로드를 대기하고 다운로드 완료 후 디스플레이.
  2. 이미지를 다운로드한만큼 디스플레이.

첫번째 옵션을 사용하는 브라우저는 없으며 단순하게 가능한한 느리게 페이지가 나타나도록 만들었기 때문입니다.

두번째 옵션은 대부분의 웹에서 이미 구축되어 있는 것입니다. 우리 모두가 이미지를 시간에 따라 위에서 아래로 '나타내는' 스타일은 꽤 익숙할 것이라고 확신합니다. 이것은 이미지가 일반적으로 래스터 순서로 저장되거나 오히려 브라우저에서 받은 이미지의 시작 바이트들이 이미지의 좌상단에서 시작하여 행을 수평으로 가로질러 이동하기 때문입니다. 만약 우리가 이미지를 다른 방법으로 저장하여 처음 전송된 데이터가 변경된다면 이미지가 어떻게 보여질지도 바뀐다는 것은 말할 필요도 없을 것입니다.

인코딩에 대한 이 “Progressive” 방식은 페이지가 '빠르게' 로딩되고 있다(주: 사용자에 따라 다를 수 있음)고 사용자가 인지하는데 긍정적인 영향을 줄 수 있습니다. 이는 사용자에게 빠르게 전달할 수 있는 작은 해상도들로 이루어진 이미지의 몇가지 추가 버전들에 대한 인코딩으로 이루어집니다.

Coddinghorror.com는 위 2가지 기법들 간의 시각적 차이점을 보여주는 좋은 예입니다. 여러분은 표준 방법이 이미지의 하향식 표시를 생성하고 Progressive 방식은 데이터를 수신할수록 시각적인 표현을 '개선'하는 것을 볼 수 있을 것입니다.

Linear
Progressive
Figure 6 - Linear 대 Progressive 로딩의 예시.

만약 유니콘들이 마음에 들지 않는다면 여러분은 보다 깊이있는 예제를 Patrick Meenan의 블로그에서 받을 수 있습니다. 또는 패트릭의 인터랙티브 도구를 이용하여 여러분의 이미지에 이것을 시도해볼 수 있습니다.

여러분의 이미지에서 이 속성을 사용하는 것은 아주 간단합니다. 간단하게 여러분의 GIF나 PNG 이미지들을 "interlaced" 옵션으로 저장하거나 여러분의 JPEG 이미지들을 "progressive" 옵션으로 저장하면 됩니다. 그러면 여러분의 사용자들이 여러분의 웹사이트에 만족하기 시작합니다. 모든 브라우저에서 Progressive 이미지를 지원하지 않는 것은 말할 필요도 없지만 그런 플랫폼에서 Progressive 이미지를 로딩하는 것은 솔직히 성능에 나쁜 영향을 줄 수 있습니다.

박스 밖의 이미지들

인터넷은 훌륭한 웹 개발자들로 가득 차있으며 훌륭한 핵들과 차선책들 그리고 개발자들이 그들로 하여금 더 작은 크기와 높은 품질을 가진 인상적인 이미지를 생성할 수 있도록 해주는 일반적인 인상적인 것들에 대한 언급없이 이미지 압축에 대한 완전한 글은 없습니다.

향상된 압축을 위한 투명 레이어의 분리.

HTML5 게임 개발자들은 일반적으로 여러분의 표준적인 웹사이트보다 더 많은 이미지 데이터를 보내고 그것들 중 대부분은 '책 넘기기 애니메이션'을 위한 투명한 프레임입니다. 슬프게도 그것은 이러한 파일들이 투명도를 위한 PNG 옵션의 사용을 강제하고 있습니다. 그러나 소수의 개발자가 이미지를 보다 좋게 압축하고 투명하게 처리하기 위해 차선책을 고안해냈습니다. 예를 들어 여러분은 여러분의 색상 데이터와 투명도 정보를 두개의 분리된 파일(예를 들어 2개의 JPEG)로 나눌 수 있으며 그것들을 캔버스 요소들을 이용하여 클라이언트에서 복원할 수 있습니다. 이러한 방법은 네트워크 상에서 많은 요청의 발생을 증가시키겠지만 그들의 사이트의 투명도를 가진 엄청난 양의 이미지들로부터 이미지의 크기를 명시적으로 절감할 수 있습니다.

Jake Achibald says:
그것을 지원해야 하는 곳에서 캔버스에서 모든 것을 하는 이 말도 안되는 일들 보다는 그냥 -webkit-mask를 사용하는 것이 훨씬 빠르다는 것은 말할 필요도 없습니다. 여러분에게는 다행스럽게도 저는 이러한 일들을 도와주는 라이브러리를 제공합니다.

보다 나은 프로세싱을 통한 PNG 압축 개선하기.

PNG의 Deflate 옵션은 무손실 인코딩을 수행하지만 여러분이 무손실 방식만을 원한다고 해도 손실 선처리를 포함하는 것을 막을 수는 없습니다. ImageAlphaImageOptim같은 이미지 프로세싱 도구들은 여러분의 PNG 이미지를 최종 PNG 포맷으로 전달하기 전에 손실 방식으로 선처리한 뒤 압축할 수 있습니다. 이것은 여러분의 손실 그리고 무손실 압축이 2개의 분리된 응용 프로그램에서 완료되는 두단계의 처리 과정을 만들어냅니다. 이는 무손실 압축기가 파일 내에 보다 자주 찾고 매칭할 수 있는 감소된 색공간을 만들어 더 좋은 압축 결과에 도달하는 인상적인 결과물을 제공합니다.

일단 PNG를 출력하고 나면 더 작은 PNG 파일을 생성하는 발전된 압축기를 사용하여 여러분의 PNG 데이터를 다시 패키징할 때입니다. 여러분이 이미지 출력한 PNG를 적용할 수 있는 advPNG와 같은 도구를 실행해서 더 나은 Deflate 압축을 통해 더 작은 파일을 얻을 수 있습니다. 혹은 OptiPNGZopfli와 같은 도구와 함께 PNGOUT를 결합하여 같은 효과를 얻을 수 있습니다. 물론 이러한 시스템은 각각 주어진 입력 시스템에 대해 약간 다른 결과를 만들어 내기 떄문에 다양한 압축기들 중 가장 작은 파일을 취하는 하나의 압축 시스템을 적용하는 것이 현명할 수도 있습니다. 만약 귀찮다면 ScriptPNG가 무거운 짐을 덜어줄 것입니다.

모든 애니메이션이 똑같이 생성되지는 않습니다.

SublimeText팀은 편집기의 기능을 보여주는 리치 애니메이션을 포함하는 웹사이트를 런칭했습니다. 비디오나 표준 GIF를 사용하는 것 대신 아주 아주 작은 용량의 사용자 애니메이션과 훌륭한 이미지 애니메이션을 제공하기 위한 패킹 시스템을 개발했습니다. 이 기법은 그들로 하여금 별도의 고도화된 비디오나 플래시 플러그인 없이도 멀티 플랫폼에서 고품질 애니메이션을 표시할 수 있었습니다.

반응형 이미지를 위한 여러가지 방법

웹사이트에서 가장 중요한 것은 사용자의 인식이기 때문에 빠른 로딩을 '인식할 수 있는' 웹사이트를 개발하는 다른 방법이 있다는 것은 주목할만 합니다. 최근 BBC는 그들의 사이트를 반응형 이미지를 처리하도록 변경했습니다. 그들의 기법은 클라이언트에서 가장 먼저 작은 이미지를 다운로드하도록 하고 (따라서 일단 뭔가 보임) 필요로하는 고해상도 이미지를 늦게 로딩(Lazy-loaded)하도록 합니다. 여러분은 그들의 기법에 대한 보다 자세한 설명과 더불어 여러분의 사이트에 활용하기 위한 오픈소스 버전을 확인할 수 있습니다.

결론

이미지는 사이트의 사용자 인지와 품질을 향상할 수 있는 교묘한 콘텐츠 형식이기도 하지만 반대로 빠른 로딩과 반응 품질에 대한 여러분의 수고를 약화시킬 수도 있습니다. 사이트를 적재하기 전에 다음을 확인하시기 바랍니다.

이미지 압축의 체크리스트:
  1. 이미지를 괜찮게 보이는 가장 낮은 품질, 올바른 포맷으로 압축하라.
    1. 모든 이미지에 대해 압축 품질을 가능한만큼 직접 튜닝하라.
    2. 나머지는 가장 높은 성능을 얻기 위해 최적화를 자동화하라.
  2. 요구되는 모든 이미지에 대해 WebP의 사용을 확인하라.
  3. 페이지의 로딩타임에 대한 사용자 인식을 개선하기 위해 Progressive 옵션으로 이미지를 저장하자
  4. 더 나은 압축이나 투명 처리를 위해 다른 흥미로운 방법들을 조사하자. 사고의 틀을 벗어나자!

유용한 도구들

Comments

0