- Evidence
- 1 October capture: first paint at 2.85 s, and 3.5 s of long main-thread tasks before trade-ready; the first app scripts start at 0.77 s in that load, but at 0.19 s in the timed loads, so a late script start is not the general cause. 3 October recorded warm load: 288 script requests before the first panel and 1.6 s of long tasks, the longest a single 616 ms task at 0.95 s; the first panel shows at 3.44 s.
- Gap observed
- 2.8 s from HTML arrival to first paint; 3.5 s of main-thread time before trade-ready
- Holds back
- Every panel: nothing is shown before this ends.
- Fix
- Profile the 616 ms task at about 1 s and split it; cut the 288 script requests before the first panel by bundling the trade route (the largest chunks are several vendor-*.js files of 0.3–0.4 MB each).
- Where
- Bundler output for the trade route; the start-up code that runs in the first second.
- Verify
- DevTools → Performance: no task over 200 ms before the first panel; Network: script requests before the first panel.
Aster: 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 5.6 s (median of 5 loads), 22 of 27 perpetual trading screens, possible rank 19 to 24; after an uncached reload 5.7 s.
The largest bottleneck: Nothing paints until 2.85 s although the HTML arrives in 15 ms. First change to try: Profile the 616 ms task at about 1 s and split it; cut the 288 script requests before the first panel by bundling the trade route (the largest chunks are several vendor-*.js files of 0.3–0.4 MB each).
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 5.6 s, range 5.3 s–6.4 s; loads: 6.4 s, 5.6 s, 5.5 s, 6.1 s, 5.3 s |
| Uncached reload | median 5.7 s, range 5.3 s–6.2 s; loads: 5.9 s, 5.6 s, 5.7 s, 6.2 s, 5.3 s |
| Standing | 22 of 27 by median; possible rank 19 to 24. 3.1 s behind the fastest, Thalex (2.4 s): 2.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 | 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 s5 s
Price3.9 s
Order form3.9 s +0.0 s
Account panel3.9 s +0.0 s
Order book4.1 s +0.2 s
Chart4.9 s +0.8 s
Trade-ready5.6 s +0.7 s settling
Stack
React; app files from static2.asterdexfx.com; BNB Chain RPC providers (Ankr, NodeReal, bscrpc, Ninicoin) and a SPACE ID name lookup; Privy wallet; market feeds from asterdex.com and a Binance stream.
Delivery
HTML from CloudFront (public, no-cache, edge hit); app files from static2.asterdexfx.com cached for a year; JSON from www.asterdex.com without a cache header.
| Host | Role | CDN edge seen | Connect | Response |
|---|---|---|---|---|
| www.asterdex.com | page | CloudFront Amsterdam | 14 ms | 10 ms |
| fapi.asterdex.com | market data | CloudFront Amsterdam | 14 ms | 234 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 from CloudFront. |
| 0.78–1.37 s | The first app scripts are only requested at 0.78 s: vendor (419 KB unpacked) and a shared locale bundle (544 KB unpacked). |
| 1.71 s | A SPACE ID name lookup starts; it takes 2.1 s (until 3.80 s). BNB Chain RPC calls go out to Ankr, NodeReal, bscrpc and Ninicoin. |
| 1.98 s | A 509 KB (unpacked) file from static.asterdexfx.com; the same 509 KB file is fetched again at 2.85 s. |
| 2.08 s | An 819 KB (unpacked) JSON from www.asterdex.com; an 819 KB response is fetched again at 3.37 s and an 824 KB one at 3.39 s. |
| 2.13 s | A Binance stream (nbstream.binance.com) opens; its handshake takes 1.7 s. |
| 2.82 s | Page header shows the market; first paint at 2.85 s. |
| 3.24 s | Aster's own market feeds open (fstream5, sstream); handshakes done at 4.00 s. |
| 3.43 s | Price shows; order book at 4.20 s. |
| 7.44 s | Chart drawn, 3.2 s after the book: trade-ready in this load. 19 long tasks took 3.5 s of main thread; vendor-BvbU0fAw.js alone 1.0 s. |
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.8 s | First market-data request |
| 1.7 s | First frame sent on a live feed |
| 3.2 s | First frame received on a live feed |
| 3.4 s | Price ready |
| 3.4 s | Order form ready |
| 3.4 s | account-info ready |
| 3.6 s | Order book ready |
| 3.7 s | positions ready |
| 4.5 s | Chart ready |
| 5.2 s | Trade-ready |
563 requests before trade-ready; 10 long main-thread tasks (over 50 ms) before trade-ready, longest 616 ms; 288 script requests before the first panel; 0 requests over HTTP/1.1.
Request waterfalldiagnostic capture 1 October, uncached
67 of the 307 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.
PageData requestScriptwaiting for the serverdownloading
Bottlenecks and fixes, largest firstdiagnostic capture 1 October, uncached
- Evidence
- 1 October capture: book at 4.20 s, chart at 7.44 s. The chart is the last panel in all 5 warm campaign loads (median 4.9 s against 3.9–4.1 s for price, book and order form). The timed loads show www.asterdex.com/fapi/v1/klines requested once early (1.4 s) and then three more times between 5.6 and 7.0 s; in the 3 October recording the first candle response is in by 1.53 s, 2.9 s before the chart is drawn. So the first candle response is in long before the chart shows.
- Gap observed
- 3.24 s between the order book and the chart
- Holds back
- Chart (median 4.9 s in the timed loads).
- Fix
- Find what the chart waits for after its first candles are in at about 1.5 s: the three later /fapi/v1/klines requests or the chart code. Start them with the other market data.
- Where
- Chart component and datafeed.
- Verify
- DevTools → Network, filter "klines": all requests start before 2 s; the chart appears close to the book.
- Evidence
- All 20 older timed loads repeat these requests. In one: /fapi/v1/astherusExchangeInfo (838 KB unpacked, 35 KB compressed) at 1.45 s and again at 2.66 s; /bapi/futures/v1/friendly/future/common/brackets (844 KB unpacked) twice in parallel at 2.67 and 2.71 s, each taking about 1.0 s; and five translation files (aster-ui, dex-on-chain-perp, futures-ui, kline-ui, trade-ui) each at 1.37 s and again at 2.17 s. The second copy of a file may come from the cache.
- Measured
- two 0.8 MB responses and five translation files, each requested twice
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Share one request per address: astherusExchangeInfo, brackets and the five translation files.
- Where
- Data-fetching hooks for exchange info and brackets; the translation loader.
- Verify
- DevTools → Network, filter "astherusExchangeInfo", "brackets", "i18n": each address once per load.
- Evidence
- 1 October capture: A SPACE ID name lookup lasting 2.1 s starts at 1.71 s and BNB Chain RPC calls to four providers at 1.97 s, before Aster's own market feeds open at 3.24 s. One provider, bscrpc.com, answers with HTTP 401 (not authorised) in the capture and in a timed load. The timed loads add that NodeReal rejects some calls with HTTP 429 (too many requests), which our repeated test loads may have caused. The order does not prove the feeds wait for the lookups.
- Gap observed
- 2.1 s for the SPACE ID name lookup
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Run wallet, name and chain lookups after the trading screen is shown, or only when a wallet is connected.
- Where
- Wallet and chain provider start-up.
- Verify
- DevTools → Network: no RPC or space.id request before the first price paint.
- Evidence
- 1 October capture: Aster's feeds (fstream, sstream) are created at 3.24 s and complete their handshakes at 4.00 s (0.75 s each); the Binance stream opened at 2.13 s needs 1.7 s to connect. The price shows at 3.43 s, before any Aster feed is connected, so the first price comes from another source.
- Gap observed
- 0.76 s for Aster feed handshakes; 1.7 s for the Binance feed handshake
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Open the market-data sockets from the first script, before the UI mounts.
- Where
- Feed client start-up.
- Verify
- DevTools → Network → WS: fstream socket created within ~500 ms.
- Evidence
- 1 October timed loads, uncached and warm: /bapi/asset/v1/public/spot/prediction/events (369 KB unpacked) from 2.68 to 3.63 s and an all-asset-logo response (115 KB) from 2.66 to 3.58 s, each taking about 0.9 s, alongside the market data.
- Measured
- 0.5 MB (unpacked) of prediction-market and logo data loaded at start-up
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Load the prediction-events catalog only on the prediction pages, and asset logos only for the markets shown.
- Where
- The callers of spot/prediction/events and all-asset-logo in the app shell.
- Verify
- DevTools → Network, filter "prediction/events": no request on the perpetuals page.
- Likely saving
- Small
- Evidence
- All 10 ranked loads have the chart last, and in every one the only readiness condition failing between the chart and trade-ready is an animation running in the chart panel. Recorded warm load: chart at 4.47 s, trade-ready at 5.18 s, all 7 samples in between.
- Gap observed
- 0.71 s between the chart having its data and trade-ready, in the recorded 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.
- Likely saving
- Up to ~0.7 s
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.