스피도미터 3(Speedometer 3): 웹을 대표하는 벤치마크 구축

오늘의 'The Fast and the Curious' 포스트에서는 웹 애플리케이션의 성능을 최적화하기 위해 업그레이드된 브라우저 벤치마킹 도구인 Speedometer 3.0 출시 소식을 다룹니다.

주요 웹 브라우저 엔진인 Blink/V8, Gecko/SpiderMonkey, WebKit/JavaScriptCore와의 협력을 통해 Speedometer 3.0의 출시를 발표하게 되어 매우 기쁩니다. Speedometer와 같은 벤치마크는 브라우저 엔진 개발사가 성능 개선 기회를 찾는 데 도움을 주는 도구입니다. 이상적인 벤치마크는 사용자가 일반적인 웹사이트에서 경험하는 기능을 시뮬레이션하여, 브라우저가 사용자에게 실질적으로 유익한 영역을 최적화할 수 있도록 보장해야 합니다.

Speedometer 3.0의 새로운 변화를 자세히 살펴보겠습니다.

다중 이해관계자 거버넌스 모델 적용

2014년 WebKit 팀이 처음 출시한 이후, 브라우저 엔진 개발사들은 엔진을 최적화하고 웹 사용자 경험을 개선하는 데 Speedometer를 성공적으로 사용해 왔습니다. 이어 2018년에는 Apple과 Chrome의 협업 결과물인 Speedometer 2.0이 출시되었으며, 당시 현대적인 웹을 더 잘 반영하는 업데이트된 워크로드 세트가 포함되었습니다.

2018년 이후 웹은 크게 변했으며, 최신 버전인 Speedometer 3도 그에 맞춰 진화했습니다. 이번 작업은 업무를 분담하고 웹 성능에 대한 공동의 이해를 구축하기 위한 공동 다중 이해관계자 거버넌스 모델을 기반으로 진행되었으며, 이를 통해 사용자에게 도움이 되는 방향으로 브라우저 성능 향상을 이끌어내고자 했습니다. 이 협력 프로젝트의 목표는 웹 성능에 대한 공동의 이해를 만들어 사용자 경험을 향상시키는 개선을 이루는 것입니다. 협력을 통해 Speedometer가 점수를 측정하고 계산하는 방식을 개선하고, 더 상세한 결과를 표시하며, 더욱 다양한 워크로드를 도입할 수 있었습니다. 이러한 크로스 브라우저 협업은 더 다양한 관점을 도입하여 광범위한 웹 사용자와 워크플로우에 대한 명확한 통찰력을 제공했으며, 사용자가 어떤 브라우저를 사용하든 최신 버전의 Speedometer가 모든 이들을 위해 웹을 더 좋게 만드는 데 기여할 수 있도록 보장했습니다.

워크로드 구축이 어려운 이유는 무엇인가요?

대표성 있는 테스트와 워크로드를 갖춘 신뢰할 수 있는 벤치마크를 만드는 것 자체가 이미 도전적인 과제입니다. 만약 이 도구가 수년 동안 브라우저 엔진의 최적화를 가이드하는 도구로 사용될 예정이라면 그 과제는 훨씬 더 어려워집니다. Speedometer 3 벤치마크를 개발하기 위해 Chrome Aurora 팀은 다른 참여 브라우저 엔진 개발사 동료들과 함께, 2024년 이후의 방대하고 다양하며 다채로운 웹에서 사용자가 경험하는 바를 정확하게 반영하는 새로운 워크로드를 찾는 임무를 맡았습니다.

몇 가지 테스트와 워크로드만으로 웹 전체를 시뮬레이션할 수는 없지만, Speedometer 3를 구축하면서 사용자 경험에 중요한 항목을 선택하기 위한 몇 가지 기준을 세웠습니다. 이제 우리는 그 어느 때보다 실제 웹을 잘 나타내는 벤치마크에 가까워졌습니다. Speedometer 워크로드가 어떻게 진화했는지 살펴보겠습니다.

워크로드는 어떻게 변경되었나요?

목표는 오늘날의 웹을 대표하는 워크로드를 사용하는 것이었으므로, 이전 Speedometer에서 사용된 워크로드를 검토하고 어떤 변경이 필요한지 결정해야 했습니다. 어떤 프레임워크가 여전히 유효한지, 어떤 앱의 업데이트가 필요한지, 그리고 이전 버전에서 캡처하지 못한 작업 유형은 무엇인지 결정해야 했습니다. Speedometer 2에서는 모든 워크로드가 서로 다른 JS 프레임워크로 구현된 할 일 관리(Todo) 앱의 변형이었습니다. 지난 6년 동안 웹이 진화함에 따라, 널리 보급된 다양한 JavaScript 및 브라우저 API를 놓치고 있었으며, 앱들이 이전보다 훨씬 더 크고 복잡해졌다는 사실을 발견했습니다. 그 결과, 포함된 프레임워크 목록을 변경하고 더 넓은 범위의 API와 기능을 다루는 더 다양한 워크로드를 추가했습니다.

프레임워크

포함할 프레임워크를 결정하기 위해 HTTP Archive의 데이터를 사용했으며, 모든 브라우저 엔진 개발사와 논의하여 광범위한 구현체를 포함하도록 했습니다. 초기 평가를 위해 2023년 3월의 HTTP Archive 스냅샷을 활용하여 복잡한 웹 앱을 구축하는 데 현재 가장 많이 사용되는 상위 JavaScript UI 프레임워크를 파악했습니다.

또 다른 접근 방식은 개발자들 사이의 인기도를 기준으로 포함 여부를 결정하는 것입니다. 현재 생산 환경에서의 사용량은 낮을 수 있지만 앞으로 채택이 늘어날 것으로 예상되는 "모멘텀"이 있는 프레임워크를 포함해야 할까요? 이는 판단하기 다소 어렵고 단독 지표로 삼기에 이상적이지 않을 수 있습니다. 모멘텀을 평가하는 한 가지 데이터 포인트는 프레임워크의 월간 NPM 다운로드 수일 수 있습니다.

다음은 2023년 3월 기준 동일한 15개 프레임워크의 NPM 다운로드 수입니다.

두 가지 데이터 포인트를 바탕으로 프레임워크를 잘 대변할 수 있다고 생각되는 목록을 결정했습니다. 단순한 Todo 앱 대신 완전히 새로운 유형의 워크로드를 위한 공간을 확보하기 위해 목록을 작게 유지했습니다. 또한 현재 사용량을 기준으로 각 프레임워크에 대해 일반적으로 사용되는 버전을 선택했습니다.

또한 이전의 JavaScript 구현체를 업데이트하고 바닐라 자바스크립트로 구현된 새로운 웹 컴포넌트 기반 버전을 포함했습니다.

더 다양한 워크로드

단순한 할 일 목록은 기능의 일부만 테스트합니다. 예를 들어, 브라우저가 복잡한 Flexbox 및 Grid 레이아웃을 얼마나 잘 처리하는지, SVG 및 Canvas 렌더링을 어떻게 캡처할 수 있는지, 실제 웹사이트에서 일어나는 더 현실적인 시나리오를 어떻게 포함할 수 있는지 등이 중요합니다.

우리는 관심 영역을 DOM, 레이아웃, API, 패턴으로 수집하고 분류하여, 이러한 영역을 테스트할 수 있는 잠재적 워크로드와 일치시켰습니다. 또한 텍스트 편집, 차트 렌더링, 사이트 네비게이션 등 관심 카테고리를 포함하는 사용자 여정을 수집했습니다.

포함하지 못한 영역이 여전히 많지만, 최종 워크로드 목록은 더 큰 다양성을 보여주며 Speedometer의 향후 버전이 현재 목록을 토대로 더욱 발전하기를 바랍니다.

검증

Chrome Aurora 팀은 Chrome V8 팀과 협력하여 위의 가설들을 검증했습니다. Chrome에서는 runtime-call-stats를 사용하여 각 웹 API(및 여러 내부 구성 요소)에서 소요된 시간을 측정할 수 있습니다. 이를 통해 특정 API가 얼마나 지배적인지 통찰력을 얻을 수 있습니다.

Speedometer 2.1을 살펴보면, 벤치마크 시간의 불균형할 정도로 많은 양이 innerHTML에서 소비되는 것을 볼 수 있습니다.

innerHTML은 중요한 웹 API이지만, Speedometer 2.1에서는 과하게 대표되고 있었습니다. 새로운 3.0 버전에서 동일한 분석을 수행하면 약간 다른 그림이 그려집니다.

innerHTML이 여전히 존재하지만, 전체 기여도는 약 14%에서 4.5%로 줄어들었습니다. 결과적으로 더 많은 DOM API가 최적화될 수 있도록 더 나은 분포를 얻게 되었습니다. 또한 v3.0의 새로운 워크로드 덕분에 몇 가지 Canvas API가 목록에 포함된 것을 확인할 수 있습니다.

빠르고 안정적인 벤치마크에서 웹 전체를 완벽하게 표현하는 것은 불가능하겠지만, Speedometer 3.0이 올바른 방향으로 나아가는 거대한 발걸음임은 분명합니다.

최종적으로 다음 섹션에 제시된 워크로드 목록이 포함되었습니다.

어떤 워크로드들이 포함되어 있나요?

TodoMVC

많은 개발자들이 TodoMVC 앱을 알고 계실 것입니다. 학습을 위한 인기 있는 리소스로, 다양한 프레임워크로 구현된 폭넓은 TodoMVC 구현체를 제공합니다.

TodoMVC는 사용자가 할 일(태스크)을 추적할 수 있는 할 일 관리 애플리케이션입니다. 사용자는 새 태스크를 입력하고, 기존 태스크를 업데이트하고, 완료로 표시하거나 삭제할 수 있습니다. 기본적인 CRUD 작업 외에도 TodoMVC 앱에는 몇 가지 추가 기능이 있습니다. 뷰를 "모두(all)", "진행 중(active)", "완료(completed)" 태스크로 변경할 수 있는 필터와 완료해야 할 진행 중인 태스크 수를 보여주는 상태 텍스트가 있습니다.

Speedometer에서는 할 일 항목을 위한 로컬 데이터 소스를 도입하여, 테스트에서 할 일 앱을 채우는 데 사용했습니다. 이를 통해 다양한 언어의 더 큰 문자 세트를 테스트할 기회를 얻었습니다.

이 앱들에 대한 테스트는 모두 유사하며, 할 일 앱을 사용하는 전형적인 사용자 여정과 관련이 있습니다.

1. 태스크 추가
2. 태스크를 완료로 표시
3. 태스크 삭제
4. 1~3단계를 정해진 횟수만큼 반복

이 테스트들은 간단해 보이지만, DOM 조작을 벤치마킹할 수 있게 해줍니다. 다양한 프레임워크 구현체를 갖춤으로써 이를 수행하는 여러 다른 방식들도 다루게 됩니다.

복잡한 DOM / TodoMVC

복잡한 DOM 워크로드는 복잡한 웹 페이지를 모방한 정적 UI 셸 내에 다양한 TodoMVC 구현체를 임베딩합니다. 이는 복잡한 웹사이트 컨텍스트에서 겉보기에 고립된 작업(예: 할 일 항목 추가/삭제)을 실행할 때 성능에 미치는 영향을 캡처하기 위한 것입니다. 고립된 TodoMVC 워크로드에서는 명확하지 않은 작은 성능 저하가 더 큰 애플리케이션에서는 증폭되므로, 실제 세상의 영향을 더 잘 포착할 수 있습니다.

테스트는 복잡한 DOM 및 CSSOM 환경에서 실행되는 TodoMVC 테스트와 유사합니다. 이는 브라우저가 손쉽게 처리해야 하는 추가적인 복잡성 계층을 도입합니다.

단일 페이지 애플리케이션 (뉴스 사이트)

단일 페이지 애플리케이션(SPA)은 스트리밍, 게임, 소셜 미디어 등 상상할 수 있는 거의 모든 웹 분야에서 널리 사용됩니다. SPA를 통해 페이지 간 이동 및 앱과의 상호작용을 포착할 수 있습니다. 주요 관심 영역을 결정론적인 방식으로 캡처할 수 있도록 SPA를 대표하는 뉴스 사이트를 선택했습니다. 중요한 점은 정적인 로컬 데이터를 사용하고 앱이 사용자에게 데이터를 표시하기 위해 네트워크 요청에 의존하지 않도록 보장했다는 것입니다.

두 가지 구현체가 포함되었습니다. 하나는 Next.js로, 다른 하나는 Nuxt로 구축되었습니다. 이를 통해 메타 프레임워크로 구축된 애플리케이션을 대표할 수 있는 기회를 가졌으며, 정적 출력을 사용하도록 주의를 기울였습니다.

뉴스 사이트 테스트는 메뉴 항목을 선택하고 사이트의 다른 섹션으로 이동하는 전형적인 사용자 여정을 모방합니다.

1. 네비게이션의 '더 보기(More)' 토글 클릭
2. 네비게이션 버튼 클릭
3. 1단계와 2단계를 정해진 횟수만큼 반복

이러한 테스트를 통해 다른 페이지로 이동할 때 표시되어야 하는 대량의 데이터를 변경함으로써 브라우저가 대규모 DOM 및 CSSOM 변경을 얼마나 잘 처리하는지 평가할 수 있습니다.

차트 앱 및 대시보드

차트 앱을 사용하면 다양한 워크로드에서 차트를 표시함으로써 SVG 및 Canvas 렌더링을 테스트할 수 있습니다. 이러한 앱은 금융 정보, 주식 차트 또는 대시보드를 표시하는 인기 사이트를 나타냅니다. SVG 렌더링과 Canvas API의 사용은 이전 버전의 Speedometer에서는 다루지 않았던 영역입니다.

Observable Plot은 점형 차트뿐만 아니라 누적 막대 차트를 표시합니다. 이는 정형 데이터를 시각화하고 SVG 요소를 출력하는 JavaScript 라이브러리인 D3를 기반으로 합니다. D3에 필요한 소스 데이터를 구축하기 위해 map, filter, flatMap 메서드를 사용하여 대규모 데이터 세트를 루프합니다. 결과적으로 이는 객체와 배열의 생성 및 복사를 실행합니다.

Chart.js는 JavaScript 차트 라이브러리입니다. 포함된 워크로드는 투명도가 있는 경우와 없는 경우 모두에 대해 Canvas API를 사용하여 산점도 그래프를 표시합니다. 이는 이전 워크로드와 동일한 데이터를 사용하지만 준비 단계가 다릅니다. 이 경우 공항 간의 거리를 계산하기 위해 삼각 함수를 많이 사용합니다.

React Stockcharts는 주식 대시보드를 표시합니다. 모든 계산에는 D3를 기반으로 하지만 React를 사용하여 SVG를 직접 출력합니다.

Webkit Perf-Dashboard는 WebKit의 다양한 성능 지표를 추적하는 데 사용되는 애플리케이션입니다. 이 대시보드는 Canvas 드로잉과 UI를 위해 웹 컴포넌트를 사용합니다.

이러한 워크로드들은 차트와 상호작용하여 SVG 또는 Canvas가 포함된 DOM 조작을 테스트합니다. 예를 들어, Observable Plot 워크로드의 상호작용은 다음과 같습니다.

1. 데이터 준비: D3가 이해하는 출력 구조로 입력 데이터 세트를 계산합니다.
2. 누적 차트 추가: SVG 요소를 사용하여 차트를 그립니다.
3. 입력 슬라이더를 변경하여 계산 매개변수를 변경합니다.
4. 1단계와 2단계를 반복합니다.
5. 리셋: 뷰를 지웁니다.
6. 점형 차트 추가: 다른 드로잉 프리미티브를 테스트하기 위해 다른 유형의 그래프(막대 대신 점)를 그립니다. 이는 또한 거듭제곱 스케일(power scale)을 사용합니다.

코드 에디터

WYSIWYG 텍스트 및 코드 에디터와 같은 에디터를 사용하면 라이브 텍스트 편집 및 폼 상호작용 캡처에 집중할 수 있습니다. 전형적인 시나리오로는 이메일 작성, 웹사이트 로그인, 온라인 폼 작성 등이 있습니다. TodoMVC 앱에도 일부 폼 상호작용이 존재하지만, 에디터 워크로드는 대규모 데이터 세트를 사용하여 성능을 더 정확하게 평가할 수 있게 해줍니다.

Codemirror는 다양한 편집 기능을 지원하는 텍스트 입력 필드를 구현하는 코드 에디터입니다. 여러 언어와 프레임워크가 지원되며, 이 워크로드에서는 Codemirror의 JavaScript 라이브러리를 사용했습니다.

Tiptap 에디터는 프레임워크에 구애받지 않는 헤드리스 리치 텍스트 에디터로, 커스터마이징과 확장이 가능합니다. 이 워크로드는 Tiptap을 기반으로 하며 상호작용을 위한 간단한 UI를 추가했습니다.

두 앱 모두 다음과 같은 방식으로 대량의 데이터에 대한 DOM 삽입 및 조작을 테스트합니다.

1. 편집 가능한 요소 생성
2. 긴 텍스트 삽입: Codemirror는 React의 개발 번들을 사용하고, TipTap은 프루스트의 '스완네 집 쪽으로(Du Côté de Chez Swann)' 발췌본을 로드합니다.
3. 텍스트 하이라이트: Codemirror는 구문 강조(syntax highlighting)를 켜고, TipTap은 모든 텍스트를 굵게 설정합니다.

맺음말

모든 주요 브라우저 엔진 개발사와 협력하고 워크로드에 함께 기여할 수 있었던 것은 독특한 경험이었으며, 브라우저 벤치마킹 분야에서 지속적인 협력을 기대하고 있습니다.

Speedometer의 새 버전을 확인하고 즐겨 사용하는 브라우저에서 테스트해 보십시오. 결과를 분석하고, 저희 저장소를 확인하며, 개선 사항이나 다음 버전에 포함되었으면 하는 워크로드 아이디어가 있다면 자유롭게 이슈를 남겨 주시기 바랍니다. 저희는 앞으로 더 빈번한 릴리스 일정을 목표로 하고 있으며, 기여하고 싶은 프레임워크 제작자분들은 Github에 이슈를 남겨 논의를 시작해 주시기 바랍니다.

작성자: Thorsten Kober, Chrome Aurora