►
From YouTube: WebPerfWG call 2021 09 30 - Landing navigations
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,
yes,
I
wanted
to
talk
about
landing,
navigations
and
exposing
that
to
rum.
A
So
the
reason
I
started
to
look
into
that
is
that
I
started
to
dig
into
sbas
and
mpa
so
single
page
apps
and
multi-page
apps
and
looking
at
their
performance
along
with
michael
here,
and
what
we
noticed
is
that,
in
terms
of
performance
characteristics,
we
have
two
very
distinct
types
of
navigations.
A
We
have
landings
and
like
what
we
call
landings
and
follow-ups.
So
landings
is
something
that
we
define
as
a
first
navigation
in
a
browsing
session.
A
That's
the
browsing
session
is
an
html
concept
that
defines
the
set
of
essentially
the
session
history
that
happens
inside
a
tab
and
it
very
much
correlates
with
what
we
define
as
a
landing,
so
either
cross-origin
navigation
or
a
navigation
where
the
user
arrived
at
the
at
the
page,
from
a
different
origin
or
a
navigation
that
was,
for
example,
open
in
a
new
tab
and
one
distinct
characteristics
of
those
navigations
is
that
they
cannot
be
developer
intercepted.
A
So
that
essentially
means
that
at
least
at
the
moment,
and
when
we're
looking
at
mpas
and
spas,
spas
only
have
landing
navigations.
At
least
for
the
sva
part
of
the
of
their
site
and
mpas
have
a
mix
of
landing,
navigations
versus
follow-up
navigations
and,
like
I
said,
we
see
very
different
performance
characteristics,
and
I
wanted
to
also
have
a
shiny
graph
to
go
along
with
that
slide.
A
But
I
started
working
on
my
slides
earlier
today
and
it
was
too
late
to
run
necessary
queries,
but
at
least
like
when
we're
looking
at
internal
chrome
metrics,
we
see
clear
differences
in
various
performance
metrics,
for
example,
in
code
vitals,
passing
rates
between
those
two
different
navigations
on
the
same
site.
A
So
thinking
about
that,
it
seems
like
something
we
want
to
expose
to
rom
and
that
would
enable
run
providers
to
split
on
that
navigation
type
as
a
dimension,
because
landing
and
follow-up
performance
can
sometimes
be
traded
off.
Sometimes
we
can
do
more
work
for
landing
navigations
where
it
will
save
us.
Work
on
follow-up
navigations,
for
example,
prefetching
and
also
being
able
to
split
on
the
dimension,
can
help
reduce
noise
and
clarify
the
data.
A
If
it's
bimodal,
because
you
have
these
two
different
types
that
can
enable
you
to
split
those
two
modes
and
then
for
mpa
and
sba
comparisons,
if
rum
providers
were
to
try
to
compare
like
broader
industry
trends,
only
landings
are
apples
to
apples
comparison
when
doing
that
comparison.
So
that
would
enable
run
providers
to
do
those
kind
of
splits
and
generate
those
kind
of
reports
and
then.
A
More
important
developers
would
be
able
to
then
monitor
migration
between
architectures,
so,
for
example,
during
rewrites,
if
you
are
rewriting
your
app
and
moving
from
an
mpa
to
an
sba
or
the
other
way
around,
you
want
to
make
sure
that,
during
that
process,
you're
not
losing
performance,
you're,
not
making
your
site
slower,
and
that
would
enable
developers
to
monitor
that
migration
to
slowly
roll
out
that
new
architecture
and
keep
track
of
landings
on
both
sides
of
that
architectural
fence.
A
That,
theoretically,
that
information
is
already
exposed
through
session
storage,
so
whatever
api
shape
we
end
up
with,
is
theoretically
polyfillable
using
session
storage.
Only
that
session
storage
is
slow
and
busted,
and
we
don't
want
anyone
to
use
it,
because
it's
a
synchronous,
api
that
accesses
the
disk
and
disks
are
bad
for
synchronous
access.
So,
theoretically
it
can
be
polyfilled.
We
don't
really
want
people
to
do
that.
At
the
same
time,
in
my
view,
I
think
it
means
that
it's
safe
to
expose
that
information.
A
I
haven't,
run
it
through
security
folks
just
yet,
but
it
seems
like
something
that's
already
exposed
to
the
platform.
So
in
terms
of
what
I
thought
of
for
api
shape
we
have.
This
is
essentially
all
this
is
the
performance
navigation
timing,
entry.
What
I
thought
is
simply
adding
a
boolean
for
landing
or
whatever
other
name.
A
We
we
will
land
on
apologies,
and
that
would,
in
my
view,
mesh
well
with
the
concept
of
this
being
tied
to
a
single
navigation
and
and
won't
require
any
updates
once
we
also
start
reporting
other
types
of
negation,
because
this
will
be
tied
to
the
navigation
entry
which
represents
this
info
and
also
there's
a
link
here
to
sketch
pr
I
put
together
today.
A
It's
still
like
work
in
progress,
but
in
terms
of
complexity,
it
seems
relatively
easy
to
add
just
like,
because
these
concepts
are
already
defined,
even
if
not
exported
in
html,
so
maybe
we'll
need
to
add
the
concept
of
landing
to
html
or
we
can
export
those
concepts
and
use
them
in
navigation
timing
directly.
But
generally
it's
already
relatively
well
defined.