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

Show HN: Speed up your site by running JavaScript when the browser is idle

npmjs.com

Post reply on HN
Print view View original

41–50 of 95 posts

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#41

Post by Kiro »

Xelynega wrote: post #26
flatiron wrote: post #14

Earlier quoted context omitted.

This is for site performance and not for general OS performance.

"Does your computer run out of battery 10x faster while on the site" should be a site performance issue if it's something in the sites js thats eating the battery.

You use this for things you would run anyway, so the total computation time will be the same, but now you will control the execution order and can for example let the main thread handle things that impact the user experience before lesser tasks.

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#42

Post by ovao »

nottorp wrote: post #9
toqy wrote: post #4

Earlier quoted context omitted.

requestIdleCallback isn’t something that you need to protect yourself from. It just executes a function when there’s nothing else happening on your page essentially.

You mean my browser still doesn't use enough CPU? I don't want sites that aren't in focus to do anything.

The requestIdleCallback API isn’t specific to inactive tabs, and trying to use it to do background work in general is not a Good Idea: the first idle callback is typically going to fire (almost) immediately after painting’s complete, or some handful of milliseconds after.

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#43

Post by butz »

The main issue with 3rd party scripts is that each one wants to be the first to run. And they are usually the ones that take up the most CPU time and bandwidth.

For some scripts "facade" solution might work even better than running them on idle. Consider a "chat plugin", that usually pops up each time you visit. If we'd replace chat script with simple dummy button, that loads actual script when user really needs to talk to website support - visitor wins as they are not bothered by popups and site loads faster.

Any ideas how to apply this idea for more 3rd party scripts, especially tracking ones?

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#44

Post by boredumb »

You may want to market this as something closer to a 'defer until idle' so it insinuates it's an essential task that can be lower in priority of browser execution. At the moment it does feel like I should start developing a monero miner to monetize my website with it.

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#45

Post by brundolf »

This is a neat idea, but it's pretty rare that I find myself with a compute-heavy JS task (slow enough to visibly impact performance) that can be neatly split off into an asynchronous process like this (i.e. isn't just part of my UI framework's main rendering process). And the couple times where that has happened, I preferred to spin up a background worker and get true parallelism. The message passing comes with some overhead, but that got swallowed by the fact that it was a heavy task

This looks well-designed and I'm sure somebody has a usecase for it, but I'm not sure I've ever had one

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#46

Post by remram »

Kiro wrote: post #40
remram wrote: post #39

Earlier quoted context omitted.

Do they? To do what when the computer is idle ? Those are interactive applications, there's not that much work for them to do when you're not interacting with them.

It's not about the computer being idle. It's about waiting for the main thread to be unblocked before doing stuff you would want to do anyway, but now you can schedule it for later to give priority to more urgent tasks. A very common optimization technique in all sorts of software and I don't see why it wouldn't be valid for a web application. Go read https://developer.mozilla.org/en-US/docs/Web/API/Background_... fo…

You still haven't answered the question. Your link has no example of use cases, though it has warnings about what not to do.

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#47

Post by vinibrito »

simonpure wrote: post #25

As other comments have pointed out, this behavior is enabled by `requestIdleCallback`. MDN has a good example and looks like this is not supported by Safari - https://developer.mozilla.org/en-US/docs/Web/API/Background_...

It's always Safari. I never figured out why.

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#49

Post by CharlesW »

simonpure wrote: post #25

As other comments have pointed out, this behavior is enabled by `requestIdleCallback`. MDN has a good example and looks like this is not supported by Safari - https://developer.mozilla.org/en-US/docs/Web/API/Background_...

> MDN has a good example and looks like this is not supported by Safari

It's currently an experimental feature that can be enabled, so hopefully Apple will enable it by default in 2023.

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#50

Post by eyelidlessness »

btbuildem wrote: post #32

What's the use case? What is "your site" doing that it would need all this computing power?

It allows you to temporarily unblock the main thread/renderer before performing a potentially expensive computation. I’ve used this technique (with plain requestIdleCallback) to display incremental UI feedback as a chain of computations progresses. This is in an application I inherited/maintain, with some existing performance problems. I intend to make more substantive performance improvements, but this stopgap measure significantly improves perceived performance, eg by immediately showing the effect of a direct interaction such as a checkbox state change even if the triggered computations may take ~500ms.

The downside is it potentially introduces “jank”, where incremental changes render temporarily, and computation time is somewhat slower overall. In my experience/opinion, the tradeoff is worth it around 100-200ms depending on what’s being unblocked.

Post reply on HN