In this post:
The load time for interactions in background tabs is 22x to 56x slower. This is undoubtedly tracked by Real user monitoring (RUM) solutions but is not discriminated against when defining alerts and budgets.
In a recent project, my challenge was to use available RUM (real user monitoring) metrics to define performance SLOs and error budgets. My initial thought was that the process would be simple since the historical data was available.
One special detail of the data was that it had a long tail. Imagine a distribution with an acceptable mean, a worrying p75, and a completely out-of-the-scope p90.
Outliers could not be excluded by analyzing percentiles, resulting in completely obscene performance metrics. This got me into an spiral of research and fear until I decided to analyze and sample the slow pages myself, to my surprise results were always close to the p50/p75.
Extracted from different posts:
- Background tabs set a per-frame simultaneous loading limit lower than for the foreground tabs. For example, Google Chrome limits the number of resources fetched to six when the tab is in the focus and to three when in the background per server/proxy. What it means is that only a limited number of requests from the browser are permitted to go to the network stack in parallel.
- Background tabs are also restricted to CPU access. Google Chrome limits timers in the background to run only once per second. In addition, Chrome will delay timers to limit average CPU load to 1% of the processor core when running in background.
- Load time difference when running in background
- median load time for background interactions was 24x worse,
- 90th percentile was 22 times slower,
- 99th percentile loaded 56 times slower