Performance Goals That Match Real Devices
Front-end performance work only pays off when targets reflect how real users experience a site. The common starting points are interaction latency and rendering smoothness: an interface should respond to input within 100ms, and each animation frame has to finish in under 16ms (roughly 60 frames per second) so the browser can paint before the next frame is due. The RAIL model suggests yielding the main thread at least every 50ms to stay inside that response window, and Estimated Input Latency should stay below 50ms.
Those numbers are runtime targets. For loading performance, a realistic baseline is a mid-range Android phone (around $200, e.g. Moto G4) on slow 3G, emulated at 400ms round-trip time and 400kbps throughput. Against that baseline, practical goals are:
- First Input Delay under 100ms (ideally 70ms).
- Largest Contentful Paint under 2.5s.
- Time to Interactive under 5s on the first visit, under 2s on repeat visits (the latter requires a service worker).
- A critical JavaScript budget of roughly 130–170KB gzipped.
What Shapes the Budget
Two hard constraints define those targets. First, network delivery: TCP Slow Start means only the first ~14KB of HTML (around 10 packets) can arrive in the first round trip. At 400ms RTT with mobile wake-up latencies, that first round trip may be all you get within one second.
Second, hardware limits: parsing and executing JavaScript consumes CPU and memory. At the 170KB gzipped end of the recommended budget, decompressed script (roughly 0.7MB) can still take up to a second to parse and compile on a mid-range phone. Real-world bundles are far larger: the median today is roughly 452KB, up more than 50% since early 2015, which can translate to 12–20 seconds to interactive on a mid-tier phone.
The environment keeps improving, so static numbers are a moving target. Wikipedia reported that code execution for its users got about 19% faster globally in 2020. If your own metrics stay flat year over year, you are likely regressing relative to device and network improvements.
Beyond a Fixed Bundle Size
A fixed byte budget is a useful starting point, but it is not the only way to track performance. Budgets can also be defined by main-thread activity, such as time to first paint or long-task measurements that flag front-end CPU bottlenecks. Tools including Calibre, SpeedCurve and Bundlesize can enforce these budgets in a build pipeline.
Budgets also do not have to be constant. The cost of a payload rises as connection quality drops, so targets can adapt by network condition. And although HTTP/2, 5G and HTTP/3 promise faster delivery, real-world conditions — congested networks, data caps, proxy browsers, save-data mode and roaming — make pessimistic assumptions the safer engineering choice.
Emerging Markets and Feature Phones
For regions such as South East Asia, Africa and India, constraints are stricter still: fewer high-quality devices, patchy networks and pricey data. Work targeted there, guided by the PRPL-30 budget, needs to account for feature-phone limitations rather than assuming a desktop-class experience.
Finally, the industry is beginning to discuss 120fps targets as high-refresh-rate screens (for example, iPad Pro at 120Hz) spread. That is not yet a mainstream target, but it is worth tracking as rendering budgets tighten further.
