- Evidence
- 1 October capture: book at 3.00 s, chart at 4.95 s. In the warm campaign loads the chart is last (median 3.2 s against 1.4–1.6 s for price and book, order form 3.1 s). All 10 timed loads send three requests to www.binance.com/fapi/v1/continuousKlines that are answered with HTTP 400 (bad request). In one load: the first runs 2.31–2.99 s and fails, then Pacifica's own api.pacifica.fi/api/v1/kline runs 2.99–3.49 s and succeeds, then a second Binance request fails (3.50–3.73 s), a second Pacifica kline request succeeds in 4 ms, a third Binance request fails (3.75–3.98 s), and the chart is drawn at 4.04 s. The 3 October recording shows the same three failures, the last one ending 0.5 s before the chart is ready. The order suggests the chart tries Binance first and falls back to its own data; the captures do not prove the dependency.
- Gap observed
- 2.0 s between the order book and the chart
- Holds back
- Chart (median 3.2 s in the timed loads).
- Fix
- Stop the three failing continuousKlines requests to Binance, or fix their parameters, and request api.pacifica.fi/api/v1/kline at start-up with the other market data. Preload the chart library.
- Where
- Chart datafeed: the code that asks www.binance.com for candles before api.pacifica.fi.
- Verify
- DevTools → Network, filter "status-code:400": none; filter "kline": the first request starts before 1 s.
Pacifica: 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.6 s (median of 5 loads), 8 of 27 perpetual trading screens, possible rank 6 to 10; after an uncached reload 4.7 s.
The largest bottleneck: The chart is drawn 2.0 s after the order book; three candle requests to Binance fail first. First change to try: Stop the three failing continuousKlines requests to Binance, or fix their parameters, and request api.pacifica.fi/api/v1/kline at start-up with the other market data. Preload the chart library.
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.6 s, range 3.5 s–4.0 s; loads: 4.0 s, 3.5 s, 3.5 s, 3.6 s, 3.6 s |
| Uncached reload | median 4.7 s, range 4.1 s–5.0 s; loads: 5.0 s, 4.7 s, 4.7 s, 4.8 s, 4.1 s |
| Standing | 8 of 27 by median; possible rank 6 to 10. 1.1 s behind the fastest, Thalex (2.4 s): 1.5 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 s
Account panel1.4 s
Price1.4 s +0.0 s
Order book1.6 s +0.1 s
Order form3.1 s +1.5 s
Chart3.2 s +0.1 s
Trade-ready3.6 s +0.4 s settling
Stack
Next.js on Vercel; TradingView chart library (library.js); Privy wallet and WalletConnect.
Delivery
HTML from Vercel marked no-store, so never cached; app chunks immutable for a year; market data from api.pacifica.fi and the feed ws.pacifica.fi. The lightest page in this test: 1.3 MB transferred.
| Host | Role | CDN edge seen | Connect | Response |
|---|---|---|---|---|
| app.pacifica.fi | page | — | 13 ms | 51 ms |
| api.pacifica.fi | market data | CloudFront Amsterdam | 12 ms | 10 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.03 s | HTML arrives. |
| 0.22–0.68 s | Script chunks (the largest about 220 KB unpacked). |
| 0.68 s | First paint. |
| 2.37 s | Header and price show, before the feed is opened. |
| 2.75 s | The live feed opens, after the price is already on screen; handshake at 3.52 s; first message at 3.75 s. |
| 3.00 s | Order book shows. |
| 4.80–5.63 s | An api.pacifica.fi request takes 0.83 s. |
| 4.95 s | Chart drawn, 2.0 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.2 s | HTML arrives |
| 0.7 s | First market-data request |
| 1.6 s | Price ready |
| 1.6 s | positions ready |
| 1.6 s | Account panel ready |
| 1.8 s | Order book ready |
| 2.2 s | First frame sent on a live feed |
| 2.5 s | First frame received on a live feed |
| 3.3 s | Order form ready |
| 3.4 s | Chart ready |
| 3.7 s | Trade-ready |
318 requests before trade-ready; 9 long main-thread tasks (over 50 ms) before trade-ready, longest 105 ms; 83 script requests before the first panel; 0 requests over HTTP/1.1.
Request waterfalldiagnostic capture 1 October, uncached
66 of the 135 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.
PageScriptFont, media, other fileData requestImagewaiting for the serverdownloading
Bottlenecks and fixes, largest firstdiagnostic capture 1 October, uncached
- Evidence
- 1 October capture: socket to ws.pacifica.fi created at 2.75 s, connected at 3.52 s, first message at 3.75 s. The price (2.37 s) and the book (3.00 s) are on screen before that, so they come from REST. The timed loads show how: api.pacifica.fi/api/v1/book is requested four times before the book shows (at 1.12, 1.44, 2.11 and 2.12 s, with the book at 2.84 s).
- Gap observed
- 0.769 s from creating the feed socket to its handshake
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Open ws.pacifica.fi from the first script and take the book from its snapshot, in place of four /api/v1/book requests.
- Where
- Feed client start-up; the code that polls /api/v1/book.
- Verify
- DevTools → Network → WS: socket created before 0.5 s; filter "api/v1/book": at most one request.
- Evidence
- All 5 warm and all 5 uncached campaign loads: in the 0.37 to 0.47 s (warm) and 0.41 to 0.51 s (uncached) before trade-ready, counted from the moment the page's main parts are in place, the chart panel still has a running animation. In some loads the chart passes its own check a little later, so the wait after the chart is shorter: in the recorded load, chart at 3.42 s and trade-ready at 3.72 s, 0.30 s.
- Gap observed
- 0.37 to 0.47 s before trade-ready in the five warm loads, counted from when the main parts are in place; 0.30 s after the chart 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.3 s
- Evidence
- Campaign, uncached: the order form is last alone in 2 of 5 loads and tied with the chart in the other 3 (medians: order form 4.4 s, chart 4.2 s, book 1.9 s, price 1.7 s). Warm: order form 3.1 s, chart 3.2 s. So the order form is ready 1.5 s (warm) to 2.5–2.7 s (uncached) after the price and book. The captures do not show what it waits for.
- Gap observed
- 2.5 s between the book median and the order-form median on uncached loads (two separate medians)
- Holds back
- The order form (median 4.4 s on uncached loads).
- Fix
- Find what the order form waits for after price and book are shown (wallet or account state is the usual candidate) and show the form before that arrives.
- Where
- Order-form component and its start-up dependencies.
- Verify
- DevTools → Performance: the order form paints within 0.5 s of the order book.
- Likely saving
- Unknown; the order form is as late as the chart
- Evidence
- 1 October capture: cumulative layout shift 0.139 (Google's "good" limit is 0.1) and 16 long tasks totalling 1.6 s. 3 October recorded warm load: 98 forced layout recalculations costing 108 ms.
- Measured
- cumulative layout shift 0.139; 98 forced layout recalculations (108 ms)
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Find the elements that move with DevTools → Performance → Layout shifts and reserve their space; batch the DOM reads and writes that force layout.
- Where
- The trade page layout around the chart and panels.
- Verify
- Lighthouse or DevTools: cumulative layout shift under 0.1; no "forced reflow" warnings in the Performance panel.
- Likely saving
- Not measured
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.