paul kinlan: hi everyone. welcome to mobileweb thursdays. i'm paul kinlan. jake archibald: and i'mjake archibald. thank you for tuning in. paul kinlan: yeah. that's right, actually. that was actually pretty good. jake archibald: yeah.
i'm getting the hangof this tv thing. paul kinlan: he's beenplanning that for about two hours now. jake archibald: oh,it's very good. jake archibald: i'm veryhappy with myself. so we're also known asthe chuckle brothers. and today we're going to betalking about mobile web performance. right?
jake archibald: yes. paul kinlan: so shallwe get started? why not? one of the things that reallybugs me when people talk about mobile performance is they'reeither treating mobiles as this special thing-- and mobiles really aren'tthat special, right? ok, they're touch. but touch isn't just mobile.
we've got chromebookpixel here. that's got touch. these windows devicesare the same. paul kinlan: is that touch? jake archibald: no. it is a mac. it's not touch. you could say, oh,cellular data. that's mobile.
but it's not. because once again, people runtheir laptops off mifis, things like that. and sometimes your phone isquite often on wifi data. in fact, some small deviceslike your nexus 7s or your ipod touches, they don't havecellular data on all models of them do. mobiles are really just smallerand less power than a main desktop machine.
jake archibald: wouldn'tyou say? it's kind of interesting. i think what's starting to leadus to what we're trying to talk about today is thatwe were at educomm-- it was educomm, wasn't it?-- andi think facebook said that they noticed a significant dropoff of interaction based off the change of frame ratebetween 60 frames a second down to 30 frames a second. and the slower and the jankierthe experience was actually
inside the application, the lessengagement that they got, which got us thinking about-- well, we've been doing it for alittle while now-- but we're starting to push more aboutthis jank-free-- i've got to say that correctly,because i can never say that quite right-- experience where you'llget 60 frames a second experience on mobile. and a lot of peoplethink you can't.
we think you can. and i think we're going to tryand show you today some of the gotchas, the how-tos,the wherefores. what else can we say? jake archibald: well, if youserve just a lump of html to a phone, it works. it works quite well, andit runs quite fast. so saying how to make somethingfaster in mobile isn't really the rightthing to say.
we're saying how not to make itslow, because it's fast to begin with. as developers, we're theones who make it slow. so i don't swear verymuch as a person. is that fair to say? paul kinlan: no. you do. jake archibald: ok. maybe i do.
but i've been told that-- paul kinlan: he's worried,by the way. jake archibald: --i'm reallynot allowed to. and when you're told you'renot allowed-- paul kinlan: beep. jake archibald: --my brain'slike the back of a teenager's math book. it's absolutely disgustingright now. and when you're told youare one syllable away
from losing your job-- so you're going tohelp, right? as i say, we've got thispreemptive beep machine. jake archibald: so you'regoing to beep. paul kinlan: i'mgoing to beep. we haven't got a proper one,so i have to go beep. i get a twitch in my eyewhen i'm about-- paul kinlan: i'vebeen watching. jake archibald: --todrop a word bomb.
so watch out for that. paul kinlan: on that note-- jake archibald: actually,shut the fridge door. see? i thought i would letyou in there. that was a test. i wasn't actuallygoing to swear. paul kinlan: dude, i know. jake archibald: butyou missed.
i thought you were goingto be here for me. paul kinlan: i'm going to bepreemptive when i know you are going to do it. and i knew you weren'tgoing to do it, so i wasn't going to do it. jake archibald: well,we'll see. we'll see if i've got a jobat the end of this. let's take a lookat an example. all that stuff i was sayingbefore about mobiles not being
special, we're going to lookat a case where they are special just to provemyself wrong. so if we can take a look atwhat's on my desktop machine and look at the firstdemo we have here-- paul kinlan: can i just saybefore we start, we have a moderator where people canactually ask questions. we should have the linkon the screen somewhere at the bottom. yeah.
so you can go and ask usquestions, and we'll answer them at the end of the show. jake archibald: let's do that. paul kinlan: so shall we getdoing what you're going to do? so i'm in jsbin forour first demo. so what we have hereis a series of devs all of the same class. it's a really dumband simple demo. and the javascript here, allthat's going to do is it's
going to loop through allof those elements. it's going to givethem a hue value. it's going to cycle through all360 and create this kind of rainbow effect here. now when you click on them usingclicklistener here, it's going to swap that to theopposite side of the hue. so what we get is click,click, click, and it will go back. so that's how it workson desktop.
it's really fast. but let's have a look athow it works on mobile. so if we can switch tothe mobile view-- this is running ona nexus 7, but it runs the same on phones. so here it is. as you can see, it'sscrolling. we get pinch zoom. that's fine.
and i tap on it, andit changes color. but it's really, really slow. and i was saying before thatmobiles are not as fast as desktop machines, but they'renot that slow. painting a rectangle differentcolors is not really a task any device shouldstruggle with so what's happening here isclick events actually run with a 300 milliseconddelay on mobile. now i'll show you whythat happens.
if we have a look atgoogle moderator-- google moderator is a site thatisn't really optimized well for mobile, so no pointsto us there for that-- apple came up with thisinteraction where they would start with the screenzoomed out. and if you wanted to zoom in toa part of it, you could use a pinch zoom, but youcould also do this. you could double-tap. you could double-tap it.
it zooms in. and all of the others mobiledevices have copied that. and this is our problem. because how do we know if you'regoing to double-tap when you tap? well, the only way we can dothat is by just having a little wait and seeingwhat you do next. and if you don't tap again,that's not a double-tap. it's said that if you wantsomething to seem instant it
has to happen within 100milliseconds of the user clicking the thing. and with 300 milliseconds addedto start of that, you're three times over budgetbefore you've run any javascript at all. but we can use javascriptto work around that. paul kinlan: i know some of theguys who are working on the touch side of things aretrying to improve this even for normal viewports.
because if you can detect thatyou're at full zoom, for instance, then you're notgoing to try and do the double-tap in. jake archibald: yep. paul kinlan: and there'squestions about whether we can optimize that experience so thatwe don't have to actually have a viewport if you don'twant to have a viewport, and all this type stuff. and if there's anything else youwant to spoil ahead of me
getting around to it-- paul kinlan: am ispoiling things? jake archibald: --that's fine. tell you what-- paul kinlan: you've got allthe lines down here. jake archibald: --i could leaveif you just want to read from my notes. paul kinlan: well, there'ssomething about the ft [inaudible].
jake archibald: no, don'ttalk about the ft. paul kinlan: you toldme to read ahead. jake archibald: you nearlymade me do one of those job-ending noises. ok. actually, let's take a look atthe desktop machine, and i can show the code for this one. it's number three. so this code looks exactly--
paul kinlan: that'sa nice code. jake archibald: --the same. it's a lovely code. it's my favorite. i spent at least a few minuteswriting it yesterday. so here's the difference. this one isn't click. it's touchend. so it's using a touch event.
it doesn't work onthe desktop. you would have to add a clickevent in as well. if we can switch to the phone,you can see the difference it makes here. so i can scroll aroundthe page. and if i tap, it changes. and as you see, it's happeninginstantly. so we've got a real performanceboost out of that. this is on chrome for android.
we'll take a look atthe same thing running in another browser. i should point out thisis not my nexus. i'm not a fitness fanatic, andi wasn't planning on having a nipple slip this early onin the presentation. paul kinlan: it's my nexus. jake archibald: isthat your nexus? paul kinlan: it's my test one. jake archibald: i'm just goingto grab him by the nipple and
fling him away. excellent. so let's go into firefox, andlet's have a look at the same url and site. in fact, do i haveit prepared? oh, that's lovely. so this is the same thing. we're using the touch event. and so if i tap, it works.
but as i scroll, when i letgo it still getting that touch end event. and this is not firefoxdoing it wrong. in fact, the default old androidbrowser does the same. ios safari does the same. in fact, chrome's kind of theone doing it different. and it's not goingagainst the spec. it's just unspeced behavior. it doesn't say whether a touchsequence should be cancelled
if a scroll starts. paul kinlan: does it happenin safari as well? jake archibald: yes,in safari on ios. paul kinlan: does it matchchrome's behavior, or does it match firefox's? jake archibald: it matchesfirefox's behavior. paul kinlan: it's actuallysomething that we're doing inside the browser ourselves. chrome is the exception.
by doing what i wouldsay would be to the right thing to do-- once you've started doing ascroll, then i don't want to hear about the touch, becausethe browser's taken over handling touch events. but yeah, no one's actuallybreaking the spec. it's unspecified behavior. we do have a fix for thisin the form of the pointer events spec.
it's something microsoft cameup with and is now being worked through w3. and that explicitly says-- and we'll includea link to this-- that if you do a zoom or a panor a scroll then you get touch cancel events, and youwon't get a touchend or a pointer end. so that's something for thefuture, but it's doesn't really help us now,unfortunately.
and i think we're much moreconcerned with now. paul kinlan: so do you know ifthere's many sites that are using touchend for this? is it mainly--? because most people find outthat it's going to cause that kind of problem. we do get some problems withsites where they've got an instance of google mapshalfway down the page. if you've got that full width,someone will be scrolling down
the page, and then they'llhit their finger on the google maps bit. and now all their touch eventsare going into google maps. it's not a very goodexperience. paul kinlan: so i do haveone question for you. jake archibald: go for it. paul kinlan: if you have atouchstart on the same range of elements that you'rein there, does the behavior match firefox?
because it feels like if you'rethat you've got a touchstart eventsyou'd definitely want a touchend event. jake archibald: if you havea touchstart event and you cancel it usingevent.preventdefault, then it's saying that you arenow in charge of all of those events. so you will get theentire sequence. there is another waywe can fix this.
so let's go backto the desktop. paul kinlan: is this what iruined before, by any chance? no? yes, it is. paul kinlan: oh, ok. this is the one you ruined. let's have a lookat number four. so this is going togo back to click. so yeah, we've got that.
click back there. but in the html we havea difference. we've got this meta viewporthere, but it's fixed. so i'm not going to beable to pinch zoom. so let's go back tothe mobile view. i'm going to go to number six. i'm not as dexterousat this distance. tell you what, let me just pickit from the link here. so we're going for fixed.
paul kinlan: preparation? jake archibald: it's brilliant,isn't it? all right. there we go. so i can't pinch zoomthe viewport. it's fixed. but the taps or click, evenjust using the click event which was slow before,it's now fast. and that's because we know asa browser double-tap has no
meaning here. so we don't have to waitaround for it. we can take the fast path. paul kinlan: there's a filmcalled "double tap." jake archibald: i'venever seen it. paul kinlan: it was rubbish. so we do this. this is something that chromefor android does. firefox does it as well.
unfortunately the otherbrowsers, including-- paul kinlan: i think we've justdone an article in html5 rocks about the interactionbetween touch and click. and that's one of the bits ofresearch that we did where we were testing which browsers whenyou had a viewport set the ability just to havestraight through. and as you were saying, thisis one of the things that we're looking at. because having a fixedviewport is ok.
but it can be nice a niceaccessibility feature you get for free in the browser tobe able to pinch zoom in. so it's worth keeping. so we're looking at ways--there's a ticket. we'll post a link to that--where we're discussing in what cases can we decide the user'snot going to do a double-tap here, so we don't haveto wait for it. that's right. so i think on the performanceside this doesn't necessarily
seem performance related. but it is, right? it's the first thing that peopleencounter when they're trying to build applicationsand sites on mobile. paul kinlan: this is theslow bit, right? it's not slow because thehardware can't handle it. it's just slow because of theway we programmed it, right? if you told the network guyswe have a trick that will shave 300 milliseconds off thedelivery time, they would jump
all over you to get it. and here we are in mobile withevery click taking that long. and this is not justa javascript issue. these examples have all beenjavascript, but even just a link on a page is going tohave that 300 millisecond delay unless you're usinga fixed viewport. there is a workaroundthat works today. paul kinlan: is thisthe bit now? jake archibald: thisis the ft bit.
paul kinlan: yes. jake archibald: actually,you haven't spoiled anything after that. paul kinlan: well, i can see allthe rest of your script. jake archibald: yeah, ok. well, we're getting tothe end of this page. it might ruin your nextjoke, by the way. jake archibald: oh, great. i nearly did a swear again.
let's have a lookon the mobile. i'm going to switchover to fastclick. so this is using a zoomableviewport, and it's really, really fast. so i'll show you what'shappening on the desktop machine, if we switchover to that. so this is using a bit of dropin javascript from the ft. and if i switch intothe edit view-- so the difference here is i'mdumping in a fastclick, which
is a script written by the ft. we'll put a link totheir github page. and in javascriptit's right here. this is just this one linesaying i want fastclick to work for the body. and what they do is they'rejust going to use the touchstart to touchend events,but when you let go they're going to look how faryou traveled while you were doing that.
and if you've traveled over acertain distance, they'll go, ah, that's not a tapreally, is it? that's not a click. you were doing a scroll or someother kind of gesture. and it's a large script. there's a lot of edge cases,a lot of browser bugs that they've worked around. so i'm sure they'd agree thequicker we can kill that script, the better.
as soon as we can get allbrowsers up to date or have a way that we can workaround this-- this click delay thing-- the better. but it's really the best we'vegot at the moment. paul kinlan: cool. i think that's touch. ah, well, we can deal with thetouch questions when we get them in the moderator.
so we want to pull up the linkfor the moderator again, just so if you want to ask questionsthere it is. jake archibald: that was good. paul kinlan: wasit timed well? jake archibald: that wasa real tv thing. pow. paul kinlan: i want to belike that guy on youtube that you showed me. jake archibald: excellent.
we'll put a link tothat as well. we should do, actually. it's pretty good. so do you want to go onto your next bit-- paul kinlan: --bearing in mindthat we haven't got a huge amount of time left. jake archibald: we don't? or we do? paul kinlan: not really.
jake archibald: not really. paul kinlan: you can go over. jake archibald: ah,we can go over. paul kinlan: it's notlike proper tv. jake archibald: i'mhaving good fun. are you having fun? i'm having fun. paul kinlan: moderatorsays no. jake archibald: ah.
oh, dear. paul kinlan: someone did say,did you just swear? or was that a nipplei just saw? jake archibald: therewas a nipple. there wasn't a swear, though,so i still keep my job. that's what's important. so let's have a look at ourgraphical performance demo. so if we could bringup the desktop, if we haven't already.
paul kinlan: you forgotto [clicks fingers]. jake archibald: there we go. i'm going to reset that. this is snakes on ageometric plane. paul kinlan: i like that. jake archibald: it'sgood, isn't it? jake archibald: i'm very, verypleased with myself. so as you see, these thingsare moving around. and we're moving aroundusing a css animation.
i'll go into the editscreen for this. so this is the automationit's using right here. let's bump up the sizeof it there. so it's just going around thetop and the left, and it's going to animate around. so the performance isn't sogood, even on desktop. so let's take a lookat it full screen. i'm going to bring upchrome's devtools. actually, let's do that now.
so let's bump up thesize there as well. so i can run this. this is the timeline. and what happens here ifi start recording-- paul kinlan: i'm going to sayone thing in a second about the timeline is that not enoughpeople use it, and not enough people know about it. jake archibald: it's thebest thing we've added to the tools.
paul kinlan: everyone seems togo to the heap profiler and the cpu profiler. jake archibald: don't do that. it's rubbish. and paul lewis, one of our othercolleagues, is really big on this at the moment. he's basically sayingall the time that-- jake archibald: it's huge. it's big.
it's where it's at. it's got two turntablesand a microphone. but anyway, the actual thingi was going to say was the biggest problem that we faceare at the moment around compositor, rendering, andunderstanding when the layout changes inside your app. paul kinlan: i know you're goingto talk about this now. jake archibald: well,this is it. you see the problemswe've got here.
paul kinlan: javascriptperformance, deal with it when you get to it. but you can get a lot out ofthis rendering performance. jake archibald: exactly. you can see the problem hereis all we've got these huge panes operations thatare happening. but let's take a look at it onmobile, because that's what we're here for. so if we switch over to themobile view, i'm going to open
the same thing. here we go. let's see if i can actuallyclick a button. paul kinlan: so you'veprepared devtools? jake archibald: i haven'tprepared devtools, but i'm going to. but we can see on the mobileview that the performance, it was bad on desktop, butit's just really suffering on mobile.
paul kinlan: and this is what wewere saying at the start is these devices are probably aboutone tenth of the speed of your normal desktopmachine. jake archibald: yeah, yeah. about that. they're going to keep gettingfaster, but they're always going to be behind what'sinside your much bigger desktop machine. and this is the thing.
compared to some laptops,we've both got high density screens. but in the normal laptops, yourmobile devices sometimes have the same amount of pixels,or near the same amount of pixels, but muchless hardware driving it. jake archibald: so i'mgoing to connect devtools up to this. we're going to do a propersession on devtools, right? paul kinlan: we'll probablyrope addie in
or someone as well. i don't want to do that. so the way you activate devtoolsis you connect via usb with your phone. if we can bring up the desktopview, i'll show you. paul kinlan: why were youpinged in google.com? did you have network problemsearlier [inaudible]? jake archibald: let'sjust go away. it wasn't that we were panickingfor about 15 minutes
before we started. paul kinlan: we had no networkbefore we started. and considering thisis a live show, we had a bit of a crisis. it was like an adventure. it was exactly what i wanted formy first time doing this. nearly swore again. so if you want to, you put usbdebugging mode on your device. you connect via usb.
we'll cover this properlyin [inaudible]. and there's this very intuitivecommand you put in. it's that. and i don't know about you,but that was the first-- paul kinlan: you might need tomake it a little bit bigger for everyone, if you can. jake archibald: well, peoplejust need to look closer. get closer to your screens. paul kinlan: manual zoom.
move your head closerto the screen. so i don't know about you, butthat was the first word that came out of my mouth wheni was born, that adb forward tcp colon. paul kinlan: well, i've justbeen with it for while now. jake archibald: am i allowedto say colon? paul kinlan: colon is fine. that's good. and then it will say, error.
device not found. and this is going to probablycause me some grief as i start to do this demo. let's see if it's just bycoincidence working. no, not at all. so what i'm going to do nowis i'm going to unplug it. jake archibald: and then i'mgoing to plug it back in, and i'm going to seewhat that does. paul kinlan: i havefull faith in you.
jake archibald: that's fine. do you know what? i'm ok. paul kinlan: i want you todo more shows later on. jake archibald: i could startcrying at some point soon. let's close chrome. paul kinlan: did youhave chrome up? jake archibald: i didhave chrome up. paul kinlan: we'lldo adb devices.
so we might as well telleveryone what's happening now. so this is the you've gotno devices attached. so the way that you actuallyconnect devtools to chrome and chrome on devtools isvia the android development kit at the moment. and there's a tool insidethe android development kit called adb. cool. we've got it working now.
so adb devices listsall of the devices connected to your machine. so there might be acouple of them. and jake is going to take theleap of faith, and it's worked, i think. he's run adb forward. and adb forward basically sayswe're going to forward a special port, tcp 922, to allthose connections straight to this or the host, called localabstract chrome devtools.
now that itself is the devtoolsinstance running inside the actual browser. so what you might notice isthat your devtools inside chrome appears different to thedevtools that you'd get when you debug a device. and that's because i think thedevice that you're on, the url says 25. you're at m25 there, and youmight be on canary on your desktop, which is at 26 or 27.
so we're basically forwardingall the requests to that device. and that device is serving updevtools for us, and then we go from there. paul kinlan: that was actually apretty good save, wasn't it? jake archibald: that wasa really good fill. i'm very happy about that. and by the way, the solutionthere was to unplug it and plug it back in, justthe other end of it.
anyway so what i'm going to donow is i'm going to pick up one of these things that'smoving around. so if we're on the desktop view,we can see that i've got this magnifying glass here. i'm going to click that. and then i can just tap on theactual device, if i can catch one of these snakes,and it's going to bring up that element. it's such a simple thing.
i really like that. anyway, what i'm going todo is a horrible hack. and i'm going to do webkittransform and then translate z, 0. and if we watch what happens onthe screen, as you can see the performance has justgone much, much better. in fact, let's not guesswhat frame raise it is. let's run devtools here. we're not perfect.
paul kinlan: you're not at thefull 30 frames a second but-- it actually visually looks alittle bit faster than that. and maybe devtools itselfwas making it slower. but the important thing is thepaints have gone, and we've got compositing instead. paul kinlan: can we describethis [inaudible]? paul kinlan: i don't alwayspay attention to you. so i'm barry. pleased to meet you.
welcome. you're in a studio. everything is ok. the bright lights are ok. there are three lights. i was going to say. jake archibald: thereare four lights. paul kinlan: there's actuallyfour lights. that reminds me of the t-shirtyou were looking at before.
yeah, so this user interface,i'm pointing at a screen which you can't see me pointat properly. but anyway, there's two lines,60 and 30, and they kind of vary based on the actualframe rate that you're actually getting. paul kinlan: because if you'regetting a really slow frame rate-- and we've seenapplications that get like a quarter of a frame a second-- you don't even see the60 frame a second.
the 30 frame a secondline's there. but this gives you a greatindication about how fast your application's runningon the frame rate. and the fix we applied thereis by applying hardware rendering to all ofthose objects. so i'm going to try and explaindifference between software and hardware renderingto you really, really quickly. so imagine you havea wall, ok?
a big white wall. and you're going to doa painting on it. paul kinlan: ok. jake archibald: so you get yourbucket of magenta paint and your paint brush, andyou draw your shape. and you stand back, andyou think, wow. that's brilliant. oh, except it's a little bittoo far to the right. i want to move it to the left.
the problem is youpainted a wall. paul kinlan: so you're sayingi knock the wall down and build it up again? jake archibald: well, you'llneed to repaint the wall white again. paint the wall white. paul kinlan: that's actuallyeven more efficient than what i was going to do. paul kinlan: so that wouldbe software rendering.
and then you paint it again. paul kinlan: what would mymechanism be, then, knocking down the wall? jake archibald: knocking downthe well, we're talking ie 5.5 mac there jake archibald: i thinkthat's what they did. but in hardware rendering, whatyou would do is put a piece of perspexover the wall. paul kinlan: yep.
jake archibald: you woulddo your painting again. and then if you wanted to moveit, you would just be able to move the perspex. in fact, you could add multiplelayers of perspex and draw stuff on there, andthen moving around becomes really cheap. if you wanted to changesomething else about it, like the color or the shape, you'vestill got to do some painting, but moving becomes really,really cheap.
did that work? paul kinlan: that was actuallypretty good. jake archibald: thatwas excellent. paul kinlan: as you can tell,i'm not that clever. i was actually going toknock a wall down. jake archibald: well, wemight do that later on. we could finish with that. we could knock this welldown, if you want. that sounds like agood way to end.
paul kinlan: with the amount oftrouble we had getting this place ready first-- jake archibald: that'strue, actually. well, yeah. so if we look at the mobilephone view, i've put this button in the middle. this wasn't a life suggestion. go out and do something. no, this is a button.
and this is going to spend asecond-- there it goes-- worth of javascript timedoing a thing. and you can see there theanimation stops as well. we can actually improve onthat and improve on the animation performance as well. we saw with the codewe had before-- let's go back to the desktopview where i can show that. let's get ride of devtools. come on, jsbin, don'tfail me now.
right. so this is the animationwe're doing. and it's using top and left. but we could alternativelyanimate using transforms like this. and if we go to the phone nowor the nexus, i'm going to make that happen, ifi can remember how. here's our animation name. and i believe it wasaround transform.
paul kinlan: i was laughing atyou earlier, because i was like, oh, you made a mistake. bug in devtools. that should be crossed out. yep. this should actually bewebkit-animation-delay, which is what's being set here, whichis why each circle is slightly off fromthe other one. and that creates a snake.
so now our performance hasactually gotten much better. paul kinlan: --on ageometric plane. jake archibald: oh, sohappy about that. and if we run devtoolsnow, look at that. and in fact, i thinkit's actually at 60 frames a second. it just gets slower when we'reactually recording. one of those heisenbugs. jake archibald: and we'vegot no paints.
we've got no recalculations. we're just doing composites on hardware, and that's brilliant. and furthermore, if i pressthis do something button, javascript is still going toblock for a second, but the animation's like don't care. i'm doing my own things. don't care about whatjavascript's doing. that's kind of cool.
we'd all like to not careabout javascript every now and then. paul kinlan: i don't evencare about most things half the time. jake archibald: that'sall right. i don't even care about you. nearly did a swear. i think that's kindof interesting. i've not seen too many peopleuse devtools, especially for
performance profiling. and that's one of the thingsthat we definitely want to encourage is people touse more of devtools. you get the same kind ofinterface exactly against these devices. i would say that if you emailme, paulkinlan@google.com, if you have any ideas about howyou'd like to use devtools and what you'd like to be able toactually interact with these devices better than we cannow, please let us know.
we'll file that feedbackdirectly to the team. that's the biggest thing i wantto get out today is we actually want feedbackwhen people start building these things. and we want you to go andplay with this as well. i don't want people to startthinking of that translate z thing as a-- silver bullet? golden bullet?
we'll call it a golden bullet. paul kinlan: silverfinger? is goldenfinger silver bullet? i don't know. we got into troubledoing something-- let's not. paul kinlan: let'sleave this one. jake archibald: let's talkabout something else. jake archibald: in fact,i think [inaudible]--
paul kinlan: it'snot a panacea. is that a word? jake archibald: i don't know. that's out of my vocabulary. can i talk about mobiles? is that ok? is that ok with you? paul kinlan: we're actuallyrunning out of time, but i'm trying to--
jake archibald: right. let me do this demoreally quickly. paul kinlan: and then we'llmove to questions. jake archibald: and then we'llmove to questions. paul kinlan: we need about10 minutes for questions. i've gone back to the slowdemo on the phone. and what i'm going to do now isi'm going to turn off some of the effects thatare going on here. so we've got a shadow andthe border radius.
and as we turn those off-- we're just softwarerendering now-- things have got lot quicker. and i'm also going to triggersomething else as well. i'm going to make thecolors change. so let's do that. so now it's going to change fromgreen to yellow just by changing a class name. and that's great.
it's not awfully fast,but it's consistent. what i'm going to do now is takeone of these boxes, and i'm going to do the samehack we did before. it's really annoying because theclass names are changing. i can't quite geta hold of it. i'm just going to press here. oh, don't do this to me. it's good. it's fine.
so i'm going to do the samehack again, translate z and down to 0. and now if we look at the phone,the performance is roughly the same asit was before. but you can see as it changescolor there's a-- we call it jank, right?-- a jank. paul kinlan: i usedto call it yank. jake archibald: it's a yank.
that's racist, man. don't. paul kinlan: it's not. jake archibald: you'regetting fired. i'm still employed. paul kinlan: well, i thought itwas like in a lot of places in europe they pronouncethe j's y's. i'm going to move on. if we have a look in timeline indevtools in the desktop, we
can see that jank happeningright there. and we can see what theresult of that is is all these paints. and as i was saying before,because we're actually changing the appearance of theelement, it's having to go away and paint every one ofthose squares individually and upload them to the gpu. and that's really cheap on yourdesktop, but it's really expensive on a mobile.
the nexus 7 we're demoing on hasquite a good relationship with the gpu, whereasphones often don't. and you can run intoreal trouble. what i'm trying to say istranslate z is like beer. it's like having abottle of beer. i don't know about you, butthere are some things i am better at after a bottleof beer, things like-- paul kinlan: darts. jake archibald: --talkingto people.
dancing. jake archibald: dancing, yeah. but after a few more beers,i am worse at them than to start. i am lying on the floor tellinga fire extinguisher how pretty its hair is, orsomething like that. and this is how it works. so your desktop can reallyhold its liquor. it's good at it.
it's being optimizedto do that. whereas your phoneis a lightweight. after a couple of beers, it'sgoing to start throwing up. and it's going to be throwingup gpu memory. jake archibald: icould demo that. or we're out of time? paul kinlan: i thinkwe're out of time. i think what we should do,though, is we've got a lot of questions in the moderator--
jake archibald: oh,that's good. paul kinlan: --some of whichi know we can demo. and we can be a littlebit quicker. i know there's no one in thisstudio after us, so i think we should be ok. and if we're not, my colleagueswill ping me and tell us to get off air. jake archibald: yeah,that's good. they'll be knockingat the door.
paul kinlan: well, they'llbe in america somewhere. jake archibald: oh. oh, ok. how can they use--? it doesn't matter. paul kinlan: it doesn'tmatter. it's the internet. jake archibald: wow. paul kinlan: this cloudthing, right?
jake archibald: oh, isthat our new product? a transporter? is that launching at i/o? paul kinlan: i did actually saythey'll ping me, not knock on the door. jake archibald: oh, ok. paul kinlan: anyway,we're wasting time. jake archibald: carry on. paul kinlan: so first andmost popular question,
from mark j in london. i don't quite knowmark j. do you? paul kinlan: well,hello, mark j. jake archibald: sorryif i do know you. paul kinlan: i'm sorry too. jake archibald: hashe put his age? people should put theirage with questions. i like it. he's 28, from london.
paul kinlan: will fixed positionalways be such a huge performance killer? so i know you've done a littlebit of research about this just today. no, it won't. in fact, let's have a look. if we go onto the mobiledevice, i'm going to launch bbc news. and there we go.
oh, what's cameron doing? anyway, let's have a lookat devtools as well. and what i'm going to do is i'mgoing to click on this, and i'm going to get holdof this masthead here. and what i'm going todo is i'm going to make this fixed position. so fixed and top 0, left 0. let's give it width 100%,because it's not in flow anymore, and z index--
what's your favoritenumber, paul? paul kinlan: 74. jake archibald: 74. paul kinlan: just ignoreme and put 64 instead. jake archibald: i hate yourfavorite number, so i'm not so if we have a look at themobile device now, i fixed that masthead at the top. and really we don'thave too much of a performance problem at all.
one thing to watchout for is if-- the bbc doesn't dopinch zooming. in fact, i'm going to make itdo pinch zooming, because we've got devtools. paul kinlan: does this work ifyou modify the viewport? jake archibald: let'sfind out. this is exciting. there it is, user-scalable 1. i don't know what that means.
that doesn't mean anything. maximum scale of 1, that'sour problem. let's see if that worked. oh, look at it go. so yeah, using fixedelements-- oh, i've clicked onthe link now. no, no, i haven't. with pinch zooming, you get areally behavior with fixed positioning.
but without it, is it's actuallydecently fast. yeah, scrolling isgoing smoothly. i think this is a problemon all the devices. i think that's what we'retalking about. jake archibald: in fact, it'smore of a problem on desktop. paul kinlan: we actually had aproblem the other week where we were debugging another appand fixed position actually caused a different behavior. i don't know whetherit was a slow path.
well, it probably wasa slow path, because it was a lot slower. yeah, it was kindof interesting. it caused a whole lotof repaints that didn't need to happen. at the moment we do a full pagerepaint on scroll, which we're working on fixing. fixed elements will go intotheir own gpu layer, which is what's happening ona mobile already.
so to answer the question, likeyou said before, it's not always going to be aperformance killer. we know it is. and this is the great thingabout open source projects, like firefox and chrome andothers as well is that there are normally openbug trackers. either submit one. if it's already submitted bysomeone else, it'll be triaged and merged in withanother issue, so
don't worry about that. but submit the feedback. and then that's when we knowfixed position is a critical problem for developers. paul kinlan: so yeah, if itis a problem, let us know. and the bug trackers arenormally the best way. and have a look at the timeline,because that will show you that large repaintsare happening. and any information youcan provider is great.
we'll look into it as well, butyou might be able to find out that the cause of yourproblem is something you can easily fix. next question. it's [inaudible] in england. is there a plan for chrome tointegrate a view which shows html5 exactly how it's processedon the mobile? jake archibald: thatwas just words. paul kinlan: that was menot reading properly.
sorry there. paul kinlan: in ios,there's a simulator which emulates safari. it has those differences. and then the same withandroid emulators. so this is actually oneof those things that-- email me, paulkinlan@google.com,because i want to find out how peoplework on desktop. because right now we're findingthat it's not too hard
to connect to a device andactually do the testing. but at the same time, weunderstand the fact that if you're on a desktop machine-- can you actually show up a pagethat we can go to to show one of the little thingsthat we can do? jake archibald: on what? what do you mean? paul kinlan: on the desktop. jake archibald: on the desktop,what do you want?
paul kinlan: devtools. jake archibald: i phased out. devtools. paul kinlan: yeah, ondesktop devtools. jake archibald: ok, ok, ok. paul kinlan: come on. just anywhere. jake archibald: but iwant to say this-- i can't even spell.
paul kinlan: it's ok. there you go. desktop. now go to settings, andthen overrides. jake archibald: overrides. we can get to user agentand device metrics. paul kinlan: so we cando some things. obviously jake's not clickingthe buttons i asked him to click.
jake archibald: oh, you didn'tsay click the buttons. paul kinlan: i thought youwould have been able to understand my-- jake archibald: i thoughtyou were just-- paul kinlan: --motioning. jake archibald: --tryingto impress people with your reading. paul kinlan: well, obviouslynot, because they can't see what i'm pointing at on thescreen properly, can they?
sorry. paul kinlan: i haven'tgot google glass. if i had google glassit'd be awesome. but essentially what we see isthat we can make the device metrics to be like a chrome formobile, chrome for android ios, so you can test it. however, it doesn't emulate theviewport, and it doesn't emulate a whole lot of otherthings that you'd expect on the machine.
and if you talk to theperformance guys, they actually want you to test-- that was quick-- on the devices, because whenyou're thinking about performance, a lot of the timeit's the gpu characteristics and a whole lot of otherstuff which might be causing you problems. you might think you've done itquite well on one machine. you go to your device,and it's a
completely different profile. so that's why we're encouragingpeople to use the devtools and actually test onthe devices themselves. jake archibald: as you say, theemulators we have, because they're actual emulators, theywill accurately show you the rendering, but they won'taccurately show you the performance. jake archibald: ios, the devsimulator is a simulator. it's using the underlyingrendering in mac os.
so your rendering might beslightly different, and your performance will be theperformance of your desktop machine rather than[inaudible] in mobile. so you need to test them. and neither of them give youthe same kind of touch experience that using anactual device will. we'll do a couple more. we'll try and get througha couple more.
a while ago there was adiscussion about the best approaches for responsiveimages, the best way to defer load in. is there a de facto standardyet, in your opinion? i no. there's no de facto standard. jake archibald: nah. paul kinlan: we showed youin the bbc before. they do an image replacementtechnique with some
javascript. if you actually use the devtoolsand go in and inspect what they do, it's actuallypretty cool. they work out the viewport sizeor the image size and then work out which ones arethe best ones to display. jake archibald: there'smatchmedia. matchmedia will let you doa css media query test in and that's reallyuseful for that. there's a webkit image settag which you can use.
and we've got a little hack,which we'll share later on. i actually did it on twitterthe other day where you can display a two times pixel ratioimage and all those types of things. but it's only responsive topixel density and not any other context. so there is none, and there'sno implementations, and there's no implementationsof [inaudible] yet, which i believe isthe other one as well.
if you're using css backgrounds,then you can obviously just usemedia queries. and there's also one fordevice-pixel ratio. but the problem withbackgrounds, is if you do an image, for instance, like thealt tag comes through still with a lot of other stuff. paul kinlan: so it's a pain. i wouldn't recommend using cssfor content images just because it's more convenientto switch them
at different widths. jake archibald: look at whatthe bbc have done. paul kinlan: it looks nice. it looks like the old gifs-- or gifs? jake archibald: gifs. definitely gifs. paul kinlan: yeah, gif. but it's gifs in "doom,"not gif.
anyway, next question. i use adobe edge and weinre toinspect mobile devices, which i'm finding useful. is it possible to do somethingsimilar in devtools? yes. we've just shown you. that's the next one. currently building an entirejavascript app for mobile. is mobile generally up to theprocess in rendering?
and how can i optimizefor mobile? from simon smith in london. and i guess his age is 26. jake archibald: oh, 26. paul kinlan: 34? jake archibald: that'syounger than me. well done. paul kinlan: anyway. so i think it all depends on theoperations that you do and
you need to test. we find that things likebox-shadow that you showed before and a whole lot of otherstuff can cause issues. box-shadow and border-radiusand a couple of other ones. paul kinlan: and it changes,because as the browsers update the performance profileschange as well. so you're going to have to keeptesting a little bit. process and rendering, yeah,they're actually pretty good. if you do it right,it's pretty good.
but you've got to test,and you've got to test on the devices. i don't think there's any realway of getting around it, because devices are different. desktops are different. tablets are different. everything's different. javascript's not your problem,really, anymore. and we heard [inaudible]guys are
saying that it's rendering. because the javascript engines,even on a mobile device, are pretty fast,unless you're doing ray tracing or tryingto do something like gzip on the clients. yeah, you're going to runinto problems there. but for general website use,javascript's not you problem. you might run into rendering,but devtools will tell you where the renderingproblems are.
even something like abox-shadow, once you've drawn it, as long as you're notchanging the shape and size of it, it draws once and itstays in memory so it's less smooth scrolling. paul kinlan: i don't know. i've seen html5 rocks go slowbecause of the scrolling. it's horses for coursessometimes. paul kinlan: and it depends. next question, [inaudible]in chile.
any link for more resourcesabout mobile dev with chrome devtools? we haven't got anythingdedicated. we've got developers.google.com/chrome/mobile. it is literally just thedevtools, so anything that you do with devtools. we should probably get someperformance articles written about how to actually do bettermobile debugging and everything.
jake archibald: and so have alook on youtube for talks by there's a new young developercalled paul irish. and he's done quite a fewinteresting talks about this stuff, hasn't he? and [inaudible] has as well. paul kinlan: so if youever see [inaudible] ask him to do his paulirish impression. it's brilliant. jake archibald: very,very good.
i want to get one more in. patrick h. lauke. jake archibald: iknow patrick. and he actually senta tweet in before. jake archibald: did he? i'm about the other tv presenteryou look like. and it was rather amusing. paul kinlan: so let'slook at this one. with mobile devices often havinglimited memory, care to
comment about not justcompressing and minimizing files over the air gzip butactually caring about the deflated file size? so this for processingit actually onto the device in memory. can i start with that one? jake archibald: whatever,mate. yeah, go on. paul kinlan: whatever.
so we've seen this with deviceswith different pixel ratios where a pixel isn'ta pixel anymore. we've seen that image decodeand resize happens when you have to-- the image decode always happens,so the bigger the image the longer ittakes to decode. and if it takes it a long timeon a desktop machine to decode, it's going to take evenlonger on a phone or a tablet to decode.
but we've also seen resizeshappen where if it's not done at the same dpi, essentially,as the target device then it has to do a resize. so if it knows it's 500 pixels,it has to actually double it to 1,000 pixels, intheory, behind the scenes. jake archibald: but with allthe different dpis that we have on devices now,it's truly nearly impossible to avoid. paul kinlan: well, you couldhave a 1.33333337.
jake archibald: you couldgenerate them on the server, i guess, if it was a problemon a particular-- i know page speed tries to dothings like this, the page speed services and everything. they try and optimize the sizefor the container and a whole load of other stuff-- jake archibald: thatmakes sense. paul kinlan: --and thedevice format. but it's hard man, especiallywhen you're on the other side
of the server where you don'tquite know the device characteristics unless you'vegot them in a big database. so how would youdeal with that? jake archibald: i think it'sdown to the browser developers. it's not our problem. go and fix image resizing. i know they're looking at it. and it's something thatwill get a lot better.
paul kinlan: i think that'sactually one thing that we haven't really touched uponis the time to decode css javascript in its raw form. jake archibald: so the bbc dosomething very interesting, and it's kind of similarto something i did when i was at lanyrd. we do a basic feature detectin the head of the page and for what we think the site needsto run the javascript we're running.
so i think for me it wasappcache and local storage. for the bbc, i think they lookat json and some other stuff. and if the browser fails thosetests, don't load any jake archibald: and becausethe site works without javascript-- the browsers that are going tofail, though, are going to be old browsers. those old browsers are goingto be slow at pausing we saw on old blackberrys--
and we weren't runningany scripts, we were just pausing it-- was causing like a 5 to10 second delay on just loading a page. and caching doesn'thelp with that. that's going to hitevery single page. so yeah, if you canconditionally load javascript or conditionally load contentas well, that works really well.
jake archibald: but what i wouldsay don't do is don't lazyload content on amobile device unless it is a huge chunk. because if you're scrolling downa page and you're loading in imagery as it appears, that'squite good on desktops. but on mobile, if you'reon cellular data-- i guess the same wouldapply for a desktop on cellular data-- the cell falls asleep.
the radio falls asleep. paul kinlan: i'm fallingasleep right now. i'm boring myself, actually. the cell falls asleep, the radiofalls asleep, and then a new thing goes to load. it has to be woken up. and before it wakes up, it wantsits breakfast, and its breakfast is yourbattery life. so it does all that, and thenit'll go and download stuff.
so lazyloading can seem like,yeah, this is going to speed things up. just load stuff whenit's necessary. on cell data, on mobile3g, whatever-- paul kinlan: but if you lazyloadat the start of the page, it's not going to makethat much difference, right? jake archibald: startof the page is fine. as long as it's roughlythe same time-- paul kinlan: so what you'resaying, though, is anything
with ajax-based refresh isgoing to be potentially a performance killer ora battery killer. and if you can get away withsending it all down the wire to start and it's not too much,then i would do that. paul kinlan: it would beinteresting to know well service and eventswork and whether they keep the battery-- it'd be interesting. so actually, that's agood time to finish.
paul kinlan: i think. you just yammered on likecrazy for ages, man. it was terrible. jake archibald: i'mgoing to the pub. paul kinlan: so what we're doingis a series of podcasts. we're going to have a cycle. so the next performanceone is going to be in a couple of weeks. i know jake's got alot more content.
he prepared it a lot today,and we ran over. jake archibald: joinus next time. paul kinlan: so we're definitelygoing to do another performance one. we'd like to hear from you tounderstand what kind of things you want to hear us talk aboutaround, i suppose, the client side of the performance. [inaudible] is going to talkabout networking and network performance, and we don't wantto go over that too much.
but building performance userexperiences and user interfaces, we want to know whatyou want to hear about, the problems that you're having,so that we can address them in articles and also invideos and programs like this. i think next week is sam, ourproducer, who's actually been switching all the buttonsfor us today and helping us out loads. what are we talking aboutnext week, sam? devtools?
sam dutton: yeah. that'll do. paul kinlan: devtools or owp. we'll send out atweet later on. but it's going to be good, andwe'll ask you for questions that you want answeredlive as well. and then we'll do thisone again in a couple of weeks' time. jake archibald: it's sam's firsttime producing as well
on one of these things. jake archibald: it'shis first time. it's my first time. paul kinlan: youare producing-- jake archibald: that'spretty romantic. paul kinlan: --next week. jake archibald: i'm notproducing next week. paul kinlan: you are. sam dutton: oh, yes, you are.
next week, if you see it justchanged to a picture of, i don't know, whatever,that's jake. so paul kinlan: anyway, with that,i think we're finished. and we would liketo say goodbye. well, i would liketo say goodbye. what would you like to say? jake archibald: hello. how's it going?
do you want to go for a drink? jake archibald: i think you'vegot a great sense of humor. with that, then we'llsee you soon. jake archibald: thankyou very much. paul kinlan: bye bye. jake archibald: bye bye.
0 comments:
Post a Comment