- Evidence
- 1 October capture: four responses from www.binance.com of 1.3 MB, 0.3 MB, 0.15 MB (no-store, no-cache) and 1.7 MB (no cache header, 62 KB compressed). The timed loads name them by matching sizes: /fapi/v1/exchangeInfo (1.3 MB, every market), /fapi/v1/ticker/24hr (0.3 MB, every market), /fapi/v1/continuousKlines (0.15 MB, the candle history, which takes 1.5 s in the capture and 0.25 s in a timed load) and /bapi/futures/v1/friendly/future/common/brackets (1.7 MB). An asset-logo list adds 0.2 MB, and three more responses from bin.bnbstatic.com (1.2 MB unpacked together, cached for 15 minutes) load at 0.36 s.
- Gap observed
- 1.5 s: the slowest of the four responses
- Holds back
- Not established: the captures do not show which panel waits for this.
- Waterfall rows
- row 4: 62 kB received, 1.3 MB unpacked, no-store; row 5: 66 kB received, 293 kB unpacked, no-store; row 27: 61 kB received, 151 kB unpacked, no-store; row 40: 62 kB received, 1.7 MB unpacked, no cache header
- Fix
- Ask exchangeInfo, ticker/24hr and brackets only for the market on the page (or cache them for minutes), and load the all-market versions after trade-ready for the market list.
- Where
- The callers of /fapi/v1/exchangeInfo, /fapi/v1/ticker/24hr and /bapi/.../common/brackets at start-up.
- Verify
- DevTools → Network, filter "exchangeInfo", "ticker/24hr", "brackets": each under 100 KB unpacked before the price shows, or served from cache.
Binance: 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 3.1 s (median of 5 loads), 5 of 27 perpetual trading screens, possible rank 3 to 5; after an uncached reload 3.0 s. It was measured logged out, so with fewer panels to load than a logged-in screen.
The largest bottleneck: About 3.4 MB of JSON at start-up, half of it marked no-store. First change to try: Ask exchangeInfo, ticker/24hr and brackets only for the market on the page (or cache them for minutes), and load the all-market versions after trade-ready for the market list.
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 3.1 s, range 3.0 s–3.2 s; loads: 3.0 s, 3.2 s, 3.1 s, 3.1 s, 3.0 s |
| Uncached reload | median 3.0 s, range 2.4 s–28.3 s; loads: 28.3 s, 3.0 s, 3.4 s, 2.4 s, 3.0 s. The 28.3 s load is counted; one slow load does not move the median |
| Standing | 5 of 27 by median; possible rank 3 to 5. 0.6 s behind the fastest, Thalex (2.4 s): 1.3 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); chart checked as drawn and updating, prices not read |
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
Price1.7 s
Recent trades2.2 s +0.5 s
Order form2.2 s +0.0 s
Order book2.3 s +0.1 s
Chart2.8 s +0.5 s
Trade-ready3.1 s +0.3 s settling
Stack
React (UMD vendor build) with app chunks from bin.bnbstatic.com; OneTrust banner; Sentry.
Delivery
HTML from www.binance.com through CloudFront, a miss in this load; app chunks cached a year; several JSON responses from www.binance.com are no-store; futures feed from fstream.binance.com.
| Host | Role | CDN edge seen | Connect | Response |
|---|---|---|---|---|
| www.binance.com | page | CloudFront Amsterdam | 12 ms | 9 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.25 s | HTML starts after a CloudFront miss. The 3 October recorded load: 0.35 s. |
| 0.36–0.85 s | App chunks (main 734 KB unpacked) and a 1.3 MB (unpacked) no-store JSON from www.binance.com. |
| 0.80 s | Page header shows the market; first paint at 0.87 s. |
| 0.86–2.35 s | A www.binance.com no-store request takes 1.5 s. |
| 1.00 s | OneTrust banner SDK (555 KB unpacked). |
| 1.87 s | The futures feed opens; handshake at 2.78 s; first message at 3.82 s. |
| 1.90–2.84 s | A 1.6 MB (unpacked) JSON response. |
| 3.06 s | Price shows, before the feed delivers; order book at 3.20 s. |
| 4.21 s | Chart drawn: trade-ready in this load. The React vendor build starts 1.0 s of main-thread work. |
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.4 s | HTML arrives |
| 0.5 s | First market-data request |
| 2.1 s | Price ready |
| 2.3 s | Order form ready |
| 2.4 s | Order book ready |
| 2.4 s | Recent trades ready |
| 3.0 s | Chart ready |
| 3.0 s | First frame sent on a live feed |
| 3.2 s | Trade-ready |
293 requests before trade-ready; 8 long main-thread tasks (over 50 ms) before trade-ready, longest 121 ms; 159 script requests before the first panel; 0 requests over HTTP/1.1.
Request waterfalldiagnostic capture 1 October, uncached
63 of the 283 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. Shaded rows are named in a finding below, tagged with its ID.
PageData requestScriptwaiting for the serverdownloading
Bottlenecks and fixes, largest firstdiagnostic capture 1 October, uncached
- Evidence
- 1 October capture: fstream.binance.com socket created at 1.87 s, handshake at 2.78 s, first message at 3.82 s, after the price is on screen at 3.06 s (so the first price comes from another source, probably REST). Five sockets are opened in total: two to fstream, two to nbstream and one to dstream; the second fstream socket (2.90 s) receives nothing before trade-ready.
- Gap observed
- 0.91 s from creating the futures socket to its handshake
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Open fstream from the first script, and check whether the second fstream socket and the nbstream and dstream sockets are needed before trade-ready.
- Where
- Futures feed client.
- Verify
- DevTools → Network → WS: fstream socket created before 0.8 s; sockets created before the chart is drawn.
- Evidence
- 1 October capture: book at 3.20 s, chart at 4.21 s; the chart is last in all 5 warm campaign loads (median 2.8 s against 2.3 s for the book). The candle history is requested at 0.86 s, and the chart script prel-Chart.a10ab629.js is first fetched as a preload at 1.13–1.27 s but requested as a script only at 2.55–2.73 s. The 3 October warm recording shows the same: the candle request runs 0.67–0.91 s and the chart is ready at 2.95 s, 2.0 s later. So the chart is not waiting for its data; it is started late.
- Gap observed
- 1.01 s between the order book and the chart
- Holds back
- Chart (median 2.8 s in the timed loads).
- Fix
- Find what delays loading the chart script until 2.6 s when it is already preloaded at 1.3 s, and start the chart when its candle data arrives.
- Where
- Chart loader and the route code that mounts the chart.
- Verify
- DevTools → Network: the chart script is requested as a script before 1.5 s; Performance: chart paint close to book paint.
- Evidence
- All 5 warm campaign loads: between the chart having its data and trade-ready (0.26 to 0.37 s) a font is not yet loaded, and in 3 of the 5 the layout also shifts. In one load every panel moved 47 px down. No chart animation is involved here. In the 1 October capture BinanceNova-Regular.woff2 is requested only at 1.88 s.
- Gap observed
- 0.26 to 0.37 s between the chart and trade-ready in the five warm loads
- Holds back
- Trade-ready itself: the page counts as ready only when nothing in a panel is still animating or loading.
- Fix
- Preload both BinanceNova font files in the HTML head, and reserve the height of whatever pushes the panels down 47 px.
- Where
- Font preload links in the HTML head; the element above the trading panels that appears late.
- Verify
- DevTools → Network: both woff2 files start before 0.5 s. DevTools → Performance → Layout shifts: none after the first panel shows.
- Likely saving
- ~0.3 s
- Evidence
- 1 October capture: OneTrust scripts at 0.36 s and its banner SDK (0.6 MB unpacked) at 1.00 s; the Sentry bundle at 0.88 s; the price shows at 3.06 s. 3 October recorded warm load: 132 ms of main thread attributed to Sentry and 68 ms to OneTrust.
- Gap observed
- 0.20 s of main-thread time attributed to Sentry and OneTrust over the recorded load
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Initialise Sentry and the banner SDK after the price shows, as far as the consent rules allow.
- Where
- The OneTrust and Sentry loaders in the page head.
- Verify
- DevTools → Performance → Bottom-up by third party: Sentry and OneTrust time before the price.
- Likely saving
- Unknown: about 0.2 s of main thread is attributed to the two over the whole load
- Evidence
- Campaign, uncached round 1: every other panel was ready by 2.74 s, but the recent-trades panel failed its check in 252 samples and passed only at 28.29 s, which made that load's trade-ready 28.3 s. The other 4 uncached loads and all 5 warm loads did not show it. The records do not show a failed request.
- Gap observed
- 25.6 s between the chart and the recent-trades panel in one uncached load
- Holds back
- The recent-trades panel, in 1 of 10 timed loads.
- Fix
- Check the recent-trades subscription for a missed first message or a failed resubscribe after connect.
- Where
- Recent-trades panel and its feed subscription.
- Verify
- Reload 20 times with the cache disabled: trades appear within a second of the order book every time.
- Likely saving
- None on the median; aimed at a rare 25 s stall
- Evidence
- All 20 older timed loads: 10 to 16 requests to api.saasexch.com/bapi/fe/usd/sa.gif per load, 9 to 16 of them before trade-ready. In one uncached load 14 start between 3.09 and 3.33 s, while the chart is still pending (ready at 3.49 s), each taking 0.23 to 0.45 s. The path is a tracking beacon; what it reports is not recorded.
- Measured
- 10 to 16 tracking beacons per load, most before trade-ready
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Queue the analytics beacons and send them in one batch after trade-ready.
- Where
- The analytics client that sends sa.gif beacons.
- Verify
- DevTools → Network, filter "sa.gif": none before the chart is drawn.
- Likely saving
- Small
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.