- Evidence
- 1 October capture: book at 2.39 s, chart at 4.13 s. In the campaign the chart is last in every ready load (warm medians: book 1.8 s, chart 2.8 s). A timed load shows the chart library (library.f5eaeb6901219f861981.js) and its first chunks requested only at 2.23 s and a second group of about 26 chart files at 2.65 s; chart ready at 3.89 s. In the 3 October recording a request classed as history runs from 2.75 to 3.01 s, around the chart's readiness at 2.86 s; the recording does not show that it carries candles or that the chart waits for it.
- Gap observed
- 1.7 s between the order book and the chart
- Holds back
- Chart (median 2.8 s in the timed loads).
- Fix
- Preload the chart library and its chunks with the first scripts, and send the candle request with the first /info requests at 0.9 s.
- Where
- Chart loader and datafeed initialisation; the HTML head.
- Verify
- DevTools → Network: library.js starts before 0.5 s; no group of chart files after 1.5 s.
HyperFlow: where its trading screen loses time, and what to fix
Measured from the Netherlands in a logged-in Chrome, October 2026.
In short. On a warm reload the screen is trade-ready after 3.5 s (median of 5 loads), 6 of 27 perpetual trading screens, possible rank 6 to 8; after an uncached reload 4.1 s.
The largest bottleneck: The chart is drawn 1.7 s after the book; its code arrives in a late wave. First change to try: Preload the chart library and its chunks with the first scripts, and send the candle request with the first /info requests at 0.9 s.
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 6 uncached reloads
| Warm reload | median 3.5 s, range 3.3 s–3.7 s; loads: 3.7 s, 3.3 s, 3.3 s, 3.5 s, 3.6 s |
| Uncached reload | median 4.1 s, range 3.6 s–8.0 s; loads: 4.2 s, 8.0 s, 4.0 s, 4.4 s, 3.6 s, 3.9 s |
| Standing | 6 of 27 by median; possible rank 6 to 8. 1.0 s behind the fastest, Thalex (2.4 s): 1.4 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, 6 of 6 uncached |
| Notes | recent trades not measured: outside viewport |
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 s
Order form0.7 s
Account panel0.7 s +0.0 s
Price0.9 s +0.3 s
Order book1.8 s +0.9 s
Chart2.8 s +1.0 s
Trade-ready3.5 s +0.7 s settling
Stack
React, built with Vite, on Vercel; TradingView chart library; viem and ethers; Privy and WalletConnect; trades on Hyperliquid through api.hyperliquid.xyz.
Delivery
hyperflow.fun on Vercel over HTTP/2 with every file served max-age=0, must-revalidate; market data from Hyperliquid's API (api.hyperliquid.xyz), over HTTP/1.1 and without compression.
| Host | Role | CDN edge seen | Connect | Response |
|---|---|---|---|---|
| hyperflow.fun | page | — | 14 ms | 32 ms |
| api.hyperliquid.xyz | market data | CloudFront Amsterdam | 12 ms | 230 ms |
| api-ui.hyperliquid.xyz | market data | CloudFront Amsterdam | 12 ms | 238 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 (Vercel). |
| 0.11–0.45 s | index-DcwWVkXX.js (1.8 MB compressed, 6.2 MB unpacked) with viem and ethers; index starts 1.0 s of main-thread work. |
| 0.51 s | First paint. |
| 0.91 s | The Hyperliquid feed opens (handshake 1.47 s, first message 1.76 s) and four REST calls go out; the three large ones (72, 64 and 137 KB) are returned uncompressed at 1.55–1.72 s. |
| 0.93 s | WalletConnect registry, 1.2 MB unpacked. |
| 1.09 s | Page header shows the market; price at 1.50 s. |
| 2.39 s | Order book shows. |
| 4.13 s | Chart drawn, 1.7 s after the book: 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 |
|---|---|
| 0.0 s | HTML arrives |
| 0.7 s | Order form ready |
| 0.7 s | account-table ready |
| 0.7 s | account-info ready |
| 1.0 s | Price ready |
| 1.1 s | First frame sent on a live feed |
| 1.4 s | First frame received on a live feed |
| 1.8 s | Order book ready |
| 2.7 s | First market-data request |
| 2.9 s | Chart ready |
| 3.5 s | Trade-ready |
185 requests before trade-ready; 8 long main-thread tasks (over 50 ms) before trade-ready, longest 145 ms; 5 script requests before the first panel; 29 requests over HTTP/1.1.
Request waterfalldiagnostic capture 1 October, uncached
67 of the 101 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.
PageScriptData requestImageStylesheetwaiting for the serverdownloading
Bottlenecks and fixes, largest firstdiagnostic capture 1 October, uncached
- Evidence
- index-DcwWVkXX.js is 6.3 MB unpacked (1.8 MB compressed) and, like every hyperflow.fun file, served with "public, max-age=0, must-revalidate" although its name is content-hashed. 3 October warm reload: of 174 responses, 10 came straight from the browser cache and 97 were re-checked with the server. 1.0 s of main-thread work starts in the index script. viem and ethers are both loaded (assets/viem-DJhKPKUP.js and assets/ethers-jAd7vO1_.js).
- Gap observed
- 1.0 s of main-thread work that starts in the main index script
- Holds back
- Start-up as a whole; which panel waits for this work is not established.
- Fix
- Serve hashed assets with max-age=31536000, immutable, and check whether both viem and ethers are needed.
- Where
- Vercel headers for /assets/; bundle dependencies.
- Verify
- DevTools → Network on a normal reload: index-*.js shows "(disk cache)", not 304.
- Evidence
- 1 October capture: four requests to api.hyperliquid.xyz start at 0.91–0.92 s and take 0.64 to 0.80 s; the three large ones wait 0.58–0.59 s for the first byte, and their responses (72, 64 and 137 KB) carry no content-encoding and were CDN misses. api.hyperliquid.xyz uses HTTP/1.1 (14 requests in the capture, 16 in the 3 October recording), as does app.hyperliquid.xyz (12). Later calls in a timed load take about 0.25 s. The captures hold no connection timing, so they do not show whether the slow first calls are waiting for a new connection.
- Gap observed
- 0.58 s to the first byte of each of the three large first API calls
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Try a preconnect to api.hyperliquid.xyz in the HTML head and see whether the first calls drop to the 0.25 s of the later ones; ask Hyperliquid for compressed responses, or proxy and cache public market data at an edge.
- Where
- HTML head; requests to api.hyperliquid.xyz.
- Verify
- DevTools → Network → Timing on the first /info call: connection set-up time; Headers: content-encoding present.
- Evidence
- All 11 ready campaign loads: between the chart having its data and trade-ready (about 0.70 s in 10 of them) the chart panel still has a running animation; in 3 warm loads the account table animates too. One uncached load took 4.3 s: the chart lost its data again and kept animating (trade-ready 7.95 s).
- Gap observed
- about 0.70 s between the chart and trade-ready in 10 of 11 timed loads
- 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.
- Likely saving
- Up to ~0.7 s
- Evidence
- 1 October capture: WalletConnect's wallet list (1.2 MB unpacked) at 0.93 s, 31 Privy scripts at 1.5–2.0 s (these came from the browser cache in that capture, so they cost processing, not download), a CoinGecko token list (202 KB) at 1.73 s and a li.quest response (84 KB) at 3.38 s; the book shows at 2.39 s and the chart at 4.13 s.
- Measured
- a 1.2 MB wallet list, 31 Privy scripts and two token lists before the chart
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Load the wallet list, Privy and the token lists after trade-ready or on the first wallet or swap action.
- Where
- Wallet provider set-up; the token-list loader (assets/getTokenList-*.js).
- Verify
- DevTools → Network: no walletconnect, privy, coingecko or li.quest request before the chart is drawn.
- Likely saving
- Unknown
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 6 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.