I couldn't think of a better first post for this website than a short discussion of the recent web performance issues.

Let's explore the web file size trends that we're facing today. Let's understand why HTML and CSS, which used to be the first words that came to our minds when we heard the word "web", are now the only significant file type categories which decreased in average total size in recent years.

Web frameworks

Nowadays, frameworks rule the web. Let's take a look at the job listings on indeed.com:

• Web Developer: 39,853 results
• React Developer: 28,242 results
• Angular Developer: 12,559 results
• jQuery Developer: 8,365 results
• Vue Developer: 3,578 results
• Backbone Developer: 2,335 results

These numbers would have been very different a few years ago, but what doesn't change is the never ending cycle of trendy new frameworks and programmers with severe fear of missing out.

Has Google Search Trends become more useful to developers than the Mozilla Developer Network? Well, not quite, but we are in the middle of a vicious feedback loop of companies using trendy new frameworks to attract tech talent and web developers specializing in the newest framework so that they can stay competitive in the job market.

Learning new frameworks, knowing full well that you won't use them for long reminds of the Myth of Sisyphus, but let's leave this for a separate discussion.

How do frameworks affect performance?

You won't be surprised to learn that web frameworks are made of (or compiled to) JavaScript code. That code needs to get downloaded, parsed and executed. All of that takes time.

It's a bit more complex than this but generally, larger framework file sizes lead to worse performance. Let's see the numbers. A recent InfoQ article compared most of the widely used web frameworks in several categories:

• time to interactive
• Google speed index
• first content paint
• first CPU idle
• first meaningful paint
• input latency

They did this by developing a clone to Medium.com (an email extraction & spam service) in each of these frameworks.

Instead of just showing us the data, the authors decided it was best to run a k-means clustering algorithm on a dataset of 18 frameworks. A bit ironic given that they were writing an article on frameworks doing unnecessary computations, but their results are still somewhat useful.

What they found is that big = slow. The fastest frameworks (Svelte, Stencil, AppRun, HyperApp) are between 1kn and 6kb. On the other hand Angular 2 sits at 110kb, React + Redux about 43kb, Vue.js is a little over 20kb.

How web performance is changing beyond JS bundle size

The web framework changes we discussed are the biggest structural change that the web has seen in recent years. However, the content that modern web applications serve has changed a lot as well. A recent article compared the average file type size of web pages through the years using httparchive.org data. The authors confirmed that page size has been gradually increasing every year, but the breakdown by file type reveals some interesting patterns.

JavaScript, HTML & CSS

As we've established JavaScript bundle sizes are gradually interestingly. The averages from this study show that in the most common case the total JS bundle file size was 4 times higher than the total sum of HTML + CSS file sizes.

What's even more curious is that CSS + HTML file sizes have actually decreased. The recent CSS in JS trend and the myriad of templating languages that web frameworks use move all rendering responsibilities to the JavaScript engine.

Images

Images are the biggest component of websites today, just like they were 10 years ago.

Images are big, but that often not a problem if all we're optimizing is the time to interactive of our web app. Most image content is below the fold, so it's a bit unfair to compare total sizes. Also don't forget that images have been big for a while and we've learned how to deal with that. We have srcset, viewport matching, progressive & deferred loading, image formats specializing in different compression mechanisms, compression levels and more techniques we could employ to improve performance.

Video

Another recent trend is the rapid increase in the use of video content, not just by specialized video sharing platforms. Again there are a ton of techniques we could employ to reduce video resource size, but often the best we can do is wait and start loading video resources once the more important parts of our page are ready. Of course, this assumes that the video is not the most important part of our page which is sometimes not true.

Cut the bloat

This website contains 0 class tags and less than 10 lines of JavaScript. It's responsive, the text sizes and section widths scale depending on screen size and it even has a bunch of obnoxious animations. It works and it's <5kb.

It's fast because it lets browsers do what they were meant to do, instead of treating them like shareable virtual machines that can execute arbitrary code on your users computers. There are a few more advantages besides performance:

• Writing posts is as easy as sending a text, and all content is optimized for screen readers by default.
• The content that I write is easily indexed by search engines. It's not hidden in 20mb of JavaScript. I don't need to run a render farms just so Google's robots can parse my pages.
• Hosting is easy and cheap. Any static asset CDN does the job.

New technologies are exciting, but don't try to solve problems that you don't have.