Slow loading from Tokyo (Japan)

Summary
On Windows 11 + Firefox, the Scratch project editor's "Loading project..." screen hangs for 1-2 minutes. Reproduces in Private Browsing with Enhanced Tracking Protection and hardware acceleration disabled. Does not occur in Chrome.

Environment

• OS: Windows 11
• Browser: Firefox 155.0 (rv:155.0)
• Project ID: 1378924028
• URL: https://scratch.mit.edu/projects/1378924028/editor

Issue 1: Broken fetch-worker chunk causes multi-minute hang (Firefox-specific)

On every page load, Firefox requests two different hashed "fetch-worker" chunks almost simultaneously:

1. chunks/fetch-worker.7298f079654fee093ceb.js
   • Always fails. Via the Tokyo (NRT) edge, it hangs for 103-127 seconds before returning a 503. Via a London (LCY) edge, it fails immediately with a 403. Both report x-cache: MISS.
2. chunks/fetch-worker.12a0667c4caaa6201bad.js
   • Always succeeds in a few to a few dozen ms, x-cache: HIT.

File #1 appears to be an orphaned/broken chunk that no longer exists correctly in the current deployment, but the client keeps requesting it every load. On the Tokyo edge/origin shield specifically, this request hangs for 100+ seconds before erroring out, which is the entire cause of the perceived "slow loading" — most other page assets finish loading within 1-2 seconds.

Edge servers observed:

• cache-nrt-rjaa8190020-NRT (MISS, hangs)
• cache-nrt-rjaa8190053-NRT (MISS, hangs)
• cache-lcy-egml8630073-LCY (MISS, fails fast with 403)

Suspected cause (unverified): Firefox's feature detection for module Web Workers (new Worker(url, { type: "module" })) may cause the app to also request a classic-worker fallback chunk. That fallback chunk (#1 above) seems to be a leftover/broken reference in the current build, while Chrome likely never requests it, since it uses module workers directly. I have not verified this against the scratch-gui source, so please treat it only as a possible lead.

Request:

• Could someone confirm whether chunks/fetch-worker.7298f079654fee093ceb.js is actually still needed by the current build? If not, removing the reference (or fixing the fallback logic) should resolve this for all Firefox users.
• It would also help to check whether the Tokyo (NRT) Fastly edge/origin shield cache for this asset needs to be purged/fixed.

Issue 2: scratch.mit.edu has no IPv6 (AAAA) support

While investigating a separate, unrelated slowness issue (severe packet loss/latency on the IPv4 peering path between my ISP and Fastly's Tokyo POP), I found that scratch.mit.edu has no AAAA record at all (nslookup -type=AAAA scratch.mit.edu returns no answer), so it can only be reached over IPv4.

Many residential connections in Japan (and IPv6/IPoE is broadly deployed there) can suffer from congestion on the legacy IPv4/PPPoE path during peak hours, while native IPv6 paths to the same CDN are unaffected. I confirmed this directly: another site served from the same Fastly network but with IPv6 support (fastly.jsdelivr.net) downloaded at ~39MB/s under the exact same network conditions where scratch.mit.edu (IPv4 only) was limited to ~15KB/s due to ~15% packet loss on the IPv4 peering link.

Request:

• Please consider adding AAAA records for scratch.mit.edu (and related domains such as projects.scratch.mit.edu) so users on IPv6-capable networks (especially in regions with high IPv6/IPoE adoption like Japan) can bypass this kind of IPv4-specific peering congestion.

Happy to share HAR files, traceroute/WinMTR output, or anything else that would help.

Start by inspecting the scratch-gui build references and reproducing the Firefox network requests for both fetch-worker chunks. Confirm whether the 7298f079... chunk is still referenced, then separately investigate the Tokyo CDN behavior and the requested AAAA records. Done means Firefox no longer waits on an obsolete chunk and the IPv6 request has a documented, validated resolution.