Just chiming in a bit, as I seem to have come from the same background as @AGulev.
For most game portals, something upwards of 5mb is a complete dealbreaker for sponsorships. Unfortunately the size has to be taken into account before gzip. Optimizations like keeping the actual engine separate in a CDN is generally just not an option supported by most portals.
As an html5 game developer who relies on sponsorships, I would be less inclined to start any project in Defold because of this. I’m still enjoying Defold, but is commercially unviable for me as a tool for html5 web based games.
I think support for manual/auto stripping would be great - in the game I’m working on, I’m using my own custom physics/collision detection engine (just a simple uniform spatial grid) and would be able to do without the hefty box2d engine.
I know that the defold team is probably already weary of this and are doing their best to keep the size low. However, seeing as we’re writing on Lua and the runtime is probably included in the build, that might be where the bulk of the payload size is and would thus never become negligible.
TLDR - size is quite non-negotiable for game portals. Gzip/CDNs is not a factor we can rely on. As it stands, the runtime is just too big to use right now for this use case.
Sorry if my comment is just a bit of a reiteration of most of the comments, but I just felt like I needed to emphasize just how non-negotiable size is for game portals, and is a problem we can’t work around.
Personally, due to how Defold is (3d engine + non-js), I feel like this would always be this big, so it’s just not a fit for games relying on sponsorships. Which is okay, since I think it can fit other niches. I’m of course optimistic as the tech improves.