- Evidence
- Price shows at 1.21 s; the first candle requests start at 1.95 s and the chart is drawn at 2.22 s. In the campaign the chart is the last panel in all five warm loads, at a median 2.07 s against 1.26 s for the price. An earlier timed load, which keeps the addresses, names the requests: gateway.architect.exchange/api/candles and /api/bbo-candles, each sent twice about 0.3 s apart, the first pair 1.1 s after the price.
- Gap observed
- 0.74 s between the first price and the first candle request
- Holds back
- Chart (median 2.1 s in the timed loads).
- Fix
- Request /api/candles and /api/bbo-candles together with the first market-data requests, not after the chart library has loaded, and send each once.
- Where
- Chart loader start-up; the calls to gateway.architect.exchange.
- Verify
- DevTools → Network, filter "candles": one request per address, starting within 100 ms of the first ticker request.
Architect: 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 2.8 s (median of 5 loads), 3 of 27 perpetual trading screens, possible rank 2 to 4; after an uncached reload 3.0 s.
The largest bottleneck: Candle history is requested 0.7 s after the first panel shows. First change to try: Request /api/candles and /api/bbo-candles together with the first market-data requests, not after the chart library has loaded, and send each once.
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 2.8 s, range 2.8 s–3.0 s; loads: 2.9 s, 3.0 s, 2.8 s, 2.8 s, 2.8 s |
| Uncached reload | median 3.0 s, range 2.9 s–3.1 s; loads: 3.1 s, 3.0 s, 2.9 s, 3.1 s, 3.0 s |
| Standing | 3 of 27 by median; possible rank 2 to 4. 0.3 s behind the fastest, Thalex (2.4 s): 1.1 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 | loaded behind a pop-up that appears on every load; measured on a stock perpetual (SPCX), not on BTC |
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 s
Price1.3 s
Order form1.3 s +0.0 s
Account panel1.3 s +0.0 s
Order book1.4 s +0.2 s
Recent trades1.5 s +0.1 s
Chart2.1 s +0.6 s
Trade-ready2.8 s +0.7 s settling
Stack
Single-page app from app.architect.exchange, loaded as 75 scripts and 52 stylesheets. The recording does not identify the framework.
Delivery
App files from app.architect.exchange over HTTP/3; on this warm reload 110 of its 124 requests were answered "not modified" (55 KB transferred in all), so the files are re-checked one by one, not re-downloaded. 21 requests use HTTP/1.1 (364 KB); their host name was masked in the recording.
| Host | Role | CDN edge seen | Connect | Response |
|---|---|---|---|---|
| app.architect.exchange | page | Cloudflare Amsterdam | 14 ms | 40 ms |
| api.architect.exchange | market data | — | — ms | — 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 orderrecorded warm reload 3 October
From one warm reload recorded with Chrome's performance trace on 3 October 2026. Recording slows the page, so read the order and the gaps, not the totals. Some host names were masked when the recording was saved.
| When | What |
|---|---|
| 0.03 s | HTML arrives. |
| 0.70 s | A 110 KB data response over HTTP/1.1, the largest before the first panel. |
| 1.13 s | First frame sent on a live feed; first one received at 1.19 s. |
| 1.21 s | Price, order form and positions show. |
| 1.51 s | Order book and recent trades show. |
| 1.95 s | Candle history requested: two requests, 113 KB together; two more at 2.09 s. |
| 2.22 s | Chart drawn. |
| 2.96 s | Trade-ready in this load, 0.74 s after the chart. |
Request waterfallrecorded warm reload 3 October
63 of the 158 requests (the page itself, the longest and the largest) started before trade-ready in the warm reload recorded on 3 October, 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 requestScriptStylesheetwaiting for the serverdownloading
Bottlenecks and fixes, largest firstrecorded warm reload 3 October
- Evidence
- In this load the chart is drawn at 2.22 s and trade-ready follows at 2.96 s. All 10 campaign loads show the same: the only readiness condition failing between the chart and trade-ready is an animation running in the chart panel (6 animated elements in the recorded load); the median wait inside the warm loads is 0.75 s.
- Gap observed
- 0.74 s between the chart 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.
- Evidence
- All 21 market-data requests in this load, including the four candle requests, use HTTP/1.1, while the app files use HTTP/3. HTTP/1.1 allows about six requests at a time per host, and each connection carries one request at a time.
- Measured
- 21 market-data requests over HTTP/1.1, including four candle requests
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Serve the market-data API over HTTP/2 or HTTP/3.
- Where
- The market-data host (gateway.architect.exchange in the timed loads) and its load balancer or CDN.
- Verify
- DevTools → Network, Protocol column: h2 or h3 on the ticker, trades and candle requests.
- Evidence
- Of 75 script requests, 34 start before the price shows at 1.21 s. Six main-thread tasks over 50 ms total 0.5 s; the longest, 136 ms, starts at 1.71 s, between the order book and the chart. The largest scripts by name: useDefaultMarket-SH9dqiiQ.js (0.6 MB unpacked), index.esm-BKU3R5c4.js (0.5 MB), Screen-Bkf6U8xB.js (0.3 MB) and useOrderbook-B9MfrtZy.js (0.2 MB).
- Gap observed
- 0.5 s of main-thread time across six long tasks
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Combine the start-up chunks the trading screen needs into a few files, and load the rest after the first price paint.
- Where
- Bundler chunking for the trading route.
- Verify
- DevTools → Network: script requests before the first price paint.
- Evidence
- Recorded warm load: of 124 requests to app.architect.exchange, 110 are answered HTTP 304 (not modified). Nothing is downloaded again, but each file costs a round trip before it can be used, although the file names of app chunks carry a content hash.
- Measured
- 110 of 124 app requests answered "not modified" on a warm reload
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Serve the hashed app files with cache-control: max-age=31536000, immutable, so the browser uses them without asking.
- Where
- Cache headers for the static files of app.architect.exchange.
- Verify
- DevTools → Network on a normal reload: app files show "(disk cache)" or "(memory cache)", not 304.
- Likely saving
- Unknown: 110 fewer round trips on a warm reload
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.