Hacker News new | ask | show | jobs
by jameslk 2001 days ago
It seems web performance is one of the least understood topics, even for engineers. Unfortunately even this author makes the mistake of confusing DOM Interactive[0] with Time to Interactive[1]. And yet this is a better analysis than what I often see repeated backed with no evidence.

For example, the myths about page weight and big SPA JS websites being the source of web performance issues is one I see so frequently here. Even in this thread others have started to claim the problem is all JS (take a closer look at the article). And it's good to see some actual data to back what I actually have seen optimizing many websites myself (spoiler: a lot of badly performing sites use jQuery).

For speed (which is also a complex subject that can't be captured in one metric[2]), the problem isn't page weight or JS frameworks, it's network latency[3]. Because you can't optimize the speed of light. This is especially true for websites that connect to many different origins (usually for different types of analytics services) and for many things related to the critical render path[4].

The issues I see most often are not the huge frameworks loading, but inefficient loading of all resources, especially those that will affect user-centric timing metrics. I frequently see many render-blocking CSS and JS files loaded which increases First Contentful Paint. I see images, script code, and other resources that affect below-the-fold content loaded before above-the-fold content and resources. And of course my favorite: above-the-fold content loaded with JS. These affect Largest Contentful Paint. Etc etc.

Of course we can all claim the problem is something else and collectively decide to switch to server-side rendering as an industry but this won't fix issues with web performance. Understanding how browsers load pages and how your users perceive the load will.

0. https://developer.mozilla.org/en-US/docs/Web/API/Performance...

1. https://web.dev/interactive/

2. https://developers.google.com/web/fundamentals/performance/s...

3. https://www.speedshop.co/2015/11/05/page-weight-doesnt-matte...

4. https://developers.google.com/web/fundamentals/performance/c...

2 comments

Yep, we have an SPA at work. It's not even small - around 2MB - but it loads, parses, and renders almost instantly (say <300ms - not bad for a complex app). However, in practice users don't get into the app for a couple of seconds. This is due to it making several slow network requests to check auth and load data before letting you in.

I have a WIP branch that caches things locally, but my boss tells me that the app is fast enough and I should be working on other things. And I'm loathe to sneak it in without proper testing as caching is something that has a tendency to break in horrible ways if you're not careful.

> the problem isn't page weight or JS frameworks, it's network latency[3].

if that was the case electron apps with content available locally would not be so slow

I'm comparing website vs website when I'm talking about web performance. You're comparing Electron apps vs... native apps?
> I'm comparing website vs website when I'm talking about web performance.

web implies "everything built with web technologies", whether it runs locally or not