WEBVTT
00:00:02.200 --> 00:00:06.000
[Music]
00:00:15.600 --> 00:00:18.000
Hi, everybody. Welcome back.
00:00:19.600 --> 00:00:24.300
I hope you all had a great lunch.
J.D. and I certainly did.
00:00:24.400 --> 00:00:27.700
Okay. So before the break, we
00:00:27.700 --> 00:00:32.400
talk about the two principles you
need to watch out when you
00:00:32.800 --> 00:00:36.600
do the performance tuning. So we
talk about how quickly we could
00:00:37.130 --> 00:00:42.120
respond to the network and then minimize
the number of buys downloaded.
00:00:42.770 --> 00:00:46.320
So in this module, we're going
to actually share with you the
00:00:46.370 --> 00:00:50.440
third principle to make your
performance even faster.
00:00:51.010 --> 00:00:57.940
So this is media usage. How we can
work smartly with media message.
00:00:58.450 --> 00:01:02.180
So as you probably remember from
the previous module, we actually
00:01:02.230 --> 00:01:07.350
had some statistics showing the
typical payload. We're showing
00:01:07.400 --> 00:01:12.330
the number of average size in the
page. And if you still remember,
00:01:12.380 --> 00:01:16.850
the number one concern or the number
one resources we're using
00:01:16.900 --> 00:01:20.690
is images. So we're going to actually
talk a lot about how to
00:01:20.740 --> 00:01:25.010
work with image, how to make sure
we don't waste any, when we
00:01:25.060 --> 00:01:29.990
download, how to make sure to work
with images more efficiently.
00:01:30.460 --> 00:01:36.220
So let start. So we're going talk
about how to optimize media
00:01:36.270 --> 00:01:41.890
usage and we're going talk about
why when we should use CSS3.
00:01:44.540 --> 00:01:50.270
So how to optimize the media usage.
Let's actually look into that.
00:01:50.890 --> 00:01:57.520
Now this is actually average number
of media resources data we
00:01:57.570 --> 00:02:01.390
took a while ago. So the number
could be actually increased.
00:02:01.440 --> 00:02:07.410
This is on the top so 100,000 websites.
So it shows it has at
00:02:07.460 --> 00:02:12.320
least 58 piece of media resources
we're working with. So this
00:02:12.370 --> 00:02:14.810
is a pretty big number.
00:02:15.370 --> 00:02:19.410
And with all the resources, what
could we do to make it better.
00:02:19.720 --> 00:02:24.460
Because that's a typical size,
58, right. So your app could
00:02:24.510 --> 00:02:28.260
be maybe even using more resources
or less resources. But one
00:02:28.310 --> 00:02:32.920
thing we feel is important to share
with you is use the native
00:02:32.970 --> 00:02:37.440
image resolution. So a lot of times,
you will probably see for
00:02:37.490 --> 00:02:42.700
the same page, you actually will
have maybe a size, a regular
00:02:42.750 --> 00:02:47.140
size kind of image you will show
for your particular product.
00:02:47.190 --> 00:02:50.930
And then maybe you have a lot of
thumbnails, a smaller scale
00:02:50.980 --> 00:02:56.220
image or even icons or you maybe
even have the same image but
00:02:56.270 --> 00:03:01.010
in a different size. Now, just
for the convenience, a lot of
00:03:01.060 --> 00:03:05.830
times we just getting the image as
it is from the server, right.
00:03:05.880 --> 00:03:07.580
So let's look at this example.
00:03:08.220 --> 00:03:13.170
So if you look at this code, basically
we're showing this is
00:03:13.220 --> 00:03:17.770
our original image from the server.
It's a local image.
00:03:17.820 --> 00:03:22.890
The size is 500 by 400. And then
for our particular need, based
00:03:22.940 --> 00:03:28.310
on the size of our device, we only
require the size to be 50
00:03:28.360 --> 00:03:32.000
by 40. So it's actually hundred
times smaller, right.
00:03:32.050 --> 00:03:34.720
However, for the convenience, a
lot of times we'll just say,
00:03:34.770 --> 00:03:38.690
ah, let's just get that original
big image from the server and
00:03:38.740 --> 00:03:42.640
then let the browser do the decoding
and resize it for you, right.
00:03:42.690 --> 00:03:47.640
It will always work. Yes, in a
way, for the convenience it's
00:03:47.690 --> 00:03:50.660
working and you probably don't
have to worry about that.
00:03:50.710 --> 00:03:54.320
But do you know you're actually
wasting quite a bit of resource
00:03:54.370 --> 00:03:58.500
just getting a huge image as when
you display on to your app
00:03:58.550 --> 00:04:03.480
is only one percent, a hundred
times smaller than that so in
00:04:03.530 --> 00:04:08.300
this case, you already have to
watch out and about, say, for
00:04:08.350 --> 00:04:11.320
example, this is just one example,
right. You may have this
00:04:11.370 --> 00:04:15.160
kind of example happen on your page
multiple times. Think about
00:04:15.210 --> 00:04:18.960
58 piece of information. You may
have a repeated, I don't know,
00:04:19.010 --> 00:04:22.320
maybe just five or six times, right,
and that's actually going
00:04:22.370 --> 00:04:27.680
to contribute to quite a bit of unnecessary
downloading and decoding
00:04:27.730 --> 00:04:32.170
and resizing. So if you can, you
should always think about say
00:04:32.220 --> 00:04:37.960
if I only need a 40 by 50, then
do yours in user graphic two
00:04:38.010 --> 00:04:42.650
or do it by hand to downsize into
50 and 40, instead of getting
00:04:42.700 --> 00:04:49.340
a big image from the web. Okay. So
based on that we did some tests.
00:04:49.860 --> 00:04:54.390
This is a very sort of like a simple
site, if you remember, you
00:04:54.440 --> 00:04:58.170
attended some of our build conference,
we actually have a build
00:04:58.220 --> 00:05:03.410
website, and it contains about
30, 40 piece of information.
00:05:03.700 --> 00:05:08.250
So we have a little, like, sort
of like a hat image and this
00:05:08.300 --> 00:05:13.010
little hat image is actually being, it's
touchable and you could rotate.
00:05:13.060 --> 00:05:17.520
It has about ten images. And then
on the bottom of the page,
00:05:17.570 --> 00:05:20.530
you see there's a lot of thumbnails.
There's a little smaller
00:05:20.580 --> 00:05:25.300
scale image to work with. So what
we do is we actually, it's
00:05:25.350 --> 00:05:28.690
a benchmark. So we actually all
choose just take the image the
00:05:28.740 --> 00:05:33.390
way it is, don't do any of the resize,
and then test the result.
00:05:33.440 --> 00:05:36.920
Versus, you know, we actually resize
everything into the exactly
00:05:37.200 --> 00:05:39.430
required size and then do the test.
00:05:40.570 --> 00:05:45.930
So the result is very interesting. I should
look into the benchmark result.
00:05:45.980 --> 00:05:51.410
So we're actually measuring the
visual throughput as well as
00:05:51.460 --> 00:05:55.430
CPU utilization, because we already
said CPU utilization is such
00:05:55.480 --> 00:06:01.030
an important factor to impact your battery
life as well as your performance.
00:06:01.430 --> 00:06:06.340
So if you look at... if I'm just
using the regular size whatever
00:06:06.390 --> 00:06:10.570
I get from server and then showing
this particular image, we
00:06:10.620 --> 00:06:15.540
actually see the time difference
here. It took about 1.8 seconds
00:06:15.590 --> 00:06:20.840
to loading the whole page so that
everything is actually arrived
00:06:21.200 --> 00:06:26.150
in the current side and you can display.
And versus the right-sized,
00:06:26.200 --> 00:06:30.440
which means scaled. We actually
scaled image manually into the
00:06:30.490 --> 00:06:35.950
right size. Then it will take 625
milliseconds, which is almost
00:06:36.000 --> 00:06:39.100
like three times shorter
than before.
00:06:39.150 --> 00:06:42.430
>> What are the charts here? Where
are they being generated from?
00:06:42.480 --> 00:06:48.230
>> Yes, they actually use the well-known
F12 tools UR responsiveness.
00:06:48.240 --> 00:06:48.450
>> Nice.
00:06:48.500 --> 00:06:55.830
J.D.'s demo, remember in Module
2, we actually spent quite a
00:06:55.880 --> 00:06:58.860
bit of time showing you how to
do that. So this is actually
00:06:58.910 --> 00:07:03.270
using F12 tool using the UR responsiveness
to grab all the data.
00:07:03.320 --> 00:07:07.080
And it's very easy to use, as you
can see. Okay. So I'm sure
00:07:07.130 --> 00:07:10.290
you could do it the same when you
go home, right? Okay. So the
00:07:10.340 --> 00:07:12.540
other things that you probably
want to pay attention is look
00:07:12.590 --> 00:07:17.890
at this, the upper part of the
diagram. The blue coding, the
00:07:17.940 --> 00:07:21.590
light blue code, which is spent
on the image of decoding.
00:07:21.950 --> 00:07:25.600
Look at this because you want to
take it for the convenience.
00:07:25.650 --> 00:07:29.260
You don't want to resize your image
by itself. So it takes a
00:07:29.310 --> 00:07:33.090
bunch of time, a bunch of CPU time
to do the image decoding,
00:07:33.520 --> 00:07:37.090
compared to all the images has
been scaled to the right size,
00:07:37.140 --> 00:07:41.020
you see very minimal decoding
here. So again go back to CPU
00:07:41.070 --> 00:07:45.740
utilization, the scaled image is
much better. And in terms of
00:07:45.790 --> 00:07:50.380
time, the page loading, the right-sized
image is much better.
00:07:50.430 --> 00:07:53.790
So this is actually a pretty
big tip to share with you.
00:07:53.840 --> 00:07:57.160
I've been talking about two different
kind of companies when
00:07:57.210 --> 00:08:00.460
I do the workshop with them. They
all ask me same questions,
00:08:00.510 --> 00:08:04.580
because really thumbnails, same image
but a display with different
00:08:04.630 --> 00:08:08.920
size, with different device, with,
you know, different nature.
00:08:09.270 --> 00:08:13.380
It happens all the time. So you
have to be careful about that.
00:08:13.430 --> 00:08:17.400
So that's one thing. The other things
you may... you may wonder
00:08:17.450 --> 00:08:23.290
is how about their memory allocation,
right. What about how
00:08:23.340 --> 00:08:29.060
much memory they're using. So again, let's
go back to this particular result.
00:08:29.110 --> 00:08:32.980
Again, this is using one of the
tools J.D. shared as a task
00:08:33.030 --> 00:08:37.750
manager, and you can see, very handy,
you can see when you have
00:08:37.800 --> 00:08:42.780
all the image with original size,
it takes about 66 megabytes,
00:08:42.830 --> 00:08:47.990
whereas with a resized, the right
sized image, then you will
00:08:48.040 --> 00:08:52.930
see it's only 37.4 megabytes. So
it's almost half the size if
00:08:52.980 --> 00:08:56.130
you compare it to the previous,
you know, just take for granted
00:08:56.180 --> 00:08:59.530
kind of approach. And then maybe
you will say, okay, it's only
00:08:59.580 --> 00:09:02.930
30 something, you know, megabytes.
No big deal. But think about
00:09:02.980 --> 00:09:07.340
it if you're using low-end device,
right, if your memory is extremely
00:09:07.390 --> 00:09:11.810
constrained, then 30 megabytes is
quite a lot, right. And then
00:09:11.860 --> 00:09:16.540
something is totally worth your
effort to make it reduced as
00:09:16.590 --> 00:09:21.670
much as possible. So again, this
is our first to share with you.
00:09:21.720 --> 00:09:26.400
If you can, resize image to the
exactly required size to avoid
00:09:26.450 --> 00:09:30.970
any unnecessary decoding
and memory usage.
00:09:33.360 --> 00:09:35.710
Now, next thing you probably will
ask me, you'll say okay, you
00:09:35.760 --> 00:09:40.850
know, I have 58 typical kind of
image resource. How should I
00:09:40.900 --> 00:09:44.290
get all the images? Should I get
them one at a time, or are there
00:09:44.340 --> 00:09:48.120
any other things I can do? Okay. So
let's take a look. For example,
00:09:48.170 --> 00:09:52.330
nowadays, as we are all very popular,
use all kinds of social
00:09:52.380 --> 00:09:57.070
network, right. And we're using
all kinds of little icons to
00:09:57.120 --> 00:10:02.780
represent the social media we're
using, and this is trying to
00:10:02.830 --> 00:10:07.900
do with 100 of those icon images,
represent different social
00:10:07.950 --> 00:10:09.470
media and different services.
00:10:10.220 --> 00:10:13.200
So we look at that, it's, of course
it's a little crazy, right?
00:10:13.250 --> 00:10:16.540
I mean thousand image, you know.
Okay. What are you going to
00:10:16.590 --> 00:10:19.750
do with that? Are you going to
try to get those icons one at
00:10:19.800 --> 00:10:23.650
a time, or are you going to group them
together into a certain size?
00:10:24.390 --> 00:10:28.390
So for our benchmark, we use about
30 to 40 images, right.
00:10:28.440 --> 00:10:31.640
That's actually pretty typical, because
average size is 58, right.
00:10:31.690 --> 00:10:35.930
So look at that and there must be a
good way of doing things, right.
00:10:35.980 --> 00:10:40.900
So if you look at a quick example,
say we have in this case we
00:10:40.950 --> 00:10:47.800
have about six icons, right. So
scenario one is we're doing,
00:10:47.850 --> 00:10:52.430
downloading one icon at a time,
right. So six images, we need
00:10:52.480 --> 00:10:57.550
to create six connections. So as
a result, you have total of
00:10:57.600 --> 00:11:04.470
96 kilobytes of the data you need
to download, right. So this
00:11:04.520 --> 00:11:08.690
is a first approach. A second approach
is we should be more smart.
00:11:09.250 --> 00:11:13.440
Why we have to do it one at a time?
Six images is no big deal.
00:11:13.490 --> 00:11:16.260
But if you think about a previous
case, a thousand images or
00:11:16.310 --> 00:11:21.070
even 30 to 50 images that's quite
a lot. We should have a better
00:11:21.120 --> 00:11:24.510
way to group them together and
then, basically, you know, you
00:11:24.560 --> 00:11:28.960
transfer one larger image and then
you only create one connection.
00:11:29.010 --> 00:11:33.400
And in this particular case, as an
end result, you're only using
00:11:33.980 --> 00:11:38.100
21K download. So you should probably
think about to group them
00:11:38.150 --> 00:11:41.540
together, and this is a technique
called the wizard sprite image
00:11:42.510 --> 00:11:46.220
in the past. Now, there are multiple
ways you can actually do
00:11:46.270 --> 00:11:50.060
the sprite images, right. You can
use some sprite tool to do that.
00:11:50.560 --> 00:11:53.300
However, when you use those tools,
be careful. You need to look
00:11:53.350 --> 00:11:57.330
to see those tools would generate
any space. There's a little
00:11:57.380 --> 00:12:01.120
spacing between them because not all
the images are regular, right.
00:12:01.170 --> 00:12:04.230
So you will have some spacing. So
by then, you should think about
00:12:04.280 --> 00:12:07.760
if you could use some simple graphical
tools or using your own
00:12:07.810 --> 00:12:12.240
tools to make less spacing between
them as much as possible.
00:12:12.290 --> 00:12:16.710
That way, you would get a smaller sprite
combined image to download.
00:12:16.760 --> 00:12:21.290
Hence, it will save you the network time
and the number of bytes downloaded.
00:12:21.340 --> 00:12:25.270
So think about using your own
tool instead of sprite tool.
00:12:25.950 --> 00:12:30.550
So this is one tip we want to share
with you, how to get the
00:12:30.600 --> 00:12:36.580
number of image. So again, based
on that particular same site,
00:12:36.630 --> 00:12:42.410
we did another benchmark. Okay. So
in this case, we are actually,
00:12:42.460 --> 00:12:46.130
you know, using one thing is try
to use uncombined way, right.
00:12:46.180 --> 00:12:49.950
We have 30 image, we download
one at a time, right. And the
00:12:50.000 --> 00:12:54.230
other way, second way is obviously
combine all the images in
00:12:54.280 --> 00:12:58.610
the downloader. So performance-wise
again, we use the F12 UI
00:12:58.660 --> 00:13:01.940
responsiveness, check the CPU utilization,
which you will see
00:13:01.990 --> 00:13:08.950
is the uncombined way, it takes
about 210 milliseconds to load
00:13:09.600 --> 00:13:14.500
whereas the combined way, you have
164 milliseconds. So again,
00:13:14.550 --> 00:13:19.400
you actually save quite a bit, at
least I would say 50 milliseconds
00:13:19.450 --> 00:13:23.380
here, right. So 50 millisecond here
and there is actually going
00:13:23.430 --> 00:13:27.430
to at least cost you, let's say, five
percent of your performance.
00:13:27.480 --> 00:13:32.050
So that's actually quite a lot.
So if you really think about
00:13:32.100 --> 00:13:36.880
the whole idea here is being smart
about downloading your resource
00:13:36.930 --> 00:13:41.740
online, right. Like we said, the fewer
number of bytes you download,
00:13:41.790 --> 00:13:45.480
the better your network response,
your page loading time will be.
00:13:45.530 --> 00:13:48.680
So always remember that particular
concept. It's always good
00:13:48.730 --> 00:13:50.370
to keep in mind.
00:13:50.420 --> 00:13:55.160
>> With the sprite too, you're able
to avoid the parallel concurrent
00:13:55.210 --> 00:13:58.570
connection so you can have those
other connections available
00:13:58.620 --> 00:14:03.280
for other resources. Instead of downloading
a hundred icons using
00:14:03.330 --> 00:14:07.200
your six concurrent connections
for each set of the icons, you
00:14:07.250 --> 00:14:10.000
can just use one connection and then
the other concurrent connections
00:14:10.050 --> 00:14:13.240
can be used for scripts
or other resources.
00:14:13.290 --> 00:14:17.060
>> Right, other resources, exactly.
Like JavaScript or some other
00:14:17.110 --> 00:14:20.930
large piece you may want to download,
yes, exactly. So again,
00:14:20.980 --> 00:14:24.620
I want to really emphasize one
more time, your marriage might
00:14:24.670 --> 00:14:28.390
be different. This is actually from
our own benchmark. This is
00:14:28.440 --> 00:14:32.080
our data. You should always try it
in your production environment
00:14:32.130 --> 00:14:38.060
so let me emphasize one more time.
Okay. So next, we're going
00:14:38.110 --> 00:14:42.420
to actually talk about... this is
really a classical discussion.
00:14:43.090 --> 00:14:47.320
So J.D., I remember quite a few years
ago, we had this type of talk.
00:14:47.370 --> 00:14:50.290
Should we use PNG or
should we use JPEG.
00:14:50.340 --> 00:14:50.600
>> PNG.
00:14:50.650 --> 00:14:52.350
>> PNG, okay.
00:14:53.120 --> 00:14:56.020
Some people say no, I love
to stay with JPEG.
00:14:56.910 --> 00:14:59.730
So usually, you know, when I go
to conference or whatever, I'll
00:14:59.780 --> 00:15:03.800
ask the audience and it's always
roughly half and half, right.
00:15:03.850 --> 00:15:07.380
So let's sort of look into that.
Which way should we use, right.
00:15:07.430 --> 00:15:13.440
So if you look into the PNG and
the JPEG, if you have to have,
00:15:13.490 --> 00:15:17.090
say, high resolution kind of images,
right, you need to have
00:15:17.140 --> 00:15:20.770
your photographs, your landscape,
your faces. You need a better
00:15:20.820 --> 00:15:25.250
resolution, then it's probably a natural
choice for you to use JPEG.
00:15:25.300 --> 00:15:30.370
However, for the rest of the other
images, like logos, charts,
00:15:30.420 --> 00:15:34.570
graphs, screen snapshots, these
doesn't require this kind of
00:15:34.620 --> 00:15:38.800
high resolution images. You can
actually very safely stay with
00:15:38.850 --> 00:15:42.380
PNG, right. So in the past, a lot
of time, we say if you don't
00:15:42.430 --> 00:15:46.110
need to use any high resolution images,
you know, stay with PNG.
00:15:46.160 --> 00:15:47.380
It's always good.
00:15:48.480 --> 00:15:53.540
Which is quite true for a very long
time, you know, up to like
00:15:53.590 --> 00:15:57.710
maybe two years ago, even one year.
That's actually very true.
00:15:57.760 --> 00:16:01.360
But I want to share with you some
of the progress we did, and
00:16:01.410 --> 00:16:05.040
share with you some of the results
to see if there's any change.
00:16:05.090 --> 00:16:08.200
So let's look into a little more
detail about... let's just
00:16:08.250 --> 00:16:12.090
step back a little bit because
I actually feel a lot of times
00:16:12.140 --> 00:16:16.690
people are confused about the download
size versus the memory
00:16:16.740 --> 00:16:21.190
size so a download size, it's easy,
right. You can think about
00:16:21.240 --> 00:16:26.470
I have image. The dimension
in this example is 686
00:16:27.680 --> 00:16:30.300
by 1024. It's quite a large image.
00:16:31.080 --> 00:16:37.120
With a disk space, lit take about
500.5 megabytes, right, half
00:16:37.170 --> 00:16:40.740
a megabyte. So not small,
but not extremely huge.
00:16:41.510 --> 00:16:45.870
But if you think about it, this
is your final memory size, no,
00:16:45.920 --> 00:16:50.020
you're wrong. This is just the
download size. So in reality,
00:16:50.070 --> 00:16:54.580
what is the memory size is your width
times your height time four.
00:16:54.630 --> 00:16:58.670
So basically, all the disk size
image is going to times four.
00:16:58.720 --> 00:17:04.150
That will be your truly memory size.
So in this case, it's 2.67
00:17:05.010 --> 00:17:08.630
megabytes decoded. Okay. So somebody
may still remember at the
00:17:08.680 --> 00:17:11.660
beginning, we talk about the statistics.
What is the average
00:17:11.710 --> 00:17:13.840
size per page.
00:17:14.370 --> 00:17:17.950
1.7 megabytes, right. That's the
average size. And here, we
00:17:18.000 --> 00:17:22.650
have, you know, not so huge image.
We already get 2.67 megabytes.
00:17:22.700 --> 00:17:28.610
So 2.67 megabytes, that's the data
you need to do decode after
00:17:28.660 --> 00:17:32.720
you get it from the net. So this
is not trivial. You really
00:17:32.770 --> 00:17:35.810
should think about memory size,
instead of just think about the
00:17:35.860 --> 00:17:39.640
download size. Okay. So one thing
to sort of clarify with you,
00:17:39.690 --> 00:17:42.750
understand what memory size is.
Okay. The second thing we want
00:17:42.800 --> 00:17:47.730
to talk about is a lot of people want to
understand how is image downloaded.
00:17:48.800 --> 00:17:52.290
How does it really happen? What's
the process or what are the
00:17:52.340 --> 00:17:55.270
procedures involved? So let's
take a look at this diagram.
00:17:55.950 --> 00:18:01.330
So I get a [Indiscernible] request and I'm
getting some kind of image and then
00:18:01.380 --> 00:18:05.590
the image will do a partial response,
right. So even though
00:18:05.640 --> 00:18:08.130
the image is a partial response,
it's pretty good, we can start
00:18:08.180 --> 00:18:12.350
doing decoding. So that is all
work. And then another little
00:18:12.400 --> 00:18:14.740
bit of image back, you can
do decoding as well.
00:18:15.290 --> 00:18:18.140
And then keep on doing it until the
image finishes loading, right.
00:18:18.190 --> 00:18:22.010
You finish all the decoding. And
then next step is you need to
00:18:22.060 --> 00:18:25.490
really look into how to process that,
right. For example, converting
00:18:25.540 --> 00:18:29.170
the colors and so on. This is how
you do it in a processing stage.
00:18:29.820 --> 00:18:34.250
Afterwards, then you will say, okay,
pretty much I could actually,
00:18:34.300 --> 00:18:37.700
you know, leave the GPU to take
care of rest of them. So I need
00:18:37.750 --> 00:18:42.560
to spend some time to copy it to a GPU
and then finally display, right.
00:18:42.610 --> 00:18:45.850
This is a whole sort of like procedure
when you see image from
00:18:45.900 --> 00:18:47.350
download to display.
00:18:47.870 --> 00:18:52.080
Now, if you look at some of the
things, you know, which we've
00:18:52.130 --> 00:18:54.250
been watching pretty
closely, like HTML,
00:18:56.090 --> 00:18:59.850
CSS AND the image loading, right,
this is what happened. So you
00:18:59.900 --> 00:19:04.960
have all those resources loading,
and you also have the CPU usage.
00:19:05.010 --> 00:19:09.380
Here, different color represent
different thing. The green area
00:19:09.430 --> 00:19:14.180
represents a decoding how much time
it's going to take from CPU
00:19:14.230 --> 00:19:18.280
perspective and the blue area
is actually how the [Indiscernible] working.
00:19:18.990 --> 00:19:22.960
So what I want you to pay attention
is also there's another piece
00:19:23.010 --> 00:19:26.450
which is GPU, right. So
it does take some time
00:19:27.660 --> 00:19:32.500
for the CPU to do the decoding,
right, as we indicated here.
00:19:32.550 --> 00:19:36.950
And it also takes a little time,
it's actually, you know, it's
00:19:37.000 --> 00:19:41.640
kind of gap. It's a break, right.
Here, from a decoding and
00:19:41.690 --> 00:19:46.730
the time to spend to copy the GPU
and then GPU could, you know,
00:19:46.780 --> 00:19:50.620
process afterwards. So this is
another kind of like little, I
00:19:50.670 --> 00:19:53.610
wouldn't say bottleneck, but this
is another pause, because you
00:19:53.660 --> 00:19:57.200
have to spend time to copy to the
GPU. So when you look at the
00:19:57.250 --> 00:20:00.830
whole thing, there are a few things
you know it's going to cost
00:20:00.880 --> 00:20:04.690
resource, you know, image decoding,
CPU time, time to copy to
00:20:04.740 --> 00:20:09.390
the GPU. That's another little time
you need to spend and that's
00:20:09.440 --> 00:20:13.170
the processing time to do the
kind of conversion. So can we
00:20:13.220 --> 00:20:14.240
do better than that?
00:20:15.450 --> 00:20:17.080
So let's take a look.
00:20:17.130 --> 00:20:24.260
Now, for any browsers, like say
IE 10 and below, everything I
00:20:24.310 --> 00:20:28.140
talk about is true. This is the
normal process. And then you
00:20:28.190 --> 00:20:32.530
did go through all the steps. However,
with the new improvement
00:20:32.580 --> 00:20:38.030
in IE-11, we do have some progress
here. So for one thing,
00:20:39.850 --> 00:20:40.770
basically the
00:20:42.000 --> 00:20:45.740
partial data, partial loading and
decoding, that particular time
00:20:45.790 --> 00:20:49.210
would be reduced because we're looking
at especially using JPEG
00:20:49.260 --> 00:20:53.930
as example. We have a smaller size
and as well as because the
00:20:53.980 --> 00:20:57.930
smaller size, so CPU decoding
time will be reduced as well.
00:20:58.480 --> 00:21:02.750
And then the other thing we did
here is we actually spent less
00:21:02.800 --> 00:21:07.310
time to copy to the GPU. And then
instead of doing all the color
00:21:07.360 --> 00:21:11.110
conversion processing which normally
would take some CPU time,
00:21:11.160 --> 00:21:14.730
we actually say we're going to leave
it at GPU to take care of that.
00:21:14.780 --> 00:21:18.770
We're going to do this processing
on GPU instead of wasting some
00:21:18.820 --> 00:21:22.780
of the CPU time, because GPU is actually
more resourceful, right.
00:21:22.830 --> 00:21:27.520
So again, the decoding time is
shortened and the copy to the
00:21:27.570 --> 00:21:34.440
GPU time is also reduced. And we
leave the processing time for
00:21:34.490 --> 00:21:37.400
the GPU to handle, which is more
resourceful. So as the end
00:21:37.450 --> 00:21:42.930
result, we actually did improve the
performance of JPEG download
00:21:42.980 --> 00:21:45.250
to display quite a bit on IE-11.
00:21:46.080 --> 00:21:51.180
So if you ask me what should I do
if I have an IE-11, if I want
00:21:51.230 --> 00:21:56.400
to use JPEG, yes, I think it's a not
bad idea to use JPEG on IE-11.
00:21:57.890 --> 00:22:00.810
And so you probably don't trust
me, you say oh, why is that?
00:22:00.860 --> 00:22:03.340
I want to actually see it. I want
to know is it really working
00:22:03.390 --> 00:22:06.630
on IE-11. Okay. Let me share with
you some of the benchmark.
00:22:07.120 --> 00:22:11.210
Again, let's go back to this particular
data. We're using the
00:22:11.260 --> 00:22:16.580
same site we just talked about before.
And one of them is totally
00:22:16.630 --> 00:22:21.010
the upper one is using all PNG images
and the bottom one actually
00:22:21.060 --> 00:22:26.450
using JPEG images. And we actually
using task manager and we
00:22:26.500 --> 00:22:31.610
see the result. Actually, you know,
the total size of memory
00:22:31.660 --> 00:22:36.390
allocation is actually different.
For PNG, it takes 51 megabytes
00:22:36.440 --> 00:22:40.280
and for the JPEG, which is actually
higher resolution image,
00:22:40.330 --> 00:22:44.110
you would think it would actually
take more memory. As a matter
00:22:44.160 --> 00:22:49.330
of fact, it's not bad at all.
It takes about 45 megabytes.
00:22:49.380 --> 00:22:53.740
So if you compare to PNG, it's
about six megabytes less which
00:22:53.790 --> 00:22:57.250
I think is quite good. It's pretty
critical especially for
00:22:58.540 --> 00:23:01.790
low end devices. And six megabytes,
that's quite a lot.
00:23:01.840 --> 00:23:04.130
You're saving the memory allocation
here so you can actually
00:23:04.180 --> 00:23:09.930
get the other resources. So if you
can, using IE-11 and you could
00:23:09.980 --> 00:23:14.940
pretty comfortable to use JPEGs. Okay.
So this is a little change.
00:23:15.310 --> 00:23:19.030
PNG and JPEG. And again, this
is a very interesting topic.
00:23:19.080 --> 00:23:24.720
I think the discussion will be going
on and maybe a few months
00:23:24.770 --> 00:23:27.100
or a year from now, maybe we'll
have a different result.
00:23:27.150 --> 00:23:32.830
>> The discussion on memory versus
download size reminds me a
00:23:32.880 --> 00:23:37.810
lot of JavaScript. Download size
of the G ZIP code versus the
00:23:37.860 --> 00:23:40.920
time it actually takes to parse
the JavaScript, it's something
00:23:40.970 --> 00:23:44.180
very similar, where it may download
quickly, but on a low end
00:23:44.230 --> 00:23:47.800
device, it's still going to take
time to parse that JavaScript
00:23:47.850 --> 00:23:52.190
or parse that CSS. And so reducing
that there can give you a
00:23:52.240 --> 00:23:53.140
benefit too.
00:23:53.190 --> 00:23:56.090
>> Exactly, absolutely.
Very true.
00:23:58.160 --> 00:24:00.050
All right. Data URI.
00:24:00.100 --> 00:24:03.400
>> Okay. So I'm going to be talking
over this next section about
00:24:03.450 --> 00:24:05.110
using data URIs.
00:24:05.890 --> 00:24:08.070
So before we talked about
00:24:09.500 --> 00:24:14.340
reducing your http requests with
a sprite, so a single image
00:24:14.390 --> 00:24:16.950
instead of hundreds or
00:24:18.950 --> 00:24:22.530
potentially more http requests.
Now we're going to talk about
00:24:22.580 --> 00:24:26.980
avoiding http requests completely.
So embedding the image directly
00:24:27.030 --> 00:24:29.810
in the page. You can do that with
something called a data URI.
00:24:29.860 --> 00:24:35.420
A data URI is a base 64 encoded image.
00:24:36.030 --> 00:24:42.180
The reason the slide here says for
a small image is because the
00:24:42.230 --> 00:24:46.790
data URI, because it's base 64
encoded, inflates the size of
00:24:46.840 --> 00:24:52.720
the image. So if you have a 0.5
kilobyte file, when you convert
00:24:52.770 --> 00:24:56.820
that to a data URI, it can
be double that or more.
00:24:57.470 --> 00:25:01.150
So this works great for small files.
So like your little icons,
00:25:01.850 --> 00:25:05.330
indicators on buttons, things like
that, this is where you could
00:25:05.380 --> 00:25:10.210
use a data URI, and this avoids
the overhead of the request and
00:25:10.260 --> 00:25:14.060
allows it to just load instantly on
the page once the page is loaded.
00:25:14.110 --> 00:25:19.100
>> It's for a larger image, over
like megabytes or something.
00:25:20.340 --> 00:25:25.860
>> You would not want to embed a
data URI for a megabyte image
00:25:25.910 --> 00:25:26.630
in your page.
00:25:28.580 --> 00:25:32.560
Back to before where we talk about
a balancing act, in this case
00:25:32.610 --> 00:25:36.780
the balancing act is the size of
the base 64 encoded image versus
00:25:36.830 --> 00:25:40.340
the http request overhead. So in
this case, it really works for
00:25:40.390 --> 00:25:43.450
small images. The example of this
is in this slide. You can
00:25:43.500 --> 00:25:47.750
kind of see it. It starts with instead
of a normal protocol of
00:25:47.800 --> 00:25:52.630
http or https, it's the data protocol,
and then there's the mime
00:25:52.680 --> 00:25:56.950
type of the image and then the base
64 encoding. And then it's
00:25:57.000 --> 00:26:01.100
the encoded image there for
the rest of the URL.
00:26:02.120 --> 00:26:02.760
Let's see.
00:26:03.550 --> 00:26:07.650
This talks about the various pieces,
which I've just discussed.
00:26:07.700 --> 00:26:09.990
>> Your syntax you need to use.
00:26:10.040 --> 00:26:13.190
>> Use, right. Well, you may be
thinking this is great. I have
00:26:13.240 --> 00:26:17.710
all these images. How do I convert
my images to base 64.
00:26:18.720 --> 00:26:20.580
If you're following along, you
can do a search for that.
00:26:20.630 --> 00:26:24.250
There's lots of tools available for
you to do this. There's also,
00:26:24.300 --> 00:26:28.770
you can... there's APIs available
in JavaScript and DOM that
00:26:28.820 --> 00:26:31.590
can allow you to get this. Your
favorite programming language
00:26:31.640 --> 00:26:35.900
probably has a way to get your base
64 encoded version of your images.
00:26:35.950 --> 00:26:38.630
So there's lots of options out
there. You don't have to sit
00:26:38.680 --> 00:26:41.220
there and try to come up with this
on your own. There's lots
00:26:41.270 --> 00:26:42.450
of tools available for you.
00:26:43.280 --> 00:26:49.170
>> Cool. Okay. So next we want to
actually look into SVG, okay.
00:26:49.920 --> 00:26:54.530
SVG is very cool, right, especially
you work with like I still
00:26:54.580 --> 00:26:59.800
remember some of the example with
HTML5 SVG usage. Let's say
00:26:59.850 --> 00:27:04.560
you want to get some of the pool
data based on the different
00:27:04.610 --> 00:27:09.360
states in the United States and
then you actually could use SVG
00:27:09.410 --> 00:27:13.370
to represent each of the area of
that state and then you could
00:27:13.420 --> 00:27:17.010
figure out, you know, the boundary
and where it is and with SVG
00:27:17.060 --> 00:27:22.210
it's so easy to do because all
the state shape is irregular,
00:27:22.260 --> 00:27:25.070
so it would be hard to work with
cameras which you have to do
00:27:25.120 --> 00:27:29.130
a lot of mass manipulation. So SVG
is totally cool. However, yes?
00:27:29.180 --> 00:27:34.160
>> There's also the advantage of
SVG is vector so you can, with
00:27:34.210 --> 00:27:39.930
like our big touch screens here
or your tablets, you can zoom
00:27:39.980 --> 00:27:44.260
in on that and they don't pixillate
so you get that crisp, clean image.
00:27:44.310 --> 00:27:47.650
>> Extremely high resolution.
You can zoom in, use it.
00:27:47.700 --> 00:27:50.550
>> So it's very handy for maps
or anything like that, yeah.
00:27:50.600 --> 00:27:56.240
>> True. However, you have to watch
out the complexity of SVG.
00:27:56.910 --> 00:28:01.380
You may use some tools or something
and after tool, you actually
00:28:01.430 --> 00:28:07.080
find extremely complex large amount
of kind of data there.
00:28:07.130 --> 00:28:09.670
And this is actually, you know,
if you think about it, such a
00:28:09.720 --> 00:28:13.620
complexity SVG data, it's actually
going to cost you, right.
00:28:13.670 --> 00:28:16.510
And if you want to download that,
work with that, it's going
00:28:16.560 --> 00:28:20.720
to be, you know, taking quite a
bit of resource to do that so
00:28:21.970 --> 00:28:25.860
by saying that, sometimes you just
say oh, my data is kind of
00:28:25.910 --> 00:28:29.560
complex, what I'm going to do with
that, right. So in that case,
00:28:29.610 --> 00:28:34.360
you can actually find some of the
external tools to reduce the SVG.
00:28:34.410 --> 00:28:38.640
Cue actually make it a little less
complex so that you could
00:28:38.690 --> 00:28:42.040
actually save some of the network
time and downloading time.
00:28:42.090 --> 00:28:45.560
So this is a key. So just
be careful using SVG.
00:28:45.610 --> 00:28:49.750
>> Right. So just like where you have
min fires for your JavaScript
00:28:49.800 --> 00:28:53.260
or your CSS, there's ways to optimize
00:28:55.440 --> 00:28:59.210
optimizers for images too. There's
optimizers for SVG to help
00:28:59.260 --> 00:29:03.590
reduce the complex paths there, because
it's this kind of markup
00:29:03.640 --> 00:29:08.240
that you're downloading. The more
complex your SVG image, the
00:29:08.290 --> 00:29:12.030
more markup you're going to have
and have to download. So being
00:29:12.080 --> 00:29:15.950
able to use G-zip and being able
to use an optimizer on that
00:29:16.000 --> 00:29:19.460
can help reduce the download
cost of the SVG.
00:29:20.160 --> 00:29:27.150
>> Exactly. So next I want to actually
talk another, which is
00:29:27.200 --> 00:29:30.850
video, right. We actually, you know,
if you're looking to a site,
00:29:30.900 --> 00:29:33.910
normally you will see a piece of
video there to make the site
00:29:33.960 --> 00:29:34.500
more fun.
00:29:35.210 --> 00:29:39.480
However, a lot of people, I'm not
sure if tried HTML5 video tag.
00:29:40.200 --> 00:29:44.590
If you look into that, HTML5 video
tag is so easy to implement
00:29:44.640 --> 00:29:50.050
and to use. So let's actually take a
quick example of this code fragment.
00:29:50.100 --> 00:29:54.540
So again, this is basically I want
to actually display a piece
00:29:54.590 --> 00:30:01.090
of video and this is actually the
video tag on the slide, which
00:30:01.140 --> 00:30:06.270
is actually showing you that this is...
if you actually started with...
00:30:06.880 --> 00:30:15.030
>> You can't show that slide.
It's got the...
00:30:16.200 --> 00:30:16.820
>> Oh, okay.
00:30:16.870 --> 00:30:23.280
So let's just talk through it.
If you have a video tag, just
00:30:23.330 --> 00:30:27.840
say, you know, square video, and
then you could actually specify
00:30:27.890 --> 00:30:32.010
the video size, width and height and
you probably could say control.
00:30:32.060 --> 00:30:38.230
Now, one of the ways to make a more
[Indiscernible] or increase the performance
00:30:38.280 --> 00:30:43.040
is actually use a keyword called
poster. Poster is something,
00:30:43.090 --> 00:30:47.490
is like I'm showing some kind of
friendly or funny image before
00:30:47.540 --> 00:30:51.000
so that when the video is loading,
or when I actually start to
00:30:51.050 --> 00:30:53.550
play that video, I will see something
interesting. It's not
00:30:53.600 --> 00:30:57.460
like a totally a black kind of screen.
That's not very interesting.
00:30:57.510 --> 00:31:01.170
That's not nice, right. So I could actually
have a little preview image.
00:31:01.730 --> 00:31:05.290
And then people will say, oh, this
is nice, I see some image.
00:31:05.340 --> 00:31:11.040
I know this video is valid or it's
going to work. So you could
00:31:11.090 --> 00:31:14.890
actually display that and then
at the same time, if the user
00:31:14.940 --> 00:31:20.450
hit on the play button, that's the
time video start to loading
00:31:20.500 --> 00:31:25.160
into the browser. So you can actually
really improve the receiver
00:31:25.210 --> 00:31:28.140
performance because there's image
there and then user can click
00:31:28.190 --> 00:31:32.450
on the button and a video start
to showing up. And even though
00:31:32.500 --> 00:31:35.370
it takes a little while to download,
it's okay. People love
00:31:35.420 --> 00:31:36.090
that image.
00:31:36.730 --> 00:31:40.060
So already, you know, poster is
a really good way for you to
00:31:40.110 --> 00:31:45.340
do a little preview. And one sort
of like, one thing we want
00:31:45.390 --> 00:31:50.390
to actually talk a little bit about
using the HTML5 video, if
00:31:50.440 --> 00:31:53.810
you want to do the it across all
browsers, you want to actually
00:31:53.860 --> 00:31:57.500
take a look at what kind of format
of your video you're using.
00:31:57.550 --> 00:32:03.640
Most likely, the JPEG, the MPEG
4 is going to work very well.
00:32:04.340 --> 00:32:07.780
However, depends on a particular
browser. Some browser doesn't
00:32:07.830 --> 00:32:11.290
want to support it and M federal
government 4, you probably want
00:32:11.340 --> 00:32:17.510
to use web [Indiscernible] so it is
actually safe for me, if I'm doing any
00:32:17.560 --> 00:32:22.750
video display, I always keep one video
format in MP4 and then the other
00:32:22.800 --> 00:32:26.610
the WebM. So this is always safe.
So make sure the video could
00:32:26.660 --> 00:32:31.240
be played for all the browsers,
all kind of browsers. Okay.
00:32:31.290 --> 00:32:35.960
So this is good for the video. We
have some idea. Next I actually
00:32:36.010 --> 00:32:42.280
want to talk about the plug-in.
So we see how powerful it is
00:32:42.330 --> 00:32:46.790
to use the HTML5 video, right? However,
you still see with some
00:32:46.840 --> 00:32:50.950
old browser, you see Flash,
Silverlight, Quick Time.
00:32:51.460 --> 00:32:54.800
All those things are still there,
right. So if you can, try
00:32:54.850 --> 00:32:58.850
to minimize using it or try to
avoid using them, because they
00:32:58.900 --> 00:33:01.890
are there for one thing. It's
not very user friendly. So if
00:33:01.940 --> 00:33:04.980
you have a browser, you have to
use plug-in and you actually
00:33:05.030 --> 00:33:08.190
share a little video with your grandma.
Your grandma say, hey,
00:33:08.240 --> 00:33:10.700
it asks me to download something,
to install something. I have
00:33:10.750 --> 00:33:14.860
no idea how to do that. So basically,
the video doesn't give
00:33:14.910 --> 00:33:18.880
end user really a nice experience,
right. But if you're using
00:33:18.930 --> 00:33:22.520
HTML5 video or audio, then you
don't need to plug in and you
00:33:22.570 --> 00:33:26.120
can show it right away, right. That's
from the user perspective.
00:33:26.170 --> 00:33:29.260
The other thing is all those plug-in,
you would think they would
00:33:29.310 --> 00:33:33.110
save you time. Actually, they're not.
They're competing on the resource.
00:33:33.160 --> 00:33:36.770
They're competing on the network
resource you try to get and
00:33:36.820 --> 00:33:40.330
they're competing on some other
internal resources as well.
00:33:40.380 --> 00:33:44.380
So overall, try to minimize the
usage of plug-in in you can.
00:33:44.430 --> 00:33:48.590
Try to all migrate on to HTML5
video as much as possible.
00:33:48.640 --> 00:33:52.040
>> This is also very relevant
for mobile development too.
00:33:52.090 --> 00:33:56.430
Because mobile phones and things,
portal devices may not have
00:33:56.480 --> 00:33:59.540
the capability to run plug-ins.
00:34:00.110 --> 00:34:04.470
So being able to use HTML5 allows
it to work for a wider audience.
00:34:05.090 --> 00:34:09.290
>> Absolutely. So we talk
00:34:10.670 --> 00:34:15.390
about quite a few things, especially
work with images, media.
00:34:15.440 --> 00:34:20.740
Perhaps it a good time, J.D., show
them web page test, see how
00:34:20.790 --> 00:34:21.700
to utilize those things.
00:34:21.750 --> 00:34:26.260
>> Okay. So earlier, I mentioned
using web page test, where you
00:34:26.310 --> 00:34:31.660
can compare the download speed of
your site and get a breakdown
00:34:31.710 --> 00:34:35.330
on the various techniques that you
need to do to optimize your site.
00:34:35.380 --> 00:34:40.170
So, like, your G-zip and the waterfall
view of the resources downloading.
00:34:40.220 --> 00:34:44.290
So now let's take a look at this
tool. So here's the demo.
00:34:47.510 --> 00:34:52.290
Basically, I went to webpagetest.org
and then I went and I'm
00:34:52.340 --> 00:34:55.810
viewing the download speed of jQuery.
So jQuery is the JavaScript
00:34:55.860 --> 00:34:59.090
library that's on, like, what
95 percent of the web now.
00:35:00.550 --> 00:35:02.080
So this is a view of that.
00:35:02.800 --> 00:35:03.380
Let's see.
00:35:04.140 --> 00:35:07.240
I'm going to just re-run the test
so we can just kind of see that.
00:35:07.870 --> 00:35:10.640
Actually, no, I'm just going to
look at the water fall view.
00:35:11.520 --> 00:35:14.530
So by looking at the waterfall
view. Before that, you can see
00:35:14.580 --> 00:35:19.420
that it shows the time to complete
the first view, the time of
00:35:19.470 --> 00:35:22.930
repeat views. So remember, when
caching is involved, the first
00:35:22.980 --> 00:35:25.920
view, the uncached view will take
longer than the cached view.
00:35:25.970 --> 00:35:30.170
So in this case, the first view
took 1.2 seconds. The repeat
00:35:30.220 --> 00:35:34.280
view took 0.5 seconds. So a little
less than half... or a little
00:35:34.330 --> 00:35:38.720
more than half the time. So that's
a big win on caching whenever
00:35:38.770 --> 00:35:41.760
you have that enabled. So let's
look at the waterfall view.
00:35:43.070 --> 00:35:46.040
This is the waterfall view of
the first view. It does allow
00:35:46.090 --> 00:35:49.060
you to see resources coming in.
00:35:50.130 --> 00:35:54.750
You can see the time to first byte.
So very similar to the F12
00:35:54.800 --> 00:35:57.640
network tool, where it was time
to first byte, time to process
00:35:57.690 --> 00:36:01.130
the request, this is just another
way to view that. So if you're
00:36:01.180 --> 00:36:05.530
not on IE or wanting to test other
mobile devices, you can do
00:36:05.580 --> 00:36:09.230
that with this tool. You can
test in different browsers.
00:36:09.280 --> 00:36:13.640
You can test different locations.
So back to the discussion
00:36:13.690 --> 00:36:16.330
before when we were talking about
your locations for CDNs, this
00:36:16.380 --> 00:36:18.900
tool allows you to pick where the
nearest server is so you can
00:36:18.950 --> 00:36:24.690
kind of see where the distance to
your CDN affects the load time.
00:36:24.740 --> 00:36:27.400
So in this case, this is just showing
you a breakdown here.
00:36:27.450 --> 00:36:31.660
It's got the familiar lines of
blue being... I'm sorry, blue
00:36:31.710 --> 00:36:35.120
being content loaded. So
that is like your...
00:36:36.070 --> 00:36:39.760
the actual resources has been loaded.
Purple in this case is
00:36:39.810 --> 00:36:42.850
DOM content loaded. DOM content
loaded is again where you're
00:36:42.900 --> 00:36:46.590
able to have your script interact
with the DOM and manipulate
00:36:46.640 --> 00:36:50.700
the page and things like that.
So that's really, if you're a
00:36:50.750 --> 00:36:53.030
JavaScript developer, that's what
you're looking for where you
00:36:53.080 --> 00:36:55.730
can first get in and start scripting
the page and adding event
00:36:55.780 --> 00:36:59.730
handlers and things like that. And
the solid blue line, I believe,
00:36:59.780 --> 00:37:01.250
is the page load.
00:37:02.000 --> 00:37:04.540
>> You know what, J.D.? I just think
about we need a standard
00:37:04.590 --> 00:37:08.150
to standardize all the colors that
represents the same thing
00:37:08.200 --> 00:37:10.990
across different browsers, different
tools, that would be nice.
00:37:11.040 --> 00:37:13.900
>> Thank goodness, there is a key
so you're able to navigate the
00:37:13.950 --> 00:37:17.900
waterfall view. This is a pretty
handy tool which you can have
00:37:17.950 --> 00:37:22.550
in your back pocket to compare your
site. As I mentioned before,
00:37:22.600 --> 00:37:26.990
you can also do some AB testing
as well to compare your site.
00:37:27.040 --> 00:37:31.740
Also, there's abilities here to give
you a grade on various components.
00:37:31.790 --> 00:37:35.850
So, like, your compression and
your caching headers too, web
00:37:35.900 --> 00:37:39.340
page test can allow you to do that
too. So that's the demo for
00:37:39.390 --> 00:37:40.250
web page test.
00:37:40.300 --> 00:37:46.540
>> Cool. So hopefully you get some
idea about media images by
00:37:46.590 --> 00:37:48.090
using web page test.
00:37:48.830 --> 00:37:50.810
So we're going to switch the gear
just a little bit. We're a
00:37:50.860 --> 00:37:52.490
going to actually talk about CSS3.
00:37:53.690 --> 00:37:59.080
Now, CSS is actually, you know,
it's very interesting. I have
00:37:59.130 --> 00:38:02.820
been a developer for a long time.
I have to confess, I'm actually
00:38:02.870 --> 00:38:06.070
kind of person kind of overlook
the CSS because I thought it's
00:38:06.120 --> 00:38:10.320
a decorative language. It's not
coding, you know. I actually
00:38:10.370 --> 00:38:14.660
trust my JavaScript coding capability.
I could do things real
00:38:14.710 --> 00:38:17.860
three well, really fast, right?
So all those things, you know.
00:38:17.910 --> 00:38:20.160
It's totally actually misconception.
00:38:21.050 --> 00:38:24.460
There's a big, big improvement
on the CSS3 implementation.
00:38:24.510 --> 00:38:27.740
If you look at all the improvement.
So let's just look at one
00:38:27.790 --> 00:38:33.010
example, CSS3 gradient. Think about
if we don't use any of the
00:38:33.060 --> 00:38:38.080
CSS property, what we have to do
is manipulating all the images,
00:38:38.130 --> 00:38:41.570
getting a bunch of images to create
a gradient kind of effect.
00:38:41.620 --> 00:38:45.250
It's going to waste a lot of resource
to loading all kind of
00:38:45.300 --> 00:38:48.490
images in order to create that.
Plus you have to write a pretty
00:38:48.540 --> 00:38:53.500
fancy JavaScript to make it happen.
Look at how easy it is.
00:38:53.550 --> 00:38:57.720
You could actually use CSS3 gradient.
Then for anybody, it's
00:38:57.770 --> 00:39:02.120
actually lower the entry of the
level for designer, because you
00:39:02.170 --> 00:39:05.160
don't have to know JavaScript
coding. You could use CSS.
00:39:05.210 --> 00:39:08.550
You could still use all the nice
features to make it work.
00:39:08.600 --> 00:39:12.700
And plus, all the CSS3 feature has
all, especially for IE, has
00:39:12.750 --> 00:39:17.040
all the hardware exploration support
so you can use it pretty safely.
00:39:17.090 --> 00:39:20.990
>> You don't have to fire up your
image editor. You can use CSS.
00:39:21.040 --> 00:39:25.280
You're able to use the F12 tools
to edit the DOM inspector.
00:39:25.330 --> 00:39:28.770
You can edit your gradients in real-time
on the page so you can
00:39:28.820 --> 00:39:32.830
experiment and say I like my darker
shade to start a little more
00:39:32.880 --> 00:39:36.000
to the left side or rotate it to
the 90 degree angle. You can
00:39:36.050 --> 00:39:39.920
do that all, like, live in the page
without having to sit there
00:39:39.970 --> 00:39:43.210
and save the file and refresh the
page or sit there and create
00:39:43.260 --> 00:39:46.870
the image, save the image, optimize
the image and import the image.
00:39:46.920 --> 00:39:48.850
So it's a great time saver.
00:39:48.900 --> 00:39:49.410
>> It is.
00:39:50.310 --> 00:39:54.310
A media visual effect if you change
some property. Then if you
00:39:54.360 --> 00:39:59.260
look at this example, it is extremely
easy to configure, right.
00:39:59.310 --> 00:40:03.670
You could actually just... but one
thing sort of like be careful
00:40:03.720 --> 00:40:09.270
is for now, still it's better to put
some of the prefix to represent
00:40:09.320 --> 00:40:14.570
different major browser. And then
always, always put a gradient
00:40:14.620 --> 00:40:18.530
because that would be a final kind
of CSS feature we should use
00:40:18.580 --> 00:40:22.700
and configure like J.D. was saying,
I could show you the demo
00:40:22.750 --> 00:40:26.010
later on. You could actually config
different things, linear,
00:40:26.060 --> 00:40:28.540
the percentage of RGB
to change that.
00:40:28.590 --> 00:40:32.400
>> With vendor prefixes, the idea
is they'll eventually go away.
00:40:32.450 --> 00:40:36.840
So you shouldn't lean on vendor prefixes
as something that is permanent.
00:40:36.890 --> 00:40:40.940
They're designed to be a stopgap
between the time that a feature
00:40:40.990 --> 00:40:43.640
is introduced and the time that it's
standardized. So when you're
00:40:43.690 --> 00:40:47.570
using vendor prefixes, like the
MS or web kit or MOS, be sure
00:40:47.620 --> 00:40:50.430
to include the non-prefixed form.
00:40:51.260 --> 00:40:54.210
You may look at this and say, well
that's a lot of duplication.
00:40:54.910 --> 00:40:59.160
But there is... there is utilities
to make that optimized.
00:40:59.210 --> 00:41:04.540
There's like SaaS or other precompiled
CSS helper languages out
00:41:04.590 --> 00:41:07.690
there for you that take care of all
the vendor prefixes for you.
00:41:07.740 --> 00:41:11.720
So with a little bit of pre-processing,
you can streamline your
00:41:11.770 --> 00:41:16.060
CSS maintenance with gradients
or anything else that requires
00:41:16.110 --> 00:41:17.210
a vendor prefix.
00:41:17.260 --> 00:41:21.410
>> Exactly. Okay. So not just the
gradient. Same thing applied
00:41:21.460 --> 00:41:25.450
to border radius, right. Border radius
is basically around the corner.
00:41:25.500 --> 00:41:28.940
Think about how much work and resource
editor you have to do
00:41:28.990 --> 00:41:33.610
in order to create around the corner.
I'm not a good designer
00:41:33.660 --> 00:41:39.240
and actually, one of my designer
friends says Doris if your image
00:41:39.290 --> 00:41:43.300
or anything is not around the corner,
it's not a good design.
00:41:43.350 --> 00:41:45.760
>> Is not web 2.0. I
mean, web 2.0...
00:41:45.810 --> 00:41:48.520
>> It's not a web 2.0 look and feel.
So you have to make sure
00:41:48.570 --> 00:41:52.460
it's around the corner. So you really
have to sort of like around
00:41:52.510 --> 00:41:56.140
the corner, what's the easiest way
to do that? Border radius, right?
00:41:56.190 --> 00:41:59.450
You just have to put the property
border radius and change your
00:41:59.500 --> 00:42:03.530
particular how you want it to be.
Boom you have everything there.
00:42:03.580 --> 00:42:07.150
So this is how you actually configure
with border radius.
00:42:07.200 --> 00:42:08.660
It can control around this.
00:42:09.430 --> 00:42:13.170
What's more about that is you can also
leverage the transforms, right.
00:42:13.220 --> 00:42:17.160
Transforms, usually you could do
with JavaScript with all kind
00:42:17.210 --> 00:42:22.090
of images to create effect, like
move, rotate, scroll. But now
00:42:22.140 --> 00:42:26.250
it's so powerful, you could have
2D and 3D transformation all
00:42:26.300 --> 00:42:32.520
use CSS3 and you could adjust for
all the nice, easy, configuration
00:42:32.570 --> 00:42:35.520
parameter to do that. Now we're
going to show you a demo later
00:42:35.570 --> 00:42:38.010
to show you how easy it is to do.
00:42:39.380 --> 00:42:43.690
Transitions is another example. Same concept.
Now we have CSS transitions.
00:42:43.740 --> 00:42:47.410
You don't have to stay with previous
way doing the transitions.
00:42:48.440 --> 00:42:52.350
Another one is animations. Because
everybody thinks animations
00:42:52.400 --> 00:42:55.870
have to be writing a bunch of JavaScript
code, watch out this
00:42:55.920 --> 00:43:00.950
and that. But actually, there is a
CSS animation property variable.
00:43:01.000 --> 00:43:04.670
So you can actually use things
like keyframes, you know, demo
00:43:04.720 --> 00:43:09.100
and then change one, like, state
to the other very easily.
00:43:09.150 --> 00:43:12.700
>> So you can avoid downloading a
big JavaScript library in just
00:43:12.750 --> 00:43:15.890
a few lines of CSS create the same
kind of effect. There's even
00:43:15.940 --> 00:43:19.680
easing in and easing out properties
to the animation and keyframes
00:43:19.730 --> 00:43:21.510
that I believe we'll cover
in the demo too.
00:43:21.560 --> 00:43:25.830
>> Exactly. So let's actually go
to the IE test drive and some
00:43:25.880 --> 00:43:28.780
of you ask for the link actually
we shared in the Q&A already.
00:43:28.830 --> 00:43:33.730
So take a look. Again, we want to
demo to demonstrate the CSS3
00:43:33.780 --> 00:43:38.870
new features on IE test drive.
So I'm probably going to skip
00:43:38.920 --> 00:43:42.400
with the gradient but start
with the 3D transform.
00:43:43.050 --> 00:43:46.890
So what you could see here is this
is a very nice tool, right.
00:43:46.940 --> 00:43:50.770
It gives you all the particular,
like, configuration you need
00:43:50.820 --> 00:43:56.570
to work around and then you can
even say, oh, I want to rotate
00:43:57.190 --> 00:44:02.980
3D and I actually want actually play
with different things, different
00:44:03.030 --> 00:44:10.250
degree, different X axis, Y axis,
Z axis, right. And once you
00:44:10.300 --> 00:44:14.390
say, ah, this is a state I like,
and you could actually just
00:44:14.440 --> 00:44:18.830
copy and paste all the configuration
data here and then directly
00:44:18.880 --> 00:44:23.350
copy and paste into your code.
Don't you like copy and paste?
00:44:23.400 --> 00:44:26.630
This is just so efficient, right?
And you can use, leverage this
00:44:26.680 --> 00:44:30.090
visual tool to do that. Then you don't
have to play with JavaScript
00:44:30.140 --> 00:44:33.660
again to take a look if that's
what you want. So again, you
00:44:33.710 --> 00:44:37.360
know, it's very fast to do. If
you see a change in any one of
00:44:37.410 --> 00:44:42.910
them, you see how responsive it
is. So that's a transforms.
00:44:43.370 --> 00:44:48.390
And then another one which I like to share
with you is actually animations.
00:44:48.710 --> 00:44:52.800
And animations is the same thing.
You can play with the ease
00:44:52.850 --> 00:44:57.200
in, ease out. You can have different
parameters to play with.
00:44:57.250 --> 00:45:01.610
And you could play with all the
things to see if that's exactly
00:45:02.030 --> 00:45:06.340
time interval you want to do it
again. And then also, you could
00:45:06.390 --> 00:45:10.260
actually specify the keyframes. Okay.
So with that, I'd actually
00:45:10.310 --> 00:45:15.220
like to share with you a very simple
example. This is one actually
00:45:15.650 --> 00:45:19.850
using CSS animation. There are
two approaches within here.
00:45:19.900 --> 00:45:23.710
One is dependent, which means I'm
going to write some JavaScript
00:45:23.760 --> 00:45:29.890
code into it. So what I do is I
basically create a spinner and
00:45:29.940 --> 00:45:34.250
that spinner keep on rotating, and then
I'm writing the JavaScript code.
00:45:34.300 --> 00:45:37.050
Actually, I cheated a little bit
here because we're using the
00:45:37.100 --> 00:45:42.630
Windows MS CSS matrix kind of property
to do that. So this is
00:45:42.680 --> 00:45:48.060
what I used to control the spinner
style and also using the transform
00:45:48.110 --> 00:45:52.790
to rotate ten degrees at a time. So
this is a totally a JavaScript
00:45:52.840 --> 00:45:55.850
kind of approach. And then the
other approach we do is let's
00:45:55.900 --> 00:45:59.390
say forget about JavaScript, right.
I'm a CSS person. So I'm
00:45:59.440 --> 00:46:03.900
just actually using, very comfortably
using the animation kind
00:46:03.950 --> 00:46:08.820
of CSS, which is specify the property
with a spinner and then
00:46:08.870 --> 00:46:14.470
using the keyframes and the transform
frame degree to 360 degrees
00:46:14.520 --> 00:46:18.980
and using the transform CSS property.
Okay. So let's actually
00:46:19.030 --> 00:46:25.630
take a look what's the difference
here. So let it run and you
00:46:25.680 --> 00:46:30.500
will see the first one is probably...
it's actually captured
00:46:30.550 --> 00:46:31.240
some data.
00:46:32.070 --> 00:46:34.200
This is again URI responsiveness
data.
00:46:35.720 --> 00:46:38.750
So let's let it rotate
for a little bit.
00:46:38.800 --> 00:46:46.910
And now, you actually see something,
which is I'm actually resizing
00:46:46.960 --> 00:46:50.120
it, just like J.D. showed
us how to do that.
00:46:51.500 --> 00:46:54.410
So we could actually take a look
at just for that little time
00:46:54.460 --> 00:46:57.390
frame, maybe I could pick something
a little further down,
00:47:00.010 --> 00:47:00.680
like here.
00:47:02.380 --> 00:47:06.970
And we see there's quite a bit
of JavaScript loading as well
00:47:07.020 --> 00:47:11.020
as the rendering time and every
other things, right.
00:47:11.070 --> 00:47:16.800
And then let's actually quickly
show with the CSS approach.
00:47:18.130 --> 00:47:25.150
Which is totally independent of
that. And again, we run the
00:47:25.200 --> 00:47:28.020
F12 tools to compare. Okay. Now
again, let's actually take some
00:47:28.070 --> 00:47:29.420
data, like one second kind of
00:47:36.170 --> 00:47:39.960
data, expand it
00:47:43.810 --> 00:47:48.210
and what we see here is really there's
some starring going on,
00:47:48.260 --> 00:47:51.590
there's nothing on JavaScript, because,
you know, simply we use
00:47:51.640 --> 00:47:54.780
CSS, not any JavaScript, right.
So that make sense. That just
00:47:54.830 --> 00:47:58.700
tells you CSS animation could be
pretty powerful, especially
00:47:58.750 --> 00:48:01.740
you have a simple application like
that. You don't really have
00:48:01.790 --> 00:48:06.010
to always write JavaScript to do
that. Okay. So one more piece
00:48:06.060 --> 00:48:09.850
of data I want to share with you is the
result of this little benchmark.
00:48:09.900 --> 00:48:13.500
So what we see here this is using
the Windows performance tool
00:48:13.550 --> 00:48:17.620
and what you see here is you will
see we're comparing all the
00:48:17.670 --> 00:48:22.470
three parameters, CPU, GPU, VSync.
And for the JavaScript mode,
00:48:22.520 --> 00:48:26.080
you actually have two additional
threads, HTML UI thread and
00:48:26.130 --> 00:48:29.550
render thread you have to work with.
Whereas with the CSS case,
00:48:29.600 --> 00:48:31.750
you don't have to worry about that
at all, because you're not
00:48:31.800 --> 00:48:36.000
using any JavaScript here. So save
the thread resource as well
00:48:36.050 --> 00:48:41.860
as a lot of other resource. For the
GPU, CSS directly work with GPU.
00:48:41.910 --> 00:48:46.410
And compared to the JavaScript case,
you have to work with a browser.
00:48:46.460 --> 00:48:51.020
So that's one more like entity
you really have to work with.
00:48:51.070 --> 00:48:53.450
And then resource wise, if you
look at it, you know, this is
00:48:53.500 --> 00:48:57.070
actually the GPU utilization and
two small peaks, versus the
00:48:57.120 --> 00:49:01.900
CSS is one small peak. Okay. So
you see the advantage of using
00:49:01.950 --> 00:49:05.070
all the CSS just by themselves and
that they're very powerful.
00:49:05.120 --> 00:49:08.580
It's very rich. You could actually
go back to the same demo I
00:49:09.260 --> 00:49:13.030
showed you and play with more
CSS feature. Okay. So wrap it
00:49:13.080 --> 00:49:17.990
up, we talked about how to minimize
the media, work with image
00:49:18.040 --> 00:49:23.750
more smartly, how to optimize as
much as possible. We also highly
00:49:23.800 --> 00:49:28.120
recommend you look into CSS3 feature
instead of just trust any
00:49:28.170 --> 00:49:34.190
third party library or your code.
And we're going to stop here.
00:49:34.240 --> 00:49:36.230
We're going to take ten minutes break.
00:49:37.010 --> 00:49:42.040
We're going to talk about next
module is about structure, the
00:49:42.090 --> 00:49:46.420
markup and so on. So see you in
about ten minutes. Thank you.