Front-End Performance Checklist

A handy pre-launch go/no-go checklist to run through before your countdown.

 Front-End Performance Checklist

Tagged with

Related links

Reminder: You Can Stitch Together Lots of Little HTML Pages With Navigations For Interactions - Jim Nielsen’s Blog

I really like the thinking that goes into this approach. It seems so counter-intuitive at first, but there’s no arguing with the snappy resilient results.

Turns out, if you have a website and you think of the browser as a way to navigate documents — rather than a runtime to execute arbitrary code and fetch, compile, and present them — things can be a lot simpler than our tools often prime us to make them.

Tagged with

Tagged with

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

Frameworks like React are often perceived as accelerators, or even as the only sensible way to do web development. There’s this notion that a more “modern” stack (read: JS-heavy, where the JS ends up running on the user’s browser) allows you to be more agile, release more often with fewer bugs, make code more maintainable, and ultimately launch better sites. In short, the claim is that this approach will offer huge improvements to developer experience, and that these DevEx benefits will trickle down to the user.

But over the years, this narrative has proven to be unrealistic, at best. In reality, for any decently sized JS-heavy project, you should expect that what you build will be slower than advertised, it will keep getting slower over time while it sees ongoing work, and it will take more effort to develop and especially to maintain than what you were led to believe, with as many bugs as any other approach.

Where it comes to performance, the important thing to note is that a JS-heavy approach (and particularly one based on React & friends) will most likely not be a good starting point; in fact, it will probably prove to be a performance minefield that you will need to keep revisiting, risking a detonation with every new commit.

Tagged with

Tagged with

The Main Thread Is Not Yours — Den Odell

Every millisecond you spend executing JavaScript is a millisecond the browser can’t spend responding to a click, updating a scroll position, or acknowledging that the user did just try to type something. When your code runs long, you’re not causing “jank” in some abstract technical sense; you’re ignoring someone who’s trying to talk to you.

This is a great way to think about client-side JavaScript!

Also:

Before your application code runs a single line, your framework has already spent some of the user’s main thread budget on initialization, hydration, and virtual DOM reconciliation.

Tagged with

Related posts

Testing browser support for `focusgroup`

A bit of feature detection for a proposed new HTML attibute.

Why use React?

Or, more precisely, why use React *in the browser*?

Reasoning

In which I find a tagline for Web Day Out and a tagline for React.

The Invisibles

Making a checklist of things that fall somewhere between front-end and back-end development.

Streamlining HTML web components

Some handy tips courtesy of Chris Ferdinandi.