Google for Developers Korea Blog: 속도의 새로운 기준을 세워온 Chrome 탄생 10주년

속도의 새로운 기준을 세워온 Chrome 탄생 10주년

2018년 10월 5일 금요일

.post-body span { white-space: normal !important; }

<블로그 원문은 이곳에서 확인하실 수 있으며 번역 리뷰에는 조은(WebTech GDE) 님이 참여해 주셨습니다.>

속도는 10년 전 Chrome이 세상에 첫선을 보였을 때부터 Chrome의 네 가지 핵심 원칙 중 하나였습니다. 웹 개발자가 사용자에게 빠르면서 매력적인 웹 환경을 제공할 수 있기를 원했습니다. Chrome의 10번째 생일을 맞이하여 지난 10년간 속도 향상을 위해 어떤 일을 해왔는 지, 또 앞으로 무슨 일을 할 것인지 살펴보는 시간을 가지면 재미있을 거라 생각했습니다.

속도 향상에 기여하는 브라우저 내 다양한 컴포넌트

V8은 Chrome의 자바스크립트 및 WebAssembly 엔진입니다. 각종 웹페이지에서 자바스크립트 사용량이 늘면서 처리 속도가 빠른 엔진이 중요한 주춧돌 역할을 합니다. 수년간 V8을 위한 새로운 자바스크립트 실행 파이프라인 개발에 매달린 끝에, Ignition(새 인터프리터)과 TurboFan(최적화 컴파일러)을 출시했습니다. 이런 제품 덕분에 Speedometer 벤치마크에서 성능을 5~10% 끌어올릴 수 있었습니다. 스크립트 스트리밍을 사용해 다운로드를 시작하자마자 백그라운드 스레드에서 자바스크립트를 파싱함으로써 페이지 로드를 최대 10% 향상할 수 있었습니다. 다음으로 백그라운드 컴파일 기능을 추가하여 주 스레드 컴파일 시간을 최대 20% 단축했습니다.

Orinoco 프로젝트에서 진행한 작업을 통해 동시 가비지 컬렉션이 가능해지면서 사용 가능한 메인 스레드를 확보하고 버벅거리는 문제를 줄일 수 있었습니다. 또한 시간이 흐르면서 실제 환경에서의 자바스크립트 성능에 초점을 맞추는 방향으로 전환했고, 이를 계기로 React.js 런타임의 성능을 배가하고 Vue.js, Preact, Angular와 같은 라이브러리에 대한 성능을 최대 40% 향상했습니다. V8의 최초 커밋 이후로 병렬, 동시 및 증분 가비지 컬렉션을 통해 가비지 컬렉션에서 발생하는 버벅거림을 100배 이상 줄였습니다. 또한 WebAssembly를 구현하여 개발자가 예측 가능한 성능으로 웹에서 자바스크립트 코드가 아닌 코드를 실행할 수 있도록 하고 Liftoff 기본 컴파일러를 출시하여 WASM 앱을 빠르게 시작할 수 있도록 했습니다. 이처럼 새롭고 다양한 컴포넌트는 지난 10년간 기울인 노력의 결과물 중에서도 최근의 성과물일 뿐이며, 이러한 노력으로 새롭게 출시할 때마다 V8의 성능을 높여 지난 수년간 무려 20배나 개선하는 성과를 올렸습니다. Chart

Chart

지난 10년간 다양한 Chrome 릴리스에 대한 V8 Bench 점수. V8 Bench는 이전 Octane 벤치마크의 전신입니다. V8 Bench를 이 차트에 사용했는데, Octane과는 달리 초기 Chrome Beta를 비롯한 모든 Chrome 버전에서 실행 가능하기 때문입니다. Chrome은 SPDY, HTTP/2 및 QUIC를 통해 네트워크 프로토콜과 전송 레이어의 발전에도 핵심적인 역할을 했습니다. SPDY는 HTTP/1.1의 한계 극복을 지향하여 지금은 모든 최신 브라우저에서 지원하는 HTTP/2 프로토콜의 토대가 되었습니다. 이와 함께, Chrome 팀은 지연 시간이 사용자 경험을 더욱 향상하는 데 목적을 두고 있고 이제는 이면에서 적극적인 IETF 작업이 이루어지고 있는 QUIC에 대한 작업을 적극적으로 몇 번이고 반복했습니다. QUIC의 이점은 YouTube 같은 동영상 서비스에서 현저히 드러납니다. 사용자의 보고에 따르면 QUIC를 통해 동영상을 시청할 때 재버퍼링이 30% 감소한 것으로 나타났습니다.다음으로 등장하는 것은 Chrome의 렌더링 파이프라인입니다. 이 파이프라인은 웹페이지가 사용자에게 올바로 응답하고 60fps(초당 프레임 수)의 속도로 콘텐츠를 표시하도록 보장합니다. 콘텐츠를 60fps로 표시하려면 Chrome은 16ms에 하나씩 프레임을 렌더링해야 합니다. 여기에는 자바스크립트 실행, 스타일, 레이아웃, 그리기, 사용자 화면으로 픽셀 푸시 기능이 포함됩니다. 이 16ms의 시간 중에서 Chrome이 쓰는 시간이 짧아질수록 웹 개발자가 사용자를 위해 쓸 수 있는 시간은 더 늘어납니다. 렌더링 파이프라인 개선에는 페이지에서 다시 그려야 할 요소의 식별 방법 최적화와 시각적으로 겹치지 않는 세트의 추적 개선이 포함되었습니다. 이에 따라 화면에 새 프레임을 그리는 데 걸리는 시간이 최대 35% 줄었습니다.

2015년, Chrome 팀은 RAIL이라는 사용자 중심 성능 모델을 선보였습니다. 우리는 최근에 RAIL을 업데이트했습니다.그렇다면, 메모리 소비는 어떨까요? Chrome 63과 66 사이에 렌더링 프로세스 메모리 사용량에 있어 최대 20~30% 정도의 개선이 이루어진 것으로 관찰되었습니다. 이제 사이트 격리가 안착했으므로 이를 기반으로 빌드할 방법을 계속 탐구하기를 희망합니다. Ignition과 TurboFan 덕분에 V8의 전체 메모리 사용량이 감소하여 V8이 지원하는 모든 기기와 플랫폼에서 5~10% 정도의 메모리 사용량 감소 효과가 나타났습니다. 올해 일부 조사에서 웹 기반 사이트 중 7%가 메모리 누수의 영향을 받은 것으로도 밝혀졌는데 지금은 우리가 이를 완전히 해결한 상태입니다. DOM, CSS 그리고 IndexedDB 같은 저장 시스템을 비롯한 많은 컴포넌트가 Chrome의 속도 향상에 기여합니다. 성능 개선 사항에 대해 자세히 알아보려면 Chromium 블로그를 계속 지켜봐 주세요.

개발자에게 더욱 강력한 웹페이지 측정 및 최적화 능력 부여 어디서부터 사이트 개선 작업을 시작할지 파악하는 작업은 지루한 과정일 수 있습니다. 이에 도움을 드리고자, 실험실 환경에서의 신호와 사용자가 실제로 겪고 느끼는 경험을 이해하기 위한 여러 가지 도구를 탐구했습니다. 지난 수년간 Chrome DevTools Performance 패널은 실험실 설정에서 웹페이지가 표시되는 방식을 실황 분석한 결과를 시각화하는 강력한 수단이 되었습니다. 사이트에서 성능 향상의 기회를 찾는 데 드는 노력과 문제를 계속 줄이고 완화하기 위해, 우리는 Lighthouse를 연구했습니다. Lighthouse는 웹사이트의 품질을 분석하여 사이트의 성능을 명확한 측정 결과로서 보여주고 사용자 환경 개선을 위한 구체적인 지침을 제시해주는 도구입니다. DevTools Audits 패널 내부에서 직접 Lighthouse에 액세스하여 명령줄에서 각종 기능을 실행하거나 WebPageTest 등의 다른 개발 제품과 통합할 수 있습니다.

Chrome DevTools Audits 패널에서 실행 중인 Lighthouse

Lighthouse에서 제공하는 실험실 데이터를 보완하기 위해, 우리는 실제 상황에서 사용자가 겪고 느끼는 경험에 대한 필드 측정항목(예: First Contentful Paint, First Input Delay)에 개발자가 접근하는 데 도움이 되는 Chrome User Experience Report를 발표했습니다. 이제는 개발자가 자체적으로 맞춤 사이트 성능 보고서를 만들고 CrUX Dashboard를 사용하여 수백만 개의 출처에 대해 진행 상황을 추적할 수 있습니다.또한 개발자가 사이트 로드를 최적화하는 데 도움이 되는 Web Platform 기능도 다수 선보였습니다. Resource Hints와 <link rel=preload>를 도입함으로써 개발자가 어떤 리소스를 먼저 로드해야 하는지 브라우저에 알려줄 수 있게 되었습니다. 압축은 Brotli, 더 작은 웹 글꼴은 WOFF2, 이미지는 WebP 지원이 제일 먼저 떠오르는 것처럼, Chrome은 바이트 절감 접근 방법 지원을 구현한 최초의 브라우저 중 하나였습니다. 시간이 흐르면서 점점 더 많은 브라우저가 이러한 기능을 지원하는 변화를 흥미롭게 지켜보았습니다. Chrome은 페이지에 반복적으로 방문하는 경우를 대비하여 오프라인 캐싱과 네트워크 복원을 지원하는 서비스 워커를 구현했습니다. 다양하고 폭넓은 최신 브라우저에서 이 기능을 지원하게 되어 기쁩니다.

사실, Google 검색에서는 반복 검색에 대해 편의적으로 캐싱하기 위해 현재 서비스 워커와 네비게이션 미리 로드 기능을 사용합니다. 이에 따라 반복 방문할 경우 페이지 로드 시간이 2배 짧아졌습니다. 미래를 전망하자면 이미지와 iframe에 대한 네이티브 레이지 로딩과 같이 새롭게 등장하는 표준과 AV1 같은 이미지 형식이 사용자에게 효과적으로 콘텐츠를 전달하는 데 도움을 주게 될 가능성에 대한 기대감도 높습니다.
같은 데이터 요금제로 Chrome을 더 즐기세요지난 10년간 웹페이지 크기는 계속 증가했지만, 많은 사용자가 처음으로 온라인에 접속하면 데이터가 엄청나게 비싸거나 끔찍하게 느린 속도를 경험할 수 있습니다. 이런 분께 도움을 드리고자, Chrome은 지난 수년간 Chrome 데이터 절약 모드 같이 데이터 문제를 감안한 기능을 도입했습니다. 데이터 절약 모드는 페이지를 지능적으로 최적화하여 데이터 소비량을 최대 92%까지 절감합니다. 앞으로도 적극적으로 데이터 절약에 도움이 될 새로운 방법을 모색하겠습니다. 연결 속도가 최저 수준인 환경의 사용자를 위해, 우리는 필수 콘텐츠를 먼저 표시하는 더욱 스마트해진 페이지 최적화를 위해 Android용 Chrome 관련 작업을 진행해왔습니다. 이렇게 변환된 페이지는 모든 콘텐츠를 포함한 페이지보다 훨씬 빠르게 로드됩니다. 앞으로도 계속 충실도, 포함 범위, 성능 개선에 힘쓰겠습니다.우리는 데이터 사용량이나 네트워크 접속이 제한적인 사용자를 위한 보호 대책을 마련하기 위한 여러 가지 실험도 해왔습니다. 예를 들어 Chrome에 네이티브 레이지 로딩을 적용하는 방안뿐 아니라 페이지에 많은 데이터가 사용될 때 페이지에서의 추가 요청을 중지하는 옵션을 사용자에게 제공하는 등의 기능을 계속 연구하고 있습니다.
이제 시작일 뿐...이러한 변화는 개발자와 기업이 사용자에게 더 빠르게 유용한 콘텐츠를 제공하는 데 도움이 됩니다. 아직 해야 할 일이 많다는 점을 누구보다 잘 알고 있습니다. 앞으로 새롭게 다가올 10년도 페이지 로드 성능을 더욱 개선하는 데 노력을 아끼지 않을 것입니다. 게시자: Addy Osmani, 자바스크립트 지킴이