共用方式為

Internet Explorer 8 성능

  • 發行項

이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 또, 이 글 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경 될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오.

원본 : IE8 Performance (영어)

업데이트 일자: 2008 년 8 월 26 일

 

안녕하세요, Internet Explorer 8 성능 향상을 담당하고 있는 Christian Stockwell 입니다.

최근  각 브라우저 업체는 자사의 브라우저 성능이 「뛰어난 속도와 성능」, 「현존하는 웹 브라우저에서 가장 빠르고 강력」, 「모든 플랫폼에서 가장 빠른 웹 브라우저」라고 말합니다. 이러한 주장을 하는 것은  성능 측정 분석 방법이 제각각이고, 복잡하기 때문이라고 생각할 수 있습니다.

이 글은 Internet Explorer 가 최고 속도의 브라우저라는 주장 대열에 참여하는 것이 아니라,  Internet Explorer 8 의 각 기능이 어떻게 생산성을 향상시키는지에 대해  설명하고자 합니다.

제가 하는 말을  모두 믿으실 필요는 없습니다. Dean이 MIX08 에서 말한 대로 (영어), Google은 Internet Explorer 8 beta 1의 개선에 대해 언급했지만, 우리는 그 뒤에 Internet Explorer 8 을 보다 빠르게 만들었습니다.

「단지 JScript 성능 테스트에서는 2.5 배 향상된  경우도 있었습니다. Internet Explorer 7 과 비교하면 일반적인 Gmail 조작의 경우, 받은 편지함을 띄우는 데는 34%, 대화창을 여는 데는 45%, 스레드를 여는 데는 27%  향상되었습니다. 」

먼저  Internet Explorer 개발 팀이 성능에 대해 어떻게 생각하고 있는지 말하겠습니다. 그리고, 지금까지 Internet Explorer 8 의 성능에 관한 작업과 어떻게 하면 Internet Explorer 8 이 사용자와 개발자에서 보다 좋은 브라우저가 될지에 대해 논의합니다. 마지막으로 개발자가 보다 효율적으로 차세대가 뛰어난 사이트를 구축할 수 있도록 하기 위한 Internet Explorer 8 의 훌륭하면서도 새로운 기능을 다룹니다.

성능과 생산성에  대한 큰 그림

"Every language has an optimization operator. In C++ that operator is '//'"

(모든 개발 언어는 최적화 연산자를 가지고 있다. C++ 의 경우는 // 이다. )

- Overheard at the O＇Reilly＇s Velocity Conference, June 2008

(O＇Reilly＇s Velocity Conference 2008 에서)

Internet Explorer 8 에 대해 말하기 전에 우선 성능과 생산성의 관련성에 대해 말하고 싶습니다. 가장 중요한 것은 성능 향상은 브라우저 개발의 마지막 수단이라는 것을 이해해야 합니다. 최종적인 목표는 사용자와 개발자 사이에 보다 생산성이 뛰어난 환경을 구축하는 것입니다. 이것을 잊고 속도만을 추구한다면 매우 간단할 수도 있습니다.― 아무것도 하지 않는다면 성능이 좋기 때문에.

사용자들이 구현되기를  바란다고  생각하는 것들이 지금까지 공개된 Internet Explorer 8 의 많은 새로운 기능에 명확하게 나타나고 있습니다. 생산성을 향상시키는 좋은 예로서 웹 조각을 들 수 있습니다. 예를 들면, 어떻게 해서 웹 조각(Web Slice)이 사용자 대신에 컨텐츠의 업데이트 상태를 확인할지 생각해 보세요. 이 기능은 사용자와 개발자 서로에게 새로운 생산성에 대한 선택사항을 제시한 것입니다.

사용자는 일반적인 데이터를 확인하는 방법을 두 가지 단추로 단축시키는 이점이 있습니다. 개발자는 페이지 상태를 확인하기 위해서 행해지는 많은 양의 업데이트에 의해서 발생하는 트래픽에 대응하기 위해, 수백명 시간 단위로 개발자를 투입하는 대신에 신속하게 도입할 수 있는 가벼운 웹 조각을 도입하는 이점을 고려할 수 있습니다.

우리가 주목하고 있는 생산성에 관한 것 이외에도 Internet Explorer 8 에는 많은 중요한 개선점이 있습니다. 다음 장에서는 생산성을 향상시키기 위한 지금까지의 활동을  소개합니다.  마지막장에서는 고속으로 동작하는 사이트를 효율적으로 구축하기 위해서 필요한 기초를 제공하는 훌륭한 개발 기능을 소개합니다.

훌륭한 성능 : 어떻게 하면 브라우저를 빠르게 설계할까?

Internet Explorer 8에 어떤 목표를 설정하는가에 대한  계획을 시작했을 때, Internet Explorer 8 을 이용한 웹 브라우징 그 자체를 개선하는 것을 의식하고 결정했습니다. 대략적으로 말하면, 브라우저 실행, 탐색, 사용자와의 상호작용 기능(AJAX 방식의 상호작용 기능을 포함)에 한해 개선을 실시했습니다.

모든 웹 페이지를 로드할 필요가 없는 브라우저가 최고 속도가 되는 것이기도 함으로, 개발 초점의 일부를 웹 조각(Web Slice)과 같은 새로운 기능에 이동시킨 적도 있습니다. 이러한 대처에 의해, Web 플랫폼으로서 Internet Explorer 를 개선하는 것에 집중했습니다.

최종 목표를 검토하여, 최고의 브라우저를 만들기 위해서 무엇이 가능할지 생각했을 때, 곤란한 선택의 문제가 있었습니다. 우선, 브라우징 경험을 크게 개선할 수 있는 스크립트 성능에 한정하여 집중하는 것이 가능했습니다. 한편, 보다 다양한 현실적인 시나리오를 가정하여, 사용 빈도가 높은 내부 구조를 조사하여, 그 결과에 응한 최적화를 실시할 수도 있었습니다. 결국 후자의 접근 방식을 선택했습니다.

그리고, 몇가지 분석에 의해서 JScript 개선에 모든 리소스를 투입해도 브라우징 경험은 크게 개선되지 않는다고 판단했습니다. 분석에 이용한 샘플에 Internet Explorer 8 Beta 1 에서 TOP 100 사이트를 브라우징 중 몇가지 중요한 내부 구조에 의해서 CPU 주기가 소비되는 것을 보여주는 아래와 같은 분석 결과가 있습니다.

Layout

Rendering

HTMLParsing

Marshalling

CSSFormatting

DOM

Jscript

Other

43.16%

27.25%

2.81%

7.34%

8.66%

5.05%

3.23%

2.49%

TOP 100 사이트의 브라우징에 사용한 환경은 일반적인 JScript 와 DOM 벤치마크 (SunSpider 등)의 측정 결과가 총 CPU 시간의 10% 이하가 되는 환경에 주의해야 합니다.

몇가지 AJAX 응용 프로그램에서 유사한 테스트를 실행했을 경우, 놀라운 결과를 얻을 수 있었습니다.

Layout

Rendering

HTMLParsing

Marshalling

CSSFormatting

DOM

Jscript

Other

8.87%

8.68%

1.48%

7.40%

36.72%

11.72%

13.59%

11.54%

전형적인 AJAX 사이트 (몇가지는 주요 웹 메일 사이트입니다)에서도 JScript 와 DOM 내부 구조가 CPU 시간의 3 분의 1 을 소비하고 있는 것이 판명되어 있습니다.

이 데이터와 다른 분석 결과에서 Internet Explorer 8 의 브라우징 성능을 크게 개선하기 위해서는 JScript 이외에 몇개 분야의 코드에도 개선을 해야 한다는 것이 판명되었습니다. 추가로,  JScript 엔진 개선을 위해 다음 세가지를 채택했습니다.

SunSpider 와 같은 벤치마크 테스트의 결과는 성능향상을 분석하기 위한 중요한 부분입니다. 이것들은 확실히 성능 향상 상황을 측정하여, 실험 환경의 브라우저 성능을 다각적으로 분석하기 위한 귀중한 수단입니다.

특히 Internet Explorer 의 내부 구조에 대해서 분석 시에는 어느 벤치마크로의 개선이 브라우징 속도 개선으로 연결되는지를 이해하는데 도움이 되었습니다. 그러나 결과적으로 벤치마크 결과는 브라우저 성능의 모든 것을 보고하는 대신, 어떻게 조작을 하면 특정 성능이 변화하는지를 잘 표현할 수 없습니다.

스크립트 실행 환경 개선

Internet Explorer 8 의 성능을 향상시키기 위한 광범위한 노력의 일환으로서 페이지가 빠르게 표시할 수 있도록, 개발자 생산성을 향상시키기 위해서 JScript 성능 강화에 많은 개발 리소스를 투자했습니다.

Internet Explorer 8 에 탑재된 Jscript 엔진은 대부분의 경우에 고속으로 동작합니다.

문자열 조작, 배열화, 검색 동작을 포함해서 광범위하게 이용되는 Jscript  함수를 고속화하기 위한 개선을 했습니다. 함수 호출, 개체 생성, 윈도우 혹은 개체에 대한 변수 범위의 참조 패턴의 비용을 큰폭으로 줄이기 위해, 코어 아키텍처를 변경을 했습니다.

이러한 개선점의 몇가지는 코드내에 존재하는 병목현상이 지속되었습니다  오랜 세월, 개발자의 고민거리인 문자열과 배열 조작은 경우에 따라서는 전보다 확연하게 고속화 되었습니다. 이러한 개선에 의해서 개발자는 Internet Explorer 에 구현된 Jscript 의 느린 부분을 피하기 위해, 복잡한 회피 방법을 생각하기 위해 시간과 노력을 낭비할 필요가 없어집니다. (더 이상 문자열 결합을 피하기 위해 array.push 나 array.join 를 쓸 필요가 없습니다)

게다가 SunSpider 벤치마크 테스트에서 Internet Explorer 8의 성능이 Internet Explorer 7에 비해 4 배 뛰어난 결과가 나왔습니다.

대다수의 사용자는 자신의 환경에서 SunSpider 벤치마크 테스트를 실행할 것은 없지만, 보다 중요한 것은 많은 사이트가 분명하게 빨라진 점입니다. Internet Explorer 에 탑재된 Jscript 엔진을 개선한 것에 대한 반응은 Google로 부터 호의적인 반향을 얻은 것과 같은 결과로 이어졌습니다.

메모리 관리 개선

중점적으로 개선을 한 두번째 분야는 메모리 소비에 관한 것입니다. 지금까지 Internet Explorer 의 400 여 곳에 이르는 메모리리크를 보안했습니다. Heap fragmentation와 AJAX 페이지로의 메모리 소비 개선도 고민했습니다. Internet Explorer 의 메모리 소비량을 줄여서 실행 시간 단축, 페이지 이동 고속화, 그리고 Internet Explorer 가 장시간에 걸쳐서 안정된다는 개선과 연결됩니다. 이러한 개선은 사용자에서 유익하지만, 개발자의 부담도 줄여줍니다.

구체적으로는 JScript 와 DOM 간에 발생하는 메모리리크의 원인을 줄이는 일에  진지하게 노력했습니다.

이전 버전의 Internet Explorer에서 JScript 가베지 컬렉터 (GC)는 JScript 개체의 수명은 관리했지만, DOM 개체를 관리하는 기능은 없었습니다. 결과적으로 GC 는 DOM 와 JScript 개체 사이의 순환 참조를 중단하지 못하고, 사이트의 관리자가 주의 깊게 메모리를 사용하는 것을 관리하지 않으면, 메모리리크가 발생했었습니다. 복잡한 AJAX 사이트에서는 부하가 큰 작업으로, 개발자의 시간을 대량으로 소비합니다.

Internet Explorer 7에서는 메모리리크가 발생한 페이지로 이동했을 때에는 순환 참조를 중단하여, 어느 정도 개선이 되었습니다. 그러나 이 대책은 현재의 복잡한 인터랙티브 페이지에서는 근본적인 대책이 될 수는 없습니다.

Internet Explorer 8에서는 가베지 컬렉터를 큰폭으로 추가하여 수명이 종료된 순환 참조를 많이 중단함으로써 개발자의 부담을 줄여줍니다. 

이것에 의해서 개발자는 메모리의 세부 사항을 관리하는 대신, 훌륭한 사이트를 구축하는 것에만 보다 많은 시간을 할애할 수 있습니다.

통신 기능 개선

Internet Explorer 8 개발을 시작 한 시점에서는 광대역 접속 환경의 증가 경향을 보다 잘 활용하는 것이 가능했습니다. 외부 스크립트가 존재하는 상황에서 다운로드 장애를 개선하여 서버 근처의 동시접속 수를 증가시키는 것, 이 두가지가  Internet Explorer 8 의 중요한 개선점입니다.

개발 초기 단계에서는 외부 스크립트에 의한 차단은 비교적 성능이 낮은 CPU 처리 능력에 최적화되어 많은 웹 사이트의 처리 능력에서 중요한 네트워크의 대기 시간 역할을 한다고 인식했었습니다. Internet Explorer 8 이 외부 스크립트와 만났을 경우, 또 하나의 스레드에서 가능한 한 고속 페이지 요소의 다운로드를 연속하는 것을 확인할 수 있습니다. 많은 경우, 이 변경에 의해서 즐겨 찾기 페이지는 고속으로 다운로드가 가능하여,  개발자는 다운로드를 직렬화하는 스크립트 생성에 시간을 소비할 필요가 없습니다.

Internet Explorer 8 Beta 1 에서 서버 근처의 접속 수 제한을 2에서 6 으로 확대했습니다. 이것은 Internet Explorer 7 이 서버에서 두 개의 요소만을 동시에 다운로드 할 수 없었던 것을 의미합니다. 이 제한을 6 으로 확대하면, 한꺼번에 3 배의 컨텐츠를 다운로드할 수 있게 되어, 대역이 허락하는 한 고속으로 페이지가 전송됩니다.

렌더링 엔진 개선

이 글로 다루는 마지막의 큰 분야는 레이아웃과 렌더링을 실행하는 새로운 표준모드의 엔진 개선입니다.

Internet Explorer 8 의 개발에 대해 이해하신 분은 CSS 2.1 에 준거한 새로운 렌더링 엔진에 특별히 놀랄 만한 곳은 없을지도 모릅니다.

앞서 말한 내부 구조 데이터에서 추측할 수 있을지 모르겠지만, 렌더링과 레이아웃 성능은 브라우징 속도의 큰  부분을 차지한다는 것을 우리도 인식하고 있습니다.

Internet Explorer 8 을 이용하는 사용자와 개발자의 생산성을 높이기 위해선, 현존하는 다른 브라우저의 성능에 손색이 없는 엔진을 생산해야 한다는 생각했습니다.

Internet Explorer 8 Beta 1 표준모드 엔진은 Internet Explorer 7 엔진보다 훨씬 느렸지만, 수개월간의 개선 노력으로 비약적인 진보를 이뤘습니다. 

Internet Explorer 8 Beta 2에서는 표준모드 엔진은 많은 사이트에서 과거 버전의 구현물과 동등하다고 생각합니다. Internet Explorer 공개까지, 지속적으로 이 분야에 대한 노력을 계속했기 때문에 개발자는 어려운 결정을 할 필요가 없습니다― 새로운 엔진용으로 개발한 것은 서로 다른 브라우저에서도 잘 동작하고, 덧붙이면 속도 역시 빠르기 때문입니다.

이미 앞에서 설명한 것처럼, 성능 개선을 조합하여, Internet Explorer 8 은 많은 사이트에서 보다 고속으로 동작하고, 지금보다 더 생산성이 향상되었습니다. 

Internet Explorer 8 Beta 2 는 지금까지 최고의 Internet Explorer 로, 개발자는 가볍고 빠른 사이트를 보다 생산적으로 구축할 수 있는 개발자 도구에 대한 한층 더 개선된 점을 확인할 수 있습니다.

새로운 개발자 대상 기능

몇가지 개선에 의해서 웹 브라이징이나 새로운 사이트 구축을 보다 생산적으로 만드는 Internet Explorer 8 이 탄생했지만, 한층 더 웹 사이트를 빠르게 해야 할 때에 이용할 수 있는 몇가지  중요한 신기술에 대한 지원도 추가됐습니다. 이 글의 나머지 부분에서 제가 즐겨 찾기 하고 있는 세가지  개발 관련의 새로운 기능을 말씀드리겠습니다.

데이터 URI

작은 이미지를 많이 사용하는  사이트의 네트워크 오버헤드를 경감하기 위해 사용하는 CSS Spriting (영어) 코드를 쓰는 것이 지겹지 않나요? 만약 그러면, 즐겨 찾기 기능의 하나가 당신에게 적합할 것입니다. Internet Explorer 8 에는 RFC 2397 (영어) 에서 정의한 데이터 URI 를 지원하고 있습니다. 이미지 파일을 지정하기 위해서 URL 를 이용하는 대신에 (브라우저에 데이터를 전송하기 위해서 여분의 왕복 비용이 증가합니다), 데이터를 직접 인코딩 한 데이터 URI 를 사용할 수 있습니다.

예를 들면, 여기에 10x10 의 푸른 도트를 보여주는 데이터 URI 가 있습니다.

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKAQMAAAC3/F3+AAA
ACXBIWXMAAA7DAAAOwwHHb6hkAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUA
AAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAAAANQT
FRFALfvPEv6TAAAAAtJREFUCB1jYMAHAAAeAAEBGNlaAAAAAElFTkSuQmCC

base64 에서 인코딩 되었기  때문에 클라이언트 처리에 어느 정도의 오버헤드가 발생하고, 같을 이미지 파일을 재사용 하는 경우에서도 캐시 할 수 없기 때문에 사용해서는 안 된다는 점에 주의해야 합니다. 데이터 URI 는 문서 스크립트, 스타일 시트 등에 직접 넣기 위해, 삽입을 시도하는 경우는 그러한 캐시가 가능한 것에 삽입해야 합니다.

선택 장치 API

데이터 URI  지원에 추가하여,  Internet Explorer 8 은 지금까지의 프레임워크에 포함된 구현을 사용하는 방법보다 확실히 고속으로 JScript에서 선택 장치를 검색하는 querySelector 와 querySelectorAll 를 Selector API로서 지원합니다. 최신 빌드를 이용한 비공식의 테스트에서는 네이티브인 구현과 일반적인 프레임워크에 의해서 제공되는 얼터너티브인 구현을 비교하면, 몇가지 경우는 몇 초에서 밀리 세컨드 단위로 개선되는 것을 볼 수 있었습니다. 선택 장치 API 의 구현에 관한 세부 사항정보에 대해는 Selectors API whitepaper (영어) 를 참조해 주세요.

JSON

제가 좋아하는 세가지 Internet Explorer 8 개발 기능 중에서 마지막은  이전 글에서 발표한 JSON 지원입니다. AJAX 웹 사이트의 개발자는 사이트상의 구성요소에서 데이터 교환을 할 때에 자주 JavaScript Object Notation (JSON)를 이용합니다. 이전 버전의 Internet Explorer에서는 개발자는 JSON 스트링을  JScript 에 복원하기 위해 JavaScript 의 Eval 메서드를 이용한 안전하지 않은 JSON 를 사용하지 않을 수 없었습니다. 보다 안전한 사이트는 일반적으로 보다 안전한 JSON parser 를 JSON 개체 삭제에 이용했습니다― 자주 성능을 저하합니다. 어느 쪽의 방법도 사용자와 개발자의 생산성을 현저하게 저하시켰습니다.

Internet Explorer 8 Beta 2 로 모든 사람의 생활을 풍부하게 하기위해, JScript 엔진에 ECMAScript 3.1JSON (영어) 제안 사양의 JSON.stringify 와 JSON.parse 메서드를 구현하여 개발자 공통의 문제인 스피드와 보안 솔루션을 제공합니다.

다른 뛰어난 기능

앞선 제가 좋아하는 세가지 개발 기능은 Internet Explorer 8 개발 기능 중에서 마지막은 개발자가 보다 좋은 사이트를 만들기 위해서 이용할 수 있는 것입니다.

물론, 이 세가지 이외에 고속사이트를 만들기 위해서 이용할 수 있는 개발자 대상의 기능 컬렉션이 있으므로, 여러분이 좋아하는 것과는 다를 수도 있습니다.

DOM 저장소의 지원 (사이트 근처 10MB 의 로컬 저장소), XDomainRequest (서버 사이드 프록시를 이용하지 않는 안전한 크로스도메인통신), Connectivity Events (스크립트에서 현재의 인터넷에의 접속 상황을 문의 가능함) 등은 개발자가 고속 웹 사이트를 구축할 때에 이용할 수 있는 강력한 기능입니다.

한층 더 개발자가 Internet Explorer 8에서 고속사이트를 구축하기 위한 도구와 기능 대처는 지금까지의 Internet Explorer 에 비해 보다 간단하고 알기 쉽다고 확신하고 있습니다.

이제  벤치마크 테스트로 머리속이 가득 차 있지만, 언제나 한 걸음 내려가 모든 일을 시야에 넣은 전체 그림이 가치가 있는 것이라는 것을 발견합니다.

그것을 염두에 두고, 여러분의 기대가 매우 높다는 것도 알고 있습니다.

Internet Explorer 의 성능을 한층 더 향상시킬 수 있는 계획이 있기 때문에 향후 공개되는 Beta에서 진행 상황을 지켜봐 주세요. 

Christian Stockwell
Program Manager & Performance Geek

Comments