- Evidence
- 1 October capture: feed socket to api.rise.trade created at 1.90 s, handshake at 3.10 s (1.2 s), first message at 3.49 s; book at 4.35 s, 0.86 s after that message. The price shows at 2.37 s, before the feed is connected, so it comes from another source. The capture does not show that the first message carries the book.
- Gap observed
- 1.2 s from creating the feed socket to its handshake
- Holds back
- Probably the book (median 2.9 s in the timed loads): the timing points to it, but the captures do not show that this panel waits for it.
- Fix
- Open the feed from the first script and check why its handshake takes 1.2 s; render the book from its first snapshot.
- Where
- api.rise.trade socket endpoint and feed client.
- Verify
- DevTools → Network → WS: socket created before 0.5 s; handshake time.
Rise: where its trading screen loses time, and what to fix
Measured from the Netherlands in Chrome, logged out, October 2026.
In short. On a warm reload the screen is trade-ready after 4.6 s (median of 5 loads), 13 of 27 perpetual trading screens, possible rank 12 to 20; after an uncached reload 4.4 s. It was measured logged out, so with fewer panels to load than a logged-in screen.
The largest bottleneck: The feed takes 1.2 s to connect, and the order book shows 0.9 s after its first message. First change to try: Open the feed from the first script and check why its handshake takes 1.2 s; render the book from its first snapshot.
Three measurements appear on this page, and their times differ. Rank and results come from the campaign's timed reloads. The diagnostic capture and the recorded reload are single loads made with recording switched on, which slows the page: read them for the order of events and the gaps, not for totals.
Resultscampaign: 5 warm and 5 uncached reloads
| Warm reload | median 4.6 s, range 4.4 s–4.8 s; loads: 4.7 s, 4.8 s, 4.6 s, 4.4 s, 4.5 s |
| Uncached reload | median 4.4 s, range 4.4 s–4.6 s; loads: 4.6 s, 4.4 s, 4.6 s, 4.4 s, 4.4 s |
| Standing | 13 of 27 by median; possible rank 12 to 20. 2.1 s behind the fastest, Thalex (2.4 s): 1.9 times as long. The possible rank is the range the measurements leave open: it counts only the exchanges that clearly beat this one and those it clearly beats. Exchanges whose ranges overlap cannot be told apart. |
| Loads ready | 5 of 5 warm, 5 of 5 uncached |
| Notes | measured logged out (fewer panels to load); recent trades not measured: inactive tab |
Where the time goescampaign medians, warm reload
Panels in the order they first showed real, usable data on a warm reload. The coloured part of each row is the time that panel added after the one before it. The last row is trade-ready: every panel is ready and the page has stopped moving.
0 s1 s2 s3 s4 s
Price2.5 s
Order form2.5 s +0.0 s
Account panel2.5 s +0.0 s
Order book2.9 s +0.4 s
Chart3.3 s +0.4 s
Trade-ready4.6 s +1.3 s settling
Stack
Next.js; TradingView chart library (library.js); Privy wallet and WalletConnect; Sentry; an IP lookup (api.ipify.org); RISE chain RPC.
Delivery
HTML from Vercel marked private, no-store, so never cached; app chunks immutable for a year; market data from api.rise.trade.
| Host | Role | CDN edge seen | Connect | Response |
|---|---|---|---|---|
| www.rise.trade | page | — | 12 ms | 48 ms |
Median of up to 10 attempts from the test machine. Response time includes the server's own time, so it is not a distance.
What happened, in orderdiagnostic capture 1 October, uncached
From one uncached diagnostic load recorded on 1 October 2026 (cache disabled, browser extensions active), so totals are slower than the campaign's timed loads; file names, sizes, headers, order of events and main-thread times are what the findings rely on. A main-thread time given for a script counts all the work that starts in that script, including code it calls in other files, so it shows where start-up work begins, not what one library costs. Endpoint paths were masked when the capture was saved.
| When | What |
|---|---|
| 0.02 s | HTML arrives on 1 October; on 3 October the recorded load waited 0.99 s for it; it is marked no-store, so it is never served from a cache. |
| 0.45–1.38 s | Script chunks: 1678 (646 KB compressed, 2.3 MB unpacked, the slowest at 0.92 s), 2743 (1.3 MB unpacked), 2399 (1.0 MB unpacked, later 0.79 s of main thread). A 157 KB image sent uncompressed with max-age=0. |
| 0.83 s | Page header shows the market; first paint at 0.98 s. |
| 1.90 s | The live feed opens; handshake done at 3.10 s, 1.2 s later; first message at 3.49 s. |
| 1.93 s | WalletConnect registry (1.2 MB unpacked); Privy makes 35 requests. |
| 2.37 s | Price shows, before the feed is connected, so it does not come from the feed. |
| 3.02–3.89 s | RISE chain RPC calls. |
| 4.35 s | Order book shows, 0.9 s after the first feed message. |
| 5.39 s | Chart drawn: trade-ready in this load. |
Recorded warm reload, 3 October
One warm reload recorded with Chrome's performance trace. Recording slows the page, so read the order and the gaps, not the total.
| When | What |
|---|---|
| 1.0 s | HTML arrives |
| 2.1 s | First market-data request |
| 2.5 s | First frame sent on a live feed |
| 2.8 s | First frame received on a live feed |
| 3.3 s | Price ready |
| 3.3 s | Order form ready |
| 3.3 s | balances ready |
| 3.6 s | Order book ready |
| 4.0 s | Chart ready |
| 5.3 s | Trade-ready |
265 requests before trade-ready; 10 long main-thread tasks (over 50 ms) before trade-ready, longest 147 ms; 121 script requests before the first panel; 3 requests over HTTP/1.1.
Request waterfalldiagnostic capture 1 October, uncached
65 of the 183 requests (the page itself, the longest and the largest) started before market data was ready in the 1 October uncached capture, in start order. The outlined part of a bar is waiting for the server; the solid part is downloading. Rows are numbered so a request can be pointed to. The numbers on the right are the size received and the total time. Vertical lines mark when a panel had data in this capture.
PageImageScriptData requestwaiting for the serverdownloading
Bottlenecks and fixes, largest firstdiagnostic capture 1 October, uncached
- Evidence
- Campaign warm loads: the chart is the last panel in all 5 (median 3.3 s) and trade-ready follows at a median 4.6 s. Recorded load: 1.3 s; in all 13 samples in between, the chart panel has 6 running animations, the last at 5.22 s. The same animation condition fails in all 10 timed loads we could replay; the panels do not move.
- Gap observed
- 1.3 s between the median time of the last panel and the median trade-ready time (two separate medians, not a wait measured inside one load)
- Holds back
- Trade-ready itself: the page counts as ready only when nothing in a panel is still animating or loading.
- Fix
- Record a reload with DevTools → Animations and find what still animates in the chart after the candles are drawn, for example a toolbar loading spinner or a fade-in; end it when the data is in.
- Where
- The chart panel and its loading states.
- Verify
- DevTools → Animations during a reload: nothing in the chart container animates after the candles appear.
- Evidence
- private, no-store on Vercel: 19 ms to the first byte on 1 October but 987 ms in the 3 October recorded load, for a 186 KB document (49 KB compressed). Two loads do not show how often the slow case happens.
- Gap observed
- 0.99 s to the HTML first byte on 3 October; 0.02 s on 1 October
- Holds back
- Every panel: nothing is shown before this ends.
- Fix
- Serve the trading page as a static or cached shell from Vercel's edge.
- Where
- Next.js route config (static rendering or revalidate) for the trade page.
- Verify
- DevTools → Network → document: x-vercel-cache HIT, under 100 ms.
- Evidence
- 1 October capture: an IP lookup (api.ipify.org) and WalletConnect's 1.2 MB wallet list at 1.92 s, 35 Privy requests from 2.76 s, and three RISE chain RPC calls at 3.0–3.9 s (0.85 s each), all before the book at 4.35 s.
- Gap observed
- 0.9 s across the chain-RPC activity window
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Defer wallet SDKs, the IP lookup and chain RPC until after the trading screen is shown.
- Where
- Providers in the Next.js app layout.
- Verify
- DevTools → Network: no privy, walletconnect or rpc request before the first book paint.
- Evidence
- 1 October timed loads, uncached and warm: api.rise.trade/api/v1/markets is requested twice (1.77 and 2.98 s), /auth/eip712-domain three times, /competitions twice 2 ms apart, and www.rise.trade/api/auth/session twice (the first takes 0.69 s). Two font files are also requested twice before the first paint. The page also fetches other pages while loading, some through addresses with a double slash (/en//vault takes 1.09 s and returns 219 bytes, followed by /en/vault; likewise /en//trade and /en//portfolio).
- Measured
- four endpoints requested two or three times each, and page prefetches through "/en//" addresses
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Share one request per address for markets, eip712-domain, competitions and auth/session. Fix the link that produces "/en//…" and prefetch other pages after trade-ready.
- Where
- The callers of those four endpoints; the navigation links that build the "/en//" addresses; Next.js link prefetching.
- Verify
- DevTools → Network, filter "/en//": no requests; filter "api/v1/markets": one request.
- Likely saving
- Small
- Evidence
- The 1 October capture and all 20 older timed loads: of 6 Sentry requests per load, one is answered with HTTP 429 (too many requests); our repeated test loads may have caused that limit. In the same loads /_vercel/insights/script.js returns HTTP 404 every time (1.64–1.81 s in one), so Vercel's analytics script is requested but does not exist.
- Measured
- 1 of 6 error-reporting requests rejected and one script answered with 404, on every load
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Remove the Vercel insights tag or enable the feature so the script exists; check how many Sentry requests one page load sends and move them after trade-ready.
- Where
- The Vercel analytics component in the app layout; Sentry client configuration.
- Verify
- DevTools → Network, filter "status-code:404" and "status-code:429": none during a page load.
- Likely saving
- None on trade-ready
Grade B: the capture shows the problem directly. Grade C: the order of events in the capture points to it; the dependency is for the team to confirm. The order is our judgement of each finding's effect on trade-ready, largest first; it is not sorted by gap. A gap is the time between two observed events or the time one piece of work takes; gaps overlap and do not add up. Where a finding is about size or count and no time was measured, the row says what was measured instead. Holds back names the panel the finding delays. Nothing here is graded higher, because no fix was confirmed by changing a page and measuring again.
Savings are estimates from the timeline, not measured after a change. They overlap, so they do not add up; the summary gives the combined estimate.
How this was measured
Timings: 5 warm and 5 uncached reloads in a seeded random order across all exchanges, each judged against a checklist frozen for this page before the campaign; trade-ready is the first moment every checklist panel shows real data, nothing is still loading, and the layout holds still for 0.5 s. The findings on this page come from separate recorded loads, which are never part of the timings. Full method.