Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The browser's main thread is expensive

kciter.so

Post reply on HN
Print view View original

151–160 of 171 posts

Re: The browser's main thread is expensive

#151

Post by jcelerier »

deathanatos wrote: post #135
jcelerier wrote: post #56

Earlier quoted context omitted.

I challenge you to browse the web one week on this laptop part of the current top 10 Amazon best sellers on a gigabit fiber connection and tell me if you still think that this is the problem: https://www.amazon.com/HP-Everyday-Processor-Microsoft-Porta...

> 【Processor】AMD Processor > 【Graphics】 Intel Graphics And this is why you don't buy laptops from Amazon. At best, the seller has no idea what they're doing, at worst, this is fraud.

my point is that as programmers we have to take into account that the average human today has a computer that likely struggles to open Win11 notepad. I don't buy random laptops from amazon, but an astonishingly high amount of people do and we have to work with that

Re: The browser's main thread is expensive

#152

Post by martinald »

pverheggen wrote: post #130
martinald wrote: post #113

Earlier quoted context omitted.

I'm not sure the author realises _what_ a massive impact bundle size has on the main thread though, especially hydration. The majority of apps I've optimised over the years have the (often vast) majority of main thread time spent on the bundle parse/hydration (plus obviously network). Also, removing dependencies is not easy. I've seen many corporate that have a huge UI lib for example that everyone should use for bra…

All good points. Perhaps rather than saying the fixes are straightforward, I should have said it's a straightforward concept to understand. If your app takes forever to load because of a huge bundle, you need to figure out how to make the bundle smaller, somehow. (How exactly to do that is where it gets complicated, like you say.)

Tbh its not just that, you can have small bundles which hydrate extremely poorly.

But yes, I think we are in agreement :).

Can you tell I have mental scars from nextjs bundle optimisation?

Re: The browser's main thread is expensive

#153

Post by martinald »

fpoling wrote: post #150
Spivak wrote: post #128

Earlier quoted context omitted.

Okay so that's no excuse for whoever is providing your internet, coax can deliver 800+ Mbps no problem. And if you are actually saying you only get DSL through a phone line in London then holy shit I would be busting down the door of my landlord. They never in the last half a century got wired for cable?!

A phone line from before WWII works fine to make a call but absolutely sucks for DSL. And in London many buildings are declared as historic making it hard to get a permit for any work. The best chance is to wait until old pipes bursts and digging has to be done in any case to put fiber along the pipes.

It's not that, it's the building owners (freeholders) refusing permission, or not replying. It's a massive issue.

You'll notice buildings in central London that are listed _but_ have housing association ownership nearly all have fibre to each apartment, as they did portfolio wide deals with hyperoptic etc.

And pipes don't help. Openreach (who owns the copper network) are not allowed in 99% of cases to "fix" copper with fibre under the agreements they have with building owners, they can only make like for like repairs.

The worst affected apartment buildings are 90s and pre 2015ish. Everything after that got fibre installed at build time.

Btw it is worth checking if you have an altnet like hyperoptic, community fibre or g network available. The majority do and if you are just checking for openreach or VM broadband it won't show up.

Re: The browser's main thread is expensive

#154

Post by BobbyTables2 »

pjmlp wrote: post #66
martinald wrote: post #49

Good article and I wish this was much better known. The issue is though that it's too focused on interactivity. In reality, 90%++ of slow sites are not slow because of interactivity really, they are slow because they ship enormous react/nextjs bundles and have extremely heavy hydration work to do. _so many_ sites have bundles >10MB that need to be downloaded, parsed and hydrated. I've even seen (many) sites which hav…

99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps.

I expect soon each website will have its own browser, compiled as WASM which will be launched in order to render the JavaScript and HTML on the website.

Re: The browser's main thread is expensive

#155

Post by gavinsyancey »

BobbyTables2 wrote: post #154
pjmlp wrote: post #66

Earlier quoted context omitted.

99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps.

I expect soon each website will have its own browser, compiled as WASM which will be launched in order to render the JavaScript and HTML on the website.

This is actually plausible as a way to prevent adblock.

Re: The browser's main thread is expensive

#156

Post by Dylan16807 »

econ wrote: post #137
odo1242 wrote: post #103

Earlier quoted context omitted.

Cooperative multitasking isn’t universally a bad idea (in fact, Rust supports it)

I can't think of a better way to make simple things billions of times slower than they should be.

> I can't think of a better way to make simple things billions of times slower than they should be.

How's it going to do that? What's so bad about it? Especially in the multi-core era which lets multiple programs run at the same time the way that multiple pages can run javascript at the same time. The lack of preemption is only within a single page/program.

During periods of time where no single chunk of code runs for more than a millisecond, cooperative multitasking should have the exact same performance as preemptive multitasking. And even when single chunks of code do run for that long, if that code wasn't properly isolated then preemption doesn't save you from lag.

So the difference only shows up when you have chunks of code that keep running way too long, that are also inside of properly isolated threads/callbacks, and on web those threads/callbacks are not inside web workers. Is that a common situation?

Re: The browser's main thread is expensive

#157

Post by pjmlp »

BobbyTables2 wrote: post #154
pjmlp wrote: post #66

Earlier quoted context omitted.

99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps.

I expect soon each website will have its own browser, compiled as WASM which will be launched in order to render the JavaScript and HTML on the website.

Basically Flash 2.0.

Re: The browser's main thread is expensive

#158

Post by john01dav »

w29UiIm2Xz wrote: post #126
thataccount wrote: post #97

Earlier quoted context omitted.

>99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps. That is because the latest framework always fixes everything that wasn't broken before.

There is no good technical solution for rendering on the server and upgrading to an interactive experience on the client.

If you can tolerate the (fairly minor) SEO consequences, just render on the client exclusively and fetch data via http calls. I've made small but quite interactive websites with entirely static Svelte + some router (routify/sveltekit/etc.) SPA that just uses http calls for whatever the server needs to be involved in. It's not the right choice for everything, but for some things it works excellently. With a relatively lightweight frontend like Svelte, as well as splitting the SPA into multiple bundles (so it's in some ways not an SPA anymore) makes it perfectly usably snappy even over 200+ms latency, and very fast over a normal connection.

Re: The browser's main thread is expensive

#159

Post by cryptonym »

doix wrote: post #86
cryptonym wrote: post #58

Earlier quoted context omitted.

It is a problem and plays a role, then the rest of the SPA interactions are as bad. Amplified by 100+ third party scripts. Stop building SPA, go back to HTML. Re-assess every third party. For extra performance and scaling, implement cache. Relax and see web experience healing.

There's definitely trade-offs. I actually prefer a proper SPA to pure HTML when on a slow connection and interacting with a site a lot. Especially when trying to buy something. I much prefer to have a longer initial load and then have everything just work instead of waiting as I navigate between pages, the multi stage checkout, confirmation etc. But yeah, if I'm just trying read a single article on a blog, preloading…

You typically still have to wait for API calls between interactions, but error handling and number of requests (linked to experience on slow connection) tend to be worse.

If that's a connection-less interaction or something small that stays on the same page, sure it makes sense to keep it in the browser. You don't need to build your whole site as a bloated SPA just for few limited use-cases.

Re: The browser's main thread is expensive

#160

Post by cryptonym »

phoghed wrote: post #111
doix wrote: post #86

Earlier quoted context omitted.

There's definitely trade-offs. I actually prefer a proper SPA to pure HTML when on a slow connection and interacting with a site a lot. Especially when trying to buy something. I much prefer to have a longer initial load and then have everything just work instead of waiting as I navigate between pages, the multi stage checkout, confirmation etc. But yeah, if I'm just trying read a single article on a blog, preloading…

These people definitely have an overly rosy view of the past. The sites that are dog slow shit ux now still would be with server rendered html and jquery spaghetti, just like they were in the past. Ever submit some giant form to get some random error and then lose the entire state of it? Used to be extremely common, even though it shouldn’t have been.

Losing the entire state happens on SPA. Plus a random error not providing any feedback is a typical SPA experience. You can poorly execute on any technology. It's just much easier to do things wrong using this-year-trendy-SPA-framework.

Use the appropriate technology, everything doesn't have to be a SPA.

Post reply on HN