lablup / lablup/backend.ai-webui

Measure the baseline: where does the time go entering the session list?

Open
#8,983 0 comments 0 reactions 0 assignees View on GitHub
wayfinder:task
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.