Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
TTI and RAIL

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.