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

https://www.npmjs.com/package/idle-task

by nuko-suke-dev • 4 years ago

94 87 4 years ago

nmcfarl• 4 years ago

What I’d really like to see on this page is more descriptive text. Mainly a description of what’s actually being done by the library. But also a section on when I should use idle-task over Partytown - https://partytown.builder.io/

warpech• 4 years ago

I agree. The README file presents it like an alternative to `requestIdleCallback`, while, in fact, it is a convenience wrapper around `requestIdleCallback`. It is a nice idea, but the description makes it confusing.

nuko-suke-dev6• 4 years ago

The README file presents it like an alternative to `requestIdleCallback`, while, in fact, it is a convenience wrapper around `requestIdleCallback`. It is a nice idea, but the description makes it confusing.

That's right. I changed README to everyone to understand it.

https://github.com/hiroki0525/idle-task#features

nottorp3• 4 years ago

One of the extensions that suspends idle tabs can protect me from this?

toqy• 4 years ago

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.

bombolo5• 4 years ago

When there is nothing happening on my page my cpu can go idle.

nottorp3• 4 years ago

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

SketchySeaBeast3• 4 years ago

A bit of remote browser crypto mining?

travisd• 4 years ago

Lot of people confused here -- the "running JavaScript when the browser is idle" part is a bit misleading.

It doesn't run stuff when you're the tab is backgrounded (browsers already heavily reduce what sites can do when not in focus[1]). Instead, it just lets you delay work until the page isn't doing anything else (such as rendering the page). For example, you might do this when updating a visualization on a page so that the other updates can complete first (e.g., update the input UI and redraw the visualization when that's done).

[1] https://blog.chromium.org/2020/11/tab-throttling-and-more-pe...

bombolo5• 4 years ago

I have an idea: why not speed up your site by NOT running js at all?

onion2k• 4 years ago

But then my contact form won't work!

ducks

SketchySeaBeast3• 4 years ago

But what if we want a site that's more interactive than a blog?

MichaelCollins2• 4 years ago

Who's 'we'? The user, or the web dev? Most javascript exists to scratch the itch of the webdev who made it, doing shit no user ever asked for.

pvg3• 4 years ago

That's a fine personal choice but don't snarkpoop on other people's Show HN's.

https://news.ycombinator.com/showhn.html

bombolo5• 4 years ago

If other people's choice had no influence on me, I would totally agree with you.

newbieuser2• 4 years ago

you are absolutely right. we should completely throw away the development of browser APIs over the years and develop sites with html 4.0

RunSet• 4 years ago

This but unironically.

togaen• 4 years ago

Totally agree with this, actually.

dahfizz• 4 years ago

The web was a much better place 10 years ago.

sirwhinesalot• 4 years ago

Is... is it bad that I think that might not actually be so bad? I never had an issue with full page reloads of a damn blog, but somehow it's all SPA garbage these days and all the sites have errors in one or more browsers but miraculously keep chugging along (except when they don't and there's a blank page).

At least in the old days if CSS or JS didn't load, you still got a semi-usable page.

Turning HTML+CSS+JS into an application platform has been one of the most fundamentally stupid things we've done as a field and we'll keep paying for it for years on end, second only to not adding slices to C.

wonnage2• 4 years ago

Incoming flood of edgelord comments saying they think that would be better

balls1874• 4 years ago

The docs are confusing.

This is really about how to make your UI more responsive by performing intensive tasks only when your browser isn’t doing any other tasks related to the javascript code.

In non JS applications, you typically would do this on any thread but the UI thread. But with Javascript, you have the option of doing tasks on the main thread, but only when all other tasks are not being executed. IE a priority queue.

qwery• 4 years ago

I actually like having software and hardware that can be idle. I find it quite peculiar that some app/window/page I'm explicitly not interacting with should be doing work because I'm not interacting with it.

madeofpalk• 4 years ago

The idea is that you schedule low priority work to happen with requestIdleCallback (which this is just a wrapper around), so it doesn't impact as much higher-priority tasks like responding to input or animations.

For example, you may schedule periodic API polling (and JSON response parsing) using this API to prioritise user input handling.

I would guess (but not know!) that the browser could de-prioritise these tasks even further when the browser decides to (such as when in the background).

kitsunesoba• 4 years ago

Couldn’t this have negative impact on user battery life depending on the weight of the JS or number of open tabs with sites using it? Seems like it might be antagonistic to host OS efforts to to coalesce work and perform it while the CPU is already awake to reduce the number of wakeups and save power, since it specifically waits for browser idle.

flatiron• 4 years ago

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

Xelynega• 4 years ago

"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.

mfbx9da42• 4 years ago

Or... use a web worker

balls1874• 4 years ago

Webworkers run on their own thread.

The point of this is to run low-priority tasks without impacting the main loop, and without the complexity of separate threads.

mfbx9da42• 4 years ago

If the task is a long running expensive task, it's going to block the main thread from being responsive to user input. If it's a quick task then you don't need to schedule it. I struggle to see the place for a medium length task which is long enough that it needs to be deferred but short enough that it can't be executed immediately.

What would be an example?

chrismorgan• 4 years ago

The code: https://github.com/hiroki0525/idle-task/blob/main/src/index....

Some initial impressions (based on https://github.com/hiroki0525/idle-task/blob/7e88c8b97c926cf...):

• The cancelIdleCallback fallback implementation will never be defined, so cancelAllIdleTasks will unexpectedly throw an exception in environments like Safari that depend on the polyfill. (Solution: delete lines 14–15.)

• That the simple fallback implementation is a modifying polyfill is not nice, if not clearly stated. Typically better to define it as a local, e.g. `const rIC = typeof requestIdleCallback !== "undefined" ? requestIdleCallback : function …` and subsequently use rIC instead of requestIdleCallback. (Related, I’m not sure quite why you only install the polyfill if self is a thing, are you deliberately ensuring you can’t use this in Node?)

• The default code path is broken, process.env.NODE_ENV will fail in normal browser environments since process is undefined. (And no, no build process gets rid of this, fetch the distributed package and see that its index.js still contains it.)

• Line 74, don’t return a value from a private function if none of the uses use that value; just drop the return keyword.

• Lines 86–93, splitting logArgs out doesn’t make sense to me, it’s functionally harmless, but needless bloat. (I am perennially disappointed at the utterly primitive state of JavaScript bundlers/optimisers/minifiers: especially with TypeScript knowledge of the interfaces being touched, reordering and inlining is a trivial and obvious optimisation that only changes behaviour on bonkers code that deserves to get broken, but no tool will do it, though Closure Compiler’s advanced optimisations mode might be able to be coaxed into doing it—if it even supports spread syntax.)

• The vibe I’m getting is that this works with a mixture of callbacks and promises, and ends up complicated because of it, parts of it feeling like the ’90s and parts like the mid-’10s. The modern approach would be to use abort signals, which… eh, they’re simpler in some cases, more complicated in others. But from this library’s perspective, you could replace the entire interface with just one promise-returning function, which I’d name schedule(task, options), with options including {signal: AbortSignal}. Cancellation would be handled a bit differently, but it’d be more flexible, because it’s left up to the caller how they hook cancellation up (want to be able to cancel a subset of all the tasks together? Easy, give them the same signal). And I think the code of this library would be simplified by going all in on such a pattern.

nuko-suke-dev6• 4 years ago

Thank you for your good code review! In most cases, I agree with you. I will improve the code as you said gradually.

simonpure• 4 years ago

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_...

vinibrito• 4 years ago

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

naet• 4 years ago

The 3 biggest browser engines are Gecko, Webkit, and Blink.

Gecko is the engine behind Firefox and is maintained by Mozilla, so it has a good number of open source contributors that help fix issues when they are found. It also has some issues occasionally but since it has only a ~3% usage these days you don't get as many complaints.

Blink is used by Chromium (which includes Edge, Chrome, Opera, Brave, and Samsung browsers). It has the biggest market share and probably the most people actively paid to work on it.

Webkit is currently only used by Safari and maintained by Apple alone. (Also all iOS browsers have to use webkit which is why iOS chrome has a lot of the same bugs as iOS safari etc). Apple has a conservative approach to Webkit and doesn't implement as many new features or standards as quickly as the other engines. It has the biggest non blink engine market share so it's usually the outlier when it comes to support issues.

Before 2013 Chromium was webkit based, but that year they made a fork and took their engine in a new direction so Webkit lost some of its previous maintainers.

CharlesW• 4 years ago

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.

nuko-suke-dev6• 4 years ago

`idle-task` has shim as below .

https://github.com/hiroki0525/idle-task/blob/main/src/index....

References - https://developer.chrome.com/blog/using-requestidlecallback/...

codedokode• 4 years ago

While unrelated to this, I would like browsers to suspend background tabs and maybe even compress their data and unload information that can be restored later (for example, unload images from memory, drop JS bytecode and JIT caches). Majority of websites have no need to do anything when I am not watching them.

Of course there are cases when you need some background activity, for example if you are listening to music or running a program. As I understand, it is extremely difficult do distuinguish between tabs doing useful work and not doing. I would be fine with a manual switch to allow site run in background.

bobbylarrybobby• 4 years ago

I'm pretty sure Safari does this, as returning to a heavy tab (say, google sheets) after a long period of it having been in the background takes a few seconds on my 2015 MacBook Pro. I assume that time is spent deserializing the tab’s state.

btbuildem• 4 years ago

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

Kiro6• 4 years ago

What kind of question is that? Games or applications like Figma obviously require more computing power than a static homepage.

postalrat• 4 years ago

Figma isn't my site.

remram4• 4 years ago

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.

eyelidlessness• 4 years ago

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.

dheera• 4 years ago

Mine bitcoin on users' computers for you when they are idle?

jasonjmcghee2• 4 years ago

It seems like people are reading this like "add this thing to always busy wait so your site goes faster and drains battery" when in reality it's just saying "schedule low priority tasks to happen at next idle"

Kiro6• 4 years ago

This comment thread is a serious mess with all sorts of bad faith takes that have nothing to do with the library. Go read https://developer.mozilla.org/en-US/docs/Web/API/Window/requ... and https://developer.mozilla.org/en-US/docs/Web/API/Background_...

This is not used for malicious CPU hijacking or whatever. It's a way to schedule low-priority JS tasks for later when the main thread is unblocked and give priority to more important things. It's a very useful API for when optimizing games or complex web applications.

butz• 4 years ago

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?

boredumb• 4 years ago

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.

brundolf• 4 years ago

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

Eduard• 4 years ago

The logo made me think it's called "oldle Task"

nuko-suke-dev6• 4 years ago

Certainly.

wonnage2• 4 years ago

This is quite similar to the postTask API currently implemented in Chromium-derived browsers: https://developer.mozilla.org/en-US/docs/Web/API/Scheduler/p...

Of course, none of this works in Safari, where setTimeout is still your only friend.

Cloudef• 4 years ago

There's lots of confusion what this is. Basically browser runs a giant eventloop. Whenever you call async function in javascript, it gets put into a queue, and called by the event loop (usually the next execution). This basically makes it so that the async call gets tagged with metadata that tells the event queue "Don't call me unless you have nothing else to call". So basically it keeps the async call at the end of the queue until it's the final call, and that's when the eventloop will call it. The subject is quite misleading as it is not really about idle.

k__• 4 years ago

Lol, thanks.

This comment was better than the docs, as usual.

nuko-suke-dev6• 4 years ago

Sorry for the confusion.

this is a convenience wrapper around “requestIdleCallback” That's right. I changed README.

https://github.com/hiroki0525/idle-task#features

balls1874• 4 years ago

In defense of the documentation, this is a convenience wrapper around “requestIdleCallback” which from MDN: “queues a function to be called during a browser's idle periods.”

https://developer.mozilla.org/en-US/docs/Web/API/Window/requ...

pastelsky• 4 years ago

On a related note – ‘networkIdleCallback’ : Preload assets and data whenever network is idle —

https://github.com/pastelsky/network-idle-callback

Helpful for progressively hydrating features in a page, or loading assets for next interaction

Etheryte• 4 years ago

This whole thing is about performance, but what I'm not seeing any of is actual measurements. Is this actually useful enough to justify all the overhead of writing code in a catered way? Right now I highly doubt it. Is this beneficial at all? After all you're adding some extra overhead and delays which might or might not be made up for by the fact that things are chopped up. The whole of the work doesn't change, you're simply adding breaks in the middle.

nuko-suke-dev6• 4 years ago

I agree with you. It is difficult to measure how to improve the site performance concretely by using idle-task, but I will do this with my application.

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

Related Stories