►
From YouTube: TPAC WebPerfWG 2021 10 27 - Optimizing 3P script loading
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
Awesome
seems
like
your
recording
is
starting
yeah,
so
we'll
pick
things
up
today,
we
wanted
to
discuss
third-party
script
loading.
This
is
a
really
complex
space,
with
many
dimensions
to
it.
That
is
one
that
has
impacted
web
performance
for
over
a
decade,
and
so
today,
pat-
and
I
would
like
to
discuss
a
few
ideas
for
incrementally
improving
this
from
both
the
web
platform
and
browser
side.
Before
we
go
into
ideas,
it's
probably
useful
to
just
level
set.
You
know
about
what
we're
talking
about
here.
A
So
what's
the
problem
with
loading
performance
there's
about
three
top
level
problems,
every
resource
has
to
be
optimized
for
performance,
so
everything
from
scripts
fonts,
css
images.
A
lot
of
folks
on
this
call
dealt
with
these
problems
before
second
problem
is,
we
have
quite
a
few
difficult
scheduling
and
ordering
problems
that
span
the
network
and
the
client.
A
You
know
these
types
of
problems
can
speak
to
the
right
ordering
for
resources
that
are
first
party
versus
third-party
resources
that
might
be
getting
injected
into
the
page
by
you
know
your
cms
or
the
platform
that
you're
on
effective
pipelining
and
then
the
third
problem
is
that
third-party
scripts,
just
generally
add
randomness
to
an
already
precarious
loading
sequence.
I
also
wanted
to
thank
should
be
panicker
for
this
fight.
A
So
what
do
we
mean
by
third-party
scripts?
This
is
a
very
big
bucket
of
stuff,
so
it's
everything
from
analytics
scripts,
cdn
scripts
customer
success,
help
desk
widgets
video
players.
Folks
may
be
embedding
is
their
pages
marketing
tag
managers
there
there's
a
lot
that
goes
into
the
wild
west
that
are
third-party
scripts,
but
we're
typically
talking
about
this
large
category
of
things
that
are
not
necessarily
owned
by
the
first
party
that
are
including
them
into
their
site.
A
I
wanted
to
call
out
we
we
have
been
doing
quite
a
bit
of
research
on
the
chrome
side
into
third
parties
for
the
last
couple
of
quarters
and
most
studies
that
we've
done
whether
they
are
via
developer
surveys
or
via
quantitative
analysis.
A
You
know
lab-based
cert
analysis
and
so
on
is
shown
that
optimizing
third
parties
remain
one
of
the
top
challenges
for
sites
that
want
to
do
well
on
performance
and
want
to
do
well
on
metrics,
like
the
core
web
vitals,
we've
historically
seen
that
every
year,
a
large
percentage
of
javascript
execution
on
the
whole
across
the
web
does
tend
to
be
third-party
code
and
there's
a
lot
of
just
general
nuance
to
this
problem
space.
So
it's
a
multi-headed
problem,
and
these
are
only
some
of
the
issues
with
it.
The
first
is
goals.
A
There
are
sites
who
may
care
a
lot
about
user
experience,
and
they
may
also
care
about
business
outcomes.
People
struggle
to
understand
like
how
to
balance
those
two.
If,
if
we're
making
you
know,
people
are
making
a
lot
of
revenue
by
having
certain
third
parties
on
their
sites,
they
may
have
a
harder
time
justifying
you
know
putting
time
into
the
user
experience
benefits
of
maybe
deferring
those
third
parties,
but
ultimately,
like
the
goals,
don't
always
align
the
next
one
is
metrics.
A
Do
sites
have
sufficient
insight
into
costly
third
parties?
We've
been
having
lots
of
great
discussions
with
yoaf
over
the
last
year
about
whether
we
should
be
increasing.
You
know,
signals
and
resource
timing
about
bite,
size,
visibility,
improving
long
task
attribution
or
improving
visibility
into
iframe
activity.
There
are
organizational
issues
here.
Very
often
the
audiences
that
are
introducing
costly
third
parties
may
not
be
performance
experts.
A
They
may
not
even
be
engineers,
it's
very
often
folks,
who
are
in
marketing
or
business
stakeholders
who
are
using
a
tag
manager
to
inject
third
parties
into
the
pages
pretty
often
working
around
the
engineering
teams.
So
it
can
end
up
being
a
little
bit
of
a
blind
spot.
Then
we've
got
ecosystem.
A
Our
third
party
is
incentivized
to
care
about
their
footprint.
Some
some
very
much
are
some
are
not
another
issue
here
is
that
latency
can
a
bore
vacuum
so
well-behaved
third
parties
may
end
up
freeing
up
the
main
threads.
Does
that
encourage
others
to
fill
the
void
and
there's
more
that
we
could
possibly
be
doing
on
the
web
platform
side?
A
Giving
developers
sufficient
knobs
to
you
know,
get
more
control
over
this
problem
and
via
developer
tooling,
so
making
sure
that
site
owners
have
got
enough
attribution
in
the
lab
and
enough
actionability
to
improve
things.
A
So
we're
going
to
talk
about
two
dimensions
to
this
problem
space
today,
pat,
is
going
to
kick
us
off
talking
about
resource
ordering
and
a
little
bit
more
about
what
we
could
be
doing
on
the
platform
side,
and
then
I'm
going
to
be
talking
a
little
bit
about
a
few
ideas
for
what
we'd
be
doing
on
the
browser
side
to
improve
the
defaults
for
folks
who
are
using
third
parties.
B
Sure
he
flipped
the
next
slide
and
next
slide.
So
I
mean,
as
addie's
mentioned,
getting
the
order
right
can
have
a
huge
impact
on
performance.
I
mean
I,
I
remember,
studies
going
back
close
to
2010
2011
or
so
when
we
were
working
on
page
speed
service,
where
phd
grads
were
doing
under
studies
about
like
cutting
the
load
times
in
half.
If
you
could
predict
the
the
perfect
order
to
deliver
the
resources
in
and
so
a
lot
of
chrome
work
has
been
going
around.
B
How
can
we
do
that
automatically
and
more
recently,
a
lot
of
work
in
the
webproof
working
group
has
been.
What
can
we
do
to
give
devs
the
knobs?
They
need
to
try
and
get
closer
to
that
optimal
ordering
on
the
delivery
side
of
things
at
least
the
most
basic
lever
we've
always
had
is
sort
of
reordering
things
in
the
html
moving
your
blocking
scripts
to
the
end
of
the
body.
B
It's
kind
of
one
of
steve's
original
rules,
right,
async
and
defer
for
scripts,
has
been
added
to
some
levels
of
success,
unblocking
the
parser
but
less
control
over
the
loading
and
execution
of
when
those
things
happen,
lazy
loading
for
images
and
iframes
in
particular.
If
you
happen
to
be
doing
a
straight
up,
embed
iframe,
but
if
you're
doing
it
through
scripts,
you
have
a
lot
less
control
over
it
and
then
some
of
the
sort
of
hinting
to
the
browser
for
the
things
that
it
can't
discover
with
dns
prefetch
preconnect
preload.
B
Hopefully
now
it
can
actually
be
used
and
then,
if
you
want
to
go
on
to
the
next
slide,
some
of
the
things
that
are
more
in
flight
right
now,
at
least
on
the
chrome
side.
We're
experimenting
with
priority
hints
to
hopefully
give
you
some
more
knobs
to
indicate
which
scripts
are
more
important
for
your
user
experience
to
hopefully
tweak
that
order
around
a
little
bit,
which
images
are
more
important.
Should
some
images
be
more
important
than
blocking
scripts
or
not
and
sort
of
that?
That
thing
that's
hard
to
get
automatically
right
all
of
the
time.
B
Our
hope
is.
We
can
give
developers
explicit
controls
that
we
don't
rely
on
on
sort
of
autumn,
automated
heuristics
at
a
protocol
level.
Http
2
was
sort
of
the
first
one
where
we
had
priority.
Support
of
some
kind,
wasn't
greatly
supported
or
implemented.
B
Hopefully,
that's
changing
with
http
3,
although
the
priority
support
is
an
extension,
it's
not
part
of
the
core
protocol
and
protocol
level.
Prioritization
doesn't
work
across
origins,
so
it
doesn't
really
help
a
whole
lot
with
third
parties
and
that's
kind
of
one
of
the
things
that
we
had
to
back
away
from
after
launching
http
2
originally
was
you
know
when
you
have
10
different
origins,
all
serving
content
in
parallel
and
each
one
can
only
prioritize
within
itself.
B
You
still
need
some
level
of
orchestration
across
all
of
those
origins,
and
so
we're
kind
of
almost
back
to
http
1.1
world
of
trying
to
do
pull
scheduling
on
the
client
side.
Early
hints
is
in
experiments
right
now,
as
well,
just
sort
of
another
way
to
do
preload,
pre-connect
all
of
that
kind
of
stuff.
Earlier
in
the
process,
is
there
anything
on
the
loading
side
of
things
that
we
don't
know
yet
that
you
won't
like?
B
Is
there
something
missing
from
being
able
to
explicitly
define
an
order?
If
you
happened
to
know
the
proper
order
ahead
of
time,
and
sometimes
like
the
first
party
site,
won't
know
what
the
third
party
resources
are
going
to
load
like
even
google
fonts,
for
example,
you
know
what
css
you're
going
to
load.
You
may
not
know
the
actual
font
file,
that's
going
to
be
loading,
and
so
you
can't
hint
at
that.
B
You
can
pre-connect
and
maybe
try
and
warm
things
up
if
we
go
to
the
next
slide-
and
this
is
just
on
the
loading
side,
I
mean,
we've
noticed
with
async
in
particular,
control
over
execution
of
the
scripts
has
been
sort
of
problematic
async
running
the
script
whenever
it
happens,
to
load,
ends
up
running
and
blocking
the
main
thread.
B
When
you
happen
to
try
doing
critical
user
interactions,
for
example,
one
of
the
things
we've
sort
of
been
playing
with
a
little
bit
does
preloading
the
script
and
then
the
onload
handler
determining
if
it's
a
good
time
to
insert
the
actual
script
tag
dynamically
may
give
you
some
level
of
control.
B
Don't
run
this
async
script
until
after
x
event
and
what
are
those
x
events
and
are
they
something
the
browser
can
actually
know
about
next
slide
and
then
rendering
it's
sort
of
one
of
those
black
boxes
right
now,
everything
in
the
head,
that's
blocking,
is
definitely
render
blocking
a
b
scripts
anti-flicker
snippers
kind
of
the
bane
of
our
existence,
particularly
with
lcp,
especially
if
you've
got
an
a
b
test.
That's
not
actually
doing
anything,
but
you
block
rendering.
B
Is
there
something
we
need
to
do
declarative
or
to
provide
more
controls
over
when
the
browser
should
be
rendering
the
first
content,
safari
and
chrome
have
very
different
views
about
incrementally
displaying
content,
as
it
arrives,
versus
trying
to
provide
as
much
parsing
and
content
at
at
the
first
render
event,
for
example,
do
devs
need
more
control
over
that?
B
I
think
that's
it
on
the
sort
of
where
we
are
on
dev,
knobs
and
problem
set
spaces,
and
it's
kind
of
a
a
across
a
lot
of
things,
we're
hoping
giving
devs.
If
we
can
find
that
we
have
all
of
the
atomic
controls
for
devs
to
be
able
to
do
exactly
the
ordering
that
they
would
want
to
get
the
optimal
experience.
B
A
Thanks
pat
so
we
talked
about
you
know
for
folks
who
are
potentially
incentivized
to
reduce
the
impact
that
third-party
scripts
can
have
on
their
overall
performance
and
have
the
experience.
How
can
we
give
them
sufficient
knobs
for
folks
that
are
incentivized
but
may
not
have
sufficient
experience?
What
are
other
things
that
we
potentially
be
doing
to
help
hear
from
the
browser
side
of
things
ideally
to
intervene
on
behalf
of
users
to
help
the
situation?
A
Now,
if
we're
talking
about
intervening
or
you
know,
changing
the
defaults
in
some
way,
we
often
end
up
talking
about
interventions.
So
what
is
an
intervention?
A
An
intervention
is
often
a
user
agent
intervention,
where
the
browser
opts
for
an
intentional
deviation
from
behavior
that
developers
might
expect
or
rely
on,
and
it's
often
motivated
by
the
desire
to
fulfill
an
important
user
need.
Interventions
are
historically
something
that
browsers
have
invested
in,
but
they're
also
not
risk-free,
and
very
often
carefulness
is
a
key
part
of
thinking
about
whether
or
not
intervention
should
be
applied,
and
so
I
want
to
stress
that,
for
this
section,
we're
really
talking
about,
especially
for
sites
who
are
interested
in
reducing
the
impact.
A
Third
parties
can
have
on
their
performance.
How
can
we
help
them
out
a
little
bit
more?
The
interventions
have
successfully
improved
user
experience.
In
many
cases.
Over
the
years
we've
seen
interventions
being
used
across.
You
know
passive
touch
event,
listeners
throttling
timers
that
are
out
of
view
in
different
iframes
throttling
the
rendering
pipeline.
A
If
you
know
frames
or
particular
parts
of
the
page,
are
not
necessarily
visible
a
throttling
expensive
timers
that
are
in
frames,
we've
seen
quite
a
few
of
these
play
out
over
the
last
number
of
years
to
varying
degrees
of
success,
but
especially
where
we're
able
to
identify
a
very
specific
pain
and
the
situations
where
it's
just
really
difficult
to
get
this
right.
I
think
that
there
is
a
case
to
be
made
that
maybe
the
platform
could
be
helping
people
improve
their
performance
and
user
experience
at
scale.
A
If
we
can
get
this
right,
so
I
wanted
to
cover
two
examples:
things
we
could
potentially
do.
Pat
talked
about.
You
know
knobs
earlier
and
mentioned
loading
equals
lazy.
A
lot
of
our
focus
around
loading,
equals
lazy,
has
been
images
and
addition
initially
iframes,
and
for
folks
who
are
incentivized
to
use
them.
They're
they're,
seeing
some
success.
A
There
is
a
case
to
be
made
that
maybe
embeds
that
are
off
screen.
You
know
think
of
video
players
that
are
much
lower
down
in
a
blog
post
or
on
a
recipe
site.
Do
this
really
need
to
be
eagerly
loaded?
Maybe
not
we've
done
a
few
initial
experiments
to
understand.
You
know
what
is
what
is
the
potential
performance
improvement?
A
We
can
see
here
a
lot
of
this
done
in
the
lab
rather
than
field,
but
we've
seen
some
significant
improvements
in
some
cases
to
total
blocking
time,
as
well
as
significant
improvements
to
data
savings
when
we're
only
loading
embeds
when
a
user
scrolls
closer
to
them.
So
that's
one
potential
intervention,
a
browser
could
explore
lazy
loading
iframes.
A
Ladies
lazy
embeds,
that
are
off
screen.
Another
potential
idea
we
have
is
being
able
to
identify
third
parties
that
are
slightly
less
critical
in
the
page.
So,
as
a
reminder,
earlier
we
mentioned
that
third
parties
are
responsible
for
57
of
script
execution
on
the
web.
They
can
impact
interactivity,
but
we
also
know
that
this
is
very
nuanced.
A
Sometimes
you
might
have
scripts
for
social
media
sharing
live
help
or
you
know
even
a
b
testing
or
personalization,
and
sometimes
these
scripts
are
actually
really
important
for
the
critical
rendering
path
and
what
gets
rendered
for
users
early
on,
sometimes
they're
not,
and
so
you
can't
arbitrarily
throttle
everything
that
isn't
first
party
what
you
can
potentially
do
is
targeted
throttling
so
defining
a
set
of
heuristics
and
signals
that
indicate
if
a
script
may
be
safe
to
throttle.
A
So
there
are
a
few
potential
ideas.
I'll
take
questions
very
soon.
There
are
a
few
potential
ideas
here
for
how
one
could
go
about
identifying.
What
is
less
critical
is
the
third
party
script
included
at
the
bottom
of
the
document
versus
the
head?
Has
it
initiated
long
tasks
that
exceed
a
certain
budget?
A
Is
it
loaded
but
never
used?
Is
it
fetched
after
lcp?
Does
it
have
a
long
request
chain
with
gaps
between?
You
know,
different
requests
that
are
being
made?
There
are
a
lot
of
potential
signals
that
somebody
could
use.
This
is,
of
course,
a
place
where
additional
developer
annotation
could
also
help,
and
that
speaks
a
little
bit
going
back
to
what
pat
was
saying
about.
Priority
hints
and
additional
signals
I'll
pause
there
before
moving
on,
I
think
aaron.
You
maybe
had
a
question
first
and
here
yeah.
C
From
a
recording
perspective,
it's
better
to
take
questions
at
the
end.
Okay,.
A
All
right
we'll
be
wrapping
up
slides,
then
very
soon.
So,
in
terms
of
you
know,
what
are
the
opportunities
here?
One
thing
we've
been
doing
is
working
with
a
few
partners
just
to
understand
you
know
if
you
were
taking
a
look
at
optimizing,
your
third-party
script
loading.
Could
you
see
significant
improvements
to
key
performance
metrics,
whether
it's
in
the
field,
whether
it's
in
the
lab
and
to
what
extent?
If
any,
could
you
see
business
outcome
improvements
off
the
back
of
that,
and
so
these
are
anonymized
partners.
A
We
can
share
around
case
studies
with
folks
interested
in
learning
more,
but
for
these
partners
we've
seen
improvements
in
lcp
improvements
in
core
vitals
pass
rates
and
better
tti,
in
addition
to
business
outcome
improvements
across
the
board,
that's
not
to
say
that
this
is
a
simple
problem
space
and
that
interventions
are,
you
know,
an
easy
way
to
get
get
these
kinds
of
wins,
but
I
do
think
it
shows
that
there
is
potentially
appetite
in
the
ecosystem
and
also
some
room
to
be
able
to
do
this
without
impacting
business
outcomes
in
a
negative
way.
A
So
how
do
we
optimize
for
for
no
surprise
and
make
sure
that
if
we
were
exploring
these
ideas
around
interventions,
we
weren't
surprising
developers
well
with
a
lot
of
these
ideas?
The
goal
would
be
to
do
as
much
of
this
development
in
public
on
extended
timelines,
so
researching
prototyping
and
outline
the
developers
in
public.
How
are
we
thinking
about?
You
know
deciding
on
heuristics?
How
are
we
thinking
about
lazy,
looting,
end
dates.
All
of
these
ideas
would
need
to
be
validated
in
production
in
a
way
that
could
get
us
back
like
real
field.
A
Data
from
production
sites
make
sure
that
people
are
actually
seeing
good
improvements
and
potentially,
if
we
were
able
to
build
enough
confidence
in
these
ideas,
maybe
there's
an
argument
to
be
made
about
shipping
a
new
default
and
iterating
on
it,
but
on
the
whole,
I
think
that
there
is
something
to
be
said
about
considering
the
role
that
interventions
could
play
in
helping
those
who
are
interested
in
improving
their
performance,
where
third
parties
are
maybe
hurting
them
a
little
bit,
but
may
not
have
as
much
experience
to
actually
be
able
to
take
control
of
that
situation.
A
So
that's
that's
it
for
the
slides.
I'd
love
to
you
know,
pause
there
and
take
questions.
We've
got
our
own
and
down.