모바일용 이미지 최적화 가이드

( 이 기사는 후원을 받은 기사입니다. ) 빠르게 로드되는 웹사이트를 구축하는 것이 얼마나 중요한지 알고 있습니다. 방문자와 판매를 잃기 시작하기에는 페이지가 1초 동안 너무 오래 로드되기만 하면 됩니다. 또한 Google이 모바일 우선 인덱싱을 기본으로 설정했기 때문에 모바일 사이트를 데스크톱만큼 빠르게 만드는 것이 얼마나 어려운지 성능 최적화를 방치할 수 없습니다.

Google은 웹사이트의 순위를 정할 때 많은 요소를 고려하며 방문자는 사이트 탐색을 결정할 때 몇 가지 요소를 고려할 수 있습니다. 둘의 교차점은 웹사이트 속도 입니다.

이미지가 웹사이트의 속도에 많은 문제를 일으킨다는 것은 놀라운 일이 아닙니다. 그리고 항상 지방을 줄이고 더 최소한으로 디자인되고 콘텐츠 중심적인 사이트를 구축할 수 있지만 왜 타협을 합니까?

이미지는 웹에서 강력한 힘입니다.

잘 선택한 이미지는 사이트의 미학을 향상시킬 뿐만 아니라 방문자가 콘텐츠를 더 쉽게 소비할 수 있도록 합니다. 물론 이미지의 SEO 이점도 있습니다.

그래서 오늘은 웹사이트 속도를 늦추지 않고 원하는 만큼 이미지를 디자인할 수 있는 방법에 집중해 보겠습니다. 이렇게 하려면 이미지 최적화 전략을 업데이트하고 ImageKit이라는 도구를 채택해야 하지만 이 새 시스템을 제자리에 설치하는 데 많은 노력이 필요하지 않습니다.

모바일을 위한 이미지 최적화 전략의 필요성

HTTP 아카이브에 따르면:

• 2019년 데스크톱 웹사이트의 중간 크기는 1939.5KB 입니다.
• 2019년 모바일 웹사이트의 중간 크기는 1745.0KB 입니다.

이러한 성장을 처리하지 못하면 빠른 웹사이트 제공에 관한 소비자 및 Google 요구 사항을 충족하는 것이 불가능할 것입니다. 그렇지 않으면 속도 최적화를 정말 잘해야 합니다.

속도에 대해 말하자면 HTTP Archive가 이미지 무게에 대해 무엇을 말하는지 봅시다.

현재 상태:

• 데스크톱 이미지 의 중간 크기는 총 1939.5KB 중 980.3KB입니다.
• 모바일 이미지 의 중간 크기는 총 1745.0KB 중 891.7KB입니다.

결론: 이미지는 웹사이트에 많은 무게를 추가하고 많은 대역폭을 소비합니다. 그리고 이 데이터는 모바일에서 이미지의 중앙값 크기가 데스크톱 이미지보다 작다는 것을 보여주지만 웹사이트에 대한 이미지의 비율은 약간 더 큽니다.

즉, 올바른 이미지 최적화 전략이 있으면 쉽게 해결할 수 있습니다.

이 전략에 수반되어야 하는 사항은 다음과 같습니다.

1. 이미지 크기를 올바르게 조정

적절한 자동화 없이 처리해야 하는 지루한 작업이 많이 있습니다. 이미지 크기를 조정하는 것과 같습니다.

하지만 당신은 그것을해야, 그렇지?

Unsplash를 사용하여 작업 중인 웹사이트의 여러 이미지를 제공한다고 가정해 보겠습니다.

파일을 다운로드할 크기나 파일 형식을 선택할 수 있는 프리미엄 스톡 리포지토리와 달리 여기에서는 선택할 수 없습니다.

따라서 이미지와 필요한 다른 모든 것을 다운로드합니다. 그런 다음 이미지를 있는 그대로 사용하거나 수동으로 크기를 조정할 수 있습니다. 파일 크기와 이미지 크기를 보고 나면 크기를 조정하는 것이 좋습니다.

이 특정 이미지는 3.6MB 파일과 5591×3145픽셀 이미지로 내보냈습니다. 그것은 어떤 웹사이트에도 너무 큽니다.

1MB보다 큰 이미지를 업로드할 이유가 없습니다. 치수는? 글쎄, 그것은 사이트의 너비에 따라 다르지만 1200에서 2000픽셀 사이의 어딘가에서 최대가 되어야 한다고 생각합니다.

스톡 사이트에서 가져온 이미지든 누군가의 DSLR에서 가져온 이미지든 동일한 과정을 거쳐야 합니다. 요점은 소스 이미지가 웹사이트에 "올바른" 크기로 나오지 않을 것이라는 점입니다.

또한 반응형 웹사이트는 보는 기기나 브라우저에 따라 다양한 크기의 이미지를 표시합니다. 그리고 전체 크기 이미지 대 축소판 또는 전체 크기 제품 사진 대 추천 이미지와 같은 다양한 사용 사례가 있습니다.

따라서 수동으로 크기를 조정하는 문제를 겪은 후에도 수행해야 하는 크기 조정이 더 있습니다.

다음 은 하지 말아야 할 일입니다.

• 이미지를 하나씩 크기를 조정합니다. 시간이 많이 걸리고 비효율적입니다.
• 문제가 발생할 수 있으므로 브라우저 크기 조정에 의존하여 이미지를 반응형으로 표시합니다.

대신 기존 이미지 서버(웹 호스트에 있음) 또는 외부 스토리지 서비스(예: S3)를 ImageKit과 통합할 수 있습니다. 또는 ImageKit의 미디어 라이브러리를 사용하여 파일을 저장할 수 있습니다.

보시다시피 ImageKit은 이 Unsplash 사진을 원래 크기와 크기로 업로드하는 것을 수락했습니다. 파일의 출처가 어디든 마찬가지입니다.

그러나 이미지 또는 이미지 저장소를 ImageKit과 통합하면 도구가 이미지 크기 조정을 제어합니다. 여기에서 방법을 확인할 수 있습니다.

위에서 보고 있는 내용을 간략하게 설명하겠습니다.

• Image Origin Preference 는 ImageKit에서 이미지를 최적화해야 하는 위치를 알려줍니다. 이 경우 ImageKit 미디어 라이브러리이며 내 웹사이트를 통해 제공됩니다.
• 이전 이미지 URL 은 서버에서 이미지가 있었던 위치를 알려줍니다.
• 새 이미지 URL 은 ImageKit을 통해 이미지가 최적화되는 위치를 설명합니다.

공식은 충분히 간단합니다. 이미지의 원본 URL을 가져와 새로운 ImageKit URL로 변환합니다.

ImageKit URL만으로도 이미지 파일의 크기가 즉시 줄어듭니다. 그러나 이미지 크기를 조정하려는 경우 변환 매개변수를 사용하여 수행할 수 있습니다.

예를 들어, 이것은 내 웹사이트의 미디어 라이브러리에서 본 Unsplash 사진입니다. 내 서버에 있기 때문에 주소에 내 URL이 표시됩니다.

ImageKit에서 변환한 후 어떻게 보이는지 확인하기 위해 내 도메인 이름을 ImageKit에서 제공한 끝점으로 바꿉니다. 그런 다음 이미지 크기 조정 매개변수를 추가하고(단순한 크기 조정 이상을 수행할 수 있음) 이미지 저장소를 가리키는 URL의 나머지 부분을 다시 연결합니다.

ImageKit을 사용하여 이미지 크기를 1000×560 픽셀로 자동 조정하면 다음과 같습니다.

이 크기가 조정된 이미지를 만들기 위해 ImageKit URL을 다음과 같이 변환했습니다.

https://imagekit.io/vq1l4ywcv/ tr:w-1000,h-560/…

파일의 크기를 줄인 것은 너비(w-) 및 높이(h-) 매개변수입니다.

보시다시피 원본 이미지만큼 픽셀이 완벽하지는 않지만 파일에 상당한 압축률(80%)이 적용되었기 때문입니다. 어떻게 작동하는지 아래에서 다루겠습니다.

그 동안에 이미지가 여전히 얼마나 멋지게 보이는지와 속도에서 얻을 수 있는 이득에 초점을 맞춰 보겠습니다.

이전에는 5591×3145픽셀 이미지용 3.6MB 파일이었습니다. 이제 1000×560픽셀 이미지용 128KB 파일입니다.

거래를 더욱 달콤하게 하기 위해 ImageKit을 사용하면 URL 기반 이미지 변환을 사용하여 이러한 방식으로 이미지 크기를 쉽게 조정할 수 있습니다. 기본적으로 다음과 같이 작동합니다.

• 하나의 마스터 이미지를 ImageKit의 미디어 라이브러리 또는 선호하는 서버에 저장합니다.
• ImageKit은 자동으로 여러 기술을 사용하여 이미지 크기를 크게 줄입니다.
• 그런 다음 ImageKit의 크기 조정 및 자르기 매개변수를 사용하여 다양한 장치 해상도 및 크기에 맞게 각 이미지를 수정할 수 있습니다.

91mobiles는 이러한 형태의 이미지 최적화를 활용하여 웹사이트의 대역폭을 매월 3.5TB 절약했습니다. 그리고 그들은 플랫폼과 통합하는 것 외에는 아무 것도 할 필요가 없었습니다. 이미지를 ImageKit 또는 다른 타사 스토리지 서비스로 이동할 필요가 없었습니다. 이 모든 것이 레거시 인프라 내에서 발생했습니다.

2. 더 빠른 로딩 이미지 형식 사용

저장 공간과 대역폭을 소모하는 것은 이미지 크기만이 아닙니다. 사용하는 파일 형식도 영향을 미칩니다.

PNG 는 일반적으로 로고, 텍스트가 포함된 이미지 및 배경이 투명한 기타 초정밀 이미지에 사용됩니다. 사진을 저장하는 데 사용할 수 있지만 가장 큰 크기를 생성하는 경향이 있습니다. 무손실 압축이 적용된 경우에도 PNG는 여전히 다른 파일 형식보다 크기가 큽니다.

GIF 는 PNG의 애니메이션 대응물이며 무손실 압축도 사용합니다.

반면에 JPG 는 다채로운 이미지와 사진에 가장 적합합니다. 크기가 더 작고 손실 압축으로 축소됩니다. JPG를 관리 가능한 크기로 충분히 압축할 수 있지만 손실 압축은 파일의 전체 품질을 저하시키고 완료되면 되돌릴 수 없으므로 주의해야 합니다.

WebP 는 2010년대 초 Google에서 도입한 이후 인기를 얻고 있습니다. Google 연구에 따르면 WebP는 JPG보다 25%~34% 작을 수 있습니다. 또한 WebP에서 손실 압축과 무손실 압축을 모두 사용하여 더 작은 크기로 줄일 수 있습니다.

WebP에서 염두에 두어야 할 사항은 보편적으로 허용되지 않는다는 것입니다. 이 글을 쓰는 시점에서 WebP는 iOS 기기에서 허용되지 않습니다. 그러나 Google 또는 기타 다른 모든 브라우저의 최신 버전은 기꺼이 표시합니다.

ImageKit이 이것을 어떻게 돕는지에 관해서는 정말 간단합니다.

이 설정이 구성되면 ImageKit은 각 파일을 전달할 최상의 파일 형식을 자동으로 결정합니다. 방문자의 장치가 지원하는지 여부와 함께 원본 이미지 형식 및 콘텐츠가 무엇인지 고려합니다.

JPG, PNG 및 GIF는 방문자가 Chrome에서 방문하는 경우(이를 허용하는 경우) 가능한 경우 모두 WebP로 변환됩니다. 가능하지 않은 경우(예: 방문자가 Safari에서 방문하는 경우)(이를 허용하지 않는 경우) ImageKit은 정의된 변환을 사용하여 최상의(즉, 가장 작은) 형식으로 변환합니다. PNG 또는 JPG일 수 있습니다.

Nykaa는 ImageKit의 이 이미지 최적화 전략을 활용할 수 있었습니다. 그들의 웹사이트는 이미 JPG와 PNG를 혼합하여 디자인되었고 웹의 여러 위치에 저장되었지만 ImageKit은 원본 URL에서 바로 이미지 형식을 자동화했습니다.

3. 이미지 압축

다음으로 이미지 압축에 대해 이야기해야 합니다. 이미 몇 번 언급했지만 두 가지 유형으로 나뉩니다.

무손실

이 압축 형식은 PNG 및 GIF에 사용됩니다. 파일을 압축하기 위해 메타데이터가 제거됩니다. 이렇게 하면 이미지의 무결성은 그대로 유지되지만 파일 축소는 손실 압축으로 얻을 수 있는 만큼 크지 않습니다.

손실

이 압축 형식은 JPG 및 WebP에 적용됩니다. 파일을 압축하기 위해 이미지의 일부가 "손실"되어 특정 부분에 원본 이미지보다 더 세분화된 모양을 줄 수 있습니다. 대부분의 경우 두 이미지를 나란히 놓고 자세히 보지 않으면 거의 눈에 띄지 않습니다. 그러나 방문자에게는 비교할 원본이 없기 때문에 저하를 놓치기 쉽습니다.

손실 압축을 사용하면 파일의 성능이 저하되는 비율을 제어할 수 있습니다. 안전한 범위는 70%에서 80% 사이입니다. ImageKit은 기본적으로 최적화를 80%로 설정하고 이로부터 파일 크기의 최소 20%에서 25%를 절약할 수 있다고 추정합니다. 그러나 실제로는 더 많을 것입니다(위의 Unsplash 이미지 예에서와 같이 40% 이상을 보고 있음).

사이트를 빠르게 로드하는 데 도움이 되는 이미지 크기를 제공하면서 품질을 유지할 수 있다고 생각되는 기본값으로 변경할 수 있습니다.

기본 설정을 사용하든 고유한 최적화 설정을 사용하든 고급 탭에서 사용할 수 있는 추가 압축 설정을 켜야 합니다.

특히 이 세 가지 설정을 사용하면 최대한 안전하게 압축할 수 있습니다.

예를 들어 첫 번째 설정인 "사본 저장"은 원본 이미지를 ImageKit 서버에 보관합니다. 그렇게 하면 자체 서버에서 부담을 관리할 필요 없이 이미지 사전 압축 복사본을 갖게 됩니다.

두 번째 설정인 "Preserve Image Metadata"를 사용하면 가능한 경우 무손실 압축을 적용할 수 있습니다.

마지막 설정인 "PNG 이미지 압축 모드"를 사용하면 PNG에 사용할 무손실 최적화 수준(최대, 최소 또는 없음)을 결정할 수 있습니다.

완료되면 다음과 같은 병렬 비교 결과가 나타납니다.

Unsplash의 JPG입니다. 어느 것이 원본이고 어느 것이 ImageKit에서 압축 및 크기 조정된 버전인지 알 수 있습니까?

검은색 테두리가 있는 왼쪽은 다음과 같습니다.

• 1500×1005픽셀
• 266KB
• 95%로 압축

흰색 테두리가 있는 오른쪽은 다음과 같습니다.

• 5444×3649픽셀
• 2.5MB
• 원래의

ImageKit 압축 및 최적화 설정 중 가장 사용하기 편한 설정을 결정한 다음 그에 따라 구성하는 것은 사용자의 몫입니다.

4. 외부 서버에 이미지 저장 및 가져오기

ImageKit을 통해 이미지를 실행하는 두 가지 방법이 있습니다.

첫 번째는 이미지를 미디어 라이브러리에 직접 업로드하는 것입니다.

두 번째는 웹사이트 또는 외부 저장소 서비스와 통합하는 것입니다. 우리는 실제로 ImageKit의 이 부분을 이미 보았습니다. 여기에서 이미지 매개변수를 정의할 수 있도록 URL 엔드포인트를 가져옵니다.

위의 모든 최적화에도 불구하고 이미지 저장 및 유지 관리에 여전히 어려움을 겪을 수 있습니다. 이미지 저장 및 유지 관리가 속도에 미치는 영향이나 저장해야 하는 저장 공간 때문입니다.

예를 들어, 이미지를 서버에 저장하면 결국 공간에 제약을 받게 됩니다(괴물 크기의 호스팅 계정이 없는 경우).

수천 또는 수백만 개의 이미지와 해당 이미지 크기가 있는 대규모 전자 상거래 상점이나 비즈니스 웹 사이트를 구축할 때 이러한 이미지를 직접 호스팅할 여유가 없습니다. 물론 방문자에게 더 빨리 서비스를 제공할 수 있는 방법이 있지만(다음 항목에서 설명하겠습니다) 필요하지 않은 경우 추가 스토리지의 부담과 비용을 부담해야 하는 이유는 무엇입니까?

5. CDN 추가

CDN은 대규모 이미지 저장소를 위한 또 다른 필수 최적화 도구입니다. 두 번째 서버라고 생각하면 이 서버만 웹사이트를 캐시(복사)하고 전 세계 방문자에게 훨씬 더 가까운 데이터 센터를 통해 서비스를 제공합니다.

결과적으로 웹 사이트와 수천 개의 제품 이미지를 뉴욕 뉴욕에서 인도 방글라데시로 보내는 데 걸리는 시간이 엄청나게 빠릅니다.

ImageKit을 사용하면 핵심 처리 서버뿐만 아니라 전 세계적으로 150개 이상의 위치를 ​​가진 AWS CloudFront CDN(모든 플랜에 포함)을 통해 이미지를 제공할 수 있는 특권을 누릴 수 있습니다.

ImageKit의 클라이언트인 Sintra는 ImageKit으로 전환한 후 성능이 크게 향상되었습니다. ImageKit 이미지 CDN(전 세계에 배달 노드가 있음)을 사용하면 페이지 로드 시간이 18% 감소했습니다.

마무리

ImageKit에서 특히 좋은 점은 이미지로 인한 속도 저하에 대한 예방 조치가 아니라는 것입니다. 이미 수백만 개의 이미지가 있는 경우에도 이를 사용하여 모바일 웹사이트 및 PWA를 소급하여 수정하고 개선할 수 있습니다. 또한 성능 센터를 통해 웹 사이트 이미지를 쉽게 주시하고 속도 향상 기회를 식별할 수 있습니다.

또한 위의 팁에서 볼 수 있듯이 ImageKit은 수동으로 처리하든 플러그인을 통해 구성하든 상관없이 수행해야 하는 많은 작업을 단순화했습니다.

웹사이트가 모바일에서 로드되는 속도에 대해 소비자와 Google이 날로 까다로워짐에 따라 이것이 필요한 이미지 최적화 전략입니다. ImageKit 전후에 추가된 모든 이미지가 최대한 최적화되도록 하는 동시에 부담을 덜어줍니다. 더 나아가 고객은 더 많은 리드와 더 많은 전환의 이점을 누릴 수 있습니다.