00:00:24.679
so I think we'll go ahead and get started we have a lot to cover and what
00:00:30.089
I want to talk about today is of course at Google we care a lot about speed and
00:00:35.550
hopefully that's something that you guys have experienced yourself across many of our applications although I know we can still make them faster and in the
00:00:42.630
process of doing this we've actually spent quite a bit of time and effort into developing better tools and just
00:00:48.390
developing better methodology for how exactly do we make our web pages faster so the intent of this talk is to
00:00:55.320
actually give you a glimpse into the process that we use ourselves to analyze our own products our own pages so on so
00:01:02.250
so forth so in terms of logistics we're going to take a look at a number of different apps I'm going to try and give
00:01:09.630
as many demos as I can assuming the the demo and Wi-Fi gods are with us hopefully that'll go well and then at
00:01:16.140
the end there will be a lot of links there's a lot of resources embedded in these slides there will be a link to the
00:01:21.569
slides at the very end so you know don't rush to try to write down every short link and all that kind of stuff it'll
00:01:28.619
all be there so with that let's let's get started so Larry Page made this
00:01:35.909
interesting statement some time ago which is browsing should be as simple and fast as during a page in magazine
00:01:41.130
now that's kind of odd right like is that really what we're inspiring or aspiring to to make her what P just feel
00:01:47.429
like you know dead media well not quiet right there's the metaphor here is that when you think about the user experience
00:01:53.969
of turning a page in magazine it actually works quite well all right there's many other usability issues that
00:02:01.079
come with the magazine but the fact is when you flip the page it doesn't just kind of like stop half way and not
00:02:06.810
permit you to like turn it further right and then when you flip it over all the content is there
00:02:12.330
like it's just a blank page and then 30 seconds later or you know 10 seconds later the the content comes in on the
00:02:18.480
ads pop up and then like the whole page shifts down by 10 pixels because the the iframe at the top showed up right that's
00:02:24.540
what we mean by that's that's the experience that we want when we reference this quote and of course you
00:02:31.110
know we shouldn't stop there which it should even be faster so with that in
00:02:36.390
mind we actually have an entire team at Google it's actually a fairly large team the name of the team is make the web
00:02:42.300
fast and I think you can infer what we're trying to do and the perhaps the most interesting aspect of this team is
00:02:49.170
the fact that while we obviously spend a lot of time optimizing our own products we also the actual mandate or the goal
00:02:57.720
for the team is to make the web fast as a whole right so we actually measure the performance of the team based on the
00:03:04.320
entire web the metrics around the entire web which is actually pretty amazing when you think about it so this
00:03:09.390
obviously includes a lot of different optimizations there's Colonel networking mobile there's chrome there's
00:03:15.209
infrastructure you know data centers our own routers all the kind of stuff so this includes research working with
00:03:22.290
standards bodies building open source tools and working with communities like the Ruby community to help make the web
00:03:29.640
faster so this is a really exciting feel to be working in so before we get into
00:03:36.300
the specifics of how do we go go about optimizing it's good to get some bass lines all right so this is just
00:03:41.850
usability engineering 101 and every month or so we got a new case study or a
00:03:47.880
new paper or some case study that goes comes out and says hey we lower it our
00:03:54.120
page loading times and our conversions went up or the sales went up or something similar and you know it's
00:04:00.180
great to hear those those stories because frankly I think we need to be reminded constantly of it but the truth
00:04:05.910
of the matter is these numbers have been published by Jakob Nielsen right in 1993
00:04:12.510
he did a bunch of studies around what is it what are some constants in terms of
00:04:18.150
usability on a computer and he found these kind of high-level buckets which is if you respond to the user
00:04:23.820
than 100 milliseconds it feels instant we can't actually tell the difference all right 50 millisecond 200
00:04:29.070
milliseconds so you're safe there zero to 300 it starts to feel sluggish it's kind of like you know that sticky button
00:04:34.650
you press it and something just didn't feel right if you go over 300 milliseconds all of a sudden you get
00:04:40.110
this mental image of like cookie the computer is thinking something is going on in the background and then if you're
00:04:45.630
over one second then you just kind of contact switch right it's you press the
00:04:51.150
button and it's doing something and then that other thought pops into your head and you're like oh yeah I need to do
00:04:56.190
something there and then if you don't deliver something well then let's say five seconds you know a lot alone 10
00:05:01.530
seconds the users already doing something else entirely right there that thought or that context switch that I
00:05:08.190
created one second evolved into a full line of thinking that has completely took him off the course rights like i
00:05:14.340
press this button and then I forgot what I was doing right happens to me all the time unfortunately so these are the
00:05:22.140
constraints so we actually did some studies we we ran and we publish these
00:05:27.330
numbers on the Google Analytics blog we looked across hundreds of millions of sessions on the web and this is not specific to google web pages this is web
00:05:34.740
as a whole and we wanted to get some feel for how long do the pages on
00:05:40.080
average take to load on desktop versus mobile so here's the numbers for desktop
00:05:45.870
we have the mean and the median all right so the mean is the blue and the median is is the red so the mean loading
00:05:52.740
time on desktop today is over six seconds right that's how long it takes
00:05:57.810
to load a page an average page on the internet for mobile it's much worse it's over ten seconds now the medians are a
00:06:04.170
lot lower and you know that's that's good but if you look at the histogram at the bottom you can see that you know
00:06:10.290
desktop is certainly faster as you would expect and by the way this mobile data is actually very optimistic because
00:06:18.510
we're using top-of-the-line devices to measure this right so these are your latest Android devices with multiple
00:06:24.600
cores likely in a good network so for all intents and purposes this is a very optimistic estimate so if you're curious
00:06:31.380
we actually published all of the country specific data and a lot more there's a link down here on the bottom so you can go to
00:06:37.300
the Google Analytics blog and find that there so you know three to five seconds
00:06:43.090
that's your average page load time that's pretty bad and what that means is
00:06:49.449
you know looking back to this chart that we saw earlier is we're just on the brink of this like I'm thinking about
00:06:55.840
something else and I'm just gone right it's a pretty terrible experience think back to that magazine metaphor that we
00:07:03.910
thought about what kind of experience would you have if you flip the page and they had to wait three to five seconds
00:07:09.880
for the page to load that's that's pretty terrible but that's where we are on the web today and that's what we need
00:07:15.610
to improve so of course one thing that we could guess at and say like well you
00:07:21.220
know let's look at the size of the pages or what is making up all of this time
00:07:26.710
and maybe a little bit hard to see but here at the top we actually have a different project that's maintained by
00:07:32.740
Googlers and a few others called the HTTP archive and what it does is every month we go out and crawl some of the
00:07:38.860
most popular pages on the web so thousands of pages CNN's BBC and all the rest and you just collect all of the
00:07:44.590
data right all of the images all of the timing data and all the rest and we graphing graphing it here over time so
00:07:50.560
you can see that from just november of last year to april of this year the
00:07:57.130
average size of a page has gone up from 702 kilobytes to just north of a
00:08:02.440
thousand kilobytes alright so think about that sink in for a second the
00:08:07.990
average size for page today is basically a megabyte that's that's crazy and then
00:08:16.449
at the top here we have a different line which is the number of requests so
00:08:21.610
there's for an average page it takes 84 requests 84 requests to render a page
00:08:26.979
and a megabyte in size right that's that's pretty bad and we can actually
00:08:32.770
break it up by the type of requests so an average page is eight HTML pages what
00:08:38.829
right well there's iframes right so requesting additional HTML resources there's a ton of images right that we're
00:08:46.390
requesting in fact they make up the bulk of the actual content or the download response there's
00:08:53.690
a ton of JavaScript and there's CSS and I'm actually emitting some of the other resources but basically you know the
00:09:00.380
pages are getting bigger and unfortunately our networks are not getting that much faster all right so we need to do something about this so
00:09:07.310
that's one good and interesting hypothesis right it's the pages are slow because we can't download them fast
00:09:13.100
enough but you know there's a lot of other things that come into a picture when you think about optimizing the web
00:09:18.830
page think of think how the page is rendered when you first type in that URL
00:09:24.430
you click on the link first the browser actually has to unload everything that's in the dong right like that's just
00:09:30.980
garbage collection it shouldn't take a lot of time but it takes some time then you have to do the dns resolution a lot
00:09:36.950
of people here today we're complaining about hey my dns oh signing out you know that's usually a hidden costs that we
00:09:42.230
don't think about but it's there there's the tcp and connection handshake we have to make 84 requests in there right some
00:09:49.399
of those will share connection many of them won't so each one of those six time we need to send the request wait for the
00:09:55.130
response parse the response and then oh by the way we need to repeat this 85 times right so that's that's kind of
00:10:00.980
cute and then once we have all the content we actually need to parse all of
00:10:05.990
the content and render and lay out the page right the beautiful thing about web
00:10:11.390
apps is there's no install process but we trade that off for an infinite install process because every time you
00:10:16.910
load the page or installing a page right so that's that's a cost that we need to take into account as well so the
00:10:24.050
question is for your pages where is a bottleneck and there's only one answer
00:10:30.740
to that all right it's we need to measure all the things this is step
00:10:36.740
number one before we can optimize anything we need to understand what it is that we're trying to fix so one
00:10:43.880
problem though let me go back how do we measure the dns resolution side in your
00:10:49.670
browser we have no access to that data how do we measure the tcp connection latency we have no access to that all of
00:10:56.329
these things are very hard to get your hands on overall these metrics are very hard to get
00:11:02.509
but we do have one new addition to the standards html5 centers and w3 standards
00:11:09.929
which will actually help us quite a bit and it's called the navigation timing spec so this was introduced last year
00:11:15.360
and this is actually a result of the work that our team at Google and a number of other organizations have been
00:11:21.119
working on for some time an idea here is to expose all of that data from the browser to you write such that you can
00:11:28.110
instrument this so previously you would have to write a native extension like a browser plug-in like a toolbar to try an
00:11:34.739
instrument and get at this data now all of this is accessible right within the browser so each one of these it's very
00:11:41.160
hard to read them but each one of these black labels at the top is actually a timer all right that you can get at us
00:11:48.239
so navigation start fetch start domain lookup start dom complete each one of
00:11:54.329
these is a micro second level timer they can give you the exact timing of how
00:11:59.699
long does it take to do a deer dns resolution so that's pretty cool and we have them colored in three different
00:12:05.629
colors here so the first part which is the app cache that dns the tcp and
00:12:11.639
making into the request is basically the users connectivity right if i'm sitting
00:12:16.949
on my mobile phone and i'm trying to access a web page all of that is effectively hidden from you as a rails
00:12:22.589
developer who is developing the app right but this definitely affects the
00:12:27.629
user experience what type of networks on so forth then there's a response which frankly that's worth you know we tend to
00:12:33.869
focus on its I got a request on my rails app server I need to render it as fast as I can and we have some very good
00:12:40.379
tools that will help us drill in on this specific section New Relic you know analyze the logs and all the kind of
00:12:46.319
stuff that will tell you that hey your active record is slow or perhaps some other aspect of it as needs optimization
00:12:52.829
and then finally we get all that content back to the client and now the browser takes over and used to parse all this
00:12:59.279
content and layout the page right so there's a lot of moving components but
00:13:04.769
the thing is the user doesn't care right the user perceives the entire loading
00:13:11.189
time as a sum of all these components not just the rail stack it's not just a
00:13:16.220
browser time it's all of these things so that's start to get really tricky so
00:13:21.800
what is the state of navigation timing API as of today it's actually supported
00:13:26.990
in IE firefox and chrome right so it is it's out there and in fact it has over
00:13:33.650
eighty-five percent penetration at this point it is available now on the latest
00:13:39.140
android browser but as you can see some of the other mobile browsers are working on it but it's not there yet right so in
00:13:46.370
terms of mobile coverage we're not quite there but it will be there it's only a matter of time so very exciting stuff so
00:13:54.560
let's take a look at what this actually gives us right we have the navigation timing spec and it means that the
00:14:00.980
browser can give you all of the detailed information about how long it took so load this page so let me open up this
00:14:12.650
guy here go to the console and we can actually type in performance timing and
00:14:21.470
we get this object back which gives us all the time stamps for all the events
00:14:28.900
associated with DNS resolution TCP connection time so on so forth so this
00:14:34.280
is really nice because you can get this on every page right so now now your client can actually look at the state
00:14:39.950
and say hey you know what that DNS lookup it took me really long which is why you experience that slow load time
00:14:45.770
so that's nice and you can find out more about how to use this by following this link later but now you have a problem
00:14:54.080
right this data is available to the client it's not available to you as a developer so now you need to collect all
00:14:59.390
of this data right so you load the page and perhaps you can write some some JavaScript to extract these time or send
00:15:06.170
them to your server or log them analyze them and do all this kind of stuff and that's great but we have something even
00:15:11.540
better which is google analytics so in fact we are collecting this data in
00:15:18.050
Google Analytics and you can access it today right there is no additional instrumentation and you can just log in
00:15:24.740
to your account I'm using the set site speed sample
00:15:31.780
right here for one specific reason so the way the sampling works today is Google Analytics will sample up to 10k
00:15:38.740
unique visits per day right so we're not going to record this data for every single user because it's a lot of
00:15:44.200
frankly it's a lot of data but we have this max limit of 10k or by default will
00:15:49.240
sample five percent of all of your visits so if you have a slight that's small ish as in it gets less than 10,000
00:15:57.340
unique visitors a day you can just set your sampling rate to 100 and roll sample across everybody which gives you
00:16:02.620
a really nice sample for how are you how are users interacting with your site so
00:16:08.950
in fact I have the set on my blog and what this gives us is a number of
00:16:15.850
reports within Google Analytics so this is where we're going to attempt to the demo gods so this is actually my own
00:16:21.820
blog and we're looking at the content section site speed or report right and you can see this average page loading
00:16:27.790
time and I you know don't want to talk about the 52nd load side that's so you
00:16:35.410
can see that in fact on my own pages right here I am preaching about site speed and my average page load time is
00:16:41.370
9.8 seconds oh my goodness so let's go
00:16:47.290
into page signings so we can go into page timing and look at the technical
00:16:54.160
tab one of the more interesting ones come on Wi-Fi
00:17:04.430
maybe not let's let's try this so this is the same
00:17:12.370
tab but pre-rendered so what we're
00:17:17.770
looking at here is the technical report within google analytics for sites feed
00:17:23.290
and you can see the average page loading time average redirection server connections server response yes you can
00:17:30.309
get server response times within your Google Analytics without any instrumentation which is pretty cool so
00:17:36.700
let's let's do some math here right so it took a user starts they do a DNS
00:17:41.830
lookup 180 milliseconds they connect to me takes on average 120 milliseconds so that's 300 it takes me on average 300
00:17:49.240
milliseconds to server page 600 milliseconds and then the download time is roughly once at 170 so you know less
00:17:57.160
than one second is all that connection time but my average page load time is nine point seven seconds where did the
00:18:04.000
other eight seconds go right so that's that's interesting that's something we can drill into now let's see if the
00:18:13.809
slowed it no luck oh
00:18:22.750
try that again I think it's just cashing
00:18:28.710
so how many of you here are familiar with Google Analytics advanced segments put up your hand awesome awesome so
00:18:37.039
let's see if I can actually load this so
00:18:42.840
one of the things you can do is this is probably not going to work but in advanced segments because you're using
00:18:48.090
google analytics you can actually segment out the traffic by any number of variables things like which country is
00:18:54.330
the visitor coming from are they on mobile phone which browser are they on which browser version are they on what
00:18:59.760
screen resolution so on so forth so we can actually you know we're looking at performance data here so we can actually
00:19:04.799
say well I have a couple of different segments predefined in here so for example Asia versus Europe there's some
00:19:12.990
funny rendering artifacts there but if I hit apply Oh looks like the wifis back and it'll actually break out all of this
00:19:22.470
traffic and give me the report comparing those two different segments right so visitors coming from Asia versus
00:19:27.960
visitors coming from Europe which is pretty amazing and you can target this at City level and even deeper right so
00:19:35.010
you can do very very detailed analysis in here and doesn't look like it wants
00:19:40.049
to cooperate but here's an example right I'm once again pre-rendering Asia versus Europe and you can see that remember
00:19:46.830
that 52nd spike well it looks like Europe was fine but for some reason Asia
00:19:52.200
really really spiked so it turns out that it's it wasn't it's likely not an
00:19:57.960
issue on my side it's likely some resource external research that are requesting which was just inaccessible or just rendering took a really long
00:20:04.770
time to render in Asia so that in itself is a really good insight so you can do
00:20:09.899
all kinds of detailed on interesting things within Google Analytics this is
00:20:15.210
your first should be your first takeaway which is to log into your Google Analytics and play with these reports
00:20:20.730
and you can do all kinds of cool things with it you can set up PDF reports that will email you every Monday Tuesday
00:20:27.120
Wednesday whatever and give you a summary of all the performance associated with your site this is
00:20:32.700
something we use extensively within Google but you know one thing we need to
00:20:37.860
be very careful of is averages when you're talking about performance and timing often lie right because very
00:20:45.129
rarely do you get a nice normal distribution for this kind of data more likely you're going to get something
00:20:50.769
like this guy here which is this really skewed distribution where the mean the median and the mode or meal and have a
00:20:59.619
lot of space in between them so to that there's only one answer right into
00:21:06.129
histogram everything because averages are misleading when you when you're talking about performance and let me
00:21:15.009
flip back maybe this guy will f faith in
00:21:23.440
Wi-Fi
00:21:29.480
well we'll wait for it to try and load but you can actually go to content site
00:21:34.940
speed page timings performance right so it's a little bit hidden but it's in there you can go into this tab within
00:21:41.929
Google Analytics and instead of giving you the averages it will actually give you the histogram for each one of these
00:21:47.330
metrics so here we're looking at an example of this is just my own site and this is a kind of a case study I put
00:21:53.450
together we're back in January I actually completely changed over my site
00:21:58.940
right I moved it to a different server i redesigned the pages i migrated from wordpress no static static the generated
00:22:06.020
site all of these things and here we're looking at the results right so this is December 12 December 31st versus January
00:22:12.350
one versus January first and it just so happens that I made flip exactly on january first so this is just like
00:22:18.200
perfect so the one thing to notice here is it is first of all a distribution
00:22:23.390
there is this tail here but you can see that starting January first the peak of
00:22:29.960
the distribution shifted up into the 123 second bucket right which is a really nice improvement we can actually show
00:22:35.780
this to recline through our users and and say that hey there's a significant
00:22:41.090
change in here and we can also look at things like the server response time and this this is why this is where the
00:22:47.990
averages really get misleading right what is the average of this distribution I don't know it's probably half a second
00:22:56.660
but the histogram tells you a much more interesting story which is there's actually this bimodal distribution in
00:23:02.540
here and I'm going to make a guess as to why that is right this this big here is
00:23:08.360
when the page was precast right so this is my blog running on wordpress it had
00:23:15.710
it stuck in memcache it just served it fast the users happy the other case is
00:23:21.260
when I got a cache miss and it needed to go and render the actual page from database right so you can see these
00:23:28.250
distributions and it affects how you your users perceive this and then of course once i migrated to a static site
00:23:34.280
that's a very different picture most of the pages are very fast you know there's
00:23:39.399
this little dip in here and it takes a little bit more so histograms are
00:23:45.159
incredibly useful and that's what we use to analyze the performance of the pages averages are good but look at the
00:23:50.499
history grams so just to recap some of the things we talked about measuring
00:23:57.580
user perceives latency is probably the most important thing you can do to help optimize the actual experience that the
00:24:04.269
user has with your pages navigation timing is your best friend there right up until very recently it's it's been
00:24:10.450
effectively impossible to get at those data you can do that now which is great
00:24:15.479
Google Analytics advanced segments and of course you don't have to use google analytics you can collect us data on your own or use some other tool but the
00:24:22.899
advanced segments in GA can give you a lot of power to slice and dice this data and then do set up some daily or weekly
00:24:29.349
reports it'll take you literally all of two minutes and you'll get a weekly email that will give you detailed
00:24:36.039
performance data for free which is very very nice so we talked a little bit
00:24:44.379
about measuring right and what and available tools that can help us measure
00:24:50.739
all this stuff now the question is perhaps I know I have a problem what
00:24:56.529
tools do i have to help me optimize around here right and there's a number of tools that chrome specifically
00:25:01.690
provides there's a lot of other tools for other browsers we're going to focus on chrome there's a network waterfall which i think many of you guys are
00:25:07.570
familiar with there's a timeline profiler which few people actually use but it's actually incredibly powerful
00:25:13.559
there is the CSS and a GS profile edge specifically for to help you optimize those specific components and then
00:25:19.869
there's this you know some of those crazy stuff in tracing which will take a very brief look at so the network
00:25:25.479
waterfall should not be new I hope right
00:25:31.049
let's try this let's open this guy go to network tab
00:25:40.370
and
00:25:52.559
we're going to try and load CNN com so here it is trying to stream over the web
00:25:57.870
right and the reason we call it the waterfall is because the resources as they get loaded request more resources
00:26:04.620
there's network latency there is blocking scripts that prevent other resources from being fetched and you can
00:26:10.230
see all of this data in here and you know the the shaded regions here actually tell you a lot of interesting
00:26:16.740
things it's stuff like this is the latency this is the actual download and a parse time right so it took us a while
00:26:23.639
to make this first request 33 seconds and then we can see all the different resources so in fact for CNN you know
00:26:30.749
it's trying to fetch all of these advertisement gifts which are getting us a 404 there's missing resources all
00:26:38.580
kinds of stuff and as you can see there is in fact over 84 resources that we're trying to fetch for a single page right
00:26:45.360
it's it's remarkable that it works
00:26:50.609
and I'm not trying to pick on CNN you know my own page took 10 seconds to load
00:26:56.470
right the CNN pages actually take as you will see in a second about 15 seconds to
00:27:01.509
load so they're actually doing a lot of things right right there you're fetching a lot of resources intro and managing to
00:27:06.909
get its you fairly fast whereas my page has like an image in an HTML file and shaking me ten seconds so perhaps they
00:27:13.720
should be giving this stuff so then we have let's go back to CNN so this is
00:27:22.330
very useful because they can tell you you know what are the resources that are being fetched how long did it take some
00:27:27.669
high level stuff the timeline which few people actually use but incredibly useful requires that we start recording
00:27:34.539
and then we can reload the page so let's reload the page and what will tell you
00:27:42.340
here let's go down
00:27:48.920
still trying to reload it come on it'll
00:27:55.550
tell you whenever each timer there we go oh come on
00:28:11.630
okay so we'll take a look at the since then so we have this chart here at the top which tells you the JavaScript
00:28:18.680
execution time delay Oh time and the actual network time so you know javascript is busy all the way through
00:28:24.980
trying to execute scripts and parse all of this content we have download time here at the top and we have the actual
00:28:31.430
layout information timing data that shows you what what the browser is doing at any given point in time and in here
00:28:38.600
you can see that we're trying to send different requests right for for different things and something caused a recalculation of the styling right so a
00:28:45.350
reflow of the page so you can drill into what each one of these so for example here i'm clicking on the evaluate script
00:28:51.170
and you can actually see which lines are getting invoked in the script how long
00:28:57.530
did they take what does get the heap size change perhaps you're leaking memory perhaps you're allocating a lot
00:29:02.990
of objects all of this data is detailed and available right within chrome right so you can going from the network
00:29:09.670
waterfall going to hear you can actually start analyzing specific scripts so in
00:29:14.870
fact this one's drifting here on the CNN page fires something like a thousand
00:29:20.420
timers I don't know why but it's it's once you look at this data it becomes painfully obvious so those are the two
00:29:28.550
tools that are that most people will use the the other one that i want to show
00:29:34.160
you quickly is tracing so this is
00:29:40.330
definitely more on the edge so let me i
00:29:46.310
press record let me just try and do something on the gauge some security errors sure let's go back stopped racing
00:29:53.980
and now we get this graph here which is actually a detailed view into exactly
00:29:59.720
what the browser is doing right so we started with the network analytics we looked at okay this this script is
00:30:06.590
executing something on the page and now we're looking at the internals of the v8 which says that for example let's zoom
00:30:13.250
in on this region here and we can look at the list here you can see that render
00:30:19.730
widget has been called 340 times there is some web view layout
00:30:25.280
implementations in all the rest so you're likely not going to be using this to optimize your web page a lot of
00:30:31.670
people that are building html5 games are similar will find a lot of interesting data in here because it'll also tell you
00:30:37.580
stuff about the GPU and other things but this is nonetheless a very good resource
00:30:42.620
to know about if you are optimizing your pages using this tool talk to me I'd
00:30:47.870
love to know what you're doing because that's awesome ok so dev tools gives you
00:30:57.919
a lot of power and a lot of flexibility but one of the things you may not know is that dev tools is in fact an HTML web
00:31:04.880
app itself there's nothing magical about it it's not some native extension built into Chrome or v8 or anything similar
00:31:11.120
it's a web app which is pretty sweet so let's take a look at what this means to
00:31:18.429
well actually demo this you can actually run chrome with a with a debugger or
00:31:23.809
with debugging enabled so I'll make this a little bit bigger so what I'm going to
00:31:29.840
do is I'm going to start another instance of chrome with a special flag called remote debugging port and you
00:31:35.570
specify any port you want so I'm just using 9222 which is the default so I'm
00:31:41.299
going to load that we have another instance here just throw this to the
00:31:46.880
side try and load a webpage there we go
00:31:54.610
awesome responsible design for the win okay so we had now we have the page here
00:32:02.110
right which is nice let's go back to here get out a full screen open a new
00:32:09.580
tab so these are two completely different processes right this is the cannery build I have running here and
00:32:15.670
then there is the regular chrome and now what i can do is i can connect to port 9222 and hey this looks familiar right
00:32:24.100
there is there's the tab that I'm viewing any other browser so if I click on this what would you expect you get
00:32:33.640
that tools so let's try that check it out so we're looking at the dev tools
00:32:41.220
for the page load at any other browser right so now we can do crazy stuff like
00:32:46.270
as I'm hovering over the dev tools and here it's actually highlighting it any other browser which is pretty sweet so
00:32:54.610
we can go into one of these guys that
00:33:03.360
too many things in here right you can actually like that at this dog you know
00:33:10.510
change it modify some styles do everything that you would expect in fact
00:33:15.580
we could even load the network tab reload this page and see all the data stream in directly right so this was
00:33:23.110
very very cool so you have all the same flexibility and power so why is this useful well you can use this to debug
00:33:29.919
your Android or on your on your mobile right so we actually announced Chrome
00:33:35.200
for Android and what you can do is you can hook up your phone via USB to your computer load the page on your mobile
00:33:41.380
phone via 3G or whatever Network and have all the detailed performance data right within your browser on your
00:33:47.260
desktop which is pretty sweet right so that's that's awesome what we can also
00:33:53.980
do is let me close this is you can actually chrome also exposes
00:34:02.540
I Jason endpoint that lists all the tabs and one thing you'll notice here is it's
00:34:07.700
giving you this web socket debugger URL so what does that turns out because the
00:34:14.660
chrome devtools is actually just a web app right and actually see if I can show
00:34:20.480
you just to prove the point that there's
00:34:26.780
nothing special about this we can actually open the inspector on the inspector all right and we can go and
00:34:37.160
look at resources there is there's a damn guy and like you know what I don't like resources so just going to delete
00:34:43.970
it right so there's nothing magical so in fact devtools is is a web app and the
00:34:49.460
way it's getting this data and the weights talking to the other browser is through a web socket so chrome exposes a
00:34:54.679
web socket or a JSON protocol that allows you to do all to analyze all this incoming data all the data that we got
00:35:01.280
about the network timing you can actually just get it in raw and I'll show you that by doing this thing here
00:35:08.630
which is so I have the script which will which I'll run and what it's going to do
00:35:18.350
is it's going to connect to this browser that I'm running with a debugger it's
00:35:23.450
going to tell it to actually go to Twitter and search for railsconf and it will just dumped a whole bunch of
00:35:29.630
networking data instead of printing it or printing it to the screen or laying it out and dev tools so there you go
00:35:38.830
write it we're loading railsconf and it's just you know scrolling text of
00:35:44.000
hundreds and hundreds of requests that are happening they're happening live and if I click on the old button you can see
00:35:51.950
more requests coming in right so this is chrome fetching the resources and it's spitting out all the debug information
00:35:57.440
about hey I started by zee nslookup hey finish the DNS lookup so and so forth so you know that's that's kind of cool
00:36:05.440
let's go back so we looked at that so what are we
00:36:13.190
doing here what does that script doing so it's actually just connecting to a regular web socket and the first thing
00:36:19.670
it does it does it sends a command that says network enabled and what that tells chrome is hey I want you to send me
00:36:25.670
network network debugging or a network events and then we send the second
00:36:31.010
command which says please navigate yourself to this specific URL right so
00:36:36.410
search for railsconf and then just print out all of this data to the command line
00:36:42.080
whenever you get a message so very very simple stuff and here's an example right we saw a lot of scrolling text this is
00:36:48.320
just one of the events which is response received and you know I clipped most of
00:36:53.690
it but we can see that for example the specific request was an xhr which is an
00:36:58.870
AJAX request for trends on that specific page it didn't reuse the connection it
00:37:04.760
didn't fetch anything from disk here's the timing data for when the request
00:37:10.220
started how long it took so on and so forth so there's a lot of detailed data in here right and you can in fact
00:37:15.380
instrument your chrome to set debug points get all kinds of stuff directly
00:37:21.230
from the CLI so why am i showing you all this well because I think there's a lot
00:37:28.460
of interesting tools that can be built right through this debugging interface there's there there's not a lot today
00:37:34.880
but i think this something that we as a community need to need to improve and
00:37:40.340
there's a lot of possibilities so there's Chrome for Android which allows you to do everything in mobile all the
00:37:46.220
same analysis and mobile we have detailed stats on the network on the DOM and the GS on the GPU everything right
00:37:53.270
we can do remote instrumentation even so maybe a year ago if we were having this
00:37:58.610
talk you know we could have stood here and lamented at the fact that there's no way for us to get up this data right
00:38:04.730
there is no navigation time inspect there is no remote debugging or the remote debugging is very limited that's
00:38:10.250
not the case anymore right we've removed quite quite a bit just in the past year so there's no excuse the tools are there
00:38:17.080
chrome is probably one of the most well instrumented platform you've ever developed for so that's all
00:38:25.750
cool right but now after this you're like well chrome is nice and fast but
00:38:31.020
how about IE right eight in singapore on a dsl modem well we have an answer to
00:38:40.420
that too so there's another project that actually started AOL but it's now being
00:38:45.849
maintained by a couple of Googlers and a few other companies called webpagetest org so if you guys are not familiar with
00:38:51.910
an awesome awesome resource let me show you what we can do so we can go to the
00:38:59.020
web page test org and we can actually pick a number of sites and a number of browsers so here I'm literally running a
00:39:06.220
test from Singapore on ie8 with the characteristics of a dsl connection
00:39:13.240
right and I'm trying to load CNN com and what it spits out is this waterfall
00:39:19.960
chart directly from my e8 and you can interact with it assuming this works
00:39:26.050
actually have a pre-loaded here so here's hear the results right it tells
00:39:31.300
us that the first you took about 10 seconds the second view because some of the resources were cashed took about 4.5
00:39:37.060
seconds we have this detailed graph here in fact you can see the waterfall difference between the first request and
00:39:42.760
the second request right so caching definitely helps we can also go into
00:39:48.070
content breakdown this is a very interesting section a kind of it
00:39:53.170
pre-loaded here there you go oh no so this is the waterfall view right so he can get detailed analytics for all the
00:39:58.450
same stuff directly from IEA you can click on this and maybe not right now oh
00:40:06.130
it's loading so you can click on each one of those and you can get all the same stats about DNS connection time tcp
00:40:12.820
time in all the rest so you can do this kind kind of analysis across the different browsers of course it's not as
00:40:18.640
well instrumented as for example chrome but you have the tools
00:40:25.480
so another thing that the web page test will give you is actually go back you
00:40:30.770
see this screen shot this screen shot was taken directly from IE and one of the things that web page test does is it
00:40:37.370
records everything frame by frame so you can actually give you a video of how the
00:40:42.410
page loaded so this is the video that a captured for me right so let's let's play this is ie so we're loading for
00:40:49.670
about three seconds four seconds in we get some content seven seconds in we get
00:40:55.520
the images at ten seconds the Dom content loaded is fired and at about 12
00:41:00.890
seconds in we get the ads and about 13 seconds in I don't know if you guys caught it we shift all of the content
00:41:11.120
down by about 15 pixels because we load the header right awesome awesome
00:41:16.190
experience so and once again I'm not
00:41:22.250
trying to pick on CNN I think they're actually doing a lot of things right right but it's just it's tough there's
00:41:27.700
hundreds of requests that are being made here the ads are coming in the images
00:41:32.930
everything so webpagetest can give you this data and this is actually a very
00:41:38.030
interesting way to look at to look at how the page is being rendered in fact we spent a Google a lot of time thinking
00:41:44.540
about this problem right it's not the case that we just want to measure the
00:41:50.390
final completion time right at about 15 seconds the page is in fact you can sort
00:41:56.570
of interact with it as soon as four seconds in right like the content some of the content is already there the
00:42:01.970
images come in at about 10 10 seconds in but you can still do something so how do
00:42:08.390
we measure this right how do we measure this visual completeness because it could be the case that page takes 20 seconds but you can in fact do a lot of
00:42:14.420
stuff even one second then so we introduced this new metric or we're playing with this new metric called the
00:42:20.420
speed index which is a way to measure or quantify how quickly the page visually
00:42:26.240
gets populated so how are we going to do this we're going to take a look at the same page right so we're going to render
00:42:32.870
to film strips think of it as step one has just render to film strips same pages right
00:42:38.550
web page test at the top we're going to have an optimized page and on the bottom the unoptimized page right so here we're
00:42:44.940
capturing frames about one second apart and once i can then on the optimized page most of the page is pretty much
00:42:50.700
render it's already there on the unoptimized page you can see that the body is still missing right so now we
00:42:56.220
have these two film strips so now we can kind of eyeball this and we can plot this and say that at one second in and
00:43:04.200
roughly let's say ninety percent of the top one is there visually whereas
00:43:09.290
fifteen or twenty percent is is there for the bottom one so we can actually produce a graph like this that says okay
00:43:16.410
one second then we're ninety percent done for the second page we're about eighteen percent done right so we can
00:43:21.690
plot this over time so then we do this trick which is to calculate the score we
00:43:28.380
actually look at the area above the graph of one of these one of these lines
00:43:33.620
right so very simple trick so basically we're looking at the area we're computing computing the score and the
00:43:39.960
lower the score the better right so you should aspire to a score of zero of course they're not going to get it but
00:43:45.890
the lower the better how do we actually determine alright so this is this is cute when you're sit down and you can
00:43:52.890
have do this manually but how do we do this programmatically how do we give you this number there's a lot of different
00:43:58.050
ways that you can determine how complete visually the pages it's actually a very interesting and tough problem if you
00:44:04.170
think about it we're using a simple trick which seems to work pretty well right now which is a color histogram so
00:44:09.390
we could we look at the distribution of colors on the page and it turns out to work actually quite well at least for
00:44:14.670
the apps that we're looking at at this point so the speed index number is
00:44:21.450
actually available on web page test org right so you can you can see that the
00:44:27.390
repeat view was it has a much lower speed index score that's that's what that speed index score is referring to
00:44:33.180
so very useful metric and something that we've been paying a lot of tensions who are playing with rather so a quick recap
00:44:42.450
so web timing API we talked about that Google Analytics very useful chrome dev
00:44:47.700
tools to help you optimize the page in your browser trying to figure out what's going on you
00:44:52.780
should absolutely test your pages in other browsers right in other geographic
00:44:58.300
locations webpagetest can help you with that and it's a free free app which is
00:45:04.000
great and then speed and the index is an interesting way to kind of quantify how how fast your pages are loading because
00:45:10.060
the load time itself often hides some of the nuances in there so now right we
00:45:20.680
have we've talked about what we're trying to measure we talked about the tools now we need to actually get to the
00:45:26.050
optimization part so there's a lot of different tools out there I'm going to talk about one family of tools that
00:45:32.619
we've been working on which is google page the family and there's a number of different products in here there's
00:45:38.050
online sdk and few others so online
00:45:43.210
service will basically allow you to just type in your URL and we'll run a bunch of heuristics and analytics on your page
00:45:49.690
and give you some recommendations so I pre-loaded this this is I'm running this
00:45:57.550
test on Rails con 2012 calm and it gave me a score 75 out of 100 it's a little
00:46:04.210
bit hard to see there but 75 out of 100 and in the on the side here it's
00:46:10.660
actually giving me a number of recommendations things like here's some high-priority fixes that you should apply right leverage browser caching so
00:46:18.550
it turns out railsconf 2012 com is actually not setting expiration dates on
00:46:23.859
most of its CSS or GI or JavaScript resources so every time you load the page you're forced to redownload
00:46:30.280
everything over and over again right so very simple things there's stuff like hey looks like compressions not enabled
00:46:37.150
either there's you can combine multiple images into CSS sprites so and so forth
00:46:42.850
you can actually defer some of the scripts so for example railsconf is
00:46:48.070
using google analytics but it's using the synchronous version which means that while it's trying to load that the gads
00:46:55.480
file nothing else on the page is being rendered right you can load that
00:47:00.820
asynchronously and speed up to page load time so there's a lot of recommendation that will give you and in fact you know
00:47:06.820
there's a lot of things that are gone well there's 15 things that rules that passed successfully so give it a try
00:47:13.390
just type in your site name any specific page and we'll give you some recommendations so that's bait speed
00:47:19.390
online base speed online also has an API
00:47:25.080
so you can easily automate this and run this periodically or for specific pages you can set different strategies things
00:47:32.740
like hey I'm actually interested in optimizations for mobile experience so
00:47:38.050
we have some different rules for mobile as opposed to desktop you can tell it to run specific rules so don't run the
00:47:44.320
whole battery of p.m. 50-plus statements just run this one specific one and you
00:47:49.510
know it's all available there be a JSON you just need to get an API key and you know go nuts build widgets all kinds of
00:47:55.960
stuff so that's nice but one of the problems is you know sometimes you're
00:48:01.870
developing something locally or perhaps on on your internal network you can't run an external tool on one of those
00:48:07.600
pages so one of the things we have is all of the code all of the rules behind yes all of the code behind all rules is
00:48:15.310
in fact open source we have an SDK it's available and we've actually made Chrome
00:48:20.590
Firefox extensions they can install directly in your browser and run on any specific page so if I go to this guy I
00:48:32.220
actually have PageSpeed installed so I can click on this all right this guy and
00:48:37.570
I can run page speed on this specific page and probably won't work at the moment because then the Wi-Fi is not
00:48:43.750
cooperating but you'll get a report very similar to the one that you saw on the online resource which you can expand and
00:48:51.100
it will give you specific recommendations for each and every page there which is very nice so that's cool
00:49:00.010
right but now we given you all these rules we made all the recommendations so
00:49:05.950
why not just automate it right and we can do that so another project that's part of the
00:49:13.080
PageSpeed family is this plug-in that we've been working on for Apache called mod PageSpeed so how many people here
00:49:19.800
run on passenger okay so fair number so I would definitely encourage you to try
00:49:25.920
mod PageSpeed it's basically a drop in output filter so what happens is rails
00:49:31.830
or passenger serves the content it then goes to mod PageSpeed mod PageSpeed runs
00:49:38.100
a whole bunch of rules on that content and there is will actually look at some of the rules in a second but you can do
00:49:43.980
all kinds of optimizations obvious things like combining JavaScript and CSS into single files so sort of like the
00:49:50.280
asset pipeline but it'll do much more so for example in here i'm showing you some of the directives that you can pass in
00:49:55.860
things like if the CSS is smaller than suta 2048 bytes just in line if
00:50:02.130
javascript is small in line it if images are small in line it by the way compress all the images for me automatically do
00:50:08.760
all of this for me right you don't have to touch your code it'll be done directly in Apache and serve to your
00:50:15.210
users which is very very nice you can you know apply things like remove all
00:50:20.940
the comments because you know your users not going to see them so to make it work
00:50:27.510
right enable passenger enable mod PageSpeed and you should automatically
00:50:33.210
inherit a lot of this performance so one of the things i will i will say is we
00:50:39.060
haven't made it very easy at this point to make it work so that's something i'm hoping we can improve in the coming
00:50:45.990
months so if you guys are working on this and trying to make it work you know ping me I'd be happy to to make it work
00:50:53.820
and I'd love to see some good case studies on us so let's see if I can load
00:50:59.610
the filters there's a lot of different filters that I can apply for you
00:51:06.020
doesn't seem like it once to load so that's cool that works for Apache right
00:51:12.080
but a lot of you were not running Apache so we also have this other service that's currently in beta it's at limited
00:51:18.800
beta only available to a few customers but we're we're playing with which is
00:51:24.230
page speed as a service so what you would do is you would actually just set your cname to one of the Google servers
00:51:29.330
and we would automatically do all of this work for you right we would optimize all of your pages all of your
00:51:35.150
CSS all of your JavaScript and also serve it from the Google CDN which you
00:51:40.970
know we have a few servers lying around the world so that should be a pretty significant win and I'm really really
00:51:47.120
excited about the service so stay tuned for more we're going to have some some great announcements later about it so
00:51:53.900
I'm really excited so you know we're out of time and there's still so much more
00:52:00.380
to cover right we didn't really talk about mobile optimizations we talked about Chrome for Android but you know
00:52:06.200
there's a lot more to be said there there's JavaScript and CSS tho those are entire talks on to themselves we have
00:52:12.230
the web p project which is trying to improve image compression if you think back to the CNN example most of the six
00:52:20.390
hundred kilobytes out of that thousand kilobytes were images you know if we can give you a ten percent saving on image
00:52:27.110
compression that's huge right where will be decreasing the load times by a significant amount there's a lot of TCP
00:52:33.860
and SSL and Colonel optimizations that we've that we've done internally at Google and also pushed upstream and
00:52:39.890
trying to push more patches upstream and of course there's speedy which is a if
00:52:45.170
you will an HTTP 2.0 proposal right which is now an ietf spec proposal so
00:52:50.480
lots of exciting stuff going on in there so with that and just a few concluding
00:52:57.020
thoughts the first thing you need to think about is what do I need to measure right before you stare down that sequel
00:53:04.880
query that's been offending you for the last six months go and look at your page
00:53:10.130
load times figure out where the actual bottlenecks are because chances are it's not the sequel query chances are it's a
00:53:16.040
javascript file that you don't even control are they just put there it's that social button from some unknown network that is now down
00:53:22.610
right that's delaying everything by two seconds second one is measured user
00:53:29.060
perceived latency right so that's just a hint from our experience measuring that
00:53:34.280
is the most important thing they could optimize optimize from users perspective you know don't focus on that sequel
00:53:40.070
query focus on the user's perspective use that as a forcing function keep in
00:53:45.350
mind that Mobile is a lot slower right and 1.5 is a very optimistic estimate so
00:53:51.800
there's a lot to be done there the tools are there right or largely there there's
00:53:58.610
been huge we've made huge huge advancements just in the last year but of course there's also you know
00:54:05.180
opportunity to build more and better tools and I'm hoping that you guys can actually help us do some of that work as
00:54:10.490
well so with that you can see the the slides so there's a bit ly faster rails
00:54:17.380
all the resources are there and I don't know if we have time for questions but I'd be happy to take any questions
00:55:05.190
bye