Tip:
Highlight text to annotate it
X
MALE SPEAKER: Website speed is a feature.
Web performance optimization developed with Google
explores performance patterns for world class site speed.
Dive into the critical rendering path uncovering
how browsers convert HTML, CSS, and JavaScript
to actual pixels on the screen.
You'll learn how to leverage recommendations
from PageSpeed Insights and data from Google Chrome's developer
tools to immediately boost website performance.
For more information, visit udacity.com/google.
PETER LUBBERS: Hello, and welcome to our ask the experts
session for our Google Udacity web performance optimization
training course.
The course just went live a couple of months ago.
And I'm here with the instructors, Ilya Grigorik,
developer advocate at Google who wrote
a book on web performance.
Cameron Pittman, course developer at Udacity,
and I'm Peter Lubbers, a program manager
on scalable developer training.
So in this ask the experts session,
we're going to cover a little bit of the basics of why
performance matters, what the critical rendering path is,
and what it has to do with performance.
Then a little bit about the tools that you need to measure.
One of the big things in your course
has been measure first and then optimize.
So how do you measure?
And then we'll answer all the questions
that have been submitted in the moderator.
So let's start with the basics.
Why does performance matter for web pages and web apps?
ILYA GRIGORIK: Sure, well I don't think any of us
like staring at a blank screen or waiting for the next page
to load, right?
So this would be a pretty simple one.
But it also helps with conversion,
user engagement, more pages.
Simply put, speed is a feature.
And for many apps, it is the killer feature.
Think of something like Google search
where speed is one of the primary features on top
of, obviously, good content.
PETER LUBBERS: So then the course
targets the critical rendering path part of performance.
There's many different aspects.
And one of the nice things about this course, it's very short.
I actually have to admit, I just took it yesterday
in preparation.
So one of the nice things about that is you
can take it in literally an afternoon or evening.
And I've really enjoyed it.
So tell me a little bit about the critical rendering path.
What is that and how does it relate to performance?
CAMERON PITTMAN: Well, like Ilya said,
nobody likes staring at a blank screen.
And so some websites, they'll load,
but the screen would be blank, and then
all of a sudden, everything will appear.
But other websites do a good job of rendering progressively
and showing more and more content as time goes on.
And essentially, the critical rendering path
is the set of steps browsers have to take to load websites.
And the course is all about understanding that set of steps
and manipulating it.
I like to think of it as sort of a game.
The steps can happen in different orders,
and there are tricks to the way you develop websites
to make pages render progressively
and as quickly as possible to get those first pixels
on the screen in as little time as possible.
PETER LUBBERS: Now measure first, optimize later.
To measure things, you need tools.
What are the tools-- the go to tools for you in this course?
ILYA GRIGORIK: We cover a lot of different schools
throughout the course.
So you get to interact with different tools,
actually, as you go through the course.
But in particular, I think we focused on Chrome dev tools
PageSpeed Insights.
CAMERON PITTMAN: And particularly, the timeline tab
in Chrome tab tools.
PETER LUBBERS: Sure, sure.
Yeah, there's a lot of other features.
ILYA GRIGORIK: So the timeline gives you
kind of a low level perspective into everything
that's going on in the browser.
And, to be honest, the first time
you open it, if you haven't seen them before,
it's going to be very overwhelming because you hit
the record button and before you know it,
you have pages and pages of events.
With cryptic names like layout and farcing this farcing that,
and it's very hard to understand what's happening.
And the incent of our course is to first explain those concepts
and how they relate to performance such
that you can optimize that loading sequence.
PETER LUBBERS: Yeah, I liked a lot of the answer videos
for the quizzes and how you, for example,
would uncheck a little box, all of sudden,
made some sense out of this massive amount of data.
CAMERON PITTMAN: Yeah, you can filter by what types of events
you want to see and filter time wise-- see chronologically,
decide what period of time you want to investigate further.
PETER LUBBERS: Yeah, so definitely
check out the course.
If you haven't taken it, it's on udacity.com/google.
Look for the web performance optimization course.
A lot of great tips and tricks and is a fairly
condensed course.
ILYA GRIGORIK: Optimized.
PETER LUBBERS: Optimized.
Highly optimized.
So let's talk about some of the questions
that the students have added on the moderator.
And we've also posted some of the answers
in the moderator themselves.
We've added some links.
So definitely, if you've asked the question,
go back to the moderator and look
at some of the detailed answers that are in there.
But we'll cover that in this session as well.
Let's just dive right in.
The first question is from Juan, the top voted question.
"Can you share some real numbers of the differences
when serving a site via pure HTTP, SPDY, HTTP 2.0, QUIC?"
For a simple page, there doesn't seem
to be much of a difference.
At what point does it start to matter
that you use all these new found--
ILYA GRIGORIK: Really interesting question.
We actually don't get into this in the course
in terms of how do you deliver resources
over these different protocols.
So for those that are not familiar, HP 2.0, HP SPDY,
QUIC are all different variants of how the data actually
gets delivered to the browser.
So in terms of actual real numbers,
HP 2 and SPDY are basically the same.
HP 2 is still in development, so it's really hard
to talk about real numbers, because really we
don't have production experience.
For SPDY, I've shared a link in the answer there.
On average, for Google services where we've deployed SPDY,
we've seen improvement of somewhere
in the neighborhood of 30 to 40% in terms
of delivery of resources.
So you get them 30 to 40% percent faster, which is nice.
Now the question of about what's a simple page
is kind of a tricky one, because I'm not sure what that means.
When I look at something like HP archive,
an average page today is like 60 resources
and two megabytes in size.
So is that a simple page?
PETER LUBBERS: Yeah.
Or is it one of the ones you use in the course
to demonstrate the Hello World type example.
ILYA GRIGORIK: Right.
So I think it depends on context.
You should measure--
CAMERON PITTMAN: And then optimize.
ILYA GRIGORIK: And then optimize.
So I think that's where you start.
And for QUIC I guess I should say,
that's also still in development.
So we don't have any kind of production numbers.
If you're curious, we actually have QUIC
enabled on some of the Google services.
So when you exit, it runs over QUIC.
But it's still mostly at a stage where
we're trying to make it work right, not make it fast.
PETER LUBBERS: Well, and I think anyone can basically
take their page, however simple that may be,
and run it through PageSpeed Insights,
see if you can improve it and if it's worth the effort, I guess.
So there you go.
So the next question is from Stewart Memo
in Glasgow, Scotland.
So that's great.
We have a lot of international questions here.
So "is it better for me to have one large CSS
file that gets cached for all pages?"
And then this is something that was specifically
covered in the course.
"--or should I have a basic base file that gets cached and have
smaller per page files?"
And remember, you talk a lot about InLine,
some CSS and JavaScript.
And so is there some general guidance?
CAMERON PITTMAN: You know, I think
yes-- the general guidance is measure first.
PETER LUBBERS: I get it now.
CAMERON PITTMAN: You know, it depends.
In some cases, if you want that first page render to happen
much faster, it's probably a good idea to inline the CSS
or just deliver as little as possible.
But if you think a user's going to be
on your site for a long time, maybe navigating
to different pages, maybe it makes more sense
to deliver the large file and cache it.
It depends.
You've got to measure first.
PETER LUBBERS: Yeah, that makes sense.
ILYA GRIGORIK: One thing I would consider--
when you think about small files or large files
is what's the content of those files?
So let's say you have five files.
And some of them are updated frequently and some of them
is like a library file that is just static,
you don't need [INAUDIBLE].
If you put that all into one bundle
and you update that one little bit in the file that
changes frequently, you have to re-downloan
the entire bundle, which is actually inefficient.
So you would actually get better cache reuse
if you separated them.
So those are the kinds of things that need to play with.
And also, on different pages, let's
say you can separate the logic and say, I only
need these functions on that page.
Well, to me, it makes sense to load
only those things on that page.
So unless you're running into like-- unless we're
talking about dozens and dozens of script files,
I wouldn't really go as far as bundling it all together.
If you just have a couple of script files, that's fine.
Because we can download those, or the browser
can download those in parallel.
And especially-- coming back to SPDY and QUIC and HP2-- there,
those restrictions don't exist anymore.
So we can download as many files as we
want as quickly as we can.
PETER LUBBERS: Yes.
Perfect.
Well, next question is from [? Uragos ?] in Greece.
"I'm developing mobile web pages for markets
with slow mobile internet.
My impression is that HTTP compression inhibits
progressive rendering and gzipped
pages take longer to start showing.
What gives?"
ILYA GRIGORIK: I'm not sure what gives,
because that's unexpected.
I would not expect gzip or HP compression
to affect us in any way.
Perhaps there is a really slow server
and it's having a really hard time trying to compress data.
But that seems silly too, because compression's
pretty darn fast.
[INTERPOSING VOICES]
PETER LUBBERS: --you would say just-- let's say,
shouldn't be a problem, of course.
ILYA GRIGORIK: Oh, in fact, compression
should help because by reducing the amount of data
you need to ship, the data should arrive faster
to the browser.
At which point the browser can stream to code gzip data.
It doesn't have to wait for the entire file to write.
So there should be no reason, short of like,
it takes a long time to generate the gzip asset for some reason.
PETER LUBBERS: So maybe a good thing [? Uragos ?]
has to really measure using the tools in the course, what's
actually happening and come up with some more detailed
analysis--
ILYA GRIGORIK: --yeah, that's the first thing I would look
at, is open up the network waterfall
and just compare with gzip on and gzip off.
Like, is there a response time difference in how long
it takes to fetch that?
Because my only guess is it has to do something
with the server.
There's nothing in the browser that
would make that statement be true.
PETER LUBBERS: Yeah, exactly.
Hopefully that would be true.
ILYA GRIGORIK: If there is, then there's a bug.
And you should let us know.
PETER LUBBERS: Which you can do.
You can file bugs specifically against Chrome, you can use--
ILYA GRIGORIK: --yeah, crbug.com--
PETER LUBBERS: --crbug.com.
Next question from F. Goldenstein
in Buenos Aires, Argentina.
So we're going all over the world here.
"If you have to get many different entities
from the server using AJAX on document ready,
is it better to make one request to get one big object
or multiple requests?"
So kind of a little bit similar-- of course,
we don't know are these entities in page updates?
Let's say if you're polling for data,
clearly you shouldn't even be using AJAX.
Any ideas here?
CAMERON PITTMAN: I think the advice
is pretty similar to the CSS questions before.
You've got to measure.
It depends on what you're doing.
And if you're going to be using those files later, cache them.
That's great.
But like Ilya said, if you're going
to make a change to one small file, they're batched together,
it's probably a good idea to separate them.
Otherwise you'll be unnecessarily
updating and re-downloading files.
ILYA GRIGORIK: I think it's-- yeah.
Same device.
To me, cache ability is always a big thing.
Can I cache this individual bit and reuse it later?
And whenever you merge multiple things,
chances are that's going to hurt your cache ability.
PETER LUBBERS: You speak a lot about caching.
Maybe you should do a course on that.
ILYA GRIGORIK: Hmm.
That's understanding.
PETER LUBBERS: Just throwing it out there.
All right, so Sergey Kretenko, he's asked,
are recommendations about reducing critical rendering
path universal for all browsers, or is it browser specific?
For example, something that works well in Chrome
may affect things negatively in Firefox.
Fortunately, I don't think-- I think
it's the same for everyone.
ILYA GRIGORIK: The steps are identical across all
the browsers.
So in fact, that's the HTML5 standard
which specifiess-- for the first time,
actually-- how given a document, the browser should
go about processing it.
So in which order, for example?
Like you have an outstanding stylesheet
and you need to execute a script.
That's a parser blocking script, and we need to block and wait.
So those steps are in the spec.
All the browsers should do the same.
PETER LUBBERS: Yeah.
And it's actually a little known fact
that is part of the HTML5 specification.
ILYA GRIGORIK: Right.
That is probably one of the most awesome things
about HTML5 specifications-- aside from WebSockets.
PETER LUBBERS: That's why I got the license plate.
ILYA GRIGORIK: Exactly.
That's true.
You also have HTML6.
PETER LUBBERS: I actually do.
It's in the parking lot right now.
Just figured you never know when that comes in handy.
So, all right.
So at least there shouldn't be any.
But are there any specific-- or, there's always
some browser specific stuff that's happening.
ILYA GRIGORIK: So there's a difference--
PETER LUBBERS: --have you seen any differences?
ILYA GRIGORIK: Yeah.
So there's a difference between the algorithm steps
that should be taken in terms of what
order things come in and implementation.
So there could be bugs, there could be different rendering
engines that do things slightly different.
You may not get the same kind of ordering
of events-- kind of individual events.
But overall, it's the same process.
So if you follow our advice in the course
and you're using Chrome Timeline,
you should get an improvement across all of the browsers,
because it's the same stuff.
PETER LUBBERS: Perfect.
Perfect.
That's great.
All right.
Another question from [? Lyte ?] in China.
"These lessons seem to focus on network.
Is there any other advice on layout and Paint?"
Actually I do remember some Paint advice in there.
CAMERON PITTMAN: We touched on Paint.
PETER LUBBERS: Touched on it.
ILYA GRIGORIK: So the way I think--
PETER LUBBERS: --another future course, maybe.
ILYA GRIGORIK: Yeah.
Yeah, definitely.
So for the critical rendering path, the trick there-- the way
I think about kind of the oral sequence of web performance
is there's [INAUDIBLE] frame really fast.
That's what this course is about.
Then after that, you need to update it
at 60 frames per second.
Right?
And that's going to delay up Paint and all the rest.
So there's also layout and Paint in the first frame per second,
and we cover it in pretty good detail in terms
of what is the layout to begin with,
or how do we paint things?
We don't get into the details of like how
particular parts of the page get invalidated, because that's not
really what painting the first frame is all about.
But the reason we talk quite a bit, I guess, about network
is that first frame mosty needs the resources.
I can't execute the JavaScript until I have the JavaScript.
And actually we know that, based on Chrome data,
we ran an experiment.
We loaded the top one million sites ranked by Alexa, right?
And we found that 70% of the time, the browser's
just sitting there idling waiting on the network.
So this is like, I would like to do something,
I would like to paint, but I can't because I'm
stuck waiting for this render blocking CSS or something.
So that's why we spend so much time talking
about why the order matters and why
you want to get those resources down to the browser
as quickly as possible.
PETER LUBBERS: All right.
We have the next question from Virginia, Jonathan Garby, who
is one of the web platform docs contributors.
"Do you know any ongoing work or discussion
to alleviate the trade offs between security
and performance?"
Both are obviously important.
For example, if a site owner enables CSP,
Content Security Policy, then they currently
can inline CSS for above the fold content.
Thought that was a good interesting question.
Like to hear your take on it.
ILYA GRIGORIK: So it is an interesting point.
The recommendations that we give.
When you inline content, that is actually potentially
a way to attack the site so they can jack content.
So CSP provides a way to set a policy that says,
anytime you see inline content, don't executed.
And that is actually the recommended policy,
because that kind of locks down your page,
which runs counter to advice.
But thankfully, the spec actually
has a section on declaring a nonce.
So what it means is, let's say you
have a script-- an inline script.
What you can do is you can take a check sum of that script.
When you inline it and say, this is the [INAUDIBLE] check sum
of this thing.
So if anybody modifies it-- if somebody other than me
modifies it, you can detect that.
So that allows you to both have the inline script
and still enforce a policy.
ILYA GRIGORIK: Alternatively you can just
like relax it completely and say, it's OK for it
to executive specifically inline CSS.
You can set that in your policy.
PETER LUBBERS: But certain companies
may have a default policy--
ILYA GRIGORIK: -- a better strategy.
A more secure strategy would be [INAUDIBLE].
So there's shouldn't be that trade off.
Anytime we see a trade off between forms of security,
that's that's not a good outcome.
So we try to make sure that both work together.
PETER LUBBERS: Good.
So you've effectively found a way
to inject performance, right?
ILYA GRIGORIK: You can have security and performance.
PETER LUBBERS: Best of all, everyone's happy.
So great.
And I noticed you posted a few links, or a link.
ILYA GRIGORIK: Yes, yes.
So we'll leave a link to the spec-- the section spec--
[INTERPOSING VOICES]
PETER LUBBERS: Cool.
Hak Touchar in Rajasthan, India asked,
how can we improve performance and compatibility
of HTML5 web and hybrid based mobile apps over native apps?
I guess that means things like Phonegap
or web view based apps.
Is there any difference, or there
things you would do differently for content
that is in a hybrid app or rendered in a webview?
CAMERON PITTMAN: Still being rendered
in essentially a browser, so the critical rendering
path will be the same.
ILYA GRIGORIK: Yeah.
All the steps are the same in terms of improving performance
over time and extensibility.
To me that's more a question of, are you
using the latest rendering engine
that has all the latest bells and whistles and all the latest
optimizations?
So if you're building a native app,
that's something you should consider.
What is that rendering engine that you're
using under the hood?
Recently release Chrome Web View,
which has all the goodies that Chrome offers.
PETER LUBBERS: I think-- I guess a lot of this
is even more important for mobile apps
where bandwidth is-- you know, you're not on your desktop.
So--
[INTERPOSING VOICES]
ILYA GRIGORIK: --the majority of our courses
focused on mobile because this stuff is critical for mobile,
right?
Because the network is slower in terms of latency on mobile.
So you end up staring at the white screen
for long periods of time.
That is just not a good experience.
So that's also why when we talk about the screencasting
mode and capturing traces, we encourage
you to do it on your phone.
Don't connect to your Wi-Fi.
Disable your Wi-Fi, fetch it from a real network,
and get it from a real device.
Because that's totally different than you
being tethered to like a fast gigabit
network on your desktop machine.
PETER LUBBERS: Use dial-up.
ILYA GRIGORIK: Not dial-up.
But--
CAMERON PITTMAN: You've gotta feel
the same pain your users might feel.
ILYA GRIGORIK: That's true.
PETER LUBBERS: Well, and there was a question earlier about
the-- from Greece-- he was developing-- Uragos in--
[INTERPOSING VOICES]
ILYA GRIGORIK: It's a funny thought.
Use dial-up.
We do have some teams at Google that, for a day,
intentionally slowed down their machines.
They just have network shaping where
they force the computer to be really slow because then it
exposes all these problems that they otherwise would not see.
PETER LUBBERS: That's great.
We should roll that out everywhere.
ILYA GRIGORIK: Not everywhere.
CAMERON PITTMAN: Upgrade Google fiber.
PETER LUBBERS: Work on both ends.
So Louis in London asked, Chrome and many other browsers
open a maximum of six parallel connections
to each host reference on a page.
Opera opens eight.
Do you see that number increasing
in the future for Chrome?
ILYA GRIGORIK: Potentially.
So there's nothing particularly magical about six.
We basically just run an empirical test
where we have a couple of thousand sites
that we test on continuously.
We tweak that number and we see how fast they slowed.
And we periodically rerun this test just to see,
maybe things changed.
And the last time we ran it, which was last year,
six was kind of that sweet spot.
Some sites do get better performance
if you give them eight connections.
But on average, the performance is worse.
So that's why magic number six is kind of round.
And that's why most browsers use it.
So maybe Opera has a particular use case, why they raised it.
But, if anything, with things like SPDY and HP2,
we're going the other way, because we
want to use just one connection.
Because that's actually more efficient.
[INTERPOSING VOICES]
PETER LUBBERS: Well, that's a good point.
So it used to be two in the specifications.
It was like-- only, no more that two.
ILYA GRIGORIK: Yep.
And you have techniques like domain sharding
where you put stuff on different host names
and you kind of work around this whole limit entirely.
But that in itself actually creates a lot of problems.
PETER LUBBERS: It's also a real hack.
ILYA GRIGORIK: It is.
So it's painful in terms of actual development cycle,
because you need to worry about what's
the magic number and all the rest.
And if anything, we actually have examples.
So etsy.com actually has an interesting case study
where they were over sharding.
So they were using too many connections.
And because of that, their mobile pages
were fetching twice as much data as it was getting retransmited.
And you wouldn't see that if you're just looking dev tools.
That you had some kind of pull up TCP
dump and look at the [INAUDIBLE] packets.
And then they decreased the number
of those connections and everything went better.
PETER LUBBERS: Cool.
ILYA GRIGORIK: So measure.
Measure then optimize.
PETER LUBBERS: Then optimize.
OK, I get it.
So another question from Lyte in China.
"How can I explore network layout painting
in other browsers?"
So we-- in the course, you have Chrome dev tools.
Of course there's IE, Firefox-- tell us
a little about how-- do you have advice for those?
CAMERON PITTMAN: Search.
Look for the documentation, play with it.
I'm not sure-- I know Ilya-- you're probably
better to answer this question than I am.
But I think the other browsers have similar tools.
But I think the network tab-- or the timeline tab
is pretty unique to Chrome.
ILYA GRIGORIK: Yeah.
The tools are different in different browsers.
In part because the rendering engines are slightly different,
so you'll get kind of different events.
But IE has great tooling, especially the latest versions.
IE11 and the rest.
Firefox has been doing a lot of great stuff releasing
new capabilities in their dev tools.
So if you're using that browser, just kind of poke around.
It won't be one to one, I can tell you that right now.
PETER LUBBERS: No, but it'll be pretty similar, right?
I mean, all of the modern browsers
and even Opera has some great tools for-- I
ILYA GRIGORIK: --I think one area that's
been tough in particular is the hybrid apps where
you have a web view.
Because it's been really hard-- it's
going to reach in and get performance data out of that.
And you have open source projects that try to do that.
That's one of things that I really
like about Chrome Web View.
You just plug-in your phone and in Chrome will show you like,
hey, there's an app running and there's a webview there.
So you just click into it and it's just
like constructing Chrome.
But if using something else, then you
may need to just go search for open source tooling
to do that sort of thing.
So that's one area that we can definitely improve in.
PETER LUBBERS: Do you use other tools, like the external tools?
ILYA GRIGORIK: Ah, yes.
So WebPagetest is a tool I use a lot.
Not for timeline, because timeline's
particular to each and every browser.
But the cool thing about web page test
is-- so webpagetest.org.
You can come there and give it a URL and pick a browser.
IE 10, 9, 7, whatever.
I don't have IE 7 on my computer,
but I use web page sets.
And then what it does is it can just run a bunch of them
and say like, I want to render this page in Firefox, Chrome
and IE.
And then it'll show you the network waterfalls
and other metadata in a consistent view.
So I can just put them side by side
and look at like, oh, something odd is happening
in this case versus something over there.
PETER LUBBERS: Do you find some very interesting cases
like that-- that are just completely unexpected?
ILYA GRIGORIK: Yes.
Yes.
They're just browser quirks.
Sometimes you have conditional logic in a particular page that
says, if IE do this, if Chrome do that,
and sometimes it's just silly.
PETER LUBBERS: What about oh-- I see, right.
What about Wireshark?
Do you use that for any of this?
ILYA GRIGORIK: I do.
And that's actually another thing that WebPagetest can do.
So there's actually a flag that says capture the TCP dump.
So if you really need to delve into the low level
networking bits-- so like, when did then connection get open?
Then what's happening in the TLS hatchegg?
You can do that.
Or I'm just capturing it directly on my computer.
But, to be honest, WebPagetest is so convenient
that I end up using it most the time.
CAMERON PITTMAN: That's great.
Now, a lot of the students have been using it
on the forums, so Sharetime line traces too.
ILYA GRIGORIK: Right.
And that's where you can do with Chrome there, right?
Because that's another check box.
And say, as you're loading this page, capture the trace.
And then you have a URL that you can share.
So I guess you could save it and email it
to your coworkers or somewhere.
[INTERPOSING VOICES]
CAMERON PITTMAN: This is almost even easier.
PETER LUBBERS: Perfect.
That's great.
All right, so next question is from Patti in Fremont.
"First, there was a full page load.
Now it's onload, which is the kitchen sink.
What's the next metric on the frontier
to take the poll position from onload,
start render, or speed index?"
Also mentions that SPDX-- why is it only in Chrome?
Is it even in Chrome?
ILYA GRIGORIK: It's not in Chrome.
PETER LUBBERS: OK.
Let's be honest here.
ILYA GRIGORIK: Yes.
Yes.
PETER LUBBERS: But yeah.
So what is the-- where do you see that going?
What is that next metric?
ILYA GRIGORIK: Right.
So first, let's define onload.
So onload is when the spinner stops spinning in a browser.
Which, if we were going for the blank page
and then everything's revealed, that's
what basically we're measuring at the end.
What we're talking about here is progressive rendering.
So we don't want to measure that endpoint.
You also want to measure one or multiple points along the way.
Like let's say I'm loading a product page in Amazon.
It's like the product's visible, and the description is visible.
Then the comments come in, then something else comes in.
And there may be three or four points that are important.
And they're important for that particular app.
So start renders-- good, in the sense of something
has happened.
But what if I just painted white pixels?
That's a start render.
So that could be gained as well.
PETER LUBBERS: Yeah, I guess that's--
[INTERPOSING VOICES] ILYA GRIGORIK:
I encourage developers to think about--
or the entire team, the product team to think about,
what are the important critical points along that loading
path in your application?
And that's what the next pole position, if you will,
because you could say, for my app,
it's showing the course page.
Then the next thing is having the video load it.
Those are the two things I really care about it.
And we have APIs in the browser now,
things like user timing where you can just
mark those endpoints and say, the video's being loaded now,
or the video has started playing.
And you can beacon those to your analytics.
That's what you should be doing.
CAMERON PITTMAN: Yeah, that makes a lot more sense.
PETER LUBBERS: That's the frontier.
Perfect.
Lewis in London on Chrome network resource timeline.
What exactly does blocking mean?
Many places describe it as time spent
waiting for an already established connection
to become available.
And what about when that happens in your first connection
to the base for the base HTML page?
ILYA GRIGORIK: So there's actually
a good discussion in the forum--
PETER LUBBERS: In the Moderator?
ILYA GRIGORIK: --in Moderator.
Basically what it means is, the connection is busy.
So this is where we come back to HP 1.1.
One of the properties of HP 1.1 is, if the socket's being used,
it can't be used for any other requests.
All right, so there's only one request
that can be processed at a time.
I guess that's what I'm saying.
And block just means there's something else keeping
the socket from doing stuff.
So that's what--
PETER LUBBERS: --like those max connections
that we talked about.
ILYA GRIGORIK: Exactly.
Right.
So if you're using HP 1.1, you'll
only have six sockets, that's using domain sharding,
and all of those six that will say fetching things.
And then you send a seventh request,
now we just stopped waiting for one the sockets to free up.
But then there's a particular question about,
what about when it happens on the first connection?
And that's a tricky one.
I'd have to actually see the page.
But I'm going to guess.
It's something to do-- same scenario,
all the sockets are busy, and we have
to cancel some requests before we can send requests.
Or we need to run some onload logic.
Some pages need to clean up before we
can go to the next page.
And that could be blocking the execution.
PETER LUBBERS: Perfect.
All right, so, let's see.
Same-- another question from Lewis.
"My site render start is about two seconds,
onload around eight seconds.
Inspecting the filmstrip shows the page
is visually ready at about four seconds."
So-- it's actually interesting question.
"Is there a way to programmatically measure-- when
above the fold is ready?"
CAMERON PITTMAN: Well it's also worth pointing out that
filmstrip he was referring to--- probably webpagetest.org's film
strip.
And you were saying that works by literally taking screenshots
of the page as it's being loaded?
ILYA GRIGORIK: Yeah.
So what happens is we record the video
and then we sample the video and basically
freeze frame the video.
And then we say-- we do a visual dip.
So, have any pixels changed?
And if no pixels have changed for a certain amount of time,
we say it has finished loading.
And that's how we give you that progress
bar, to say it like, oh, your 40% percent loaded,
60% loaded, and all the rest.
This is why it's also very hard to implement in the browser.
Because it's like we're not going to be capturing a video
and then doing the disk.
There's been some attempts, but so far, they
have not been very successful.
So I don't know.
It's a tricky subject.
PETER LUBBERS: Yeah, I guess you could
do that yourself and then--
[INTERPOSING VOICES]
ILYA GRIGORIK: So the simple answer to this question
is use wepbage test.
Perhaps you could build some stuff on top of it
to kind of measure that.
So in fact, WebPagetest allows you
to switch in a film strip that can visually
complete versus document onload.
So you can use that.
But just do it yourself directly in dev tools-- today
that's not really possible.
CAMERON PITTMAN: And it sounds like also a good use
case for user timing.
What events are important--
[INTERPOSING VOICES]
ILYA GRIGORIK: --I would actually
encourage that instead.
Because you could define an important milestone
to say the video has started playing on the course page.
That's what I care about it.
Fire an event right there and send it to your analytics.
PETER LUBBERS: That's the next-- the next frontier.
ILYA GRIGORIK: Yep.
Exactly.
PETER LUBBERS: All right, so Jordi in Girona, Spain.
What's the performance difference
between HTTP 1011 and Doze over SSL?
Why should anyone still use non SSL pages,
and why is Google using 100% SSL web pages?
ILYA GRIGORIK: So there's a lot of different questions
in there.
PETER LUBBERS: So let's start with the Google one.
So is Google already doing everything over SSL?
ILYA GRIGORIK: It's not everything,
but we're definitely moving towards it.
And that is an explicit goal across entire company
to move all of our products to 100% SSL.
And I'm hoping that will happen soon.
Very soon.
PETER LUBBERS: So then why-- should anyone still,
that's not at Google, still use non SSL?
There is a great website for this.
ILYA GRIGORIK: Yes, yes.
So there's two different questions, right?
There's the why and then there's the performance part,
which I think is what you're applying.
So the why I think is, no you shouldn't be using it.
So everything should be under SSL.
SSL provides some nice properties
in terms of education, making sure
that you connect to the right site,
nobody can modify it in multi-transit,
and it's encrypted.
So this is actually very important for privacy
and security of your site.
PETER LUBBERS: So that's good-- why.
And then I guess the real question for most people
is-- and this may be something that they're
used to thinking-- is, yeah, but isn't it slow?
ILYA GRIGORIK: So it's not slow.
You may have to just add-- just as with critical rendering
path-- gotta put in a little bit of thought
into how you serve it.
So that means spending some quality time with your server
config or your friendly server administrator
to poke him and say, hey
[INTERPOSING VOICES]
PETER LUBBERS: --course in the making?
ILYA GRIGORIK: Perhaps.
CAMERON PITTMAN: How to focus [INAUDIBLE].
ILYA GRIGORIK: In the meantime, as we develop that course,
there is a site that I've been keeping up to date
with all the latest best practices, which
is istlasfastyet.com.
The answer is yes.
And it gives you a list of recommendations
for CDN providers, servers and the different features
it supports.
So the common complaints-- or questions, I should say--
are does it encryption out a lot of overhead?
And it can.
But modern CPUs are fast enough such as that it's not
a problem.
Google runs everything in software
without any sort of dedicated hardware.
It's not an issue.
Simply for Facebook and many other companies.
The thing you need to be aware of
is those extra round trips, because it does take some time
to negotiate the connection.
So this is where we come back to the discussion between HP1
and 1.1.
In 1.0, for every request, it's opened a new connection,
which is kind of like you have to do TCP handshake, the TLS
handshake, which would be incredibly expensive.
So you want to make sure that things
like Keepalived work and others.
So this is definitely way down into the networking
performance.
And that site provides a lot of tips.
PETER LUBBERS: So the website that you
mentioned is istlsfastyet.com.
ILYA GRIGORIK: That's right.
And we'll--
PETER LUBBERS: --that has all the tips as well?
ILYA GRIGORIK: Yes.
PETER LUBBERS: And for TLS SSL here,
just for those transporting layer of security,
you're using kind of interchangeably.
ILYA GRIGORIK: That's right.
So SSL is the original name, which
was developed by Netscape.
And then two years later, they made
us an actual spec out of it and called it TLS.
That's the ITF standard.
PETER LUBBERS: No I just-- because the question
was about SSL.
ILYA GRIGORIK: So the only other thing I'll add is-- Pierre
and myself-- Pierre is on the webmaster team at Google
and did a presentation on Google I/O on tips
on if you have a site today, what
do you need to do to migrate your site to HTTPS
and what are things you need to watch out for,
both in terms of migrating HTTPS like indexing
and all the rest and performance.
So that site has a link to that video,
so definitely check that out.
PETER LUBBERS: We'll add it to the moderator
if it's not already.
Perfet.
All right, so now we've come to the final question
from Andy Leo in Chicago.
CAMERON PITTMAN: Which you're going to read literally, right?
PETER LUBBERS: I'm going to read it literally.
You have to see this to believe it.
There are two examples.
Basically a web page with a Hello JavaScript example.
One with a-- I guess the difference is there is a title.
ILYA GRIGORIK: So this is a very simple page.
So HTML.
And there's an inline script that
pops up an alert box that says Hello World.
And the only difference here is there's
a little bit of content, a title, before the script.
So honestly, I would not expect any difference whatsoever
in terms of-- yes, if you want to measure in microseconds,
I'm sure we could come up with something.
But-- and you should measure first--
PETER LUBBERS: --maybe we can start
running this in a test on there.
ILYA GRIGORIK: Right.
But for all practical applications,
this won't make any difference.
Where it can be important is-- so let's say instead
of just a short Hello HTML, you had a giant HTML comment,
which is-- I've seen it before.
And that seems like well, who cares?
Except it does add a lot of content
to the beginning of the response, which means
it may take more time to fetch those bytes.
So those kinds of things you should watch out for,
but in this particular example, unless we're
talking microseconds, I would not
expect to see any difference.
PETER LUBBERS: Well, still-- microseconds.
CAMERON PITTMAN: It could matter.
PETER LUBBERS: Microseconds matter.
Is that a new hashtag?
ILYA GRIGORIK: I think we still need to solve the seconds part.
[INTERPOSING VOICES]
PETER LUBBERS: All right, so that
concludes the questions we have.
So--
ILYA GRIGORIK: I think there was one, right?
PETER LUBBERS: Oh, that's right.
There's another one from the forums.
CAMERON PITTMAN: So I've been spending a lot of time
on the forums answering student questions
and grading their work.
I used to be a high school teacher,
so actually interacting with students
is way more entertaining than interacting with the camera.
No offense.
But yes, the students have been confused between the difference
of render blocking and parser blocking.
So it's important to note that CSS is render blocking
and JavaScript is parser blocking.
In fact, this is actually kind of funny,
because when we were filming the course,
there was an answer video that I did by myself without-- well,
I checked with Ilya first-- but I had the wrong answer,
actually, because I got these two mixed up.
So it could happen to anybody.
But basically, CSS is render blocking
because the page won't render until the CSS on
has been built.
So nothing's going to show up on the screen
unless the CSS has arrived, it's been parsed and turned
into the CSS on.
But Javascript's a little different.
It's parser blocking, which means that the page won't
continue to parse the HTML that comes after the JavaScript
until the JavaScript itself has been executed.
So everything that comes before it in the HTML that can be
displayed.
It can be rendered.
But once you hit that parser blocking script,
what comes below it is going to be blocked until that script
finishes.
ILYA GRIGORIK: And we talk about a couple
of strategies in the course for how to mitigate that.
So for example, there's an async keyword onscript
that you could add that basically is like an escape
clause that says, this won't be rendered-- or parser blocked.
That's the one.
I got it.
[INTERPOSING VOICES]
ILYA GRIGORIK: So definitely check out the course.
And also, there's material on web fundamentals
that kind of goes into details and shows the examples.
PETER LUBBERS: Yeah, some great stuff in there
and a lot of the course notes, instructor notes
that give additional information.
CAMERON PITTMAN: Tons of links.
[INTERPOSING VOICES]
PETER LUBBERS: So I think that concludes
our ask the expert office hours session.
Thanks Cameron, thanks Ilya.
[INTERPOSING VOICES]
PETER LUBBERS: If you haven't taken the course,
definitely check it out.
All of our Google courses that we partnered with Udacity
on are available at udacity.com/Google.
You can see the entire line up there.
Check out some of the other courses as well.
We have courses on mobile web development, HTML5 game
development, Androids, UX design, App Engines.
So it's continuously growing.
We're excited about all the courses we've put out.
And next week, there will be office hours on the Android
fundamentals course, as well as the Cloud App Engine
course that we built.
So with that, if you haven't checked them out, do that.
And if you have been on the forums,
definitely check out the moderator pages
for the extra links that we're posting.
Thank you very much.
[MUSIC PLAYING]