Client Runtime Constraint
The properties of the browser or device you do not control — CPU, network, version, extensions — which make the client a distributed system component rather than a rendering surface.
Server-side components run on hardware you chose, on a network you provisioned, at a version you deployed. None of that holds on the client.
The device may be a five-year-old mid-range phone with a fraction of the CPU of a developer's laptop. The network may be a congested mobile connection with three hundred milliseconds of latency and periodic loss. The runtime may be a browser version two years old, with extensions injecting scripts and a content blocker removing requests. The user may have three hundred tabs open and no memory headroom.
Treating the client as a distributed component follows from this: it has its own state that can diverge, its own cache with its own invalidation problem, its own failure modes, and a deployment you cannot force. The consequences are ordinary distributed-systems ones — retries need idempotency, optimistic updates need reconciliation, and a client running last month's code will call your API tomorrow.
The practical discipline is to test on the constraint rather than on the development machine: a throttled CPU and a throttled network, on the oldest supported browser. Performance work done without that measures the wrong system.