Fixed Slow loading of smilies & emojis menu - needs to be faster

Martok

Well-known member
Affected version
2.1.0
I know there's been some discussion of this elsewhere but I thought I'd post it as a bug as I don't think this is how the devs would intend this to work. If it's a 'feature' then maybe it could be moved to Suggestions.

Now that I've finally moved to XenForo 2.1.0 (from XenForo 1.5.23) some members have commented that it takes a while to load the smilies & emojis menu. I hadn't noticed an issue until I test on my mobile devices and they are indeed slow. Subsequently I have tested this on here with various devices to rule out any issues with my site.

The test on each device (repeated several times for consistency) involved the visiting a thread, clicking in the text editor and then pressing/clicking on the smilies button. The results I got are:

MacBook Pro (latest MacOs and Chrome)
Initial load time: < 2 secs
Subsequent load time: < 1 sec (near instantaneous)

Samsung Galaxy S7 (Android 8 and latest Chrome)
Initial load time: ~ 9 secs
Subsequent load time: ~ 9 secs (plus when loading this time, the menu seems to half appear and be partially transparent with the smilies/emojis the same until they load in fully

Xperia Z3 Compact Tablet (Android 6 and latest Chrome)
Initial load time: ~ 30 secs
Subsequent load time: ~ 7 secs

Whilst the desktop results are acceptable, the results on the mobile devices are very slow. Whilst these aren't the latest devices on the market, they aren't crippled budget devices.

Clearly it would be desirable for the smilies/emojis menu to load a lot quicker on mobile devices.
 
Yes I can confirm it is very uncomfortable to wait 2-3 seconds (first click) and 1 second (further clicks) when you simply want to add a smilie.

I think the smilie images should load asynchronously with preloaded array of their names (array of strings) so search system would work while images still loading.
 
Last edited:
I think the smilie images should load asynchronously with preloaded array of their names (array of strings) so search system would work while images still loading.
Yeah, that’s the kicker - we already do this.

Believe me, we are well aware of the potential impact of adding a feature that suddenly starts loading 3000+ images on demand. There’s no way we’d do that.

So there is very much so a “lazy load” system involved here. And that can be thanked for the reasonable experience on desktop/laptops... oh and iOS mobile devices btw.

So despite our best efforts, there is still something which seems to disagree with (some? All?) Android devices.

Realistically this is either something to do with the overall DOM tree being fairly huge (even though it isn’t performing any HTTP requests) or some overhead in Android when it comes to displaying native emoji (they are displayed as a placeholder until the EmojiOne image is requested).

Needless to say it’s something we’re aware of based on discussions elsewhere but thank you for opening the bug report.
 
Believe me, we are well aware of the potential impact of adding a feature that suddenly starts loading 3000+ images on demand.
I understand that async loading 3000+ images is not cool. Maybe use a Job's approach here: load 30 batches with 100 smilies in each, immediately showing loaded blocks. Load a batch and display then load next batch -> dislpay and so on... As far as I undestand, Twitter does something like that.

No way I am telling how you should do. Just ideas that come in my head...
 
it takes a while to load the smilies & emojis menu.
And that is way I have to pay someone to create an add-on with preloaded Recently used Smilies here (my solution for this):

 
And that is way I have to pay someone to create an add-on with preloaded Recently used Smilies here (my solution for this):

Or for the time being you can do this instead:

As basically all phones have their own emoji keyboard, it may be worth to consider cutting down the menu to just the custom emoji on mobile.
I've now disabled the emoji appearing in there, leaving just the custom smilies. It's now a lot quicker. I've also given my users instructionson how to still add emojis from desktop and mobile devices.
 
Thank you for reporting this issue. It has now been resolved and we are aiming to include it in a future XF release (2.1.1).

Change log:
Improve performance of loading the editor emoji menu on Android devices.
Any changes made as a result of this issue being resolved may not be rolled out here until later.
 
Ok, this is fairly silly. We've tracked this down to some super weird behaviour in Android.

I think I explained before, but we obviously do not attempt to load every single emoji image from EmojiOne when the emoji menu is loaded. Instead, we render this:
HTML:
<span class="smilie smilie--emoji smilie--lazyLoad" data-alt="🙂" title="Slightly smiling face" data-src="path/to/emojione/image.png" data-shortname=":slight_smile:">🙂</span>
This is just some basic HTML with the native emoji character in place (i.e. the emoji is the standard device emoji, rather than a web-hosted image).

After the emoji menu loads, once these spans are visible in the viewport (so only about 30-40 at a time) we convert them to an image, pointing to EmojiOne.

If we remove that lazy loading stuff, and just load the spans with no additional magic, Android still takes a huge amount of time to load the menu.

For some reason, on Android, there is some major overhead in displaying their native emoji images 🙂.

If we change the HTML to this (which we have done):
HTML:
<span class="smilie smilie--emoji smilie--lazyLoad" title="Slightly smiling face" data-src="path/to/emojione/image.png" data-shortname=":slight_smile:"></span>
Then the emoji menu loads much quicker.

If you want to give it a try here, those changes have been rolled out and you should see an improvement.
 
1f44d.png
Much better.
 
So another weird thing about this is that the native Android emoji character in the alt attribute of the span doesn't cause a slow down. It's only if it's rendered in a text node that it causes the slow down 🤔 🧐
 
Top Bottom