The emoji picker is incredibly slow for me when it comes to previews. Can I cache all the emojis so it becomes useable?
deleted by creator
Cache the codes or keywords in your brain
spoiler
That’s not helpful, but it’s what I do
I too would dearly love a solution to this
I think scrolling the emoji picker so they all load helps
That takes ages for me ): they load super slowly for some reason
honestly I think there were a lot of issues around caching and cache-busting early on in the site to the point where we don’t do it any more because then after an outage or planned upgrade people’s browsers would have cached broken emojis every time and there was much consternation. This should be a surmountable problem, but if devs and power users aren’t using the emoji picker much or are using it on desktops with fast connections…
I don’t know of a workaround really that’s client side but I’ll look for one. Firefox mobile? (I’m guessing with any other browser you’re SOL due to no extensions)
Edit: honestly not sure why this doesn’t work, the images seem to come back with this header which should cache them for a week
cache-control: public, max-age=604800, immutable
maybe we have so many browsers are refusing to cache them all
2dit: also worth checking if you’ve configured it to clear cache every time you restart the browser or something, I’ve been known to do that kind of thing and forget
Somewhat related, I’ve always thought that we should be compressing these, not to reduce file size, but because it would cut literal thousands of requests. Can someone with web front end experience weigh in and mention if this is reasonable?
There’s probably too many to serve the entire thing as a single compressed file every time, but I wonder if something like sprites could work (I know that’s what reddit would do for custom icons in subreddits). I don’t know how best they could be divided up–every n emotes, grouping emotes of similar palettes to maximize compression efficiency, grouping to reach a target maximum size per sprite, etc.
That’s all a bit academic, though, since I just scrolled through the emoji picker and the number one problem became immediately obvious: all images are being served at full size even though they’re displayed as tiny icons with a max width/height of 24 px. The total size of all the requests was something like 100 MB (!!) and once I started scrolling back up my browser had actually unloaded most of the images and had to reload them from the disk cache.
Just as a single example, the emote is 348,162 bytes. If I chuck that into ImageMagick and resize so that the largest side is 24 px using
resize ">24"
, the resulting image is 1,936 bytes–that’s a 180x reduction in size. Separate from that, additional image optimization can be done to reduce size: using Efficient Compression Tool with the-strip
and-9
parameters (to remove metadata and apply maximum compression, respectively) I can reduce the size of the larger by 26% and the smaller by 19%. Those savings are nice, and I think should be done eventually for the free bandwidth savings, but implementing variable image size should clearly be the priority when we’re talking a potential two orders of magnitude in savings. That obviously won’t be the case for every image (e.g. with the GIFs you’ll probably get large absolute reductions since they’re some of the heaviest files but small relative reductions because the dimensions are already fairly small), but it’s definitely worth doing. An intermediate max 60 px width size could be used for the keyword picker (the one that pops up when you type:
). We could even go further and resize the actual inline emotes in comments/posts, but there’s more nuance there and it’s not relevant to the emote picker performance.I will be honest and say that I have zero web dev experience, but I don’t think it ought to be too complicated (especially compared to the sprite or compression solutions). It’s a matter of doing the initial bulk generation + optimization of alternate sized images, storing each of the sizes in separate subdirectories, and having the three different cases point to the image in the correct subdirectory instead of the original image.
They are cached for sure. Just tested on Firefox mobile.
But they don’t stay in the cache, at least for me. I’ll wait 5 even 10 minutes sometimes, scrolling around and letting them all load, but then the next day I have to wait all over again (this is without logging out or even closing the browser). I’m also on firefox mobile but get the same results on firefox for desktop.
okay i waited two days and i still have them cached. I’m using Hexbear installed as a PWA on my android phone through firefox. Hard to say whats going on, but if you have the capability to debug it, i could try and fix it.
Can you even do this on pc? I have to scroll through the entire emoji picker every time and wait for them to load lmao