Start up performance of arcade iframe embed

For fun/learning, I threw together a site with Gatsby and hosted it on github pages collecting some of the games I’ve made with makecode arcade: https://jacobcarpenter.com/makecode.

I’ve been really impressed with the Gatsby site’s performance. It’s fun writing React that essentially turns into static content.

However, on the individual game pages, the makecode simulator embed that I’m using seems to monopolize JS execution for several uninterrupted seconds on my computer (with no CPU throttling):

On my phone, the result is even worse. The page becomes unresponsive (scrolling, navigating), during the time the uninterrupted compile function is running.

Am I using the embed incorrectly? Am I perhaps linking to the wrong resource or something? I’d love to hear any suggestions you may have to make this faster!

To be clear: I’m not concerned about the total duration that “Loading…” is displayed for. I’m specifically interested in not utilizing all of the browser’s script execution resources for a long, uninterrupted chunk of time.

Thanks!

As you noticed, a lot of that time is likely just the compiler building the game - you can get around that entirely by using the github pages built with beta, which build a precompiled version of the game on each bump and load that instead - here’s a page with a bunch of sims at once using that: jwunderl.dev/examples (it’s a bit ugly, I only tend to update it when I wanna try something new e.g. react router or react transition groups).

1 Like

Ooh. Yes. Okay… more incentive to use the beta GitHub integration.

That page you linked to works great, even on my phone. Thanks!

We precomiple the JavaScript and avoid the iframes in the GitHub integration.

I locally tested putting meadow onto github and using the prebuilt version as the embed and performance is indeed much better!

Question: Is there a way to point my pages at a specific release? I’d like to retain the ability to be able to iterate on a project (with commit history) without overwriting what’s deployed and referenced by my site.

Question: Is there a way to point my pages at a specific release ? I’d like to retain the ability to be able to iterate on a project (with commit history) without overwriting what’s deployed and referenced by my site.

Yes, it looks like this is how releases work already! From some testing it looks like the pages version of the site always reflects the latest release.

I think I was initially confused by some of the UI (all of this is about /beta):

  1. after committing to a repo that already has a release, the dialog displays the following:

  1. (continued…) “Pages building” is confusing, because it seems like, if there’s a release, Pages doesn’t actually update after a commit. (Which is exactly the desired behavior I want; but the status message seems confusing.)

  2. While testing this, I think I ran into a bug: after creating a release for testing, I reverted a commit (using the History commit list UI). Then I created another release. But the version number in version.txt had been reverted by the revert commit, so the next version number was improperly computed.

Github rebuilds page on every commit and the button reflects that. It might be that you updated README.md and it is getting updated. The javascript is only update on release – it’s pretty big and would bloat the commits.

Yeah… reverting and version numbers. Did you end up overriding an existing release?

I guess we are ready the version number from pxt.json and not github so you’ll probably end up with 2 version numbers unless you are careful. I should test if the version number already exists in the selection dialog.

Yes, I think I understand. The distinction is subtle, but I get it.

Yes, I think that’s what happened. In tags view and on the releases tab, I only see two version numbers (1.0.0 and 1.0.1), despite the fact that I have made three releases (using the Release button in makecode). The third release seems to have overwritten the previous 1.0.1.