Email or username:

Password:

Forgot your password?
Nolan's posts Post Back to profile
Nolan Lawson

Got a bug report on emoji-picker-element that it's super slow if you have ~20k custom emoji (some fediverse instances… 😵‍💫). I was about to write some complex virtualization logic until I remembered that `content-visibility` exists: web.dev/articles/content-visib

~15% perf boost in Chrome, ~5% in Firefox, Safari has it in Tech Preview I guess. And no accessibility pitfalls or complicated code to maintain. Not as good as virtualization, but amazing what a few lines of CSS can do. github.com/nolanlawson/emoji-p

7 September at 21:37 | Open on toot.cafe
8 comments
Nolan Lawson

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. github.com/nolanlawson/emoji-p

A bit of extra code, but still not as gnarly as a full virtual list!

7 September at 21:41 | Open on toot.cafe
Nolan Lawson

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.

7 September at 21:43 | Open on toot.cafe
Anthony

@nolan I wonder if removing `loading=lazy` after landing github.com/nolanlawson/emoji-p 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.

7 September at 21:56 | Open on indieweb.social
Nolan Lawson

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

Screenshot of Chrome DevTools profiler with a big gray block saying ResourceFetcher::requestResource
7 September at 23:46 | Open on toot.cafe
Nolan Lawson

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

7 September at 23:56 | Open on toot.cafe
westbrook

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

#proposalsOfDaysPast

7 September at 22:00 | Open on mastodon.social
Nolan Lawson

@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…

7 September at 23:57 | Open on toot.cafe
Nolan Lawson

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: issues.chromium.org/issues/365

8 September at 1:49 | Open on toot.cafe
Go Up