I use Gamemaker and the HTML5 versions also suffer from bugs and crappy performance.

You’re using Python, an infamously slow language, inside of another emulated language, and the way you draw is slower than even just using canvas’s builtin drawing functions.

The physics engine is definitely the fastest here, considering it doesn’t have to loop anything per individual pixel.

Sorry, but there is nothing surprising here. At least one of the two things I mentioned have to go.

I use HTML5, JS, and CSS to code. I got lucky, and only need to directly upload my files. Going from web version to downloadable is actually difficult for me.

I have several games created with Pygame and exported to the web.

As others have mentioned, Python is a high-level language, designed to be easy to use, but it's not hardware-optimized like some other languages, and Pygame, depending on your game's resolution, requires a lot of CPU cycles.

You can optimize by vectorizing, using parallel processing, or leveraging GPU acceleration, but all of these tend to cause problems with Pygbag. So, the truth is, not every game programmed in Pygame is playable on the web.

In my experience, the same game that runs at 165 FPS on the desktop version will drop to 30 or 20 FPS on the web version,  If you're going to use Pygbag, it's best if your game has a low resolution or is a slow-paced game, like an interactive fiction game.

Not just you 🎮 Though mid and hechelion are right that the interpreter is the biggest single term in your particular case. I came at the browser from the other side — Three.js, JS all the way down, realtime multiplayer — and I still hit a version of this, so it’s worth separating “Python is slow” from “the browser is a different machine”. The second one bites everybody, and it’s the part that will still be true if you ever do rewrite in something faster.

The bit of your first post that nobody picked up is the crackling soundtrack, and I think it was the most useful signal you had.

Browser audio crackle is almost never an audio problem. It’s a buffer underrun — the audio callback didn’t get its next chunk of samples in time, so the hardware plays whatever was in the buffer. And in an Emscripten/SDL build the mixer usually shares the main thread with your frame loop, unless it’s specifically been moved onto an AudioWorklet. So a frame that blows its budget starves the audio in the same instant.

Which means the crackle was never a second bug sitting next to the slowdown. It was the same bug, and it’s a better instrument than an FPS counter, because a frame counter averages and an audio buffer forgives nothing. If you ever go back into this: loop a constant tone and walk through every screen. Everywhere it buzzes is somewhere you’re over budget — including places where an averaged frame number will tell you everything is fine.

Two other things that are browser-specific rather than Python-specific, in case they’re useful when you pick the next framework:

Check what resolution your canvas is actually rendering at. If anything in your stack sizes the drawing buffer by devicePixelRatio, then on a HiDPI screen you’re pushing 4x the pixels (9x on some phones) for an identical-looking image. It’s worth confirming because it’s invisible in exactly the wrong way — if you develop on a standard-DPI monitor you will never see it, and your report will be from players on laptops saying it’s unplayable while it’s perfect on your desk. Clamping that multiplier is usually the cheapest large win available in a web build.

The download didn’t go away, it moved. You went to web to kill install friction, which was the right call. But the payload still has to arrive, and now it downloads while the player watches a blank canvas with nothing to look at and no commitment made yet. Install friction at least happens after someone has decided they want the thing. A slow first load happens before. So on the web, payload size is a conversion number, not a performance number — which is a strange thing to get used to, and it argues for a loading screen that shows something the moment it can rather than at the end.

One question, since you’ve just been through it and the answer is a line: did the crackling and the frame rate get better together as you optimised, or did you have to fix them separately? If they moved together that’s the main-thread story above, and it would be good to have it confirmed by someone who actually measured it rather than just me asserting it.

I never managed to make web conversions of my games. For now they all are: download, unzip, play. No install ! To remove the game, just delete its folder.