Time to Interactive Gap
The interval between a page appearing complete and actually responding to input, during which the user's taps do nothing.
Server rendering produces markup quickly, so the page looks ready. It is not: the JavaScript must download, parse, execute and attach behaviour before anything responds. The interval between those two moments is the gap, and it is the worst kind of performance problem because the interface actively invites interaction it cannot service.
Users do not wait — they tap again, then a third time, and the queued events fire at once when hydration completes, producing three navigations or a duplicated submission.
The gap widens with bundle size and narrows with CPU speed, so it is far worse on the devices most likely to be used by the customers you have not optimised for.
The mitigations differ in ambition. Reducing bundle size helps everything. Splitting by route ships less on first load. Partial or selective hydration attaches behaviour only to interactive regions, leaving static content as markup — which is the structural fix. And on the pure end, shipping no framework JavaScript for routes with no interactivity removes the gap entirely rather than shortening it.