브라우저 성능 평가의 일반적인 문제

IE 팀에서 브라우저 성능을 담당하고 있는 프로그램 관리자 Christian Stockwell 입니다.

웹 사이트와 웹 브라우저의 전체적인 성능을 측정하는 일은 사용자가 경쟁 관계에 있는 브라우저를 비교하기 위해서,  개발자가 다운로드 시간이나 응답을 최적화하기 위해서, 브라우저 공급업체가 코드 변경과 성능 변화의 관련성을 조사하기 위해, 그리고 웹 사이트 성능에 대해 관심 있는 모든 사람들에게도 중요한 일입니다.

이 글은 브라우저 성능 테스트에 영향을 주는 문제나 브라우저 성능을 효율적으로 측정하기 위한 기술에 대해 기술할 예정입니다. 

브라우저 성능 측정

일반적인 성능 테스트의 접근 방식은 특정 벤치마킹 제품군 (패키지)에 집중합니다. 이것은 유효한 측정 방법이지만 소수를 타겟으로 하는 벤치마크만을  의존하기 때문에 사용자가 느끼는 성능을 잘못 이해할 가능성이 있습니다. 브라우저 성능을 측정하는 가장 정확한 방법에는 실제로 잘 행해지고 있는 브라우징 시나리오측정이 포함되어야 합니다. 실제 사이트에서 측정하면, 다른 벤치마크에서는 추출할 수 없는 요소를 포착할 수 있어 종합적인 측면에서의 성능을 알 수 있습니다. 실제 사이트에 대해서 브라우저 테스트를 실시하는 것은 몇가지 중요한 도전이 필요하지만, 이 글은 우리가 개발 과정에서 IE 성능을 효율적으로 측정하기 위해 사용한 해결 방법을 보여줍니다.

먼저, 성능 벤치마크를 유효하게 실시한다는 것은 생각보다 많은 어려움이 있다는 것을 미리 말해 두고 싶습니다. IE 팀은 매일 수천개의 독립적 테스트를 여러 서버에서 실시하기 위해, 수백 대의 데스크톱과 랩톱에서 유효성 검사와 성능 측정을 위한 실험 환경을 구축하기 위한 작업에 많은 노력을 했습니다. 그리고 성능 데이터 안정성, 정밀도 명확성을 개선하기 위한 새로운 아이디어를 매일 만들었습니다. .

브라우저 성능 측정의 도전 중 하나는 브라우저가 사용되는 방법이 방대하다는 것입니다. 사용자는 매일 다양한 사이트를 브라우즈징하며,  그 중에는 Flicker 와 같은 컨텐츠량이 많은 사이트에서 Google과 같이 최소화된 사이트도 포함되어 있습니다. Windows Live Hotmail 과 같은 상호작용 목표 AJAX 사이트도 방문하고, Craigslist와 같이 단순하고 정적인 HTML 사이트도 방문합니다. 또한 미션 크리티컬한 응용 프로그램에서 업무용으로 사용하는 사람도 있습니다.

이러한 각각의 카테고리 사이트  성능은 많은 경우 브라우저내의 다른 하부구조에 의존합니다. 예를 들어 이미지가 많은 사이트에서는 브라우저의 다운로드와 이미지의 배포 속도에 의존합니다. 대조적으로, 단순한 사이트의 성능은 HTML 렌더링 속도가 주요한 요소가 됩니다. 다른 예로서 AJAX 웹 사이트의 성능은 JavaScript 엔진과 CSS 엔진, DOM가  얼마나 긴밀히 통합되었는지,  각각의 하부구조가 속도 이상으로 중요한 요소입니다. Flash 나 Silverlight 와 같은 타사의 컨트롤이 포함되어 있으면, 많은 경우 성능은 컨트롤이 얼마나 효율적으로 브라우저와 통합되었는지 관련합니다.

여기서 소개하는 접근 방식은  IE8에서 행해진 성능 개선 배경과 관련되었으며, 또 우리의 개발 공정에 대해 알려드릴 것입니다. 이것들을 통해서, 이 글에서 브라우저와 사이트의 성능을 측정하여 검토하는 방법을 향상시키기 위한 아이디어를 찾기 바랍니다.  

캐싱 동작(Caching Behavior)

모든 브라우저는 기본적으로 네트워크에 의존하며, 어떠한 테스트에서도 성능 측정을 충분히 실시하려면 그 현실이 반영되어야 합니다.

브라우징 성능에 영향을 줄 수 있는 인터넷 성질 중 하나는 인터넷을 구성하는 다양한 수준의 서버 컨텐츠 저장 방법입니다. 이러한 저장 동작은 캐싱이라 불립니다.

브라우징 성능 측정에서는 www.microsoft.com 을 표시할 때  브라우저는 이 컨텐츠를 회사내의 프록시 서버나 로컬 서버, 전세계의 수많은 서버 등  여러 서버에 요청합니다 .

브라우징 스피드를 향상하고, 웹 페이지를 제공하는 작업을 분산화하기 위해, 표시한 페이지의 일부를 일시적으로 저장하여, 다른 사용자가 그 일부를 보다 빨리 취득할 수 있도록 합니다. 예를 들어 여러분이 아침에  제일 먼저 뉴스를 보기위해,  www.msnbc.com (영어)를 방문하는 경우, 먼저 회사의 프록시 서버에 요청합니다. 프록시 서버는 최종적으로 원격지 서버에서 페이지를 취득전에 로컬 서버에 그 요청을 중계합니다. 페이지 취득이 완료하면, 프록시 서버 또는 로컬 서버는 컨텐츠의 일부를 저장합니다. 이 때 동료인 Tracy 가 10 분 늦게 출근하여 www.msnbc.com (영어) 에 액세스하면, 원격지 서버 대신 프록시 서버에서 직접 컨텐츠를 취득하여, 사이트를 표시하는데 필요한 시간이 현저히 단축되어 Tracy 는 매우 행복해집니다.

마찬가지로 여러 브라우저에서 성능을 측정하는 경우, 캐싱 영향을 고려하는 것이 중요합니다. 예를 들어 첫번째 브라우저의 10 개 탭에서 10개의 다른 웹 사이트를 연 뒤, 두번째  브라우저에서도 같은 10 개의 탭을 열면, 두번째 브라우저가 빠르다는 다른 결과를 얻을 수 있습니다. 실제로는 이러한  차이는 주로,  브라우저가 처음에  페이지를 요청했을 때에 컨텐츠가 가까운 서버에 저장되어 있는지에 따라 달라집니다..

서버가 어떻게 캐시 하는지를 엄격히 제어하는 것은 어렵지만, 성능 측정의 일반적인 원칙은 어떠한 경우도 한번의 측정으로 끝내서는 안됩니다. 상위에서의 캐싱 영향을 따로 측정하려는 것이 아니면, 성능 데이터의 수집을 시작하기 전에 측정하고자 하는 사이트를 한 번은 방문해야 합니다. 실제로는 프록시는 사용자 에이전트 (브라우저) 마다 컨텐츠를 캐시하므로, 테스트를 원하는 사이트의 각각을 테스트 하는 모든 브라우저로 방문해야 합니다.

여기까지의 캐시 동작 소개는 단순화 한 것입니다. 보다 자세한 정보가 필요하면, 동작이 세부 사항에 해설된 중요한 리소스가 다수 있어, HTTP 프로토콜 규격 자체도 그 하나입니다. HTTP 프로토콜 규격 (영어) 가 매우 좋은 자료입니다.

샘플 양

정확하게 말하면, 브라우징 성능에 영향을 주는 요소는 매우 다방면에 걸쳐있기 때문에 성능 측정 횟수에 따라 그 결과에 큰 차이가 있는 경우가 있습니다.

앞에서 얘기한 것과 같이, 성능 측정의 일반적 원칙은 어떠한 경우도 한 번의 측정으로 끝내서는 안됩니다. 이 원칙을 「어떤 경우에도 충분한 회수 측정을 해야 한다」라고 확장하고 싶습니다. 「충분한 회수」가 무엇을 의미하는지에 대해는 신뢰구간이나 표준편차, 그 외의 통계학상의 흥미로운 응용에 근거한 여러 가지 의견이 있습니다.

우리가 수집한 다수의 성능 데이터에 관해서는 대부분의 경우, 실용적인 접근 방식을 채용하여 비교적 복잡한 과제를 피할 수 있었습니다. 유효성 검사 환경에서는 7~ 10 회의 반복으로 안정성있는 데이터 집합을 수집합니다. 다만 유효성 검사하는 환경 제어가 보다 불충분한 경우는 보다 많은 회수가 필요합니다.

성능 데이터를 수집되면, 결론을 이끌기 위해 결과를 요약해야 합니다 . 산술평균 (영어), 조화평균 (영어), 기하평균 (영어), 또는 그 외의 어떠한 방법을 사용하는 경우여도 데이터 요약 방법에 따라 결과가 달라 질 수 있다는 것을 충분히 이해하고 있어야 합니다.

예로서 두 개의 브라우저에서 단일 웹페이지를 표시하는 테스트에서 수집된 점수 데이터입니다.

억지로 맞춘 듯한 이 예에서 명확한 점은 데이터를 어떻게 요약하는지에 따라서 데이터 해석이 바뀐다는 것입니다. 이 예에서는 산술평균은 브라우저 B 가 브라우저 A 보다 빠르다고 보여주는 것에 반해, 기하평균과 조화평균에서는 그 반대의 결과가 나왔습니다.

대역폭 경쟁(Bandwidth Competition)

네트워크를 다른 사용자와 공용하는 것은 분명히 웹 브라우저가 같은 동작을 하는데 보다 많은 시간을 필요로 합니다.

Microsoft 와 같은 대기업에서 일을 하는 경우의 이점 중 하나는 직원이 다수이기 때문에 특정 현상을 측정가능하고 신뢰할 수 있습니다. 예를 들어 페이지 다운로드에 필요로 하는 시간을 하루 동안의 통계를 살펴보면 많은 Microsoft 직원은 오전 8 시에서 오전 9 시의 사이에 일을 시작하여 오후 5 시에서 오후 6 시의 사이에 퇴근하는 것이 확실합니다.

그 이유로서 명확하게 말할 수 있는 것은 많은 Microsoft 직원은 하루 종일 거의 끊임없이 네트워크에 액세스합니다. MSDN 를 참조하거나 SharePoint 문서를 읽거나 최신 Xbox 게임 테스트를 실시하는 등의 대역폭을 함께 사용합니다. 그러한 공유는 브라우저 성능을 측정하려면 회사 전체가 업무를 시작하여 전자 메일을 송신하기 시작하는 오전 9 시 대신, 오전 6 시에 가는 것이 일관된 결과를 확실히 얻을 수 있는 것을 의미합니다.

기업에 따라서 가능한 네트워크 구성 종류도 폭넓기 때문에 대역폭 경쟁 영향을 예상하는 일은 어렵습니다. 결과를 왜곡하지 않도록 권장하는 방법은 직장에서 성능 데이터를 수집하는 경우에는 주요 업무 시간 이외로 성능 데이터 수집을 하는 것입니다.

자택에서 성능 데이터의 수집을 실시하는 경우도 가족이나 주변 사람과 대역폭을 공유하는 것이 됩니다. 그러한 경우, 영업시간이나 또는 이른 아침 등 다른 사람이 브라우징을 많이 하지 않는 시간대에 맞춰 측정하면 좋을 것입니다.

리소스 경쟁

컴퓨터  리소스에 대한 응용 프로그램 사이의 경쟁도 대역폭의 경쟁과 같이 브라우징 성능에 크게 영향을 줍니다.

여러 응용 프로그램이 동일한 외부 응용 프로그램이나 플랫폼에 의존하는 경우, 이것은 특히 틀림없는 사실입니다. 예를 들어, 안티 바이러스 제품에는  여러 브라우저와 다른 방법으로 통합가능 하지만, 그 성능에 주는 결과는 불명확합니다.

두개의 브라우저를 병렬하여 테스트 하면, 정확하지 않은 결과가 되는 경우가 있습니다. 예를 들어, Windows 플랫폼에서는 아웃 바운드의 소켓 요청은 동시에 10개 까지 제한됩니다. 게다가 요청은 접속 요청이 성공 또는 실패할 때까지 차례를 대기합니다. 두 개의 브라우저를 병렬하여 테스트하면 이러한 제한에 쉽게 이릅니다. 그 결과, 어느 쪽이든 한쪽의 브라우저가 수 밀리초  빨리 실행을 시작하여 우위가 되는 결과가 나옵니다. 

여기에서는 두개의 단순한 예를 들었지만, 그 이외에도 문제는 확실히 존재합니다. 이것에 대해 보다 세부 사항에는 논하지 않지만, 브라우징 성능을 측정할 때의 복수 응용 프로그램의 실행에 대해서 명료한 조언이 있습니다. 

최악의 경우에도 다른 응용 프로그램에서의 영향을  줄이기 위해 다음 두 단계를 거쳐야 합니다. 

• 작업 표시의 우측 통지 영역에만 표시되는 것을 포함하여, 열려 있는 모든 응용 프로그램을 종료한다.
  이것은 다른 응용 프로그램이 네트워크를 사용하지 않기 위해 특히 중요합니다.
• 커멘드 프롬프트에서 다음의 코맨드를 실행하면, 테스트시의  시스템동작을 줄일 수 있습니다.

서버 상호작용(Server Interaction)

컴퓨터나 네트워크  리소스 공유에 의한 간섭을 넘어도 성능 결과는 액세스 대상의 서버 내부적인 동작으로 영향을 받습니다.

성능 측정의 포괄적인 원칙의 하나는 테스트를 통해서 일정한 상태를 유지하는 일입니다. 캐시 관리에서는 성능 데이터 수집 전에 상위의 서버를 기존 상태에 해야 하는 일로 또 네트워크에서는 외부적인 요소의 영향을 줄이기 위해 일정한 환경에서 테스트를 하도록 노력합니다. 

벤치마크에 영향을 주는 응용 프로그램 설계 특성의 예로서 온라인 뱅킹 응용 프로그램을 채택합시다. 보안상의 이유로, 뱅킹 응용 프로그램은 적절한 자격 정보가 제시되었을 경우에만 계정 정보에의 액세스를 허가합니다.  두 개 (또는 그 이상)의 브라우저를 이 온라인 뱅킹 웹 사이트에서 벤치마크 테스트 한다면, 어떤 브라우저에 대해서도 응용 프로그램을 확실히 동일한 상태로 하는 것이 중요합니다. 설계상, 대부분의 온라인 뱅킹 응용 프로그램은 동시에 두 개의 세션에서 사용자가 로그인 할 수 없습니다. 한편으로 로그인 하면, 한편에서는 로그 아웃 됩니다. 두번째 브라우저 테스트를 시작하기 전에 웹 응용 프로그램 상태를 초기화 하는데 실패하면, 서버 기반의 응용 프로그램은 두번째 요청을 분석하여, 최초의 세션을 종료하고 새로운 세션을 시작하기 위해 여분의 시간이 필요합니다.

이와 같이 시작 처리와 종료 처리는 벤치마크에 영향을 줍니다. 이것은 온라인 뱅킹 응용 프로그램에 한정된 것은 아니기 때문에 이러한 요소를 없애도록 해야 합니다. 더 일반적으로 말하면, 성능 테스트에 사용하기 전에 대상이 되는 사이트의 동작을 이해해야 합니다.

관찰자 효과(Observer Effect)

많은 분야에서 측정하는 작업 자체가 측정 대상을 변화시키는 잠재적인 가능성이 있습니다. 이 현상은 관찰자 효과 (영어) 라 부릅니다.

특정 브라우징 시나리오 측정 작업을 편의상, 수많은 프레임워크의 한쪽을  사용할 수가 있습니다. 이러한 프레임워크는 전형적으로는 개발자나 기술자를 대상으로 합니다. 그러한 프레임워크의 일례로서는 Jiffy (영어) 가 있습니다.

어떠한 인프에서든 측정 결과에 직접 영향을 준다면, 주의 깊게 액세스 하여 측정에 사용하는 프레임워크에 의한 성능 변화를 부르는 잠재적 가능성을 최소화해야 합니다.

여담이지만, IE 팀에서는 내부적인 테스트에 ETW 트레이스 로그인 인프라 구조를 사용하고 있습니다. 이것은 ETW 가 확장성 높은 로그인 인프라 구조로, 결과를 왜곡하는 관찰자 효과의 가능성을 최소화할 수 있기 때문입니다.

컴퓨터 구성(Machine Configuration)

사람과 마찬가지로, 엄밀하게 동일한 두 개의 컴퓨터는 존재하지 않습니다.

앞에서 얘기와 같이, IE 성능 유효성 검사 환경에서는 매일 성능 테스트를 실행하는 대량의 컴퓨터를 보유하고 있습니다. 유효성 검사 환경의 유연성을 최대로 하기 위해, IE8 의 초기에 일관된 성능 데이터집합을 만들어 내기 위한 기획했습니다. 이러한 컴퓨터는 연번의 직렬화Serialization) 넘버가 붙어있고,  같은 조립 라인으로 생산되어 각각의 구성요소는 "완전히 동일" 이었습니다. 이러한 노력에도 불구하고, 컴퓨터에서 수집된 데이터는 다양하기 때문에 다른 컴퓨터에서의 성능 결과를 직접 비교 하는 일은 피했습니다. 

이것은 놀라운 일은 아니지만, 다른 플랫폼간에 브라우저 성능은 가지각색이 되므로, 모든 브라우저의 테스트를 단일의 컴퓨터에서 실행해야 한다는 것을 알아 주셨으면 합니다.

Cold Start vs. Warm Start

브라우저를 시작하는데 필요한 시간의 총합은 브라우저 관할 외의 여러가지  요소에 의존합니다. 

캐시 동작과 같이, 브라우저를 시작하는 스피드는 외부 요소의 영향을 받기 쉽습니다. 이것은 특히 첫번째 브라우저 실행에서 현저하게 나타납니다. 브라우저가 웹 사이트에 전환을 시작하기 이전에 우선 자기 자신의 파트를 메모리에 로드하기 위한 시간이 소요되는 동작이 필요합니다. 첫번째  브라우저의 실행에서는 얼마나 많은 부분이 이미 메모리에 읽히고 있는지를 정확하게 아는 일은 어렵습니다. 특히 IE에서는 많은 구성요소가 다른 프로그램과 공유되기 때문에 매우 어렵습니다.

일관성이 있는 데이터를 수집하기 위해서는 테스트의 시작 전에 대상이 되는 브라우저를 각각 한 번 실행한 후 종료합니다. 브라우저에 필요한 구성요소의 일부를 운영 체제가 메모리에 로드하는 동작을 하는 다른 응용 프로그램이 없으면, 결과의 정확함과 일관성은 향상합니다. Windows Superfetch (영어) 와 같은 평상시 잘 사용하는 브라우저에 유리하게 될지도 모르는 기능을 특히 고려하면, 브라우저 사이의 비교도 공정하게 할 수 있습니다. 

웹 사이트 컨텐츠

웹 사이트는 항상 변화합니다. 유감스럽게도 성능 테스트를 시도하는 동안도 그 예외가 아닙니다.

IE 팀의 성능 유효성 검사 환경에서는 모든 웹 사이트의 컨텐츠는 테스트 기간 중 캐시된 상태가 되어 있었습니다. 캐시 동작의 영향 중 하나는 테스트 매회 반복하여 브라우저에 정확하게 같은 컨텐츠가 제공됩니다.  실제로는 이것이 그렇게 빈번히 일어나는 일이 아닙니다.

일례이지만, 뉴스 사이트는 화제가 널리 알려지는 것에 따라 컨텐츠를 업데이트합니다.  Facebook 나 MySpace 를 두 번 방문하면, 친구가 새로운 사진을 추가하거나 상태를 업데이트 하면, 완전히 다른 경험이 얻을 수 있습니다. 광고는 많은 웹 사이트에서는 빈번히 변경되므로, 즐겨 찾기의 사이트를 두 번 표시하면, 틀림없이 차이가 납니다.

유효성 검사 환경이 아니면, 이러한 변경을 제어하는 일은 어렵습니다. 이것에 대한 접근 방식은 확실히 존재합니다. Fiddler 와 같은 도구를 사용하여 브라우저가 받는 컨텐츠를 조작하는 것이 가능합니다. 그렇지만 이러한 접근 방식은 성능 결과에 영향을 줄 가능성이 큽니다. 결과적으로, 현실적인 해결 방법은 샘플 양에 대해 지적했을 때의 조언과 같습니다. 페이지를 몇차례 표시할 때 마다 매우 무거운 광고가 표시되는 경우, 유효성 검사가 있는 일련의 결과를 얻기 위해서 측정을 상당 회수 반복해야 합니다 .

웹 사이트 설계

웹 사이트는 액세스 마다 변화할 뿐만 아니라, 다른 브라우저에는 각각 완전히 다른 버전의 웹 사이트가 제작자에 의해서 준비된 경우도 있습니다.

테스트 마다 웹 서버에서 확실히 같은 컨텐츠가 제공되도록 하는데  귀찮은 문제의 하나는 다른 브라우저에 대해서 분명하게 다른 코드를 반환하는 그러한 사이트입니다. 많은 경우, 그러한 차이는 사용자가 다른 웹 사이트를 방문했을 때의 경험을 정당하게 반영한다고 생각하여 브라우징 성능 측정에서는 차이를 무시해야 합니다.

그렇다고는 해도 웹 사이트가 제공하는 기능이 브라우저 간에 광범위하게 다르기 때문에, 브라우저 간의 비교가 의미를 만들어내지 않는 경우도 있습니다. 예를 들어, 최근 고객이 웹 사이트 이용에 IE8 를 사용하면 경쟁 관계의 다른 브라우저를 사용했을 경우보다 시간이 걸린다는 보고를 받아, 조사한 일이 있습니다. 조사의 결과, 그 웹 사이트는 IE 를 사용하면 IE 이외를 사용했을 경우에 비해 보다 리치한 기능을 제공하는 프레임워크를 사용한다는 것을 알았습니다. 다행히도 웹 사이트는 그러한 리치한 기능에 의존하지 않았기 때문에 프레임워크의 사용법을 조금 변경하여, 어느 브라우저에서도 같은 속도로 동작하도록 할 수 있었습니다.

이 예와 같이 웹 사이트가 프레임워크의 제공하는 확장기능을 사용하지 않고, 사이트를 업데이트 할 수 있는 경우도 있지만, 많은 경우 브라우저의 종류에 의존하여 완전히 다른 사용자 경험을 제공합니다. 이러한 웹 사이트의 평가는 대체로  경우에 따라 다르지만, 이러한 사이트는 브라우저 성능보다 사이트 개발자의 의도가 성능에 크게 반영되므로, 일반적으로는 직접적인 비교에는 해당하지 않는다고 생각합니다.

브라우저를 구별하는 사이트를 식별하는 것이 단순하지는 않습니다. 게다가 이 경우 웹 개발자는 조사 담당자를 제어할 수 있습니다. 웹 개발자는 프로파일러나 디버거, 그 외의 도구를 사용하여, 브라우저마다 웹 사이트가 완전히 다른 경험을 제공하기 위한 식별 방법을 자유롭게 결정할 수가 있습니다.

조사 담당자나 보다 기술에 경험이 많지 않은 사용자는 이용해 보고 분명하게 시각적으로나 동작이 다른 사이트에서 여러 개의 브라우저 성능 측정은 피해야 합니다. 그러한 사이트를 사용한 테스트에서는 브라우저 성능을 웹 사이트 설계의 영향에서 분리하는 일은 어렵습니다.

「페이지가 표시되었습니다」

「페이지가 표시되었습니다」라는 표시의 의미를 정확하게 정의할 수 있을까요. 복잡하고 인터랙티브 AJAX 사이트에서는 어떻습니까.

성능 측정에 대해 놀라울 정도 귀찮은 문제 증 하나는 페이지 전환으로, 「완료」란 무엇을 의미하는지를 정의하는 일입니다. 이 귀찮은 문제는 웹 사이트가 복잡하고 비동기적이며, 한층더 심각합니다. 브라우저가 페이지 전환을 완료된 것을 보여주는 표지로서 HTML "onload"(영어) 이벤트를 사용하는 웹 개발자도 있습니다.그러나 이 이벤트의 정의는 유감스럽게도 브라우저에 따라서 다른 해석이 됩니다.

IE 팀 내부에서는 여러가지 사이트에서의 페이지 로드를 측정하기 위해서 내부적인 이벤트 기록을 이용하고 있습니다. 이 기록은 IE 에 특화된 것으로, 브라우저 마다의 페이지 로드 성능을 측정하기 위한 크로스 브라우저의 간단한 해결책이 되지는 않습니다. 사이트 개발자가 각각의 시나리오의 「완료」를 정의하는데 도움이 되는 Jiffy (영어)  또는 Episodes (영어) 와 같은 프레임워크는 존재하지만, 일반 사용자에게 폭넓게 받아 들여지는 것이 아닙니다.

특정 코드 수준에 의한 식별 대신, 브라우저 진행률 표시기 (모래시계, 푸른 점, progress bar, 텍스트 박스나 그 외의 사용자 인터페이스 요소)를 페이지의 다운로드 완료 통지에 사용하는 사람도 있습니다. 그러나 이러한 요소는 어떠한 표준에도 잘 다뤄지지 않고, 브라우저 제조자는 이것을 언제 표시할지 (또 표시하지 않을지도) 독자적으로 결정할 수 있습니다.

이러한 현실에 직면한 다음 조사 담당자나 사용자에게 사용하도록  권장할 수 있는 것은 실제 웹 페이지의 동작에 대응하는 것을 확인할 수 있는 방법은 브라우저의 진행률 표시기를 사용하는 것입니다. 예를 들어 특정 웹 페이지가 얼마나 신속하게 로드 되는지 테스트한다면, 최초의 로드 시에 브라우저의 진행률 표시기를 사용해 봅니다. 만약 진행률 표시기가 완료되기 전에 웹 페이지가 로드되어, 읽기 조작 가능하게 된 것처럼 보인다면, 인디케이터는 무시하고 페이지의 보이는 방법을 측정을 위해서 사용합니다. 또는 다양한 브라우저 사이에 페이지 다운로드의 속도를 초기적으로 평가하는 것 뿐이면, 진행률 표시기로 충분할지도 모릅니다. 실제 페이지 로드와 브라우저 인디케이터의 표시가 얼마나 일치하는지를 평가하지 않으면 성능 측정 시에 인디케이터를 신뢰해야 할 것인지 판단할 수 없습니다.

브라우저 애드온

브라우저 테스트를 할 때에 애드온을 동작시키면, 브라우저 성능만을 테스트한다고 말할 수 없습니다.

4 월에 쓴 글에서 말한 것처럼, 애드온은 브라우저 성능에 매우 큰 영향을 줍니다. Microsoft 의 데이터 경로를 통해서 받은 데이터에서는 수십 개의 애드온이 설치된 브라우저는 드물지 않고, 아마 Mozilla corporation 에서 저와 같은 입장의 사람들도 그들의 브라우저에 대해 같이 말할 것입니다.

이러한 애드온은 모두 브라우저 안에서 독자적인 활동을 실행합니다. 이 영향에 대해 일화적으로 설명하면, 자주 사용하는 브라우저가 있는 사용자가 다른 브라우저에서도 평소 사용하는 브라우저보다 빠르다고 느끼는 것은 단지 새로운 브라우저는 깨끗한 상태이기 때문이라는 것을 알았습니다. 예를 들어, 많은 애드온이 설치된 Firefox 사용자가 IE 로 변경하면 성능이 크게 향상되었다고 느끼고, IE사용자가 Firefox 로 이행했을 경우도 같은 성능 향상을 느낍니다. 이 결과는 결코 모순된 것이 아니고, 브라우저 애드온 영향의 크기를 반영합니다.

결과적으로, 우리의 성능 유효성 검사 환경에서는 깨끗한 브라우저의 설치와 일반적으로 잘 사용되는 애드온을 설치한 브라우저를 모두 테스트 했습니다. IE8 로 애드온을 무효로 하려면, "도구" 메뉴를 클릭하여 "애드온 관리" 를 선택합니다. 애드온 관리 화면에서는 우선 "표시" 에서 "모든 애드온" 을 선택하고, 다음에 표시된 애드온을 한개씩 무효로 합니다. 또는 커멘드라인이 익숙하다면, 애드온을 무효로한 IE 를 "iexplore.exe -extoff" 커멘드로 실행 할 수 있습니다.

대부분의 브라우저 배급업체는 브라우저를 업그레이드해도 애드온이 계속 올바르게 기능하도록 보장하기 노력하고 있습니다. 그러나 어떠한 성능 향상이어도 단지 하나의 애드온 때문에 엉망이 되어버릴 수도 있기 때문에 위의 같은 절차를 밟는 일은 매우 중요합니다.

글이 조금 길어졌지만, 우리가 IE 의 성능을 측정할 때의 몇가지 기술을 여러분의 요구에 따라 이용해주시기를 바랍니다. 또 우리가 성능 테스트에 대해 어떠한 생각을 가지고 있는지 이해하고, 브라우징 성능 프로세스와 접근 방식을 보다 이해하게 되었으리라 생각합니다. 마지막으로 IE8 제공 과정에서 어떠한 노력을 하고 있는지 조금이라도 알아 주시면 감사하겠습니다.

Christian Stockwell
프로그램 관리자

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

업데이트 일: 2009 년 1 월 23 일

영문 원본 : Common Issues in Assessing Browser Performance