►
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,
I'm
for
those
who
don't
know
me,
I
I'm
known
from
excel
microsoft
and
I'm
going
to
talk
about
how
we
tackle
the
problem.
How
what
is
our
thinking
about
responsiveness
in
the
app
and
we're
gonna?
A
For
those
who
are
not
familiar
so
excel
for
the
web,
it's
the
web
client.
We
have
at
microsoft
for
excel,
you
can
use
excel
in
the
cloud
author
documents
and
so
on.
It
is
an
sba,
it's
a
complex
sphere,
with
lots
of
moving
parts
tons
of
javascript
and
everything
else,
so
that
just
keep
that
in
mind
and
let's
let
me
start
with
what
we're
trying
to
achieve
so
we
we
actually
want
to
improve
interactivity
and
I'm
not
going
to
talk
about
all
aspects
of
interactivity.
A
We
talked
about
some
of
it
yesterday
regarding
animation,
smoothness
and
in
in
your
talk
about
navigation
response
time,
and
I'm
actually
going
to
talk
about
more
immediate
response
so
be
before
we
do
that
just
want
to
share
what
we're
currently
using
the
the
apis
that
we
have
we're
relying
on
long
task
api.
A
So
we
can
measure
long
javascripts
and
the
main
downside
for
that
approach
is
that
it's
hard
to
get
attribution,
what
actually
causing
long
tasks
and
also
it's
hard
to
to
determine
the
actual
user
experience
in
terms
of
when
things
got
rendered.
It's
only
about
javascript
task
execution.
A
The
second
approach
that
is
commonly
used
is
using
request,
animation
frame
loop,
the
challenge
here
that
there
are
actually
several
challenges
listed,
I'm
not
going
to
go
over
all
of
them,
but
I
think
the
the
main
problem
with
this
approach
is
that
it
does
not.
It's
only
triggered
we
to
conserve
user
battery
and
cpu.
A
So
we
start
thinking
about
what
are
the
goals
for
responsiveness
metric
if
you're
trying
to
define
it
or
articulate
it,
and
we
want
to
be
as
accurate
as
possible
and
stable,
so
it
would
not
fluctuate
and
we
want
to
be
able
to
use
it
for
regression.
Detection
know
what
is
the
responsiveness
of
specific
user
user
action
and
not
just
any
random
user
input
in
our
app
one
use
it
as
an
metric.
So
we
can
use
inside
the
organization
as
an
internal
metric,
so
we
can
follow
it
and
and
so
on.
A
A
A
A
It's
essentially
the
next
frame
and
some
people
can
see
it's
already
aligned
pretty
well
with
event
timing
and
the
last
definition
is
responsive
user
action,
which
essentially
is
and
every
user
action
that
has
a
response
time
with
that's
below
100
millisecond,
because
above
that
user
starts
feeling
lag
in
the
ui
and
that's
just
an
illustration
what
we
mean
with
response
time,
for
example,
clicking
doing
like
mouse
down
on
a
grid.
So
after
less
than
100
milliseconds,
we
want
to
show
the
selection
of
where
the
user
clicked.
A
The
start
time
indicates
when
the
user
does
the
input
and
the
full
duration
is
actually
the
response
time
that
we
are
interested
in
measuring
and
there
are
several
other
parts
when
we
using
event
timing,
we
can
determine
the
input
delay
based
on
the
processing
start,
and
we
can
turn
we
can
determine
how
long
it
took
the
event
handlers
to
process,
and
we
know
there
is
a
remaining
time
that
other
async
tasks
and
the
rendering
can
happen,
and
that
impacts
the
full
response.
Time.
A
The
apis,
what
we're
using
is
the
performance
of
server
observer.
We
observe
the
events
with
400
millisecond
responses
and
I'd
like
to
pay
attention
to
an
important
aspect
of
the
spec,
which
we
take
advantage
of
for
this
and
notice
that
the
performance
timing,
entry
has
a
start
time
which,
according
to
the
spec
associated
to
the
event
timestamp,
which
is
when
the
user
input
actually
happened.
A
So
how
we
take
advantage
of
that
fact
for
every
user
action
that
we're
interested
in
measuring,
we
use
add
event
listener
with
the
event
in
this
example,
some
element,
and
then
we
call
like
a
global
function
that
we
created
pass
it
the
event
and
a
string
that
represents
the
user
action.
Now.
A
The
challenge
here
that
we're
trying
to
address
is
how
to
correlate
between
the
user
action,
which
is
represented
by
the
event
and
the
string
and
the
performance
event
timing
entry,
and
we
do
that
by
storing
the
events
in
a
map
using
the
the
event
type
and
timestamp
as
keys,
and
we
just
store
the
user
action.
This
is
a
actually
a
simplification,
what's
actually
happening
behind
the
scene,
but
it's
sufficient
for
for
the
explanation.
A
Now,
when
we
process
the
event
timing
entries
in
the
observer
callback,
we
basically
match
the
entry
start
time
with
the
event
timestamp
that
we
got
and
we
also
can
match
the
the
event
type
and
or
even
aim.
A
Yeah,
so
that's
about
that
and
after
that
we
can
log
the
information
and
inaugurate
it
and
update
any
counters
that
we'd
like
to
report
on
and
that's
maybe
an
example
of
of
a
simplified
log.
We
have
for
every
action.
We
have
some
total
count
of
how
many
times
the
action
happens
and
how
many
slow
actions
we
detected.
A
So
now
that
we
have
this
metric
for
or
this
measurement
of
slow
actions,
it's
not
really
a
responsiveness
metric.
We
can
rate
our
app.
So
we
start
by
defining
what's
a
responsive
session
and
we
took
a
definition
of
90.
Of
all
actions
in
a
session
are
responsive.
I'm
not
going
to
go
into
what
a
session
means,
it's
probably
specific,
to
any
app
how
they
define
what
a
user
session
is.
But
essentially
it's
a.
I
guess,
a
certain
flow
that
the
user
interacts
with
the
application.
A
So,
and
I
put
an
example-
chart
that
you
can
see
that
what
we
found
that
the
using
this
responsive
metric
is
very
stable
and
it's
sensitive
enough
to
detect
any
regression
when
you
introduce
new
codes
or
other
aspects
of
changes
to
your
application,
and
we
are
working
towards
making
this
like
an
official
responsiveness
metric
in
the
app.
A
I'd
like
to
talk
a
bit
about
the
challenges
we
have
and
some
of
them
I
some
of
them
may
some
of
you
may
have
noticed
them
them,
and
this
is
a
list
that
probably
not
gonna
go
over
all
of
them,
but
the
list
here
is
by
order
of
importance
based
on
my
thinking
and
the
hardest
part
with
this
api
is
integrated
as
you
notice.
A
The
integration
is
manual
you
have
to
for
each
event
handler
inject
a
javascript
call
to
a
function,
and
you
want
to
ensure
that
when
developers
inject
it
or
add
this,
it's
added
to
a
synchronous
part
of
the
event
handler.
So
if
the
event
handler
is
calling
an
asynchronous
part,
it's
not
guaranteed
that
the
tracking
would
happen
as
part
of
the
the
same
frame
right,
because
the
the
callback
could
run
later.
A
Some
idea
is
oh
and
another
thing:
is
you
want
to
make
sure
that
it's
inside
an
event
handler
that
actually
modifies
the
dom
or
part
of
the
process?
It
could
be
other
event,
handlers
that
modify
the
dom
as
part
of
the
sequence
and
that's
fine,
but
it
shouldn't
be
as
part
of
any
event
handler
that
doesn't
cause
any
any
flow
of
event,
handlers
that
doesn't
cause
any
dom
modification,
because
that
means
we're
not
really
measuring
the
response
time.
A
I'm
thinking,
maybe
we
can
add
if
there
is
an
option
to
add
some
indication
about
the
dom
status
that
might
help
to
determine
that,
but
I'm
not
sure
if
that's
the
best
approach.
The
second
hardest
problem
is
how
we,
how
would
we
correlate
the
dom
input
events
with
the
event
timing
entries?
Ideally,
we
wouldn't
have
to
do
that.
Ideally,
it
would
be
able
to
just
track
the
user
actions
somehow
and
then
immediately
without
storing
it
or
doing
some
complex
matching
logic
know
what
the
responsiveness
of
that
input
user
input.
A
Some
ideas
here
is
maybe
adding
some
event
id
that
either
auto
generated
or
can
be
set
somehow
to
both
dom
event
and
performance.
Timing
event:
timing,
entry.
Another
idea
that
would
eliminate
the
need
for
doing
like
a
function
call
is
using
maybe
tags
on
the
dom
event
that
would
propagate
somehow
to
the
event
timing.
A
Entry,
I
don't
know,
maybe
there
are
other
ideas,
other
challenges,
the
the
event
timing,
api
doesn't
support
scroll,
yet
not
in
the
spec
and
not
in
any
implementation,
and
that
has
been
discussed
previously.
A
A
So
once
we
have
an
indication
of
a
slow
response,
it's
not
always
clear,
not
what's
blocking
now,
if
it's
input
delay,
we
know
it's
blocked
by
maybe
some
tasks,
we're
not
sure.
If
it's,
we
know
if
it's
a
long
event
handler
processing
time,
but
we
don't
know
what
comes
after
that.
Is
it
like
a
lot
of
async
javascript
tasks?
Is
it
gc?
Is
it
rendering
complexity
that
takes
a
lot
of
time,
yeah
and
and
so
on?
A
So
any
more
attribution
or
indication
of
what's
actually
causing
the
gaps
that
are
not
exposed
with
event?
Timing
would
be
helpful.
A
A
A
We
also
thinking
about
integrating
with
the
js
self-profiling
that
has
been
recently
released
in
chromium
and
cross
the
event
timing
entries
with
records
we
get
from
just
self-following,
so
we'll
get
full
attribution
and
allow
us
to
do
root,
cause
analysis
on
slow
response
response
time,
events
and
last,
but
not
the
least,
is
be
happy
if
other
vendors
would
have
a
full
support
for
event,
timing
pi,
so
we
could
have
better
coverage
for
all
our
clients.
A
That's
all
I
had
if
I
have
thoughts
or
questions
comments
or
if
you
want
to
follow
up
in
more
details,
I'll
be
happy.
If
you
can
reach
out
that's
what
I
had.