#ASKTHEINDUSTRY 02: What is RAIL and why do you feel it‘s a game changer?

It was December 5, 2015 when I first watched Paul Irish introduce the audience of the annual Google I/O conference to a new performance model the Chrome Dev Team had invented. I gotta say, it was a game changer for me. I always thought there was more to performance than simple computational speed and have been deeply interested by the studies on perceived performance. And that was finally it. A practical, proven method to make sure the experience you’re building feels absolutely great.

I always thought there was more to performance than simple computational speed.

RAIL is actually an acronym that stands for Response Animation Idle Load, and it’s goal is to bring the user at the center of the performance dialogue: what is really important for the person interacting with the app?

According to this model, when you look at the problem from the user’s perspective, four measures become relevant:

• The Response time, meaning how fast the app responds to an interaction (e.g — the press of a button)
• The Animation smoothness, meaning how pleasant an animation can be experienced (e.g — smooth scrolling)
• The Idle time, meaning how quickly the app can recover from an idling state and start being interactive again
• The Load time, meaning how soon it can boot up

What’s even cooler about RAIL is that it gives developers a performance budget to operate in. In order for an app to perform optimally, in fact, it should:

• Load in under 1000ms
• Respond to interactions in under 100ms
• Animate or scroll at 60fps, meaning prepare frames in under 16ms
• Recover from an Idle state in under 50ms

RAIL gives developers clear directions on what to measure and why.

As I argued in the past, when approaching performance, you need to start with profiling. And there’s nothing more difficult than profiling an app when you don’t know where to begin. This model helps us not only to better understand what a fast experience looks like for the user, but it also gives developers clear directions on what to measure and why.

This piece is part of the #ASKTHEINDUSTRY project, a series of daily conversations with the Web Dev industry. You ask, I’ll answer, or find someone who can.