►
Description
Productive Web Development Powered by AMP - Kristofer Baxter & Ben Morss, Google
A
So
hello
welcome
to
a
session
here
on
amp
and
productive
abilipad
powered
by
amp.
My
name
is
Ben
Morse
I'm,
a
developer
advocate
for
Google
my
job.
There
is
help
the
web
be
faster
and
easier
to
use
for
users,
as
for
developers
as
well,
I
used
to
be
a
full
time
musician,
which
we
can
discuss
if
you're
interested,
also
but
I'm.
Not
here
today
is
really
a
Googler
or,
of
course,
musician
I'm.
Here
today,
as
a
representative
of
the
amp
open
source
project,
amp
is
joining
open,
jeaious
and
we're
very
excited
about
this.
A
So
today
my
Googler
hat
is
not
on
my
amp
open
source
hat
is
on
so
why
am
first
of
all?
What
is
this
app
thing,
and
why
do
you
think
it's
a
good
idea
to
try
out
amp?
The
thing
is
that
the
web
is
a
wonderful
place
full
of
endless
possibilities.
It's
like
cooking.
You
can
use
any
ingredients
you
want
to
in
any
way
you
want
to
mix
and
match
things.
However,
you
want
to
and
do
whatever
you
want,
which
is
great,
because
the
web
should
be
free
so
in
website.
A
You
can,
for
example,
have
lots
of
stuff
if
you
want
to,
you,
can
have
lots
of
images
and
lots
of
CSS
and
code
and
third-party
libraries
and
you
can
put
on
chat,
widgets
and
complicated,
elaborate
menus
and
video
embeds,
and
you
can
have
pixels
on
there.
Various
sorts
analytics
lots
of
things
which
is
all
finding
good,
useful
functionality.
The
problem
can
happy,
though,
when
you
have
a
lot
of
these
things
on
there,
it
can
become
a
little
more
like
this.
A
It
came
became
become
a
little
more
of
a
giant,
wonderful
kind
of
mess,
and
that's
fine,
that's
good
to
you,
but
the
story
is
web
developer.
The
problem
may
be
also
that
not
just
things
are
kind
of
complicated
to
use
or
might
taste
funny
in
strange
combinations,
but
also
that
a
site
with
lots
of
JavaScript
on
it
and
lots
of
CSS
may
be
slower.
What
happens,
then?
A
Is
people
like
this
here
are
looking
at
your
site,
loading
up
your
site,
they're
on
their
phone
and
it's
not
loading
they're,
looking
at
their
site,
they're
getting
frustrated
by
it
this
guy
over
here
you
see,
taken
up
smoking
and
drinking
because
his
life's
looking
so
slowly
and
the
frustration
so
you're
gonna
shorten
his
lifespan.
So
to
save
this
guy's
life
given
more
years
to
enjoy
everything
there
is
to
enjoy
about
Montreal.
The
poutine
here
is
incredible.
A
For
example,
you
should
make
your
site
faster
for
him,
and
it
isn't
just
this
guy
over
here
I
mean
you
may
also
say.
Well,
my
site
has
a
lot
of
users
who
have
4G
connections
and
LTE.
They
live
in
nice
cities
where
they
get
great
connections.
They
have
top-of-the-line
iPhones
or
Galaxy
phones,
but
remember
also
it's
about
inclusion.
It's
about
accessibility,
because
last
time,
I
checked.
40%
of
connections
in
the
world
were
still
2g
and
2g
is
quite
different.
A
Experience
I
know
because
I
have
t-mobile
and
I
travel
I
get
free,
unlimited,
2g
data
roaming
and
many
sites
don't
work
at
all.
You
can
tell
actually
ok
this
a
it's
gonna
load
up.
I
can
look
Wikipedia,
it's
gonna
work,
other
things
you're,
like
my
banking
site.
It's
never
gonna
work
at
any
point.
It'll
be
slow
and
hard
to
use.
I
mean
you
guys
know
this
already.
Your
program
is
about
performance.
Before
we
often
forget
the
people
and
other
places
in
the
world
we've
been
in.
A
This
country
often
can't
use
sites
unless
they're
made
carefully,
so
they
can
load
quickly,
not
too
much
code,
not
too
large
images
and
so
on
and
so
forth.
Amp
was
created
to
make
these
problems
easier
to
solve
problems
like
slow
loading,
which
we
just
discussed,
but
also
if
content
already
has
loaded
up
and
JavaScript
is
still
loading
and
parsing
and
executing
event
handlers,
you're
still
attaching
to
things
in
the
Dom.
A
A
I
think
shift
around
sometimes
several
times
as
the
site
loads
and
this
kind
of
unstable
content
loading
is
kind
of
disturbing
for
the
user
and
hard
to
make
things
kind
of
feel
like
a
bowl
and
trustworthy
and
accessible.
So
amp
was
designed
to
fix
these
kinds
of
problems.
Of
course
you
need
amp
for
these
things,
you
can't
fix
it
yourself
right
away,
you're
supposed
to
get
it
programmers
you
can
use
JavaScript
to
make
things
better
and
you
can
make
things
easier
for
the
user
and
all
of
these
ways.
A
The
problem
is
it's
pretty
hard
to
actually
do,
because
we
see
on
the
web
that
most
people
don't
do
these
things
at
all.
We
see
that
very
people,
people
lazy
load
images.
We
still
see
a
web
full
of
a
megabyte
of
unmodified
JavaScript,
it's
hard
for
people
to
actually
make
things
fast
out
there.
So
this
is
what
app
was
created
to
make
easier
for
people
on
the
web.
So
it's
why
people
do
say.
Sometimes
things
like
yeah
everyone's
doing
amp
tried
to
use
amp
yeah.
A
You
should
because
Google
kinda
wants
it
for
SEO,
it's
just
kind
of
do
it,
because
Google
really
expects
you
to
do
it.
Okay,
so
I'll
make
this
amp
thing.
Should
I
pick
my
site
better
or
change
it
for
amp
or
you
work
it
no
just
kind
of
use
a
plug-in,
and
you
just
watch
the
money
you
kind
of
roll
in
or
something
and
some
truth
to
be
things,
because
Google
does
actually
give
certain
amp
pages
ice
little
badge
on
search,
which
shows
it's
an
amp
page.
A
So
some
of
this
has
some
truth
to
it,
but
it
makes
me
sad
because
wasn't
why
app
was
created.
It
wasn't
to
make
these
kind
of
sort
of
haphazard
sites
that
aren't
great
and
maybe
load
faster
in
some
way.
So
what
is
amp
I
keep
saying
this
word
amp.
What
is
this
thing
simply
put
AMPAS
web
component
framework
and
it's
web
components,
and
it
was
designed
several
years
ago
to
create
websites.
They
were
easier
to
make
and
then
faster
for
users.
That
was
the
idea.
A
It
also
has
since
then
been
adopt
or
other
kinds
purposes
as
well.
So,
for
example,
there
are
now
amp
stories
out
there.
The
kind
of
story
format
that
snapchat
pioneered
Instagram
made
famous
on
Instagram.
These
open
web
stories
now
exists
powered
by
amp.
Also,
if
it's
being
used
in
emails,
now
they're
being
a
bit
of
the
web
power
embedded
into
emails,
little
features
you
can
do
with
amp
components
like
refreshing
data
or
sending
things
to
a
server
somewhere.
A
Those
kinds
of
things
are
possible
now
an
email
using
amp
and
also
because
amp
makes
things
faster
in
general
and
it
conserve
discourages
extra
JavaScript
and
it's
been
useful,
making
ads
as
they're
less
of
intrusive
and
ads
that
also
load
more
quickly
for
users.
So
I
said
AMPAS
web
components
here
are
a
few
of
the
possible
components
you
can
use
in.
One
big
jumble
would
be
a
quiz
later
on
now.
This
is
just
to
show
you
some
examples
of
the
kinds
of
things
amp
can
do,
so
it
can
embed
things.
A
It
can
embed
tweets
and
there's
music
players
and
is
also
interactive,
app
components.
There's
iframes,
there's
all
kinds
of
things:
here's
what
hamper
it's
basically
EML
framework.
So
here's
an
example:
web
components
this
here
embeds
a
YouTube
video
on
your
site
instead
of
using
YouTube's
JavaScript
use
this
component
instead,
a
few
things
that
are
notable
about
this
over
here.
The
first
attribute
is
called
layout.
It
says,
lay
it
equals
responsive
when
they
have
amp
scenes.
This
automatically
will
take
your
YouTube
video.
A
It
will
shrink
it
and
grow
it
as
the
container
shrinks
and
grows
it
does
is
all
for
you
out
of
the
box.
The
width
and
height
are
there,
because
the
amplitude
are
the
size
of
things
in
advance.
That
way,
temp
can
leave
space
for
things
as
your
page
loads
up.
So
in
this
case
YouTube
videos
over
here
on
the
page.
It
leaves
a
blank
space
for
it
and
then,
as
it
loads
up
it
pops
into
its
space.
A
So
amp
guarantee
is
stable
layout
on
your
page
as
well,
and
then
you
provide
the
video
ID
on
the
bottom
over
there
and
it
just
kind
of
sticks,
the
YouTube
video
on
your
site
and
that's
it
a
simple
exemple
and
get
much
more
sophisticated
than
this.
But
this
is
simply
what
it
is.
If
you
make
a
valid
amp
page
that
follows
amps
rules.
A
There
are
also
our
web
spiders
out
there
like
Google's
and
like
bings
they're,
looking
out
there
for
pages
that
are
valid
amp,
which
don't
have
the
JavaScript
in
the
wrong
places
that
will
make
performance
worse,
which
don't
have
too
much
CSS,
which
follow
the
various
rules
for
accessibility
that
happen.
Courage's.
If
you
follow
these
rules,
when
spiders
will
find
these
things
and
they
will
tell
amp
caches
to
cast
your
documents
on
the
caches
so,
for
example,
on
Google's
app
cache
Google
will
find
these
things
and
then
serve
your
page
from
its
own
servers.
A
It
gets
a
little
bit
of
a
badge
there
on
search
and
then
in
some
cases
it
will
be
get
pre-rendered
in
an
iframe,
so
it
loads
up
almost
immediately
when
the
user
clicks
on
it.
Another
cases
it
just
loads,
a
lot
faster.
So
amp
has
this
sort
of
search
tie-in
as
well.
So
amp
really
is
this
thing
about
components
and
about
validation?
If
you
want
to
get
into
these
amp
caches
impulse
is
used
in
various
contexts.
A
These
days
it
was
used
at
first
for
simple
publisher
sites,
but
now
we're
seeing
it
all
over
the
place
so
on
the
left
is
an
e-commerce
example.
This
is
Aliexpress,
you
know
Alibaba
the
very
large
Chinese
company
they
made
it.
They
made
an
ecommerce
experience
for
mobile
sites
with
amp
a
couple
years
ago.
Alibaba
is
a
very
large
company
and
it's
been
pretty
good
for
them
in
production.
Various
interactive
features
are
possible
in
amp.
You
see
the
second
example
there,
or
something
from
SB.
A
So
this
is
an
example
of
a
page
here
which
is
responsive,
working
on
desktop
and
mobile,
all
created
with
amp,
that's
the
basic
overview
of
amp,
but
now
for
more
details
about
amp
I
want
to
bring
up
over
here
my
colleague
Chris,
to
discuss
much
more
detail
like
that.
That's
the
slide
for
you
to
your
home
base
server!
Yeah!
That's
that's
good!.
B
Hi
I'm
Chris,
it's
very
nice
to
meet
you
all
I'm,
a
performance
engineer
at
Google.
My
job
is
to
try
to
make
the
internet
faster.
Specifically,
my
goal
is
1%
faster
for
all
users
every
single
year,
so
I
work
on
lots
of
open-source
technologies
and
frameworks,
but
I
also
work
on
amp
I
want
to
talk
a
little
bit
about
improving
the
return
on
investment
for
your
development
time.
B
We
think
that
amp
can
support
this
concept
of
the
accelerated
developer,
workflows
to
allow
you
to
focus
more
on
the
content
and
the
things
that
make
your
domains
unique
and
less
on
your
infrastructure.
But
first
a
brief
aside.
We
talked
about
amp,
but
not
the
amp
project.
The
amp
project
as
a
whole
is
larger
than
just
the
web
component.
B
If
you're
using
amp,
you
can
also
use
it
across
many
different
surfaces.
Sorry,
my
notes
are
very
large
here,
so
the
the
surfaces
that
have
been
kind
of
briefly
touched
on
you
can
make
websites
using
amp
technologies.
You
can
make
stories
which
are
rich,
visual,
storytelling
tools.
You
can
make
advertisements
that
use
the
same
amp
runtime
in
cash
as
documents,
and
you
can
also
create
interactive
emails.
Interactive
emails
is
fairly
new
and
I
think
also
very
interesting.
B
B
Amp
stories
are
captivating
and
beautiful
because
they
use
the
landscape.
They
use
the
format,
the
vertical
format
that
your
phone
is
designed
with
the
way
that
we
all
consume
format
on
our
devices.
This
means
that
we
can
pair
that
with
great
rich
visual
imagery,
and
we
can
get
a
good
experience
for
users
of
all
sorts
of
different
devices,
but
amp
works
across
all
sorts
of
things,
not
just
mobile
phones
but
browsers
and
desktop
machines
as
well.
It
supports
every
single
user
agent.
We
can.
There
are
course
limitations.
B
We
can't
support
ie8
anymore,
but
we
can
support
IE
10,
which
is
a
huge
compatibility
matrix
that
is
not
found
across
many
technologies
and
if
you
were
looking
at
how
a
high-level
view
of
how
amp
works,
this
is
kind
of
it.
You've
got
origins
that
contain
amp
documents.
Those
amp
documents
can
either
be
served
directly
from
the
origin
or
via
a
cache.
That
is
a
distributed
CDN
by
huge
CDN
partners.
Then
you
have
devices
that
will
pre
render
that
content
to
make
it
feel
almost
instant.
The
moment
you
touch
it,
an
amp
is
really
great.
B
As
a
result
of
this
instant
pre
loading
for
a
lot
of
things,
but
it's
not
perfect
for
everything.
If
someone
comes
up
and
says
to
you,
there's
one
framework
or
one
technology
that
can
build
every
single
thing
on
the
planet,
you
should
call
them
out
for
it
they're
wrong.
The
web
is
an
open,
healthy
ecosystem,
because
of
so
many
tools
that
work
together
and
different
technologies
and
different
approach
is
amp
is
no
different.
We
think
amp
is
great
for
content,
focused
experiences,
things
that
are
focused
more
on
bringing
information
to
users
but
not
say
Gmail.
B
So,
as
a
result,
you
should
use
amp
on
things
like
article
pages
in
product
details,
but
if
you
have
more
sophisticated
workflows
like
say,
settings
pages
or
shopping,
carts
or
you've
got
advanced
search,
capabilities,
amp
isn't
a
great
fit
there.
You
should
use
a
different
technology.
You
should
use
something.
That's
more
fitting
to
that
use
case.
B
Amp
is
an
open
source
technology.
I
may
work
at
Google,
but
amp
is
not
a
Google
product
and
I.
Think
that's
very
important
to
reinforce
the
amp
project
is
open
source.
It's
joining
the
open,
J's
foundation
and
we
think,
as
a
result
of
this,
it
will
make
it
much
easier
to
use.
In
a
long
term.
We
have
public
meetings
for
all
of
our
working
groups.
I
lead
the
UI
and
the
performance
working
group
ones,
there's
ones
for
outreach
as
well
as
several
other
facets.
B
We
would
love
to
have
new
people
joining
and
helping
us
make
a
better
experience
of
the
web.
I
won't
briefly
talk
about
amp
as
a
service
or
affectionally.
How
you
can
worry
less
with
amp
here.
Are
the
segment's
they'll
briefly
dive
into
as
fast
as
I,
possibly
can
get
through
them?
More
content,
less
code,
caching
and
distribution
being
always
up
to
date,
guaranteed
performance
worker
eyes,
JavaScript
and
PWI
support,
so
more
content
and
less
code.
One
of
the
things
that's
really
interesting
and
been
touched
on
this
is
that
amp
is
not
a
JavaScript
framework.
B
It's
an
HTML
framework
and
the
intent
here
is
to
allow
you
to
express
your
interactions
and
all
the
complexities
of
those
types
of
documents,
but
enrich
them
in
a
way
that
is
that
happens
over
time.
It
doesn't
require
a
large
amount
of
JavaScript
upfront
to
be
functional
and
usable,
but
as
a
result,
there
is
a
trade-off
and
if
you
look
at
what
amp
kind
of
lies
in
this
matrix
here,
we
think
this
is
a
fairly
realistic
representation
of
it.
Vanilla,
JavaScript.
You
can
do
almost
anything.
B
Unless
you
need
web
assembly,
then
you
can
do
anything
with
a
J's
library.
You
probably
don't
write
a
lot
of
vanilla,
javascript,
most
people
don't
anymore.
When
it
comes
to
front-end
documents,
you
can
use
JSI
very
like
a
react
or
pre
act
and
you're
able
to
achieve
a
lot
of
that
functionality
that
you
wanted,
with
a
little
bit
less
complexity
and
pulls
the
complexity
down
significantly,
but
as
a
result
of
that,
it's
slightly
less
flexible
and
we
think
this
is
an
interesting
trade-off
for
large
swaths
of
the
web.
B
You're
familiar
with
building
content
focused
websites,
and
this
is
a
bit
what
your
time
looks
like
if
you're
using
a
JavaScript
framework,
a
lot
of
time
spent
on
performance,
optimization
and
build
tools
and
babel
configuration
and
web
pack,
it's
a
lot
of
work
and
a
lot
of
expensive
time
that
you
could
be
using
to
focus
on
your
content.
Instead
with
amp
our
partners
that
have
used,
it
have
seen
a
shift
in
the
way
that
they
work.
This
is
more
like
their
work
style.
B
Some
of
the
app
components
also
have
a
little
bit
of
superpower,
so
antennae
lytx,
is
a
great
example.
Analytics
are
incredibly
important
to
any
page.
It's
making
money
because
you
need
to
be
able
to
track
how
it's
being
seen
and
so
as
a
result.
What
happens
often
is
you
have
several
of
them
and
they
all
starve
and
compete
for
attention.
Each
vendor
is
monitoring
the
Dom.
Each
vendor
is
spending
CPU
cycles,
capturing
information,
none
of
them
are
coordinating
with
one
another
and,
as
a
result,
you
get
huge
microtasks
chunks
on
browsers.
B
So
amp
changes
this
slightly
because
there's
an
intermediary
later
amp
analytics
measures
once
for
all
vendors
and
then
distributes
those
responses
to
the
vendors
using
the
most
efficient
form
that
it
can
to
each
vendor.
So,
for
instance,
it
prefers
beacon
over
using
HTTP,
XML
HTTP
requests
and
in
order
to
use
one
of
these
vendors
with
amp
there's
a
collaboration
that
happens
between
people
on
the
amp
project
and
the
vendors,
and
that
makes
sure
that
those
things
work
efficiently
on
documents
that
might
make
it
seem
like.
B
The
next
item
is
being
always
up
to
date.
When
you
npm
install
something
you
tend
to
get
a
hat
version
of
something
like
react,
but
that's
the
version
that
you
ship
and
until
you
update
react,
you
don't
ship
a
new
version.
This
is
great
in
many
ways,
but
they're
also
trade
offs.
It
means
that
the
the
react
team,
for
instance,
couldn't
operate
it
fully
independently
from
your
website.
They
would
need
you
to
pull
the
new
version
of
react
in
in
order
to
leverage
their
new
code
on
your
site.
Amp
acts
differently.
B
You
point
to
the
amp
CDN
to
grab
JavaScript.
The
amp
has
a
cadence
and
a
release
cycle
on
different
release
branches
that
allows
you
to
pick
how
flexible
you
want
to
be,
but
you
always
get
an
up-to-date
version
of
amp
one
that
changes
and
improves
over
time.
A
good
example
of
this
is
animation.
Support.
Animations
may
start
by
implemented
being
implemented
directly
with
CSS,
but
over
time,
without
changing
the
API
contract
move
to
being
implemented
by
Houdini.
B
But
how
do
we
make
sure
we
don't
break
these
documents
because
there
are
over
a
hundred
billion
of
them
in
the
web.
We
can't
break
them.
Is
the
answer,
and
so
we
do
a
lot
of
testing
a
lot
of
testing.
We
have
one
of
the
biggest
test
matrix
that
you've
ever
seen
for
a
front-end
framework.
It's
not
perfect,
of
course,
that
we
do
our
absolute
best
and
we
feel
reasonably
confident
here
for
four
years
we've
been
doing
this
and
we've
not
had
to
roll
back
a
crazy
number
of
times.
B
Amp
is
built
for
speed
from
the
very
core
concepts
of
how
it
works.
It's
a
very
small
runtime
that
guarantees
static
layout
on
the
on
a
document
and
allows
it
to
do
some
performance
enhancements
along
the
way.
However,
if
you're
like
me,
you've
probably
had
this
conversation
a
few
times.
I
just
want
one
more
beacon
library
on
the
page,
or
can
you
just
add
that
one
more
third-party
vendor
and
every
single
time
this
happens,
I
feel
like
sab
Batman,
who
realized
that
he
picked
the
wrong
comic
universe
to
build
movies
in
well.
B
Amp
is
also
a
technical
well
for
you.
If
something
doesn't
work
in
HAMP,
you
can't
put
it
on
a
valid
amp
document,
and
in
order
for
that
thing
to
be
on
a
valid
amp
document,
it
has
to
meet
amps
performance
guarantees.
This
means
that
we
work
with
those
vendors
to
ensure
their
code
is
performant
and
we'll
work
on
across
the
corpus
of
documents.
B
A
good
example
of
this
is
the
above-the-fold
layout
system,
which
ensures
that
only
the
JavaScript
that
is
necessary
for
where
you're
looking
at
any
given
time
on
a
page
is
used
because
we
have
a
static
layout
guarantee
an
amp.
We
can
effectively
understand
when
a
component
will
become
on-screen
and
in
advance
of
it
becoming
on-screen
fetch
the
JavaScript,
eval
and
parse
it
lazily.
B
Every
one
of
amps
constructors
clot
in
their
classes
does
nothing.
The
goal
is
to
just
set
it
up
to
be
invoked
lazily
later
and
as
a
result,
we
can
also
deprioritize
specific
content
on
a
page,
so
for
a
little
CPU
bound
at
any.
Given
time
we
can
tell
the
ad
unit
that
it's
going
to
get
a
bit
less
CPU
and
that's
great
for
user
experience,
because
it
means
the
article
remains
consistently
usable.
B
Now,
computers
have
multiple
CPU
cores.
You
can
do
multiple
things
in
tandem,
but
the
browser
doesn't
really
work
that
way.
In
general,
it
tends
to
be
single
threaded.
There
are
exceptions,
of
course,
to
this.
So
if
you
haven't,
if
you
have
JavaScript
that's
interfering
with
the
main
threads
processing,
it's
very
difficult
to
understand
how
to
process
the
next
input
looks
a
little
like
this
and
it
ends
up
with
something
called
Rage
clicks.
B
Brief
aside,
it's
a
bit
like
how
the
DMV
used
to
work
you'd
go
to
the
DMV
you'd
wait
in
line
until
you
got
to
the
front
desk.
They've
asked
you
to
fill
out
a
form
and
then
you
could
move
on,
but
most
offices
realize
that
this
wasn't
efficient,
and
so
they
move
to
the
dr.
model
and
the
dr.
model
is
effectively
that
you
come
in.
They
give
you
a
form,
you
go
sit
down
and
you
fill
out
the
form
and
then
you
take
it
back
and
you
go
get
your
results.
B
The
result
is
that
they're
able
to
process
have
more
people
filling
out
forms
simultaneously,
instead
of
a
single
person
impossible
on
the
front
end
in
the
web
for
a
long
time
with
web
workers,
we
just
haven't
used
them,
because
they're
difficult
to
use
so
amp
makes
this
transparent.
Most
of
amp
can
run
within
a
worker,
and
we
think,
as
a
result
of
this,
we
can
offload
a
lot
of
the
CPU
time
from
the
main
thread.
B
That's
where
I
was
supposed
to
say
that
sorry,
so
worker
as
JavaScript,
we
think
is
made
much
easier
with
amp
and
quickly
to
amp.
Doesn't
hate
JavaScript,
it
loves
JavaScript.
All
of
amp
is
written
in
JavaScript.
You
can
use
JavaScript
in
amp
just
because
it's
an
HTML
framework
doesn't
mean
you
can't
use
JavaScript.
It's
just.
We
think
that
the
future
of
JavaScript
isn't
on
the
main
thread.
We
think
the
future
of
JavaScript
in
a
browser
runs
off
main
thread
and
only
interacts
with
the
main
thread
as
necessary.
B
The
way
that
this
works
in
amp
is
that
we
built
an
implementation
of
the
Dom
from
scratch
that
runs
in
a
worker,
so
you
load
your
application
code,
that's
specific
to
your
domain.
It
runs
within
a
worker.
It
has
no
idea
that
it's
not
running
on
the
main
thread
and,
as
a
result,
the
main
thread
stays
less
contentious.
B
There
are
things
that
are
synchronous
about
the
Dom
and
you're
in
a
worker
that
can't
be
synchronously
known
at
that
point.
It's
a
really
good
question.
The
compact
tables
here
we're
also
happy
to
answer
questions
about
this.
There's
a
few
people
here
that
work
on
amp
right
now
and
distribution
is
also
built
into
amp.
It's
an
important
part
about
how
it
stays.
Performant,
amp
pages,
aren't
just
web
documents,
they're
ultra
portable
embeddable
content
units.
B
The
idea
is
to
be
able
to
distribute
them
and
load
them
independently
of
a
route
origin,
and
this
is
what
we
call
instant
loading.
So,
for
instance,
here
on
a
Google
search
results.
Page
amp
documents
can
be
loaded
in
the
background,
so
when
the
user
clicks
on
them
they're
instantly
available
to
support
this
amp
has
something
called
a
pre
render
mode
internally
inside
of
it.
All
of
the
components
do
not
expose
this
through
their
API
contract,
but
deal
with
it.
Internally.
B
Pre-Rendering
comes
with
a
bunch
of
caches,
though
that
are
difficult
to
do
unless
you
design
for
it
up
front.
So,
if
you
order
pre-render
in
advance,
you
would
leak
a
person's
identity,
and
we
think
this
is
terrible
for
users.
So
if
I
went
to
a
search
results,
page
and
then
I
loaded,
a
domain
for
noted,
a
document
from
another
domain
I
would
expose
who
that
person
is
to
the
other
domain
without
them
having
clicked
on
it,
and
this
is
why
we
have
an
amp
cache.
B
Now,
when
you
run
an
amp
document
locally
on
your
domain,
and
you
run
an
ad
document
on
the
cache
they're
very
different,
because
there's
static
guarantees
about
how
amp
documents
look
and
feel
and
operate,
the
cache
can
perform
a
series
of
optimizations
on
those
documents.
Every
image
can
be
modified
to
be
compressed
in
a
lossless
manner.
Every
part
of
the
document
can
be
restructured
as
needed.
B
The
in
order
to
make
this
available
to
things.
Besides
a
cache
like
say
your
canonical
domain,
we've
open-sourced,
the
amp
optimizer,
the
amp
optimizer
is
a
series
of
transforms
written
in
JavaScript
that
work
on
your
documents
and
do
pretty
much
what
the
cache
does.
This
allows
you
to
get
the
benefits
of
the
optimizations
of
the
cache,
but
on
your
local
domain.
B
Lastly,
and
then
PWA
work
really
well
together,
even
better
than
this
animated
gif
shows
we
have
a
one-line
serviceworker,
that's
built
and
customized
for
amp
documents,
so
you
can
retain
that
functionality
immediately
without
having
to
build
complexity
within
your
serviceworker
implementation
and
now
dr.
Ben
thanks.
A
For
doing
all
the
hard
work
there
Chris,
so
that
was
a
lot
of
content
over
there.
If
you
want
to
hear
about
more
of
these
things
in
detail,
you
can
come
to
us
or
other
folks
here,
work
with
amp
or
you
of
course,
and
go
to
our
site
amp
dev,
which
of
course
is
created
with
amp,
and
you
can
find
over
here
many
things
that
are
useful,
interesting
kinds
of
things
on
this
site.
For
example,
there
are
courses
you
can
take
to
learn
how
to
use
amp
using
a
project-based
approach.
A
There's
tools
you
can
use
to
build
your
site
better
to
optimize
things:
lots
of
nice
node
modules,
things
like
that
templates
that
are
built
in
that
you
can
then
download,
and
you
can
use
to
build
your
site
quickly
and,
of
course,
lots
of
documentation,
examples
sometimes
I,
think
actually
work
and
interactive
playgrounds.
You
can
use
to
try
amp
code
out
in
and
modify
things
and
see
what
they
do
and
if
here's,
what
working
on
in
the
future
then
come
visit
over
here.
A
road
map
is
public
because
it's
an
open-source
project
go
to
am
dev.