Readit NewsGoogle's one (of many) heads has no idea what another (of many) heads says or does.
INP is the time between you click/press a key/etc and the moment the next paint happens. It’s only measured for on-page interactions, not for navigations.
It’s basically like http://danluu.com/input-lag/ but as a web metric.
Deno discussion: https://news.ycombinator.com/item?id=36537533
Your move, Google.
AFAIK (correct me if I’m wrong!) first-party and third-party codecs in media players are kinda equal: you load a file, and the media player picks which codec to delegate that file to. You can’t do that in with a Chrome extension – the extensions can manipulate HTML and run custom JS, but that’s more or less it (plus some basic browser-level stuff like work with tabs and intercept network requests).
This doesn’t mean an extension isn’t possible at all – eg there’s https://github.com/zamfofex/jxl-crx/ that detects JXL images and decodes them with JS – but that’s slower.
Plus the bigger issue is adoption. You want all users to get your JPEG XL images, not just the 0.1% of users that installed the extension.
This fall, I was lucky to help Causal (a web spreadsheet for forecasting) with speeding up their frontend app. Here are some of my favorite findings:
- Turns out when React DevTools tell you “the component rerenderd because hook no. 2 changed”, it doesn’t mean that it’s hook no. 2 that actually changed! That’s because a) `useContext` hooks aren’t counted, b) only native hooks are counted – so if you use one `useSelector`, but it has 8 native hooks inside, you’ll see something like “hook no. 7 changed”. You need to go to the Components pane and look for hook numbers there.
- Web workers are cool but hard to make use of :/ In this case, we tried moving an operation into a web worker but weren’t able to because copying data between threads took longer than the actual op. And one doc I’ve read earlier still fascinates me – in 2018, Google explored moving frameworks into web workers but stumbled upon many limitations [1].
- React (unfortunately) still causes a lot of performance issues. It’s too easy to rerender something unnecessarily; and in a large app, many cheap components easily add up into an expensive render. I’m looking forward to React Forget [2], hopefully, solving this (at least partially?)
[1] https://docs.google.com/document/d/1nu0EcVNC3jtmUVWL8Gs5eCj2... [2] https://reactjs.org/blog/2022/06/15/react-labs-what-we-have-...
It also seems to be a metric that is very easily gamed.
If all that matters is instant feedback, then just draw that loader as soon as user clicks add to cart, do not wait for the request to start. It does not matter that it will take X or Y seconds.
Fun fact: the current JS-specific metric (which is being fazed out) is First Input Delay, and it was explicitly designed to avoid this gaming:
> FID only measures the "delay" in event processing. It does not measure the event processing time itself nor the time it takes the browser to update the UI after running event handlers. While this time does affect the user experience, including it as part of FID would incentivize developers to respond to events asynchronously—which would improve the metric but likely make the experience worse. > - https://web.dev/fid/
I wonder why they decided to reconsider this trade-off when designing INP.