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

[Martok]

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.

 

[CMTV]

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.

 

[Max Taxable]

some members have commented that it takes a while to load the smilies & emojis menu.

They're not hallucinating.

 

[Lukas W.]

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.

 

[Chris D]

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.

 

[CMTV]

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...

 

[Lukas W.]

@Lukas W. in such approach mobile users won't be able to use custom forum smilies.

I didn't say remove the dropdown, I said remove the non-custom emojis from the dropdown by not loading them to cut down load time.

 

[xffutureuser]

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):

Add-on - Recently used Smilies always visible when writing a post

I would like to have Recently used Smilies always visible when writing a post. Because when I click on the Smilies icon, the popup window with the smilies is loading too slowly. Something like this: I don't know if there is such add-on or if it is...

xenforo.com

 

[Martok]

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

Add-on - Recently used Smilies always visible when writing a post

I would like to have Recently used Smilies always visible when writing a post. Because when I click on the Smilies icon, the popup window with the smilies is loading too slowly. Something like this: I don't know if there is such add-on or if it is...

xenforo.com

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.

 

[XF Bug Bot]

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.

 

[Chris D]

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:

<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):

<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.

 

[Lukas W.]

Can confirm on Pixel 2. Menu opens up in roughly a second on wireless, and 2 seconds on mobile connection.

 

[Ozzy47]

Much better.

 

[webbouk]

Have you any indications as to when we can expect future XF release (2.1.1). ?

 

[Ozzy47]

Wait,

 

[Ozzy47]

Have you any indications as to when we can expect future XF release (2.1.1). ?

When it's ready™

 

[webbouk]

Is it ready now, can we get it now, are we there yet ?

 

[Chris D]

Can confirm on Pixel 2. Menu opens up in roughly a second on wireless, and 2 seconds on mobile connection.

Much better.

Could you try again just to ensure the issue is still fixed.

(The large emoji images was related to this fix).

 

[Lukas W.]

Looks still good.

 

[Chris D]

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