|
Top-level
Working on an additional PR now that adds a _bit_ more complexity but gains a ~15% perf boost in Chrome and ~36% in Firefox. It relies on detecting when the `content-visibility: auto` state changes and using the old `<img data-src>` trick to set the `src` in that case. https://github.com/nolanlawson/emoji-picker-element/pull/449 A bit of extra code, but still not as gnarly as a full virtual list! 7 comments
@nolan I wonder if removing `loading=lazy` after landing https://github.com/nolanlawson/emoji-picker-element/pull/449 might yield a bit more performance: loading images eagerly could save the browser from doing the bookkeeping and querying to know if it should load now or later. If it does, you might want to replace `contentvisibilityautostatechange` with a real `IntersectionObserver` to avoid regressing on browsers without that event. @anthony That's interesting; I'll toy around with that! What prompted this was noticing a huge amount of time Chromium is spending in "ResourceFetcher::requestResource" (visible if you turn on "show all events"). I had a hunch that this was related to the `<img>`s, so I removed the `src` and suddenly all the costs went away. I'll need to dig to see if it's `loading=lazy`-related… As for IntersectionObserver, yes, I messed around with that too. It's definitely the better cross-browser choice. @anthony Hm, `loading=lazy` doesn't affect those `ResourceFetcher` costs… Still might make sense to get rid of, though, if I'm effectively doing my own lazy-loading. @nolan if only the push for native virtualization a number of years back hadn’t stopped at _just_ ‘content-visibility’. Don’t get me wrong, it’s a great API that I use a lot, even in much simpler contexts (though not with these fancy events, TIL), but the project had so much more it was attempting to achieve. Alas. @westbrook Yeah I seem to recall there was a whole "built-ins" proposal that had some various JavaScript utilities like a virtual list and an async LocalStorage. Would be nice to revive… Bonus! I randomly discovered that Chrome's implementation of the "contentvisibilityautostatechange" event (boy, that's a mouthful) differs from Firefox's and WebKit's. Bug filed: https://issues.chromium.org/issues/365168180 |
Gregory's Server
Of course there's no way that rendering 40k DOM nodes (even with all these optimizations) will be as performant as a real virtual list, but… I'm interested to see how far I can take this with just some simple browser APIs.
With emoji-picker-element I really wanted to strike the balance between perf and simplicity, keeping bundle size low and not going overboard with complex optimizations.