정보실

웹학교

정보실

javascript jQuery는 상위 5M 웹 사이트의 85 %에 포함됩니다

본문

소개 


JavaScript는 웹에서 대화형의 복잡한 환경을 구축 할 수 있는 스크립트 언어입니다. 

여기에는 사용자 상호 작용에 대한 응답, 페이지의 동적 내용 업데이트 등이 포함됩니다. 

이벤트가 발생할 때 웹 페이지의 작동 방식과 관련된 것은 JavaScript가 사용하는 것입니다.


전 세계 개발자들이 사용하는 많은 커뮤니티 구축 라이브러리 및 프레임워크와 함께 언어 사양 자체가 1995 년에 언어가 만들어진 이후로 변화하고 진화했습니다. 

JavaScript 구현 및 통역사도 계속 발전하여 많은 언어에서 언어를 사용할 수 있게 되었습니다. 웹 브라우저뿐만 아니라 환경.


https://almanac.httparchive.org/en/2019/javascript 


HTTP 아카이브는 매달 수백만 페이지를 크롤링하고 WebPageTest의 개인 인스턴스를 통해 실행하여 모든 페이지의 주요 정보를 저장합니다. 

(방법론에서 이에 대해 자세히 알아볼 수 있습니다). JavaScript와 관련하여 HTTP Archive는 전체 웹의 언어 사용법에 대한 광범위한 정보를 제공합니다. 

이 장에서는 이러한 여러 추세를 통합하고 분석합니다.


우리는 얼마나 많은 JavaScript를 사용합니까? 


JavaScript는 브라우저에 보내는 가장 비용이 많이 드는 리소스입니다. 

다운로드, 파싱, 컴파일 및 최종 실행이 필요했습니다. 브라우저가 스크립트를 구문 분석하고 컴파일하는 데 걸리는 시간을 크게 줄였지만 웹 페이지에서 JavaScript를 처리 할 때 다운로드 및 실행이 가장 비싼 단계가 되었습니다.


더 작은 JavaScript 번들을 브라우저로 전송하는 것이 다운로드 시간을 줄이고 페이지 성능을 향상 시키는 가장 좋은 방법입니다. 

하지만 실제로 얼마나 많은 JavaScript를 사용합니까?


 

그림1. 페이지 당 JavaScript 바이트 분포


위의 그림1은 50 번째 백분위 수 또는 중앙값에서 373KB의 JavaScript를 사용함을 보여줍니다. 

즉, 모든 사이트의 50%가 이보다 많은 JavaScript를 사용자에게 제공합니다.


이 숫자를 보면 너무 많은 JavaScript인지 궁금해 하는 것은 당연합니다. 그러나 페이지 성능 측면에서 영향은 전적으로 네트워크 연결 및 사용 된 장치에 달려 있습니다. 

다음 질문은 모바일과 데스크톱 클라이언트를 비교할 때 얼마나 많은 JavaScript를 제공합니까?


 

그림 2. 장치 별 페이지 당 JavaScript 배포


모든 백분위 수마다 모바일보다 데스크탑 장치에 약간 더 많은 JavaScript를 보냅니다.


처리 시간 


파싱 ​​및 컴파일 된 후, 브라우저에 의해 페치 된 JavaScript는 처리되기 전에 처리 (또는 실행)되어야 합니다. 장치는 다양하며 컴퓨팅 성능은 페이지에서 JavaScript를 처리하는 속도에 크게 영향을 줄 수 있습니다. 웹에서 현재 처리 시간은 얼마입니까?


다른 백분위 수에서 V8의 주요 스레드 처리 시간을 분석하여 아이디어를 얻을 수 있습니다.

 

그림3. 장치 별 V8 기본 스레드 처리 시간


모든 백분위 수마다 데스크탑보다 모바일 웹 페이지의 처리 시간이 더 길다. 데스크톱의 평균 총 메인 스레드 시간은 849ms이며 모바일은 2,436ms입니다.


이 데이터는 모바일 장치가 더 강력한 데스크탑 컴퓨터와 비교하여 JavaScript를 처리하는 데 걸리는 시간을 보여 주지만, 모바일 장치도 컴퓨팅 성능 측면에서 다양합니다. 다음 차트는 단일 웹 페이지의 처리 시간이 모바일 장치 클래스에 따라 크게 달라질 수 있는 방법을 보여줍니다.


JavaScript processing times for Reddit.com 

그림4. reddit.com의 JavaScript 처리 시간 2019 년 JavaScript 비용에서.


요청 수 


웹 페이지에서 사용하는 JavaScript의 양을 분석 할 때 탐색 할 가치가 있는 방법 중 하나는 배송 된 요청 수입니다. 

HTTP/2를 사용하면 여러 개의 작은 청크를 보내면 더 큰 모 놀리 식 번들을 보내는 것보다 페이지 로드가 향상 될 수 있습니다. 장치 클라이언트별로 분류하면 몇 개의 요청을 가져오고 있습니까?

 

그림5. 전체 JavaScript 요청의 분배


중앙값에서 19 개의 요청이 데스크톱에 전송되고 18 개의 요청이 모바일에 전송됩니다.


First-party vs. third-party 


지금까지 분석 된 결과 중 전체 크기와 요청 수가 고려되었습니다. 

그러나 대부분의 웹 사이트에서 가져 와서 사용되는 JavaScript 코드의 상당 부분이 타사 소스에서 제공됩니다.


타사 JavaScript는 외부의 타사 소스에서 가져올 수 있습니다. 광고, 분석 및 소셜 미디어 임베드는 모두 타사 스크립트를 가져 오기 위한 일반적인 사용 사례입니다. 

따라서 당연히 다음 질문으로 이어질 수 있습니다. 제 1자가 아닌 제 3자가 보낸 요청은 몇 건입니까?


 

그림 6. 데스크탑에 자사 및 써드 파티 스크립트 배포


 

그림 7. 모바일에서 퍼스트 및 써드 파티 스크립트 배포


모바일 및 데스크톱 클라이언트 모두에 대해 백분위 수마다 자사보다 많은 타사 요청이 전송됩니다. 이것이 놀라운 것처럼 보일 경우, 실제 공급되는 코드가 타사 공급 업체로부터 얼마나 많이 제공되는지 알아 봅시다.


 

그림 8. 데스크탑에 다운로드 된 총 JavaScript의 분포.


 

그림 9. 모바일에 다운로드 된 총 JavaScript의 분포.



중앙값에서 개발자가 모바일 및 데스크톱 용으로 작성한 자사 코드보다 89% 더 많은 타사 코드가 사용됩니다. 이는 타사 코드가 부풀리기의 가장 큰 기여자 중 하나 일 수 있음을 분명히 보여줍니다.


자원 압축 


브라우저-서버 상호 작용의 맥락에서 리소스 압축은 데이터 압축 알고리즘을 사용하여 수정 된 코드를 나타냅니다. 브라우저에서 요청한 대로 리소스를 정적으로 미리 또는 즉시 압축 할 수 있으며, 두 가지 방법 모두 전송 된 리소스 크기가 크게 줄어들어 페이지 성능이 향상됩니다.


여러 개의 텍스트 압축 알고리즘이 있지만 HTTP 네트워크 요청의 압축 및 압축 해제에는 주로 두 가지만 사용됩니다.

  • Gzip (gzip): 서버 및 클라이언트 상호 작용에 가장 널리 사용되는 압축 형식
  • Brotli (br): 압축률을 더욱 향상 시키는 새로운 압축 알고리즘. 브라우저의 90 %가 Brotli 인코딩을 지원합니다.


압축 된 스크립트는 일단 전송 된 브라우저에서 항상 압축 해제해야 합니다. 즉, 내용이 동일하게 유지되고 실행 시간이 최적화되지 않습니다. 

그러나 리소스 압축은 다운로드 시간을 항상 향상 시켜 가장 비싼 JavaScript 처리 단계 중 하나이기도 합니다. 

JavaScript 파일이 올바르게 압축 되도록 하는 것은 사이트 성능을 향상 시키는 데 가장 중요한 요소 중 하나 일 수 있습니다.


JavaScript 리소스를 압축하는 사이트는 몇 개입니까?


 

그림 10. gzip 또는 brotli를 사용하여 JavaScript 자원을 압축하는 사이트 백분율


대부분의 사이트는 JavaScript 리소스를 압축하고 있습니다. Gzip 인코딩은 사이트의 ~ 64-67 %에서 사용되고 Brotli는 ~ 14 %에서 사용됩니다. 압축 비율은 데스크톱과 모바일 모두에서 비슷합니다.


압축에 대한 자세한 분석은 "압축"장을 참조하십시오.


오픈 소스 라이브러리 및 프레임 워크 


오픈 소스 코드 또는 누구나 액세스하고 보거나 수정할 수 있는 허가 라이센스가 있는 코드. 작은 라이브러리에서 Chromium 및 Firefox와 같은 전체 브라우저에 이르기까지 오픈 소스 코드는 웹 개발 세계에서 중요한 역할을 합니다. 

JavaScript와 관련하여 개발자는 오픈 소스 도구를 사용하여 모든 유형의 기능을 웹 페이지에 포함 시킵니다. 개발자가 전체 응용 프로그램의 아키텍처를 지시하는 작은 유틸리티 라이브러리 또는 대규모 프레임 워크를 사용하기로 결정했는지 여부에 관계없이 오픈 소스 패키지 캠을 사용하면 기능을 보다 쉽고 빠르게 개발할 수 있습니다.


어떤 JavaScript 오픈 소스 라이브러리가 가장 많이 사용됩니까?


LibraryDesktopMobile
jQuery85.03%83.46%
jQuery Migrate31.26%31.68%
jQuery UI23.60%21.75%
Modernizr17.80%16.76%
FancyBox7.04%6.61%
Lightbox6.02%5.93%
Slick5.53%5.24%
Moment.js4.92%4.29%
Underscore.js4.20%3.82%
prettyPhoto2.89%3.09%
Select22.78%2.48%
Lodash2.65%2.68%
Hammer.js2.28%2.70%
YUI1.84%1.50%
Lazy.js1.26%1.56%
Fingerprintjs1.21%1.32%
script.aculo.us0.98%0.85%
Polyfill0.97%1.00%
Flickity0.83%0.92%
Zepto0.78%1.17%
Dojo0.70%0.62%
그림 11. 데스크탑 및 모바일의 최상위 JavaScript 라이브러리


가장 인기있는 JavaScript 라이브러리인 jQuery는 데스크톱 페이지의 85.03 % 및 모바일 페이지의 83.46 %에서 사용됩니다. 

FetchquerySelector와 같은 많은 브라우저 API 및 메소드의 출현으로 라이브러리에서 제공하는 많은 기능을 기본 형식으로 표준화 했습니다. jQuery의 인기가 떨어지고 있는 것처럼 보이지만 왜 대다수 웹에서 여전히 사용됩니까?


여러 가지 가능한 이유가 있습니다.

  • 사이트의 30 % 이상에서 사용되는 WordPress에는 기본적으로 jQuery가 포함됩니다
  • jQuery에서 최신 클라이언트 측 라이브러리로 전환하는 데는 애플리케이션의 크기에 따라 시간이 걸릴 수 있으며 많은 클라이언트 측 라이브러리는 최신 클라이언트 측 라이브러리 외에도 jQuery로 구성 될 수 있습니다.

가장 많이 사용되는 JavaScript 라이브러리에는 jQuery 변형 (jQuery 마이그레이션, jQuery UI), Modernizr, Moment.js, Underscore.js 등이 있습니다.


프레임 워크 및 UI 라이브러리 


지난 몇 년 동안 JavaScript 에코 시스템은 단일 페이지 애플리케이션 (SPA)을 보다 쉽게 ​​구축 할 수 있도록 오픈 소스 라이브러리 및 프레임 워크가 증가했습니다. 

단일 페이지 응용 프로그램은 단일 HTML 페이지를 로드하고 JavaScript를 사용하여 서버에서 새 페이지를 가져 오는 대신 사용자 상호 작용시 페이지를 수정하는 웹 페이지로 특징 지워집니다. 

이것이 단일 페이지 응용 프로그램의 주요 전제로 남아 있지만 다른 서버 렌더링 방법을 사용하여 해당 사이트의 환경을 개선 할 수 있습니다.


이러한 유형의 프레임 워크를 사용하는 사이트는 몇 개입니까?


 

그림 12. 데스크탑에서 가장 자주 사용되는 프레임 워크.


여기서는 널리 사용되는 프레임 워크의 하위 집합 만 분석하지만 모든 프레임 워크는 다음 두 가지 방법 중 하나를 따릅니다.

컴포넌트 기반 모델로의 전환이 있었지만 MVC 패러다임 (AngularJS, Backbone.js, Ember)을 따르는 많은 오래된 프레임 워크가 여전히 수천 페이지에 사용되고 있습니다. 그러나 React, Vue 및 Angular는 가장 널리 사용되는 구성 요소 기반 프레임 워크입니다 (Zone.js는 이제 Angular 코어의 일부인 패키지입니다).


이 분석은 흥미롭지만 이러한 결과는 타사 탐지 라이브러리인 Wappalyzer에 의존한다는 점을 명심해야 합니다. 이러한 모든 사용량은 각 탐지 메커니즘의 정확도에 따라 다릅니다.


차동 로딩 


JavaScript 모듈 또는 ES 모듈은 모든 주요 브라우저에서 지원됩니다. 모듈은 다른 모듈에서 가져오고 내보낼 수 있는 스크립트를 작성하는 기능을 제공합니다. 이를 통해 누구나 타사 모듈 로더에 의존하지 않고 모듈 패턴으로 설계된 애플리케이션을 빌드하고 필요한 곳에서 가져오고 내보낼 수 있습니다.


스크립트를 모듈로 선언하려면 스크립트 태그가 type = "module"을 가져와야 합니다.


<script type="module" src="main.mjs"></script>

페이지에서 스크립트에 type = "module"을 사용하는 사이트는 몇 개입니까?


 

그림 13. type = module을 사용하는 사이트 비율


모듈에 대한 브라우저 수준의 지원은 여전히 ​​비교적 새롭고, 현재 숫자는 현재 스크립트에 type = "module"을 사용하는 사이트가 거의 없음을 보여줍니다. 

많은 사이트가 여전히 코드 로더 내에 모듈을 정의하기 위해 모듈 로더 (예 : 모든 데스크톱 사이트의 2.37 %가 RequireJS를 사용함)와 번들러 (예 : 웹팩)에 의존하고 있습니다.


기본 모듈을 사용하는 경우 아직 모듈을 지원하지 않는 브라우저에 적절한 대체 스크립트를 사용해야 합니다. nomodule 속성을 가진 추가 스크립트를 포함 시키면 됩니다.

<script nomodule src="fallback.js"></script>

모듈을 지원하는 브라우저를 함께 사용하면 nomodule 속성을 포함하는 모든 스크립트를 완전히 무시합니다. 반면, 아직 모듈을 지원하지 않는 브라우저는 type = "module"인 스크립트를 다운로드하지 않습니다. 

모듈도 인식하지 못하기 때문에 속성이 있는 스크립트를 정상적으로 다운로드합니다. 이 방법을 사용하면 개발자가 최신 코드를 최신 브라우저로 보내 페이지를 더 빠르게 로드 할 수 있습니다.


그렇다면 페이지에서 스크립트에 nomodule을 사용하는 사이트는 몇 개입니까?

 

그림 14. 모듈을 사용하지 않는 사이트의 백분율


마찬가지로 모든 스크립트에 nomodule 속성을 사용하는 사이트 (0.50 % -0.80 %)는 거의 없습니다.


프리로드 및 프리 페치 


프리로드 프리 페치는 다운로드해야 할 리소스를 결정하는 데 도움이 되는 지시문입니다.

  • <link rel = "preload">를 사용하여 리소스를 사전로드 하면 브라우저가 이 리소스를 가능한 빨리 다운로드 하도록 지시합니다. 이는 페이지 로드 프로세스 후반에 발견되는 중요한 리소스 (예 : HTML 하단에 있는 JavaScript)에 특히 유용하며 마지막으로 다운로드 됩니다.
  • <link rel = "prefetch">를 사용하면 브라우저가 향후 탐색에 필요한 리소스를 가져와야 하는 유휴 시간을 활용하도록 합니다.

그렇다면 프리로드 및 프리 페치 지시문을 사용하는 사이트는 몇 개입니까?


 

그림 15. 스크립트에 rel = preload를 사용하는 사이트의 백분율


HTTP 아카이브로 측정 된 모든 사이트의 경우 데스크톱 사이트의 14.33 % 및 모바일 사이트의 14.84 %가 해당 페이지의 스크립트에 <link rel = "preload">를 사용합니다.


프리 페치의 경우 :


 

그림 16. 스크립트에 rel = prefetch를 사용하는 사이트 백분율


모바일과 데스크톱 모두 0.08 %의 페이지에서 스크립트에 프리 페치를 사용합니다.


최신 API 


JavaScript는 언어로 계속 발전하고 있습니다. ECMAScript로 알려진 새로운 버전의 언어 표준 자체는 매년 새로운 API와 함께 제공되어 제안 단계를 통과하여 언어 자체의 일부가 됩니다.


HTTP Archive를 사용하면 지원되는 (또는 곧 있을) 최신 API를 살펴보고 그 사용이 얼마나 광범위한 지 확인할 수 있습니다. 

이 API는 이미 모든 브라우저에서 작동하는지 확인하기 위해 해당 API를 지원하는 브라우저 또는 함께 제공되는 폴리 필과 함께 이미 사용 중일 수 있습니다.


다음 API를 사용하는 사이트는 몇 개입니까?


 

그림 17. 새로운 JavaScript API 사용.


Atomics (0.38 %) 및 SharedArrayBuffer (0.20 %)는 이 페이지에서 거의 사용되지 않으므로 이 차트에서 거의 볼 수 없습니다.


여기에 있는 숫자는 근사치이며 UseCounter를 사용하여 기능 사용을 측정하지는 않습니다.


소스 맵 


많은 빌드 시스템에서 JavaScript 파일은 축소되어 많은 브라우저에서 아직 지원되지 않는 새로운 언어 기능의 크기와 변환을 최소화합니다. 

또한 TypeScript와 같은 언어 수퍼 셋은 원래 소스 코드와 현저하게 다른 출력으로 컴파일 됩니다. 이러한 모든 이유로 인해 브라우저에 제공되는 최종 코드를 읽을 수 없고 해독하기가 어려울 수 있습니다.


소스 맵은 브라우저가 최종 출력을 원래 소스에 매핑 할 수 있는 JavaScript 파일과 함께 제공되는 추가 파일입니다. 따라서 프로덕션 번들 디버깅 및 분석이 훨씬 간단 해집니다.


유용하기는 하지만 많은 사이트가 완전한 소스 코드를 공개하지 않기로 선택하는 등 최종 프로덕션 사이트에 소스 맵을 포함하지 않는 데는 여러 가지 이유가 있습니다. 실제로 얼마나 많은 사이트가 소스 맵을 포함합니까?


 

그림 18. 소스 맵을 사용하는 사이트의 백분율


데스크톱과 모바일 페이지 모두 결과는 거의 같습니다. 17-18 %는 페이지에 하나 이상의 스크립트에 대한 소스 맵을 포함합니다 (sourceMappingURL을 사용하여 자사 스크립트로 감지).


결론 


JavaScript 생태계는 매년 계속 변화하고 진화합니다. 최신 API, 개선 된 브라우저 엔진 및 최신 라이브러리 및 프레임 워크는 우리가 무기한으로 일어날 것으로 예상되는 모든 것입니다. HTTP Archive는 야생의 사이트가 어떻게 언어를 사용하는지에 대한 귀중한 통찰력을 제공합니다.


JavaScript가 없으면 웹은 오늘날의 위치에 있지 않으며 이 기사에 대해 수집 된 모든 데이터만 이를 증명합니다.



  • 트위터로 보내기
  • 페이스북으로 보내기
  • 구글플러스로 보내기
  • 카카오톡으로 보내기

페이지 정보

조회 8회 ]  작성일19-11-30 16:41

웹학교