JavaScript 的代价(2018 版) 已翻译 100%

oschina 投递于 2018/08/06 15:41 (共 18 段, 翻译完成于 08-17)
阅读 4330
收藏 41
5
加载中

About the author:

Addy Osmani,Eng. Manager at Google working on Chrome • Passionate about making the web fast.

Building interactive sites can involve sending JavaScript to your users. Often, too much of it. Have you been on a mobile page that looked like it had loaded only to tap on a link or tried to scroll and nothing happens?

Byte-for-byte, JavaScript is still the most expensive resource we send to mobile phones, because it can delay interactivity in large ways.


JavaScript processing times for CNN.com as measured by WebPageTest (src). A high-end phone (iPhone 8) processes script in ~4s. Compare to the ~13s an average phone (Moto G4) takes or the ~36s taken by a low-end 2018 phone (Alcatel 1X).

Today we’ll cover some strategies you can use to deliver JavaScript efficiently while still giving users a valuable experience.

tl;dr:

  • To stay fastonly load JavaScript needed for the current page.Prioritize what a user will need and lazy-load the rest with code-splitting. This gives you the best chance at loading and getting interactive fast. Stacks with route-based code-splitting by default are game-changers.

  • Embrace performance budgets and learn to live within them. For mobile, aim for a JS budget of < 170KB minified/compressed. Uncompressed this is still ~0.7MB of code. Budgets are critical to success, however, they can’t magically fix perf in isolation. Team culture, structure and enforcement matter. Building without a budget invites performance regressions and failure.

  • Learn how to audit and trim your JavaScript bundles. There’s a high chance you’re shipping full-libraries when you only need a fraction, polyfills for browsers that don’t need them, or duplicate code.

  • Every interaction is the start of a new ‘Time-to-Interactive’; consider optimizations in this context. Transmission size is critical for low-end mobile networks and JavaScript parse time for CPU-bound devices.

  • If client-side JavaScript isn’t benefiting the user-experience, ask yourself if it’s really necessary. Maybe server-side-rendered HTML would actually be faster. Consider limiting the use of client-side frameworks to pages that absolutely require them. Server-rendering andclient-rendering are a disaster if done poorly.

(Video for my recent talk on “The Cost of JavaScript” on which this write-up is based :https://youtu.be/63I-mEuSvGA

已有 1 人翻译此段
我来翻译

The web is bloated by user “experience”

When users access your site you’re probably sending down a lot of files, many of which are scripts. From a web browsers’ perspective this looks a little bit like this:


A mad rush of files being thrown at you.

As much as I love JavaScript, it’s always the most expensive part of your site. I’d like to explain why this can be a major issue.


The median webpage today currently ships about 350 KB of minified and compressed JavaScript. Uncompressed, that bloats up to over 1MB of script a browser needs to process.

Note: Unsure if your JavaScript bundles are delaying how quickly users interact with your site? Check out Lighthouse.


Statistics from the HTTP Archive state of JavaScript report, July 2018 highlight the median webpage ships ~350KB of minified and compressed script. These pages take up to 15s to get interactive.

Experiences that ship down this much JavaScript take more than 14+ seconds to load and get interactive on mobile devices.

A large factor of this is how long it takes to download code on a mobile network and then process it on a mobile CPU.

Let’s look at mobile networks.


Countries that perform better in a particular metric are shaded darker. Countries not included are in grey. It’s also worth noting that rural broadband speeds, even in the US, can be 20% slower than urban areas.

This chart from OpenSignal shows how consistently 4G networks are globally available and the average connection speed users in each country experience. As we can see, many countries still experience lower connection speeds than we may think.

Not only can that 350 KB of script for a median website from earlier take a while to download, the reality is if we look at popular sites, they actually ship down a lot more script than this:


Uncompressed JS bundle size numbers from “Bringing Facebook.com and the web up to speed”. Sites like Google Sheets are highlighted as shipping up to 5.8MB of script (when decompressed).

We’re hitting this ceiling across both desktop and mobile web, where sites are sometimes shipping multiple megabytes-worth of code that a browser then needs to process. The question to ask is, can you afford this much JavaScript?

已有 1 人翻译此段
我来翻译

JavaScript has a cost


“Sites with this much script are simply inaccessible to a broad swath of the world’s users; statistically, users do not (and will not) wait for these experiences to load” — Alex Russell

Note: If you’re sending too much script, consider code-splitting to break up bundles or reducing JS payloads using tree-shaking.

Sites today will often send the following in their JS bundles:

  • A client-side framework or UI library

  • A state management solution (e.g. Redux)

  • Polyfills (often for modern browsers that don’t need them)

  • Full libraries vs. only what they use (e.g. all of lodash, Moment + locales)

  • A suite of UI components (buttons, headers, sidebars etc.)

This code adds up. The more there is, the longer it will take for a page to load.

Loading a web page is like a film strip that has three key moments.

There’s: Is it happening? Is it useful? And, is it usable?


Loading is a journey. We’re shifting to increasing caring about user-centric happiness metrics. Rather than just looking at onload or domContentLoaded, we now ask “when can a user actually *use* the page?”. If they tap on a piece of user-interface, does it respond right away?

Is it happening is the moment you’re able to deliver some content to the screen. (has the navigation started? has the server started responding?)

Is it useful is the moment when you’ve painted text or content that allows the user to derive value from the experience and engage with it.

And then is it usable is the moment when a user can start meaningfully interacting with the experience and have something happen.

I mentioned this term “‘interactive” earlier, but what does that mean?


A visualization of Time-to-Interactive highlighting how a poorly loaded experience makes the user think they can accomplish a goal, when in fact, the page hasn’t finished loading all of the code necessary for this to be true. With thanks to Kevin Schaaf for the interactivity animation

For a page to be interactive, it must be capable of responding quickly to user input. A small JavaScript payload can ensure this happens fast.

Whether a user clicks on a link, or scrolls through a page, they need to see that something is actually happening in response to their actions. An experience that can’t deliver on this will frustrate your users.


Lighthouse measures a range of user-centric performance metrics, like Time-to-Interactive, in a lab setting.

One place this commonly happens is when folks server-side render an experience, and then ship a bunch of JavaScript down afterward to “hydrate” the interface (attaching event handlers and extra behaviors).

When a browser runs many of the events you’re probably going to need, it’s likely going to do it on the same thread that handles user input. This thread is called the main thread.

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:https://youtu.be/N5vFvJUBS28

Avoid blocking the main thread as much as possible. For more, see “Why web developers need to care about interactivity

已有 1 人翻译此段
我来翻译

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 where

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)

Measuring the Time-to-Interactive of Google News on mobile, we observe large variance between a high-end getting interactive in ~7s vs. a low-end device getting interactive in 55s. So, what is a good target for interactivity?


When it comes to Time to Interactive, we feel your baseline should be getting interactive in under five seconds on a slow 3G connection on a median mobile device. “But, my users are all on fast networks and high-end phones!” …are they? You may be on “fast” coffee-shop WiFi but effectively only getting 2G or 3G speeds. Variability matters.

已有 1 人翻译此段
我来翻译

Who has shipped less JavaScript and reduced their Time-to-Interactive?


Let’s design for a more resilient mobile web that doesn’t rely as heavily on large JavaScript payloads.

Interactivity impacts a lot of things. It can be impacted by a person loading your website on a mobile data plan, or coffee shop WiFi, or just them being on the go with intermittent connectivity.


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.

已有 1 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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:


Processing (parse/compile) times for 1MB of uncompressed JavaScript (<200KB minified and gzipped) manually profiled on real devices. (src)

At the top we have high-end devices, like the iPhone 8, which process script relatively quickly. Lower down we have more average phones like the Moto G4 and the <$100 Alcatel 1X. Notice the difference in processing times?

Android phones are getting cheaper, not faster, over time. These devices are frequently CPU poor with tiny L2/L3 cache sizes. You are failing your average users if you’re expecting them to all have high-end hardware.

Let’s look at a more practical version of this problem using script from a real-world site. Here’s the JS processing time for CNN.com:


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.

This hints that maybe we need to stop taking fast networks and fast devices for granted.


Some users are not going to be on a fast network or have the latest and greatest phone, so it’s vital that we start testing on real phones and real networks . Variability is a real issue.

已有 1 人翻译此段
我来翻译

“Variability is what kills the User Experience” — Ilya Grigorik. Fast devices can actually sometimes be slow. Fast networks can be slow, variability can end up making absolutely everything slow.

When variance can kill the user experience, developing with a slow baseline ensures everyone (both on fast and slow setups) benefits. If your team can take a look at their analytics and understand exactly what devices your users are actually accessing your site with, that’ll give you a hint at what devices you should probably have in the office to test your site with.


Test on real phones & networks.

webpagetest.org/easy has a number of Moto G4 preconfigured under the “Mobile” profiles. This is valuable in case you’re unable to purchase your own set of median-class hardware for testing.

There’s a number of profiles set up there that you can use today that already have popular devices pre-configured. For example, we’ve got some median mobile devices like the Moto G4 ready for testing.

It’s also important to test on representative networks. Although I’ve talked about how important low end and median phones are, Brian Holt made this great pointit’s really important to know your audience.


“Knowing your audience and then appropriately focusing the performance of your application is critical” — Brian Holt (src)

Not every site needs to perform well on 2G on a low-end phone. That said, aiming for a high level of performance across the entire spectrum is not a bad thing to do.


Google Analytics > Audience > Mobile > Devices visualizes what devices & operating systems visit your site.

You may have a wide range of users on the higher end of the spectrum, or in a different part of the spectrum. Just be aware of the data behind your sites, so that you can make a reasonable call on how much all of this matters.

If you want JavaScript to be fast, pay attention to download times for low end networks. The improvements you can make there are: ship less code, minify your source, take advantage of compression (i.e., gzipBrotli, and Zopfli).


Take advantage of caching for repeat visits. Parse time is critical for phones with slow CPUs.


If you’re a back-end or full stack developer, you know that you kind of get what you pay for with respect to CPU, disk, and network.

As we build sites that are increasingly more reliant on JavaScript, we sometimes pay for what we send down in ways that we don’t always easily see.

已有 1 人翻译此段
我来翻译

How to send less JavaScript

The shape of success is whatever let’s us send the least amount of script to users while still giving them a useful experience. Code-splitting is one option that makes this possible.


Splitting large, monolithic JavaScript bundles can be done on a page, route or component basis. You’re even better setup for success if “splitting” is the default for your toolchain from the get-go.

Code-splitting is this idea that, instead of shipping down your users a massive monolithic JavaScript bundle — sort of like a massive full pizza — what if you were to just send them one slice at a time? Just enough script needed to make the current page usable.

Code-splitting can be done at the page level, route level, or component level. It’s something that’s well supported by many modern libraries and frameworks through bundlers like webpack and Parcel. Guides to accomplish this are available for ReactVue.js and Angular.


Adding code-splitting in a React app using React Loadable — a higher-order component that wraps dynamic imports in a React-friendly API for adding code-splitting to your app at a given component.

Many large teams have seen big wins off the back of investing in code-splitting recently.


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.

已有 1 人翻译此段
我来翻译
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(6)

collinChen
collinChen

引用来自“开源中国-首席村长”的评论

JS脚本为什么不能延迟加载/执行呢?也就是先加载渲染DOM元素,完成后再在后台下载js脚本文件再执行

引用来自“半世为仙”的评论

js有可能动态生成dom,改写当前dom,更新当前dom。如果先渲染dom,再加之js,那么用户所见有可能并不是所得。

引用来自“喻恒春”的评论

到目前为止, js 和 DOM 的主流关系依然是 动态和静态强耦合关系.
开发者难以做到彻底解耦, 为了快速开发大量使用"成品"库, 致使开发基于 "业务表现", 而不是剥离出的 "业务数据逻辑".
不深挖"数据逻辑", 还要快速开发, 还想降 JS 尺寸, 这世界哪里有这么好的事儿.

想降低尺寸很简单: 所有代码根据业务逻辑定制, 不被执行的代码通通剔除.
可有多少人会这么干呢?

有句话说的很有道: 解决了 10 个 BUG, 又创造了 11 个新 BUG
然后又来了12个需求....
莫默磨墨先生
莫默磨墨先生
这种就一个点深挖的优化,基本都是固定业务的某一个站。而现实中很多项目尤其是外包项目,追求的是快速实现,从一开始就追求极致的优化,不现实。
喻恒春
喻恒春

引用来自“开源中国-首席村长”的评论

JS脚本为什么不能延迟加载/执行呢?也就是先加载渲染DOM元素,完成后再在后台下载js脚本文件再执行

引用来自“半世为仙”的评论

js有可能动态生成dom,改写当前dom,更新当前dom。如果先渲染dom,再加之js,那么用户所见有可能并不是所得。
到目前为止, js 和 DOM 的主流关系依然是 动态和静态强耦合关系.
开发者难以做到彻底解耦, 为了快速开发大量使用"成品"库, 致使开发基于 "业务表现", 而不是剥离出的 "业务数据逻辑".
不深挖"数据逻辑", 还要快速开发, 还想降 JS 尺寸, 这世界哪里有这么好的事儿.

想降低尺寸很简单: 所有代码根据业务逻辑定制, 不被执行的代码通通剔除.
可有多少人会这么干呢?

有句话说的很有道: 解决了 10 个 BUG, 又创造了 11 个新 BUG
疯兔子
疯兔子

引用来自“开源中国-首席村长”的评论

JS脚本为什么不能延迟加载/执行呢?也就是先加载渲染DOM元素,完成后再在后台下载js脚本文件再执行
可以延迟加载,问题是js有可能会阻碍交互,例如:js没加载完,按钮有可能不能点击
前端之虎陈随易
前端之虎陈随易

引用来自“开源中国-首席村长”的评论

JS脚本为什么不能延迟加载/执行呢?也就是先加载渲染DOM元素,完成后再在后台下载js脚本文件再执行
js有可能动态生成dom,改写当前dom,更新当前dom。如果先渲染dom,再加之js,那么用户所见有可能并不是所得。
osc_2425058
osc_2425058
JS脚本为什么不能延迟加载/执行呢?也就是先加载渲染DOM元素,完成后再在后台下载js脚本文件再执行
返回顶部
顶部