Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
May 27, 2021 07:00 am GMT

The Cost Of JavaScript

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 web is bloated by user experience

When users access your site youre probably sending down a lot of files, many of which are scripts. From a web browsers perspective this looks a little bit like this:
As much as I love JavaScript, its always the most expensive part of your site. Id like to explain why this can be a major issue.

JOIN THEVIKCODE NEWLETTER ( GET DAILY WHICH WILL NOT BE AVAIBLE HERE ) - https://thevikcode.substack.com/

JavaScript has a cost

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 dont 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.

Why is JavaScript so expensive?

To explain how JavaScript can have such a large cost, Id like to walk you through what happens when you send content to a browser. A user types a URL into the browsers 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, its 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 cant 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.

Mobile is a spectrum.

If were 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 youre using.

How to send less JavaScript

The shape of success is whatever lets 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.

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. Its something thats well supported by many modern libraries and frameworks through bundlers like webpack and Parcel. Guides to accomplish this are available for React, Vue.js and Angular.

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.

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.

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.


Original Link: https://dev.to/square/the-cost-of-javascript-182b

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To