The emoji picker is incredibly slow for me when it comes to previews. Can I cache all the emojis so it becomes useable?

  • Chronicon [they/them]@hexbear.net
    link
    fedilink
    English
    arrow-up
    7
    ·
    edit-2
    3 months ago

    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

  • aaro [they/them, she/her]@hexbear.net
    link
    fedilink
    English
    arrow-up
    6
    ·
    3 months ago

    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?

    • AernaLingus [any]@hexbear.net
      link
      fedilink
      English
      arrow-up
      3
      ·
      3 months ago

      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 left-unity-4 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.

    • QuietCupcake [any, they/them]@hexbear.net
      link
      fedilink
      English
      arrow-up
      7
      ·
      3 months ago

      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.

      • makotech222 [he/him]@hexbear.net
        link
        fedilink
        English
        arrow-up
        1
        ·
        3 months ago

        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.