Slow loading from Tokyo (Japan)

Abierto
  • ¿Algo no está bien?
#696 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript
Área
cloud, frontend, networking, performance

Línea de trabajo

Empieza inspeccionando las referencias de build de scratch-gui y reproduciendo las solicitudes de red de Firefox para ambos chunks de fetch-worker. Confirma si el chunk 7298f079... todavía está referenciado y, por separado, investiga el comportamiento del Tokyo CDN y los registros AAAA solicitados. Se considera terminado cuando Firefox ya no espera un chunk obsoleto y la solicitud IPv6 tiene una resolución documentada y validada.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

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.

Lenguaje dominante
JavaScript
Estrellas
310
Forks
299
Merge medio
19 h 41 min
PR fusionados (30 d)
14

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de scratchfoundation/scratch-editor

Todos los issues de scratchfoundation/scratch-editor

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.