WURFL 디바이스 탐지 모듈 NGINX 탑재하기
해당 포스트에서는 NGINX Plus 및 WURFL 의 반응형 웹 디자인 및 웹 사이트 성능에 대해 논의하고 간단한 구성으로 방법을 보여주며 설명합니다.
반응형 웹 디자인(RWD)은 어느 정도 시간이 지나며 “하이프 사이클(hype cycle)”을 통과하고 “생산성의 고원(plateau of productivity)“에 이르렀습니다. RWD를 사용하면 웹 개발자들은 디자인이 브라우저 창에 동적으로 조정되고, 일부로는 사용자 디바이스의 형태 요소에도 조정되는 방법에 대한 프레임워크와 지침을 갖게 됩니다.
하지만, 빛나는 것이 모두 금은 아닙니다. 반응형 웹 디자인에서 이미지 처리는 웹사이트의 성능이 중요할 때 주요한 문제로 대두되었습니다. 일반적인 일체형 이미지 콘텐츠의 경우, 웹 개발자들은 데스크톱, 태블릿, 스마트폰 사용자에게도 고해상도 이미지를 제공해야 하는 상황에 직면하게 됩니다.
게다가 이러한 사용자들이 불안정한 모바일 연결을 통해 사이트에 액세스(Access)할 수 있다는 사실을 추가하면 이러한 접근 방식은 많은 사용자에게 실망스러울 정도로 느린 사용자 환경을 상상할 수 있습니다. 네트워크가 느린 경우가 많을 뿐만 아니라, 메모리 사용량이 큰 페이지는 렌더링이 느리고 스크롤이 어렵습니다. 따라서 서비스와 상호 작용하려고 할 때 디바이스(Device)가 응답하지 않는 것처럼 느껴질 수 있습니다.
느린 페이지 로딩 시간은 사용자뿐만 아니라 검색 엔진 순위 결정 시에도 영향을 미칩니다. 구글은 페이지 로딩 시간을 검색 엔진 순위 결정에 사용합니다. 따라서 페이지 로딩 시간이 오래 걸리면 사용자들이 웹페이지에 도달할 때 좌절할 뿐만 아니라, 처음부터 웹페이지에 도달하지 못하게 할 수도 있습니다!
목차
1. 느린 페이지 로딩 시간 해결
2. ScientiaMobile의 ImageEngine 소개
3. 시나리오 1: ImageEngine에 직접 이미지 요청
4. 시나리오 2: WURFL을 활용하기
5. WURFL 디바이스 탐지 요약
1. 느린 페이지 로딩 시간 해결
느린 페이지 로딩 시간을 완화하기 위한 조기 접근 방식은 폴리필(polyfills), CSS hacks, JavaScript libraries 등의 기술이었습니다. 그러나 몇 년 후에는 반응형 이미지(HTML <picture> 태그)가 같 문제를 보다 표준적인 방법으로 해결하기 위해 도입되었습니다. <picture> 태그를 통해 개발자들은 이미지의 여러 버전에 대한 참조를 제공하고, (최근의) 브라우저가 현재의 브라우징 환경에 맞는 올바른 이미지를 선택할 수 있도록 할 수 있습니다.
오래된 브라우저는 제외하고, <picture> 태그를 사용하여 반응형 이미지를 제공하는 전형적인 시나리오는 다음과 같습니다:
<picture>
<source media="(min-width: 40em)" srcset="big.jpg 1x, big-hd.jpg 2x">
<source srcset="small.jpg 1x, small-hd.jpg 2x">
<img src="fallback.jpg" alt="">
</picture>오래된 브라우저는 대체 이미지인 “fallback.jpg”를 기본으로 사용하지만, 최신 브라우저는 브라우저 컨텍스트를 평가하고 가장 적합한 이미지를 요청할 수 있습니다. NGINX 블로그의 독자들은 이것을 기반으로 한 스마트한 트릭으로 NGINX가 Image-Filter 모듈을 사용하여 크기 조정된 이미지를 제공할 수 있음을 인식할 수 있습니다.
이 필터를 사용하면 마크업에서 필요한 크기를 지정할 수 있으며, 설정을 통해 이미지 URL에 필터가 크기 조정을 위해 필요한 지시문을 함께 포함할 수 있습니다.
위의 기술은 훌륭한 방법이지만, 웹 콘텐츠가 어떻게 구성되고 관리되는지에 대한 몇 가지 중요한 가정에 의존합니다. 예를 들어, 이미지가 파일로 구성되어 있고 서버의 폴더에 배치되어 있다고 가정합니다. 특히 대규모 조직에서 이것이 불가능할 수 있는 이유는 다음과 같습니다.
- 기존 그래픽 자산은 콘텐츠 관리 시스템(CMS)을 통해 관리됩니다. 즉, 자동으로 조작하거나 이름을 바꿀 수 있는 정적 파일이 없습니다.
- 이미지 용도를 변경하기 위해 HTML을 편집하는 것은 실행할 수 있 옵션이 아닐 수 있습니다.
- 기존 웹 콘텐츠는 쉽게 재구성되지 않을 수 있습니다.
위에 언급된 기존 콘텐츠를 가진 경우, <picture> 태그는 문제의 해결책이 되지 않습니다. 기껏해야 문제를 재정의하는 메커니즘으로 간주할 수 있습니다. 반응형 이미지를 사용하면 다중 제공 이미지는 더 이상 기술적인 문제가 아니라 리소스 중 하나입니다. 이제 중단점을 선택하고, 다양한 이미지 버전을 만들고, 끊임없이 확장되는 이미지 자산 라이브러리를 관리할 수 있는 편집팀이 필요합니다.
문제는 이미지. 즉, 각 이미지의 올바른 버전이 어딘가에 존재해야 하며, 가볍고 모든 디바이스에서 시각적 품질이 좋아야 한다는 것입니다. 그러나 그것만으로는 충분하지 않습니다. 웹은 점점 다양해지고 있습니다. 새로운 디바이스는 새로운 크기나 형식을 요구할 수 있으며, 오래된 형식과 크기는 시간이 지남에 따라 사용되지 않게 될 수도 있습니다. 이 시점에서는 미래를 고려하는 것이 바람직할 수 있습니다.
2. ScientiaMobile의 ImageEngine 소개
여기에서 ScientiaMobile의 ImageEngine이 도움이 되는 곳입니다. ImageEngine은 동적 이미지 최적화 콘텐츠 전송 네트워크(CDN)로, 엣지 서버에 추가 로직이 있습니다. 이 엣지 서버는 CDN을 구성하며 클라이언트 애플리케이션에 근접성을 보장합니다. 이 엣지 로직 덕분에 ImageEngine은 요청하는 디바이스의 크기와 특성에 맞게 이미지를 최적화할 수 있습니다.
더 구체적으로 말하면, ImageEngine은 디바이스 감지를 활용하여 디바이스의 화면 크기와 특성을 기반으로 이미지의 최적 크기와 형식을 결정합니다. 디바이스 감지는 WURFL 디바이스 설명 저장소와 클라이언트 힌트의 조합을 활용합니다. 이 두 가지를 함께 사용함으로써, 이미 알려진 디바이스 특성과 연결 유형 또는 데이터를 저장해야 한다는 표시와 같이 실행 시에만 알 수 있는 특성을 결합하여 최상의 결과를 제공합니다.
예를 들어, ImageEngine은 저대역폭 연결을 통해 서비스에 접근하는 HTTP 클라이언트를 위해 더 강력하게 압축할 수 있습니다. 이러한 최적화는 실시간으로 이루어지지만, CDN은 이미지를 요청할 수 있는 에이전트 근처에 캐시하여 저장합니다. 이를 통해 이미지 요청에 대한 응답 속도를 향상하고, 네트워크 대역폭을 효과적으로 관리할 수 있습니다.
WURFL 을 사용하면 ImageEngine이 추가적인 반응형 이미지 HTML 태그 없이 모바일 트래픽을 처리할 수 있게 해줍니다. 또한, WURFL 은 Client Hints를 지원하지 않는 브라우저에 대해서도 보완적인 역할을 합니다.
이 포스트에서는 NGINX Plus와 ImageEngine이 함께 작동하는 두 가지 시나리오를 설명합니다. 첫 번째 시나리오는 이미지 URL을 rewrite하는 간단한 NGINX Plus 구성을 사용하여 ImageEngine CDN에 이미지 서빙을 Offload하는 간단하면서도 효과적인 방법입니다. 이 시나리오는 추가 모듈이나 추가 소프트웨어가 필요하지 않습니다.
두 번째 시나리오는 더 고급이며 NGINX Plus용 WURFL InFuze Certified 모듈에 의존합니다. 이 더 고급 시나리오에서 WURFL 은 명시적인 ImageEngine 지시문에 의존하여 조직의 특정 비즈니스 모델을 지원합니다.
첫 번째 시나리오를 위한 전제 조건은 ImageEngine 라이선스입니다. 두 번째 시나리오에는 WURFL NGINX Plus Certified 모듈이 추가로 필요합니다. ImageEngine 및 WURFL 모듈의 무료 평가판을 요청하려면 www.scientiamobile.com 에서 신청할 수 있습니다.
3. 시나리오 1: ImageEngine에 직접 이미지 요청
NGINX 또는 NGINX Plus 구성에서는 모든 이미지 요청을 ImageEngine 계정 등록 절차 중에 얻은 고유한 ImageEngine 호스트명으로 간단히 리다이렉션합니다. 아래의 예시에서는 try.Imgeng.in을 호스트명으로 사용합니다. 이는 ImageEngine을 시도해보고 싶은 사용자를 위해 공개적으로 제공되는 계정입니다.
이 호스트명을 통해 이미지를 제공할 때, 모든 이미지는 요청한 디바이스나 브라우저에 자동으로 최적화됩니다. 그러나 try.imgeng.in에는 일부 제한이 있으므로 완전한 기능을 이용하려면 본인만의 평가판 계정을 등록하는 것을 권장합니다.
여러 이미지 유형의 요청을 ImageEngine으로 리다이렉션하려면 다음 스니펫을 server 블록에 추가하십시오:
location ~ .*.(jpg|jpeg|gif|png|webp).*$ {
if ($arg_optimize != no) {
return 301 http://try.imgeng.in/http://$http_host$request_uri?optimize=no;
}
}요청 URL에 optimize=no 인자를 포함하면, 처리되지 않은 원본 이미지를 받을 수 있습니다.
<body>
<h1>Redirect</h1>
<p>Request for image below is redirected to imgeng.in for processing.</p>
<img style="max-width: 100%" srcredu="ie1.jpg"/>
<p>Request for image below is returned as is.</p>
<img style="max-width: 100%" src="ie1.jpg?optimize=no"/>
</body>이 간단한 구성 변경만으로 사용자는 더 빠른 페이지 로딩을 경험할 수 있습니다. ImageEngine의 효과는 사이트의 성격마다 다르지만, 다음 테스트 결과는 개선 가능성을 보여줍니다. 테스트에서는 ImageEngine 데모 도구를 outnorth.com 전자 상거래 사이트에 대해 실행했습니다.
이 데모 도구는 오픈 소스인 WebPagetest.org 소프트웨어를 기반으로 하며, ImageEngine 최적화를 적용한 웹 사이트와 적용하지 않은 웹 사이트의 성능을 비교합니다. 이 도구는 여러 가지 흥미로운 지표를 제공하여 살펴볼 수 있습니다.
- “시각적 완성”까지 걸리는 시간 – 사용자가 콘텐츠를 읽고 상호작용을 시작할 수 있는 정도로 페이지가 시각적으로 완성된 시점을 측정합니다. 이는 WebPagetest의 Speed Index를 기반으로 합니다. ImageEngine을 사용하면 페이지의 시각적 완성이 1.5초 더 빨리 이루어지며(약 2배), 완전한 로드 시간도 1초 이상 짧아집니다.
ImageEngine 유무에 따른 시각적 완료 시간
- 페이지 무게 – 페이지를 완전히 렌더링하기 위해 다운로드해야 하는 데이터양을 말합니다. ImageEngine은 이미지의 용량을 55%로 줄이고, 전체 페이지 무게도 거의 20% 감소시킵니다.
ImageEngine 유무에 따른 페이지 무게 및 이미지 비교
- 이미지 로딩 시간 – 아마도 가장 흥미로운 지표 중 하나는 브라우저가 이미지를 로딩하는 데 걸리는 시간입니다. 이미지가 빠르게 다운로드되고 렌더링되면, 브라우저는 절약된 시간을 다른 작업에 사용할 수 있으며, 다른 자산을 로딩하거나 JavaScript를 실행하는 등 페이지의 시각화 속도를 크게 향상 수 있습니다. ImageEngine을 사용하면 페이지 로딩 시간이 거의 80% 정도 감소합니다.
ImageEngine 유무에 따른 이미지를 로드하는데 소요하는 시간
4. 시나리오 2: WURFL 을 활용하기
기본적으로 ImageEngine은 Client Hints와 디바이스 정보를 사용하여 이미지를 최적화하는 방법을 결정합니다. 그러나 이는 도구를 사용하는 유일한 방법은 아닙니다. ImageEngine은 각 이미지를 처리하는 방법에 대한 명시적 지시문도 받을 수 있습니다. 지시문을 통해 ImageEngine에서 디바이스 감지 기능을 비활성화하는 경우가 많지만, 모든 지시문이 그렇지는 않습니다. 지시문은 사실상 프로그래머가 자신이 무엇을 하고 있는지 알고 있으며, 크기 조정을 위한 ImageEngine의 built-in 지능을 재정의하기를 원한다고 알리는 방법입니다.
지시문은 이미지의 압축률, 포맷, 높이, 너비, 크롭, 맞춤, 그리고 기타 기능들을 지정할 수 있습니다. ImageEngine은 이미지의 최적화 대부분을 자동으로 처리하지만, 일부 지시문은 웹 사이트를 디자인할 때 유용합니다.
지시문은 쿼리 문자열 매개변수로 ImageEngine에 전달됩니다. 예를 들어, 이미지를 검색하는 URL에서 이미지의 정확한 너비와 높이를 지정하고 싶을 수 있습니다. 이 특정한 경우에서는 반환되는 이미지의 너비가 800픽셀이고 높이가 500픽셀입니다.
try.imgeng.in/http://example.com/img.png?imgeng=/w_800/h_500
이렇게 이미지 크기를 잠그면, 디바이스 및 브라우저의 속성과 관계없이 모든 디바이스 및 브라우저가 동일한 이미지를 받게 됩니다. 그러나 InFuze WURFL 모듈을 사용하여 자체 디바이스 인텔리전스를 지원할 수 있다면, NGINX Plus 사용자는 이를 수행할 수 있습니다. InFuze WURFL 모듈은 NGINX Plus에 디바이스 감지 기능을 추가합니다. 이러한 기능을 사용하여 각 디바이스별로 지시문이 변경된 URL을 생성할 수 있습니다.
참고: 설치 지침은 InFuze NGINX 모듈 사용 설명서를 참조하십시오.
다음은 추가 디바이스 정보로 HTTP 요청을 강화하는 방법을 보여주는 샘플 NGINX Plus 구성 스니펫입니다.
http {
wurfl_enable on;
# -- WURFL Data file load
wurfl_root /usr/share/wurfl/wurfl.zip;
# Increase the variable hash size
variables_hash_max_size 1024;
variables_hash_bucket_size 1024;
# -- WURFL cache: uncomment one of the following
#wurfl_cache_null;
wurfl_cache_double_lru 100000,30000;
# -- WURFL user-requested static capabilities (this is not a complete list)
wurfl_request_capability resolution_width;
wurfl_request_capability resolution_height;
}이 구성을 통해 NGINX Plus의 $resolution_width 및 $resolution_height 변수에서 요청하는 디바이스의 resolution_width 및 resolution_height 특성을 사용할 수 있습니다. 이러한 변수는 ImageEngine에 지시하여 요청하는 디바이스의 화면 크기에 맞는 이미지를 제공하도록 할 수 있습니다.
try.imgeng.in/http://examle.com/img.png?imgeng=/w_$wurfl_cap_resolution_width/h_$wurfl_cap_resolution_height/
이 변환을 동적으로 수행하려면 NGINX Plus가 필요합니다. 또한 이 단계를 사용하여 URL 재작성을 통해 URL을 더 예쁘게 만들 수 있습니다. 그 과정에서 다음과 같이 간단한 URL로 이미지를 참조할 수 있도록 imgeng.in에 대한 참조도 제거하고자 합니다.
//images.example.com/img.png
다음 NGINX Plus 구성은 해상도 이미지를 imgen.in 서비스에 전달하고 URL을 다시 작성하는 예입니다. 이 구성 조각은 더 큰 server 블록의 일부로 /etc/nginx/conf.d의 기존 .conf 파일에 추가할 수 있습니다.
location ~ .*.(jpg|jpeg|gif|png|webp).*$ {
if ($arg_optimize != no) {
return 301 http://try.imgeng.in/w_$wurfl_cap_resolution_width/h_$wurfl_cap_resolution_height/http://$http_host$request_uri?optimize=no;
}
}이 설정은 이미지가 화면의 해상도 너비보다 절대 크지 않도록 합니다. 예를 들어 영웅 이미지나 배경에 사용되는 이미지의 경우에 유용할 수 있습니다.
WURFL은 디바이스 화면 크기에 관한 것일 뿐만 아니라 다른 유형의 최적화, 광고 기술 및 분석에 활용할 수 있는 다양한 기타 속성도 포함합니다.
5. WURFL 디바이스 탐지 요약
이 포스트에서는 모바일 디바이스를 통해 액세스하는 웹 페이지의 페이로드를 최소화하기 위한 서버 측 디바이스 최적화의 이점에 대해 논의했습니다.
위에서는 디바이스 감지를 활용하여 RWD 환경에서 이미지의 크기 조정과 최적화를 위한 사용자 정의 정책을 구현하는 방법을 보여주었습니다. 이는 디바이스 감지가 적용될 수 있는 샘플 시나리오에 불과한 것이며, 다른 여러 시나리오도 가능합니다. NGINX Plus용 WURFL Certified 모듈은 스마트폰이나 피처폰과 같은 기기에 대해 콘텐츠의 축소된 버전을 생성하여 최적화하는 데 사용될 수 있습니다.
디바이스 정보를 HTTP 요청에 추가하는 것은 디바이스의 형태 요소와 HTTP 클라이언트를 기반으로 사용자 경험을 최적화하는 간단한 전략입니다. 제공하는 서비스에 따라 데스크톱 사용자, 태블릿 사용자 및 스마트 TV 사용자가 사이트를 다르게 탐색하는 것이 바람직할 수 있습니다. 디바이스 감지는 조직이나 비즈니스 모델에 더 적합한 방식으로 오퍼링을 세분화하는 데 도움을 줄 수 있습니다.
ScientiaMobile의 ImageEngine은 즉시 이점을 제공하는 훌륭한 출발점이지만 NGINX Plus 사용자는 NGINX Plus용 InFuze WURFL 인증 모듈을 채택하여 이점을 얻을 수도 있습니다.
WURFL 모듈은 NGINX Plus를 강화하고 다양한 HTTP 클라이언트의 실제 기능을 기반으로 새로운 정책을 활성화합니다. NGINX Plus용 WURFL 인증 모듈이 ImageEngine과 함께 작동하여 이미지 최적화를 위한 맞춤형 정책을 구현하고 사용자 경험을 개선하는 시나리오를 보여주었습니다.
이미지 최적화 사용 사례는 매우 매력적이지만 디바이스 감지에는 특히 강력한 NGINX Plus 기계와 연결하여 사용할 때 다양한 다른 용도가 있다고 언급했습니다.
WURFL InFuze Certified 모듈을 30일 동안 무료로 사용해 볼 수 있습니다.
NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.
사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.
댓글을 달려면 로그인해야 합니다.