PAUL: I have been a bit worried about your little peanut
head in winter.
And with it coming up to Thanksgiving,
I thought, well, I'm thankful for Jake.
So I got you a present.
I bought you a hat.
JAKE: I have a hat.
Oh my word.
PAUL: It's both on brand for Thanksgiving.
JAKE: It's all I hoped for and more.
What do I do with these?
They're going to chafe.
[MUSIC PLAYING]
PAUL: The network people for a long time have had all the fun.
And now it's the runtime time.
We've got a new API.
It's the web smoothness API.
JAKE: The web smoothness API?
Please tell me it's just web smoothness true
and then the web is smooth.
PAUL: Yes.
Now, the problem with that name kind of came up in the feedback
from other vendors.
And they said no, actually, it isn't that.
Because it's about measuring information.
It's not about whether you're going to switch on smoothness.
And it does sound like that, doesn't it?
So it's actually been renamed to the frame timing API.
JAKE: So it's going to give us some
of what we have for the network [? tiny ?] API
but for rendering?
PAUL: Yeah, pretty much.
So I think most people are used to the idea
that they use something like DevTools Timeline.
They get all the records, like what's your frames per second,
but that only applies to the machine they've got, right--
their desktop machine, their phone,
whatever they've got on their desk or in their lab.
This is about doing it at like an API level,
so you can do it out in the wild.
So all your users, you could, in theory,
measure your transitions, your animations, your scrolling,
all those things, and start to get a lot more data
about what's going on in your main thread, what's
going on in your compositor thread.
JAKE: So you could use this to, say, find out--
in combination with the user agent string--
find out on a particular device that you've never even tested
before, maybe you've never heard of before,
but you have a major performance problem there.
PAUL: You may not even do it through the UA string.
Because you can collect these bits of information and beacon
them back to analytics or something like that.
And it will do all that hard work of what device it was,
or where it was in the world, and all those things.
And you could just beacon back events
and say, well, look, I think it was 60 frames a second.
And then you could slice the data however
make sense to you, really.
JAKE: So how can I tie these events
back to the elements that are causing the problem?
Does it tell me which element has
been drawn, which element's been composited?
PAUL: Nope.
So the API is actually quite low-level, I suppose.
And it doesn't say what was going on,
because the browser doesn't really
know ahead of time what makes sense.
So it just kind of goes, here's what the main thread was doing.
Here's what the compositor thread was doing.
And you're responsible for marking those areas yourself.
And the spec itself is still in flux, right?
So there's a lot of opportunity for developers
and other vendors to kind of come
back and bike shed it until we get to something
we think is great.
But at this point, hopefully, there's
enough base information in there and in the API
that people can start using it, start
pulling data from the works.
We've heard so many times, it's so hard.
I do the measurement in my own machine,
but I don't know if I've actually
got runtime problems out in the wild.
I know this for network because I've got webpage tests.
I've got all these other APIs.
So this is the first API we should get for this.
It's very exciting.
JAKE: Do you give them feedback to the stuff?
Where is it?
Is it W3, is it--
PAUL: W3.
There's a W3C repo/frame-timing and all the issues on there
and there's an explainer doc and the latest draft of the specs.
So, well worth checking out.
JAKE: Real world analytics for rendering.
PAUL: Woo-hoo!
[MUSIC PLAYING]
JAKE: So it's been conference season.
So I've been doing a lot of traveling.
And so you've got your suitcase full of clean clothes.
As the week goes on, they become soiled
by your personal wearing.
PAUL: They become soiled.
Maybe time to go and see somebody.
JAKE: There's just general personal soilage.
PAUL: Oh.
Let's move on.
JAKE: So we were speaking about getting undressed.
You do the flick off [WHISTLES], catch.
Where did it go?
PAUL: Oh.
Into the suitcase?
JAKE: Not with your clean clothes.
[INTERPOSING VOICES]
JAKE: You monster.
PAUL: No, you unpack them like a grown-up
and you put them in the drawers.
JAKE: They're folded-- in the drawers?
That's where stuff gets forgotten.
Your clothes, all nicely folded already, stay in the suitcase.
So I have a solution.
I take with me a bin bag.
And that is where the dirty clothes go.
And this has many advantages, right?
Because you put them in there.
It's a separate place for them to go.
Keeps them separate from the clean clothes,
which are all nicely folded in the suitcase still.
And it also locks the freshness in.
But because it's airtight, which is a plus,
at the end of the week it becomes negative.
Because you need to pack that away.
And in order to get it back in the suitcase,
you need to lose the excess air.
PAUL: No.
JAKE: And you go for a process that I've
come to know as stinky bagpipes.
[MAKES BAGPIPE SOUND]
PAUL: [MAKES BAGPIPE SOUND]
JAKE: You get to play a sad, sad song.
[MUSIC PLAYING]
JAKE: OK, Paul.
I want to talk to you about font rendering.
PAUL: Ooh.