Re-sizing the images ahead of time should fix this issue and could also save some space.
The bigger problem I can see with this fix is it is could be a lot of work and it would would increase the workload for new stuffing images.
You do have a lot of stuffing images in my opinion and can easily reduce or remove them from the game while still keeping in enjoyable.
My first impression regarding the images is about how many different for the play relevant states for the charaters exists. I see only two: Normal and overfull.
I am for limiting the number of pictures to these two states.
Regarding the images I implore you to not delete them. It is far to possible, that you may find use for them later.
Honestly youāre more likely to see the middle stuffing states at the beginning of the game, as near end game youāll be blitzing through enemies so youāll usually see the last stuffing state. So reducing the stuffing frames to like 4 in the first set of weight stages, 2-3 for the second set of weight stages, and then just like 1 or 2 for the last set as by then theyāll be so big that a stuffed tum would be less noticeable. Considering each weight level has 10 pictures (Base, then 9 different stages of stuffed), thatād reduce the number of images for each character at most down by about less than half of the original amount of pictures for a fully fleshed out character, and at the lowest a third of the original amount.
I think I know what Iām gonna do at this point, reduce the stuffing images by half and optimizing the filesize with tinypng. The problem was my assumption that the image files were already very well optimized + my tendency to fall for āNot Invented Hereā
There 10 stuffing levels per weight level, so its 150 images per character total.
Thank you, I should be able to fix the game with this information
Theyāre already as small dimension-wise as Iād like them to be, so they can look good on large screens.
Iām late to this party, but having watched the game load in developer tools, I suspect the problem isnāt the size of the images, but the sheer number of them. It takes time to request and handshake each one (geographic distance to the server is the killer here - those packets have to go back and forth during negotiation) and the browser only allows itself to have a certain number of requests active at one time (four is a typical count) - making these operations essentially sequential.
Two things that could help:
Put all the weight/stuffing images of a character in a single image, like a sprite sheet. This will compress better, but importantly result in a single request per character rather than 150 requests per character. Then use offsets & cropping to display the right part of the sheet in the image. Getting four characters as four downloads is something the browser can do in parallel and is only then limited by download speeds (which you canāt control).
Lazily load characters. You only need the starting four to get the game going, put off loading the others until they are unlocked and needed.
I hope that helps.
Than I want to amend my comment about only two relevant states of fullness:
There is a (not that relevant) third stage for a character that goes over capacity but is not yet overfull (between 100% and 200% fullness with over 200% they become incapicated).
But please do not delete already complete art. Make a legacy folder or something but there will be a time for you when you will want to look at one (or more) for reference. Please 
Ah I didnāt realize # of requests was such a factor. This is my first big web development project so Iām still learning things.
This is something I want to do but I figured getting the filesize under control first was important
I basically never delete anything, Iāll keep the files at least. Donāt know if Iāll post them anywhere.
Sure, it wonāt look as majestic as it is right now, but if it streamlines the development process Iām all for this change of pace.
Donāt worry about it; Iāve had to point this out to professionals from top consultancies before now! I usually begin with āWe cannae break the laws of physics!ā. So, the speed of light is roughly 300,000 km/s (excuse the metric - the maths is easier), and for reasons (waveguides, regeneration of optical wavefrontsā¦) signals, ballpark, travel at 1/3 light speed (still faster than full impulse, more like warp 0.7 if the earlier reference struck home), so 100,000km/s. Itās roughly 7,000km from me in the UK to the USA, or 14,000km there and back. So, even assuming no delay in the host web server (not remotely true!) it takes about 1/7th of a second for a round trip. Multiply that up for the 600 images for the four original characters and Iām looking at 1 minute and 24 seconds just for the comms delay, without moving any image data. By contrast (assuming 600 200kb images) if both ends and all the gubbins in the middle can sustain 10Mbyte/s then the data transfer is just 12 seconds. Obviously this is very simplified, and these figures are going to be swamped by the processing times at either end, but I donāt suppose you even considered the speed of light was a factor in your fetish game development!
So, if this is the case, then why not put all of the gameās images into one really big picture? Then only one imageās data needs to move between the host and client.
Just an idea I had for a character concept: A character that is Slow and can only target one enemy at a time, but can attack using all 4 offensive attack types (Weapon, Magic, Sneak, and Faith).
How do you get an S-rank time on the Bonus Round next to the Beefcake Dragon? The target time is 7.487 seconds and my best is 12.272. A lot of the enemies are physical, and all physical damage is single target. It just seems well beyond the limits of my manual dexterity.
Keeping each character separate would allow for lazy loading - you donāt need to load all the characters at startup. I suspect most players have a few favourites, and stick to them, meaning there would be parts of such a huge picture that would never be needed. If I were to play with four characters out of a roster of 12 (honestly Iāve forgotten how many there are so far) then I only need 1/3rd of the image of them all - the other 2/3rds is redundant for me, and a different 2/3rds redundant for someone else. As with any optimisation there are going to be trade-offs, and some experimentation needed to see what works well. What Iāve suggested is my best first guess based on what I can observe and my experience/intuition.
Also keeping them separate might help preserve @bewildered_angelās sanity in dealing with the code necessary to pick the right part of the image to display, and make adding a new character to the roster more straightforward (just another file, rather than a complete re-work).
This is the biggest reason right here. You never want to put all your eggs in one basket, and by extension you never want to put all of your assets on one sprite sheet. Especially given that, if something goes wrong, it could mess up literally every single graphic in the game if they are all in the same file. And being able to isolate issues to a specific file makes troubleshooting so much easier.
I think this is sort of the right direction to be thinking as the gameās visual assets uhā¦ expand, though designing vector images and getting them to work as intended (especially when it comes to varying fatness levels) is a greater initial technical challenge than having umpteen image layers. A properly designed vectorized belly system would use far less space as the number of characters grows.
It makes me think of the visualisation system used in Tainted Elysium which (iirc) was a pain in the butt for the dev to begin with but was really cool in how it allowed for all sorts of seemingly seamless morphs.
If vector art frees room for size transition animations then I think any necessary delay in updates will be forgiven. :3
Update, everything works now, thanks!
Iām hesitant about this because sheād be a really strong pick for every level in the game. Might be too good.
I will be fixing the algorithmās weapon adjustment soon.
I havenāt actually done anything yet oops. Maybe a file loaded incorrectly and it got redownloaded?
Using vector images would definitely be the best option, but itās very difficult to do when the majority of your work is drawn. You would have to take the drawn work, cut it into shapes, make those shapes into vectors, and then re-assemble it into an image. Which is not an easy task, by any means.
Well, GIMP has a āselect by colorā tool that can come in handy with stuff like that. Just grab the belly, put it on a new layer, hide the original layer, and export as a .png. Dunno what Angelās using, but I think itād be more tedious than difficult.
GIMP isnāt ideal for Vector work, if you use FOSS, youāre more likely to have a good time using something like Inkscape. Definitely requires short-term work for conversion, but drawing could be done straight to vectors going forward after that.