W3C 권고안으로 급부상 중인 웹 성능 API
W3C 웹 Performance 작업 그룹은 최근 W3C 권고안으로 세 가지 규격을 공표했습니다. 이는 모든 주요 브라우저 공급업체에서 완벽하게 구현되며, 이로써 개발자들은 웹 응용 프로그램의 성능을 더욱 정확하게 측정할 수 있게 되었고 웹 속도도 높일 수 있게 되었습니다. 지난 3년간 Microsoft, Google, Mozilla, Intel, Facebook과 같은 기업들은 작업 그룹의 Navigation Timing, High Resolution Time, Page Visibility 인터페이스의 표준화를 위해 노력했습니다. 이러한 권고안이 빠르게 채택되고 있는 것을 보면 업계와 커뮤니티가 W3C를 위해 함께 힘을 모을 때 어떤 일들이 가능한지를 알 수 있습니다.
웹 속도를 높이려면 개발자들이 웹 응용 프로그램의 성능 특성을 정확하게 측정할 수 있어야 하고 기본 하드웨어를 효과적으로 사용하여 응용 프로그램의 성능을 향상시킬 수 있어야 합니다. 이러한 문제를 극복하기 위해 웹 성능 작업 그룹은 이 문제를 해결할 수 있는 15가지 다양한 규격을 연구했습니다. 최근에 작업 그룹에서 수정한 모든 규격에 대한 기술 성숙 단계는 아래 표에서 확인할 수 있습니다.
| 규격 | 편집자 초안 | 첫 번째 공개 작업 초안 | 마지막 호출 | 권고 후보안 | 제안 권고안 | 권고안 |
|---|---|---|---|---|---|---|
| 탐색 타이밍 | 2010년 9월 | 2010년 10월 | 2011년 1월 | 2011년 3월 | 2012년 7월 | 2012년 12월 |
| 리소스 타이밍 | 2010년 9월 | 2011년 5월 | 2011년 8월 | 2012년 5월 | ||
| 사용자 타이밍 | 2010년 10월 | 2011년 8월 | 2011년 9월 | 2012년 7월 | ||
| 성능 시간 표시줄 | 2011년 7월 | 2011년 8월 | 2011년 9월 | 2012년 7월 | ||
| 고분해능 시간 | 2012년 2월 | 2012년 3월 | 2012년 3월 | 2012년 5월 | 2012년 10월 | 2012년 12월 |
| 페이지 표시 유형 | 2011년 4월 | 2011년 6월 | 2011년 7월 | 2012년 7월 | 2013년 2월 | 2013년 5월 |
| 그림판 알림 표시 | 2011년 5월 | 2011년 6월 | 2012년 2월 | |||
| 탐색 타이밍 L2(최신) | 2013년 1월 | 2013년 1월 | ||||
| 효율적인 스크립트 일드 | 2011년 6월 | |||||
| 고분해능 시간 L2(최신) | 2013년 4월 | |||||
| 신호(최신) | 2013년 3월 | |||||
| 리소스 우선순위(최신) | 2013년 4월 | |||||
| 탐색 오류 로깅(최신) | 2013년 4월 | |||||
| 리소스 오류 로깅(최신) | 2013년 4월 | |||||
| 사전 렌더링(최신) |
Navigation Timing, Resource Timing, User Timing, Performance Timeline 규격은 개발자들이 문서 탐색 타이밍과 페이지 리소스 가져오기, 개발자 스크립트 실행을 더욱 정확하게 측정할 수 있도록 도와줍니다. 이러한 API들이 있기 전에는 이러한 데이터를 쉽게 구할 수 없었습니다. 탐색 타이밍은 W3C 권고안으로 게시되었고 모든 주요 브라우저 공급업체가 지원하고 있습니다. 다른 세 가지 인터페이스는 현재 권고 후보안 상태로 두 군데의 브라우저 공급업체에서 완벽하게 구현될 수 있도록 대기 중입니다. IE10는 현재 이 모든 인터페이스가 구현되는 유일한 브라우저입니다. 하지만 다른 공급업체들도 이를 구현할 수 있도록 노력하고 있습니다.
이러한 성능 메트릭이 최대한 가장 정확한 방법으로 측정될 수 있도록 High Resolution Time 규격은 개발자들이 서브 밀리초의 정확성으로 작업을 측정할 수 있게 합니다. 이 인터페이스는 성능 메트릭의 정확한 측정이 가능하다는 장점뿐만 아니라 프레임 속도 계산, 애니메이션 동기화, 오디오 신호 측면에서도 더 나은 프레임을 제공합니다. 이 인터페이스는 W3C 권고안으로 게시되었으며 모든 브라우저 공급업체에서 규격으로 정의된 performance.now() 방식을 구현합니다.
Page Visibility API에서는 페이지의 현재 표시 상태를 프로그래밍 방식으로 결정할 수 있습니다. 따라서 개발자들은 이 데이터를 사용하여 CPU 효율과 전원 효율을 향상시키는 방법(예: 이 페이지가 배경 탭에 있을 때 작업 속도를 낮추는 것 등)을 선택할 수 있습니다. 이 규격 또한 W3C 권고안으로 게시되었으며 모든 주요 브라우저 공급업체에서 구현됩니다.
Timing Control for Script-Based Animations, Efficient Script Yielding 규격을 통해 개발자들은 CPU 효율과 전원 효율이 더 뛰어난 웹 응용 프로그램을 개발할 수 있습니다. 스크립트 기반 애니메이션의 타이밍 제어 규격에서 비롯된 requestAnimationFrame API에서는 보다 효율적인 JavaScript 애니메이션 생성이 가능합니다. 모든 브라우저 공급업체가 이 인터페이스를 완벽하게 지원하고 있으며, 작업 그룹은 이 규격을 후보 권고안으로 게시하기 위해 최선을 다하고 있습니다. 효율적인 스크립트 일드 규격의 setImmediate API에서는 개발자들이 제어 흐름을 효율적으로 사용자 에이전트에 일드하고 바로 콜백을 받으며 CPU를 활용할 수 있습니다. IE10는 이 인터페이스를 최초로 구현한 브라우저입니다.
올해 작업 그룹은 현재 작업 그룹 내에서 논의되고 있는 편집자들의 초안을 바탕으로 새로운 아이디어를 찾기 시작했습니다. Beacon API는 언로드 이벤트를 차단하지 않고 스크립트가 데이터를 웹 서버에 비동기식으로 전송하는 것을 도와주기 위한 것입니다. 언로드 이벤트가 차단되면 다음 탐색의 성능에 대한 인식에 나쁜 영향을 줄 수 있기 때문입니다. Resource Priorities API는 웹 개발자가 리소스 다운로드 우선순위에 대한 힌트를 제공하는 방법을 정의하여 페이지 로드 시간이 개선되도록 하는 데 도움을 줍니다. 타이밍 규격으로 인한 당연한 결과로서 Navigation Error과 Resource Error Logging 규격은 개발자들이 오류와 그들의 응용 프로그램 유용성을 더욱 잘 이해할 수 있도록 도와줍니다. Navigation Timing Level L2 규격에는 탐색 타이밍을 지원하는 고분해능 시간, 성능 시간 표시줄이 추가되었습니다. 또한 High Resolution Time L2 규격에는 웹 작업자를 지원하는 기능이 추가되었습니다. 이는 단지 작업 그룹에서 현재 논의되고 있는 초안 중 일부일 뿐이며, 사전 렌더링과 기타 진단 분야에 대한 더 많은 규격 초안을 곧 선보이게 될 것입니다.
W3C 웹 성능 작업 그룹은 새로운 아이디어가 얼마나 빠르게 상호 운용성 표준(개발자가 최신 HTML5 지원 브라우저에 의존할 수 있는)이 될 수 있는가를 보여 주는 훌륭한 예입니다. 우리는 이 작업 그룹에 참여한 업계 및 커뮤니티 리더와 협력하여 개발자가 웹 속도를 높이는 데 도움이 될 수 있도록 상호 운용성 표준을 지속적으로 개선해 나갈 계획입니다.
감사합니다.
Internet Explorer 프로그램 관리자
Jatinder Mann