논문번호: TR11-103, 논문접수일자:2011.12.30, 논문수정일자:2012.01.19, 논문게재확정일자:2012.02.07 김상헌, 고석주: 경북대학교
모바일 단말 환경에서 웹브라우저의 로딩속도 개선 기법
Loading Speed Improvement of Web Browsers on Mobile Devices
김 상 헌 ∙ 고 석 주
Sang-Heon Kim ∙ Seok-Joo Koh
최근 무선 인터넷 서비스의 활성화와 함께 모바일 환경에서 브라우저의 사용이 급증하고 있으며 모바일 사용자들 은 PC 수준의 품질을 요구하고 있다. 이에 따라 모바일 웹브라우저도 WAP 방식이 아닌 풀브라우징(full browsing) 방식으로 전환되고 있다. 하지만 모바일 단말 환경에서 웹브라우저의 성능에는 많은 제약사항이 존재하며 부족한 메 모리, 저사양의 CPU, 낮은 네트워크 속도, 그리고 브라우저의 엔진 문제 등으로 인해 여전히 사용자들의 브라우저 로 딩에 대한 체감속도는 낮은 편이다. 본 논문에서는 저사양 휴대 단말 환경에서의 브라우저 로딩속도를 개선할 수 있는 방안을 제시한다. 제안방식에서는 텍스트와 이미지 등 데이터 타입을 분류하여 부하가 적게 걸리는 텍스트 레이아웃 을 먼저 보여줌으로써 사용자의 체감속도를 향상시키고 아울러 이미지가 커서 렌더링(rendering) 시간이 오래 걸리는 경우 이미지를 축소하거나 화질을 낮추는 방식으로 렌더링 부하를 줄여서 페이지 로딩시간을 단축시키는 방법을 사용 한다. 실험결과, 제안 기법을 사용하는 경우 현재 사용하는 방법에 비해 이미지가 적은 Web 페이지의 경우 1st
drawing 77.04%, full drawing 5.47%, 이미지가 많은 페이지의 경우 26.32%의 로딩시간을 단축시킬 수 있음을 확 인하였다.
주제어: 모바일, 웹브라우저, 로딩속도, 성능 개선
With the development of wireless technology, the use of Web browser in the mobile environment has been increasing. In particular, the usage of Web browser continues to increase in Tablet PC and mobile phones as well as home appliances. Mobile users have been demanding the performance of full browser such as PC, instead of WAP browser. However, it still takes a long time to load the web pages in mobile devises, due to many factors such as small memory, low-level CPU and network bandwidth, and the Web browser engines. In this paper, we propose a scheme of improving the loading speed of Web browsers on mobile devices. In the proposed scheme, the speed of loading of Web documents can be improved by classifying the Web contents into low-load data and high-load data and by loading the low-load data first. In addition, the loading speed can also be improved by converting high-load image contents into low-load images. From the experimental results, we see that the proposed scheme can reduce the loading speed of Web contents by 77.04% for the 1stdrawing,
5.47% for the full drawing, and 26.32% for a document with many images, compared to the current method. Keywords: Mobile, Web browser, Loading speed, Performance improvement
키고 아울러 이미지가 커서 렌더링시간이 오래 걸리는 경우 사업자의 Proxy를 사용하는 실제 망인 경우 저사 양 User Agent(이하 UA)로 변경하여 사업자 서버로부 터 작은 이미지를 받고 일반 사이트인 경우 이미지를 축 소하거나 화질을 낮추는 방식으로 렌더링 부하를 줄여 서 페이지 로딩시간을 단축시키는 방법을 사용한다. 본 논문은 다음 순서로 구성된다. 먼저 II장에서는 기존 브라우저 로딩속도에 관한 연구 및 브라우저의 로 딩속도에 영향을 미치는 요소를 설명하고 III장에서는 브라우저 로딩속도에 대한 고속화 방안에 대해 설명한 다. IV장에서 제안하는 브라우저 로딩속도 방법을 소 개한다. V장에서 결론을 맺는다.
II
. 관련 연구
최근에는 웹 브라우징 성능을 측정하기 위하여 웹 브라우저의 개발을 위한 연구[1], 브라우저 기반의 네 트워크 시스템의 개선[2], 브라우저의 모바일 기기의 웹브라우징 성능 요인 분석[3], 웹브라우저의 성능향상 을 위해 브라우저를 병렬화 하는 것에 대한 연구[4], 웹 사이트의 종류에 따른 웹 페이지 구성요소에 대한 분류 를 수행한 연구[5], 다양한 모바일 웹브라우저의 기능 [6] 이나 성능[7]의 비교를 수행한 연구 등이 수행되었 다. 또한 브라우저의 고속화 방안[8]을 통해 각 모듈 별로 브라우저 성능을 비교 분석하여 최적화할 수 있는 연구들이 진행되어왔다. 일반적인 브라우저의 성능에 대해 네트워크적인 연구 개선 효과와 브라우저의 엔진 성능에 대한 연구가 병행되어 왔으나 실제 저사양 단말 의 제한적인 환경에서 영향을 주는 요소에 대한 연구는 부족한 실정이다. 또한 실제 사업자망에서 네트워크 성 능에 영향을 받으며 테스트 하기란 현실적으로 많은 어 려움이 있다. 먼저 브라우저의 로딩속도에 영향을 미치는 요소를 살펴보면 다음과 같다. 현재 고사양의 휴대단말기들에 탑재된 브라우저의 경우 성능 비교시 자바 스크립트를 반드시 테스트하고 그 결과를 매우 중요시 여긴다. 실제 CSS나 HTML 페이지를 화면에 drawing 하는 것은 브 라우저 로딩속도에 많은 영향을 주지는 않는다. 이미지 가 많고 렌더링이 복잡하며 무거운 자바스크립트로 구성 된 큰 페이지를 로딩할 경우 저사양 휴대단말기에서는 CPU의 많은 부하와 함께 로딩시 많은 시간이 걸리게 된 다. 또한 네트워크의 불안전한 요소로 인해 지연시간이 발생할 경우 더욱더 로딩시간이 늦어지게 된다. 브라우저별로 렌더링 방식의 차이가 있지만 일반적 으로 단말은 서버에 HTTP layer의 GET/POST로 데 이터를 요청하게 되며 서버로부터 HTML 텍스트, 자바 스크립트, CSS, 이미지 등을 TCP Layer를 통해 전송 받게 되며 전송이 완료되면 서버로부터 200OK를 응답 으로 전송받게 된다. 이 데이터를 이용하여 브라우저I
. 서 론
모바일 환경에서 브라우저의 사용이 많아지게 되면 서 모바일 단말기에 탑재되는 브라우저의 성능 또한 중 요해지고 있다. 사용자들은 PC처럼‘풀브라우징’성능 을 갖는 브라우저를 요구하게 되었으며 모바일 환경에 서 브라우저는 요구되는 성능을 제공하기 위해 많은 진 화를 거듭하고 있다. 기술적인 측면에서 보면 브라우저 는 크게 웹브라우저와 왑(WAP)브라우저로 나뉠 수 있 다. 웹브라우저는 웹 서버와 자료를 주고 받기위해 HTTP 프로토콜[8]을 사용하는 클라이언트를 총칭하 며 왑브라우저는 웹 서버와 자료를 주고 받기위해 WAP 프로토콜을 사용하는 클라이언트를 총칭한다. 일반적으로 PC에서 사용하는 Internet Explorer, 구글 크롬, 오페라, 파이어폭스, 모질라 등이 대표적인 웹브 라우저이며 단순히 웹브라우저의 기능 뿐만 아니라 FTP client나 Mail box등의 기능까지도 포함하는 등 그 규모가 점차 커지고 있는 추세이다. 현재는 HTML 4.01에서 HTML 5가 지원되면서 더욱더 다양한 기능 들을 지원하게 되었다.저사양 무선 휴대단말기에서 일반적으로 사용하는 브 라우저는 Access社의 Netfront, Openwave, Opera, Nokia web, Safari, Obigo 브라우저 등을 들 수 있다. 각각의 독립적인 렌더링(rendering) 엔진을 가지고 있으 며 특화된 기능을 지원하고 있다. 저사양 피쳐폰의 모바 일 환경은 제한된 메모리(1Gx512MB, 512x256MB 등), 작은 크기의 LCD Resolution(128x160, 240x400등), 낮은 클럭을 갖는 ARM7, ARM9, ARM11의 CPU, 제한된 성능을 갖는 모바일용 브라우 저 등 그 특수성 때문에 WEB 대신 규격을 축소한 WAP 규격을 이용해왔다. WAP1.0은 HTML보다 좀 더 적은 태그를 지원하는 WML 파일을 이용하며 WAP Gateway를 통해 이를 다시 WBXML 파일로 변환하여 송수신한다. 하지만 점차 휴대폰 기능이 발전하고 사용 자들의 요구가 늘어나고 있으며 WAP 환경도 진화되어 현재는 WAP2.0을 지원하며 HTTP 프로토콜을 함께 사용할 수 있게 되었다. 현재 모바일 환경에서는 WAP 브라우징이 아닌 웹브라우징 능력을 갖춘 브라우저가 요구되고 있다. 하지만 저사양 모바일 환경에서 브라우저는 웹 페이 지를 로딩할 때 제한된 메모리, 낮은 속도의 CPU 등으 로 인해 많은 문제가 발생하게 되었으며 그 중 브라우저 속도에 대해 가장 큰 이슈가 현재 부각되고 있다. 이는 저사양 모바일 브라우저의 활성화를 가로막는 요인이 되고 있다. 이를 해결하기 위해 다양한 연구가 진행되 고 있으며 본 논문에서는 저사양 브라우저의 로딩 알고 리즘을 변환하여 로딩속도를 개선할 수 있는 방안을 제 시하고자 한다. 제안방식에서는 텍스트와 이미지 등 데 이터 타입을 분류하여 부하가 적게 걸리는 텍스트 레이 아웃을 먼저 보여줌으로써 사용자의 체감속도를 향상시
이가 발생됨을 알 수 있다. 자바스크립트를 Off 할 경 우 휴대단말에서는 서버에 GET으로 자바스크립트 데 이터를 요청을 하지 않게 되며 이는 곧 패킷전송이 발생 되지 않는 것을 의미한다. 결국 패킷전송시간과 자바스 크립트로 인해 화면 렌더링에 필요한 계산 시간이 발생 하지 않게 되므로 브라우저 로딩속도에 영향을 주게 되 는 것이다. 2. LCD Resolution 저사양 피처폰의 경우 LCD Resolution은 일반적으 로 128x160, 176x220, 240x320, 240x400 등의 사 이즈를 가진다. 물론 더 큰 사이즈의 LCD Resolution 이 있을 수 있지만 보통 더 큰 사이즈의 경우 고가의 단 말기로 사용된다. 무선 휴대단말에서 브라우저를 사용하기 위해서는 Profile이라는 네트워크 세팅값이 필요하다. 일반적으 로 사용자는 이 값을 알 필요가 없으며 휴대단말에서 자 동으로 설정되어 있다. 특별한 경우에 이 값을 수동으 로 설정하게 되는데 보통 국가 이동이나 로밍 (roaming)을 할 경우 사업자 서버에서 OMA CP 메시 지를 통해 사용자에게 알려준다. 이 값들 중 Proxy라 값이 있으며 이는 사업자의 고유 IP를 의미한다. 이 Proxy를 사용하는 사업자 서버의 경우 User Agent 정 보를 확인하여 단말에 맞는 컨텐츠를 제공하기도 하고 모바일 사이트를 Redirect 하여 자동으로 URL을 Web 페이지에서 WAP 페이로 변환하여 접속하기도 한다. 사이트의 서버에서 URL을 변경하는 경우도 있으며 보 엔진은 파싱(parsing)을 하게 되며 파싱된 데이터로 브 라우저 엔진에서는 렌더링에 필요한 요소들에 대해 계 산을 하게 된다. 계산이 끝나면 화면에 렌더링하게 되 는데 이런 일련의 과정에서 단말은 많은 부하가 발생하 며 휴대단말은 마치 화면이 정지한 것 같은 현상을 사용 자에게 보여준다. 또한 망 상태가 좋지 않은 지역인 경 우 TCP를 통한 데이터 전송이 원활하지 않아 데이터 지연 현상이 발생하게 되며 심할 경우 Request time out 등의 서버 에러가 발생하여 브라우저 로딩을 하지 못하고 강제로 종료하는 경우도 발생한다. 1. 자바스크립트(JavaScript) 자바 스크립트는 브라우저의 로딩속도에 많은 영향 을 주게 된다. 특히 화면 렌더링을 위해서 많은 양의 계 산이 필요하게 된다. 그림 1은 Access社의 Netfront 3.5와 Netfront 4.0의 브라우저 엔진에 사용되는 자바 스크립트 개선에 대해 보여주고 있다. 자바스크립트 엔 진을 개선함으로써 기존 Netfront 3.5 브라우저 대비 20배 빠른 향상된 속도를 명시하고 있다[9]. 또한 prototype.js, dojo, jQuery, ExtJS, Firebug Lite 등 을 추가로 지원하여 성능을 향상시켰다. 그림 1과 같이 브라우저 성능에 대해 자바스크립트 가 차지하는 비중이 높으며 근본적으로 자바스크립트를 On/Off 하여 그림 2와 같이 결과를 확인해 봄으로써 실 제 자바스크립트가 브라우저 성능에 미치는 영향을 알 수 있다. 자바스크립트 유무로 인해 52.92%의 로딩속도 차
JavaScriptTMEngine Execution Speed Comparison NetFront Browser v4.0 Versus NetFront Browser v3.5
(SunSpider Benchmark 0.9)
(2010/01) Shorter bar is better
2 200xx T
Tiimmeess FFaasstteerr
43,245 msec NetFront Browser v3.5
JavaScript Engine
그림 1. Access社 Netfront 브라우저의 JavaScript 성능 향상 2,144 msec NetFront Browser v4.0 JavaScript Engine 50000 45000 40000 35000 30000 25000 20000 15000 10000 5000 (msec)0
String을 분석하면 그림 3과 같다.
http://wap.samsungmobile.com/uaprof/GT-I9000.xml 에서 Samsung I9000의 User Agent Profile의 값을 확인할 수 있다. UA 뿐만 아니라 User Agent Profile(이하 UAProf)값 또한 중요하다. 통 Proxy를 거쳐 휴대단말에서 www.naver.com,
www.samsung.com 이라는 Web 사이트를 접속할 경우 UA의 긴 내용 중에 몇개의 키워드를 찾아내서 WAP 페 이지로 redirect를 하게 된다. 즉 m.naver.com으로 URL이 변경되어 자동으로 접속되게 된다. User Agent
Site: http://www.go.com Browser: NetFront 4 Browser
50 45 40 35 30 25 20 15 10 5 0 로딩시간(초) JavaScript OFF JavaScript ON 그림 2. 자바스크립트 On/Off를 통해 성능 측정 결과
그림 3. Samsung I9000 User Agent 분석
1 2 3 4 5 6 7 8 9 10 11
17.44 17.41 23.68 16.65 18.22 20.32 21.99 17.99 19.21 21.23 19.41 46.47 40.48 40.86 38.69 39.22 41.23 43.99 38.21 38.92 44.32 41.24
E250(128x160), E2652(240x320), S8300(240x400), S8500(480x800)으로 User Agent 및 UA Profile을 변경하면 사업자 proxy를 거쳐 서버에서 모델의 LCD Resolution에 맞는 컨텐츠를 휴대단말에 전송하게 된 다. 즉 사업자 페이지는 User Agent에 따라 페이지를 동적으로 재구성하여 휴대단말기에 전송하게 된다. 그 림 4와 같이 UA/UAProf를 변경함으로써 서버는 휴대 단말의 LCD에 맞는 컨텐츠(이미지, CSS, 자바스크립 트, HTML, 스타일 등)를 전송하게 된다 그림 4와 같이 UA/UAProf를 변경했을 때 사업자 UAProf은 모바일 디바이스에 대한 capturing
capability(Vendor, Model, Screensize, Multimedia Capabilities, Character Set support, etc)와 preference information의 정보를 가지고 있다. 표 1 은 모델별 LCD Resolution, User Agent, User Agent Profile을 나타낸다. 인도에는 대략 260개의 공식적인 사업자와 비공식적 인 사업자를 합쳐 대략 600여개의 사업자가 존재한다. 인도의 여러 사업자중 가장 많이 사용하는 Airtel 사업자 의 홈페이지 사이트(http://live.airtelworld.com)에 대해 Specifications Resolution: 128 x 160 pixels, 2.0 inches
User Agent: SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/ CLDC-1.1 UP.Browser/6.2.3.3.c.1.101(GUI) MMP/2.0 Resolution: 240 x 320 pixels, 2.6 inches
User Aget: SAMSUNG-GT-E2652/1.0 NetFront/3.5 Profile/MIDP-2.0 Configuration/CLDC-1.1
Resolution: 220 x 176 pixels, 2.2 inches
User Aget: SAMSUNG-GT-B3210/1.0 Netfront/3.5 Profile/MIDP-2.0 Configuration/CLDC-1.1
Resolution: 240 x 400 pixels, 2.8 inches
User Agent: SAMSUNG-S8300/1.0 SHP/VPP/R5 NetFront/3.5 NexPlayer/2.9.1 SMM-MMS/1.2.0 profile/MIDP-2.1 configuration/CLDC-1.1 Resolution: 480 x 800 pixels, 3.3 inches
User Agent: Mozilla/5.0 (Linux; U; Android 2.1-update1; ar-ae; GT-I9000 Build/ECLAIR) AppleWebKit/530.17(KHTML, like Gecko) Version/4.0 Mobile Safari/530.1
Resolution: 480 x 800 pixels, 4.0 inches
User Agent: Mozilla/5.0(Linux; U; Android 2.1-update1; ar-ae; GT-I9000 Build/ECLAIR) AppleWebKit/530.17(KHTML, like Gecko) Version/4.0 Mobile Safari/530.1
Model Samsung E250 Samsung E2652 Samsung B3210 Samsung S8300 Samsung S8500 Samsung S9100
표 1. 모델별 LCD Resolution, UA(User Agent), UAProf(User Agent Profile)
Samsung E250 UA/UAprofile (size : 128x160)
그림 4. UA/UAProf 의한 변환된 사업자 페이지
Samsung E2652 UA/UAprofile (size : 240x320)
Samsung S8300 UA/UAprofile (size : 240x400)
Samsung S8500 UA/UAprofile (size : 480x800)
이 다르게 구성된다.
UA/UAProf가 로딩속도에 얼마나 영향을 주는지 Airtel 사업자 페이지로 인도 New Delhi에서 확인하였 다. 그림 5와 같이 Samsung E250, E2652, I9000은 컨 텐츠 구성이 각각 다르기 때문에 서버로부터 전송되는 패 킷 데이터 차이로 인해 로딩속도가 다르게 나타나는 결과 를 보인다. 즉 테스트 결과를 바탕으로 LCD resolution 에 따라 브라우저 로딩속도가 다름을 알 수 있다. 서버로부터 전송되는 화면이 달라진다. LCD resolution에 따라 화면에 지원되는 컨텐츠의 모양, 페이지 구성, 이미지 사이즈가 모두 변경되게 된 다. 서버에서 내려주는 컨텐츠는 데이터 양과 페이지 구성이 다르기 때문에 브라우저 로딩속도에 영향을 주 게 된다. Samsung E250의 경우 WBXML의 압축된 형식으로 전송이 되며 로딩시간으로 인해 자바스크립트 가 컨텐츠에 포함되지 않는다. 반면 Samsung I9000 의 경우 이미지, 자바스크립트, HTML의 레이아웃 등 Site : http://live.airtelworld.com Browser : Netfront Browser
25 20 15 10 5 0 로딩시간(초) Samsung E250 (size : 128x160) Samsung E2652 (size : 240x320) Samsung I9000 (size : 480x800) 그림 5. UA/UAProf 사업자 페이지 로딩속도 측정 그림 6. Airtel 사업자 페이지에 대한 이미지 On/Off 레이아웃 화면 1 2 3 4 5 6 7 8 9 10 7.81 7.23 8.65 7.07 8.01 7.99 7.23 8.12 7.01 7.72 14.22 10.13 11.54 10.31 12.31 13.21 12.11 10.23 11.33 12.89 22.51 19.82 18.31 19.86 20.12 18.99 21.32 18.12 19.32 18.27
3. Display Image 트래픽에 가장 많은 영향을 미치는 것이 페이지에 함 께 포함된 이미지들이다. 그림 6과 같이 Airtel 사업자 페 이지에는 여러개의 이미지들이 포함되어 있다. 이미지 On/Off를 함으로써 레이아웃의 차이를 알 수 있다 이미지가 로딩속도에 얼마큼 영향을 주는지 확인하 기 위해 Airtel 사업자 페이지로 인도 New Delhi에서 확인해 보았다. 그림 7의 이미지 On/Off를 했을 경우 이미지가 로딩속도에 영향을 미치는 것을 알 수 있다. 그림 7에서와 같이 이미지 Off를 할 경우 On 할 경 우 대비 평균 61.22%의 속도 차이가 발생함을 알 수 있다. 이미지의 경우 페이지에 포함된 경우와 Link 형 식의 inline 이미지가 있다. 다수의 이미지가 포함된 큰 페이지의 경우 이미지 전송시 패킷전송에 대해 많은 시 간을 차지하게 되고 이는 곧 브라우저 로딩속도에 영향 을 주게 된다. 또한 큰 이미지가 포함된 경우는 오랜 로 딩시간과 전송된 이미지를 화면에 렌더링할 때의 시간 으로 인해 추가적인 로딩 지연 현상이 발생되곤 한다.
III
. 브라우저 로딩속도 고속화 방안
본 논문에서는 브라우저 로딩시 발생하는 로딩 지연 을 개선할 수 있는 방안을 제시하고자 한다. 구글과 같 은 작은 크기의 페이지를 로딩할 경우 저사양 휴대단말 에서는 페이지 로딩에 크게 문제가 되지 않았으나 WEB 페이지인 큰 사이즈의 www.go.com와 같이 CSS, 자바스크립트, 이미지 등이 복합적으로 구성되어 있는 경우 단말의 브라우저는 페이지를 로딩하는데 많 은 부하가 걸리며 로딩시간이 많이 소요된다. 이때 브 라우저는 부하로 인해 폰의 동작이 심하게 느려지면서 입력이 안되는 현상이 발생하기도 하고 심지어 단말에 서는 부족한 메모리로 인해 사용자에게“Not enough memory”라는 팝업창을 보여주고 브라우저 로딩을 강 제로 중지하기도 한다.또한 특정 사업자(Vodafone, Orange, T-Mobile, 허치슨 등)에서는 브라우저의 로딩시간에 있어 특정 페 이지를 로드하는데 최소한의 제한시간을 두고 사업자의 요구사항에 맞춰줄 것을 요구하기도 하지만 이는 제한 적인 하드웨어 사양과 네트워크로 인해 요구사항을 맞 추기가 어려운 것이 현실이다. 속도에 영향을 미치는 여러가지 모듈 중 이미지는 많은 부분 로딩시간에 영향을 준다. 이미지의 사이즈가 큰 경우에 데이터의 로딩이 완료되고 화면에 그리기 위 해서는 많은 용량의 메모리가 필요하다. 사용 가능한 메모리만큼 화면에 표시하고 기다렸다가 다시 그만큼을 그리는 반복동작을 해야 한다. 예를들어 1100 x 759 사이즈의 WBMP 파일을 디코딩할 경우 Temp Buffer 로 브라우저에 할당된 메모리가 사용된다. 브라우저에 서 점유하고 있는 메모리를 제외한 상태에서 해당 이미 지 디코딩 시에 필요한 가용 메모리를 분석해 사용한다. 기존에는 큰 사이즈의 이미지 데이터로 인해 패킷 전송시 트래픽에 부하가 걸려 브라우저 로딩시간에 영 향을 주는 문제가 있다. WI-FI나 네트워크 상태가 좋 은 경우에 대해서는 큰 문제가 되지 않으나 네트워크 상 태가 좋지 않을 경우 성능에 아주 큰 영향을 주게 된다. 실제 망에서는 네트워크 상태가 좋지 않은 경우가 빈번 하게 발생한다. 본 논문에서는 웹브라우저의 로딩속도 개선을 위해 Site : http://live.airtelworld.com
Browser : Netfront 4 Browser 25 20 15 10 5 0 로딩시간(초) Image OFF Image ON 그림 7. 이미지 On/Off를 통해 성능 측정 결과 1 2 3 4 7.55 19.86 5 7.29 20.12 6 8.11 18.99 7 7.33 21.32 8 7.87 18.12 9 8.01 19.32 10 7.12 18.27 7.73 8.54 19.82 6.71 18.31 22.51
두가지 방법을 제안한다. 첫째, 사용자에게 HTML로 구성된 텍스트 레이아웃을 먼저 보여줌으로써 사용자가 느끼는 체감속도를 향상시키고 화면 렌더링은 화면이 drawing 된 후 재구성한다. 둘째, 이미지가 커서 렌더 링시간이 오래 걸리는 경우 이미지를 축소하거나 화질 을 낮추는 방식으로 렌더링 부하를 줄여서 페이지 로딩 시간을 단축시키는 방법을 제시한다. 사업자 사이트의 경우 이미지의 크기를 판단하여 저사양 단말의 User Agent를 보냄으로써 사업자 서버로부터 작은 이미지를 전송받아 부하를 줄이고 일반 Web 페이지의 경우 이미 지가 일정 개수 이상 큰 페이지가 있을 경우 텍스트는 그대로 전송받고 부하가 많이 걸리는 이미지는 저사양 이미지로 변경하여 큰 페이지 로딩시에 시간을 단축하 여 브라우저 로딩시간을 개선하고자 한다. 이미지 개수 가 지정한 개수보다 적어 이미 원본 데이터를 전송받았 는데 이미지 크기가 커서 페이지 렌더링에 시간이 많이 걸리는 경우 이미지를 축소하거나 이미지의 질을 낮추 어 화면 렌더링시 부하를 줄여 페이지 로딩시간을 단축 하여 속도 개선 효과를 얻는다. 그림 8은 제안하는 렌더링 방법 및 이미지 변환 과 정을 보여준다. ① 일반적으로 웹페이지의 경우 HTML, CSS, 자바스 크립트, 이미지 등으로 페이지가 구성된다. 단말은 HTTP의 GET/POST method를 통해 서버에 데이 터를 요청하게 되고 서버는 최초 데이터로 일반적으 로 HTML로 구성된 테스트를 전송하게 된다. ② 페이지 로딩시 Header의 정보와 단말에 저장된 Cache를 통해 페이지 유무를 파악한다. 이는 불필 요한 패킷 데이터 전송을 방지하고 사용자로 하여금 빠른 화면을 보여주기 위한 것이다. 만약 Cache에 페이지 정보가 존재하고 expired되지 않았다면 화면 에 페이지를 출력한다. HTTP Header에서 Last Modified Time 과 Max-age 의 값을 구분하여 페이 지가 expired 되었는지 판단하여 페이지 reload 유 무를 판단한다. ③ Cache에 페이지가 존재하지 않는다면 Server로부 터 HTML page의 정보를 요청한다. ④ 서버로부터 전송된 문서는 HTML 파일 형식이며 HTML 파일에 대한 토큰화(tokenize) 및 파싱을 페 페이이지지 요요청청 Set URL
Send request Pager reload Web page displayed
Load HTML L Looaadd JJaavvaaSSccrriipptt LLooaadd CCSSSS SShheeeett Parse CSS sheet CSS DOM L Looaadd IImmaaggee 기존 이미지 사용 저사양 이미지로 변환 Server로 부터 Data 전송 Image , javaScript Off
HTML Dispaly Image , javaScript On page Rendering W Weebb ppaaggee DDiissppllaayyeedd 그림 8. 제안된 브라우저 로딩 알고리즘 순서도 If Image, javaScript on? Image 개수가 적은가? If proxyuse? 저사양 UA/UAP 요청 (Multiple User Agent)
저사양 이미지 사용 If proxy use? Image 사이즈가 작은가? H HTTMMLL ppaarrsseerr
�Image num: nCount
�Image size (width,Height) �JavaScript check If Cache ? If expired? (1) (2) (4) (9) (3) (6) (8) (7) (5) (11) (10) D DOOMM R Reennddeerr ttrreeee HTML Layout Style update SVG CSS Yes Yes Yes Yes Yes Yes No No No No No No
휴대폰 단말의 UA/UAProf로 변환하여 서버에서 저사양 이미지를 전송하도록 유도한다. 이미지 개 수가 작아서 휴대폰 단말로 전송했는데 이미지의 크 기가 큰 경우 일정 사이즈가 넘은 이미지에 대해서 는 내부 디코딩을 통해 이미지를 축소하여 화면에 보여 주는데 걸리는 시간을 단축한다. 페이지에 큰 이미지가 존재할 경우 상당히 많은 부하가 발생됨으 로 그 이미지를 최소한의 사이즈로 축소하게 된다. ⑨ HTML 파싱 단계를 걸쳐 HTML 태그, 내용 등과 같 은 HTML 구 성 요 소 로 분 리 되 어
DOM(Document Object Mode) 트리 형태의 자료 구조가 생성된다.
⑩ DOM 트리와 함께 render tree가 생성된다. 렌더링 에 필요한 다양한 컨텐츠에 대한 처리를 진행하여 자료구조의 갱신(layout, style update)을 수행하게 된다. ⑪ 화면 재구성을 통해 페이지를 화면에 drawing하게 된다.
IV
. 실험 및 성능분석
1. 실험 환경 본 논문에서 제안하는 기법의 성능 실험을 위해 인 도 New Delhi에서 Airtel 사업자 페이지와 표 2와 같 은 성능의 휴대단말기를 사용하였다. 2. 로딩시간 측정 표 3과 4는 표 2의 휴대단말기들을 사용하여 수행한다. HTML의 페이지에는 레이아웃 정보와 페이지내의 CSS, 자바스크립트 유무, 이미지 크기, 이미지 개수 등의 정보가 포함된다. 지정한 개수 이 상과 지정한 크기 이상이 될 경우 이미지의 크기 및 개수 정보는 별도의 DB에 저장하여 이미지 데이터 요청시 활용한다. ⑤ 자바스크립트와 이미지의 플래그를 파악하여 우선적 으로 HTML 페이지를 렌더링하여 사용자게 보여줌 으로써 사용자의 체감속도를 높일 수 있다. ⑥ HTML 텍스트 페이지를 화면에 보여주고 자바스크립 트의 정보를 서버에 요청하여 데이터를 전송받는다. ⑦ HTML 파싱을 수행 중에 발견되는 추가적인HTML, CSS(Cascade Style Sheet), 자바스크립 트, 이미지 등에 대해 Server에 데이터 정보를 요청 하게 되는데 다운로드가 되지 않은 경우 서버에 다 시 요청하게 된다. CSS 파일의 경우 CSS 문서 파 일을 통해 스타일 정보가 추출되어 CSS DOM 구조 를 통해 컨텐츠 정보를 활용하게 된다. ⑧ 단말은 Server부터 이미지를 전송받게 되는데 이미 지로 인해 화면의 렌더링에 영향을 주게 된다. 이미 지의 개수가 적을 경우 이미지 사이즈가 작은 경우 기존과 동일하게 서버에 이미지를 요청하고 서버로 부터 이미지를 전송받는다. 이미지 개수가 많고 사 업자 proxy를 사용하여 사업자 홈페이지에 접속하 는 경 우 저 사 양 휴 대 폰 단 말 의 UA(User Agent)/UAprof(User Agent Profile)를 사용하여 저사양 단말의 이미지를 전송받는다. 또한 이미지 개수가 적고 이미지 사이즈가 클 경우 사업자 proxy 를 확인하고 일반적인 사이트인 경우 저사양 이미지 로 변환하여 렌던링에 대한 CPU 부하를 줄인다. 만약 이미지 크기가 지정한 값보다 클 경우 저사양 휴대단말기 1 Infineon GPRS Class 10(4+1/3+2slots), 32~48kbps EDGE Class 10, 236.8kbps 3G No WLAN No
BluetoothYes, v2.1 with A2DP Infrared portNo 2G Network GSM 900/1800/1900-SIM 1 GSM 900/1800/1900-SIM 2 240 x 320 pixels, 2.6inch Netfront Browser WAP2.0/XHTML,HTML HTTP, OTA provisioning supported
WAP Push service supported
휴대단말기 2 Qualcomm GPRS/EDGE class 12,
HSDPA 7.2Mbps WLAN No
BluetoothYes, v2.1 with A2DP Infrared portNo GSM 850/900/1800/1900MHz,
UMTS 900/2100MHz
240 x 320 pixels2,8-inch TFT, QVGA resolution WebKit Browser 0.8
WAP2.0/XHTML,HTML HTTP, OTA provisioning supported
WAP Push service supported Category Base band RF Band LCD Type WAP Data 표 2. 무선 휴대단말기 사양
www.go.com 페이지를 대상으로 제안 기법을 적용한 페이지 로딩시간을 보여준다. 휴대단말기 종류에 관계 없이 제안 기법을 통해 페이지 로딩시간이 단축됨을 알 수 있다. 그림 9는 Netfront 브라우저를 사용하는 경우 1st drawing에 대한 로딩속도를 나타내고 있다. 그림에서 정리된 바와 같이 1st drawing시 기존 방식에 비해 제 안방식 후가 평균속도로 -35.73초가 빨라졌음을 알 수 있다. 즉 www.go.com의 사용자는 최초 브라우저 화 면을 평균 10초때에 볼 수 있다. 즉 사용자가 느끼는 체감속도는 많은 개선 효과를 볼 수 있다. 그림 10은 Netfront 브라우저를 사용하는 경우 full drawing시 측정된 시간을 보여준다. full drawing 인 경우 -2.52초를 보인다. 이는 최초 drawing 후 파싱, 이미지 전송, 화면 rendering, 자바스크립트, 스타일등 여러가지 화면구성에 필요한 처리를 하고 성능에 영향 을 주는 부분들에 대해 처리를 하면서 기존 대비 향상됨 을 알 수 있다. 표 5는 표 3과 표 4의 실험결과를 토대로 제안방식 의 페이지 로딩시간 감소율을 정리한 결과이다. 최초 화면 로딩이 기존 대비 1st drawing시 78.31%, 28.22%의 속도 증가 현상을 보였으나 전체 화면 로딩 full drawing 44.30 46.62 45.55 47.16 46.99 47.17 47.23 45.34 45.31 45.43 46.11 1st drawing 10.47 9.63 10.89 9.67 9.59 9.29 9.54 9.98 10.01 9.92 9.90 full drawing 43.55 44.45 43.99 43.12 45.88 43.23 41.88 42.32 44.33 43.12 43.59 1st drawing -33.35 -36.51 -34.18 -37.01 -36.92 -37.40 -37.21 -34.88 -34.82 -35.03 -35.73 full drawing -0.75 -2.17 -1.56 -4.04 -1.11 -3.94 -5.35 -3.02 -0.98 -2.31 -2.52 1 2 3 4 5 6 7 8 9 10 평균 1st drawing 43.82 46.14 45.07 46.68 46.51 46.69 46.75 44.86 44.83 44.95 45.63 표 3. 제안방식을 통한 페이지 로딩시간 측정 (단위: 초) 측정: 휴대 단말기 2 Site: http://www.go.com Browser: WebKit Browser 0.8 측정: 휴대단말기 1
Site: http://www.go.com Browser: Netfront 4 Browser
기존 방식 제안방식 차이 full drawing 35.09 32.86 36.68 33.45 34.15 35.56 39.44 35.1 34.15 36.98 35.35 1st drawing 9.23 9.87 10.4 9.78 10.77 9.45 9.32 8.45 11.2 9.84 9.83 full drawing 32.01 30.11 31.8 30.47 31.17 32.15 34.65 31.77 31.45 34.55 32.01 1st drawing -2.22 -3.56 -2.16 -5.81 -3.67 -4.09 -7.13 -5.00 -1.36 -5.26 -4.03 full drawing -3.08 -2.75 -4.88 -2.98 -2.98 -3.41 -4.79 -3.33 -2.70 -2.43 -3.33 1 2 3 4 5 6 7 8 9 10 AVR 1st drawing 11.45 13.43 12.56 15.59 14.44 13.54 16.45 13.45 12.56 15.1 13.86 표 4. 제안방식을 통한 페이지 로딩시간 측정 (단위: 초) 기존 방식 제안방식 차이
웹 사이트들은 영향을 받지 않아 두개의 UA/UAProf로 인해 저품질의 이미지 변환에 대한 알고리즘이 적용되 지 않아 full drawing에 대한 속도에 영향을 주지 못하 였다. 반면 큰 이미지나 일정 수준이상의 이미지를 로 딩한 경우 화면에 drawing 할 경우 크기를 축소하고 저 품질로 변환하는 경우 렌더링에 영향을 줌을 알 수 있 다. 그림 11은 http://m.midb.com의 PC Browser 화 면(a)과 기존방식(b)에서 보여주는 화면, 제안방식(c) 에서 보여주는 단말의 화면을 보여준다. 그림 11에서처럼 PC로 접속하는 경우 페이지내에 많은 이미지가 존재한다. 이는 페이지를 로딩을 할 때 각각의 이미지를 모두 서버로부터 요청하게 되며 이때 이미지가 클 경우 화면에 렌더링할 때 로딩속도에 영향 을 주게 된다. 일정 개수 이미지가 존재하고 지정한 사 이즈보다 크게 된다면 device에서는 이미지를 저품질, 인 full drawing에 대해서는 5.47%, 9.38%의 개선 현 상을 보였다. 이는 1stdrawing시 부하가 걸리는 자바 스크립트나 일반 렌더링이 아닌 단순히 레이아웃을 보 여줌으로써 사용자의 체감속도 현상이 발생한 것이다. 하지만 full drawing을 할 경우 전체 화면을 구성하고 drawing하기 위해 자바스크립트, 이미지, CSS 등을 재 구성 함으로써 속도 차이가 1st drawing에 비해 다소 크게 개선되지는 않았지만 기존 방식에 비해서는 5.47%, 9.38% 개선되었음을 알 수 있다. 사업자 페이지가 아닌 일반 사이트로 UA/UAProf 의 값에 영향을 받거나 받지 않을 수도 있다. 이는 생산 되는 모든 단말의 UA/UAProf를 모든 사이트가 실시간 으로 등록하기란 사실상 불가능하기 때문이다. 그렇기 때문에 일반적으로 사용되는 웹 페이지인 경우 LCD resolution에 영향을 받지 않도록 페이지를 구성하게 된다. 일부 사이트는 UA/UAProf에 영향을 받지만 일부 50.00 45.00 40.00 35.00 30.00 25.00 20.00 15.00 10.00 5.00 0.00 로딩시간(초) 1 1sstt ddrraawwiinngg 1 2 3 4 5 6 7 8 9 10 43.07 1st drawing(개선 전) 1st drawing(개선 후) 43.97 43.51 42.64 45.40 42.75 41.40 41.84 43.85 42.64 10.47 그림 9. 제안방식을 통한 1st drawing 로딩시간 측정(초) 9.63 10.89 9.67 9.59 9.29 9.54 9.58 10.01 9.92 48.00 47.00 46.00 45.00 44.00 43.00 42.00 41.00 40.00 39.00 로딩시간(초)
ffuullll ddrraawwiinngg
1 2 3 4 5 6 7 8 9 10 44.30 full drawing(개선 전) full drawing(개선 후) 46.62 45.55 47.16 46.99 47.17 47.23 45.34 45.31 45.43 43.55 그림 10. 제안방식을 통한 full drawing 로딩시간 측정(초) 44.45 43.99 43.12 45.88 43.23 41.88 42.32 42.33 43.12
그림 11. 이미지가 많은 페이지에 대한 제안방식 화면 (a)PC로 접속한 사이트 (b) 기존 방식 (c) 제안방식 full drawing 1.69 4.65 3.42 8.57 2.36 8.35 11.33 6.66 2.16 5.08 5.47 1st drawing 19.39 26.51 17.20 37.27 25.42 30.21 43.34 37.17 10.83 34.83 28.22 full drawing 8.78 8.37 13.30 8.91 8.73 9.59 12.15 9.49 7.91 6.57 9.38 1 2 3 4 5 6 7 8 9 10 평균 1st drawing 76.11 79.13 75.84 79.28 79.38 80.10 79.59 77.75 77.67 77.93 78.31 표 5. 제안방식을 통한 페이지 로딩시간 측정(%) 제안방식(휴대단말기 1) 제안방식(휴대단말기 2) 제안방식 30.59 29.12 32.22 31.54 31.76 29.45 28.45 30.77 34.45 29.98 30.83 차 이 7.94 7.34 8.46 11.90 5.37 9.53 6.11 5.68 6.67 12.14 8.11 % 20.61 20.13 20.80 27.39 14.46 24.45 17.68 15.58 16.22 28.82 20.83 1 2 3 4 5 6 7 8 9 10 평균 기존 방식 38.53 36.46 40.68 43.44 37.13 38.98 34.56 36.45 41.12 42.12 38.95 표 6. 제안방식을 통한 이미지가 많은 페이지의 full drawing 로딩시간 측정(초) 측정: 휴대단말기 1 Site: http://m.imdb.com Browser: Netfront 4 Browser
작은 사이즈의 이미지로 변환하게 된다. 표 6은 이미지가 많은 http://m.imdb.com 페이지 에 대해 제안방식을 적용 full drawing의 로딩시간을 나타낸다. 표 6에서 제안방식을 통해 full drawing시 평균 8.11초의 시간 차이가 발생하며 평균 20.83%의 개선 효과가 발생되었음을 알 수 있다.
V
. 결 론
본 논문에서는 저사양 휴대단말기의 웹브라우저 로딩 속도를 개선하기 위한 기법을 제안하였다. 이를 위해 휴 대단말 환경에서 브라우저 웹 페이지 로딩시 어떤 과정을 거치는지 알아보고 어느 모듈에서 부하가 걸리는지 문제 점을 찾아보았다. 분석을 통해 성능에 영향을 미치는 자 바스크립트 프로세싱, 이미지 렌더링, 이미지 사이즈 등 이 직접적으로 로딩시간에 영향을 준다는 것을 파악하였 다. 이를 토대로 본 논문에서는 텍스트와 이미지 등 데이 터 타입을 분류하여 부하가 적게 걸리는 텍스트 레이아웃 을 먼저 보여줌으로써 사용자의 체감속도를 향상시키고 아울러 이미지가 커서 렌더링시간이 오래 걸리는 경우 이 미지를 축소하거나 화질을 낮추는 방식으로 렌더링 부 하를 줄여서 페이지 로딩시간을 단축시키는 방법을 사 용하였다. 또한 UA/UAProf에 영향을 받는 페이지인 경우 실제 서버로부터 전송되는 이미지 패킷 데이터 용 량이 작아지기 때문에 속도 향상이 됨을 알 수 있었다. 한편 웹브라우저의 로딩속도는 본 논문에서 분석한 소프트웨어적인 요소 뿐만 아니라 브라우저 엔진(CSS, JavaScript, DOM, Image, Parser 등), CPU 성능, 네트워킹 프로토콜 등의 다양한 요소에 영향을 받는다. 향후 연구로서 하드웨어 및 다양한 요인에 대한 로딩속 도 개선방안 도출이 필요하다. 아울러 개방형 웹 플랫 폼 환경에서 다양한 이미지 축소 기법과 이에 대한 컴퓨 팅시간 및 렌더링시간에 대한 비교 분석도 함께 이루어 질 필요가 있다. 감사의글 본 논문은 한국연구재단의 기초연구사업(2011-0026529)과 정보통신산업진흥원의 대학 IT연구센터 지원사업(NIPA-2012-C1090-1221-0002) 및 방송통 신위원회의 산업원천기술개발사업(KCA-2011-10913-05004)의 연구결과로 수행되었음. [참고문헌] [1] 한선영, 김병학, 권민순, 박종훈, 송관호, "브라우저 개발을 위한 연구", 한국통신학회 학술대회 논문집, 제7권1호, 1997, pp. 114~128.[2] Jiann Hung Lin, et al., “Implement Browser-Based
Network Management System using Visibroker,”
Proceeding of Asia-Pacific Network Operations and Management Symposium, 1997
[3] 박기호, “모바일 기기의 웹브라우징 성능 요인 분석,” 정보과학회논문지: 컴퓨팅의 실제 및 레터, 제17 권 제2 호, 2011.
[4] C. G. Jones, et al., "Parallelizing the Web Browser,"
First USENIX Workshop on Hot Topics in Parallelism (HotPar09), March 2009.
[5] M. Somers and J. M. Paul, "Webpage-Based
Benchmarks for Mobile Device Design," 13th Asia and
South Pacific Design Automation Conference (ASP-DAC 2008), January 2008, pp.795-800.
[6] E. A. Hernandez, "War of the Mobile Browsers,"
IEEE Pervasive Computing, Vol. 8, No. 1, Jan. 2009,
pp. 82-85.
[7] J. Nielson, et al., "Bench marking Modern Web Browsers," IEEE HotWeb 2008, October 2008. [8] W3C의HTTP표준 관련 자료 모음,
http://www.3.org/Protocols
[9] Netfront Core Document, http://www.access-company.com
김 상 헌 (Sang-Heon Kim) 1997~2005: 동명정보대학교 컴퓨터공학과 학사 2005~현재: 삼성전자 무선사업부 2011~현재: 경북대학교 전자전기컴퓨터학부 석사과정 관심분야: 미래 인터넷, 모바일 Browser, WebKit, HTML5 E-mail: [email protected] 고 석 주 (Seok-Joo Koh) 1988~1992: KAIST 경영과학과 학사 1992~1994: KAIST 경영과학과 석사 1994~1998. 8: KAIST 산업공학과 박사 1998. 8~2004. 2: ETRI 표준연구센터 선임연구원 2004. 3~현재: 경북대학교 IT대학 컴퓨터학부 교수 2000~현재: ITU-T SG13 및 ISO/IEC JTC1/ SC6 Editor 관심분야: 미래 인터넷, 이동성 관리, SCTP, 멀티캐스트, 국제표준화 E-mail: [email protected]
