McQuade: Thanks, everyone,
for coming. How was your
first day at I/O? [cheers and applause] Awesome. We’ve got one more talk
for you. I’m Bryan McQuade.
Song: I’m Libo Song. McQuade: And we’ll be talking
about using Page Speed to optimize your Website
for mobile. So, feedback link, hashtags. So, we’ll start
with a little background on Page Speed itself before we dive
into mobile specifics. How many people here
are familiar with or have used Page Speed? Great.
Good to see. So, for those of you who aren’t
familiar with our tool, Page Speed is a tool
that performs analysis on a Web page, so you run
Page Speed on a Web page. It analyzes the content
that you serve. So your HTML, your CSS,
your JavaScript, your images, et cetera, analyzes
that, you know, the thing sent– the headers,
HTTP response headers content and comes back and generates
specific suggestions to make your page load faster
without changing the way that that page appears
in the user’s browser. And so, we’re available today
via browser add-ons for Firefox and Chrome,
via Page Speed online and Google labs,
pagespeed.googlelabs.com, which we launched
about a month ago, the Page Speed online API, which allows you to get
sort of the raw data, the raw Page Speed results data
and process that as you wish, which we launched
actually yesterday at boot camp, and then via some third-party
integrations with Web page test in the Gomez recorder,
which Amir Rozenberg, who is here today, will talk to us about
in a few minutes. And then yesterday in the
Word Plus plugin W3 Total Cache. So, W3 Total Cache now uses
the Page Speed online API to provide
Page Speed suggestions right in the Word Press
dashboard. And so, if you’re not
familiar with Page Speed, this is the UI,
the Page Speed UI here. And what you get–this is
one of our browser add-ons. What you get when you run
Page Speed on a Web page is you get
this sort of summary, which starts with a Page Speed
score at the top, 91 out of 100 in this case. And what the score
indicates is essentially how much room there is
for optimization opportunity on your page. So, a really high score
indicates that there’s very little
that Page Speed has to suggest to make your page faster. In other words, you’re
doing a really good job, and your page is really as fast
as we know how to make it. Whereas a low score indicates
that there’s lots of optimization opportunity
on your page. There’s lots of room
to make the page faster. So, in this case,
91 out of 100 indicates that this particular page, which I believe is
the Page Speed page itself, is doing reasonably well– a green checkmark. And so, underneath that,
we list the specific suggestions ordered in importance
for that page, starting with we see
leverage browser caching, defer parsing
of JavaScript. Each of these
is a Page Speed suggestion. The first one is yellow. So it’s a sort of
a medium priority. There’s also
a red category. In this case,
there are no red, sort of high-priority
suggestions. And so, you may look at this
and say, “Well, okay, “you know,
Page Speed says “I should leverage
browser caching, “or I should defer
parsing of JavaScript. “But what does that mean? What specifically
are you telling me to do?” And so, you can click
on any one of these headings and expand it.
So, in this case, we would expand
“Specify a cache validator,” one of the Page Speed
suggestions. And you can see
the specific suggestions associated
with that Page Speed rule. So, for this site,
these specific resources, we believe,
are missing a validator, and we sort of explain up top with a little bit of text
that by adding a validator, you can reduce the overhead
of content refreshes from the server. If you’re still sort of
wondering, “Well, what does that mean?” You know, “Why should
I implement this? Or what specifically
do I need to do?” You can actually click
on any one of these headings, and you’ll be taken to our
documentation on the Web, which goes into specific details
for each of these rules, and we’ll tell you, you know,
why you should implement this and how you can do that. And so, that’s Page Speed. And now we’ll look
at the agenda. So, we’ll be covering
four topics today, four sort of topic areas. First,
a Web performance overview, and then we’ll look
at key differences in performance for mobile and then based on that
information that we’ve covered, we’ll look at new Page Speed
rules targeted for mobile. And finally, we’ll do a brief
survey of tools available for mobile Web performance
analysis. So, first, we’ll do
a Web performance overview. And so, before we dive
into sort of the technical aspects
of Web performance, we wanted to spend
a little bit of time talking about why it’s important
to optimize your site, why it’s important
to make your site fast. And so, we’ve got sort of
three statistics here, two of these we actually showed
last year in our talk at I/O, and one that’s sort of new
and specific to mobile. So, first, Google did
an experiment a couple of years ago,
several years ago, where they added latency, 400 milliseconds of latency
to search results pages. And we observed that as
a result of adding that latency, there was a .6%– statistically significant
.6% search decrease in search interactions
as a result of that latency. And so, what we saw is that
by making the page slower, people used it less,
and, conversely, you know, making the page faster,
people would use Search more. And so, there was a–
you know, so that really drove the point home internally
that it was really important that we make our product
as fast as possible. And so, secondly, a statistic
that came out of the Velocity Conference
in 2009, Shopzilla did
a complete site redesign where they were focused
on performance and they were able
to actually make their page five seconds faster
as a result of that redesign. And what they saw is that
not only was their site faster, but they saw
a 12% increase in revenue and on top of that a 50%
decrease in hardware costs. And so, in this case, they saw,
you know, a faster site led to increased revenue and actually decreased costs
as well. And so, finally, a third statistic that we wanted
to share this year that came
from some internal work, when the Google Maps team
added one of the best practices that we’ll talk about
on a future slide, targeting mobile, using
an HTML5 application cache, they saw that their average
page-load time for the Google Maps products
for mobile devices went down by three seconds. So, implementing
that one suggestion had a three-second–
an impact of three seconds on their load time,
their average load time. And so, we’re starting to see
lots more interesting statistics come in internally, and we’re excited
to continue to share those, but what we’re seeing
is that consistently, where performance optimizations
make sense on desktop, they make even more sense
in the mobile space. So, for instance,
a three-second overview from one optimization is a
really substantial improvement. So, let’s go ahead and look
at the life of a Web page load. We sort of have
three components here. We have the server,
network, and client. And, of course,
the first thing that happens is the client says– you know, they want to fetch
some Web page. A request is sent
to the server. And the server spends
some amount of time processing that request
and generating the response. And so, typically,
we’re looking at, you know, a 100 millisecond, maybe
a couple hundred milliseconds to generate that response. And if you’re familiar
with Steve Souders’ work, you’ll know that, in fact,
that’s a minority of the overall
page load time. In the life cycle
of a page load– Steve talks about this
in his talks and in his books– in the life cycle
of a page load, that time spent generating
the results on the server is actually a very small part
of the overall page load time. The rest of the time
is spent on the network, you know, namely due to
bandwidth and round-trip. So, you know, if you’ve got
a lot of content on your page, you may be bandwidth limited. If you’ve got lots of resources
on your page, you’re gonna be issuing
lots of requests and round-trip is gonna
be a dominator. And then once that content
arrives back at the browser, we’re looking
at things like parse time, sub-resource fetches, layout and rendering,
which is clipped unfortunately, and JavaScript parse and
execution time in the browser. All contribute to the sort of
time it takes to load a page. Yeah. So, let’s look at this
sort of from a different view. We’ve got three columns here. We’ve got a client column, activity that’s initiated
by the client, server column, activity
initiated by the server, and then a third column,
the render state at that point in time. So, essentially, what does
the screen look like for the user
at that point in time? And so, what we can see here
is that the first thing the client has to do
in Desktop is issue a DNS lookup
which takes a round-trip. And essentially,
what’s happening here is, you know, the user types in
foo.com. Browser says,
“Okay, I need to find the IP address for foo.com.” They send that
to the DNS server. The result comes back,
then they can proceed. And the browser performs
a TCP connection to the IP address that came back
in the DNS lookup. And so, each of these steps here
is a round-trip to a server. And in Desktop,
that’s typically on the order of, you know, 40 milliseconds
to 100 milliseconds. And the worst cases,
it can be a second, but typically, you know, between, I’d say,
40 and 100 millis. And, so, then we begin
a third round-trip to actually send
the request to the server. The server begins
processing that request and begins returning data,
and finally at this point, after these three round-trips
have elapsed, we start to see content
render on the page. And so, at this point,
parse and layout starts to take place. The browser
discovers sub-resources, and the HTML content starts
to issue requests for those. We can see images
in the results page. And then those results
start to come back. More content is rendered. And eventually,
the page finishes loading. That’s sort of the life cycle, you know,
in this sort of client server and then what does it actually
look like for the client? And so, we can see here
that actually, you know, in the sort of typical
cold case, you know, the browser has to issue
a DNS lookup, TCP connection, and send the HTTP request– three round-trips
all before any content is rendered on the screen. And so, in a minute, we’ll look
at how that differs on mobile. Song: Next, we’ll talk about
the key difference on mobile. There are two types
of differences. One is the network. We all know our mobile, the round-trip trip time
is longer, and we have a lower bandwidth, and also the devices
is different. The mobile devices
have less CPU power and less memory and that there is
another unique difference. It’s the interaction model,
is quite different. The mobile phones or tablet
use touch screen and laptop or desktop
use mouse or track pad. We will talk about this
in detail later. McQuade: And so, first– so a minute ago,
we looked at the diagram with a Chrome
desktop browser Web server. So, now let’s look at, you know,
the differences in mobile. So Libo talked about
some of those differences. And so, one of the biggest
differences is that the device itself is not
connected all the time. It’s not connected
to a Wi-Fi network. It’s not connected to a–
you know, a hardwire like a desktop might be. And so, when it wants
to talk on the network, it has to establish
a connection. And so, as a result–we’ll talk
about that in more detail what that means
for mobile performance. But we see differences in
bandwidth and round-trip time as a result of, you know,
being on a, you know, talking over
to a cell tower. And then because the devices
are less powerful, as Libo mentioned, because
they’re relatively less powerful than, you know,
desktops or laptops, we see increased parse time
and increased JavaScript time. JavaScript parse and execution
times in the mobile space. And so, we’ll talk
about each of the categories that, you know, Libo mentioned
on the previous slide, the first of which
is round-trip times. And so, the most important
thing here is that initial mobile
channel establishment time can be substantially higher
than a typical round-trip time that we’re used to
on the network. So if the device–so if you
pick up your mobile device and you type in, example.com,
and the device has been inactive on the network
for about 10 seconds, at least on 3G networks, we’ve
seen that the time it takes to establish a channel
with a mobile tower is on the order
of about two to three seconds. And so, before the device can
even issue that DNS request to sort of say, what is
the IP address for foo.com or whatever site the user
is navigating to, you’re looking at a two-
to three-second delay, you know, while the device
establishes a channel with the tower. Now, once that’s done,
what we’ve observed on 3G is that the sort of active
channel round-trip times are substantially lower. So, you know,
on the order of between– as low as 40 milliseconds
up to 100 milliseconds. And so,
while in the desktop space, when we talk
about round-trip times, we’re used to thinking
about sort of a unimodal distribution
around a single average round-trip time, what we see is
that in the mobile space, for a single client,
there’s actually multiple modes. Multiple modes on the
distribution of round-trips. That one mode associated
with the channel establishment up around two to three seconds
and then a second mode for active channel
round-trip times in the 40-to-100-millisecond
range. And so, we’ll talk
in a future slide about what this means
for performance and sort of how you can build
your sites such that it’s not sluggish in the face
of, you know, these channel– high channel
establishment times. But before we do that,
I’ll just mention 4G may have different
characteristics. And initial studies
we’ve done look like that the channel
establishment time is substantially lower in 4G. It’s too early to say
for sure. But, you know,
we’ll be keeping an eye on that, and you should as well. As 4G rolls out, things
may improve substantially. But for 3G, anyway, the times
are on the order of two to three seconds, which
is just a huge latency hit. Song: The mobile network
has evolved so much recently, from the 1X, 2G, 3G, but compared to
the world network, it’s still
very low bandwidth. A typical 3G network now
has only about 800 Kbits per second
download bandwidth and about 400 Kbits per second
upload bandwidth. On the world network,
the bandwidth is much higher. We have seen studies showing
two megabits per second for the cable network. At my home, I have–
the Internet provider has 25 megabits per second
for download. So, the comparison
is obvious. 3G network has a much lower
bandwidth. The CPU power
is also obvious. There’s no doubt that
mobile devices still have a low CPU power. Here, we show a table
that shows my MacBook Pro running the JavaScript
benchmark, SunSpider. It has 427 millisecond. The Nexus IS,
it’s the new Google phone, it has more than
5,000 millisecond. The Samsung Captivate
has older Android OS. It has more than
12,000 millisecond. You can see clearly the desktop is still 10 times faster
than mobile. And so, in that case,
the JavaScript need more time to be parsed, to be executed
on your mobile phone or tablet. And also, it need more time
to render the layout. Because the phones
have less memory, it may need more frequent
garbage collection. And so, it’s extra. The other unique difference
is the interaction model. Desktop and the laptops
use mouse or track pad. It’s the same as mouse. But on your mobile phones
or tablet, use the touch screen. So, the mobile browser
won’t fire the click event until 300
to 500 milliseconds delay. At that time, the browser
or device decide that this is just one click,
not double click, not pinch,
not other interactions. McQuade: And so,
now based on the differences that we’ve covered,
let’s look at that same view, that same three-column view
for mobile. And so, as we talked about, the
most sort of significant change here is that initial mobile
channel establishment that the device
now has to perform when it wants to issue
a request. And so, you know,
that’s actually issued to the cell tower, which
is sort of a fourth component in this graphic. And so, I should mention, too, that that this is not to scale
in terms of, you know, amount of time,
as we talked about. We’re looking
at two to three-second mobile channel establishment,
and, you know, 40 to 100 to maybe several
hundred millisecond DNS lookup. So that channel establishment
actually should be substantially taller,
but we’re space limited And so, it’s not as big
as it should be. So once we establish a channel,
things start to look much more like Desktop, so we
see that DNS lookup round-trip, TCP connection,
HTTP request to the server, Content starts to come back. And here, now we’ve got
a mobile view, and it starts to render
very similarly to the desktop at this point. The device issues
its sub requests. That content
starts to come back, then the page view
completes rendering. And so, we see here, too, that,
that parse and layout step tends to take longer
on the mobile device because the device
is just less powerful. And so, in this case,
the Google search for mobile is actually substantially
simpler in terms of the number of DOM nodes
and the amount of JavaScript as compared to
the desktop version. So, even though
the device is slower, we see that it still
renders very quickly. And so, it’s important
to keep in mind that if you’re taking
a desktop app and you’re just gonna port it
over to the mobile space, you should expect
that that same desktop app is going to be on the order
of about 10 times slower when you port it over
to mobile. So, it’s important to be
thoughtful about, you know, “Do I really need all this
JavaScript in the mobile space?” You know, essentially, you know,
prioritize the content that’s most important in mobile and especially because the
screen real estate is less, too. You know, certainly,
there’s likely a lot of content that you can exclude
from that initial page view in order to make
that initial page view faster. Okay. So, we covered the key
differences for mobile. And now we’ll take some time
to look at Page Speed rules that we’ve derived
from these key differences. So, we’ll look at Page Speed
rules that we’ve added to Page Speed that you can see
on Page Speed online and our other tools
that will suggest essentially fixes that address
these differences in mobile. And so, there are five rules
that we’ve added. And we’ll go through
each of these. Use an application cache,
defer parsing of JavaScript, make landing page redirects
cacheable, prefer touch events,
and enable Keep-Alive. And these are–some of these
we’ve added already. Some of them are under
active development. You could expect to see them
added to Page Speed in the coming weeks
and months. And we’ll also be adding
additional rules going forward that aren’t listed here as we learn about new
mobile best practices. So, first,
use an application cache. So, the idea here–so, this is
actually the exact suggestion that Gmail mobile team– the mobile version of Gmail
implemented, and they saw
about a three-second reduction in page load times
for that application. And so, interestingly,
that matches–that correlates with that initial channel
establishment time that we talked about earlier,
2.5 to 3 seconds. It’s not clear that they’re
the same for that for a reason, but it’s interesting to note
that essentially what the benefit of using
the application cache is that you’re able to avoid that initial, very expensive
round-trip to the server because the content is cached
locally on the device. And so, that as soon as a user
types in maps.google.com, or whatever site
they may type in, that content starts to load
before it has to– before the request has to even
be sent on the network. So, the frame of the page,
for instance, the content that’s static
can display immediately and really let the user
know that, you know, this page is starting
to load quickly. You know, it’s there
and the idea is that the user doesn’t get sort of frustrated
or discouraged and leave. They say, “Okay, great.
Some content is loading.” And then as the network
becomes available, as the mobile channel
is established, the device is able to start
sending requests to fill in sort of the dynamic parts
of the page, you know, at a later time. And so, using a manifest
is an HTML5 feature, HTML5 application cache,
is a pretty simple thing to do. You just add a manifest
attribute to your HTML tag in your HTML document. That refers to a file,
in this case, you know, “my manifest”
on the Web server. And that page, which we’ll
actually see an example of this content in a minute
in one of our demos, but that piece of content
is just a list of resources that are used by the app. And so, it starts with
CACHE MANIFEST, all in caps, and then each line after that
is just a list of the resources that are used–
needed by that application. And another nice benefit
of using app cache, and actually the primary reason
app cache was added was for offline capability
on the Web. But it does have
that nice added benefit that even when you’re online, the content starts to render
and display immediately. And that’s actually
the reason that we like
the application cache. It actually has a substantial
performance benefit in mobile. Song: The next rule we propose
is to defer parsing of JavaScript, at desktop
of low CPU power, low memory. So, and there was–
parsing of JavaScript will put upfront time
for your page to be loaded. If your JavaScript don’t need
to be executed right up front, you can defer parsing them
or even defer load them. Here in this table,
I did some experiment to run four popular
JavaScripts libraries, and measured how long it takes
for iPhone 4 to parse them. We get the result. It’s almost
one millisecond per kilobyte. So if we can defer
parsing of them, your page will be showed up
quickly. And there are several ways
that you can defer parsing. One is if you can
defer load them, then defer loading
the JavaScript, that’s the best way. If you can’t, you can put
your JavaScript in literal string
or in the comment. In that case,
the JavaScript engine will parse them very quickly. That’s also at Google, the Maps team or the Gmail team
are using those techniques. McQuade: There’s actually
a nice blog post a couple of years ago
the mobile Gmail team wrote that goes into some more detail
about how they accomplished this that you can take a look
at on the Web if you search for, you know, mobile Gmail
performance, I believe, blog. Using your favorite
search engine, you should find that blog post,
and they’ll go into more detail. Song: The other rule we propose
to make your landing page redirect cacheable. We know that each redirect
involves at least a reconnection at a request
to round-trip times. If the host is not resolved,
you have another DNS lookup. So, there’s multiple round-trip
times involved in each redirect. For example, if example.com
redirects to www.example.com which redirects
to m.example.com, and then redirects it
to the final landing page, www.example.com/m,
there are three redirections. We have seen this parsing
in the real world. It may not be the real
example.com. So, to solve this problem,
if you make your– each of those three directions
cacheable so that when the browser
looks up the first URL, it will just use the cache,
and you’ll see– you’ll find all that
in page directly. This won’t save much
for the first visit, but for the repeated visits,
you will see the improvements. The first rule we propose
is to prefer touch events. As I have said before, this is a very unique rule
for mobile only. The other rules
we have proposed, they work–also work
on desktop, laptops, but those are more important
on mobile because of the network,
the CPU. But this interaction mode rule
is quite unique here because the phone
has this onclick event. If your event handler
listens to onclick handler, you won’t get the event
until the browser wait 300 to 500 milliseconds. Here I can show a short video
that demos the click. You can also go to the URL
I put there. Look at–
show the demo yourself. McQuade: So, if you have
a mobile device, you can actually
try this out. It really shows the difference
in sort of response time. Song: Yeah.
That won’t work on the desktop since the desktop
has no touch event. McQuade: We’ll show the video,
but it’s most compelling if you just try it yourself. You’ll really see
the difference in response time. Song: On this screen,
we have two buttons. One is slow button.
The other is fast button. On the right
is the slow button. If you click, you can see
there is some change in the text area,
but it won’t– doesn’t show the change
right away. But on the left, you can see
it’s more responsive. And also on the slow button,
if you click too quickly, the browser don’t know
what you are doing. So it just wait until you end
so it will sync up, finish this click. The last rule we propose–
to enable Keep-Alive for your server. Each connection need–
there are many resources in each of the Web pages. Each resource
needs a request. For each request,
you have to connect the server and send the request,
then receive the response. If the connection can be reused,
you will save the time to reconnect
to the server. Here in this chart,
I show connection wheel. That’s each row in this chart
is a connection. There are one request
on each of the row. The brown bar
shows the connection time. Green shows
the sending requests and awaiting the response. And the blue bar shows
the receiving time. We can see that every request there is a connection cost
up front. If you have enabled your server
to use Keep-Alive– I will show
the next chart. It’s the same 16 resources
and the same 6 connections. We have done this test
using webpagetest.org, which uses IE 8. It has a maximum
of eight connections per host. So, all those results
are on the same host. Here on the right chart, when the server
has enabled Keep-Alive, we can see on each row–
on the first row, there are four resources
and only one connection cost. The second row,
we have only two resources, because one of the resources
took longer. But overall,
we saved connection cost. McQuade: And so,
we’ll finish by giving a– doing a survey of tools
available to analyze mobile Web performance. So before we do that,
or as a first tool that we’ll talk about,
we’ll have Amir Rozenberg from Compuware come up
and talk about their use of Page Speed
in the Gomez Recorder, and in Gomez mobile products. So, welcome,
Amir Rozenberg. [applause] Rozenberg: Thanks, Bryan
and Libo, this was great. Hi, everyone.
My name is Amir, from Compuware Gomez APM. I’ll do the mandatory one slide
about who we are and what we do. And so, we are in the application
performance management business. If you have a Website,
a mobile Website, a native application,
or an SMS application, and you really care about it,
whether it makes money for you, or it’s a brand play
or whatever it is, we’re in the business
of telling you whether the application
is up, is it performing
in the eyes of your end user wherever they may be,
and if it doesn’t perform for whatever reason,
our job is to quickly tell you or give you enough information
to go and fix the issue that causes the performance
to be degraded in the view of the end user. And so, that’s who we are, and I am
the mobile product manager in the Compuware Gomez APM. And what I wanted to do today
is just to give you a couple of things that
we’re seeing in the marketplace and what we’re doing
with mobile Page Speed. And so, you know, mobile
is a terrific opportunity. You have an opportunity
to get closer to your end users and learn more about them and give them
really unique experiences, but what we’re seeing
is that mobile users really don’t have
a lot of patience with applications
that don’t really perform well or have all kinds
of latency issues. And so, a lot of users,
and, you know, check it out with yourselves,
you know, expect mobile experiences
to perform even better than desktop experiences, and you can think
about navigation applications or health care applications. If a physician
gives a prescription over the weekend
and so forth, They need access to information
rather quickly, and they need the experience
to perform really well. And so, what we’re seeing
is that, like I said, a lot of people expect the
experience to perform as well, if not better. And a lot of people are actually
unhappy with the experiences, and when they are, they’re
unlikely to come back to it. In fact, nowadays,
when, you know, it’s not so much anymore
about the carrier and so forth, many of them actually will move
to your competition, right? So there are many
applications out there. They’ll just choose
another alternative. And so, one thing
that we’ve done here is we actually measured
the abandonment rate by page load time,
and the really interesting thing that correlates well with
what Bryan mentioned earlier is those two seconds as the page
loads for the first time. And so, what we’re seeing
is that in mobile, users are actually
a little bit more tolerant of the experience and wouldn’t abandon it
right there and then. And what we’re hoping to see
is that indeed, the 4G deployment of networks
would actually reduce that and would give us
some more breathing room. However, what you can see
out there is that users on mobile
will abandon the pages or mobile native applications
pretty quickly after that, almost as fast as desktop Web. And we see that that trend will
actually increase over time. I’m sorry. And so, one of the things
that we’ve done with Google– we are also very much in line
with making the Web faster and making it much better. This is probably the key tool
that our users would be using to describe Web, mobile Web, and
native application experiences. We call that
the Gomez Recorder. And we’ve actually integrated
the Page Speed recommendations to every one of our users. And so, if you use this tool, you’d effectively go
to your Website and click through and go
through the various steps that you want to
then monitor, and then you run
the scripts again, and for each of the pages
that you go through, you will actually get
the recommendation of the Page Speed
as you’ve seen earlier with these stand-alone
Page Speed description that Bryan gave. And so, this is really
a tremendous help to our customer base,
because now not only they can, you know, become aware
of performance issues, post-production in the field,
but actually they can get recommendations
to what to fix on their Website
pre-production as they– you know, as they create
the experience. So, thanks for Bryan
and the team to give us those APIs
and let us use them. And that’s kind of my piece. McQuade: Thanks, Amir. [applause] Okay, so, now Libo and I will do a brief survey of other
mobile performance tools. So two that we’ve built
on the Page Speed team, and two that were built–
that are third-party tools, that were built outside
of our team. Song: The first one,
we will show Pcapperf that will help you analyze
your mobile device, mobile analysis that will show
that flow chart to see which requests
at what time and then you can see
the bottleneck of your Web page. McQuade: Second, we’ll talk
about Page Speed online, which performs Page Speed
analysis on Websites. It also has the ability to load the mobile specific
version of a page and perform mobile page speed
specific analysis on that site. So we’ll look at a demo
of that shortly. And so, another tool
that we’ll look at is a tool called JDrop
that was built by Steve Souders. And I’ll talk about that
in a future slide. Song: Lastly, we will talk
about Blaze.io that provides a service
to analyze your mobile set also and show work flow chart, and they have
provided video capture. First, let me show
the Pcapperf. Last summer, when we started
looking at how to optimize mobile Web pages, we found
that there are basically no tools for us to use
at that time. So, we looked around
and found that there are some HAR tools
that can show the work flow chart
from HAR format. And then there’s also
an Open Source product that can covert
the PCAP file to HAR, which PCAP is TCPdump–
capture of the packets. With those available tools then,
we’ve come up with this setup to capture the mobile traffics
and then convert them to HAR, and then show,
you know, work flow chart. So the setup is we run
TCPdump and workshop on the laptop computer. And the laptop computer
has two network parts. One is wireless
that can connect to a phone. The computer is set up
as an access point. So the phone connect
to the computer. And then the computer use
another network connection to the Internet. So all the traffic
on your phone goes to your computer
and then to the Internet. You run TCPdump or workshop
on your computer, you capture the traffic
and then save them to a PCAP file
and then you upload your PCAP file
to pcapperf.app.support.com. Magically, you will get
this work flow chart. Now let me show you a demo. This Pcapperf–so first,
I have uploaded some examples on the site, you can
just click real work flow chart. You can see
one of those examples. Now let me upload
one of the captures Bryan just did this morning
or last night. McQuade: So this was captured
using TCPdump just as Libo described.
And so, that’s the first step. If you–so before we do this,
actually–if you go to the site and click on how to capture
mobile traffic, it’ll go over the specifics
of how to use TCPdump to get the right data
and then– Song: And we have checkbox
to remove all your cookies so that if other people
happen to have the URL you have uploaded, they won’t
see your privacy cookies. If you want to keep them,
you can uncheck that box. So this shows
Google’s mobile site. At the top, we can see
there is “m? manifest.” That’s the application cache. And in a second, it will request
the www.google.com page. McQuade:
So, here’s actually the HTML. and we can look at that
and see indeed, oh– Indeed HTML, and here we go,
Manifest equals… And so, this is using that,
you know, using the application cache–
it’s something that google.com uses, you know, as an
optimization for mobile and then subsequently–
these are actually out of order in the display due to the way
the network stack is configured. But then you can see here’s
the actual manifest response. So, you know,
starts cache manifest and then lists all those
resources that google.com needs to actually render its page
as an application either offline or instantly as soon as
the user types in google.com. Song: And also, Pcapperf
integrated with Page Speed so if you run this as a HAR
with Page Speed, it will analyze this Web page to show what Page Speed rules
applies on this page. And I think that’s all. McQuade:
So, why don’t we look now– let’s take a look
at Page Speed online. So, I’ll go ahead
and do a demo of that site. So pagespeed.googlelabs.com. And here we go. I’ll actually
switch back to desktop. And so, we can enter
a Web page. Song:
Someone pick one. McQuade:
We’ll do CNN. Any site will do.
So we’ll run– So this is running a sort
of traditional desktop analysis, the Page Speed desktop analysis
for their desktop site. And so, what we get back here
first, at the top, you know, the page, this page,
you know, CNN, got an overall Page Speed score
of 67 out of 100. So that indicates there’s,
you know, some room for improvement
for CNN to become faster, you know, somewhere in
the middle essentially, right? And then over here
on the left, we get the same
prioritized suggestions that we saw on the screen
showing the browser extension. And so, the top thing
that this site can do is turn on browser caching. And so, if we click on that,
we get some information about, you know, what that means
and then if we’re curious, you know, “Okay.
How do I do that?” Or, you know,
specifically– Yeah, specifically,
“What does that mean?” You can click through
and go to our documentation and learn all about that,
and we’ll go into detail about the right headers
you have to set and, you know, what their–what optimal
settings are for those headers and all that good detail. So… Let’s find the actual, aha. And then, so, you know, there
are the specific suggestions associated
with each rule. So, in this case, we see,
you know, there are a number of resources
that don’t have expiries, and thus could benefit
from, you know, caching headers, which would allow them to be
read from the browser cache, as opposed to fetch
from the network when the user
returns to the page. And so, subsequently, you know,
we see each suggestion, you know, listed in order
of priority, but if we want to get a mobile-specific report
for the site, we can just simply click
“mobile report.” And then what we get back
is a very similar-looking page, but the differences here are
that the mobile-specific version of the site
has been loaded. And so, the first thing
we see, actually, is that the site www.cnn.com
redirected to m.cnn.com, the mobile-specific version
of the content. And so, we get a page
speed score here, 61. A little bit, different score,
but in the same ballpark. And we see suggestions
over here on the left. And in fact, leverage browser
caching comes up as the same, you know,
highest-priority suggestion. But if we click through,
what we see is that the specific resources
being analyzed and suggested for caching
are entirely different from the desktop version. And so, using this tool makes it
really easy for you, if you have a mobile-specific
version of your site, it makes it really easy
for you to analyze the mobile-specific version,
whereas it can typically be harder to do that
using a desktop browser if you’re using
the Firefox add-on or the Page Speed add-on
for Google Chrome. So, in addition,
we’ve got some other rules in the Page Speed online
offering for mobile analysis. In our experimental section
right now, we have a suggestion to use an application cache. And right now it’s–
you know, simply says, essentially,
use an application cache and if you do that,
the page will be faster. Going forward
in the coming weeks, what we’ll do is we’ll actually
provide what we believe is an optimal application cache
for that page for you, so you can just take
that content and use it. Of course, we’ll be clear here,
and I’ll say now. It’s always important
to, you know, look at the suggested content and make sure
it really does make sense. We’ll do our best, but you know
your site better than we do. So, we’ll give you
as much information as we can, and then, you know,
you can go from there. So that’s Page Speed online. So the third tool is a tool
called JDrop, jdrop.org. It’s built by
Steve Souders and launched recently
in the last few months. And the idea here is that
there’s all sorts of analysis you’d like to do
on your mobile device, you know, be it looking
at the DOM on the page or at the content
of the HTML document, looking at local storage,
other HTML5 properties. But analyzing that content
on this tiny screen is really not a pleasant
experience, right? You’ve got this tiny screen. You’d much rather look
at that content on your desktop or laptop,
big screen, you know. And so, the idea with JDrop is
that you log into JDrop here and on your laptop or desktop,
you perform analysis using bookmarklets
on the mobile device, and then post the results
of that content to JDrop, where it’s stored, and then because you’re
authenticated on your desktop, you can see those results
on the big screen. And so, the nice thing
about JDrop, too, is that it’s totally plugin
based and totally extensible. So, they’ve got lots
of really great bookmarklets that you can use today. But if there’s something
that’s missing that you’d like to add,
it’s very easy to add a new bookmarklet that does
new kinds of analysis. So that’s JDrop. Song: Last tool we want
to talk about is Blaze.io, which provides a service. You don’t have to use
your own mobile devices. They can–they provide
three devices now. You can choose one of them
to run the URL you want and then it will tell you
an overview of how long it took
to load the page and what’s the size of the page,
the total number of bytes. And also it can give you
a screen shot of the site, and also they have
this work flow chart. You can analyze
the requests that– the bottleneck
of the requests. Lastly, it has
video capture. You can just see how your page
is loaded on the phone, if you don’t have
so many phones. If you develop a Web page,
you can just run those phones without buying them yourself. McQuade:
So that’s our talk. To summarize, we’d like
to emphasize two points. The first is that, you know,
the unique characteristics of mobile networks
and mobile devices present new optimization
opportunities. So, things like the mobile
channel establishment time, like we talked about,
and limited CPU and memory of the devices
means there are new, you know– both new optimizations
that we need to perform to make our mobile Websites
fast, and also sort of reprioritization
of existing optimizations based on these
new characteristics. And so, second, you can use
Page Speed and these other tools we’ve talked about
to understand your performance and to optimize your site
for mobile performance. Any questions? And if you do have questions,
please step up to the mic. [applause]
Thank you. man:
Hello. I was wondering, is there a way
to tweak the user agent that you use so that if you
want to test the tablet version of a certain mobile version? McQuade:
From the desktop browser? man:
Yeah. McQuade: Yeah, so,
you can actually– So in Chrome–
So that PCAP file, actually, I cheated a little bit,
and I told Chrome to use a mobile-device user
agent when I did that. So you can–
In the Chrome case, you can do “–user-agent”
on the command line and specify a UA,
whatever you want, and the nice thing about using
a browser like Chrome or Safari is that many of the browsers
on mobile devices are Web-based, as are Chrome and Safari. So you can expect content
that’s targeting mobile devices to render correctly
in those browsers. man: So, but what about
from your Website, you know, when you can run
view mobile report? McQuade: Oh, the one that–
Page Speed online? man: Yeah.
McQuade: Yeah. It actually does
the same thing. So it uses a Web-based
render in it. It uses a different user agent
to essentially tell the server, you know, to look like
a mobile device or a desktop device.
man: But can you tweak that one? McQuade: Oh, can you override
that as a user? We don’t provide
that capability today, but it’s something
we could do. man:
Thanks. McQuade: So, we’ll
think about that. Thanks. man: I had a question
about the manifest file that you showed
for google.com/m. McQuade:
Uh-huh. man: Towards the bottom,
you actually had– There weren’t any resources.
They were just domain names. McQuade: Oh, they were just–
I’m sorry? man: They were just
domain names. They weren’t any resources
actually at the domains, and it looked like they were
sub-domains of maybe image hosting static domains
that you were using. McQuade: Yeah. Let me
go ahead and look at that. So, I actually don’t work
on search–on mobile search, so we may not be able to answer,
but we can look at it and see. man: I guess the only–
I was curious, yeah. Some are there.
McQuade: Uh-huh. man: So is that–you’re not
actually looking for a resource. Why are you doing that? Is that because you’re kind of
caching the IP address so that you don’t have to go
back and do another DNS query, or what’s the purpose of that? McQuade: Which one?
man: Further down. YTimage.com.
You’ve got I1, I2, I3, but there are no resources
thereafter. Usually–In the example you
gave, it was my.css and my.js. McQuade:
Sure. Yeah. That’s interesting,
actually. So I actually don’t have
a good answer. That’s a really good question. I think you’re probably right. It’s probably a pre-resolve, or it’s white listing
in those domains. I actually don’t know.
I’m sorry to say. I wish I had an answer. One of the things that we found
in our research with manifest support is that,
because it’s relatively new, different browsers
have different spec compliant or quirks. And so, in fact, we–you know,
there’s this nice feature of manifests that is you can
have a network section where you basically say, “Here
are the things I think I need.” And then you could say,
“network:star,” and that essentially means,
“Anything I didn’t declare here, go get it from the network.” And we’re like,
well, fantastic. That means that, you know,
if you forget it, at least you can fetch it from
the network if you’re online. Turns out– Song: Some browsers
does not support this feature. McQuade: Yeah. So, it may
very well be that these lines are working around
sort of quirks in current browser
implementation. Or it may have something
to do with the spec, but it’s not immediately obvious
to me what’s going on there. It’s a good question. I’ll actually,
if you sync with me afterwards, I can take your email
and try to find out. man: Okay. And then I had
another question. You didn’t talk
about Web sockets at all. I think I read somewhere
that if you use Chrome and you use google.com, it uses Web sockets
more than HTTP. I don’t know
if that’s accurate or not. McQuade:
It may be that– So it uses
the Speedy protocol. I don’t know that
they’re making extensive use of Web sockets today. I think as–Certainly
Web sockets is the kind of thing that we’ll start to suggest
as it becomes sort of more proven
and more well used. At this point, we’ve seen
some issues with Web sockets around, you know– Essentially proxies sometimes
can get in the way. HTTP proxies or ports
can be blocked if you’re doing it
on a non-standard port. And so, we’re sort of waiting
to see how that plays out over the coming months,
and then–or, you know, six months, say. And if things look good
at that point, we would certainly recommend
using Web sockets, because they have
some nice characteristics… man:
Thank you. McQuade:
…for performance. Yeah. man: Hi. Have you seen
the strictness of the page having a page load
time impact? So if you have a page
with a lot of TagSoup in it, you know, like it’s not
well-formed DOM, does that make
a big impact? I didn’t see it as one
of the line items up there in the recommendations.
McQuade: Yeah. Today we don’t suggest
well-formed HTML. We haven’t seen any compelling
evidence that suggests that it will load
more quickly. If we saw information
that did suggest that– so let me just bring up
the response– we would certainly–that
actually looks very well formed. Traditionally,
major sites actually have not served
well-formed content. man:
Right. McQuade: And so, we–
in our test labs, as I said, we haven’t seen any difference
when we do AB tests, and it also seems
that other sites either haven’t
investigated it themselves, or if they have, they haven’t
seen any difference either. But I will say, if somebody
shows that there is a substantial difference,
you know, for some aspect
of well-formed HTML, we would absolutely add that
to the Page Speed rules set. We just haven’t seen
evidence of that yet. man: ‘Cause I’ve heard
anecdotally, that TagSoup,
you know, causes the– you know, like Firefox
to go into a failure case, and sometimes
if it’s, you know, it’ll have to go into a backup
or lookup or something like that. But I haven’t heard any proof
one way or the other that it actually
makes a difference. McQuade: We’d be glad to–
So we have a mailing list, page-pagespeed-discuss
on Google groups. if there’s a link
or something like that that you can point us to,
we’d love to know about that. And we’d certainly
add suggestions for that if that proved out. man: Thank you.
McQuade: Yep. man: Maybe an obvious question,
but I have to ask it. Would you recommend against
using GWT for a mobile Web app? If so, why in particular
and if not, can you say anything about optimizing such a Website
with Page Speed. McQuade:
Sure. So, the first thing
I’ll say, actually, is that there’s a talk tomorrow
about using GWT to build high-performance
mobile apps. And so, I would–that talk will,
I think, give you a better idea for, you know, performance. And I certainly know, too,
that the GWT team from the beginning has been
very mindful about performance. And they actually try to roll
in a lot of these techniques into their compiler so that you
don’t have to think about them when you’re building your app, but you automatically
get things that we suggest, like deferring unused
JavaScript, minification of content,
spriting, and things like that. So, while I don’t know
specifically in the mobile space
of any issues, positive or negative with GWT,
my expectation is that it’s– they’re probably
very high performance today, and the nice thing
about using GWT is that as they– they constantly improve it,
and so, you’ll benefit from those improvements
automatically. man: So, would you say
there’s less need for an analysis tool
like that? McQuade: So, hmm.
That’s an interesting question. So I certainly
would always run– so I’ll give,
actually, an example. So pagespeed.gogglelabs.com
uses GWT, actually. And one of the things
we did initially was we sort of–there’s some
browser-feature detection that GWT likes to do, and that, by default,
runs client side. And so, we ran some
Page Speed analysis and we saw, “Oh, okay, that’s
actually add some serialization, some performance impact.” And so, we actually–
we either had just rolled out, or about to roll out
an optimization, where we do
that detection server side. And so, that’s something
you can do with GWT. It’s just may not
be turned on by default. And again, I’m not
a GWT expert, so I would recommend asking
the guys speaking tomorrow. But I think it makes sense
to use both tools. GWT will do a lot for you, but it’s always good to,
you know, sort of double-check and make sure with a tool
like Page Speed. man: Thank you.
man: Bryan, can I jump in? This is David Chandler.
I am on the GWT team. And that’s a great answer
that you gave. I’m the one giving
the talk tomorrow. McQuade: Awesome.
man: And, yes. It’s still worthwhile
to use the tools, because there are
features in GWT that can be used
to improve performance. One of them, for example,
that we’re working on for the next few months
is an app cache linker that will automatically generate
that manifest for you. But you’ll still want to run
Page Speed first to determine that you can benefit
from that kind of a thing. So, thanks.
McQuade: Great. man: Hi.
Two questions. First, what in the manifest–
what is your guys’ strategy for, like, in the case–
the example you gave, like, you’re caching out
some JS files. What if you need to pop
that JS file? Do you just rename it
something else? Or, like, how is the manifest
structure work in terms of telling it, no,
there’s a new version of that you should be using? McQuade: In terms
of changing the content? Song:
Yeah. The application cache
is relatively complex thing. If you have the application
cache on the browser side and you are changing the
resources on the server side, the browser
may not notice that until you change
your manifest itself. Then the browser will start reloading
all the resources again, at least to check
if it’s changed. One technique is to change
the name of your results. And then this can be done using
more pages. If you change your content, it will automatically change
the name of your resources. It will solve the problem. And then you have to regenerate
the manifest. That’s another problem
that needs to be solved. man: I see. And then,
I was kind of surprised at how high some of those
numbers were in Froyo for the JavaScript rendering.
In cases like that, it almost seems like
you could make a good argument for depending on the
functionality of the page, to just do it all
server side. Is that an accurate assessment?
McQuade: Yeah. I think that’s a very–
a reasonable way to address– So, one of our suggestions is
to defer parsing of JavaScript, and one of the ways
to accomplish that is to do as much as possible
prerendered on the server, because you’ll have
more CPU there. So the user–
if you do that, I suppose– you want to be mindful that
you–so, another technique that is wise to use
is called chunk encoding. The idea is that you
push data down as it’s generated
on the server. So if what you’re doing
is really CPU intensive, you don’t want to block
sending the first byte back to the user
on all that work. And so, using chunking
in combination with server-side rendering,
I think, would be a great way to speed up mobile performance. man:
Okay. Thanks. man #2: Can you talk
a little bit more about HTML5 application cache
and, like, what types of things you’re caching
and whether that’s for, like, targeted at specific devices
or just, like, in general, or just wanted to know
more about that. McQuade: Sure.
Do you want to start with that? Song:
Yeah. HTML5 application touch,
I think it’s a relatively new, older browsers support–
most of the Web page browsers support
HTML application cache. But there was a bug
that we just found out that if you used the network:star, that basically means
everything else not listed in the application cache
go to network and download them. But the older implementation
of WebKit does not implement
this rule. So if you left them out, those will stack
on the browser cache. So you will never get updated. That I found out the hard way. McQuade: In terms
of browser support, I think all the sort of most– I actually don’t know
about IE 9. Does anyone here know
if IE 9 supports app cache? I can’t say. So the nice thing
about app cache in mobile is that the predominant devices
in mobile use WebKit. And WebKit
has very good support. And so, you know,
iPhone and Android both have really great
app cache support. And so, while on Desktop– it actually has a benefit
on Desktop as well. You know the page will load
instantly on Desktop, and it makes sense
to use it. But you won’t reach all
your desktop users, because not all of them
have support. The support is, you know,
virtually everywhere for mobile users.
man: Cool. McQuade:
And it’s improving, too. I would definitely recommend–
based on what Libo said, definitely test
on a variety of devices whatever you have available
just to make sure, because it is changing
rapidly, too. So if you can test
a generation or two back, it’ll help you to find bugs
as you roll that out. man: Cool.
Thank you. McQuade:
Hmm-mm. Okay, 38 seconds left. Anyone?
One more? Thank you.
Song: Thank you. [applause]

Google I/O 2011: Use Page Speed to Optimize Your Web Site For Mobile
Tagged on:                                     

8 thoughts on “Google I/O 2011: Use Page Speed to Optimize Your Web Site For Mobile

  • May 12, 2011 at 10:45 pm
    Permalink

    Great work Amir! @29:00

    Reply
  • May 31, 2011 at 12:51 am
    Permalink

    Do you have a link to the slides shown in this presentation? Regards.

    Reply
  • April 23, 2012 at 7:23 am
    Permalink

    hope you can share your slides, hehehehe!!! anyway it is a good presentation

    Reply
  • February 20, 2013 at 1:27 am
    Permalink

    I don't understand why people unlike this?? It's FREE KNOWLEDGE TO HELP YOU!!

    Reply
  • February 20, 2013 at 1:38 am
    Permalink

    However, design for these slides kind of suck

    Reply
  • March 7, 2013 at 12:23 pm
    Permalink

    Howdy! Have you ever heard about the "Phantom Cash System"? I found it on Google Search and listened to a lot of awesome stuff about it. Some of my mate also recommend me to try it

    Reply
  • October 11, 2013 at 3:53 pm
    Permalink

    So called because there's actually no cash, it's just a phantom?

    Reply
  • July 9, 2014 at 8:59 pm
    Permalink

    Teşekkürler arkadaşlar çok güzel bir anlatım olmuş. Alt yazıyı okuyarak biraz zorlandım ancak 59 dk. tam olarak durdurarak ileri duşları ile biraz daha gelişe ayak uydurmaya çalıştım. Ancak; anlatım ve sunum İng. Dünaya genelinde sunumları dil olarak herkesin anlaması mümkün değil. Bu işlemde anlamayı %15 zorlaştırıyor.Anlatım çok ileri düzeyde yapılmış. yani Geliştirici modunda anlatım olmu. Çok basit bir blog üzerinden basit bir yazıya uygulama yapılarak anlatılmış olsa Dünya genelinde birçok kullancı daha fazla anlayacak ve anadıklarını yazacaktır. Buda anlatımlarınızın dah fazla kitleye ulaşması olacağı kesindir. Küçük ve yapıcı bir eleştiri! Anlatan, dinleyen ve yorumlar bölümü kapasatite olarak ileri düzeyde geliştiriciler kapasatesinde.  Youtube beğeni ve dağılımına baktığımızda çok düşük bir kesimi oluşturuyor.Bence bu konuyu ön planda tutmanız daha verimli bir paylaşım ve okuyucu yayılımı olacaktır diye düşünüyorum.
    Tekrar teşekkür ederim.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *