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.
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-stripand-9parameters (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.