1
00:00:00,580 --> 00:00:05,087
Your ability to measure your site's
performance is the single most important

2
00:00:05,087 --> 00:00:07,214
part of front end web optimization.

3
00:00:07,214 --> 00:00:12,980
And the necessity to do so has birthed
a vast array of ingenuity and tools.

4
00:00:12,980 --> 00:00:15,427
As they say,
necessity is the mother of invention.

5
00:00:16,550 --> 00:00:20,510
Using some of these tools will help you
best determine how you are meeting your

6
00:00:20,510 --> 00:00:24,410
performance goals and maintaining
resolution with your performance budget.

7
00:00:25,500 --> 00:00:30,470
Measuring performance isn't all just
about how fast a user can download data.

8
00:00:30,470 --> 00:00:34,640
The pillars of performance
are host server, network,

9
00:00:34,640 --> 00:00:36,340
user's device and load time.

10
00:00:38,260 --> 00:00:43,027
You want the fastest server that transmits
the smallest versions of data possible.

11
00:00:43,027 --> 00:00:48,018
For example, Gzipping your assets like
discussed previously and then making use

12
00:00:48,018 --> 00:00:53,450
of a distributed network, a CDN,
something that we'll discuss later on.

13
00:00:53,450 --> 00:00:55,580
After your user makes a request,

14
00:00:55,580 --> 00:00:58,430
you want to get that data
moving as fast as possible.

15
00:01:00,060 --> 00:01:02,070
After the user makes a request and

16
00:01:02,070 --> 00:01:07,420
the server starts to send data, your first
performance hindrance is the network.

17
00:01:07,420 --> 00:01:13,580
Is the user on a slow mobile data network
or a blazing fast internal office network?

18
00:01:13,580 --> 00:01:17,850
These are last mile issues that you have
no control over, but need to be aware of.

19
00:01:19,030 --> 00:01:22,330
Many of the performance assessment
tools we will discuss make really

20
00:01:22,330 --> 00:01:24,360
good attempts at emulating bad networks.

21
00:01:25,390 --> 00:01:29,520
But nothing beats going out with your
phone to a crowded public area and

22
00:01:29,520 --> 00:01:34,780
testing it for yourself,
which brings us to the user's device.

23
00:01:34,780 --> 00:01:39,410
When building any app or site,
you have to have in mind what is probably

24
00:01:39,410 --> 00:01:42,700
the most commonly used device
your customers will use.

25
00:01:42,700 --> 00:01:46,088
Will they be using feature phones
in remote corners of the world?

26
00:01:46,088 --> 00:01:48,770
Are they high-end smart phone users?

27
00:01:48,770 --> 00:01:53,360
Are they professionals who may be
on a mobile or desktop device?

28
00:01:53,360 --> 00:01:57,190
Keeping these questions in mind will help
you best measure against your performance

29
00:01:57,190 --> 00:01:58,440
budget for that scenario.

30
00:01:59,930 --> 00:02:01,750
Last is nailing down your load time.

31
00:02:02,830 --> 00:02:05,610
Having set realistic goals for
your user scenarios,

32
00:02:05,610 --> 00:02:10,220
you can now use performance
assessment tools with clear intent.

33
00:02:10,220 --> 00:02:14,320
Without having specific goals in mind and
understanding the constraints,

34
00:02:14,320 --> 00:02:18,660
using assessment tools is more like
a post-mortem than an opportunity for

35
00:02:18,660 --> 00:02:20,410
progressively enhancing your app.

36
00:02:21,800 --> 00:02:25,570
To better understand the processing
abilities of your most commonly used

37
00:02:25,570 --> 00:02:29,860
devices, a few developers on the WebKit
team came up with motion mark.

38
00:02:30,940 --> 00:02:35,080
Motion mark is a tool that will measure
a browser's ability to handle complex

39
00:02:35,080 --> 00:02:39,830
UI's and animations while maintaining
the desired 60 frames per second.

40
00:02:40,980 --> 00:02:45,170
Using this tool on various devices
going from mobile to desktop

41
00:02:45,170 --> 00:02:49,910
will help you best understand the actual
performance capabilities of your devices.

42
00:02:51,380 --> 00:02:55,080
The next series of tools we will look at
are the ones that are designed to review

43
00:02:55,080 --> 00:02:57,670
the overall performance
of a deployed web app.

44
00:02:58,820 --> 00:03:02,800
These tools provide insight for reports
into the performance of your site or

45
00:03:02,800 --> 00:03:07,920
app in its production state, and how
your users will see it perform as well.

46
00:03:07,920 --> 00:03:11,580
After all, testing things locally
is kind of cheating, isn't it?

47
00:03:12,830 --> 00:03:15,750
>> Google's PageSpeed Insights has
risen to being one of the most

48
00:03:15,750 --> 00:03:20,570
widely used performance assessment tools,
and it's extremely easy to use.

49
00:03:20,570 --> 00:03:23,430
Enter the URL of your site,
and hit the ANALYZE button.

50
00:03:23,430 --> 00:03:27,480
For example, I made a quick weather
app that's not yet optimized.

51
00:03:27,480 --> 00:03:32,110
After it analyzes your site, it'll return
a report for both mobile and desktop.

52
00:03:32,110 --> 00:03:36,070
For mobile, insights checks a number of
data points to see how well your site

53
00:03:36,070 --> 00:03:38,180
performs on a mobile network.

54
00:03:38,180 --> 00:03:42,580
Its main criteria is how well your site
renders above the fold content within

55
00:03:42,580 --> 00:03:43,990
one second.

56
00:03:43,990 --> 00:03:49,690
Insights looks for server response time,
number of http redirects,

57
00:03:49,690 --> 00:03:53,680
number of roundtrips made to
render above the fold content.

58
00:03:53,680 --> 00:03:57,620
And avoid render blocking calls needed
to render above the fold content.

59
00:04:00,100 --> 00:04:05,100
The results come back as should fix,
consider fixing, and passed rules.

60
00:04:05,100 --> 00:04:06,825
Don't let this report hurt your feelings,

61
00:04:06,825 --> 00:04:09,440
it's pretty difficult
to get a perfect score.

62
00:04:09,440 --> 00:04:11,740
You may have constraints that
are difficult to overcome.

63
00:04:12,740 --> 00:04:16,200
Some should be easy to fix,
one being above the fold content.

64
00:04:16,200 --> 00:04:20,202
We will discuss this later in
JavaScript and CSS optimization.

65
00:04:20,202 --> 00:04:24,110
In regards to image optimization, you
should take this feedback very seriously

66
00:04:24,110 --> 00:04:27,740
as bloated images are the number one
cause for poorly optimized sites.

67
00:04:28,858 --> 00:04:33,910
The analysis Insights uses for
desktops follows a similar criteria, but

68
00:04:33,910 --> 00:04:37,540
is not as critical on issues
related to power and network.

69
00:04:37,540 --> 00:04:41,580
Insights also reserves time
needed to render the view layout,

70
00:04:41,580 --> 00:04:45,210
then it evaluates how well
the JavaScript execution is and

71
00:04:45,210 --> 00:04:48,800
the rendering time needed to
display the view in the browser.

72
00:04:48,800 --> 00:04:52,374
But be sure to take pride in
the number of rules you did pass,

73
00:04:52,374 --> 00:04:54,102
after all this is good work.

74
00:04:56,126 --> 00:04:59,233
Now there's another site that
uses the PageSpeed API and

75
00:04:59,233 --> 00:05:01,180
gives you a different experience.

76
00:05:02,310 --> 00:05:03,570
Let's get our test site in here,

77
00:05:04,800 --> 00:05:09,550
this assessment tool adds in another score
factor, that of mobile friendliness.

78
00:05:10,640 --> 00:05:14,370
This is important because Google
is starting to use this score

79
00:05:14,370 --> 00:05:16,060
in their search results algorithm.

80
00:05:17,280 --> 00:05:21,676
The worse you are at mobile friendliness,
the lower your rankings, and

81
00:05:21,676 --> 00:05:24,281
whoever said that mobile didn't matter?

82
00:05:24,281 --> 00:05:27,250
A new tool I discovered is ready.mobi.

83
00:05:27,250 --> 00:05:32,460
Like the others, I simply enter the URL
that I want to test and click GO.

84
00:05:36,968 --> 00:05:40,373
They take a similar approach
as Google's PageSpeed, and

85
00:05:40,373 --> 00:05:44,401
do a great job presenting the data
in a representation of your site and

86
00:05:44,401 --> 00:05:50,340
various devices, ranging from desktop to a
feature phone with a really small screen.

87
00:05:50,340 --> 00:05:52,359
The score feedback is great too.

88
00:05:52,359 --> 00:05:57,890
It is clearly illustrated as to what is
good and bad with your app's experience.

89
00:05:57,890 --> 00:06:01,720
And with each targeted feedback, there
are helpful tips for how you can fix them.

90
00:06:03,100 --> 00:06:05,880
Last, I wanted to show
Google's Lighthouse.

91
00:06:05,880 --> 00:06:09,610
Lighthouse is a tool that requires
a Chrome extension to be installed and

92
00:06:09,610 --> 00:06:11,390
it works pretty simple.

93
00:06:11,390 --> 00:06:15,210
Go to your site, either locally or
globally hosted, and

94
00:06:15,210 --> 00:06:18,270
activate the app from the Chrome task bar.

95
00:06:18,270 --> 00:06:22,480
LIghthouse will begin to perform
a series of tests to assess your score.

96
00:06:22,480 --> 00:06:24,050
Here's the bad news.

97
00:06:24,050 --> 00:06:26,640
If you scored less than
okay in the previous tests,

98
00:06:26,640 --> 00:06:29,060
you may have your soul crushed here.

99
00:06:29,060 --> 00:06:32,960
Lighthouse is a rigorous series of
tests for a progressive web app, and

100
00:06:32,960 --> 00:06:35,690
they keep adding testing features,
which is pretty awesome.

101
00:06:36,970 --> 00:06:41,723
One thing I really like about Lighthouse
is it's easy to read results.

102
00:06:41,723 --> 00:06:46,137
You can quickly find things like
your first meaningful paint, or

103
00:06:46,137 --> 00:06:48,240
your perceptual speed index.

104
00:06:48,240 --> 00:06:50,400
There's a lot of criteria to meet, and

105
00:06:50,400 --> 00:06:52,750
it's difficult at best
to get a perfect score.

106
00:06:54,140 --> 00:06:58,160
Even sites where performance is
everything, like say, Amazon.com,

107
00:06:58,160 --> 00:07:01,109
they currently only have
a score of 50 out of 100.

108
00:07:02,320 --> 00:07:05,583
Like the other tests,
the data is easy to consume and

109
00:07:05,583 --> 00:07:09,218
there is a slew of helpful hints and
tips to help you address

110
00:07:09,218 --> 00:07:13,463
the areas where your app didn't
score as well as you hoped it would.

111
00:07:15,684 --> 00:07:20,034
>> While all these assessment tools
are amazing, for local host profiling,

112
00:07:20,034 --> 00:07:23,430
Lighthouse, the Google Chrome
extension is the winner.

113
00:07:24,470 --> 00:07:29,027
And while this test is amazing, we can't
ignore the grandfather of web performance

114
00:07:29,027 --> 00:07:33,280
profiling and that's Chrome's Inspector,
specifically the Network tab.

115
00:07:35,040 --> 00:07:38,510
>> We are all familiar with Chrome's
Inspector, at the very least for CSS and

116
00:07:38,510 --> 00:07:40,170
JavaScript debugging.

117
00:07:40,170 --> 00:07:42,080
But for
the purpose of assessing performance,

118
00:07:42,080 --> 00:07:44,090
we want to pay close
attention to the Network tab.

119
00:07:45,110 --> 00:07:47,960
Before we get started,
if you haven't already, be sure to

120
00:07:47,960 --> 00:07:52,470
update the inspector settings to always
disable cache when the inspector's open.

121
00:07:52,470 --> 00:07:55,540
This will prevent you from
getting false performance data,

122
00:07:55,540 --> 00:07:59,340
as there will be cached data in the
browser from previous hits to the site.

123
00:07:59,340 --> 00:08:04,400
In this example, I threw in the kitchen
sink, and I'm using really large images.

124
00:08:04,400 --> 00:08:06,450
Most know that this is not performant, but

125
00:08:06,450 --> 00:08:09,340
I really want an exaggerated
example to illustrate here.

126
00:08:11,580 --> 00:08:13,360
With Chrome's inspector open,

127
00:08:13,360 --> 00:08:16,410
we can easily see where
the bottlenecks are in our app.

128
00:08:17,430 --> 00:08:19,650
With this view open, analyzing our site,

129
00:08:19,650 --> 00:08:24,100
we see a waterfall graph being generated
that shows all of the assets being loaded.

130
00:08:24,100 --> 00:08:27,050
The information here can
be complex to read, but

131
00:08:27,050 --> 00:08:31,100
with some poking around we can quickly
understand some key information.

132
00:08:31,100 --> 00:08:32,620
But is this example real?

133
00:08:33,650 --> 00:08:35,140
I am loading this from my laptop.

134
00:08:35,140 --> 00:08:38,218
So let's throw in some network
throttling to make this more real and

135
00:08:38,218 --> 00:08:39,029
refresh the app.

136
00:08:42,197 --> 00:08:45,510
In the foot of the Network tab
are some important data points.

137
00:08:45,510 --> 00:08:48,900
How many requests,
how much data is being transferred,

138
00:08:48,900 --> 00:08:54,030
the finish load time,
DOMContentLoaded, and total load time.

139
00:08:54,030 --> 00:08:57,260
Critical points to consider
are what is the total

140
00:08:57,260 --> 00:08:59,960
time to load all of the code and data?

141
00:08:59,960 --> 00:09:03,160
When is DOMContentLoaded completed?

142
00:09:03,160 --> 00:09:05,370
And what is the total load time?

143
00:09:05,370 --> 00:09:08,390
Simply put, the larger the numbers,
the worse off we are.

144
00:09:09,450 --> 00:09:13,540
Finish time, this is the time that
it takes for the browser to finish

145
00:09:13,540 --> 00:09:19,105
downloading and executing all the code,
which is usually just behind load time.

146
00:09:19,105 --> 00:09:24,270
DOMContentLoaded, a critical factor
that should be as small as possible.

147
00:09:24,270 --> 00:09:28,040
I would always target this to
be at least one second or less.

148
00:09:28,040 --> 00:09:34,780
The definition of DOMContentLoaded means,
the DOM and CSS object model are ready.

149
00:09:34,780 --> 00:09:38,010
There are no style sheets that
are blocking JavaScript in the critical

150
00:09:38,010 --> 00:09:39,390
rendering path.

151
00:09:39,390 --> 00:09:41,250
The render tree can now be built.

152
00:09:42,335 --> 00:09:46,870
DOMContentLoaded is usually pretty close
to your first meaningful paint, and

153
00:09:46,870 --> 00:09:50,060
fires immediately after DOM interactive.

154
00:09:50,060 --> 00:09:53,700
This is roughly your first
meaningful interaction.

155
00:09:53,700 --> 00:09:57,270
If there is anything blocking
the DOMContentLoaded event,

156
00:09:57,270 --> 00:10:01,150
your users will just sit there
looking at a blank screen.

157
00:10:01,150 --> 00:10:05,160
Another visualization of DOMContentLoaded
is the capture filmstrip

158
00:10:05,160 --> 00:10:06,300
in the top part of the tab.

159
00:10:07,400 --> 00:10:10,940
Once the recording is complete, there will
be a series of screenshots that depict

160
00:10:10,940 --> 00:10:14,870
specific time intervals of
the loading of your site.

161
00:10:14,870 --> 00:10:18,440
You will see that the timestamp of
the first slice in the filmstrip is

162
00:10:18,440 --> 00:10:22,257
really close to the same time as
the DOMContentLoaded timestamp.

163
00:10:23,380 --> 00:10:26,550
You can also click on a slide in
the filmstrip and that will filter

164
00:10:26,550 --> 00:10:29,880
out the waterfall to illustrate what
has been completed up to that point.

165
00:10:31,020 --> 00:10:33,440
Which takes us to the waterfall
cascade of events for

166
00:10:33,440 --> 00:10:36,100
downloading all of
the content to your site.

167
00:10:36,100 --> 00:10:41,410
This is a very clear depiction of how
large assets are, when they loaded,

168
00:10:41,410 --> 00:10:44,210
if they are blocked, or
if assets didn't load at all.

169
00:10:45,240 --> 00:10:48,380
There's an amazing amount of
information in this area of the report.

170
00:10:48,380 --> 00:10:50,240
For even more information,

171
00:10:50,240 --> 00:10:54,510
you can click on the depiction
of the asset in the timeline.

172
00:10:54,510 --> 00:10:59,820
This will tell you exactly when the asset
was requested, what the wait time was,

173
00:10:59,820 --> 00:11:01,584
and how long it took to download.

174
00:11:01,584 --> 00:11:06,730
The wait time is the clear
depiction of latency.

175
00:11:06,730 --> 00:11:11,872
Also interesting to note, in this
example there are broken resources.

176
00:11:11,872 --> 00:11:14,957
These things take time too.

177
00:11:14,957 --> 00:11:16,680
That's something to keep in mind and

178
00:11:16,680 --> 00:11:20,080
to make sure that you are maintaining
all of your references correctly.

179
00:11:21,340 --> 00:11:25,780
As you can see here, there are a lot of
tools that can provide a lot of data to

180
00:11:25,780 --> 00:11:29,410
help us better understand
the performance of our sites.

181
00:11:29,410 --> 00:11:33,750
In the next stage of this course, we will
discuss some real life examples for how to

182
00:11:33,750 --> 00:11:38,780
best optimize our assets and really drive
these critical performance numbers down.