►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hey
everyone,
my
name
is
melta
and
I'm
a
member
of
the
technical
steering
committee
for
the
amp
project
and
the
tech
lead
for
the
team
at
google
that's
contributing
to
app.
Now
I
want
to
recognize
that
there
are
worse
problems
in
the
world
right
now
than
javascript
frameworks
and
web
performance.
I
want
to
thank
the
protesters
in
the
streets
and
unequivocally
state
that
black
lives
matter
in
today's
talk.
I'll
talk
a
little
bit
around
the
original
thinking
about
amp
how
it
evolved
over
time
and
how
we
think
it
will
develop
in
the
future.
A
One
good
way,
I
think,
to
think
about
how
we
wanted
amp
to
be
was
to
kind
of
think
about
that
performance.
Is
this
race
different
race,
cars
right
and
so
certainly
in
2015?
I'm
not
sure
this
actually
changed
was
that
the
average
mobile
site-
you
know
just
wasn't
doing
quite
so
well
and
was
kind
of
there
in
the
back
of
that
race
right
and
but
we
also
realized
that
there
wasn't.
Actually.
This
is
really
important.
That
was
not
a
technology
problem.
A
You
could
make
a
website
with
great
ux
great
performance
who
was
right
there
at
the
top
right,
if
you
just
hand
tune
it.
If
you
were
an
expert
now,
our
goal
with
amp
was
to
get
up
there
in
the
front.
We
were
not
aiming
to
win
against
every
hand
tuned
website
in
the
world.
We
just
wanted
to
be
up
there,
and-
and
this
is
really
important-
we
wanted
everyone
to
be
up
there
right
all
amp
documents,
and
this
actually
brings
me
to
a
point.
A
I
don't
think
it's
talked
about
enough,
which
is
that
web
performance
is
biased
right
roughly,
the
smaller
a
website
is
the
less
well
funded.
It
is
the
slower
it
is,
and
I'm
really
really
proud
that
amp
does
not
have
this
bias
very
roughly.
You
know,
obviously,
there's
some
variation
but,
like
I'm
documents,
have
a
quite
uniform
speed,
even
though
there's
huge
diversity
in
how
they
look
and
how
their
experiences-
and
you
know,
I
think
it's
it's
fair-
to
say
that
this
worked
in
terms
of
adoption.
A
There's
now
tens
of
millions
of
websites
using
and
billions
of
pages,
you
can't
count
them,
and
you
also
like
it
doesn't
matter
right
like
it's
a
very
large
number,
so
that's
that's
kind
of
how
how
we
got
started
and
then,
as
it
does,
the
internet
got
mad
at
us
all
right
and
I
actually
want
to
acknowledge
that.
Like
many,
you
know
there's
complaints
and
criticism
about
amp
and
I
actually
personally
agree
with
many
of
them
and
we've
taken
that
to
heart
and
and
worked
of
them
right.
A
I
want
to
broadly
summarize
the
known
issues
that
amp
was
facing
as
one
of
them
being
awkward
urls
on
google.
That
was
largely
based
because
of
the
iframe
based
viewer,
which
created
that
privacy
preserving
instant
loading
and,
on
the
other
hand,
there
was
this
feature
called
top
stories
carousel
on
google
that
relied
on
a
deep
amp
integration
and
thus
was
exclusive
to
amp.
And
you
know,
if
you
didn't
want
to
make
an
amp
page,
you
got
sad
right
and
I
think
that's
that's
really
fair.
A
Now
we
worked
on
these
issues,
but
we
didn't
stop.
There.
Amp
started
like
so
many
open
source
projects
with
this
benevolent
dictator
model,
which
is
awkward
and
weird,
and
apparently
that
was
me,
and
it
certainly
doesn't
represent
all
the
constituencies
of
this,
like
vast,
open
source
project
with
all
these
all
these
stakeholders,
and
so
we
updated
it
to
modern,
open
governance
model,
largely
actually
inspired
by
by
node.js,
who,
I
think
was
in
the
forefront
of
kind
of
rethinking
how
how
open
source
governance
should
work.
A
There's
a
technical
steering
committee,
an
advisory
committee
and
so
forth.
The
second
thing
we
you
know
were
planning
to
do
at
the
time
was
to
bring
this
project,
which
is
you
know,
formally
as
in
copyright
owned
by
google,
into
our
foundation
and
so
last
fall.
It
was
announced
that
the
amp
project
would
join
the
incubation
phase
to
become
a
project
of
the
open,
js
foundation,
and
so
today,
I'm
incredibly
proud
to
announce
that
the
amp
project
has
completed
the
incubation
project
and
is
joining
the
opengs
foundation
as
a
growth
project.
A
There's
actually
one
more
announcement,
which
I'm
extraordinarily
happy
about
just
came
in
literally
today
we
have
a
new
member
in
the
m
technical
theorem
committee,
kasiana
who's
representing
axia's
media,
which
is
one
of
the
you
know,
a
very
important
publisher
in
the
digital
native
space
and
we're
actually
really
happy
to
have
her
because
so
far
on
the
steering
committee,
that's
different
from
the
advisory
committee.
Obviously
we
did
not
have
a
representation
from
publishers
with
platforms
like
pinterest,
twitter,
microsoft,
but
like
there
was
no
publisher
or
presentation.
A
This
is
really
amazing
to
have
her
now
looking
a
little
bit
ahead.
I
think
the
mission
of
continues
to
be
more
important
than
ever.
We
still
see
that
bias
of
web
performance
being
better
for
large
sites
as
a
whole
for
the
web
and
users
also,
you
know,
continue
to
seek
out
the
streamlined
experiences
that
we
find
in
wallet
gardens
now
I
touched
on
this
a
little
bit
earlier.
I
just
want
to
talk
really
quick
about
that.
A
What
google
is
calling
page
experience
signals
and
ranking,
so
this
is
largely
based
on
something
called
core
web
vitals,
which
are
three
metrics
largest
contentful
paid.
First
input
delay
and
cumulative
layout
shift.
Now
these
are
all
metrics
that
went
through
the
respective
working
groups
in
the
w3c,
representing
loading
interactivity,
visual
stability
of
our
websites
and
kind
of
they're,
taking
together
and
they're,
bundled
with,
like
other
signals
like
mobile
friendliness,
safe
browsing
https,
I
don't
think
they're
as
important,
because
nowadays,
most
websites
actually
kind
of
do
okay
on
them.
A
So
it's
really
these
metrics,
which
are
collected
using
a
chrome
user
experience
report
that
drive
these
ranking
factors
right
and
it
doesn't
matter
how
a
website
is
built
technology
is
not
taken
into
account.
It's
just
basically.
What
is
the
user
experiencing?
That's
why
accounting?
And
so
I
would
summarize
that
a
little
bit
like
this,
you
know
basically
google
saying
hey,
we
prefer.
A
If
you
provide
a
good
page
experience,
we
literally
do
not
care
how
you
do
it
and
some
desks
will
say:
cool
I'll
use
x,
my
favorite
framework
and
they're
happy,
but
we
also
know
there's
folks
who
are
going
to
say
yeah,
you
know,
but,
like
some
guidance
would
be
nice
and
you
know
we
want
to
make
amp
to
be.
You
know
the
framework
of
their
choice
if
they
to
choose
right
and
and
again
bring
give
everyone
the
opportunity
to
be
right
there
at
the
top
of
that
web
performance
race.
A
We
want
to
make
amp
the
most
cost,
effective
and
simplest
solution
for
publishers
to
create
great
page
experience
and
we
want
to
match
or
exceed
the
user
experience
that
closed
platforms
provide
and
do
that
by
default,
so
that
without
major
ux
project
for
every
every
single
web
publisher
on
the
web,
we
want
to
unbias
great
page
experience.
We
want
to
provide
good
performance
to
every
website
we're
going
to
provide
good
accessibility
for
every
website.
A
Overall,
great
user
experience-
and
we
want
to
achieve
that,
while
keeping
the
business
goals
of
the
website
owners
in
mind,
because
if
they
aren't
successful,
the
websites
aren't
sticking
around
and
that
would
not
fulfill
our
mission.
That
is
all
I
had
today.
Thank
you
very
much
I'll
be
tweeting
out
a
link
to
a
blog
post
that
has
a
bit
of
a
longer
version
of
amp's
history,
but
this
was
the
10
minute
version.
Thank
you
very
much.