607.srt

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:00.506 --> 00:00:09.496 A:middle
[ Silence ]

00:00:09.996 --> 00:00:10.486 A:middle
>> Simon Fraser: Good morning.

00:00:11.616 --> 00:00:13.516 A:middle
This session is about
Power and Performance,

00:00:14.096 --> 00:00:16.326 A:middle
Optimizing your Websites
for Great Battery Life

00:00:16.326 --> 00:00:17.406 A:middle
and Responsive Scrolling.

00:00:18.136 --> 00:00:19.956 A:middle
I'm Simon Fraser
and I'm Engineer

00:00:19.956 --> 00:00:23.306 A:middle
on the Safari and WebKit Team.

00:00:23.506 --> 00:00:27.116 A:middle
So as you've heard about all
week, one of our primary goals

00:00:27.766 --> 00:00:32.406 A:middle
with OS X Mavericks was to
get great power efficiency

00:00:32.926 --> 00:00:36.186 A:middle
but still maintain and even
improve responsiveness.

00:00:36.506 --> 00:00:41.226 A:middle
So through all the levels of the
operating system we've optimized

00:00:41.506 --> 00:00:44.126 A:middle
for fast performance
and long battery life.

00:00:44.586 --> 00:00:46.956 A:middle
And we know that battery life
is really important to you

00:00:47.206 --> 00:00:48.696 A:middle
because we all use
MacBook's every day

00:00:48.696 --> 00:00:50.416 A:middle
and you really want
that all day battery.

00:00:50.936 --> 00:00:53.646 A:middle
And we also know that you spend
a lot of time browsing the web

00:00:54.416 --> 00:00:57.296 A:middle
so you want a web browser
that's super power efficient and

00:00:57.296 --> 00:00:59.586 A:middle
yet still feels fast
and responsive.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:01:00.106 --> 00:01:03.006 A:middle
But that's not an easy
thing for a web browser.

00:01:03.906 --> 00:01:05.756 A:middle
Web browsers have to
load complex pages.

00:01:06.206 --> 00:01:08.446 A:middle
Those pages contain scripts
that have to be executed.

00:01:08.656 --> 00:01:10.016 A:middle
They load plugins and so on.

00:01:10.586 --> 00:01:13.046 A:middle
So this is quite a challenge
but this is a challenge

00:01:13.046 --> 00:01:17.026 A:middle
that we've met head on in Safari
7 so we have a great new set

00:01:17.026 --> 00:01:18.386 A:middle
of features in Safari 7

00:01:18.656 --> 00:01:20.336 A:middle
that give us much
better power efficiency.

00:01:20.846 --> 00:01:24.096 A:middle
But we also need your help.

00:01:24.686 --> 00:01:28.466 A:middle
In many ways we can only be as
power efficient as the web pages

00:01:28.466 --> 00:01:31.956 A:middle
that we load and display so
we need your help to make sure

00:01:31.956 --> 00:01:33.386 A:middle
that your pages are
power efficient

00:01:33.386 --> 00:01:34.776 A:middle
and that they also play well

00:01:34.776 --> 00:01:36.566 A:middle
with Safari's new
power saving features.

00:01:36.846 --> 00:01:41.336 A:middle
So I'll be talking about
that later on in the session.

00:01:41.466 --> 00:01:43.926 A:middle
So there are three main
sections in this talk today.

00:01:44.606 --> 00:01:47.126 A:middle
First of all I'll talk about
the new power saving features

00:01:47.126 --> 00:01:47.706 A:middle
in Safari.

00:01:48.886 --> 00:01:51.806 A:middle
Secondly I'll talk about how
you can make power efficient web

00:01:51.806 --> 00:01:55.816 A:middle
pages, some new web API you
can use, the tools you use

00:01:55.816 --> 00:01:57.986 A:middle
to detect whether your page
is using too much power

00:01:57.986 --> 00:02:01.216 A:middle
and also some common mistakes
that we've seen pages make

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:01:57.986 --> 00:02:01.216 A:middle
and also some common mistakes
that we've seen pages make

00:02:01.456 --> 00:02:03.886 A:middle
that cause them to use too much
power than the author intended.

00:02:04.386 --> 00:02:07.576 A:middle
And finally I'll talk
about Safari's new response

00:02:07.576 --> 00:02:10.216 A:middle
to scrolling which will give
your users a buttery smooth

00:02:10.216 --> 00:02:13.186 A:middle
scrolling experience on your web
pages and how you can make sure

00:02:13.186 --> 00:02:14.836 A:middle
that your pages get
that best scrolling.

00:02:15.276 --> 00:02:18.266 A:middle
So let me start by talking

00:02:18.266 --> 00:02:20.906 A:middle
about these new power
saving features in Safari.

00:02:21.016 --> 00:02:24.106 A:middle
And there are two features that
I want to talk about today.

00:02:25.136 --> 00:02:27.386 A:middle
The first one is called
App Nap for Safari tabs

00:02:27.916 --> 00:02:30.286 A:middle
and the second one is
called Power Saver.

00:02:32.796 --> 00:02:34.136 A:middle
So if you were in any

00:02:34.136 --> 00:02:36.766 A:middle
of the energy related
sessions yesterday you'll know

00:02:36.766 --> 00:02:40.136 A:middle
that there's a new feature in
OS X Mavericks called App Nap.

00:02:41.316 --> 00:02:44.066 A:middle
Now the purpose of App Nap
is to focus system recourses

00:02:44.356 --> 00:02:46.346 A:middle
on the task that's most
important to the user.

00:02:46.346 --> 00:02:49.706 A:middle
So what we've done is
we've applied App Nap

00:02:49.706 --> 00:02:50.786 A:middle
to tabs in Safari.

00:02:51.196 --> 00:02:53.576 A:middle
And this means we can
Nap background tabs

00:02:53.606 --> 00:02:57.326 A:middle
and that saves us
a lot of power.

00:02:57.506 --> 00:02:58.306 A:middle
So how does this work?

00:02:58.536 --> 00:03:00.016 A:middle
Well you may already know

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:02:58.536 --> 00:03:00.016 A:middle
Well you may already know

00:03:00.016 --> 00:03:03.056 A:middle
that in Safari we actually use
a separate process for loading

00:03:03.056 --> 00:03:04.166 A:middle
and rendering the web page

00:03:04.166 --> 00:03:06.276 A:middle
and we call this the
Web Content Process.

00:03:07.186 --> 00:03:11.696 A:middle
New in Safari 7 now, each tab
has its own web content process

00:03:12.116 --> 00:03:13.266 A:middle
and that means that the pages

00:03:13.266 --> 00:03:15.896 A:middle
in different tabs are mostly
isolated from each other.

00:03:17.096 --> 00:03:19.616 A:middle
But it also means that
we can now apply App Nap

00:03:20.166 --> 00:03:22.326 A:middle
to the processes for
each tab independently

00:03:22.446 --> 00:03:26.606 A:middle
and of course now we can do
that, we can Nap background tabs

00:03:26.836 --> 00:03:29.526 A:middle
and this allows Safari to
focus all its resources

00:03:29.526 --> 00:03:30.946 A:middle
on the tab you're
working with right there

00:03:30.946 --> 00:03:32.156 A:middle
which makes it really
responsive.

00:03:32.156 --> 00:03:36.236 A:middle
So when can we do
this napping of tabs?

00:03:36.566 --> 00:03:38.216 A:middle
Well in general we'll
Nap any tab

00:03:38.216 --> 00:03:40.116 A:middle
that the user can't
currently see

00:03:40.446 --> 00:03:43.776 A:middle
so that means background tabs,
tabs that minimize windows

00:03:43.776 --> 00:03:46.206 A:middle
on another space or with the
screen servers on covering

00:03:46.206 --> 00:03:48.236 A:middle
up Safari and in
general any window

00:03:48.236 --> 00:03:49.966 A:middle
which is what we call
occluded which just means

00:03:49.966 --> 00:03:51.376 A:middle
that it's covered
up by something else

00:03:51.376 --> 00:03:52.756 A:middle
and the user can't see it.

00:03:53.226 --> 00:03:57.206 A:middle
And there's one other
case where we can Nap tabs

00:03:57.506 --> 00:03:59.576 A:middle
and that's what we
call idle windows.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:04:00.716 --> 00:04:03.976 A:middle
So the system can now tell
us whether a window has been

00:04:03.976 --> 00:04:04.906 A:middle
updated recently.

00:04:05.546 --> 00:04:08.476 A:middle
And if it hasn't then
we can apply App Nap

00:04:08.476 --> 00:04:11.946 A:middle
to that web process which means
that if a web page is loaded,

00:04:11.946 --> 00:04:14.646 A:middle
maybe it's in the background,
and you can kind of see part

00:04:14.646 --> 00:04:16.086 A:middle
of the window but
it's not actually,

00:04:16.086 --> 00:04:17.606 A:middle
the page is not really
doing anything.

00:04:17.805 --> 00:04:20.736 A:middle
That means that page is
also eligible for napping.

00:04:23.776 --> 00:04:27.226 A:middle
So what is the impact on your
web page of being in a tab

00:04:27.226 --> 00:04:29.436 A:middle
that has been App Napped?

00:04:29.886 --> 00:04:31.266 A:middle
Well if you were in any

00:04:31.266 --> 00:04:33.496 A:middle
of the energy related
sessions you'll know that one

00:04:33.496 --> 00:04:36.186 A:middle
of the worst things for power
efficiency is the firing

00:04:36.186 --> 00:04:36.926 A:middle
of timers.

00:04:37.676 --> 00:04:40.086 A:middle
Every time a timer fires
the system has to wake up,

00:04:40.396 --> 00:04:42.236 A:middle
the CPU has to ramp up
from a low power mode

00:04:42.236 --> 00:04:44.516 A:middle
to a how power mode and
all this is very wasteful.

00:04:44.936 --> 00:04:47.766 A:middle
So one of the best ways
that we can save power is

00:04:47.766 --> 00:04:50.276 A:middle
to rate limit the JavaScript
timers and those are setTimeout

00:04:50.276 --> 00:04:51.526 A:middle
and setInterval in JavaScript.

00:04:52.156 --> 00:04:56.526 A:middle
If you're using
requestAnimationFrame,

00:04:56.526 --> 00:04:58.306 A:middle
which I'll talk about a bit
later on in the session,

00:04:58.496 --> 00:04:59.776 A:middle
that will also get rate limited.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:05:00.886 --> 00:05:04.746 A:middle
But when we were working on
this we found a couple cases

00:05:04.746 --> 00:05:08.646 A:middle
where tabs in the background
are actually doing useful work

00:05:08.646 --> 00:05:09.996 A:middle
or things that you
want to continue.

00:05:09.996 --> 00:05:12.116 A:middle
For example there are
some audio players

00:05:12.466 --> 00:05:15.576 A:middle
that you know periodically
load data dynamically

00:05:15.576 --> 00:05:19.436 A:middle
as they're running and that's
something you want to continue

00:05:19.436 --> 00:05:20.756 A:middle
to work because you
want that audio

00:05:20.756 --> 00:05:22.296 A:middle
to keep playing audio
in the background.

00:05:22.296 --> 00:05:24.986 A:middle
So we actually detect that and
we don't Nap tabs in that case.

00:05:25.296 --> 00:05:28.186 A:middle
And if tabs are also dynamically
loaded content we won't

00:05:28.686 --> 00:05:31.286 A:middle
Nap them.

00:05:31.566 --> 00:05:32.836 A:middle
So what should you
do to make sure

00:05:32.836 --> 00:05:36.766 A:middle
that your web pages play nicely
with App Nap for Safari Tabs?

00:05:37.596 --> 00:05:38.506 A:middle
Well in general, nothing.

00:05:38.506 --> 00:05:40.396 A:middle
We hope this will just
work very transparently.

00:05:40.816 --> 00:05:41.756 A:middle
But you should be aware

00:05:42.036 --> 00:05:43.846 A:middle
that your timers
could be rate-limited.

00:05:44.426 --> 00:05:49.576 A:middle
So that's App Nap
for Safari Tabs.

00:05:50.206 --> 00:05:51.246 A:middle
We think this is
going to be great

00:05:51.246 --> 00:05:54.046 A:middle
for people we call tab
holders, the kinds of people

00:05:54.046 --> 00:05:56.136 A:middle
who have lots of tabs
open and lots of windows.

00:05:56.906 --> 00:05:59.116 A:middle
Those kinds of people should
really investigate Safari

00:05:59.116 --> 00:06:00.956 A:middle
Reading Lists because that's a
much better way of keeping track

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:05:59.116 --> 00:06:00.956 A:middle
Reading Lists because that's a
much better way of keeping track

00:06:00.956 --> 00:06:01.846 A:middle
of all of those URL's.

00:06:01.846 --> 00:06:03.646 A:middle
But if you do have lots
of windows and lots

00:06:03.646 --> 00:06:07.546 A:middle
of tabs open now, Safari is able
to Nap all those background tabs

00:06:07.796 --> 00:06:09.796 A:middle
which means that it's
really focusing resources

00:06:09.796 --> 00:06:11.186 A:middle
on the tab you're
currently working with

00:06:11.186 --> 00:06:13.176 A:middle
and that makes you feel
much more responsive.

00:06:13.846 --> 00:06:16.676 A:middle
So the second new
feature I want to talk

00:06:16.676 --> 00:06:19.076 A:middle
about today is called
Safari Power Saver.

00:06:19.076 --> 00:06:21.766 A:middle
One of the things we found

00:06:22.276 --> 00:06:24.556 A:middle
when we were investigating
power usage in Safari,

00:06:24.556 --> 00:06:26.206 A:middle
and this didn't really
surprise us,

00:06:26.556 --> 00:06:28.966 A:middle
is that plugins use an
enormous amount of power.

00:06:29.526 --> 00:06:32.786 A:middle
And this is a problem we
didn't have to solve in iOS.

00:06:33.136 --> 00:06:36.526 A:middle
Now in OS X we could have
simply stopped running plugins

00:06:36.796 --> 00:06:38.006 A:middle
but the problem is
that would result

00:06:38.006 --> 00:06:39.376 A:middle
in a broken user experience.

00:06:39.726 --> 00:06:42.226 A:middle
Many people visit a page and not
really understand why it didn't

00:06:42.226 --> 00:06:44.146 A:middle
work the way it used to
because the plugins not running.

00:06:44.696 --> 00:06:46.606 A:middle
So we had to fix this in a way

00:06:46.606 --> 00:06:48.406 A:middle
that was a bit smarter
than that.

00:06:48.756 --> 00:06:50.986 A:middle
And we came up with something
that we call Power Saver.

00:06:51.896 --> 00:06:55.776 A:middle
This gave us, the impact of
turning on Power Saver we got an

00:06:55.776 --> 00:06:58.426 A:middle
up to 35% reduction in
CPU power consumption

00:06:58.776 --> 00:07:00.296 A:middle
so it's really great
energy saving.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:06:58.776 --> 00:07:00.296 A:middle
so it's really great
energy saving.

00:07:00.836 --> 00:07:05.336 A:middle
So you know why do
we need this thing?

00:07:05.336 --> 00:07:07.586 A:middle
Well this is typical of the
web pages you visit every day,

00:07:07.586 --> 00:07:09.336 A:middle
like a typical news
site or a blog site.

00:07:09.336 --> 00:07:11.916 A:middle
And one of the things you
may not really pay attention

00:07:11.916 --> 00:07:14.376 A:middle
to is all the marginal content,
all the peripheral content

00:07:14.566 --> 00:07:16.676 A:middle
which you don't really care
about, often it's adds.

00:07:16.676 --> 00:07:18.606 A:middle
But what you may not
realize is how much

00:07:18.606 --> 00:07:21.016 A:middle
of this content is actually
running through plugins.

00:07:21.786 --> 00:07:25.286 A:middle
So without Power Saver these
plugins are running all the time

00:07:25.496 --> 00:07:28.996 A:middle
and that is, of course, causing
the CPU to be busy all the time.

00:07:28.996 --> 00:07:30.836 A:middle
The CPU is always active.

00:07:31.216 --> 00:07:32.066 A:middle
It gets warm.

00:07:32.066 --> 00:07:33.036 A:middle
The fans come on.

00:07:33.036 --> 00:07:35.026 A:middle
And of course that's all
really bad for battery life.

00:07:35.566 --> 00:07:39.946 A:middle
Now that we can pause these
plugins the CPU usage is much

00:07:39.946 --> 00:07:45.406 A:middle
lower and it has a really
positive impact on battery life.

00:07:45.996 --> 00:07:47.526 A:middle
So I said before,
we do this in a way

00:07:47.526 --> 00:07:49.026 A:middle
that most users won't notice.

00:07:49.026 --> 00:07:49.786 A:middle
It's unobtrusive.

00:07:49.786 --> 00:07:51.746 A:middle
So we call it Smart
Power Saving.

00:07:52.286 --> 00:07:57.396 A:middle
And generally the way we do this
is through three techniques.

00:07:58.216 --> 00:08:01.086 A:middle
First of all when you visit
a page in order to see

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:07:58.216 --> 00:08:01.086 A:middle
First of all when you visit
a page in order to see

00:08:01.086 --> 00:08:02.596 A:middle
like an internet
video or something,

00:08:02.596 --> 00:08:04.136 A:middle
some plugin is up
front and center.

00:08:04.516 --> 00:08:06.366 A:middle
We'll just continue to run
that because you probably went

00:08:06.366 --> 00:08:07.756 A:middle
to that page to see
that thing anyway.

00:08:08.256 --> 00:08:10.676 A:middle
So that we call a primary
plugin and we'll just run.

00:08:11.956 --> 00:08:15.716 A:middle
Secondly, plugins are often used
for things like playing audio

00:08:15.896 --> 00:08:17.936 A:middle
and those plugins might
be like really small

00:08:17.936 --> 00:08:19.356 A:middle
or positioned somewhere
else on the page

00:08:19.676 --> 00:08:21.286 A:middle
and we'll just let
those continue to run.

00:08:21.996 --> 00:08:26.746 A:middle
And finally if the user
interacts with a plugin

00:08:26.746 --> 00:08:29.306 A:middle
on the page we'll remember
the fact that they clicked

00:08:29.306 --> 00:08:32.696 A:middle
that plugin on the page and next
time they visit we'll just start

00:08:32.696 --> 00:08:33.756 A:middle
that plugin automatically.

00:08:36.046 --> 00:08:38.186 A:middle
So what's Power Saver
doing under the hood?

00:08:38.416 --> 00:08:42.866 A:middle
Well when a page loads we
let the plugins run but just

00:08:42.866 --> 00:08:45.026 A:middle
for a short time
and we let them run

00:08:45.026 --> 00:08:47.476 A:middle
until they've given us a
useful snatch of their contents

00:08:47.616 --> 00:08:49.626 A:middle
and then we actually
replace the plugin

00:08:49.626 --> 00:08:50.906 A:middle
in the page with that snapshot.

00:08:51.416 --> 00:08:56.236 A:middle
And then if the user clicks
the snapshot we'll go ahead

00:08:56.236 --> 00:08:58.796 A:middle
and recreate the plugin, we'll
pass that click event through

00:08:58.796 --> 00:09:00.166 A:middle
and then the plugin
we'll run as normal.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:08:58.796 --> 00:09:00.166 A:middle
and then the plugin
we'll run as normal.

00:09:00.166 --> 00:09:02.346 A:middle
And in many cases the
user won't even notice.

00:09:02.856 --> 00:09:07.556 A:middle
When we do pause plugins, if the
user happens to hover over one

00:09:07.556 --> 00:09:09.916 A:middle
of those plugins, Safari
will put up this banner

00:09:09.916 --> 00:09:12.116 A:middle
that just indicates that it's
done something to that plugin

00:09:12.326 --> 00:09:14.356 A:middle
but the user can just go ahead
and click anywhere on the plugin

00:09:14.446 --> 00:09:15.716 A:middle
and the plugin will
start running.

00:09:18.356 --> 00:09:21.236 A:middle
So what should you do to make
sure that your pages play nicely

00:09:21.236 --> 00:09:22.206 A:middle
with Safari Power Saver?

00:09:22.526 --> 00:09:25.176 A:middle
Well of course the most obvious
thing is to use fewer plugins.

00:09:25.456 --> 00:09:28.346 A:middle
If you can use one of the
great HTML 5 technologies

00:09:28.346 --> 00:09:33.766 A:middle
like the audio and video
elements or Canvas or Web Audio

00:09:33.766 --> 00:09:37.236 A:middle
or SPG or any of those for
rich media presentations,

00:09:37.856 --> 00:09:38.676 A:middle
those are always going

00:09:38.676 --> 00:09:40.346 A:middle
to be more power
efficient then a plugin

00:09:40.416 --> 00:09:41.936 A:middle
because we've optimized
those really heavily.

00:09:42.476 --> 00:09:46.646 A:middle
We have seen a few cases
where pages that communicate

00:09:46.646 --> 00:09:49.216 A:middle
with a plugin through
script have had problems.

00:09:49.586 --> 00:09:53.076 A:middle
And generally in these cases
the page is not prepared

00:09:53.076 --> 00:09:56.436 A:middle
to handle the fact that there
may be more than one instance

00:09:56.436 --> 00:09:58.556 A:middle
of a plugin for a given
object or embed element

00:09:58.556 --> 00:09:59.966 A:middle
over the lifetime of the page.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:10:00.436 --> 00:10:02.296 A:middle
So the page needs to
be prepared for plugins

00:10:02.296 --> 00:10:03.636 A:middle
to be destroyed and recreated.

00:10:04.016 --> 00:10:05.946 A:middle
And generally what this means is

00:10:05.946 --> 00:10:08.966 A:middle
that the plugin should
request state for the page

00:10:08.966 --> 00:10:11.566 A:middle
when it starts up, rather
than the page pushing state

00:10:11.566 --> 00:10:17.296 A:middle
down to the plugin and
expecting that to persist.

00:10:17.296 --> 00:10:18.466 A:middle
So that's Safari Power Saver.

00:10:19.196 --> 00:10:21.966 A:middle
And it gives us a really great
energy saving and we hope

00:10:21.966 --> 00:10:27.276 A:middle
that most of users will not
even notice that it's there.

00:10:27.696 --> 00:10:29.946 A:middle
So I talked about these two
new features in Safari 7

00:10:29.946 --> 00:10:32.056 A:middle
that combined give us
really great power savings.

00:10:32.276 --> 00:10:33.686 A:middle
But we also need your help.

00:10:34.636 --> 00:10:35.946 A:middle
We need you to make sure

00:10:35.946 --> 00:10:40.106 A:middle
that your pages are really power
efficient and we need to do this

00:10:40.106 --> 00:10:43.546 A:middle
because we can't just have
Safari do power saving things

00:10:43.546 --> 00:10:44.866 A:middle
that break the way pages work.

00:10:45.516 --> 00:10:47.776 A:middle
So I'll tell you about how

00:10:47.776 --> 00:10:49.246 A:middle
to make power efficient
web pages now.

00:10:50.046 --> 00:10:52.506 A:middle
Firstly we've got a couple
new pieces of web API

00:10:53.046 --> 00:10:55.116 A:middle
which you can use to make
sure your pages save power.

00:10:56.436 --> 00:10:58.736 A:middle
Secondly I'll talk about
the tools you can use

00:10:58.736 --> 00:11:00.676 A:middle
to detect whether your
pages are using more power

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:10:58.736 --> 00:11:00.676 A:middle
to detect whether your
pages are using more power

00:11:00.676 --> 00:11:01.346 A:middle
than they should.

00:11:01.996 --> 00:11:04.436 A:middle
And finally I'll talk about some
common mistakes we have seen

00:11:04.776 --> 00:11:09.096 A:middle
that really is a pitfall
that some pages fall

00:11:09.096 --> 00:11:12.086 A:middle
into that cause them to
use a lot more power.

00:11:13.076 --> 00:11:18.246 A:middle
So first the new web API, now
there are two of these I'd

00:11:18.246 --> 00:11:20.556 A:middle
like to talk about, the first
is called Page Visibility

00:11:20.556 --> 00:11:23.196 A:middle
and the second is the
requestAnimationFrame API.

00:11:23.196 --> 00:11:26.796 A:middle
So let's talk about
Page Visibility.

00:11:26.796 --> 00:11:33.456 A:middle
This is a W3 specification
that allows a page to detect

00:11:33.906 --> 00:11:35.596 A:middle
when it's hidden
and get notified

00:11:35.596 --> 00:11:36.906 A:middle
when the visibility changes.

00:11:37.726 --> 00:11:40.206 A:middle
Now I've already talked about
hidden pages in the context

00:11:40.206 --> 00:11:41.646 A:middle
of App Nap for Safari Tabs.

00:11:42.586 --> 00:11:46.146 A:middle
The reason we have or the way
you'd use Page Visibility is

00:11:46.146 --> 00:11:48.406 A:middle
to make sure that your
page can take its own steps

00:11:48.406 --> 00:11:50.536 A:middle
to conserve power when
it's in the background.

00:11:51.536 --> 00:11:54.286 A:middle
And by in the background I mean
the same things that I talked

00:11:54.286 --> 00:11:56.366 A:middle
about in the context of
App Nap for Safari Tabs.

00:11:56.746 --> 00:11:59.486 A:middle
Any pages that are minimized
or hidden or occluded.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:12:00.016 --> 00:12:06.156 A:middle
So there are some things that
the browser does to hidden pages

00:12:06.986 --> 00:12:10.296 A:middle
that are kind of like
App Nap for Safari Tabs.

00:12:10.556 --> 00:12:13.686 A:middle
The browser will also
rate-limit JavaScript timers

00:12:13.686 --> 00:12:15.626 A:middle
and we're not the only
browser that does this.

00:12:15.626 --> 00:12:16.796 A:middle
Other browsers do this too.

00:12:17.336 --> 00:12:19.916 A:middle
But there are some things
that we know are related

00:12:19.916 --> 00:12:22.316 A:middle
to visual updates like
requestAnimationFrame

00:12:22.316 --> 00:12:24.016 A:middle
and CSS Transition Animations.

00:12:24.286 --> 00:12:27.076 A:middle
And we know with hidden pages
none of this work has to happen

00:12:27.336 --> 00:12:28.616 A:middle
so we pause both of these.

00:12:29.136 --> 00:12:33.736 A:middle
So how do you use this API?

00:12:34.556 --> 00:12:36.456 A:middle
Well there are two pieces
to it, there's request

00:12:36.456 --> 00:12:38.336 A:middle
in the current state and
there's getting notified

00:12:38.336 --> 00:12:39.346 A:middle
about state changes.

00:12:39.816 --> 00:12:42.576 A:middle
So to query the current
state there are a couple

00:12:42.576 --> 00:12:44.336 A:middle
of new attributes on
the document object.

00:12:44.956 --> 00:12:47.076 A:middle
There's a simple
Boolean hidden property,

00:12:47.796 --> 00:12:49.456 A:middle
which obviously is
just true or false,

00:12:50.036 --> 00:12:52.606 A:middle
and then there's a property
that returns a string

00:12:52.606 --> 00:12:54.206 A:middle
and this property is
called visibility state.

00:12:54.206 --> 00:12:57.436 A:middle
And it returns the strings
hidden, visible or prerender.

00:12:58.776 --> 00:13:00.176 A:middle
Now hidden and visible
are pretty obvious

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:12:58.776 --> 00:13:00.176 A:middle
Now hidden and visible
are pretty obvious

00:13:00.176 --> 00:13:02.066 A:middle
but let me explain
prerender for a second.

00:13:04.036 --> 00:13:06.436 A:middle
Now in Safari when you're
typing the location field,

00:13:06.816 --> 00:13:10.506 A:middle
the browser's actually going
to preload the top head,

00:13:10.506 --> 00:13:13.376 A:middle
the most likely thing that
you're going to load so that

00:13:13.376 --> 00:13:15.926 A:middle
when you actually hit the return
key you've already mostly loaded

00:13:15.926 --> 00:13:17.536 A:middle
that page and we can
show it right away

00:13:17.536 --> 00:13:18.726 A:middle
and this feels really fast.

00:13:19.496 --> 00:13:21.886 A:middle
But this means that the browser
is actually loading a page

00:13:22.186 --> 00:13:24.146 A:middle
in a way that's not
currently visible to the user.

00:13:24.146 --> 00:13:27.656 A:middle
And the way we indicate
this to the content is

00:13:27.656 --> 00:13:30.156 A:middle
to have document.visibilityState
return prerender.

00:13:31.046 --> 00:13:33.736 A:middle
And you might want to make
use of this in your pages

00:13:33.986 --> 00:13:38.796 A:middle
to do things like not counting
add impressions in that case.

00:13:38.896 --> 00:13:40.966 A:middle
So the second piece
of this API is a way

00:13:40.966 --> 00:13:42.176 A:middle
to listen for state changes.

00:13:42.796 --> 00:13:45.506 A:middle
And the way you do that is by
adding an event listener just

00:13:45.506 --> 00:13:46.656 A:middle
as you would for user event.

00:13:46.996 --> 00:13:48.866 A:middle
So you add an event
listener on the document.

00:13:49.446 --> 00:13:51.086 A:middle
The events called the
visibility change.

00:13:51.766 --> 00:13:54.026 A:middle
And then in your event
handler you simply check one

00:13:54.026 --> 00:13:55.626 A:middle
of these properties
like document.hidden

00:13:55.916 --> 00:13:58.166 A:middle
to know whether your
page is hidden or not.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:14:00.396 --> 00:14:08.636 A:middle
So that's page visibility new
in Safari 6.1 and 7 and in iOS7.

00:14:08.846 --> 00:14:11.336 A:middle
So before I talk about
the next new API I want

00:14:11.336 --> 00:14:12.336 A:middle
to give a little
bit of background

00:14:12.336 --> 00:14:15.276 A:middle
on how people do animations
in JavaScript currently.

00:14:15.916 --> 00:14:19.066 A:middle
And pretty much the
only way traditionally

00:14:19.066 --> 00:14:21.136 A:middle
to do this would be to use
one of the timing function,

00:14:21.136 --> 00:14:22.516 A:middle
setTimeout or setInterval.

00:14:22.826 --> 00:14:24.286 A:middle
But let's have a
couple of problems.

00:14:25.696 --> 00:14:28.446 A:middle
The biggest problem is you
really don't know how often

00:14:28.446 --> 00:14:31.246 A:middle
to file those timers in order
to get smooth animation.

00:14:31.496 --> 00:14:33.486 A:middle
You don't really know what
the display frequency is.

00:14:33.626 --> 00:14:35.276 A:middle
You don't know what else
the browser is doing.

00:14:35.776 --> 00:14:39.156 A:middle
And often we see content
that calls set time

00:14:39.156 --> 00:14:40.446 A:middle
out with a 0 time out.

00:14:40.446 --> 00:14:42.196 A:middle
And that's actually really bad.

00:14:42.716 --> 00:14:45.276 A:middle
So under the hood 0 is actually
clamped to 4 milliseconds.

00:14:45.656 --> 00:14:48.686 A:middle
But most of our displays
update at 60 hertz

00:14:48.896 --> 00:14:51.186 A:middle
so that's a 16.7
millisecond interval.

00:14:51.876 --> 00:14:54.246 A:middle
But if you're generating
frames every 4 milliseconds,

00:14:54.436 --> 00:14:57.126 A:middle
it means that 3 out of every
4 frames is just never shown

00:14:57.126 --> 00:14:59.466 A:middle
to the user so that's
a real waste of power.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:15:00.106 --> 00:15:02.696 A:middle
Now the second problem

00:15:03.066 --> 00:15:06.486 A:middle
with using timers is the
browser can't turn them off,

00:15:06.486 --> 00:15:07.466 A:middle
it can't optimize them away

00:15:07.466 --> 00:15:09.306 A:middle
because it really doesn't
know what you're doing inside

00:15:09.306 --> 00:15:10.366 A:middle
that JavaScript callback.

00:15:10.986 --> 00:15:13.496 A:middle
So requestAnimationFrame
is designed

00:15:13.496 --> 00:15:14.776 A:middle
to solve these two problems.

00:15:15.356 --> 00:15:21.006 A:middle
So it's a Web API for animation
and it consists of two methods

00:15:21.006 --> 00:15:23.176 A:middle
on the window object
requestAnimationFrame

00:15:23.466 --> 00:15:26.406 A:middle
and then there's a function
that you can use just

00:15:26.406 --> 00:15:29.976 A:middle
to cancel an early request.

00:15:29.976 --> 00:15:34.376 A:middle
And its advantages though
of using timers are twofold.

00:15:34.376 --> 00:15:38.876 A:middle
First, the browser handles
the display-refresh problem.

00:15:39.016 --> 00:15:41.406 A:middle
It will call your request
for animation during callback

00:15:41.556 --> 00:15:43.926 A:middle
at just the right time so
you can get work done to show

00:15:43.926 --> 00:15:45.206 A:middle
up at the next display cycle.

00:15:45.766 --> 00:15:47.576 A:middle
And secondly because we know

00:15:47.576 --> 00:15:50.896 A:middle
that requestAnimationFrame
is being used

00:15:50.896 --> 00:15:54.556 A:middle
for visual updates we can
pause it in background tabs.

00:15:55.076 --> 00:15:58.666 A:middle
And requestAnimationFrame
is described

00:15:58.666 --> 00:16:04.186 A:middle
in the W3C Animation
Timing Spec.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:15:58.666 --> 00:16:04.186 A:middle
in the W3C Animation
Timing Spec.

00:16:04.476 --> 00:16:07.106 A:middle
So before requestAnimationFrame
you probably had an animation

00:16:07.106 --> 00:16:08.546 A:middle
loop that looked
something like this.

00:16:09.166 --> 00:16:10.646 A:middle
You have a do animation
function.

00:16:10.646 --> 00:16:12.966 A:middle
It probably did some date math
to figure out where it was

00:16:12.966 --> 00:16:16.086 A:middle
in the animation timeline and
then it would update the display

00:16:16.466 --> 00:16:18.586 A:middle
and then call set timeout
to get called again.

00:16:18.586 --> 00:16:20.336 A:middle
And you know the
author here has guessed

00:16:20.336 --> 00:16:21.936 A:middle
that 60 milliseconds
is a good interval.

00:16:22.966 --> 00:16:25.266 A:middle
So requestAnimationFrame
is pretty much a drop

00:16:25.266 --> 00:16:26.236 A:middle
in replacement for that.

00:16:26.386 --> 00:16:27.806 A:middle
But it actually helps
you a bit more.

00:16:28.366 --> 00:16:32.116 A:middle
Your call back gets passed a
time value which is the time

00:16:32.116 --> 00:16:34.666 A:middle
in milliseconds since the page
started to load so instead

00:16:34.666 --> 00:16:36.186 A:middle
of doing date math
you can just use that.

00:16:36.816 --> 00:16:38.916 A:middle
But the other thing to note is

00:16:38.916 --> 00:16:41.516 A:middle
that requestAnimationFrame
is just a one shot call back,

00:16:41.666 --> 00:16:42.616 A:middle
just like setTimeout.

00:16:43.056 --> 00:16:44.466 A:middle
So if you want to get
called for another frame

00:16:44.466 --> 00:16:47.376 A:middle
of animation then you just call
requestAnimationFrame again

00:16:47.376 --> 00:16:48.226 A:middle
inside your callback.

00:16:48.796 --> 00:16:52.216 A:middle
So doing this will enable your
callback called basically just

00:16:52.216 --> 00:16:53.526 A:middle
before every display refreshed

00:16:53.526 --> 00:16:55.576 A:middle
so you can do really smooth
animation in JavaScript.

00:16:56.016 --> 00:17:00.896 A:middle
So requestAnimationFrame
you may be familiar

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:16:56.016 --> 00:17:00.896 A:middle
So requestAnimationFrame
you may be familiar

00:17:00.896 --> 00:17:02.536 A:middle
with as WebKit
requestAnimationFrame

00:17:02.536 --> 00:17:05.256 A:middle
in earlier releases but now
it's just requestAnimationFrame

00:17:05.516 --> 00:17:08.965 A:middle
and it's in Safari
6.1 and 7 and iOS7.

00:17:09.205 --> 00:17:12.306 A:middle
So what should you do with
these new JavaScript API's

00:17:12.306 --> 00:17:14.116 A:middle
to make sure that your
pages use less power?

00:17:15.326 --> 00:17:18.096 A:middle
Well the most important thing is
to use the page visibility API

00:17:18.746 --> 00:17:21.146 A:middle
to stop doing work in pages
that the users can't see.

00:17:21.536 --> 00:17:24.236 A:middle
For example, you
might have a ticker

00:17:24.236 --> 00:17:26.455 A:middle
on the page that's fetching
data from the server

00:17:26.455 --> 00:17:28.656 A:middle
to update stock prices
or something like that

00:17:28.716 --> 00:17:30.756 A:middle
and there's no point in doing
that work in a background tab

00:17:31.096 --> 00:17:33.636 A:middle
so you can just use page
visibility to turn off that.

00:17:33.636 --> 00:17:36.036 A:middle
And that also means that
your server load is reduced

00:17:36.036 --> 00:17:37.596 A:middle
so that's great on both sides.

00:17:38.146 --> 00:17:41.166 A:middle
If you do need to use JavaScript

00:17:41.166 --> 00:17:43.366 A:middle
for animation then you should
use requestAnimationFrame

00:17:43.596 --> 00:17:46.016 A:middle
instead of just doing
setTimeout or setInterval.

00:17:48.366 --> 00:17:51.826 A:middle
One slight wrinkle we've
seen here is you may remember

00:17:51.826 --> 00:17:55.046 A:middle
that I said that CSS Transitions
and Animations are paused

00:17:55.426 --> 00:17:58.856 A:middle
when a tab is either in the
background or for example

00:17:58.856 --> 00:18:00.196 A:middle
when the user switches bases

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:17:58.856 --> 00:18:00.196 A:middle
when the user switches bases

00:18:00.196 --> 00:18:02.536 A:middle
and the Safari window
ends up being now visible.

00:18:03.816 --> 00:18:05.676 A:middle
And we've seen this trip
up a couple of pages

00:18:06.216 --> 00:18:07.966 A:middle
where the page was
relying on the fact

00:18:07.966 --> 00:18:09.646 A:middle
that it would receive
transition end events

00:18:09.646 --> 00:18:13.386 A:middle
or animation end events in order
to progress its business logic.

00:18:14.266 --> 00:18:18.166 A:middle
So there's a general rule here
for well behaving pages which is

00:18:18.166 --> 00:18:21.166 A:middle
to separate out the business
logic from the visual updates.

00:18:21.826 --> 00:18:25.546 A:middle
So in hidden pages you can let
the business logic continue

00:18:25.976 --> 00:18:27.486 A:middle
but will be able to save power

00:18:27.486 --> 00:18:28.846 A:middle
by not running those
visual updates.

00:18:28.846 --> 00:18:34.196 A:middle
So at this point I'd like to
invite my colleague Tim Horton

00:18:34.196 --> 00:18:38.696 A:middle
onto the stage to show we can
take a power inefficient page

00:18:38.986 --> 00:18:40.456 A:middle
and fix it using
page visibility.

00:18:40.456 --> 00:18:41.036 A:middle
[Applause]

00:18:41.036 --> 00:18:44.776 A:middle
>> Tim Horton: So
I'm Tim Horton.

00:18:44.906 --> 00:18:47.626 A:middle
I also work on Safari
WebKit with Simon.

00:18:47.716 --> 00:18:51.236 A:middle
And so if any of you
guys were in What's New

00:18:51.236 --> 00:18:53.986 A:middle
in WebKit yesterday you met
Enrika [phonetic] and you know

00:18:53.986 --> 00:18:58.176 A:middle
that she really likes to cook.

00:18:58.376 --> 00:19:03.336 A:middle
[laughter] So what you
don't know, or may not know,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:18:58.376 --> 00:19:03.336 A:middle
[laughter] So what you
don't know, or may not know,

00:19:03.336 --> 00:19:06.336 A:middle
is that she also has a giant
pizza oven in her backyard

00:19:06.666 --> 00:19:09.896 A:middle
and it takes a while for
this oven to heat up.

00:19:10.376 --> 00:19:12.316 A:middle
So she's installed a
thermometer into it,

00:19:13.696 --> 00:19:15.736 A:middle
an internet connected
thermometer into it,

00:19:15.976 --> 00:19:21.656 A:middle
and we've written a web app so
she can, from inside her house,

00:19:21.656 --> 00:19:23.236 A:middle
monitor the temperature.

00:19:23.476 --> 00:19:25.486 A:middle
So I'm going to show
that to you now.

00:19:25.716 --> 00:19:26.416 A:middle
So here it is.

00:19:26.416 --> 00:19:28.216 A:middle
You can see the pizza
oven is heating up.

00:19:29.376 --> 00:19:31.326 A:middle
This is a graph of
temperature over time.

00:19:31.376 --> 00:19:34.316 A:middle
This is temperature on a 500
millisecond JavaScript timer.

00:19:35.116 --> 00:19:38.056 A:middle
The green ticks at the top
display every time we fetch the

00:19:38.056 --> 00:19:39.336 A:middle
temperature from
the thermometer.

00:19:40.066 --> 00:19:41.966 A:middle
So let's look at the
source code for a second.

00:19:42.876 --> 00:19:45.606 A:middle
It's just using setInterval,
very basic.

00:19:45.606 --> 00:19:47.516 A:middle
Just straight forward JavaScript
timing, nothing fancy.

00:19:48.816 --> 00:19:54.806 A:middle
So let's see what happens
right now when we switch tabs.

00:19:54.936 --> 00:19:57.626 A:middle
So right now in the
background the other tab,

00:19:57.706 --> 00:19:59.866 A:middle
the timers are rate
limited, as Simon mentioned,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:20:00.496 --> 00:20:03.286 A:middle
but we're still doing
updates occasionally

00:20:03.286 --> 00:20:06.236 A:middle
and you can see the green
ticks coming at a lower rate

00:20:06.956 --> 00:20:09.876 A:middle
but we're still getting data.

00:20:10.056 --> 00:20:13.286 A:middle
So we're still not being a
great power citizen here, right,

00:20:13.286 --> 00:20:15.036 A:middle
we're still doing
updates in the background.

00:20:15.596 --> 00:20:17.196 A:middle
And we can do better.

00:20:17.196 --> 00:20:19.466 A:middle
We can use 0 power
in the background

00:20:19.936 --> 00:20:22.856 A:middle
by adopting the page visibility
guide that was just mentioned.

00:20:24.266 --> 00:20:27.976 A:middle
So let's replace this
function, this setup function

00:20:27.976 --> 00:20:31.976 A:middle
that just starts the
timer explicitly with one

00:20:32.016 --> 00:20:36.096 A:middle
that instead respects
page visibility.

00:20:36.286 --> 00:20:37.826 A:middle
We listen to the page
visibility page event

00:20:37.826 --> 00:20:39.796 A:middle
and when it changes we
start and stop our timer,

00:20:40.156 --> 00:20:41.426 A:middle
very simple, not much code.

00:20:42.406 --> 00:20:45.326 A:middle
Let's refresh and now
let's do a spaces swipe.

00:20:45.996 --> 00:20:48.256 A:middle
My friends just got back
from Bali so I was checking

00:20:48.256 --> 00:20:49.986 A:middle
out the Island to see
where they had been.

00:20:50.746 --> 00:20:52.846 A:middle
Now let's swipe back.

00:20:52.896 --> 00:20:56.026 A:middle
And you can see here while
the page was hidden we did no

00:20:56.026 --> 00:20:58.636 A:middle
updates at all, no green ticks.

00:20:59.056 --> 00:21:02.136 A:middle
You'll also notice while it
was hidden the graph kind

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:20:59.056 --> 00:21:02.136 A:middle
You'll also notice while it
was hidden the graph kind

00:21:02.136 --> 00:21:03.016 A:middle
of looks broken.

00:21:03.186 --> 00:21:05.716 A:middle
That's a big oopsy on our part.

00:21:05.766 --> 00:21:09.016 A:middle
So maybe we should fix this.

00:21:09.566 --> 00:21:12.866 A:middle
So luckily the thermometer that
Enrika chose stores five minutes

00:21:12.866 --> 00:21:16.556 A:middle
of data back in time so we can
ask for all of the temperatures

00:21:16.556 --> 00:21:20.526 A:middle
since the last time we updated,
when we come back from hiddency.

00:21:21.486 --> 00:21:23.096 A:middle
So let's just make
that simple change just

00:21:23.096 --> 00:21:28.836 A:middle
to make our graph look more
correct, and this is just, yeah.

00:21:30.586 --> 00:21:33.556 A:middle
And now let's see
what it looks like.

00:21:33.556 --> 00:21:36.566 A:middle
So now in the background
we're doing no work at all

00:21:37.866 --> 00:21:40.706 A:middle
but when we come
back we've filled

00:21:40.706 --> 00:21:41.886 A:middle
in the graph and
it looks perfect.

00:21:42.156 --> 00:21:44.666 A:middle
Now just pretend you remove
the grey and the green

00:21:44.666 --> 00:21:45.796 A:middle
and you just got the graph.

00:21:45.796 --> 00:21:46.596 A:middle
It looks perfect.

00:21:47.286 --> 00:21:49.976 A:middle
And the background
uses no power.

00:21:49.976 --> 00:21:51.866 A:middle
So now you've seen a
simple example of how

00:21:51.866 --> 00:21:55.466 A:middle
to use the page API to
make a very effective power

00:21:55.466 --> 00:21:56.666 A:middle
and bandwidth efficient website.

00:21:57.856 --> 00:21:58.606 A:middle
Back to you, Simon.

00:21:59.061 --> 00:22:01.061 A:middle
[Applause]

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:21:59.061 --> 00:22:01.061 A:middle
[Applause]

00:22:01.106 --> 00:22:01.546 A:middle
>> Simon Fraser: Thank you, Tim.

00:22:02.066 --> 00:22:06.626 A:middle
So I talked about the new
web API available to you

00:22:06.726 --> 00:22:09.596 A:middle
so that your pages can use
less power in the background.

00:22:10.386 --> 00:22:12.286 A:middle
Now let me talk about
how to figure

00:22:12.286 --> 00:22:14.276 A:middle
out if your pages are
using too much power.

00:22:14.846 --> 00:22:18.876 A:middle
And there are two
levels of tools here

00:22:18.876 --> 00:22:20.576 A:middle
that I want to talk about.

00:22:20.576 --> 00:22:21.986 A:middle
There are tools provided
by the system

00:22:22.486 --> 00:22:23.896 A:middle
and then there's
some tools in Safari.

00:22:24.436 --> 00:22:27.426 A:middle
So first briefly I'll talk
about the system tools.

00:22:28.366 --> 00:22:31.776 A:middle
OS X Mavericks now has an
energy tab and activity monitor.

00:22:32.416 --> 00:22:34.626 A:middle
And so this is the kind of thing
that users would go to to find

00:22:34.626 --> 00:22:37.886 A:middle
out which applications have
recently been using a lot

00:22:37.886 --> 00:22:38.416 A:middle
of energy.

00:22:39.366 --> 00:22:42.796 A:middle
So it's actually really bad for
Safari to shop in this list.

00:22:43.516 --> 00:22:46.076 A:middle
You don't want your site to
be the site that causes Safari

00:22:46.076 --> 00:22:48.976 A:middle
to be using all the power here.

00:22:49.006 --> 00:22:52.016 A:middle
Similarly in the battery menu we
have a listing of applications

00:22:52.016 --> 00:22:53.916 A:middle
that have been using power
and again it's really bad

00:22:53.916 --> 00:22:56.366 A:middle
if Safari is here so make sure
your pages don't cause that.

00:22:56.876 --> 00:22:59.976 A:middle
Of course as web developers
you're probably more interested

00:22:59.976 --> 00:23:02.256 A:middle
in the tools that are
closer to your web content.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:22:59.976 --> 00:23:02.256 A:middle
in the tools that are
closer to your web content.

00:23:02.906 --> 00:23:04.896 A:middle
There were a couple of
great sessions yesterday

00:23:05.196 --> 00:23:07.726 A:middle
on Safari Web Inspector and I
encourage you if you didn't go

00:23:07.726 --> 00:23:09.636 A:middle
to those to go back
and watch the videos.

00:23:10.726 --> 00:23:12.486 A:middle
So briefly, to use
the web inspector

00:23:12.486 --> 00:23:16.686 A:middle
for investigating power issues
you would enable the develop

00:23:16.686 --> 00:23:18.176 A:middle
menu and then access
the web inspector

00:23:18.176 --> 00:23:19.426 A:middle
through Safari's develop menu.

00:23:19.736 --> 00:23:22.506 A:middle
And then the tab that's
most interesting in terms

00:23:22.506 --> 00:23:24.666 A:middle
of power usage is
the timelines tab.

00:23:25.386 --> 00:23:26.706 A:middle
So you can switch to that tab

00:23:27.266 --> 00:23:30.466 A:middle
and then you would start
recording a timeline

00:23:30.466 --> 00:23:31.326 A:middle
by pressing the button.

00:23:31.816 --> 00:23:33.676 A:middle
And then interact with
your page in a way

00:23:33.676 --> 00:23:35.646 A:middle
that you think is interesting,
maybe you can scroll the page

00:23:35.646 --> 00:23:37.576 A:middle
or reload it and see what
happens at loading time

00:23:37.956 --> 00:23:39.526 A:middle
or interact within other ways.

00:23:40.066 --> 00:23:43.106 A:middle
So what this timeline panel
shows you is all the activity

00:23:43.106 --> 00:23:45.766 A:middle
that the page has been doing,
loading resources, the layout

00:23:45.766 --> 00:23:47.756 A:middle
and rendering work that
the engine is doing,

00:23:47.906 --> 00:23:51.976 A:middle
all the JavaScript is running,
the events that are firing.

00:23:52.136 --> 00:23:54.066 A:middle
Now you may think that
the amount of power used

00:23:54.066 --> 00:23:56.386 A:middle
by the page is going to
be roughly proportional

00:23:56.386 --> 00:23:57.816 A:middle
to the amount of
JavaScript that's running

00:23:58.436 --> 00:24:00.976 A:middle
but that's actually
not usually the case.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:23:58.436 --> 00:24:00.976 A:middle
but that's actually
not usually the case.

00:24:01.696 --> 00:24:05.206 A:middle
Usually the most common
cause of badly behaving pages

00:24:05.206 --> 00:24:08.046 A:middle
that we see are interactions
between the JavaScript

00:24:08.046 --> 00:24:11.236 A:middle
and layout and rendering so
I'll talk about some of those

00:24:11.526 --> 00:24:13.396 A:middle
in the context of common
mistakes we've seen

00:24:13.396 --> 00:24:14.326 A:middle
that web pages make.

00:24:14.756 --> 00:24:19.026 A:middle
And there are two basic areas
here I'd like to talk about.

00:24:19.476 --> 00:24:22.156 A:middle
First of all pages that cause
too much layout to happen

00:24:22.556 --> 00:24:24.856 A:middle
and secondly pages that
just paint too much.

00:24:26.856 --> 00:24:28.016 A:middle
So what is layout?

00:24:28.016 --> 00:24:29.086 A:middle
Well layout is the process

00:24:29.086 --> 00:24:31.956 A:middle
by which the browser takes
the [inaudible], applies style

00:24:31.956 --> 00:24:35.246 A:middle
from the CSS and then computes
the positions and the sizes

00:24:35.506 --> 00:24:37.556 A:middle
of all the boxes and lays
them out on the page.

00:24:37.556 --> 00:24:39.516 A:middle
And that's quite an
expensive process.

00:24:39.996 --> 00:24:41.306 A:middle
And we've optimized this a lot.

00:24:41.306 --> 00:24:44.526 A:middle
And we've also optimized
when the browser does layout.

00:24:45.076 --> 00:24:47.116 A:middle
We want to layout as
infrequently as possible

00:24:47.526 --> 00:24:49.496 A:middle
so that you know we're
not doing excess work

00:24:49.846 --> 00:24:51.936 A:middle
and generally we can layout
just before we paint stuff

00:24:51.936 --> 00:24:52.676 A:middle
on the page.

00:24:53.406 --> 00:24:55.706 A:middle
But there is a problem
here and that's

00:24:55.886 --> 00:24:57.856 A:middle
that there are various
properties and functions exposed

00:24:57.856 --> 00:25:00.476 A:middle
to JavaScript that force
us to eagerly do layout.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:24:57.856 --> 00:25:00.476 A:middle
to JavaScript that force
us to eagerly do layout.

00:25:01.156 --> 00:25:02.676 A:middle
And there's quite
a few of these.

00:25:02.946 --> 00:25:03.806 A:middle
But there's a general theme

00:25:03.806 --> 00:25:05.566 A:middle
which is they're all
geometry related.

00:25:05.976 --> 00:25:08.906 A:middle
They're all properties that
are getting things like sizes,

00:25:09.446 --> 00:25:11.716 A:middle
widths and heights and positions

00:25:11.716 --> 00:25:14.836 A:middle
and scroll information
and stuff like that.

00:25:15.656 --> 00:25:18.246 A:middle
But when JavaScript accesses
any of these properties

00:25:18.246 --> 00:25:20.966 A:middle
or calls these functions,
the browser has to,

00:25:21.316 --> 00:25:24.386 A:middle
if layout is currently what
we call stale, the browser has

00:25:24.386 --> 00:25:25.416 A:middle
to go ahead and do a layout

00:25:25.416 --> 00:25:27.326 A:middle
so it can give you the
correct answer to the question

00:25:27.326 --> 00:25:29.676 A:middle
that you're asking and
that can be expensive.

00:25:29.746 --> 00:25:34.486 A:middle
Now when pages do this
we tend to see a patent

00:25:34.486 --> 00:25:35.736 A:middle
like this in the inspector.

00:25:36.316 --> 00:25:40.546 A:middle
There'll be a repeated cycle of
invalidate styles, recalc style,

00:25:40.546 --> 00:25:41.986 A:middle
invalidate layout and layout.

00:25:43.116 --> 00:25:44.596 A:middle
And generally the
kind of JavaScript

00:25:44.596 --> 00:25:48.186 A:middle
that causes this problem is
some JavaScript that has a loop

00:25:48.186 --> 00:25:49.266 A:middle
and this is very common.

00:25:49.556 --> 00:25:51.586 A:middle
And the loop does
two things generally.

00:25:52.096 --> 00:25:54.666 A:middle
There'll be a call to one of
these geometry related functions

00:25:54.666 --> 00:25:57.566 A:middle
like offsetHeight and that's the
point at which the browser has

00:25:57.566 --> 00:25:58.866 A:middle
to make sure the
layouts up to date.

00:25:59.326 --> 00:26:01.456 A:middle
Now the first line through
the loop you're probably fine.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:25:59.326 --> 00:26:01.456 A:middle
Now the first line through
the loop you're probably fine.

00:26:02.166 --> 00:26:05.356 A:middle
But then later on in the loop
it's common for the JavaScript

00:26:05.356 --> 00:26:07.776 A:middle
to invalidate style
by changing something

00:26:07.776 --> 00:26:11.246 A:middle
like you know
food.style.something=whatever.

00:26:11.576 --> 00:26:13.586 A:middle
So that invalidation
means that next time

00:26:13.586 --> 00:26:17.026 A:middle
through the loop the
offsetHeight is going to have

00:26:17.066 --> 00:26:19.176 A:middle
to recompute all the
layout information

00:26:19.356 --> 00:26:20.586 A:middle
and that's what gets expensive.

00:26:21.676 --> 00:26:22.606 A:middle
So this is not good.

00:26:23.176 --> 00:26:26.516 A:middle
Now generally the way you fix
this is to break this work

00:26:26.696 --> 00:26:27.826 A:middle
into two separate loops.

00:26:28.046 --> 00:26:30.176 A:middle
First you should fetch all
the geometry information

00:26:30.466 --> 00:26:33.306 A:middle
and then you can batch all of
the style changing later on

00:26:33.576 --> 00:26:36.266 A:middle
and that setup should
just result in one layout,

00:26:36.266 --> 00:26:37.516 A:middle
which will be much
more efficient.

00:26:38.086 --> 00:26:43.296 A:middle
Now the second issue we
see fairly often is pages

00:26:43.296 --> 00:26:46.986 A:middle
that paint too much and there's
one very common cause of this

00:26:47.316 --> 00:26:49.526 A:middle
which is people leaving
animated images

00:26:49.526 --> 00:26:50.536 A:middle
in their background style.

00:26:51.536 --> 00:26:53.456 A:middle
It's quite common for pages
to have an animated image

00:26:53.456 --> 00:26:56.066 A:middle
in the background style and
then load stuff on top of it

00:26:56.326 --> 00:26:58.676 A:middle
and they assume because the
animated image is covered

00:26:58.676 --> 00:27:00.856 A:middle
up the browser is going to
be able to stop painting it.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:26:58.676 --> 00:27:00.856 A:middle
up the browser is going to
be able to stop painting it.

00:27:01.456 --> 00:27:02.866 A:middle
Well in many cases we can.

00:27:02.866 --> 00:27:05.106 A:middle
We've done a lot of
ultimizations to detect

00:27:05.406 --> 00:27:06.996 A:middle
when animated images are covered

00:27:06.996 --> 00:27:08.166 A:middle
up so we don't have
to animate them.

00:27:08.166 --> 00:27:10.176 A:middle
But we can't detect
all the cases.

00:27:10.636 --> 00:27:13.926 A:middle
So the best advice I have
for you is to make sure

00:27:13.926 --> 00:27:15.576 A:middle
that you don't leave
these animating images

00:27:15.576 --> 00:27:18.316 A:middle
in your style once you
finish loading a content.

00:27:18.606 --> 00:27:20.316 A:middle
This is especially true on pages

00:27:20.316 --> 00:27:21.826 A:middle
that have the infinite
scrolling model.

00:27:22.176 --> 00:27:24.096 A:middle
We see pages where there's
an animated spin and right

00:27:24.096 --> 00:27:25.786 A:middle
at the bottom it's
normally off the screen

00:27:26.346 --> 00:27:29.686 A:middle
and even this can cause
painting to happen for reasons

00:27:29.686 --> 00:27:30.956 A:middle
that I'll mention later on.

00:27:31.986 --> 00:27:34.266 A:middle
But of course the
real way to tell

00:27:34.266 --> 00:27:36.636 A:middle
if you're painting too much is
to look in the web inspector.

00:27:37.216 --> 00:27:40.696 A:middle
And if you see in the layout
and rendering timeline a lot

00:27:40.696 --> 00:27:43.566 A:middle
of painting like this, it
means you've probably got one

00:27:43.566 --> 00:27:45.706 A:middle
of those animated images sitting
on your page so you need to go

00:27:45.706 --> 00:27:47.306 A:middle
and find it and remove it.

00:27:47.966 --> 00:27:52.726 A:middle
So I've talked about a
couple of common mistakes

00:27:53.096 --> 00:27:55.396 A:middle
but there's a more
general theme here which is

00:27:55.566 --> 00:27:56.986 A:middle
to use the right
tool for the job.

00:27:58.286 --> 00:28:01.126 A:middle
If you're doing animation,
CSS transitions

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:27:58.286 --> 00:28:01.126 A:middle
If you're doing animation,
CSS transitions

00:28:01.126 --> 00:28:02.196 A:middle
and animations are always going

00:28:02.196 --> 00:28:03.766 A:middle
to be more efficient
then running animations

00:28:03.766 --> 00:28:04.496 A:middle
in JavaScript.

00:28:05.116 --> 00:28:09.176 A:middle
And if you need to do
animations in JavaScript,

00:28:09.176 --> 00:28:11.386 A:middle
requestAnimationFrame is
much better than using timers

00:28:11.606 --> 00:28:12.566 A:middle
because we can pause it

00:28:12.566 --> 00:28:14.846 A:middle
and it gets the right
display update frequency.

00:28:15.306 --> 00:28:16.696 A:middle
There are many other cases

00:28:16.696 --> 00:28:18.486 A:middle
where you might be running
JavaScript right now

00:28:18.896 --> 00:28:21.036 A:middle
but you could be using something
that's built into the browser.

00:28:21.796 --> 00:28:24.276 A:middle
If you're doing responsive
layouts that change depending

00:28:24.276 --> 00:28:25.636 A:middle
on window size, for example,

00:28:26.116 --> 00:28:29.136 A:middle
you should be using CSS
Media Queries instead

00:28:29.136 --> 00:28:30.066 A:middle
of running JavaScript.

00:28:30.536 --> 00:28:33.246 A:middle
And there are a number of new
layout models in WebKit now

00:28:33.956 --> 00:28:35.836 A:middle
which Beth talked about
yesterday in the session

00:28:35.836 --> 00:28:37.116 A:middle
on What's New in
Safari and WebKit.

00:28:37.116 --> 00:28:39.106 A:middle
For example, CSS Flexible Boxes.

00:28:39.106 --> 00:28:43.156 A:middle
So you can use these to get
interesting layouts that change

00:28:43.156 --> 00:28:45.576 A:middle
as the page changes size
rather than running JavaScript.

00:28:45.996 --> 00:28:48.826 A:middle
And there's a bunch of other
features like this too.

00:28:48.976 --> 00:28:51.156 A:middle
Beth yesterday also
talked about CSS calc.

00:28:51.416 --> 00:28:53.466 A:middle
So this is another great
way where you can ditch

00:28:53.466 --> 00:28:56.066 A:middle
in JavaScript, use a feature
that's built into the browser

00:28:56.396 --> 00:28:59.326 A:middle
and automatically get better
power efficiency that way.

00:28:59.886 --> 00:29:08.076 A:middle
So I would like to take a moment
to talk about Safari Extensions.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:28:59.886 --> 00:29:08.076 A:middle
So I would like to take a moment
to talk about Safari Extensions.

00:29:08.856 --> 00:29:12.086 A:middle
If you are a Safari Extension
Developer it's extremely

00:29:12.086 --> 00:29:15.596 A:middle
important that your
scripts don't fall into any

00:29:15.596 --> 00:29:18.106 A:middle
of these common pitfalls and
you make sure your scripts

00:29:18.106 --> 00:29:19.016 A:middle
are super-efficient.

00:29:19.486 --> 00:29:22.326 A:middle
And this is because your
extension can inject scripts

00:29:22.326 --> 00:29:24.016 A:middle
into every page the user visits.

00:29:24.516 --> 00:29:28.386 A:middle
There's something else that's
important for extensions

00:29:28.866 --> 00:29:32.336 A:middle
which is that extensions use the
page visibility API to make sure

00:29:32.336 --> 00:29:35.146 A:middle
that they're only doing work in
pages that the users can see.

00:29:36.616 --> 00:29:38.136 A:middle
There's also another reason

00:29:38.136 --> 00:29:40.346 A:middle
that extensions should
use page visibility.

00:29:40.976 --> 00:29:43.246 A:middle
You remember I talked about
the prerender state earlier

00:29:43.566 --> 00:29:46.716 A:middle
and how that's involved in the
browser preloading the top head?

00:29:47.236 --> 00:29:49.926 A:middle
Extensions need to be very
careful to not show UI

00:29:50.166 --> 00:29:52.916 A:middle
to the user for pages
that the user can't see.

00:29:53.246 --> 00:29:56.736 A:middle
So extensions need to check
document.hidden and only show UI

00:29:57.306 --> 00:30:03.896 A:middle
if the page is actually visible.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:29:57.306 --> 00:30:03.896 A:middle
if the page is actually visible.

00:30:03.896 --> 00:30:08.806 A:middle
So I talked about two new
power saving features in Safari

00:30:08.806 --> 00:30:11.076 A:middle
and I've talked about how you
can make power efficient web

00:30:11.076 --> 00:30:12.256 A:middle
content and how to detect

00:30:12.256 --> 00:30:16.606 A:middle
where your content is less power
efficient then it should be.

00:30:17.546 --> 00:30:19.096 A:middle
But you might think
with all this talk

00:30:19.096 --> 00:30:20.766 A:middle
about saving power
they're actually going

00:30:20.766 --> 00:30:22.356 A:middle
to have worse performance,
maybe we need

00:30:22.356 --> 00:30:24.896 A:middle
to you know sit power
more carefully

00:30:24.896 --> 00:30:26.006 A:middle
and we won't be as good.

00:30:26.006 --> 00:30:29.256 A:middle
But in many ways,
or in some cases,

00:30:29.426 --> 00:30:31.106 A:middle
you can actually get
better performance

00:30:31.796 --> 00:30:33.406 A:middle
by using a different algorithm

00:30:33.406 --> 00:30:35.086 A:middle
or actually using
a new architecture

00:30:35.086 --> 00:30:38.346 A:middle
that makes better use of the
hardware and we've done this

00:30:38.346 --> 00:30:41.366 A:middle
with responsive scrolling
in Safari so I'd

00:30:41.366 --> 00:30:42.466 A:middle
like to talk about that now.

00:30:43.636 --> 00:30:44.716 A:middle
Now people love to scroll.

00:30:44.716 --> 00:30:46.026 A:middle
Now we all have iOS devices

00:30:46.026 --> 00:30:47.376 A:middle
where the scrolling
is buttery smooth

00:30:47.876 --> 00:30:50.926 A:middle
and now we have track pads on
our desks and on our notebooks.

00:30:52.176 --> 00:30:54.366 A:middle
You feel that really direct
connection with the web content

00:30:54.366 --> 00:30:56.486 A:middle
and you want the web content
to be really responsive

00:30:56.486 --> 00:30:57.516 A:middle
and scroll right away.

00:30:57.646 --> 00:31:00.226 A:middle
So it was very important for us

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:30:57.646 --> 00:31:00.226 A:middle
So it was very important for us

00:31:00.496 --> 00:31:02.766 A:middle
that Safari had extremely
responsive scrolling.

00:31:03.376 --> 00:31:06.336 A:middle
But to explain how this works
I need to step back a moment

00:31:06.496 --> 00:31:08.566 A:middle
and explain how scrolling
worked in the old days.

00:31:09.066 --> 00:31:13.586 A:middle
So it used to be that when
you scrolled the browser would

00:31:13.586 --> 00:31:15.496 A:middle
simply copy a chunk of
bits up in the window

00:31:15.716 --> 00:31:18.336 A:middle
and then it would paint the
exposed strip at the bottom.

00:31:18.876 --> 00:31:21.706 A:middle
So every scroll would be
copy paint, copy paint

00:31:21.706 --> 00:31:23.506 A:middle
and that all happened
synchronously

00:31:23.506 --> 00:31:24.316 A:middle
on the main thread.

00:31:24.846 --> 00:31:27.826 A:middle
But that also meant that if
the web page was busy doing

00:31:27.826 --> 00:31:29.716 A:middle
something like loading
or running JavaScript,

00:31:30.026 --> 00:31:32.416 A:middle
it means the web page
could block scrolling

00:31:32.416 --> 00:31:35.446 A:middle
and that would give a less
than great user experience.

00:31:36.696 --> 00:31:38.996 A:middle
So we knew we had to
get to a model in Safari

00:31:39.276 --> 00:31:41.166 A:middle
where we could scroll
without doing painting.

00:31:42.356 --> 00:31:44.496 A:middle
So I'll explain how
that works now.

00:31:45.276 --> 00:31:46.726 A:middle
Instead of painting the page

00:31:46.726 --> 00:31:48.936 A:middle
into the window we
actually paint the page

00:31:48.936 --> 00:31:50.306 A:middle
into a series of tiles.

00:31:50.656 --> 00:31:53.166 A:middle
And these tiles are actually
core animation layers

00:31:53.166 --> 00:31:53.776 A:middle
under the hood.

00:31:55.136 --> 00:31:58.246 A:middle
But it now means that we can
do scrolling not by painting

00:31:58.496 --> 00:32:00.696 A:middle
but simply by moving
those tiles around.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:31:58.496 --> 00:32:00.696 A:middle
but simply by moving
those tiles around.

00:32:00.696 --> 00:32:03.276 A:middle
So the implementation is
actually just setting the

00:32:03.276 --> 00:32:05.266 A:middle
position of the layer
that contains the tiles

00:32:05.486 --> 00:32:09.076 A:middle
and that means scrolling is
just changing a layer position.

00:32:10.096 --> 00:32:13.366 A:middle
And that also means that
we're leveraging the GPU

00:32:13.366 --> 00:32:15.596 A:middle
because the window server is
compositing this layer tree

00:32:15.596 --> 00:32:16.936 A:middle
and that makes great
use of the hardware

00:32:16.936 --> 00:32:17.986 A:middle
so this is really efficient.

00:32:18.516 --> 00:32:23.896 A:middle
It does mean that we have to
keep some extra tiles around so

00:32:23.896 --> 00:32:25.636 A:middle
that we always have content
that is ready to scroll

00:32:25.636 --> 00:32:28.316 A:middle
into the window and that
ties back to that problem

00:32:28.316 --> 00:32:29.986 A:middle
with animated images
I talked about before

00:32:29.986 --> 00:32:32.876 A:middle
where an image might be off the
page but still causing painting

00:32:32.876 --> 00:32:34.546 A:middle
and that's because it might
be on one of these tiles

00:32:34.836 --> 00:32:37.376 A:middle
that we're keeping up to date
so we can scroll within anytime.

00:32:37.656 --> 00:32:41.356 A:middle
So that explains how we
can scroll without painting

00:32:42.066 --> 00:32:43.376 A:middle
but how do we scroll
in such a way

00:32:43.376 --> 00:32:45.126 A:middle
that the web page
can't interfere,

00:32:45.126 --> 00:32:46.356 A:middle
that can't block the scrolling?

00:32:47.186 --> 00:32:50.206 A:middle
And to explain that, let me
get a bit nerdy for a minute

00:32:50.676 --> 00:32:53.376 A:middle
and explain our Threading
model in Safari.

00:32:53.836 --> 00:32:56.536 A:middle
So of course there are two
processes involved that I talked

00:32:56.536 --> 00:32:57.986 A:middle
about the web content
process earlier.

00:32:58.576 --> 00:33:01.626 A:middle
But the user events initially
go to this Safari application.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:32:58.576 --> 00:33:01.626 A:middle
But the user events initially
go to this Safari application.

00:33:01.976 --> 00:33:03.786 A:middle
But Safari then sends
those events directly

00:33:03.786 --> 00:33:06.636 A:middle
to the web content process
and they're received

00:33:06.636 --> 00:33:08.066 A:middle
in the web content
process by a thread

00:33:08.066 --> 00:33:10.706 A:middle
that we call the event
thread that is always ready

00:33:10.706 --> 00:33:11.736 A:middle
to receive those events.

00:33:11.736 --> 00:33:13.156 A:middle
It's never blocked
by anything else.

00:33:13.686 --> 00:33:16.776 A:middle
And then the event thread
simply bounces those events

00:33:16.776 --> 00:33:18.066 A:middle
to what we call the
scrolling thread

00:33:18.066 --> 00:33:20.416 A:middle
and the scrolling thread is the
one that's changing the layer

00:33:20.416 --> 00:33:21.746 A:middle
position there.

00:33:23.096 --> 00:33:24.556 A:middle
And all this can happen even

00:33:24.556 --> 00:33:26.646 A:middle
if the main thread is busy
doing layout and painting.

00:33:26.976 --> 00:33:28.846 A:middle
So this means that we
can do scrolling even

00:33:28.846 --> 00:33:31.656 A:middle
when layouts happening or the
page is busy doing other stuff.

00:33:31.846 --> 00:33:34.026 A:middle
So this is what gives us our
really responsive scrolling.

00:33:34.536 --> 00:33:39.686 A:middle
Now this is all fine when the
page is simply you know block

00:33:39.686 --> 00:33:42.816 A:middle
of pixels that moves up and down
but there are various features

00:33:42.816 --> 00:33:44.786 A:middle
in CSS that makes scrolling
a little more complicated

00:33:44.786 --> 00:33:45.166 A:middle
than that.

00:33:45.586 --> 00:33:47.976 A:middle
So let me just quickly
explain some of those.

00:33:48.556 --> 00:33:50.506 A:middle
The first one is fixed position,

00:33:50.506 --> 00:33:52.656 A:middle
which I'm sure you're all
familiar with as web developers,

00:33:52.936 --> 00:33:54.106 A:middle
the position fix property.

00:33:54.416 --> 00:33:57.396 A:middle
And of course it's very
common, for example,

00:33:57.396 --> 00:34:01.686 A:middle
his social link aside,
that the author has styled

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:33:57.396 --> 00:34:01.686 A:middle
his social link aside,
that the author has styled

00:34:01.686 --> 00:34:05.556 A:middle
with position fixed and when
the page scrolls of course

00:34:05.556 --> 00:34:07.656 A:middle
that social link stays
in the same place.

00:34:07.856 --> 00:34:09.485 A:middle
Standard position
fixed behavior.

00:34:10.005 --> 00:34:12.666 A:middle
But the browser has to
understand this now and be able

00:34:12.666 --> 00:34:15.065 A:middle
to analyze the page and break
the page up into a series

00:34:15.065 --> 00:34:17.306 A:middle
of layers so it knows how
to move all those layers

00:34:17.306 --> 00:34:20.436 A:middle
around when you scroll and
keep the right behavior.

00:34:22.966 --> 00:34:26.356 A:middle
There's a second sort of special
scrolling behavior in CSS

00:34:26.356 --> 00:34:28.585 A:middle
and that's fixed backgrounds,

00:34:29.275 --> 00:34:32.565 A:middle
backgrounds that have the
background attachment fixed

00:34:32.565 --> 00:34:36.545 A:middle
style in them and these
are also quite common.

00:34:36.926 --> 00:34:39.596 A:middle
For example the author of this
page may have put a background

00:34:39.596 --> 00:34:42.936 A:middle
image on the page by starting
the body in this case.

00:34:43.246 --> 00:34:46.426 A:middle
And then they said they wanted
background detachment fixed.

00:34:46.596 --> 00:34:48.896 A:middle
And that means that when the
page scrolls the background

00:34:48.896 --> 00:34:50.976 A:middle
image actually stays in the
same place in the view port

00:34:51.246 --> 00:34:53.946 A:middle
so it's sort of the background
equivalent of position fixed

00:34:54.255 --> 00:34:57.666 A:middle
so it looks like this.

00:34:57.836 --> 00:35:00.606 A:middle
But again, this is a scrolling
behavior the browser now

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:34:57.836 --> 00:35:00.606 A:middle
But again, this is a scrolling
behavior the browser now

00:35:00.606 --> 00:35:04.396 A:middle
understands and we do
that by breaking the page

00:35:04.396 --> 00:35:05.546 A:middle
into a series of layers.

00:35:05.836 --> 00:35:07.746 A:middle
And then we know how
to move those layers

00:35:07.746 --> 00:35:09.736 A:middle
around at the right time
when the user scrolls.

00:35:10.176 --> 00:35:12.166 A:middle
So it's this functionality
that allows us

00:35:12.166 --> 00:35:13.516 A:middle
to get really responsive
scrolling

00:35:13.516 --> 00:35:15.216 A:middle
on many more pages in Safari 7.

00:35:15.216 --> 00:35:21.026 A:middle
Now I need to say a little bit
more about fixed backgrounds.

00:35:21.906 --> 00:35:23.306 A:middle
When we looked at pages

00:35:23.306 --> 00:35:25.246 A:middle
that were using fixed
backgrounds we found

00:35:25.246 --> 00:35:27.856 A:middle
that by far the most
common case was for pages

00:35:27.856 --> 00:35:28.996 A:middle
to use fixed backgrounds

00:35:29.066 --> 00:35:33.406 A:middle
to style the page
background, normally the body.

00:35:33.636 --> 00:35:35.396 A:middle
So that's the case
that we optimized for.

00:35:35.946 --> 00:35:39.286 A:middle
And you can style the
page background either

00:35:39.286 --> 00:35:42.626 A:middle
by putting the fixed background
style on the HTML element

00:35:42.626 --> 00:35:45.826 A:middle
or the body element in your
CSS but you really want

00:35:45.826 --> 00:35:47.246 A:middle
to do both and not one of those.

00:35:48.036 --> 00:35:50.676 A:middle
But actually CSS 2.1 has
something to say here.

00:35:51.536 --> 00:35:54.626 A:middle
If we go and read CSS 2.1
in detail it does recommend

00:35:54.626 --> 00:35:58.176 A:middle
that you style the page
background by putting that style

00:35:58.176 --> 00:36:05.286 A:middle
on the body not on the HTML so
we recommend that you do that.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:35:58.176 --> 00:36:05.286 A:middle
on the body not on the HTML so
we recommend that you do that.

00:36:05.456 --> 00:36:07.306 A:middle
Now there's something else
when we're looking at scrolling

00:36:07.306 --> 00:36:10.536 A:middle
that we saw that was really
common and that is pages

00:36:10.536 --> 00:36:14.686 A:middle
that use scroll events to do
stuff, to move things around,

00:36:15.156 --> 00:36:16.676 A:middle
when to use the scrolling
the page.

00:36:17.626 --> 00:36:19.266 A:middle
But there's a problem
with scroll events

00:36:19.316 --> 00:36:20.466 A:middle
in that they're asynchronous.

00:36:21.586 --> 00:36:23.346 A:middle
Many browsers have
discovered that if you try

00:36:23.346 --> 00:36:25.666 A:middle
to run JavaScript at the same
time the user is scrolling,

00:36:25.906 --> 00:36:28.826 A:middle
that really impacts the users
experience in scrolling,

00:36:28.826 --> 00:36:31.816 A:middle
it really can make
scrolling less than stellar.

00:36:32.446 --> 00:36:35.396 A:middle
So a lot of browsers now send
scroll events asynchronously

00:36:35.396 --> 00:36:36.146 A:middle
to the page.

00:36:36.636 --> 00:36:40.696 A:middle
But there's one behavior that
we saw that was really common

00:36:40.696 --> 00:36:43.626 A:middle
where people were still
using these scroll events

00:36:43.626 --> 00:36:45.326 A:middle
which have this asynchronous
problem

00:36:45.406 --> 00:36:47.736 A:middle
to get what we call
sticky behavior

00:36:48.736 --> 00:36:50.306 A:middle
and I'll explain what that is.

00:36:50.806 --> 00:36:51.886 A:middle
Here are a couple of examples.

00:36:51.886 --> 00:36:53.606 A:middle
This is the Apple Store.

00:36:53.706 --> 00:36:55.996 A:middle
And if you watch that box
on the right hand side,

00:36:56.716 --> 00:37:01.616 A:middle
when the page scrolls that box
moves with the page for a bit

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:36:56.716 --> 00:37:01.616 A:middle
when the page scrolls that box
moves with the page for a bit

00:37:01.616 --> 00:37:03.046 A:middle
and then it sticks
to the top edge.

00:37:03.286 --> 00:37:05.686 A:middle
And as the page scrolls
back down it drops back

00:37:05.686 --> 00:37:06.756 A:middle
into its old location.

00:37:07.626 --> 00:37:09.176 A:middle
Here's another example
from Yelp.

00:37:09.816 --> 00:37:12.786 A:middle
If you take a look at the map on
the right hand side you'll see

00:37:12.786 --> 00:37:15.356 A:middle
that when the page scrolls
the map moves up with the page

00:37:15.906 --> 00:37:17.526 A:middle
but it sticks to the top.

00:37:17.686 --> 00:37:19.996 A:middle
And at a certain point the
content underneath the map is

00:37:19.996 --> 00:37:21.376 A:middle
pushing it up back
to the viewport.

00:37:22.096 --> 00:37:24.296 A:middle
You may also have noticed a
little jump at the beginning

00:37:24.296 --> 00:37:25.176 A:middle
where the map disappeared

00:37:25.176 --> 00:37:28.696 A:middle
under the edge slightly
before it came back down

00:37:28.696 --> 00:37:30.326 A:middle
and that's caused by the fact

00:37:30.326 --> 00:37:31.746 A:middle
that scroll events
are asynchronous

00:37:32.056 --> 00:37:34.336 A:middle
so the page only hears about
the scroll a little time

00:37:34.336 --> 00:37:35.136 A:middle
after it's happened.

00:37:35.686 --> 00:37:39.016 A:middle
So by using scroll events to get
this behavior you're never going

00:37:39.016 --> 00:37:41.616 A:middle
to get frame accurate
really smooth scrolling.

00:37:42.956 --> 00:37:47.176 A:middle
So we knew in Safari that we
had to make a declarative way

00:37:47.546 --> 00:37:51.566 A:middle
where authors could get this
behavior in CSS without having

00:37:51.566 --> 00:37:52.566 A:middle
to run any JavaScript.

00:37:53.016 --> 00:37:54.926 A:middle
And that's what we
call sticky position.

00:37:55.486 --> 00:37:59.966 A:middle
So this is a new value for the
position property called sticky

00:37:59.966 --> 00:38:03.096 A:middle
and because it's still in draw
form it has the WebKit prefix.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:37:59.966 --> 00:38:03.096 A:middle
and because it's still in draw
form it has the WebKit prefix.

00:38:03.626 --> 00:38:08.346 A:middle
And to be a little more
technical, sticky specifies

00:38:08.346 --> 00:38:10.306 A:middle
that an element takes
up space in the flow

00:38:11.646 --> 00:38:15.126 A:middle
but its position is
constrained by the viewport

00:38:15.126 --> 00:38:17.906 A:middle
or some scrollable ancestor
and the containing block.

00:38:18.556 --> 00:38:19.646 A:middle
What does that mean?

00:38:19.646 --> 00:38:20.996 A:middle
Well let me show
you a few pictures.

00:38:21.856 --> 00:38:24.336 A:middle
So here's a page with a
sticky element, the red one,

00:38:24.866 --> 00:38:26.356 A:middle
which is simply positioned

00:38:26.356 --> 00:38:28.416 A:middle
or simply inflow
after the green box.

00:38:29.216 --> 00:38:31.376 A:middle
So at this point the
element is behaving just

00:38:31.376 --> 00:38:32.456 A:middle
like position relative would.

00:38:33.056 --> 00:38:36.856 A:middle
So when you scroll the page
the sticky element just scrolls

00:38:36.856 --> 00:38:37.676 A:middle
up with the page.

00:38:37.956 --> 00:38:42.106 A:middle
But now the sticky element has
hit the edge of the viewport

00:38:42.826 --> 00:38:45.506 A:middle
so it starts behaving more like
position fixed at this point.

00:38:45.826 --> 00:38:48.466 A:middle
And so as the page scrolls
it stays in the same place.

00:38:49.306 --> 00:38:53.246 A:middle
But if you scroll a bit more the
sticky element hits the bottom

00:38:53.246 --> 00:38:56.516 A:middle
edge of its containing
block and so if you continue

00:38:56.516 --> 00:38:57.856 A:middle
to scroll the bottom edge

00:38:57.856 --> 00:38:59.776 A:middle
of the containing block
is pushing the sticky item

00:38:59.776 --> 00:39:00.566 A:middle
out of the page.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:38:59.776 --> 00:39:00.566 A:middle
out of the page.

00:39:00.976 --> 00:39:02.866 A:middle
And so this is exactly
the behavior we saw

00:39:02.866 --> 00:39:03.666 A:middle
with the Yelp map.

00:39:04.116 --> 00:39:07.356 A:middle
So how do you get this behavior
now with this new property?

00:39:07.846 --> 00:39:10.826 A:middle
Well it's actually
just two lines of CSS.

00:39:11.056 --> 00:39:15.456 A:middle
You specify that you want the
sticky property for position

00:39:16.426 --> 00:39:18.306 A:middle
and then you have to
tell us which edge

00:39:18.306 --> 00:39:21.846 A:middle
of the viewport the sticky
thing is going to stick

00:39:21.846 --> 00:39:25.406 A:middle
to so top right from
the left and you have

00:39:25.406 --> 00:39:27.396 A:middle
to tell us how far away from
that edge you want to stick.

00:39:27.656 --> 00:39:29.896 A:middle
So in this case we're saying
we want to stick 10 pixels

00:39:29.896 --> 00:39:33.066 A:middle
from the top and that's all
we need to get that behavior.

00:39:35.716 --> 00:39:39.756 A:middle
So we've been pursuing position
sticky in the CSS working group

00:39:40.116 --> 00:39:41.136 A:middle
and they really loved it.

00:39:41.136 --> 00:39:42.206 A:middle
They were really enthusiastic.

00:39:42.586 --> 00:39:44.436 A:middle
And we hope to see it
in a future version

00:39:44.436 --> 00:39:45.706 A:middle
of the CSS positioning module.

00:39:46.246 --> 00:39:53.526 A:middle
And it's present in Safari
6.1 and 7 and on iOS 7 Mac.

00:39:55.106 --> 00:39:57.156 A:middle
So what should you
do to make sure

00:39:57.156 --> 00:40:01.256 A:middle
that your pages are getting the
best possible scrolling behavior

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:39:57.156 --> 00:40:01.256 A:middle
that your pages are getting the
best possible scrolling behavior

00:40:01.256 --> 00:40:01.886 A:middle
in Safari?

00:40:02.456 --> 00:40:07.386 A:middle
If you use fixed backgrounds
you should only use them

00:40:07.386 --> 00:40:10.396 A:middle
for the page background and
preferably on the body element.

00:40:11.046 --> 00:40:14.726 A:middle
Now I talked about scroll events

00:40:15.146 --> 00:40:18.366 A:middle
which is the most common scroll
event handler that we see

00:40:18.796 --> 00:40:21.726 A:middle
but there's one other scroll
event that people register

00:40:21.726 --> 00:40:24.926 A:middle
for which unfortunately
does force us to drop

00:40:24.926 --> 00:40:27.986 A:middle
out of our best scrolling mode
and that's the mousewheel event.

00:40:28.766 --> 00:40:32.586 A:middle
Now mousewheel doesn't have
this asynchronous nature.

00:40:32.586 --> 00:40:34.536 A:middle
People expect that
mousewheel events are delivered

00:40:34.536 --> 00:40:37.506 A:middle
synchronously with scrolling so
if we see a mouse event header

00:40:37.506 --> 00:40:40.226 A:middle
on the page we have to drop out
of our fastest scrolling mode

00:40:40.526 --> 00:40:42.786 A:middle
and get you know good scrolling
but not great scrolling.

00:40:43.326 --> 00:40:47.706 A:middle
And of course as I said, if
you're using scroll events

00:40:47.936 --> 00:40:48.846 A:middle
and if you're using them just

00:40:48.846 --> 00:40:50.976 A:middle
to get sticky behavior
then you should start using

00:40:50.976 --> 00:40:51.726 A:middle
position sticky.

00:40:53.626 --> 00:40:56.776 A:middle
Finally this is another
case where we optimize

00:40:56.776 --> 00:41:00.026 A:middle
for the most common case
that we saw which is

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:40:56.776 --> 00:41:00.026 A:middle
for the most common case
that we saw which is

00:41:00.026 --> 00:41:03.306 A:middle
that almost all pages scroll by
just scrolling the main document

00:41:03.646 --> 00:41:05.806 A:middle
but there are a few pages
that scroll by putting a bunch

00:41:05.806 --> 00:41:09.096 A:middle
of content into overflow
scroll or iframes or frames.

00:41:09.716 --> 00:41:11.786 A:middle
And we didn't ultimize
for those yet.

00:41:12.246 --> 00:41:16.036 A:middle
So you should make sure that you
simply use main document scroll

00:41:16.036 --> 00:41:18.846 A:middle
then and that's how your users
will have the best scrolling

00:41:19.256 --> 00:41:20.516 A:middle
experiences on your pages.

00:41:20.516 --> 00:41:25.356 A:middle
So at this point I'd like to
invite Tim back on the stage

00:41:25.676 --> 00:41:28.486 A:middle
to show us how we can take a
page that doesn't scroll as well

00:41:28.486 --> 00:41:30.586 A:middle
as it should and to
scroll really well.

00:41:31.086 --> 00:41:34.396 A:middle
[Applause]

00:41:34.896 --> 00:41:37.356 A:middle
>> Tim Horton: Alright so
my friends who just got back

00:41:37.356 --> 00:41:41.016 A:middle
from Bali sent me this website
full of their photos and noted

00:41:41.016 --> 00:41:43.556 A:middle
to me that scrolling
didn't really seem as smooth

00:41:43.556 --> 00:41:45.896 A:middle
as they expected it to be
and they knew that I worked

00:41:45.896 --> 00:41:48.666 A:middle
on WebKit so they wanted to
see if there was anything

00:41:48.666 --> 00:41:49.786 A:middle
that they could do
to make it better.

00:41:50.196 --> 00:41:51.286 A:middle
So here's that site.

00:41:51.286 --> 00:41:54.326 A:middle
And let's just scroll
it for a minute

00:41:54.326 --> 00:41:56.776 A:middle
and see what it looks like.

00:41:56.776 --> 00:41:58.876 A:middle
So you might be able to
see up here on the screen

00:41:58.876 --> 00:42:00.096 A:middle
that scrolling is
kind of chunky.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:41:58.876 --> 00:42:00.096 A:middle
that scrolling is
kind of chunky.

00:42:00.096 --> 00:42:03.616 A:middle
It's not really super smooth
and I can really, really feel it

00:42:03.616 --> 00:42:06.366 A:middle
with my fingers down
on the track pad.

00:42:06.516 --> 00:42:09.146 A:middle
So let's see if we can figure
out why this is happening.

00:42:09.146 --> 00:42:12.336 A:middle
Let's go to the develop menu
and show the web inspector.

00:42:13.436 --> 00:42:16.276 A:middle
And let's record a layout
remembering timeline while we're

00:42:16.276 --> 00:42:19.056 A:middle
scrolling and just see
what it looks like.

00:42:19.056 --> 00:42:21.576 A:middle
So as we scroll along here
we're painting constantly

00:42:21.756 --> 00:42:22.436 A:middle
and that's not good.

00:42:22.436 --> 00:42:25.076 A:middle
That consumes power and it
obviously doesn't perform well.

00:42:25.386 --> 00:42:29.076 A:middle
So let's go back and look at the
page and see if we can figure

00:42:29.076 --> 00:42:31.726 A:middle
out why this is happening.

00:42:31.726 --> 00:42:34.336 A:middle
You may remember, and Simon
mentions to me quite often,

00:42:34.336 --> 00:42:38.086 A:middle
that fixed backgrounds
can often drop us out of,

00:42:38.616 --> 00:42:42.136 A:middle
or can in some cases drop
us out of fast scrolling.

00:42:42.606 --> 00:42:46.046 A:middle
So you notice that this page
back here has a fixed background

00:42:46.046 --> 00:42:47.736 A:middle
so let's look at the code and
see if that's what's happening.

00:42:48.516 --> 00:42:54.666 A:middle
[Noise]

00:42:55.166 --> 00:42:56.986 A:middle
So as I look through
the code I notice

00:42:57.056 --> 00:43:02.726 A:middle
in fact they do have a fixed
background on an element

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:42:57.056 --> 00:43:02.726 A:middle
in fact they do have a fixed
background on an element

00:43:02.726 --> 00:43:03.946 A:middle
that is not a root element

00:43:03.946 --> 00:43:05.526 A:middle
and not the body
[inaudible] tells them to.

00:43:05.526 --> 00:43:08.956 A:middle
So let's just move
that up in the code,

00:43:09.266 --> 00:43:14.906 A:middle
up to the body, and
see what happens.

00:43:14.956 --> 00:43:18.356 A:middle
Woe, scrolling is
perfectly smooth now.

00:43:19.276 --> 00:43:20.566 A:middle
Let's go back into
the web inspector

00:43:20.566 --> 00:43:24.386 A:middle
and see what it looks like now.

00:43:24.596 --> 00:43:27.566 A:middle
We'll record another
timeline and take a look.

00:43:28.106 --> 00:43:29.146 A:middle
And you'll notice now

00:43:29.486 --> 00:43:31.596 A:middle
as we scroll there's really
not much painting happening.

00:43:32.146 --> 00:43:34.336 A:middle
That's excellent.

00:43:35.186 --> 00:43:38.016 A:middle
So let's look at the
JavaScript timeline,

00:43:38.016 --> 00:43:40.496 A:middle
which we notice has lots
of stuff going on in it

00:43:40.496 --> 00:43:42.216 A:middle
for some reason and it looks

00:43:42.216 --> 00:43:44.456 A:middle
like this page is using
scroll events for some reason.

00:43:44.456 --> 00:43:47.056 A:middle
You can see all of
these scroll events.

00:43:47.056 --> 00:43:51.086 A:middle
Let's go back and look
at the page again and see

00:43:51.086 --> 00:43:54.046 A:middle
if we can maybe determine why it
would be doing that since waking

00:43:54.046 --> 00:43:56.056 A:middle
up for JavaScript isn't
great for power either.

00:43:57.416 --> 00:44:00.966 A:middle
So you'll notice here at the
top of the page, scroll down,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:43:57.416 --> 00:44:00.966 A:middle
So you'll notice here at the
top of the page, scroll down,

00:44:00.966 --> 00:44:04.546 A:middle
see the map and post section
there, it's sticking to the top.

00:44:05.066 --> 00:44:07.726 A:middle
You can see that, oops.

00:44:08.256 --> 00:44:11.666 A:middle
So let's look at the page

00:44:11.666 --> 00:44:13.696 A:middle
and see what they might
be doing with JavaScript.

00:44:14.066 --> 00:44:18.446 A:middle
And you see here they
do actually have a bunch

00:44:18.446 --> 00:44:21.516 A:middle
of JavaScript that's just being
used to perform that sticky

00:44:21.516 --> 00:44:23.956 A:middle
and that's not great
because just

00:44:23.956 --> 00:44:25.906 A:middle
as I mentioned we now
have position sticky

00:44:26.356 --> 00:44:28.986 A:middle
so we can actually just delete
this JavaScript, get rid of all

00:44:28.986 --> 00:44:29.906 A:middle
of the JavaScript on the page.

00:44:29.906 --> 00:44:35.296 A:middle
Let's see what the page looks
like now just for kicks.

00:44:35.296 --> 00:44:38.426 A:middle
So you see now the
sidebar does not stick.

00:44:38.926 --> 00:44:41.126 A:middle
It's alright because
again we have sticky.

00:44:41.126 --> 00:44:45.206 A:middle
We can go and with two lines we
can apply to that same element,

00:44:45.816 --> 00:44:50.526 A:middle
we can apply sticky positioning
and tell it to stick to the top

00:44:51.256 --> 00:44:53.276 A:middle
and now let's refresh and scroll

00:44:53.276 --> 00:44:55.446 A:middle
and we get the same
behavior we had before,

00:44:56.366 --> 00:44:57.206 A:middle
right there very nice.

00:44:58.466 --> 00:45:01.106 A:middle
And let's look one more time
back in the develop menu

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:44:58.466 --> 00:45:01.106 A:middle
And let's look one more time
back in the develop menu

00:45:01.246 --> 00:45:02.246 A:middle
and show the web inspector

00:45:03.006 --> 00:45:04.946 A:middle
and record another
timeline while scrolling

00:45:05.736 --> 00:45:08.396 A:middle
and you'll see there's
nothing, no painting,

00:45:09.286 --> 00:45:10.666 A:middle
no JavaScript events, nothing.

00:45:10.666 --> 00:45:12.166 A:middle
This is fantastic for power.

00:45:12.166 --> 00:45:13.556 A:middle
It's fantastic for performance.

00:45:14.356 --> 00:45:16.936 A:middle
And so I hope this has shown
you at least some small things

00:45:16.936 --> 00:45:19.126 A:middle
that you can do to maybe make
your website scroll better

00:45:19.676 --> 00:45:20.496 A:middle
and use less power.

00:45:20.916 --> 00:45:21.886 A:middle
Thank you.

00:45:21.886 --> 00:45:22.116 A:middle
[Applause]

00:45:22.116 --> 00:45:33.406 A:middle
>> Simon Fraser: Thank you, Tim.

00:45:34.446 --> 00:45:36.916 A:middle
Once you've feel the scrolling
performance in Safari 7

00:45:36.916 --> 00:45:38.886 A:middle
in OS X Mavericks we think
you'll really love it.

00:45:39.376 --> 00:45:40.826 A:middle
And you should really make sure

00:45:40.826 --> 00:45:42.676 A:middle
that your pages get the
best possible scrolling

00:45:42.676 --> 00:45:44.946 A:middle
because your uses will notice
and they'll love your pages.

00:45:46.836 --> 00:45:48.166 A:middle
So let me wrap up.

00:45:48.886 --> 00:45:54.396 A:middle
So I talked about the two new
power saving features in Safari,

00:45:54.916 --> 00:45:57.146 A:middle
App Nap for Safari
Tabs and Power Saver,

00:45:57.546 --> 00:45:59.396 A:middle
that give us these
great power savings

00:45:59.396 --> 00:46:01.036 A:middle
and make Safari super
power efficient.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:45:59.396 --> 00:46:01.036 A:middle
and make Safari super
power efficient.

00:46:01.506 --> 00:46:03.926 A:middle
And we've also talked
about responses scrolling,

00:46:04.196 --> 00:46:06.376 A:middle
which is not only a more
efficient way of scrolling

00:46:06.956 --> 00:46:08.996 A:middle
but really improves our
scrolling performance

00:46:08.996 --> 00:46:09.986 A:middle
in a way that you can feel.

00:46:10.576 --> 00:46:15.776 A:middle
But we also talked about
how web content also needs

00:46:15.776 --> 00:46:16.536 A:middle
to be ultimized.

00:46:16.706 --> 00:46:19.416 A:middle
So we want you to go back
and look at your web content

00:46:19.876 --> 00:46:24.076 A:middle
and take this advice to heart
so you should reduce the amount

00:46:24.076 --> 00:46:25.556 A:middle
of work you do in
background pages

00:46:25.866 --> 00:46:28.856 A:middle
by using the page
visibility API and also

00:46:28.856 --> 00:46:32.356 A:middle
to use requestAnimationFrame for
animations if you really need

00:46:32.356 --> 00:46:33.736 A:middle
to use JavaScript
for animations.

00:46:34.686 --> 00:46:36.906 A:middle
You should make sure that
you don't fall into any

00:46:36.936 --> 00:46:39.836 A:middle
of those common pitfalls that
we talk about in terms of laying

00:46:40.146 --> 00:46:43.946 A:middle
out too much and painting too
much and use the web inspector

00:46:43.946 --> 00:46:45.956 A:middle
to make sure that,
as Tim showed,

00:46:46.166 --> 00:46:49.206 A:middle
when you scroll your page
there's really no work.

00:46:49.206 --> 00:46:52.646 A:middle
The browser's just taking care
of everything under the hood.

00:46:52.766 --> 00:46:54.646 A:middle
And finally, as we said,

00:46:54.646 --> 00:46:56.556 A:middle
responsive scrolling is
really great, you'll love it.

00:46:56.836 --> 00:46:58.226 A:middle
And we think your
users will love it

00:46:58.276 --> 00:46:59.546 A:middle
when they see it on your pages.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:47:00.126 --> 00:47:05.246 A:middle
So if you need more information
you contact John Geleynse

00:47:05.246 --> 00:47:08.336 A:middle
or a look at the
documentation on Safari.center.

00:47:08.336 --> 00:47:11.386 A:middle
If you're an extension
developer you should go

00:47:11.386 --> 00:47:12.226 A:middle
and read the updates

00:47:12.226 --> 00:47:13.986 A:middle
to the Safari extensions
development guide

00:47:14.176 --> 00:47:17.116 A:middle
because there are some important
points about changes in Safari 7

00:47:17.386 --> 00:47:18.396 A:middle
that you should go
and read about.

00:47:18.896 --> 00:47:19.826 A:middle
And finally, of course,

00:47:19.826 --> 00:47:22.286 A:middle
the Apple Developer forums are a
great place to go and get help.

00:47:22.806 --> 00:47:26.066 A:middle
Now there were a lot of
related sessions yesterday

00:47:26.766 --> 00:47:28.556 A:middle
and I encourage you to
go and watch the videos

00:47:28.556 --> 00:47:29.746 A:middle
if you haven't seen
those already.

00:47:30.346 --> 00:47:31.686 A:middle
There were two on
the web inspector.

00:47:31.686 --> 00:47:33.996 A:middle
There was one on New
Features in WebKit Safari

00:47:34.256 --> 00:47:37.326 A:middle
and then there were a couple
of more OS level sessions

00:47:37.326 --> 00:47:40.066 A:middle
about battery life
and actually coming

00:47:40.066 --> 00:47:41.936 A:middle
up next I think is
the App Nap talk

00:47:42.236 --> 00:47:44.526 A:middle
which will give you the
sort of system level view

00:47:44.526 --> 00:47:46.086 A:middle
of the App Nap feature
that I talked about.

00:47:46.586 --> 00:47:47.216 A:middle
Thank you very much.

00:47:47.216 --> 00:47:49.016 A:middle
[Applause]

00:47:49.016 --> 00:47:59.436 A:middle
[Silence]