Relate browser, API and database timings correctly

A slow screen does not establish where time is being lost. A focused investigation needs development and operations to use the same task, the same request and clearly named measurement boundaries.

The following example is entirely hypothetical. Identifier req-17, all timings and the query structure are invented. No customer system was measured.

Define a concrete request

Here, a portal loads an order list with 20 rows. These assumed measurements belong to the request:

Database time is contained in server time, which is contained in the resource fetch. Adding the values counts contained time repeatedly. For parallel calls, their summed durations can also exceed elapsed time.

Absolute browser and server start timestamps cannot simply be subtracted without a suitable time basis. Use defined durations and a traceable association with the same request.

Investigate the conspicuous part

The invented flow makes 21 database calls: a list query followed by a detail query for each row. This makes repeated data access a specific point to investigate. A high query count alone would not prove that structure; here it is an explicit part of the example.

Examine which information the view actually needs. A bounded combined fetch may be one possible change. It must return the same permitted records. Fetching all data in one enormous query does not follow from this.

The browser value in the table ends when the resource is received. It does not establish that the view is usable then. If it remains blocked, processing, rendering and other resources need separate consideration.

Check a change under comparable conditions

Record the software version, task, data volume and filters, as well as permission scope. Concurrent load and cache state also belong in the record. An empty cache and a populated one can produce different results.

Repeat the relevant flow before and after the change under suitable conditions. Check the result and access boundaries alongside time. One unusually fast request is insufficient evidence of a general improvement.

Technical metrics should have controlled access; customer content is unnecessary for this note. The investigation should produce a justified next change with a defined scope, rather than a blanket judgement about the speed of the entire application.

Sources

• MDN — Server timing

• MDN — PerformanceResourceTiming: responseEnd

• Microsoft — Chatty I/O antipattern