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

111–120 of 167 posts

Re: The browser's main thread is expensive

#111

Post by phoghed »

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…

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.

Re: The browser's main thread is expensive

#112

Post by StilesCrisis »

pjmlp wrote: post #91
StilesCrisis wrote: post #72

Earlier quoted context omitted.

https://playcanv.as/p/MflWvdTW/ This isn't new at all, just one of the first things I found by googling "webgl demo." WebGPU of course goes even further. I think the real gap is just that people by-and-large aren't building real games on top of Safari. It's more lucrative to use the app store with its low-friction payment system.

At the same level, as a commercial game, not a tech demo scene.

There are business-level issues with web based AAA games, as I was alluding to before. Apple has a two-click payment system. If you failed a Candy Crush level and you needed to get up from the couch and get your credit card out of your wallet to buy more turns, no one would ever do it.

Re: The browser's main thread is expensive

#113

Post by martinald »

pverheggen wrote: post #104
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…

The article acknowledges this in the very first paragraph: > For most of us it’s things like reducing network requests, shrinking the bundle, or making good use of the cache. These are likely going to be your first port of call for performance issues at your day job, but fixes like removing dependencies or making fewer network calls are pretty straightforward. I think the author chose to do a deep dive on the topic o…

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 brand consistency. But it's many MBs of JS, because it has to cover every possible use case.

This doesn't even get into 3rd party vendors who _also_ ship react et al and have other bundles.

I'm not saying the article is wrong, but if you want to free main thread time especially at the most critical point (when the user has initially loaded the page) you _probably_ will find that most of the opp is in bundle size and hydration improvements.

Re: The browser's main thread is expensive

#114

Post by kccqzy »

Here is a problem that I had thought about in my last frontend project: the project needed to parse a user-provided string to provide syntax highlighting. The implementation was to parse the string immediately after a user keystroke so the user always sees correct colors. But I had this nagging thought that if I had designed the grammar wrong some parses might take more than linear time and would hold the main thread during the parse. But I didn’t really want to first render a black string, parse on a service worker and then rerender with color. The effect must have seemed disorienting.

Anyways I stopped the project for unrelated reasons and this thought kept nagging me in the back of my mind. The time I work on the project I’ll be sure to try some techniques in the article.

Re: The browser's main thread is expensive

#115

Post by bot403 »

martinald wrote: post #113
pverheggen wrote: post #104

Earlier quoted context omitted.

The article acknowledges this in the very first paragraph: > For most of us it’s things like reducing network requests, shrinking the bundle, or making good use of the cache. These are likely going to be your first port of call for performance issues at your day job, but fixes like removing dependencies or making fewer network calls are pretty straightforward. I think the author chose to do a deep dive on the topic o…

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…

I would think, or hope, a UI library like that could benefit from webpack and tree shaking such that only the needed components end up in the final bundle.

Re: The browser's main thread is expensive

#116

Post by [deleted] »

odo1242 wrote: post #103
amelius wrote: post #60

Earlier quoted context omitted.

Since at least Windows 3.1 we all know that cooperative multitasking is a bad idea. But we see a lot of developers use it, even Rust developers who should know better.

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

[deleted]

Re: The browser's main thread is expensive

#117

Post by jjk166 »

bgirard wrote: post #107
nerdralph wrote: post #81

I agree with most of the article, but would clarify the following: > For the screen to look smooth, frames have to be drawn at the display’s refresh rate. On the most common 60Hz display, that means 60 frames per second, or about 16.6 milliseconds per frame. It isn't absolutely necessary to match the display refresh rate. With a 144Hz monitor, 72FPS is going to look smooth for the vast majority of the people, and eve…

It's a good nitpick. A hypothetical 1000Hz display will still look smooth to the human eye at 60/120Hz. A 1Hz display will never look smooth. But it's more about honoring the user's preference. I personally would rather 60Hz, then 120Hz heating up my room unnecessarily. If someone has a display set to 1000Hz for whatever reason, then you should try your best to honor that.

A user's hardware represents the worst case scenario they want to be able to handle, not their preferred nominal settings. Most people aren't changing their screen refresh rate when they switch between playing a game and reading wikipedia.

Re: The browser's main thread is expensive

#118

Post by kevin_thibedeau »

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…

NoScript is a remedy for this. When a site is broken I whitelist a few domains likely to be necessary. After a few attempts I bounce. If I see a dozen plus domains I don't even bother. This cuts down on the volume of garbage sites I waste time on and shields me from novel trackers not on any block list.

The web is much faster when useless JS is taken away.

Re: The browser's main thread is expensive

#119

Post by Me1000 »

nerdralph wrote: post #81

I agree with most of the article, but would clarify the following: > For the screen to look smooth, frames have to be drawn at the display’s refresh rate. On the most common 60Hz display, that means 60 frames per second, or about 16.6 milliseconds per frame. It isn't absolutely necessary to match the display refresh rate. With a 144Hz monitor, 72FPS is going to look smooth for the vast majority of the people, and eve…

Below a certain threshold things are certainly going to look janky. But you’re right you don’t have to match the screens native refresh rate. More important is that you have a consistent frame rate. If you can’t hit 120hz, it’s better to target 60hz, rather than 120 a miss your frame budget. 30fps will also look better than 60 but regularly dropping frames.

Re: The browser's main thread is expensive

#120

Post by [deleted] »

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…

[deleted]
Post reply on HN