4
Emoji Picker Performance and UX
(hexbear.net)
submitted
1 month ago* (last edited 1 month ago)
by
LeninWeave@hexbear.net
to
c/technology@hexbear.net
cross-posted from: https://hexbear.net/post/6598439
Cross-posting my own post from /c/feedback to /c/technology, because it seems like the feedback comm is bugged.
There has been discussion recently about the performance of the emoji picker. I wanted to make a follow-up thread.
To establish context, there are two emoji pickers.
- The one that appears when you type ":" followed by a string to filter the results. I will refer to this as the "inline" picker.
- The one that appears when you click the "Emoji" button above the text entry area for a comment/post. I will refer to this as the "popup" picker.
Many people have had performance issues with these pickers. Some have proposed reducing the number of emoji, which I am personally strictly opposed to. I think the emoji are a crucial part of this website, including the very rarely used ones. It seems much better to first pursue technical solutions to this problem.
- Lazy loading of the images, meaning that only the images matching your search string will be loaded rather than all the images at once.
- @makotech222@hexbear.net implemented this, which works well. However, it seems to work only for the inline picker and not the popup.
- Could this be implemented for the popup? I assume the popup uses a 3rd party library, which may complicate this.
- This should theoretically allow a functionally unlimited number of emoji.
- Some of the images (as @WhyEssEff@hexbear.net pointed out) are oversized.
- Perhaps these could be bulk resized. This was discussed in the previous thread.
- I would like to also propose very low resolution versions (32x32 or similar) be created to act as thumbnails for the popup picker, if possible. This may not be worth the effort, or do more harm than good.
I have also noticed other problems with the pickers.
- The popup picker and inline picker seem to use different filtering algorithms, which do not provide the same list of emoji for the same input. I personally find the popup picker to work better.
- The popup picker seems to insert emoji at the end of the comment/post text with a space before and after.
- This means having to remove one or more spaces when combining emoji.
- This also means having to cut and paste the inserted text if the desired location was not the end of the post/comment.
- I propose that it would be better for the emoji text to be inserted at the location of the typing cursor, without spaces before and after. This is only for the popup picker, it makes sense for the inline picker to insert a space after because it functions as autocomplete.
Disclaimer: I am not a web dev I am not a web dev I am not a web dev. Nothing I say should be taken as anything more than slightly educated conjecture.
I have a quibble with point 2, everything else looks like a good summary: I have not yet been convinced that image sizes are the bottleneck. My experience with optimizing code to run faster was that we needed to use some profiler built into the IDE, run a test, and it gave a trace of every function and how long it took to run or how many resources it took to run. This was something in C++ 4 years ago with a senior developer to hold my hand. I have no idea how we'd test this for Hexbear. But I think it would be prudent of us to identify what the actual performance bottleneck is before making fixes, or we may mess something up with no benefit (e.g. resizing all the emojis only to find out that the sizes make no discernible difference).
Please see this comment and its children: https://hexbear.net/comment/6632467
Edie mentions that "Loading is slowed down by each emoji being its own HTTP call"
Redwizard mentions that there are 2700+ emoji and at full resolution they add up to about 2GB, and that a lot of gifs could be converted to animated pngs to reduce their size.
From these comments it's not at all clear to me if the issue is # of emojis, size of emojis, both, or neither (neither, because it's possible there's something else at play here.)
OH FUCKING GREAT I DIDN'T TEST THOROUGHLY ENOUGH BEFORE I MADE MY POST.
Inline picker: Lazy loading change made it work great, popup picker still abysmally slow.
Private browsing window where my extensions are disabled: Popup picker still slow but way way way faster than before. It's got to be one of my extensions causing the problem on my end. I'll test more tomorrow to isolate which one.
Culprit Found: I had a Malwarebytes extension that was slowing down the emote loading. Removed it and it's markedly faster now.
NoScript on: emotes load quickly
uBlock Origin on: emotes load quickly, both inline and popup
I don't think that they are, but there are outlier emoji (as WhyEssEff pointed out, older ones) which are larger than normal and should be resized for consistency even if the benefit to average performance is not very large.
I think that the core issue is how they are loaded. With lazy loading implemented in both pickers, I don't see a reason we could not have a functionally unlimited number of emoji. In the popup picker, I never have more than a few dozen emoji once I have entered my search string - the list doesn't even overflow the size of the popup.