RAIL in the real world (Chrome Dev Summit 2015)

Key Takeaways

so obliging clapping a second time but I guess if you're watching this on YouTube you don't know that I just did a talk um and speaking of which I should do this bit where I explain uh rail just very quickly these are the goals of rail responding in a tenth of second animating at 60 frames a second being idle at 50 millisecond chunks and loading in under a second so my job is to talk about rail in the real world to apply rail um and I guess you know are any tips and tricks and to know about that or to answer that you have to kind of start with life in Devil um because the thing about being in Devil is that we do get to test uh Technologies just as apis are landing we're working very hard with the engineers who are working on those um and that's part and Par of what we do we sort of like the the crash test domies of the web which explains my gorgeous good looks um and we also get to test uh ideas some ideas are good some ideas are not so good but all the same we try and test them out anyway in the last year I have been testing rail amongst the other things I've been trying out um and I've been building web apps to do just that Progressive ones no less Progressive web apps awesome this is the first one um might have seen it a couple times over the last couple days um it's called voice memos the idea is it lets you record voice uh memos and you can save them to the device and it works offline and it uses index DB and es250 and stuff but you see there's all these Transitions and it's got to load quickly and and so on then there was this one which is a guitar tuner which actually will tune your guitar and this was a slightly different bet I was trying to get polymer to load uh under a second and get itself bootstrapped and the the dial is going round and that's 60 frames a second as well as processing the audio so that was a different challenge altogether and then the last one which I'm still working on is a podcast player what a handsome pair of gentlemen there with a podcast that you might want to subscribe to um again these big hero transitions uh scrolling and all that sort of stuff so the question then becomes does rail work and the immediate answer I can give you is yes it does that's the good news but like anything of this nature I think it needs a couple of tweaks and the reason I think it needs tweaks is just because it's it's a model it's a way of thinking but reality often just sort of diverges a little bit let me give you uh the first example when you hear about rail the first thing you might think is that you know everything's equally important like everything I've got these four numbers that I have to meet and it's not necessarily like that in my experience so give give you an example if you're building a Content site your profile your rail profile I guess might look more like this it's more like the classic performance profile where load is super important getting that first content on screen we don't necessarily think somebody's going to add it to the home screen or anything we just want to get something up on on screen animations are important here because the user is going to scroll almost certainly and we don't want janky scroll idle yeah you could use a bit of that if you're going to Beacon analytics type stuff back but response is doesn't really rank that high because probably it's linkto link sort of page refresh bounce around from different URLs you know it's not so uh not so heavy duty there however an app will have a different profile alt together in my view um an app is more like this because you've got these uh gestures you probably got big transitions hero transitions that kind of thing going on idle is is quite important here because you're probably going to pull data from something like index DB and you're going to want to sort it search it do that kind of stuff and you don't really want to do that in a way that gets in the users or bothers the user sorry and then load yeah it's it's there but hopefully you're using things like a service worker to really make these things fast and snappy now you could argue that you know it should be this way or the chart should look that way and f app it might look different um I think the thing I'm saying is for me they're not always just sort of four equal players the other thing that I think um It's that kind of caught me out actually as I was trying out rails I thought goodness you know there's these four independent things um you know responses they're not going to play with the animations whatever the reality is sometimes they they group together let me show you what I mean let's say we're going uh from a list View to a details view so I tap on my item in the list that's a response then is followed by a load and then we do the animation to the final state so we actually have three three rail actions going on here and that forces us into ask asking a question what is the primary action in that situation we throw it to you what would you say is the primary action hands up for response hands up for load hands up front of the animation okay it's an interesting one I think think the response is the most important one the reason I think the response is the most important one is because it's the user-driven one it's the where the thing where they tapped on something and they expect an answer back so I for me that 100 milliseconds becomes the the upper limit interestingly enough in that case the animation was the implicit response they don't always go in sort of you know they sometimes group together in a funny way I suppose um that's what happens rail headlines then don't assume the four will be equally important figure out the rail actions for your app you know it's actually really good to kind of sit down and going to go yeah that looks like a response ah that looks like they're going to group together um when they do group together figure out which one is your primary and go from there so with that what I want to do is I want to step into each of these four areas and show you how I try and get uh within those thresholds responses is up first uh Target is 100 milliseconds and for me I T try and sort of break them out into two categories the first is what I like to call Simple responses which is sort of like a state change I suppose like okay most of the time these ones are very straightforward to kind of get inside that 100 millisecond battery like tapping on a button or something like that the more complex ones and you can see another example here the response load and animation ones which really is a response I think um those become more difficult those complex ones those combination ones what I do in those situations is I take this approach first of all I will set up a timeout the idea being one of two things is going to happen I'm either going to get inside that 100 milliseconds or I'm not now if I if I in this case fail to meet the 100 millisecond window I'm going to show a spinner they like for whatever reason this is taking a long time I'm sorry maybe the disc is slow maybe I'm going into the network something like that at the same time I'm going to request the data then when the data comes back in I'm going to clear the timeout so if it's fired in under 100 milliseconds we we just clear it don't worry about it it's it was an sort of easy thing to do and I'll hide the spinner so if it has shown it's it now goes away one of those two is kind of unnecessary but they're both needed in this situation and then I can do my transition to the details view when it comes to like measuring the responses um say for example we're going to tap on the the hamburger button here to bring out the side nav the way I tend to approach measuring this um is with Dev tools and console.time so for example in the the button listener I start here with console.time which is me saying right start tracking this one thing please and then I'll do my toggle side nav and then I'll wait for the next frame so when my JavaScript is finished there'll still be Styles layout paint composite and all that kind of work that needs to happen and at the start of the next frame it's a pretty it's a pretty decent marker that says okay that previous frame is shipped we've responded to the user and so I'll just do Time end if you do take that approach and you've got say you know you can do this on desktop but you can also do it on a mobile device and here I have my uh my Android plugged in and I go to Chrome inspect and I can click on the inspect button and you see I get my little device view there which is great go to the timeline and take a recording bring out that side naav and I get my um get my details now two things here firstly in my console I see this which tells me how long it took for that to finish which was 13 milliseconds but I also get this extra Row in the timeline and now I can start correlating that piece of work with what was going on on the main thread and what was going on the compositor thread all of a sudden it becomes very easy to kind of see when things are overlapping and you know oh goodness I didn't meet that Mark and oh that's cuz there's loads of layout okay I need to figure something out so it's a very quick and easy way to start getting this data so response is um differentiate between the simple and the complex ones the complex ones should normally be raced with that sort of uh timeout and then you can just go crazy with Time and Time end to track your response times and then you can do what you you need to do with those you can also use the window. performance the user timing API as well here if you want to kind of Beacon some of that back I think next up an now I'm going to go straight to the how to win at animations bit uh because the reality is it we have 8 milliseconds here most people go I thought you said 16 and I did but that's what everybody's got and when I say everybody I mean us and the browser but the browser has overhead and it has housekeeping to do and so we get left with a window of about 8 milliseconds in which to do our work and that's not a lot of time and so the way to win is to work with the compositor and the way to win and to work with the compositor is to limit yourselves to things that can be done just with the compositor um for example um you can use transforms or opacity here so I built this site CSS trigger. comom um a while ago and it will tell you for every CSS property what it's going to trigger in the rendering pipeline I can give you the the heads up there's only two that don't trigger paint or layout and paint and those are transform and opacity for elements that have their own layer now there we go there's the transform one the way I do my animations um particularly these kind of Big Hero ones is I use a process I call Flip which I mentioned last year when I was talking about building the Chrome Dev simp site uh for the 2014 yes that one um and I've since given it a name first last invert and play it helps you remap your expensive animations to cheaper ones like this let's say want to get this purple box from the top left to the bottom right most of us I think would probably go well transition on width height left and top the downside of those is that they trigger layout and paint and they're not something you're going to be able to do at 60 frames a second typically typically you might get away with it but probably not it's definitely more challenging to build but what we do is we start by calling something like get bounding client wrecked on the start position this is the F of flip so we say where are you on screen and what are your Dimensions next and this is where any animations on whatsoever we add a class that puts it in the final position the L of flip like so we call get bounding get bounding client wrecked it's a nice rollof the tongue kind of API um we call that again to find out where it's moved to on screen now what we can do is we can apply a transform and we just move it back to the starting position as far as the user is concerned nothing changed but we know we just did it with cheap to animate properties like transform and the same is true for opacity now what we can do is we can switch on our animations and just let it play forward we just remove that transform and it goes back what we're doing here is we're most likely taking advantage of this setup where the user tapped and then we do some kind of animation and what we can do is we can take the that window of opportunity because as like you saw before it was like 13 milliseconds to do my my response work well that left me about 990 to do other things so what we're going to do is we do the first last and invert part of flip there and then we can play out nice and cheaply it works we've used it uh on the google.io website used it last year on the Chrome Dev site it's used on all three of my apps um that I built this year it's great it works there are caveats and so if you are interested in reading more about it I do have a blog post that you can grab there bitly / flip D anims um so genuinely applied to the the podcast one um let's say you're tapping on on the podcast it goes like that just backwards you know goes to the final bit and squish it back in and then you you play it forward and you get close to 60 frames a second well you actually get 60 frames a second if it goes well similarly to um the responses when you want to measure things like this you you can call console.time do all the flip stuff in this case I'm using transition so I can wait for a transition transition end and then on the end of the transition I'm just going to call console.time end and in Dev tools I'm going to see this kind of thing and again I can see a couple of red triangles just um above the main thread activity which tells me that that my frame rate did drop a little bit um but I don't think there was anything I was doing I think that was just one of those things if you don't do uh with a flip like animation it will probably be very difficult to get 60 frames a second but it's a big cheat and I love it so animate with transforms and opacity where you can flip your expensive properties over to cheap ones and be super cautious and avoid work during Scrolls in particular if you can big shout out to The Parallax massive um yeah my favorite crew uh next up Idol now our Target here as we discussed before is 50 milliseconds and the reason being that we want to be able to respond to the user quickly so if they're in the middle of something and we're doing some you know idle time they tap we want to respond so we can finish our idle time of you know up to 50 millisecs and we can still probably get something to screen quickly enough that the user feels okay about it now up to not so very long ago there wasn't a great answer here um as to like how do I actually do this because you'd be in a situation where you would have to kind of add event listeners to everything on your page and be like well the user doesn't seem to be doing anything because there's no no events firing and I don't know how long I've got but I'm going to guess so I'm going to maybe try and do it it wasn't something that we could realistically do Chrome uh currently as of chrome 47 has request idle callback which is an extremely useful API when you want to do idle work here's how it works let's say I've got some tasks at the top there and it's an empty array um and let's say it gets populated and I know how long my tasks should take maybe I've got a hundred of them and then I'm saying that each one's going to take maybe one millisecond what I do is I call request idle call back with my call back and when my call back fires it gets this deadline object and the deadline object has stuff in it one of which is that time remaining function and I can basically say this look while I have time remaining and as enough time to do a task and I have tasks to do do the task if I run out of time and I still have tasks to go I can request another idle call back the browser is in the unique position of knowing what the user is doing what's going on in the system whether the main uh thread is free and how much time it thinks you've got the schedulers inside of um Chrome and blink are very good at this so it can tell you look you've got this amount of time this would be good I wrote a post on um on Google web developers yeah web fundamentals yes the updates yeah it is um about using request idle call back so if you want to read more about it head over there the thing about idle time though is it is a bit different because most of the time we used to being like well I got an event I'm just going to do my stuff off we go but you have to think differently when it's idle time you have to think defensively because you you're kind of running against the clock it goes you got six milliseconds go and you're like hi don't know okay great and it's a different way of working it spins it on its head but it's fine you won't get preempted by the way if you go over that time it's just that the reason the browser gave you that time is because it knows what's going on if you're looking for things that you could do with idle time the basic answer is non-essential work like uh beaconing your analytics it's a good time to just kind of say look I'm not you know you tapped on that button to bring out the side of I'm not going to send the analytics right now I'll just request an idle call back and you know maybe when the animation's finished or something like that the user just like looking at the menu that's a good time to kind of process that work you have to think in small all deterministic operations rather than right I'm going to make all my dom changes now great now what you need to do say for example if you were trying to do Dom work I'd suggest you either use something like a vdom or you do something on a document fragment so you're working kind of off Dom and then in some future request animation frame or something then drop it onto the page and as I said before you want to think a bit more defensively you're kind of running against the clock a little bit load is the last of the rail and our Target here is 1 second or 1,000 milliseconds and I've added my own little caveat there for the 75th percentile which is to say most people because most of the time on 3G or 2G you're not going to achieve it straight up because the radio might be off or the user's device is just busy doing other things makes it very very difficult but if you say something like for the 75th percen it becomes a lot more uh achievable however it doesn't absent us from making good decision in the architecture of our apps uh this is how I try and approach it for something that's built with vanilla so in the case of voice memos uh inlining that initial view is is super critical uh Rob Bob Dod I nearly messed up there Bob Dod showed this yesterday where you have a skeleton and you say this is the the initial view that you need and I'm going to inline my styles for that I'm going to in this case I inline an SVG and you know so the user gets something pretty quickly on screen then we do like an async the first I'll load on some JavaScript so it's not blocking and that's going to it start the request for the the views that we're going to need in the hopefully in the order that we're going to need them in the case of the app it's actually quite straightforward for me because I know the user flow you're going to record something you're going to see its details you're probably going to go back to the list like that and I do the list you know later because I don't need it up front and then I can go go back into the details and play it and so on if I need to so there's a variant on this um which is how I work with polymer and um the way I do say so the guitar tuner uses polymer but it's all custom um elements and that I did and the way I do it again is very similar in line the Styles even for the custom uh elements that I've got in the page um I basically make it look like that so it's like everything is roughly in the right place uh in fact it's very much in the right place then with my um javascripts in place I'm going to Lazy load on my various inputs like that and they are all going to request polymer independently but the way that HTML Imports works is that you can request the same URL 30 times and it'll actually only get loaded once and then all 30 would be satisfied so it's kind of like they're all having a race to get polymer and when polymer comes back in they can all bootstrap and the app is complete and it works really well when you're doing your testing for load I cannot recommend web page test highly enough it's where I always go uh what I tend to do is I tend to switch on for mobile 3G so I feel it's quite tough um I'll do something like first and repeat View and the check boox there at the bottom is for capturing a video which is really really useful when you just want to kind of feel what it actually you know what it's like to use to to kind of make the point though about the 3G and even trying to make the right calls on the architecture I get a speed index here of of 3,43 ideally speaking I'd like to see something uh lower than that maybe maybe 3,000 maybe a little bit bit less but the reason I'm not going to get much better than that is because when I look at the request for just the index HTML which had everything in to get that initial view up um you see numbers that look like this the DNS over half a second the connection the SSL negotiation time to first B but the the content download the bit I'm actually feel like I'm in control of is very very tiny in other words there's the flame transition Don't Mind If I Do 99% connection it's like that it's like all that other stuff I don't feel like is really something I can affect and this is what it's like on first view on the left is um desktop on cable on right mobile 3G and off it goes it's pretty fast but this is the bit where we go now I'm going to bring it back to the 75% off this is how I'm going to try and win by using I did say it was a spoiler service workers yeah I'm actually going to explain the code of the service workers Jeffy did a great job with that and we've got plenty of stuff for you but the important thing is by having a service worker on my numbers for repeat views are really very very good and the reason I'm visually complete slightly after a second is because I do a nice fade in so it doesn't think I'm visually complete I could not do that I could just snap it on I don't think that's quite as nice so I take the hit on the numbers but I know I know what I'm happy with and this is what it looks like in video Ready Steady go you can't say fairer than that if a user has an app that does that they are going to be so happy um Jake built an app called SVG OMG for SVG editing and somebody remarked on Twitter they said I I just I didn't realize the web could be this fast and it's like yes it really really can and it's really nice when it is and it's perfectly possible as well so then load stuff I would say inline your app shell CSS lazy load absolutely everything else uh Bob do did a great job explaining that yesterday I'm saying the same thing today uh far future cache your JavaScript your CSS your images um this is classic page load stuff and user service worker one other thing that I've been working on which has been a sort of like uh I suppose a 20% projecti thing for me is something called Big Rig um and Dev tools is absolutely amazing and what I use on a day-to-day basis but sometimes I just want a bit of a smoke test for like rail measurements and be like is that roughly doing the right thing or maybe I'm looking at somebody else's stuff and I'm just like how much time is going into JavaScript or not and where's that which JavaScript from which domain and that's why I built Big Rig this is this is big rig you can um have a play with it yourselves um the idea of big rig is that you make a project so let's say I make one for the Chrome Dev Summit website that I you know want to track and inside the project you have actions and actions are things you're interested in they're rail actions essentially like in this case I do load response and animation so let's say I want to do the I don't know the initial homepage load or something like that and it creates it for me and then you go in it says upload a trace for this action and you're like what uh traces are Chrome's internal way of measuring performance timelines are traces effectively and you can get a timeline file from webpage test so here I've got Chrome Dev on an xus 5 select that and again it's mobile 3G why not and under the Chrome settings you can check a box that says capture a Dev tools timeline turns out really quite useful that then off we go we start the test and it takes a while when it comes back in you see there's this link here in the corner says timeline so you click it and then you go back to Big Rig and you give big rig the file like so you do the dance while you wait and eventually it will say this this is what you spent your time doing this is the PA HTML this was the JavaScript this was the Styles the layout the paint the composite and you get that number those numbers immediately and you can also go into the extended information where it'll tell you by domain where the JavaScript was coming from so 4,9 milliseconds on the site itself and you start to get this over time you can actually build up a picture of you know how am I sort of spending my time across all these rail actions so it's good for responses um you know like I'm going to tap on a thing what it does is if you give it a a timeline file with console.time and console. end it will use those as the labels and it'll go oh you got one there okay that's looks like a response that one looks like an animation and so on say it's good for animations you know you can it'll give you those in frames per second and again you can start to see how you're doing there this one's an actual real one uh Paul kinan uses big rig to monitor his site and you can see the on the far left hand side there's a big block of green and big block of yellow and the big block of green he was like why have I got a big block of green and we went to look at his site and it happened that he'd forgotten to resize down an image and it caught it for him and he fixed it and you can see it's sort of settled down a lot for him um if you you can post a um the timeline file the trace file uh to an endpoint and it'll process it and if you do that with the hook you can see which web page test result it was and you can also see the get commit as well so you can be like I had a regression why kind of useful and in his case in case you're curious that's what the blame game looks like for him I've suggested that he might want to Lazy load his comments makes it quite easy to do that kind of stuff so if you're interested um big rig is on the Google Chrome GitHub org some people don't want a UI though and that's cool um so there's an alternative which is the um globally installable big rig um similar kind of deal actually just on your command line where you can go big rig with a file and it's the same timeline file from before and I'm just going to ask it to pretty print the results because otherwise it'll return just adjacent to you and you can see here again it's the same kind of details but if you want to you know integrate into an existing flow you can do that as well and that is under node big rig or you can just do npm install and then there's this one as well which is another tool that I've been working on these are all as I said these is kind of TR try and make rail measurement just a bit easier if you want to do it outside of Dev tools and there's loads to do and there's loads I want to do uh one of the things is like it's hard to do a scroll test so I've got the big rig Runner and you can give it the site that you're interested in tracking or just getting a scroll test from I'm telling it to look for the body element and I'm going to pipe it through to Big Rig you see Chrome's opened in the background and it just does an automatic scroll test without me doing anything and at the end of the scroll test it it spits out the results which big rig then pauses and says well that was a smooth scroll and an animation and it was 54 frames a second and it tells me what I was doing per frame kind of useful if you just want to as I say uh do a smoke test and go how am I actually doing okay I have not so much time so we'll come back into the final thoughts on rail in the real world Rail and those thresholds they genuinely work if you build a site or an app against those rail thresholds you'll find that it feels just right it feels Snappy it's well worth dissecting your site into those rail components and um trying to instrument your code with Time and Time end and so forth and you could stick to the limits they are very very good they will serve you well and as always test and use web page test use Dev tools and if you try big rig do let me know and with that I will say thank you very much