Perf: cut first-load JS ~8× via route splitting + deferred web3 (PlayBlind teardown)

Aperta
  • Qualcosa non va?
#779 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
chart.js, react, typescript, vite
Ambito
frontend, performance

Direzione di ricerca

Start by reading vite.config.ts and tracing the app’s route components and wallet initialization; the issue names no route files or tests. Compare the initial bundle with route and wallet code to identify what loads at startup. Done means route splitting and deferred web3 loading reduce first-load JavaScript without changing dependency versions.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Summary

Competitive teardown of playblind.com (a similar onchain poker site with notably faster UX) shows they run nearly the identical stack we do — Vite + React + wagmi/viem + Reown AppKit + MetaMask/Coinbase. They are not fast because of an exotic framework. They are fast because of how they split and defer-load the same libraries. Our entire perceived-speed gap is bundling strategy.

The core finding: ~8× larger first-load

PlayBlind Us
Build tool Vite Vite
Framework React React 19
Web3 wagmi + viem + WalletConnect/Reown + MetaMask/Coinbase same
Initial JS ~218 KB (index.js) ~1.8 MB gzip / 7.4 MB raw, 22 chunks
Route splitting ~40 route-level chunks (Lobby, Table, Admin, Blog, Replay, ProvablyFair…) 0 routes split
Web3 stack lazy-loaded post-paint in an 800 KB Boot chunk loaded up front
React.lazy usage extensive 1 in the whole app

What's loaded up front for us, before first paint:

  • index-BY5dEnPJ.js — 626 KB gzip of pure wallet code (walletconnect / wagmi / coinbase / metamask / ethers / appkit)
  • index.esm-zM1Edlf2.js — 693 KB gzip of cosmjs + bip39 (gameplay signing)
  • crypto-browserify-B2Ep7zwg.js — 145 KB gzip

vite.config.ts also sets manualChunks: undefined, disabling Vite's splitting heuristics.

Proposed optimisations (impact-ordered)

  • Route-level code splitting (biggest win). 524 source files, 0 routes split. Wrap route components in React.lazy + Suspense. Lobby shouldn't ship the table/game engine; table shouldn't ship admin/profile.
  • Defer the web3 stack. Initialize Reown/wagmi lazily — only on "Connect Wallet" / deposit / withdraw — not at app boot. This is the single biggest lever (626 KB gz off first load).
  • Split the cosmjs/bip39 chunk (693 KB gz). Only needed once a wallet exists / a game is joined, not on the lobby/marketing view.
  • Re-enable manualChunks in vite.config.ts (remove manualChunks: undefined); let Rollup split vendors or define explicit groups (react / web3 / cosmos / charts).
  • Lazy-load chart.js + framer-motion — only on stats/profile screens, not the table.
  • Transport/caching parity: serve /assets/* with cache-control: immutable, max-age=31536000 (filenames are hashed), enable Brotli (~15-20% over gzip), HTTP/2/3, preconnect font/RPC origins. PlayBlind serves via Caddy with immutable 1-yr caching.
  • Optimise SVGs — b52CardBack.svg 101 KB, PokerProfile.svg 89 KB; run SVGO (likely -50-70%).

Recommendation

Do route splitting + deferred wallet init first — ~80% of the perceived-speed gap lives there, and both are low-risk config/wrapper changes, not rewrites.

Caveat: Node is pinned ≤22.13 for the Cosmos SDK, so these changes should stay bundling-config only and not touch dependency versions.

Findings from a bundle teardown on 2026-10-13 comparing our built build/assets against playblind.com's live assets.

Lingua principale
TypeScript
Stelle
2
Fork
5
Merge medio
22h 35m
PR unite (30g)
91

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di block52/ui

Tutte le issue di block52/ui

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.