[번역] Javascrip 2018의 비용
원본 : https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4
2018 년 JavaScript 비용
대화 형 사이트를 구축 하면 JavaScript를 사용자에게 전송할 수 있습니다. 자주 그것의 너무 많이 . 링크를 탭하기 위해로드 된 것처럼 보이거나 스크롤하려고 시도한 것처럼 보이지 않는 모바일 페이지에 있었 습니까?
Byte-for-byte, 자바 스크립트는 여전히 상호 작용을 크게 지연시킬 수 있기 때문에 휴대 전화로 보내는 가장 비싼 리소스입니다.
WebPageTest ( src )에서 측정 한 CNN.com의 JavaScript 처리 시간입니다 . 상한 전화 (iPhone 8)는 ~ 4 초 안에 스크립트를 처리합니다. 평균 전화 (Moto G4)가 ~ 13 초, 저가형 2018 전화기 (Alcatel 1X)로 촬영 한 ~ 36 초를 비교하십시오 .
오늘은 사용자에게 가치있는 경험을 제공하면서도 효율적으로 JavaScript를 전달하는 데 사용할 수있는 몇 가지 전략에 대해 살펴 보겠습니다.
tl; dr :
빠른 유지하기 위해
, 자바 스크립트 만 현재 페이지에 필요한로드합니다.
사용자가 필요로 하는 것보다 우선 순위를 정하고 나머지는 코드 분할로지연로드하십시오
이로써 대화식으로 빠르게 로딩하고 얻는 최상의 기회를 얻을 수 있습니다
기본적으로 경로 기반 코드 분할을 사용하는 스택은 게임 체인저입니다.
성과 예산을 수용하고 그 안에서 살기를 배웁니다. 모바일의 경우 축소 또는 압축 된 <170KB 의 JS 예산을 목표로 삼습니다 . 압축되지 않은 코드는 여전히 0.7MB입니다. 예산은 성공에 결정적으로 중요하지만, 마술처럼 혼자서 성능을 수정할 수는 없습니다. 팀 문화, 구조 및 시행 문제 . 예산을 세우지 않으면 성능 회귀와 실패가 발생합니다.
자바 스크립트 번들 을 감사 하고 트리밍 하는 방법에 대해 알아보십시오. 당신이있는 높은 가능성이있다 당신이 일부분 만 필요로 할 때 전체 라이브러리를 출시 , 그들이 필요, 또는 코드를 복제하지 않는 브라우저에 대한 polyfills는.
모든 상호 작용은 새로운 'Time-to-Interactive'의 시작입니다. 이 상황에서 최적화를 고려하십시오. 전송 크기는 로우 엔드 모바일 네트워크 및 CPU 바인딩 장치의 JavaScript 구문 분석 시간에 중요합니다.
클라이언트 측 JavaScript가 사용자 경험에 도움이되지 않는다면 정말로 필요한지 스스로에게 자문 해보십시오. 어쩌면 서버 측 렌더링 HTML이 실제로 더 빠를 수도 있습니다. 클라이언트 측 프레임 워크의 사용을 절대적으로 요구하는 페이지로 제한하는 것을 고려하십시오. 서버 렌더링 과클라이언트 렌더링은 제대로 수행되지 않으면 재앙입니다.
이 글을 기반으로 한 "JavaScript of the Cost"에 대한 최근 비디오
웹은 사용자 "경험"에 의해 부풀어 오른다.
사용자가 귀하의 사이트에 액세스 할 때 많은 파일을 보내고 있으며 대다수는 스크립트입니다. 웹 브라우저의 관점에서 볼 때 다음과 같이 보입니다.
너에게 던져지고있는 파일의 화를 많이 낸다.
Javascript를 좋아하는 한, 항상 사이트에서 가장 비싼 부분입니다. 이것이 왜 중요한 문제인지 설명하고 싶습니다.
중간 웹 페이지는 현재 약 350KB의 축소되고 압축 된 JavaScript를 제공 합니다. 압축되지 않은 브라우저는 브라우저가 처리해야하는 1MB 이상의 스크립트를 압축합니다.
참고 : 자바 스크립트 번들로 인해 사용자가 귀하의 사이트와 얼마나 빨리 상호 작용할 수 있는지 알 수 있습니까? 등대를 확인하십시오 .
자바 스크립트 보고서 의 HTTP 보관 상태 인 2018 년 7 월 통계 는 중간 크기의 웹 페이지를 350KB의 축소 및 압축 된 스크립트로 강조 표시합니다. 이 페이지는 상호 작용하기 위해 최대 15 초가 걸립니다.
이 자바 스크립트를 다운로드 한 경험 으로 휴대 기기에서 로드하고 대화식으로 전환 하는 데 14 초 이상 걸릴 수 있습니다.
이것의 큰 요인은 모바일 네트워크에서 코드를 다운로드 한 다음 모바일 CPU에서 처리하는 데 얼마나 걸리는지입니다.
모바일 네트워크를 살펴 보겠습니다.
특정 지표에서 더 잘 수행되는 국가는 더 어둡게 음영 처리됩니다. 포함되지 않은 국가는 회색입니다. 또한 가치 에 주목 하는 농촌 광대역 속도를, 심지어 미국에서, 도시 지역에 비해 20 % 속도가 느려질 수 있습니다.
OpenSignal 의이 차트는 4G 네트워크가 얼마나 일관되게 사용 가능하며 각 국가의 평균 연결 속도 사용자가 사용하는지 보여줍니다. 우리가 볼 수 있듯이, 많은 나라들은 생각보다 낮은 연결 속도를 경험합니다.
이전 버전의 중간 웹 사이트에 대한 350KB의 스크립트 만 다운로드 할 수있을뿐만 아니라 실제로 인기있는 사이트를 보면 실제로는 이보다 훨씬 많은 스크립트가 제공됩니다.
압축되지 않은 JS 번들 크기는 " Facebook.com 및 웹 가져 오기 속도 "에서 나타납니다. Google 스프레드 시트와 같은 사이트는 5.8MB의 스크립트 (압축 해제 된 경우)로 전송되는 것으로 강조 표시됩니다.
데스크톱과 모바일 웹 모두에서이 천장을 치고 있습니다. 사이트는 때때로 브라우저에서 처리해야하는 여러 메가 바이트 상당의 코드를 제공합니다. 묻는 질문은, 당신은이 정도 자바 스크립트를 감당할 수 있습니까?
JavaScript에는 비용이 있습니다.
"이 스크립트를 많이 사용하는 사이트는 전세계 사용자의 광범위한 접근이 불가능합니다. 통계적으로 사용자는 이러한 경험이로드되기를 기다리지 않습니다. "- Alex Russell
참고 : 너무 많은 스크립트를 보내는 경우 코드 분할 을 사용하여 번들을 분리 하거나 트리 흔들기를 사용하여 JS 페이로드를 줄이십시오 .
오늘 사이트는 종종 JS 번들에서 다음을 보냅니다.
클라이언트 측 프레임 워크 또는 UI 라이브러리
이 코드가 합쳐집니다. 페이지가 많을수록 페이지를로드하는 데 더 오래 걸립니다.
웹 페이지를로드하는 것은 세 가지 중요한 순간을 가진 필름 스트립과 같습니다.
거기에 : 그것은 일어나고 있습니까? 유용할까요? 그리고, 그것은 사용할 수 있습니까?
로드는 여행입니다. 우리는 사용자 중심 행복 메트릭스에 대한 관심을 높이기로 이동하고 있습니다. onload 또는 domContentLoaded를 보는 것보다 "사용자가 언제 * 페이지를 사용할 수 있습니까?"라고 묻습니다. 사용자 인터페이스의 일부를 탭하면 곧바로 응답합니까?
이 일어나고 화면에 일부 콘텐츠를 제공 할 수있는 순간이다. ( 탐색이 시작 되었습니까? 서버가 응답을 시작 했습니까?)
사용자가 경험에서 가치를 끌어 내고 참여할 수있는 텍스트 또는 콘텐츠를 그렸던 순간 이 유용 합니다.
그런 다음 사용자가 의미있게 경험과 상호 작용하고 어떤 일이 발생할 수있는 순간을 사용할 수 있습니까?
나는이 용어를 "대화 형"이라고 일찍 언급했지만, 그 의미는 무엇입니까?
대화 형 텍스트를 시각화하여 시각적으로 표현하면 사용자가 목표를 달성 할 수 있다고 생각하게 만듭니다. 사실, 페이지가 실제로이 코드를 모두로드하지 않아도됩니다. 대화 형 애니메이션을위한 Kevin Schaaf에게 감사드립니다.
페이지를 대화식으로 사용하려면 사용자 입력에 신속하게 응답 할 수 있어야합니다. 작은 JavaScript 페이로드로 이러한 일이 빠르게 이루어질 수 있습니다.
사용자가 링크를 클릭하든 페이지를 스크롤하든, 사용자는 자신의 행동에 대한 응답으로 실제로 어떤 일이 일어나는지 확인할 필요가 있습니다. 이 문제를 해결할 수없는 경험은 사용자를 좌절시킬 것입니다.
Lighthouse는 실험실 환경에서 Time-to-Interactive와 같은 다양한 사용자 중심 성능 메트릭을 측정합니다.
여러분의 서버 측이 경험을 렌더링 할 때 일반적으로 발생하는 하나 개의 장소입니다 및 다음 "수화물"인터페이스 (연결 이벤트 핸들러 및 추가 행동)까지 이후 자바 스크립트의 무리를 제공.
브라우저에서 필요로하는 많은 이벤트를 실행하면 사용자 입력을 처리하는 동일한 스레드에서이를 수행 할 가능성이 큽니다. 이 스레드를 주 스레드라고합니다.
Loading too much JavaScript into the main thread (via <script>, etc) is the issue. Pulling JS into a Web Worker or caching via a Service Workerdoesn’t have the same negative Time-to-Interactive impact.
Here’s an example where a user may tap around some UI. Ordinarily, they might check a checkbox or click a link and everything’s going to work perfectly fine. But if we simulate blocking the main thread, nothing’s able to happen. They are not able to check that checkbox or click links because the main thread is blocked.
Avoid blocking the main thread as much as possible. For more, see “Why web developers need to care about interactivity”
We’re seeing teams we partner with suffer JavaScript impacting interactivity across many types of sites.
JavaScript can delay interactivity for visible elements. Visualized are a number of UI elements from Google Search.
Too much (main thread) JavaScript can delay interactivity for visible elements. This can be a challenge for many companies.
Above are a few examples from Google Search where you could start tapping around the UI, but if a site is shipping too much JavaScript down, there could be a delay before something actually happens. This can leave the user feeling a bit frustrated. Ideally, we want all experiences to get interactive as soon as possible.
Time-to-Interactive of news.google.com as measured by WebPageTest and Lighthouse (source)
모바일에서 Google 뉴스의 인터랙션 시간을 측정 한 결과, 하이 엔드급 대화 형 대화 상대는 ~ 7 대 대 초반대 기기 대 대화 형 대화 상대는 55 대 사이에 큰 차이가 있음을 알 수 있습니다. 그럼, 상호 작용을위한 좋은 목표는 무엇입니까?
Time to Interactive에 관해서는, 표준 모바일 장치에서 3G 연결 속도가 느린 경우 기준이 5 초 이내에 대화 형으로 전환되어야한다고 생각합니다. "하지만, 내 사용자가 모든 고속 네트워크 및 하이 엔드 휴대폰에있다!" ... 그들은입니까? "빠른"커피 숍 WiFi에 있지만 2G 또는 3G 속도 만 효과적으로 얻을 수 있습니다. 변동성 문제.
JavaScript를 적게 공급하고 Interactive-Time-to-Interactive를 단축 한 사람은 누구입니까?
Pinterest는 자바 스크립트 번들을 2.5MB에서 <200KB로, Time-to-Interactive를 23에서 5.6으로 줄였습니다 . 매출은 44 %, 가입은 753 %, 주간 활성 사용자는 103 % 증가했습니다 .
AutoTrader는 자바 스크립트 번들 크기를 56 % 줄였으며 페이지에 대한 Time-to-Interactive를 50 % 줄
였습니다.
Nikkei는 자바 스크립트 번들 크기를 43 %, Interactive Time-to-Interactive를 14s 단축했습니다.
큰 JavaScript 페이로드에 크게 의존하지 않는보다 탄력적 인 모바일 웹을 디자인 해 보겠습니다.
상호 작용은 많은 일에 영향을 미칩니다. 모바일 데이터 요금제 또는 커피 숍 WiFi에서 웹 사이트를로드하는 사람이나 간헐적 인 연결로 이동 중일 때 영향을받을 수 있습니다.
When this happens, and you have a lot of JavaScript that needs to be processed, users can end up waiting for the site to actually render anything. Or, if something does render, they can be waiting a long time before they can interact with anything on the page. Ideally, shipping less JavaScript would alleviate these issues.
Why is JavaScript so expensive?
To explain how JavaScript can have such a large cost, I’d like to walk you through what happens when you send content to a browser. A user types a URL into the browser’s address bar:
A request is sent to a server which then returns some markup. The browser then parses that markup and discovers the necessary CSS, JavaScript, and images. Then, the browser has to fetch and process all of those resources.
The above scenario is an accurate depiction of what happens in Chrome when it processes everything that you send down (yes, it’s a giant emoji factory).
One of the challenges here is that JavaScript ends up being a bottleneck. Ideally, we want to be able to paint pixels quickly, and then have the page interactive. But if JavaScript is a bottleneck, you can end up just looking at something that you can’t actually interact with.
We want to prevent JavaScript from being a bottleneck to modern experiences.
One thing to keep in mind as an industry is that, if we want to be fast at JavaScript, we have to download it, parse it, compile it, and execute it quickly.
That means we have to be fast at the network transmission and the processing side of things for our scripts.
If you spend a long time parsing and compiling script in a JavaScript engine, that delays how soon a user can interact with your experience.
To provide some data about this, here’s a breakdown of where V8 (Chrome’s JavaScript engine) spends its time while it processes a page containing script:
JavaScript parse/compile = 10–30% of the time spent in V8 (Chrome’s JS engine) during page load
The orange represents all the time spent parsing JavaScript that popular sites are sending down. In yellow, is the time spent compiling. Together, these take anywhere up to 30% of the time it takes to process the JavaScript for your page — this is a real cost.
As of Chrome 66, V8 compiles code on a background thread, reducing compile time by up to 20%. But parse and compile are still very costly and it’s rare to see a large script actually execute in under 50ms, even if compiled off-thread.
Another thing to keep in mind with JavaScript is that all bytes are not equal. A 200 KB script and a 200 KB image have very different costs.
Not all bytes weigh the same. A 200KB script has a very different set of costs to a 200KB JPG outside of the raw network transmission times for both sets of bytes.
They might take the same amount of time to download, but when it comes to processing we’re dealing with very different costs.
A JPEG image needs to be decoded, rasterized, and painted on the screen. A JavaScript bundle needs to be downloaded and then parsed, compiled, executed —and there are a number of other steps that an engine needs to complete. Just be aware that these costs are not quite equivalent.
One of the reasons why they start to add up and matter is mobile.
Mobile is a spectrum.
Mobile is a spectrum composed of cheap/low-end, median and high-end devices.
If we’re fortunate, we may have a high-end or median end phone. The reality is that not all users will have those devices.
They may be on a low-end or median phone, and the disparity between these multiple classes of devices can be quite stark due too; thermal throttling, difference in cache sizes, CPU, GPU — you can end up experiencing quite different processing times for resources like JavaScript, depending on the device you’re using. Your users on low-end phones may even be in the U.S.
“Insights into the 2.3 Billion Android Smartphones” by newzoo. Android has a 75.9% share of the global market with a predicted 300m more smartphones joining the market in 2018. Many of these will be budget Android devices.
Here’s a breakdown of how long it takes to parse JavaScript across a spectrum of hardware available in 2018:
실제 장치에서 수동으로 프로파일 링 된 1MB의 비 압축 JavaScript (<200KB 축소 및 gzip)에 대한 처리 (구문 분석 / 컴파일) 시간. ( src )
상단에는 iPhone 8과 같은 고급 장치가있어서 스크립트를 비교적 빨리 처리 할 수 있습니다. 아래로 내려 가면 Moto G4와 <$ 100 Alcatel 1X와 같은 일반 전화가 더 많이 있습니다. 처리 시간의 차이점에 주목하십시오.
Android 휴대 전화는 시간이 지남에 따라 더 저렴하지는 않습니다 . 이러한 장치는 CPU 크기가 작고 L2 / L3 캐시 크기가 작습니다. 일반 사용자가 모두 고급형 하드웨어를 사용할 것으로 예상되는 경우 일반 사용자는 실패합니다.
실제 사이트의 스크립트를 사용하여이 문제의보다 실용적인 버전을 살펴 보겠습니다. CNN.com의 JS 처리 시간은 다음과 같습니다.
JavaScript processing times for CNN.com via WebPageTest (src)
On an iPhone 8 (using the A11 chip) it takes nine seconds less to process CNN’s JavaScript than it does on an average phone. That’s nine seconds quicker that experience could get interactive.
Now that WebPageTest supports the Alcatel 1X (~$100 phone sold in the U.S, sold out at launch) we can also look at filmstrips for CNN loading on mid-lower end hardware. Slow doesn’t even begin to describe this:
Comparison of loading CNN.com, a JavaScript-heavy site, over 3G on mid-lower end hardware (source). The Alcatel 1X takes 65s to fully load.
이것은 아마도 우리가 빠른 네트워크와 빠른 장치를 당연시하는 것을 중단해야 할 필요가 있음을 암시합니다.
일부 사용자는 빠른 네트워크에 있거나 최신의 최고의 전화를 가지지 않으므로 실제 전화 및 실제 네트워크에서 테스트를 시작해야합니다. 변동성은 실질적인 문제입니다.
"가변성은 사용자 경험을 죽이는 것입니다"- Ilya Grigorik. 빠른 장치는 때로는 느려질 수 있습니다. 빠른 네트워크는 느려질 수 있고, 가변성은 결국 모든 것을 느리게 만들 수 있습니다.
분산이 사용자 경험을 죽일 수있는 경우 느린 기준선을 사용하여 개발하면 모든 사람이 (빠른 설정과 느린 설정 모두에서) 이점을 얻을 수 있습니다. 팀이 분석을보고 실제로 사용자가 귀하의 사이트에 액세스하고있는 장치를 정확히 파악할 수 있다면 사이트를 테스트하기 위해 사무실에 있어야 할 장치를 알 수 있습니다.
실제 휴대 전화 및 네트워크에서 테스트하십시오.
webpagetest.org/easy 에는 "모바일"프로파일로 사전 구성된 많은 Moto G4가 있습니다. 이는 테스트를 위해 자신의 고유 한 중앙 집중식 하드웨어 세트를 구입할 수없는 경우에 유용합니다.
현재 널리 사용되는 장치가 사전 구성되어있는 오늘날 사용할 수있는 프로필이 몇 가지 있습니다. 예를 들어, 우리는 Moto G4와 같은 중간 규모의 모바일 장치를 테스트 할 준비가되어 있습니다.
대표적인 네트워크에서 테스트하는 것도 중요합니다. 나는 로우 엔드 및 중간 전화가 얼마나 중요한지에 대해 이야기했습니다 있지만, 브라이언 홀트는 이 만든 좋은 점 : 그것은 당신의 청중을 알고 정말 중요합니다.
"잠재 고객을 파악하고 애플리케이션의 성능을 적절하게 맞추는 것이 중요합니다"- Brian Holt ( src )
모든 사이트가 로우 엔드 폰에서 2G에서 잘 작동해야하는 것은 아닙니다 . 즉, 전체 스펙트럼에서 높은 수준의 성능을 목표로하는 것은 나쁜 일이 아닙니다.
Google 애널리틱스> 잠재 고객> 모바일> 기기는 기기 및 운영체제가 내 사이트를 방문하는 시각을 보여줍니다.
스펙트럼 상단이나 스펙트럼의 다른 부분에 광범위한 사용자가있을 수 있습니다. 사이트의 모든 데이터가 얼마나 중요한지 합리적으로 파악할 수 있도록 사이트 뒤의 데이터를 알고 있어야합니다.
자바 스크립트를 빨리 사용하려면 로우 엔드 네트워크의 다운로드 시간에주의하십시오. 당신이 할 수있는 개선 사항은 다음과 같습니다 : 코드를 줄이고 출처를 축소 하며 압축 (즉, gzip , Brotli 및 Zopfli )을 활용하십시오.
반복적 인 방문을 위해 캐싱을 활용하십시오. 구문 분석 시간은 CPU 속도가 느린 휴대 전화에 중요합니다.
백엔드 또는 전체 스택 개발자 인 경우 CPU, 디스크 및 네트워크와 관련하여 비용을 지불하는 것이 좋습니다.
JavaScript에 점점 더 의존하는 사이트를 구축 할 때 우리는 때때로 우리가 보지 못하는 방식으로 비용을 지불합니다.
적은 자바 스크립트 보내는 방법
성공의 형태는 무엇이든간에 우리에게 사용자에게 유용한 스크립트를 제공하면서 가장 적은 양의 스크립트를 보내 게합니다. 이를 가능하게하는 코드 분할 은 하나의 옵션입니다.
크기가 큰 획일적 인 JavaScript 묶음을 페이지, 경로 또는 구성 요소별로 분할 할 수 있습니다. "스플릿 (split)"이 도구 체인의 기본 기능이라면 성공을위한 더 나은 설정입니다.
코드 분리는 대량의 전체 피자와 같은 일종의 거대한 획일적 인 자바 스크립트 번들을 사용자에게 전달하는 대신 한 번에 한 조각 만 보내면 어떨까요?현재 페이지를 사용할 수있게 만드는데 필요한 스크립트 만 있습니다.
코드 분할은 페이지 수준, 경로 수준 또는 구성 요소 수준에서 수행 할 수 있습니다. webpack 과 Parcel 같은 번 들러를 통해 많은 현대 라이브러리와 프레임 워크가 잘 지원합니다 . 이를 수행하기위한 가이드는 React , Vue.js 및 Angular에서 사용할 수 있습니다 .
React Loadable을 사용하여 React 앱 에 코드 분할 추가 - 주어진 컴포넌트에서 코드 분할을 위해 React-friendly API에서 동적 가져 오기를 래핑하는 고차원 구성 요소.
많은 대형 팀이 최근에 코드 분할에 투자하여 큰 성과를 거두었습니다.
In an effort to rewrite their mobile web experiences to try to make sure users were able to interact with their sites as soon as possible, both Twitter and Tinder saw anywhere up to a 50% improvement in their Time to Interactive when they adopted aggressive code splitting.
Stacks like Gatsby.js (React), Preact CLI, and PWA Starter Kit attempt to enforce good defaults for loading & getting interactive quickly on average mobile hardware.
Another thing many of these sites have done is adopted auditing as part of their workflow.
Audit your JavaScript bundles regularly. Tools like webpack-bundle-analyzer are great for analyzing your built JavaScript bundles and import-cost for Visual Code is excellent for visualizing expensive dependencies during your local iteration workflow (e.g. when you `npm install` and import a package)
Thankfully, the JavaScript ecosystem has a number of great tools to help with bundle analysis.
Tools like Webpack Bundle Analyzer, Source Map Explorer and Bundle Buddy allow you to audit your bundles for opportunities to trim them down.
These tools visualize the content of your JavaScript bundles: they highlight large libraries, duplicate code, and dependencies you may not need.
From “Put your Webpack bundle on a diet” by Benedikt Rötsch
Bundle auditing often highlights opportunities to swap heavy dependencies (like Moment.js and its locales) for lighter alternatives (such as date-fns).
If you use webpack, you may find our repository of common library issues in bundles useful.
Measure, Optimize, Monitor, and Repeat.
If you’re unsure whether you have any issues with JavaScript performance in general, check out Lighthouse:
Lighthouse recently added a number of useful new performance audits that you may not be aware of.
Lighthouse는 Chrome 개발자 도구로 구운 도구입니다. Chrome 확장 프로그램 으로도 제공됩니다 . 성능 개선 기회를 강조하는 심층적 인 성과 분석을 제공합니다.
우리는 최근 Lighthouse에 높은 " JavaScript 부팅 시간 "을 표시하는 지원을 추가했습니다 . 이 감사에서는 인터랙션을 지연시키는 오랜 시간 파싱 / 컴파일 작업을 수행하는 스크립트를 강조 표시합니다. 이 감사를 이러한 스크립트를 분리 할 수있는 기회로 보거나 그 곳에서 일하는 횟수를 줄일 수 있습니다.
할 수있는 또 다른 일은 사용하지 않는 코드를 사용자에게 제공하지 않는 것입니다.
Chrome DevTools 의 Coverage 탭에서 사용되지 않는 CSS 및 JS 코드를 찾습니다 .
코드 커버리지 는 개발자가 페이지에서 사용하지 않는 자바 스크립트 (및 CSS)를 발견 할 수있게 해주는 DevTools의 기능입니다. DevTools에서 페이지를로드하면 적용 범위 탭에 실행 된 코드의 양과로드 된 양이 표시됩니다. 사용자가 필요로하는 코드 만 배송하여 페이지의 성능을 향상시킬 수 있습니다.
팁 : 커버리지 레코딩을 사용하면 앱과 상호 작용할 수 있으며 DevTools는 사용 된 번들의 양을 업데이트합니다.
이는 스크립트를 분할 할 기회를 식별하고 중요하지 않은 스크립트의로드가 필요할 때까지 지연시키는 데 유용합니다.
사용자에게 JavaScript를 효율적으로 제공하기위한 패턴을 찾고 있다면 PRPL 패턴을 확인하십시오 .
PRPL은 효율적인 로딩을위한 성능 패턴입니다. 이것은 초기 경로, 초기 경로, (P) 잔여 경로를 다시 캐시, (L) 아지 -로드 (azy-load) 및 나머지 요청 경로를 생성하기위한 중요한 자원을 의미한다.
PRPL (Push, Render, Precache 및 Lazy-Load)은 모든 단일 경로에 대해 적극적으로 코드를 분할 한 다음 서비스 작업자 가 향후 경로에 필요한 JavaScript 및 논리를 사전 캐시하고 필요할 때 지연로드하는 패턴입니다. .
이것이 의미하는 바는 사용자가 경험의 다른 뷰를 탐색 할 때 이미 브라우저 캐시에있을 가능성이 높으므로 스크립트를 부팅하고 대화식으로 가져 오는 데 드는 비용을 훨씬 줄일 수 있다는 것입니다.
퍼포먼스에 관심이 있거나 사이트의 성능 패치를 다룬 적이 있다면, 몇일 후에 다시 돌아와 팀의 누군가가 의도하지 않게 경험을 망 쳤습니다. 다음과 같이 조금씩 나아갑니다.
고맙게도이 문제를 해결하기 위해 노력할 수있는 방법이 있으며 한 가지 방법은 성능 예산 을 마련하는 것입니다.
실적 예산은 모두가 같은 페이지를 유지하기 때문에 중요합니다. 그들은 사용자 경험과 팀의 책임 성을 지속적으로 향상시키기 위해 열정을 공유하는 문화를 창조합니다.
예산 은 팀이 성과 목표를 달성 할 수 있도록 측정 가능한 제약 조건 을 정의 합니다. 예산의 제약 속에서 살아야하기 때문에, 성과는 사후에 대비되는 것처럼 각 단계에서 고려 사항입니다.
Tim Kadlec 의 작업을 기반으로 perf 예산에 대한 메트릭은 다음과 같습니다.
마일스톤 타이밍 - 페이지를로드하는 사용자 경험 에 기반한 타이밍 (예 : Time-to-Interactive). 페이지로드 중에 완성 된 이야기를 정확하게 표현하기 위해 몇 가지 마일스톤 타이밍을 짝을 이루기를 원할 것입니다.
Alex Russell은 다음 과 같은 주목할 가치가있는 몇 가지 중요한 점을 제외하고 성능 예산에 대해 트위터 폭풍우를 겪었습니다 .
"리더십 바이 인은 중요 합니다. 전반적인 사용자 경험을 유지하기 위해 기능 작업을 보류하려는 의도는 기술 제품의 사려 깊은 관리를 정의합니다. "
"성능은 도구로 지원되는 문화에 관한 것입니다. 브라우저는 가능한 한 HTML + CSS를 최적화합니다. 더 많은 작업을 JS로 옮기면 팀과 도구에 부담이됩니다. "
"예산은 당신을 슬프게 만들지 않습니다. 그들은 조직을 스스로 정정 할 수있는 곳입니다. 팀은 의사 결정 공간을 제한하고 팀을 치는 데 도움이되는 예산이 필요합니다. "
사이트의 사용자 경험에 영향을 미치는 모든 사람은 사이트의 사용자 경험과 관계가 있습니다.
대화를 공연의 일부로 만듭니다.
성능은 기술적 인 것보다 더 자주 문화적 도전입니다.
기획 세션 및 다른 모임에서 공연에 대해 토론하십시오. 비즈니스 이해 관계자에게 실적 기대치를 문의하십시오. 퍼펙트 (perf)가 비즈니스 메트릭에 어떤 영향을 미칠 수 있는지 이해하고 있습니까? eng에 문의하십시오. 팀은 병목 현상 병목 현상을 해결할 계획을 세우고 있습니다. 여기에 대한 답변이 만족스럽지는 않지만 대화가 시작됩니다.
"중요한 통계에 어떤 영향을 미칠 수 있는지 보여줌으로써 이해 관계자의 목표와 관련된 성과를 창출하십시오. 공연 문화가 없으면 공연은 지속될 수 없습니다. "- Allison McKnight
다음은 성과를위한 실천 계획입니다.
- 성과 비전을 수립하십시오 . 이것은 비즈니스 이해 관계자 및 개발자가 "우수한 성능"을 고려하는 것에 대한 1 페이지 분량의 동의입니다
- 귀하의 성과 예산을 설정하십시오 . 비전에서 핵심 성과 지표 (KPI)를 추출하고 현실적인 측정 가능한 목표를 설정합니다. 예 : "5 초 동안 대화 형으로로드 및 가져 오기" 크기 예산이 떨어질 수 있습니다. 예 : "JS <170KB 축소 / 압축"유지
- KPI에 대한 정기 보고서를 작성하십시오. 진행 상황과 성공을 강조하는 비즈니스 보고서를 정기적으로 보낼 수 있습니다.
앤디 스틸 (Andy Still)의 웹 퍼포먼스 워리어 (Web Performance Warrior) 와 라라 호간 (Lara Hogan)의 퍼포먼스 를 위한 디자인 (Designing for Performance for Lara Hogan)은 훌륭한 공연 문화를 만드는 방법에 대해 토론하는 훌륭한 책입니다.
예산 예산에 대한 도구는 어떻게됩니까? Lighthouse CI 프로젝트 와의 지속적인 통합을 통해 Lighthouse 점수 예산을 설정할 수 있습니다 .
Lighthouse CI에서 perf 점수가 특정 값 이하로 떨어지면 병합 요청이 병합되지 않도록합니다 . Lighthouse Thresholds 는 구성 예산을 설정하는 또 다른 구성 기반 접근 방식입니다.
다양한 성능 모니터링 서비스가 Calibre , Treo , Webdash 및 SpeedCurve를 포함한 예산 예산 및 예산 경고 설정을 지원합니다 .
내 사이트에 대한 자바 스크립트 반환 한 예산 teejungle.net 의 다양한 지원 SpeedCurve 사용하여 예산 측정을 .
성능 예산을 수용하면 팀이 디자인 단계에서부터 중요 시점의 끝까지 모든 결정의 결과에 대해 진지하게 생각하게됩니다.
추가 참조를 찾고 계십니까? 미국 디지털 서비스 타임 - 투 - 대화 형처럼 메트릭에 대한 목표와 예산을 설정하여 등대와 추적 성능에 자신의 접근 방식을 문서화합니다.
다음..
각 사이트는 실험실 및 현장 성능 데이터 에 모두 액세스 할 수 있어야 합니다 .
RUM (Real User Monitoring) 설정에서 자바 스크립트가 사용자 경험에 미칠 수있는 영향을 추적하려면 체크 아웃을 권장 할 웹에 두 가지가 있습니다.
필드 데이터 (또는 RUM - 실제 사용자 모니터링)는 실제 사용자가 야생에서 겪고있는 실제 페이지로드에서 수집 된 성능 데이터입니다. JavaScript 페이로드가 많은 사이트는 Long Tasks 및 First Input Delay를 통해이 작업의 메인 스레드를 측정하면 도움이됩니다.
첫 번째는 Long Tasks입니다 . API를 사용하면 주 스레드를 차단할 수있는 50 밀리 초보다 오래 지속되는 작업 (및 속성이 지정된 스크립트)에 대한 실제 원격 측정을 수집 할 수 있습니다. 이러한 작업을 기록하고 분석에 다시 기록 할 수 있습니다.
First Input Delay (FID)는 사용자가 처음으로 사이트와 상호 작용할 때 (즉, 단추를 누를 때)부터 브라우저가 실제로 해당 상호 작용에 응답 할 수있는 시간까지의 시간을 측정하는 기준입니다. FID는 여전히 초기 측정 기준이지만, 오늘 확인할 수 있는 polyfill을 사용할 수 있습니다.
이 두 가지 사이에서 실제 사용자가 원격으로 충분한 원격 측정을 할 수 있어야 실행중인 JavaScript 성능 문제를 파악할 수 있습니다.
Marcel Freinbichler는 USA Today가 EU 사용자에게 슬림 한 사이트를 발송하는 것에 대해 바이러스 트위터를 열었습니다 . 정상적인 페이지보다 42 초 빠릅니다.
제 3 자 JavaScript가 페이지로드 성능에 심각한 영향을 미칠 수 있음은 잘 알려져 있습니다. 이것이 사실인데도 불구하고, 오늘날의 많은 경험들이 자체의 제 1 자 자바 스크립트를 많이 제공한다는 것을 인정하는 것이 중요합니다. 로드 속도가 빨라지면이 문제의 양면이 사용자 환경에 미칠 수있는 영향을 차단해야합니다.
문서 헤드에서 자바 스크립트 차단을 사용하여 사용자에게 표시 할 A / B 테스트를 결정하는 팀을 포함하여 여기에서 볼 수있는 몇 가지 일반적인 슬립 업이 있습니다. 또는 A / B 테스트의 모든 변형에 대해 JS를 발송합니다. 단 하나만 실제로 사용하게 될 것입니다.
타사 JavaScript 가 현재 발생하는 주요 병목 현상 인 경우 타사 JavaScript를로드하는 방법에 대한 별도의 안내서 가 제공됩니다.
빨리, 빨리 머물러 라.
공연은 여행입니다. 작은 변화가 많으면 커다란 이익을 얻을 수 있습니다.
사용자가 최소한 의 마찰로 사이트와 상호 작용할 수 있습니다 . 진정한 가치를 제공하기 위해 가장 작은 양의 JavaScript를 실행하십시오. 이것은 거기에 도달하기 위해 점진적인 조치를 취하는 것을 의미 할 수 있습니다.
결국 사용자가 감사 할 것입니다.
참고 문헌
당신은 그것을 감당할 수 있습니까? : 실제 웹 성능 예산
Tree-shaking으로 JavaScript 페이로드 줄이기
Fast & Resilient - 왜 "빠름"경로를 조각하는 것만으로는 충분하지 않습니다.
에 큰 감사와 토마스 슈타이너 , 알렉스 러셀 , 제레미 바그너 , 패트릭 Hulce , 톰 금속 앵커 및 Houssein Djirdeh 이 쓰기까지 자신의 기여. 웹 페이지 테스트 (WebPageTest)에 대한 그의 지속적인 작업에 대한 Pat Meenan 덕분에 - 관심 이있으시면 이 페이지에 대한 등대 보고서가 있습니다. 트위터에서 내 작업을 팔로우 할 수 있습니다 .
