Thanks.
Whoa, there's some bass.
Oh, yes.
Thanks again.
Take a seat, and we'll come back to you
at the Q&A session in a few minutes.
So on to the next talk, to do with the technical aspects
of performance.
The next person we have-- again, this dovetails so nicely,
because Akamai was mentioned right there and then.
And we're going to build on that right
now with a talk from someone who works at Akamai.
Tobias is based at Akamai and where
he's a Solutions Architect.
So many people will be familiar with Akamai already as the CDN.
But really understanding how Akamai
could be used to improve your performance and the kind
of products that they can build to tune your performance
and understand that better is the kind of things
that Tobias has been involved in.
We heard a little bit earlier on from Estelle about images
and optimizing images.
And I think that might be something
that we build on in this talk, which is beautifully titled
Your Hero Images Need You.
So I'm already excited about that.
So please make him very welcome.
It's Tobias Baldauf.
Thanks, everyone.
Just like Jan, I'm probably going to need a second
to see if everything's working.
So there's a cursor.
That's a good thing.
And now if the clicker is working,
that's going to be even better.
Excellent.
All right.
Here we go.
Yeah, like Phil already mentioned, my name is Tobias.
I've been without Akamai for two years,
but I've been dabbling with image optimization
for the better part of four years now.
Friends of mine have called me the guy who
knows most about images, or another friend
called me the guy who fixed JPEG compression.
Let me show you none of this is true.
It's all a grand lie and scheme to get me a better pay raise.
But what is true, is I invented block level JPEG compression
and a tool that lets you automatically
find the best JPEG compression quality for input image.
That has been what I did in the last two years.
Today I am very, very happy and, honestly,
super nervous to present something completely new.
So today here at Fronteers I'm going
to give a talk I've never given before.
And I'm going to do it on a tool I've never used before.
And I'm going to talk about something
I've never talked before.
So if anything goes wrong, all right.
Yeah, like this clicker not working again.
Ah, man.
This is not going off well.
Come on.
Be nice.
Yes.
Here we go.
No.
Ah, finally.
So what I am going to talk about today is,
I'm going to show you a completely new technique
to optimize images, to get better speed index of plus 6%,
building on top of all existing best practices.
So everything you know about image optimization
or what performs forms optimization,
this is something that gives you an extra 6% of boost
for the speed index.
And I'm going to show you that it's
possible to give a beautiful visual impression tool
you use with only 15% of image data sent over the wire.
So I hope you-- so before you boo me off the stage,
because that all sounds like too good to be true
and a snake oil salesman, let me show you some data.
So like we heard already today before,
images are a big concern of ours.
Our way of treating images actually sucks.
If you look at the data from HTTP Archive-- again,
HTTP Archive, thank you Steve Souders-- images
are the biggest part of each website, currently about 64%
of all the data we send over the wire to render web page.
JPEGs make up almost 50% of that.
And because of that, images have a high correlation
to page load time and a very high correlation
to speed index, obviously, because without an image,
the page doesn't look complete.
So what can we do to fix this?
And as Jan has already mentioned,
HTTP2 is an awesome tool we can look into
to optimize the delivery of our bigger and bigger websites.
Images, for example, are currently
growing 200 kilobytes per year.
So we need to find a new way to deliver all that massive data,
and HTTP2 is here to help us.
Jan already showed a very, very beautiful and very, very
complex technological graph.
So I think I can't top this, so I went for licorice.
This is the difference between what
HTTP1 can do for your website and what
HTTP2 can do for your website.
HTTP1 is like, yeah, the bland little sweety thing.
It's kind of nice, it's licorice.
Who doesn't like it?
But HTTP2 is like all the gorgeous tastiness you could
ever want in one big package.
And you can just chew it all in.
I love HTTP2.
If this is maybe too much focused
on sweets for your tummy, here's a little more technical view
of things.
On the left-hand side you'll see what
HTTP1 would be doing with a traditional waterfall graph
we've all come to know.
You see Chrome in action with six simultaneous connections
and that nice little ladder of assets being downloaded.
The demo site you're seeing is set up
that it has minimal HTML and CSS footprint.
The CSS inlined, and it just contains 20 images.
But the 20 images ramp up to 1.6 megs,
so it should roughly resemble what
the average website currently is holding in terms of image data.
And on the right-hand side, you see what HTTP2
is able to do for your website.
So all the requests start simultaneously.
There is no connection limit or anything.
And everything gets delivered instantaneously.
That is pretty awesome.
That is basically what Jan mentioned as multiplexing.
This is multiplexing in action.
It's very, very, very cool.
By the way, a little footnote.
I just found out like two weeks ago,
if you intend to use HTTP2, and I
hope you all will be or are already,
consider checking your initial congestion window,
because you need a different one for HTTP2 than you
need for HTTP1.
Just a little hint here.
There's a blog post going to follow on that.
So ingredient number one for the hopefully snake-oil-free
solution to deliver images faster by 6%
and to get a better visual impression
is HTTP2's multiplexing.
But inside that diagram we just saw,
there is another ingredient hiding.
And that was in the lowest graph.
That was the browser main thread rendering.
And here you can see 850 milliseconds
spent on paint in HTTP1 and only 400 milliseconds spent
on paint times in HTTP1.
And you might be wondering, hmm, why is that?
And the answer is, if you consider what I'm shipping
here, I'm shipping images.
So why is HTTP2 suddenly far more efficient
in rendering the website too, although it's just a protocol?
Oh, "just a protocol."
It's because it's progressive images.
I'm using progressive JPEGs.
So what are progressive JPEGs?
On the left-hand side, you see the traditional baseline
sequential JPEG rendering, the window blind effect.
Everybody hates it.
And on the right-hand side, you see gorgeous or, in parts,
gorgeous progressive JPEGs.
They start with that little preview that basically gives
you the blocky color thingy, and then it
gets better and better and better
and suddenly it's all there.
This is very, very nice, because it gives your users
an indication of how the image is going to look soon,
and it gives your browser the ability
to lay out the website sooner.
Because with sequential, it doesn't
know the height and width of the image
until it's fully downloaded, while with progressive, it
knows it after the first scan layer.
And this is a term I'm going to be using a lot now--
scan layer.
All right.
So scan layers.
You can see different scan layers in this image.
It's an image of the Rhine River that's
passing the beautiful town of Dusseldorf.
On the left-hand side, you see scan layer 1.
In the middle you see scan layer 5.
On the right-hand side, you see scan layer 10
where the image is complete.
So how does that work?
In progressive JPEGs, we have 10 scan layers that
make up the image by default. The first one you can see
is grayscale, and in that resolution it looks OK,
but it's actually quite blocky.
I'm going to show you that in a second.
Then in the second layer, you can
see that the Rhine is suddenly purple, which is weird, right?
But the image has at least color now.
Then it gets better and better and better and better
until all the data has been sent,
and the image renders completely in scan level 10.
This is the default, how this is supposed to work.
And there is a code for that hidden inside CJPEG
and inside it switches on how it's going to do this.
This is called the scan file.
It is aptly hidden under the section called "For Wizards."
So I didn't bring my Wizards hat,
but I'm kind of proud that I touched this,
because not many people have touched this kind of stuff
in the last couple of years.
So I'm really happy that I got to play with it.
And this is what the scanned file is supposed to do.
JPEG encodes its image information
in a brightness channel and two color channels, that is,
red and blue.
So that's YCRMCB.
CRM
The first, the yellow circles, tell the JPEG encoder
which color information channel to send from.
So 0 is brightness and 1 is blue channel and 2 is red channel.
And the things I circled in green
tell the JPEG encoder which pixels from each 8 x 8
block to send.
Because JPEG iterates over an image by 8 x 8 blocks.
So that means we have 64 pixels to send information on.
And JPEG is doing that, if you don't
tell it to do differently, in zig zag order.
So not [SOUND EFFECT] like sequential but more like this.
That's the a zig zag order.
So 0 to 63 are the positions of pixels in which information
we want to send from them.
So this is how the 10 scan layers get created,
by this command.
This is what the CJPEG does natively
if you don't tell it to do anything else.
And this is what the first scan layer of that output
would look like.
I showed you the preview before.
This is it in its full HD glory, completely pixellated,
grayscale.
But the good news is, over HTTP2, pretty
quickly to render, which means the browser can at least show
something, and it can lay out the page.
So that's the benefit of progressive JPEGs here.
So the first scan layer, it ships fast, and it shows soon.
That's good for the browser.
That's really, really good.
And this is the crucial element here.
This initial scan layer shipping benefits immensely from HTTP2.
While we saw with HTTP1, only maximally five images
could get the first scan layer out in our test site.
With HTTP2, we could get, theoretically, infinite number
of scan layers out initially, which
makes the browser far more efficient in laying out
the page and showing something to the users, which is good.
So this is something to keep in mind.
So progressive JPEGs are another important part
of that, hopefully snake-oil-free solution.
So you might ask yourself, OK, that's all nice and well,
but how fast is that actually doing?
How fast can I go with HTTP2 and progressive JPEGs?
Because at the end of the day, we're
trying to make the website faster for everybody,
so we want to have some seconds-- milliseconds data
to go on.
So this is WebPagetest results for the test site.
By the way, before anybody throws something heavy at me,
this is all median of medians run over days.
So this is quantifiable.
Thank you very much.
So, again, I've circled in the good parts and the bad parts.
HTTP1 basically loses out all across the board.
Load time is worse, start render is worse.
The speed index, which is the crucial element for my talk
here, is worse.
And, of course, then the fully loaded is worse.
HTTP2 wins everywhere.
The important bit being that the speed
index, as you can clearly see, is more than a second faster.
That's really, really, really cool.
So just shaving off an entire second of load time
just because you've switched protocols.
So the work HTTP2 is doing for us is fantastic.
It's really, really good.
But it's also great for the user experience
because, as you can see in this visual progression graph
from WebPagetest, the progressive JPEGs
ship much faster over HTTP2 because
of their separate scan layers that are shipping.
And thus gives the users a faster visual impression
of how the entire site is going to work.
HTTP2 is the red graph that clearly
wins everything versus HTTP1.
That's pretty, pretty neat.
I also brought you a video of that,
and I'm hoping with my flimsy excuse of a presentation
framework that this is going to play.
Oh, no, it's not.
Of course not.
Hold on.
[SOUND EFFECT] Ah, you cursor.
There you go.
Ha.
On the green is HTTP2, obviously.
Much faster.
So this is with 0.1 seconds resolution in the video.
And as you can see, HTTP2 clearly wins out.
HTTP1 is still going while I'm talking.
So that's really, really cool.
HTTP2 renders the website much, much faster.
But now, you might say, well Tobias,
that's all nice and well, but HTTP2 has so many changes.
Like Jan already mentioned, there
are so many cool things happening under the hood,
we can't really see the benefit of progressive JPEGs here.
Maybe sequential JPEGs render faster on HTTP2 too.
So, yeah, so how about we just check out our sequential JPEGs,
these window blind JPEGs are doing, because then we
get an actual number as to how much benefit
we have from progressive JPEGs.
So, again, I circled it.
The speed index is more than 350 milliseconds better
for progressive JPEG, because the browser
can show more stuff sooner.
The user gets an impression of lots of the images much,
much sooner than with sequential baseline.
So that's really, really good.
Again, you can see it in the visual graph.
I mean, now the gap is a little closer,
but you can still clearly see that progressive JPEG wins out
against sequential JPEG even if we
used HTTP2 for both instances.
And, again, for the effect, I also provided a video for it.
Let's see.
Here we go.
Sequential on the left, progressive on the right.
And here we go.
That's pretty neat.
You can see that in some parts, the competition is closer,
like we saw with the two visual graphs being closer together.
But the user experience of the images showing up
like this and lots of them showing up like this
is much better than the window blind effect we have.
So that's all nice and well.
And that's something we should have been doing for ages.
Progressive JPEGs aren't very well used right now.
I think about 12% of the JPEGs I sampled currently
have progressive encoding, which should be much, much better,
especially with HTTP2.
But now you might ask yourself, well, that's all nice and well,
but I could have done that without listening
to you, Tobias.
And you're right, you could have.
But maybe I can show your something
to make things even faster.
And, yeah, we can go even faster.
So to go even faster, we have to look
at the guts of JPEG encoding, at the viscera.
And here's my version of progressive JPEG encoding
viscera.
This is the scan script that I wrote instead of relying
on the default level.
So what am I doing here?
You can clearly see that I'm not shipping 10 scan levels.
I'm only shipping five.
In the first scan level, I ship information
which is called the direct current, the first bit
of a 64-bit metrics, all at once for all three channels.
That guarantees me that my initial preview has color,
unlike the preview we just saw with grayscale.
In the second one, I ship half of all the brightness values.
In the third and fourth, I ship all the remaining color
information.
In the fifth, I just provide the left-over brightness
information that it probably hopefully won't need.
So this is what I came up with.
And here's how it looks like.
That's the initial scan.
Pretty good, eh?
I mean, compared to the black and white blocky thing, that's
pretty good, because just the initial scan
of the whole thing.
And here is the kicker.
This is scan level two out of five instead of scan level 10.
And this is already a very, very close approximation
of the final image.
Now, with the third and fourth scan layer,
we just get more color information.
But let's go back two.
You can still see that in scan level two,
the image already looks OK.
So here's a little more color and then finally--
now pay close attention.
You see nothing.
The fifth scan layer really doesn't matter at all anymore.
After the second scan, we've provided so much good
visual information already, that the image looks
pretty OK to most of the users.
So that's really, really nice.
So let's see how much faster that technique
renders in comparison to standard progressive JPEG.
I have aptly called that optimized progressive JPEG,
so OPJPEG instead of PJPEG.
So here, things get a little more heterogeneous.
It's not such a clear-cut yes-and-no, black-and-white
answer anymore.
You can clearly see that I am shipping a little more data,
because now my scan layer is a little more heavier
at the beginning.
So the progressive JPEGs with 10 scan layers
are a little smaller, therefore the visual complete
is a little faster.
But the speed index is another 110 milliseconds faster,
which averages out in median of medians for 6%, the famous 6%
I mentioned in the beginning.
Woohoo!
Here they are.
So with my technique, I can shave off another 6%
of the speed index of the site.
Again, this is quantifiable.
And here's the visual graph for that.
And again, you can clearly see it's not
as black and white as it was before.
But we see after the initial hit that we
take, because my initial scan layer is now a little heavier,
which is why the red bar is a little to the back,
it overtakes progressive JPEG visual progression
after about 1/3 of the image data.
And then it is superior all the way out.
So with this technique of manipulating the scan layer
creation process, we can successfully
manipulate the speed index to another whopping 6%
on top of everything we've known before.
So this is something I'm really, really proud of.
And this is something your users will really, really
be happy about, because they can see their beloved cat
images much, much sooner in better resolution.
All right.
So time for takeaways.
Ingredient number one, please, please start using HTTP2.
It's brilliant.
It's wonderful.
It just works.
It's out of beta at Akamai.
It's free for everybody to use.
Thanks to Let's Encrypt, it's just a brilliant piece
of technology.
There's really no reason why you shouldn't be using HTTP2.
Second, please, please, please again start
using progressive JPEGs people.
I mean, it's really easy.
Every JPEG encoder can do it now.
By the way, the best traffic encoder is Mozjpeg.
So maybe you want to switch to that.
But every JPEG encoder can do progressive JPEG encoding now.
And when they can do it and, like I said, most of them
can, you can supply them with a separate scan.txt
file containing your own wizard hackery
optimizing the scan level creation process, which
will yield you a whopping 15% to image data
to start rendering something meaningful to your users.
And it will improve the speed index of your sites by 57%,
with 6% of that just being because you
optimized the scan layers.
So that's it.
Thank you very much.
[APPLAUSE]