Size matters

Frontend frameworks. There's a lot. A quick google search returns frameworks with names I haven't heard nor will remember. Why there are so many is another story. For now let's look at React, an extremely popular framework, and check out its production size when bootstrapping a web React application using Create React App (CRA), a command line interface utility.

The following questions need answers:

  • How big is CRA's React build for web?
  • How many KB's does the browser need before being able to render user interfaces?
  • Roughly how long does it take to download a production ready web React build?

Take my strong hand and let's find out.

Create React App v1.5.2 was release early 2018 and was used here. Tidbit: v0.0.0 and v0.1.0 were released early 2016.

1
2
3
4
5
6
7
8
9
> react-scripts build

Creating an optimized production build...
Compiled successfully.

File sizes after gzip:

36.94 KB build/static/js/main.a285be49.js
299 B build/static/css/main.c17080f1.css

Okay, cool! That's not so heavy, although the file is gzipped.

Bare in mind, CRA includes one component that renders to screen on base URL load. I reckon this is totally negligible.

Let's look to the browser to answer how big the file is after inflating (decompressing) it. Chrome says the file is 116KB. Woah. Okay. ~1/10 MB.

Using Chrome's Network throttling feature, how long does it take to download main.a285be49.js on decent mobile hardware, say 3G?

Type Hardware Time
Content download Slow 3G 2.29s
Total cycle Slow 3G 4.34s
Content download Fast 3G 621.20ms
Total cycle Fast 3G 1.21s

Looking at Slow 3G speeds, content download takes 2.29s and the total request-response cycle takes 4.34s.

There are many factors influencing how long it takes to start executing JavaScript in the browser runtime, primarily infrastructure and hardware (shown above) and the 1's and 0's (code) sent over the wire, not to mention the processing time a CPU takes to inflate a gzipped file.

To draw a conclusion and end this short masterpiece, size matters - we should all pay close attention to our file sizes, dependency sizes and the scope of work applicable; large apps can bear the cost of large JavaScript build sizes whereas smaller or less complex use cases can not.

Why does this matter? Well, Mr. Sloth, web surfing happens fast, like Formula One fast. We need to engage users quickly, retaining attention and desired flow; breaking flow with load time can cost us developers users. Bad, mm'kay. Determining whether a use case warrants a particular framework and it's size is a critical design decision and can shape your entire project going forward. Perhaps for your next project vanilla JavaScript will do just fine, maybe better. May the force be with you.