RAIL encouraged loading a site in under 1000ms on cable and (not well documented) between 3000ms and 5000ms on 3G. This loosely correlates to Google's research that 53% of mobile users will abandon a site if it doesn't load in 3s. So 5s is the headroom we give you for loading and becoming interactive so a user can realistically tap on a part of your user interface and have something useful happen. Loading is more nuanced than we as web developers once thought however.
It's is a pretty broad term and we don'the think it's enough for the page to "look" done. It should be engagable.
There are many different "key moments" in loading a page however that offer us more nuance.
- “is it happening?” (i.e. time to first paint)
- “is it useful?” (i.e. time to first meaningful paint)
- “is it usable?” (i.e. time to stable layout / time to interactive)
What we think a user really cares about is when is the page done "enough" that they can start interacting with it (Time-to-interactive). So, scrolling, taps on icons, reading when the layout has stabilised. We think TTI represents a good enough moment when there isn't heavy main thread contention that would prevent interactions from being successful.
So back to the L in RAIL. We say you should aim for a TTI of <5000ms on average hardware over 3G - this can be accomplished if you put the work in. Just take a look at HNPWA.com for some examples with frameworks. Your first meaningful paint will be a moment that comes before this and your moment of load completion may be a little beyond TTI, but ultimately we're trying to get folks caring more about a more granular view of loading than just getting pixels on the screen fast.