As designed Emoji menu rendering phases

[Lukas W.]

Affected version

2.1

Opening the emoji menu on a mobile device results in a number of rendering phases, all in all taking sometimes several seconds to load, where first the pop-up will load, then the HTML structure inside of it, then the native emoji font and then the custom emoji font. All in all this seems a bit disruptive and especially the change in style when the second emoji font overwrites the native one is quite confusing when already scrolling. I wonder if this could be improved?

 

[Mike]

This is more or less necessary to deal with lazy loading the emoji images, otherwise you're talking about loading thousands of images as soon as the popup loads (which would cause reflows anyway).

We will only convert emojis to the image version on scroll (using an intersection observer if available, for efficiency -- as is increasingly the case, this doesn't include iOS/Safari; without that, we fallback to a less efficient detection method) which is why you're seeing the replacement.

There may be some minor improvements that can be made to this overall, but I think this type of approach is roughly necessary, particularly as we support multiple emoji styles.

 

[Mike]

I'm going to call this "as designed", though we have made more improvements (particularly for browsers that don't support intersection observers). The general approach won't be changing though so we limit the amount of HTTP requests to roughly what is visible.