Improving Emoji/Award UX & Performance
I know emojis are not a huge priority for GitLab right now, but my wifi connection was a little slower than normal today, and one of the first things that started to bother me were performance issues I experienced using emojis. So I did a little digging to make sense of it.
There are several open issues related to this, but I thought it would be useful to ask if we should be considering UX and performance issues as one.
- Too many 'Award Emoji'
- Emoji dropdown should have less choices
- Create a static file for emoji autocomplete
The request we make for emoji returns an html file that is .5 MB. The html file isn't static -- we generate it here on each request, as far as I can tell. That seems pretty inefficient. (There an open issue for this linked above)
In addition to the .5MB html file, the user must also download a 1MB sprite to use a single emoji. From a UX perspective, it seems like not a great idea to require users to load such large files on every page. When you're on a slow network or you're paying for data, an extra 1.5 MB per page makes a difference.
We do make the request asynchronously, but since we load it only when the user asks for it, there can be pretty long delay the first time you want to use an emoji. For example, on "Good" connection (1.5 Mb/s) just downloading the HTML file takes 2.92s and the sprite takes 5.92s. On a "Regular" (4Mb/s) connection, those wait times are about half as long. This is especially annoying if you only use a few common emojis. For example, if you have to wait a few seconds every time you want to give a
The rendering performance isn't great. On a "Regular" connection, I count roughly 80 style recalculations, repaints, and composites, and half as many layouts being triggered during a 5 second period. Frames/second stays around 10-15 (ideally should be 60).
Maybe this is redundant, but the user doesn't need anywhere near that many emojis for the amount they get. I'd imagine in most cases it's just 1, and probably 1 they use all the time.
- We could render
👍 👎and a few other commonly used emojis on pageload, and let the user click a "Load more" button if they want more.
- Provide far fewer emojis in general. Does anyone have insight into how the current set of emojis was chosen?
- Let users opt between "Basic emojis" or "All emojis" in their personal settings
- Let orgs/groups opt between "Basic emojis" or "All emojis" in case of network concerns
- Serve a static emoji file
What do others think? Am I making too much of this? Are there other ways to address these issues?
(they weren't fitting well into my numbered list
The sprite takes almost 6s to load: