JavaScript 시작 성능 병목 현상 분석 및 솔루션-JS 튜토리얼-php.cn

웹 개발에서는 수요가 증가하고 코드 기반이 확장됨에 따라 결국 우리가 게시하는 웹 페이지도 점차 확장됩니다. 그러나 이러한 확장은 더 많은 전송 대역폭을 차지한다는 의미일 뿐만 아니라 사용자가 웹을 검색할 때 성능이 더 나빠질 수 있음을 의미합니다. 브라우저가 특정 페이지가 의존하는 스크립트를 다운로드한 후에도 여전히 구문 분석, 해석 및 실행을 거쳐야 합니다. 이 글에서는 브라우저의 JavaScript 처리 과정을 심층적으로 분석하고, 애플리케이션의 시작 시간에 영향을 미치는 원인을 찾아내고, 개인적인 경험을 바탕으로 그에 맞는 솔루션을 제안하겠습니다. 되돌아보면, 우리는 JavaScript 구문 분석/컴파일 단계를 최적화하는 방법에 대해 구체적으로 생각하지 않았습니다. 우리는 구문 분석기가 <script> 태그를 발견한 후 즉시 구문 분석 작업을 완료할 것이라고 예상했지만 이는 분명히 헛된 꿈입니다. 다음 그림은 V8 엔진의 작동 원리에 대한 개요입니다.

주요 단계를 심층적으로 분석해 보겠습니다.

애플리케이션 시작 시간을 늦추는 것은 무엇입니까?

시작 단계에서는 JavaScript 엔진이 실행되는 동안 구문 분석, 컴파일 및 스크립트 실행이 대부분의 시간을 차지합니다. 즉, 이러한 프로세스로 인해 발생하는 지연은 실제로 사용자의 상호 작용 지연을 반영합니다. 예를 들어 사용자가 버튼을 보았지만 실제로 클릭하기까지 몇 초가 걸리므로 사용자 경험에 큰 영향을 미칩니다.

위 그림은 Chrome Canary에 내장된 V8 RunTime Call Stats를 사용하여 웹사이트를 분석한 결과입니다. 데스크톱 브라우저에서 구문 분석 및 컴파일이 수행된다는 점에 유의하세요. up 시간은 여전히 꽤 길고, 모바일 단말기에서 걸리는 시간은 더욱 깁니다. 실제로 Facebook, Wikipedia, Reddit 등 대형 웹사이트에서 구문 분석 및 컴파일에 소요되는 시간은 무시할 수 없습니다.

위 그림의 분홍색 영역은 V8에 소요된 시간 Blink의 C++에 소요된 시간과 비교할 때 주황색과 노란색은 각각 구문 분석 및 컴파일에 소요되는 시간 비율을 나타냅니다. Facebook의 Sebastian Markbage와 Google의 Rob Wormald도 Twitter에 JavaScript의 긴 구문 분석 시간이 무시할 수 없는 문제가 되었다고 게시했습니다. 후자도 이 부분이 Angular를 시작할 때 주요 소비 중 하나라고 말했습니다.

모바일 단말기의 물결이 커지면서 우리는 잔인한 사실에 직면하게 되었습니다. 모바일 단말기에서 동일한 패키지 본체를 구문 분석하고 컴파일하는 데 드는 비용은 모바일 단말기에서 발생하는 비용과 동일합니다. 데스크탑 브라우저는 2~5배 더 오래 걸립니다. 물론 iPhone이나 Pixel과 같은 고급형 휴대폰은 Moto G4와 같은 중급형 휴대폰보다 훨씬 더 나은 성능을 발휘할 것입니다. 일반 및 저가형 휴대폰:

위 그림은 일부 데스크톱 브라우저와 모바일 브라우저 간의 1MB JavaScript 패키지 본문 구문 분석 시간을 비교한 것입니다. 서로 다른 구성을 가진 휴대폰 사이에는 큰 차이가 있습니다. 애플리케이션 패키지 본문이 이미 매우 큰 경우 코드 분할, TreeShaking, Service Workder 캐싱 등과 같은 일부 최신 패키징 기술을 사용하면 시작 시간에 큰 영향을 미칩니다. 다른 관점에서 보면 작은 모듈이라 할지라도 코드가 제대로 작성되지 않았거나 종속성 라이브러리가 좋지 않으면 메인 스레드가 컴파일이나 중복 함수 호출에 많은 시간을 소비하게 됩니다. 실제 성능 병목 현상을 찾아내기 위해서는 종합 평가의 중요성을 분명히 이해해야 합니다.

JavaScript 구문 분석 및 컴파일이 대부분의 웹사이트에서 병목 현상을 일으키나요?

나는 Facebook이 아니라고 누군가가 말하는 것을 여러 번 들었습니다.
언급하신 JavaScript 구문 분석 및 컴파일이 다른 웹사이트에 어떤 영향을 미칠까요? 나 역시 이 문제에 대해 궁금해서 React, Angular, Ember, Vue와 같은 인기 있는 프레임워크나 라이브러리가 포함된 6,000개 이상의 웹사이트를 분석하는 데 두 달을 보냈습니다. 대부분의 테스트는 WebPageTest를 기반으로 하므로 이러한 테스트 결과를 쉽게 재현할 수 있습니다. 광섬유 접속이 가능한 데스크톱 브라우저는 사용자 상호작용을 허용하는 데 약 8초가 걸리는 반면, 3G 환경의 Moto G4는 사용자 상호작용을 허용하는 데 약 16초가 걸립니다.

대부분의 애플리케이션은 데스크톱 브라우저의 JavaScript 시작 단계(문법 구문 분석, 컴파일, 실행)에서 약 4초를 소비합니다:

모바일 브라우저에서는 구문을 구문 분석하는 데 약 36% 더 많은 시간이 걸립니다.

또한 통계에 따르면 모든 웹사이트가 사용자에게 거대한 JS 패키지를 제공하는 것은 아닙니다. 사용자가 다운로드한 Gzip 압축 패키지의 평균 크기는 410KB입니다. 이는 기본적으로 이전에 HTTPArchive에서 공개한 420KB 데이터와 일치합니다. 그러나 최악의 웹사이트는 10MB의 스크립트를 사용자에게 직접 전달하는데, 이는 그야말로 끔찍한 일입니다.

위의 통계를 통해 패키지의 양이 중요하다는 것을 알 수 있지만, 이것이 구문 분석 및 컴파일에 소요되는 시간이 반드시 늘어나는 것은 아닙니다. 패키지 볼륨 성장과 선형 성장. 일반적으로 작은 JavaScript 패키지는 더 빠르게 로드됩니다(브라우저, 장치 및 네트워크 연결의 차이를 무시함). 그러나 200KB의 동일한 크기를 사용하면 다른 개발자 패키지의 구문 분석 및 컴파일 시간이 엄청납니다. 서로 다르며 비교할 수 없습니다.

JavaScript 구문 분석 시간을 줄이려면 어떻게 해야 하나요?

JavaScript 패키지 본문 크기를 줄입니다. 또한 위에서 언급했듯이 패키지 본체가 작을수록 구문 분석 작업량이 적어 구문 분석 및 컴파일 단계에서 브라우저의 시간 소모도 줄일 수 있습니다.
코드 분할 도구를 사용하여 요청 시 코드를 전달하고 남은 모듈을 지연 로드하세요. PRPL과 같은 모델은 경로 기반 그룹화를 장려하고 현재 Flipkart, Housing.com 및 Twitter에서 널리 사용되고 있으므로 이것이 아마도 최선의 접근 방식일 것입니다.
스크립트 스트리밍: 과거 V8에서는 개발자가 async/defer을 사용하여 스크립트 스트리밍을 기반으로 10~20%의 성능 향상을 달성하도록 권장했습니다. 이 기술을 사용하면 HTML 파서가 해당 스크립트 로딩 작업을 전용 스크립트 스트리밍 스레드에 할당하여 문서 구문 분석이 차단되는 것을 방지할 수 있습니다. V8에서는 가능한 한 빨리 더 큰 모듈을 로드할 것을 권장합니다. 결국 우리에게는 스트리머 스레드가 하나만 있기 때문입니다.
종속성 분석 비용을 평가합니다. React 대신 크기가 더 작고 구문 분석 및 컴파일 시간이 덜 필요한 Preact 또는 Inferno를 사용하는 것과 같이 기능은 동일하지만 로드 속도가 더 빠른 종속성을 선택하기 위해 최선을 다해야 합니다. Paul Lewis는 또한 최근 기사에서 프레임워크 시작 비용에 대해 논의했는데, 이는 Sebastian Markbage의 다음과 같은 진술과 일치합니다. 프레임워크의 시작 비용을 평가하는 가장 좋은 방법은 인터페이스를 먼저 렌더링한 다음 삭제하고 마지막으로 다시 렌더링하는 것입니다. 첫 번째 렌더링 프로세스에는 분석 및 컴파일이 포함되며, 비교를 통해 프레임워크의 시작 소비를 찾을 수 있습니다.

JavaScript 프레임워크가 AOT(ahead-of-time) 컴파일 모드를 지원하는 경우 구문 분석 및 컴파일 시간을 효과적으로 줄일 수 있습니다. Angular 애플리케이션은 다음 패턴의 이점을 얻습니다.

최신 브라우저는 구문 분석 및 컴파일 속도를 어떻게 향상합니까?

낙담하지 마십시오. 시작 시간을 단축하는 방법에 대해 고민하는 사람은 당신뿐만이 아닙니다. 우리 V8 팀도 열심히 노력해 왔습니다. 이전 평가 도구인 Octane이 실제 시나리오를 잘 시뮬레이션한 것으로 나타났습니다. 이는 마이크로 프레임워크 및 콜드 스타트 측면에서 실제 사용자 습관과 매우 일치합니다. 이러한 도구를 기반으로 V8 팀은 이전 작업에서 약 25%의 시작 성능 향상을 달성했습니다.

이 섹션에서는 지난 몇 년 동안 구문 분석 및 컴파일 시간을 향상시키는 기술에 대해 설명합니다.

코드 캐시

Chrome 42에서는 컴파일된 코드 복사본을 저장하는 메커니즘을 제공하는 소위 코드 캐시 개념을 도입하기 시작했습니다. 이렇게 하면 사용자가 두 번째로 페이지를 방문할 때 스크립트 크롤링, 구문 분석 및 컴파일 단계를 피할 수 있습니다. 또한 이 메커니즘을 통해 반복 방문 시 컴파일 시간을 약 40% 줄일 수 있다는 사실도 확인했습니다. 여기서는 몇 가지 세부 사항을 자세히 소개하겠습니다.

코드 캐싱은 다음과 같은 스크립트를 수행합니다. 72시간 동안 반복적으로 실행됩니다.
서비스 워커 스크립트의 경우 코드 캐싱은 72시간 이내에 스크립트에도 작동합니다.
서비스 워커를 사용하여 캐시 저장소에 캐시된 스크립트의 경우 코드 캐싱은 스크립트가 처음 실행될 때 작동합니다.

간단히 말하면, 적극적으로 캐시된 JavaScript 코드의 경우 최대 세 번째 호출에서 구문 분석 및 컴파일 단계를 건너뛸 수 있습니다. chrome://flags/#v8-cache-strategies-for-cache-storage을 사용하여 차이점을 확인하거나 js-flags=profile-deserialization을 설정하여 Chrome을 실행하여 코드가 코드 캐시에서 로드되었는지 확인할 수 있습니다. 그러나 코드 캐싱 메커니즘은 주로 전역 변수를 설정하는 데 사용되는 최상위 코드를 참조하는 컴파일된 코드만 캐시한다는 점에 유의해야 합니다. 함수 정의와 같은 지연 컴파일된 코드는 캐시되지 않지만 V8에는 IIFE도 포함되어 있으므로 이러한 함수도 캐시할 수 있습니다.

스크립트 스트리밍

스크립트 스트리밍을 사용하면 백그라운드 스레드에서 비동기 스크립트를 구문 분석할 수 있으므로 페이지 로딩 시간이 약 10% 향상될 수 있습니다. 위에서 언급한 것처럼 이 메커니즘은 동기화 스크립트에도 작동합니다.

이 기능은 처음으로 언급되므로 V8에서는 모든 스크립트를 허용하며 차단된 <script src=''> 스크립트도 백그라운드 스레드로 구문 분석할 수 있습니다. 그러나 단점은 현재 스트리밍 백그라운드 스레드가 하나만 있다는 것이므로 크고 중요한 스크립트를 먼저 구문 분석하는 것이 좋습니다. 실제로는 <script defer> 블록 내에 <head>를 추가하여 브라우저 엔진이 구문 분석해야 하는 스크립트를 가능한 한 빨리 발견한 다음 이를 처리를 위해 백그라운드 스레드에 할당하는 것이 좋습니다. 또한 DevTools 타임라인을 확인하여 스크립트가 백그라운드에서 구문 분석되는지 확인할 수 있습니다. 특히 구문 분석해야 하는 중요한 스크립트가 있는 경우 스크립트가 스트리밍 스레드에 의해 구문 분석되는지 확인해야 합니다.

문법 구문 분석 및 컴파일 최적화

또한 현재 V8 메인 스레드에서 가장 큰 병목 현상이 되고 있는 보다 가볍고 빠른 파서를 구축하기 위해 노력하고 있습니다. 소위 비선형 분석 소비에 있습니다. 예를 들어 다음 코드 조각이 있습니다.

(function (global, module) { … })(this, function module() { my functions })

로그인 후 복사

V8은 메인 스크립트를 컴파일할 때 module 모듈이 필요한지 모르므로 일시적으로 컴파일을 포기합니다. 그리고 module을 컴파일할 때 모든 내부 기능을 다시 분석해야 합니다. 이것이 소위 V8 구문 분석 시간의 비선형성에 대한 이유입니다. N 레벨 깊이의 모든 함수는 N 번 재분석될 수 있습니다. V8은 처음 컴파일할 때 이미 모든 내부 함수에 대한 정보를 수집할 수 있으므로 V8은 향후 컴파일에서 모든 내부 함수를 무시합니다. module 형식의 위 함수에 대해서는 성능이 크게 향상될 것입니다. 자세한 내용은 The V8 Parser(s) — Design, Challenges, and Parsing JavaScript Better를 읽어보는 것이 좋습니다. V8은 또한 시작 시 JavaScript 컴파일 프로세스가 백그라운드 스레드에서 실행될 수 있도록 적합한 오프로딩 메커니즘을 찾고 있습니다.

사전 컴파일된 JavaScript?

몇 년마다 누군가는 엔진이 미리 컴파일된 스크립트를 처리하기 위한 메커니즘을 제공해야 한다고 제안합니다. 즉, 개발자는 빌드 도구나 기타 서버 측 도구를 사용하여 스크립트를 바이트코드로 변환한 다음 직접 실행할 수 있습니다. 브라우저 이 바이트코드로 충분합니다. 내 개인적인 관점에서 볼 때, 바이트코드를 직접 전송한다는 것은 패키지 본체가 더 커진다는 것을 의미하므로 필연적으로 로딩 시간이 늘어나게 되며, 안전하게 실행될 수 있도록 코드에 서명해야 합니다. V8에 대한 우리의 현재 입장은 위에서 언급한 내부 재분석을 최대한 피하여 시작 시간을 개선하는 반면, 사전 컴파일은 추가적인 위험을 가져오는 것입니다. 그러나 V8은 현재 컴파일 효율성을 향상시키고 서비스 워커 캐시 스크립트 코드의 사용을 촉진하여 시작 효율성을 향상시키는 데 중점을 두고 있지만 모두가 이 문제에 대해 함께 논의하는 것을 환영합니다. 우리는 또한 BlinkOn7에서 Facebook 및 Akamai와 함께 사전 컴파일에 대해 논의했습니다.

JS 최적화 최적화

V8과 같은 JavaScript 엔진은 전체 구문 분석을 수행하기 전에 스크립트의 대부분의 함수를 사전 구문 분석합니다. 이는 주로 대부분의 페이지에 JavaScript 함수가 포함되어 있지 않기 때문입니다. 즉시 실행됩니다.

사전 컴파일은 브라우저 실행에 필요한 최소한의 기능 집합만 처리하여 시작 시간을 향상시킬 수 있지만, 이 메커니즘은 실제로 IIFE에 비해 효율성을 떨어뜨립니다. 엔진은 이러한 기능을 전처리하지 않기를 바라지만,optim-js와 같은 라이브러리보다 훨씬 덜 효과적입니다. Optimize-js는 엔진보다 먼저 스크립트를 처리하고 즉시 실행되는 함수에 대해 괄호를 삽입하여 더 빠른 실행을 보장합니다. 이러한 종류의 전처리는 즉시 실행될 수 있는 다수의 작은 모듈을 포함하는 Browserify 및 Webpack에서 생성된 패키지 본체에 매우 좋은 최적화 효과를 갖습니다. 이 작은 트릭은 V8이 사용하려는 것이 아니지만, 해당 최적화 메커니즘은 현 단계에서 도입되어야 합니다.

요약

시작 단계의 성능은 매우 중요합니다. 느린 구문 분석, 컴파일 및 실행 시간은 웹 페이지 성능의 병목 현상이 될 수 있습니다. 이 단계에서 페이지가 소비하는 시간을 평가하고 이를 최적화하는 적절한 방법을 선택해야 합니다. 앞으로도 V8의 시동 성능을 향상시키기 위해 최선을 다하겠습니다!

위 내용은 JavaScript 스타트업 성능 병목현상 분석 및 해결방법에 관한 내용입니다. 더 많은 관련 내용은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!