►
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
Okay,
so
topic
for
today
is
element
timing
and
shadow
dom.
My
name
is
emea.
I
am
a
web
engineer
at
microsoft.
I
joined
the
working
group
a
few
months
ago.
This
is
my
first
tpack
today's
topic.
I
want
to
revisit
sort
of
an
older
issue,
that's
been
discussed
in
the
past,
but
I
just
wanted
to
share
some
of
my
observations
and
pain
points
related
to
element
timing
when
it's
used
in
conjunction
with
shadow
dom.
A
So
before
element
timing
existed.
You
know,
web
developers
really
had
no
direct
way
to
observe
when
elements
of
their
page
were
painted
to
the
screen,
and
you
know
that's
really
important,
for
you
know-
measuring
perceived
performance
as
as
experienced
by
your
end
users,
but
you
know
web
developers.
A
Aren't
you
know,
they're
they're
they'll
always
look
for
workarounds
right,
so
there
were
hacky
sort
of
approximations
that
existed
and
been
used
for
a
long
time.
So,
if
you
were
trying
to
observe
when
an
image
is
painted
to
the
screen,
you
might
use
the
resource
timing,
api
or
a
load
handler.
That's
on
the
image
tag.
A
The
downsides
with
these
approaches-
they're
not
totally
accurate,
they're,
not
measuring
when
the
image
actually
paints
to
the
screen,
they're
actually
measuring
when
the
network
activity
was
over
in
the
case
of
resource
timing
or
when
the
load
handler
fires,
which
probably
doesn't
coincide
exactly
with
when
that
image
actually
shows
up
on
the
screen.
A
A
One
one
approach
was
to
have
an
inline
script
marker,
a
perf
marker,
that's
scheduled
inside
a
combination
of
a
request,
animation
frame
plus
set
timeout,
and
there
are
some
other
flavors
of
this
approach
as
well
request,
animation,
frame,
plus
request,
animation
frame
or
request,
animation
frame,
plus
there's
some
other,
which
is
there
that
that
were
used,
and
that
would
basically
the
tell
the
browser
to
record
a
performance
marker
at
the
next
frame,
basically
after
the
current
frame
has
completed
so
that
approximates.
A
When
you
know
a
given
chunk
of
markup
has
painted
to
the
screen
the
downsides
with
this
again.
This
is
not
totally
accurate.
This
would
tend
to
over
report
the
number,
as
opposed
to
the
prior
cases,
where
they
would
under
report
and
there's
also
a
bit
of
an
observer
effect,
because
just
in
simply
including
a
script
tag
in
line
in
the
page
to
do
this,
instrumentation
can
actually
change
the
the
actual
rendering
behavior
of
the
browser,
so
the
browser
might
induce
paints.
A
Given
the
existence
of
that
script,
tag
that
may
not
have
otherwise
happened.
So
you
know
this.
This
could
change
the
behavior
of
the
page
when
you're
just
trying
to
observe
it
and
the
element.
Timing.
Api
was
great
because
it
fixed
all
of
this.
It
added
a
declarative
way,
for
you
know
web
developers
to
observe
when
specific
elements
had
been
painted
to
the
screen.
A
So
so
that
was
a
great
you
know,
step
forward
and
just
to
illustrate,
I
I
built
a
couple
of
pages.
So
these
these
pages
look
basically
identical
and
I've
shared
the
links
here.
One
one
page
is,
you
know
just
a
really
simple
page
and
h1
a
paragraph
and
an
image.
That's
that's
really
big,
so
that
sort
of
forms
a
long
pole
and
the
source
is
is
shared
over
here.
So
I
have
a
performance
observer
that
is
just
looking
for
element,
timing,
events
and
it'll
it'll,
basically
do
a
console
log.
A
Every
time
an
element,
timing
event
is
is
fired
and
I
have
element
timing
set
up
for
each
of
the
tags.
So
there's
an
element:
timing
for
the
h1
that
just
logs
in
h1
string,
there's
there's
one
for
the
p
and
there's
one
for
the
the
img
element
as
well.
So
so
each
each
of
these
fires,
its
own
element,
timing
event,
and
then
I
have
the
same
page,
also
implemented
with
shadow
dom
where
the
the
image
is
actually
implemented.
A
As
as
a
shadow,
dom
image
as
a
shadow
element
and
the
the
h1np
tags
are
the
same
and
I've
added
an
element.
Timing
attribute
to
the
outer
div,
which,
which
contains
the
shadow
dom
but
doesn't
contain
any
additional
content,
and
I
also
have
an
element
timing
attribute
here,
which
is
inside
the
the
shadow
element
and
what
what
you'll
see
if
you
open
these
up
is
in
the
case
of
the
no
shadow
dom
page,
you
get
these
three
events,
the
h1,
the
p
and
the
img.
A
They
all
fire
their
own
element,
timing,
events
and
typically
the
the
img
one,
is
the
last
to
arrive,
because
it's
an
external
image,
it's
pretty
big,
so
that
number
is
higher
than
these
others
and
over
here.
If
you
load
up
the
page
with
the
shadow
dom
it
will
not
fire
element.
Timing
events
I
neither
for
the
outer
div
nor
for
the
img.
So
so
this
is
a
limitation
of
you
know.
A
If
you're
trying
to
implement
a
page
that
contains
shadow,
dom
elements,
web
components
you're
not
able
to
observe
the
the
performance
of
of
that
page.
A
Going
back
to
the
slides
so-
and
there
have
been
prior
discussions
about
this,
this
is
this
is
not
something.
This
is
that's
a
new,
but
I
just
you
know
I
just
wanted
to
bring
this
discussion
up
again
and
hopefully
move
move.
This
forward,
get
it
to
a
place
where
we
can
have
this
implemented.
A
There
have
been
some
prior
discussions
that
the
gist
of
it
is
that
the
behavior
is
sort
of
by
design,
given
that
shadow
dom
is
isolated
from
the
rest
of
the
page,
so
the
rest
of
the
page
can't
really
observe
you
know
what's
going
on
in
the
shadow
dom,
but
but
there
have
you
know,
there's
there
was
a
case
being
made
for
a
you
know,
an
element
being
able
to
opt
into
being
observed.
A
So
you
know
if
some,
if
a
web
developer
is
writing
a
component
using
shadow
dom,
they
should
be
able
to
opt
in
so
that
the
parent
page
could
still
measure
when,
when
that
element
showed
up
on
the
screen,
for
example.
A
So
what
what
are
the
implications
of
this?
As
I
mentioned
so
shadow,
dom
elements
cannot
use
the
element.
Timing,
api,
which
is
which
is
a
bummer.
You
know
we
we
had
this,
this
great
new
feature
implemented
and
now
we're
not
able
to
use
this.
I
know
of
one
one
case
where
on
for
msn.com,
they
were
moving
from
react
to
web
components
and
the
the
react
pages
did
use
element
timing
successfully
to
measure
when
certain
critical
elements
showed
up
on
the
page
and
they
had
to
take
a
step
backwards.
A
So
they
had
to
go
back
to
using
sort
of
the
prior,
more
hacky
techniques
that
I
discussed
earlier
so,
which
was
an
unfortunate
side
effect
of
the
the
migration
to
web
components
there
and
the
other
case
you
know
I
just
I
just
ran
web
page
test
against
those
two
pages
that
I
built,
and
so
so
lcp
still
does
capture
the
the
shadow
dom
element.
A
So
it's
kind
of
a
mismatch
between
these
two
sort
of
approaches
so
that
you
know
lcp
is
sort
of
a
a
built-in
approach
where
the
the
browser
just
gives
you
this
this.
This
metric,
which
you
know
it's,
sort
of
a
one-size-fits-all
approach
to
measuring
the
perceived
visual
performance
of
a
page,
and
so
you
know
so
lcp
does
capture
that
that
image
I
can.
I
can
pull
up
the
I
don't
have
okay,
I
have
the
links
here.
A
So
in
this
case
this
is,
let
me
pull
up
the
page
with
no
shadow
dom
first,
and
you
can
see
the
lcp
is
about
1.3
seconds
and
it's
it's
clearly
waiting
for
for
that
big
image
to
come
down,
which
is
which
is
the
long
pole
in
the
waterfall
and
so
that
the
lcp
is
recorded
as
1.3
seconds
here,
and
the
same
is
the
case
in
for
the
page
with
shadow
dom.
So
again,
the
lcp
is
is
1.3
seconds
here.
A
So
it
seems
like
a
bit
of
a
mismatch
between
these
two
approaches
where,
if
you're,
if
you're,
using
the
the
more
declarative
approach,
you're
you're
missing
out
on
the
ability
to
to
measure
specific
components
on
the
page,
although
if
you
use
the
lcp
approach,
you
are
accounting
for
that
performance,
so
yeah.
I
wish
that
element.
Timing
was
able
to
to
handle
this
as
well,
so
yep.
So
that's
what
I
had
to
you
know
to
present
today
but
happy
to
open
it
up
for
discussion.