12 ms·
Show HN: Speed up your site by running JavaScript when the browser is idle
- nmcfarl 4y agoWhat 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/ https://partytown.builder.io/
- warpech 4y agoI 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-dev 4y 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 https://github.com/hiroki0525/idle-task#features
- nottorp 4y agoOne of the extensions that suspends idle tabs can protect me from this?
- toqy 4y agorequestIdleCallback 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.
- bombolo 4y agoWhen there is nothing happening on my page my cpu can go idle.
- nottorp 4y agoYou mean my browser still doesn't use enough CPU? I don't want sites that aren't in focus to do anything.
- matsemann 4y agoThe point is to play nice. "I have this task the page needs to do, but I can wait a bit until more convenient". Not "browser is idle, let's mine some bitcoin" as you suggest.
- nottorp 4y agoActually I wasn't thinking of bitcoin, but for example of needless auto refreshes and animations. Seriously, web devs need to learn to respect my battery and electricity bill more.
- Kiro 4y agoThis does not do what you think it does. You're tilting at windmills. It's not about doing stuff in a tab that isn't in focus. "Idle" refers to the main thread idling in the page you're currently using, so it's about controlling the execution order and priority of JS tasks. E.g. on Google Maps you give priority to rendering the visible map tiles while deferring preloading the surrounding non-visible tiles until the main thread is unblocked (and thus idling).
- neweroldguy 4y agoThis is just a generic “old man shouting at clouds” complaint at this point. You’re not engaging with the material at all.
- ovao 4y agoThe 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.
- travisd 4y agoLot 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-performance.html https://blog.chromium.org/2020/11/tab-throttling-and-more-pe...
- bombolo 4y agoI have an idea: why not speed up your site by NOT running js at all?
- onion2k 4y agoBut then my contact form won't work! ducks
- deleted 4y ago[deleted]
- SketchySeaBeast 4y agoBut what if we want a site that's more interactive than a blog?
- MichaelCollins 4y agoWho'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.
- SketchySeaBeast 4y agoWell, people who don't want to keep refreshing the page to see the site update. That's not just "[scratching] the itch of the webdev who made it".
- pvg 4y agoThat's a fine personal choice but don't snarkpoop on other people's Show HN's. https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html
- bombolo 4y agoIf other people's choice had no influence on me, I would totally agree with you.
- qwery 4y agoI 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.
- deleted 4y ago[deleted]
- madeofpalk 4y agoThe 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).
- deleted 4y ago[deleted]
- kitsunesoba 4y agoCouldn’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 4y agoThis is for site performance and not for general OS performance.
- Xelynega 4y 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.
- Kiro 4y agoYou 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.
- mfbx9da4 4y agoOr... use a web worker
- balls187 4y agoWebworkers 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.
- mfbx9da4 4y agoIf 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?
- balls187 4y agoSending telemetry data. It’s low priority, and perhaps it’s quick, but there is no reason it can’t when idle.
- chrismorgan 4y agoThe code: https://github.com/hiroki0525/idle-task/blob/main/src/index.ts https://github.com/hiroki0525/idle-task/blob/main/src/index.... Some initial impressions (based on https://github.com/hiroki0525/idle-task/blob/7e88c8b97c926cf39db3e8b4e8169e6c70965548/src/index.ts 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.
- 4y ago
- simonpure 4y agoAs 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_Tasks_API https://developer.mozilla.org/en-US/docs/Web/API/Background_...
- vinibrito 4y agoIt's always Safari. I never figured out why.
- naet 4y agoThe 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.
- robocat 4y agoGoogle could let Chrome rot: Microsoft let Internet Explorer rot back in the days before Edge (primarily because Microsoft recognised that browsers would compete with their Windows monopoly: which is exactly what happened).
- uncletammy 4y ago> Apple has a conservative approach to Webkit and doesn't implement as many new features or standards as quickly as the other engines This is far too generous. They intentionally withold features in an effort to push people towards their app store.
- codedokode 4y agoWhile 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 4y agoI'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 4y agoWhat's the use case? What is "your site" doing that it would need all this computing power?
- Kiro 4y agoWhat kind of question is that? Games or applications like Figma obviously require more computing power than a static homepage.
- postalrat 4y agoFigma isn't my site.
- remram 4y agoDo 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.
- Kiro 4y agoIt'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_Tasks_API https://developer.mozilla.org/en-US/docs/Web/API/Background_... for a better explanation.
- remram 4y agoYou still haven't answered the question. Your link has no example of use cases, though it has warnings about what not to do.
- collaborative 4y agoCan't reply above. So it's "low-priority" async?
- jasonjmcghee 4y agoIt 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"
- Kiro 4y agoThis 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/requestIdleCallback https://developer.mozilla.org/en-US/docs/Web/API/Window/requ... and https://developer.mozilla.org/en-US/docs/Web/API/Background_Tasks_API 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 4y agoThe 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 4y agoYou 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 4y agoThis 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 4y agoThe logo made me think it's called "oldle Task"
- nuko-suke-dev 4y agoCertainly.
- deleted 4y ago[deleted]
- wonnage 4y agoThis is quite similar to the postTask API currently implemented in Chromium-derived browsers: https://developer.mozilla.org/en-US/docs/Web/API/Scheduler/postTask 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 4y agoThere'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__ 4y agoLol, thanks. This comment was better than the docs, as usual.
- nuko-suke-dev 4y agoSorry for the confusion. >this is a convenience wrapper around “requestIdleCallback” That's right. I changed README. https://github.com/hiroki0525/idle-task#features https://github.com/hiroki0525/idle-task#features
- balls187 4y agoIn 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/requestIdleCallback https://developer.mozilla.org/en-US/docs/Web/API/Window/requ...
- pastelsky 4y agoOn a related note – ‘networkIdleCallback’ : Preload assets and data whenever network is idle — https://github.com/pastelsky/network-idle-callback https://github.com/pastelsky/network-idle-callback Helpful for progressively hydrating features in a page, or loading assets for next interaction
- deleted 4y ago[deleted]
- Etheryte 4y agoThis 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-dev 4y agoI 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.