lablup / lablup/backend.ai-webui
Measure the baseline: where does the time go entering the session list?
- Dominant language
- TypeScript
- Stars
- 133
- Forks
- 81
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 344
Description
## Question
Nothing about "reduce time to first data" is decidable without knowing where the time currently goes. There is no measurement in the tree today (`react/src/reportWebVitals.ts` exists but is never called).
Instrument and record, for **in-app navigation into the session list** (sider click from another page, already logged in, client connected):
1. nav click → route commit
1. route commit → `ComputeSessionListPageQuery` request leaving the network layer
1. request sent → response received
1. response received → first row painted
Then repeat for a **cold entry** (direct URL load / reload on `/session`), separately recording the `backend-ai-connected` gate in `RelayEnvironment.ts` so the two paths are not conflated.
Also record how the five sibling count queries (`all` / `interactive` / `inference` / `batch` / `system`, all inside the same query document) and the inner Suspense boundaries contribute.
**Deliverable**: a findings note with concrete numbers per segment, a statement of which segment dominates, and the measurement method written down well enough for the prototype ticket to re-run it identically. If the dominant segment turns out **not** to be the render→fetch waterfall, say so plainly — that reshapes the rest of the map.
Method is the implementer's call (Playwright + `performance` marks against a live dev server is the obvious one; `webui-connection-info` skill has the endpoint/credentials). Do not change production code to get the numbers unless the instrumentation is trivially removable.
Map: FR-3636.
----
## Amendment (2026-08-23, after FR-3639 / #8985 resolved)
The canonical-pattern research changed what this measurement has to establish. Two additions, both load-bearing for the map's go/no-go.
**1. Warm and cold must be reported separately, and the cold path is the one that matters.** FR-3639 measured, against `@remix-run/router` 1.23.3, that a route with a loader commits at **+17 microtasks** while a route with no loader commits at **+0** — and that a synchronous loader and an `async` loader commit at the same 17, so `loadQuery()`'s synchronicity buys nothing at the router level. On a warm in-app navigation the only work a loader skips is **one React render pass in the same macrotask** — zero frames.
But three suspending call sites sit **above** the pilot's own Suspense boundary: `ProjectScopeLayout.tsx:61` (`useUrlProjectValidity` → `useAccessibleProjects` → `useLazyLoadQuery`), `MainLayout.tsx:301` (`RouteAccessBreadcrumbGate` → `useCurrentUserProjectRoles`), and `routes.tsx:307,310` (`useSuspendedBackendaiClient`, `useCurrentProjectValue`). On a cold entry into the project scope the page cannot render — and so cannot issue its query — until those resolve, whereas a loader-started `loadQuery` runs in parallel with them.
So measure and report as two distinct numbers:
- **Warm**: sider click from another page inside the same project. Expected saving ≈ one render pass. If that is what you measure, say so — it is a real answer.
- **Cold**: first entry into the project scope (fresh load, or a project switch that invalidates the ancestor queries). Record how long the three ancestor queries above take, because _that_ is the upper bound on what a loader could save here.
State plainly which of the two dominates the user-visible complaint. If the warm path is what users actually feel and it is already one render pass, the map's premise is in trouble and the owner should hear it from this ticket, not from the prototype.
**2. There is no baseline instrumentation problem to solve for loaders.** `grep -cE '\bloader:' react/src/routes.tsx` = 0 today, so every navigation short-circuits at `matchesToLoad.length === 0`. The current numbers are a clean no-loader baseline; nothing needs disabling first.
Method note carried from FR-3639: measure in a **production build**. Under `React.StrictMode` (`react/src/index.tsx:84-91`) the dev double-invoke changes the fetch pattern.
JIRA Issue: FR-3637
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading react/src/reportWebVitals.ts, RelayEnvironment.ts, ProjectScopeLayout.tsx:61, MainLayout.tsx:301, routes.tsx:307,310, and react/src/index.tsx:84-91. Measure warm and cold entry separately in a production build, including ancestor queries, sibling count queries, Suspense boundaries, and the backend-ai-connected gate. Done means a reproducible findings note with concrete segment timings, the dominant path, and whether the loader premise holds.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- playwright, react, typescript
- Domain
- frontend, performance, testing
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 52/100