Tech News
← Back to articles

JavaScript-heavy approaches are not compatible with long-term performance goals

read original related products more articles

This post is a (very long) opinion piece, albeit one that I hope is somewhat substantiated by the accompanying anecdotes. The TL;DR is that in my experience the title is a correct statement the vast majority of the time, and we should favour more server-centric approaches instead, when possible.

What I mean by “JS-heavy approaches“ I use this term to refer to any approach that relies on shipping large quantities of JS to the browser, for the browser to execute as an intrinsic part of using the web app, often in the critical path. These sorts of approaches are usually associated with Single-page Applications (SPAs), but do unfortunately pop up in Multi-page Applications (MPAs) as well.

Background

My experience

In case you don’t know me, hi! 👋 I work full-time on web performance at Automattic, as part of a small PerfOps team whose mission is to improve performance across the various things we build or work on as a company. Our team also builds and maintains our company’s performance monitoring infrastructure, but the majority of our time is spent finding and fixing performance issues across our various stacks, all the way from optimising DB queries to fixing janky CSS animations.

Personally, I specialize on the browser side of things. As part of this work, I have had more than my share of debugging sessions for loading performance issues, runtime performance problems, bundle size increases, framework-specific issues like expensive re-renders in React , etc., and there are some underlying root causes I’ve seen over and over again. These problems are not necessarily insurmountable, but they do add up to reveal some important gaps and outright falsehoolds in the narrative about the “modern web development approach” that we’ve been sold over the years.

Caveats

I don’t think I’ll necessarily bring any groundbreaking revelations to the table, nor do I come with a large corpus of data to back anything up as the unquestionable truth. This is all based on my own experience, and may not apply to what any given project is doing, particularly if it’s a small web app maintained by a focused, dedicated team.

Also note that I’ll be jumping between different aspects of web performance throughout the post, without much thought. That’s because while they’re all distinct, they’re all important! You don’t want to have an application that takes forever to load, any more than one that is sluggish at rendering the characters the user is typing, or one that has a disruptive delay on in-app navigations.

The pitch and the reality of frameworks

... continue reading