The Cost Of JavaScript In 2018

  • 2019-01-08 04:32 AM
  • 542

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? The Cost Of JavaScript In 2018

Aiodex’s Referral Program  will give you 20% -80% commission from their transaction fee for 7 years. The value will be calculated starting from the date the member you invite sign up ☞ https://aiodex.com/p/referral-program
Next Generation Shorten Platform. Optimal choice to make a profit and analyze traffic sources on the network. Shorten URLs and earn big money ☞ http://vrl.to/
Get Free 15 Geek ☞ https://geekcash.org/
Playlists Video Tutorial ☞ http://on.edupioneer.net/7cd1499b1f
Developers Chat Channel ☞ https://discord.gg/KAe3AnN
Learn to code for free and get a developer job ☞ https://codequs.com

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

The Cost Of JavaScript In 2018

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

tl;dr:

  • To stay fast, only 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 and client-rendering are a disaster if done poorly.

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:

The Cost Of JavaScript In 2018

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 Cost Of JavaScript In 2018

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.

The Cost Of JavaScript In 2018

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.

The Cost Of JavaScript In 2018

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:

The Cost Of JavaScript In 2018

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?

JavaScript has a cost

The Cost Of JavaScript In 2018

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?

The Cost Of JavaScript In 2018

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?

The Cost Of JavaScript In 2018

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.

The Cost Of JavaScript In 2018

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