Post AllzKCUhX9JSj4urz6 by nolan@toot.cafe
 (DIR) More posts by nolan@toot.cafe
 (DIR) Post #AllzKBfIcGCE9erorg by nolan@toot.cafe
       2024-09-07T21:37:20Z
       
       1 likes, 1 repeats
       
       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: https://web.dev/articles/content-visibility~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. https://github.com/nolanlawson/emoji-picker-element/pull/445
       
 (DIR) Post #AllzKCUhX9JSj4urz6 by nolan@toot.cafe
       2024-09-07T21:41:17Z
       
       1 likes, 0 repeats
       
       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/449A bit of extra code, but still not as gnarly as a full virtual list!
       
 (DIR) Post #AllzKDYHbJlw0TbFCq by nolan@toot.cafe
       2024-09-07T21:43:46Z
       
       0 likes, 0 repeats
       
       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 interesting 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.