Thread by @JoshWComeau

🌠 It's so easy to get sucked into performance micro-optimization territory.

Someone will say that Method X is slow, and inevitably somebody else will point out that it doesn't really matter outside of contrived, unrealistic benchmarks.

🧵 I wanna dig into that a bit…

Here's an example. We have a list of users, and we wanna filter so that we only show the people who are online.

We can do that with a "filter", or with a "reduce", or with a "forEach". Which is faster? Does it matter? Why or why not?

Code: codesandbox.io/s/crazy-herman…

Well, we can measure how long it takes!

Browsers come with a "Performance" API that lets us take high-res snapshots, offering sub-millisecond precision, so we can measure small gaps.

Here's what that code looks like:

(Quick caveat: In an effort to reduce fingerprinting, some browsers will limit the precision of this DOM API. In Firefox, you can temporarily loosen this restriction by setting the "reduceTimerPrecision.microseconds" setting to 1)

In the current setup, with 250 items in the array, here's how long various methods take:

• `filter`: 40μs (0.04ms)
• `reduce`: 90μs (0.09ms)
• `forEach`: 60μs (0.06ms)

(Approximate numbers, running each one 10 times and taking a rough average)

The slowest of these is incredibly quick. In the span of a human blink, the `reduce` solution can run over 1000 times.

But that's with 250 items. What if the # of items was much, much bigger? The reduce solution is 2x slower, won't that matter when we have millions of items?

We don't need to worry about that on the front-end, because we won't ever have millions of items. If we did, we'd have *way bigger* problems than the JS iteration speed.

The reason we iterate through data is because we want to render something, and rendering is *expensive*.

Google recommends that our page shouldn't have more than 1500 DOM nodes, total. DOM nodes consume a lot of memory, and the browser will explode if we try rendering millions of them. We should paginate our data, so that we're only dealing with small amounts at a time.

Our code example filters for users that are online, which happens to be about 50% of them. If I increase that number to 2500, we get awfully close to that DOM node limit.

The slowest method still only takes ~175μs (0.175ms). The performance doesn't scale linearly.

Now, there is a clever technique called virtualization that can help us here.

The idea with virtualization is that we only render what's in the viewport (along with a bit of a "buffer"). In theory, we only have to pay for the elements we can see at one time.

Virtualization is a fantastic technique and should absolutely be used when dealing with large data, but it doesn't give us carte blanche to have infinitely large data sets!

All of that data still needs to come over the wire, and make it to the user. If we try to send 100,000 objects, that payload will be big and slow, and it'll take a while for the browser to download and parse it, even before getting to any iteration.

There are also memory concerns; once we receive this data, we have to hold it in RAM. Modern devices have a lot of it, but they also have a lot of Chrome tabs to manage.

It's just never a good idea to be dealing with millions of items in JS. Not on the front-end. And not really on the back-end either. Databases are good at doing this stuff. We should be doing it at the database layer.

If we use virtualization, we *might* be able to get away with 10k items. Maybe.

With 10k items, the slowest "reduce" method still takes less than 1ms (~400μs).

I can guarantee that many other steps in the render process will be orders of magnitude slower than this.

Some context around human time perception: if something happens within 100ms or less, it'll feel instant for us. If I click a button and the screen has repainted in <100ms, it feels snappy AF.

(the exception is animation: if something is moving across the screen, we need to repaint it 60 times a second for it to feel fluid, which works out to 16.6ms per frame.)

(Either way, though. JS iteration time is a drop in the bucket.)

I think we often lose the forest for the trees when we talk about performance. We get caught up in the metrics. Really, the only thing that matters is if the user gets bored waiting for our page to load/react.

A rant for another day: _perceived_ performance matters way more than raw transfer/load speeds, but it's harder to measure / fit into a KPI.

UX optimizations, not JS optimizations, are often the lowest-hanging fruit.

When iterating in JS, it's way more important to focus on readability. Choose the method that is easiest to understand, not the one which is fastest. Especially on the front-end, there are bigger fish to worry about when it comes to performance.

If you still find yourself worrying that a particular method may be slow, you can always measure it! In fact, this is a good habit to get into, as it helps build your intuition for what's quick & what's slow.

Combine this with profiling layout/paint times for a sense of scale 😄

Thanks for reading all the way through; this thread got longer than I expected 😅

If you'd like to learn more about performance optimizations on the front-end, I go way deeper in my 2019 React Rally talk: