►
From YouTube: WebPerfWG call 2022 06 09 Render Blocking status
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
Oh
hi,
so
I'm
ebin,
I'm
from
india
and
today
I'll
be
presenting
about
a
small
feature,
an
under-blocking
status
in
resource
timing.
A
So
the
primary
use
case
is
to
basically
give
a
direct
signal
from
the
browser
regarding
which
resources
are
under
blocking.
Currently,
if
the
developers
have
to
do
it,
they
have
to
rely
on
heuristics
so
that
they
can
get
rid
of
heuristics.
We
plan
on
providing
and
add
signal
from
the
browser,
so
that
is
the
primary
use
case.
For
this,
the
main
benefit
would
be
for
rum
tools,
so
the
api
is
pretty
straightforward.
A
So
the
motivation
for
this
is
there
was
basically
two
previous
works
that
served
as
motivation
for
this.
The
first
one
is
the
values
for
each
resource
that
was
introduced
to
chromium
traces,
so
this
was
done
by
as
part
of
in
it
was
done
in
chromium.
It's
only
available
to
dev
tools
in
chromium.
So
in
that
case,
what
was
done
was
basically
five
values
were
introduced
and,
in
addition
to
the
fact
that
it
was
blocking
or
not
blocking,
more
information
was
also
passed
through
that
value.
A
So
the
case
here,
one
of
the
case,
you
could
look
at
dynamically
injected
non-blocking,
so
that
would
provide
more
information
as
along
with
the
block,
the
fact
that
it's
not
blocking.
It
would
also
give
information
that
it
was
added
by
scripts
or
in
the
case
of
in-body
password
blocking,
along
with
the
information
that
it's
blocking.
A
A
So
this
is
basically
a
bullet,
so
it
has
two
values
right,
so
this
was
added
later
on,
and
in
this
case
the
boolean
specifies
that
if
the
boolean
value
is
true
instead
of
saying
that
the
resource
is
blocking,
it
says
that
the
resource
is
potentially
render
blocking
to
to
make
up
for
all
the
cases
that
we
discussed
previously
here.
So
in
this
case
using
the
heuristics
in
the
html
specs,
based
on
the
heuristics,
this
boolean
is
set
and
yeah.
So
we
reuse
that
boolean.
A
So
instead
of
defining
new
heuristics
based
on
the
boolean's
value,
we
set
our
render
blocking
status
in
resource
timing.
So
whenever
the
boolean
is
say
true,
our
underblocking
status
would
be
set
to
true
and
whenever
the
boolean
is
false,
the
underlocking
status
would
be
set
to
non-blocking
or
non-blocking.
So
we
are
basically
reusing
the
heuristics.
A
So
that's
how
our
proposal
work
currently
and
the
spec
changes
are
pretty
minimal.
Since
we
are
using
the
heuristics
on
the
render
blocking
boolean,
we
define
the
status
based
on
that
and
then
just
pass
it
on
to
finalize
and
report
timing
and
find
lesson
report
timing
again
in
html
we
pass
on
the
value
and
in
fetch
we
take
the
value
and
use
that
to
create
the
resource
timing
entry.
A
So
that
is
the
entire
addition.
In
the
nutshell,
it's
a
pretty
small
addition,
so
yeah,
so
I'll
link
the
ppt
in
the
chat,
and
you
can
look
at
to
be
explaining
on
the
ps
for
the
spec
changes
and
in
addition
to
that
initially,
since
we
started
off
with
the
chrome
values,
it
was
a
string
having
more
information.
So
since
later
on,
it
was
changed
to
a
boolean
value.
A
Would
it
make
sense
to
replace
it
with
a
boolean
value?
The
only
case
where
we
would?
We
could
keep
it
as
a
string
is
if
there
was
a
chance
that
this
could
be
replaced
later
on
with
something
that
provides
more
information
like
the
potentially
blocking
or
the
dynamically
injected
cases
we
discussed
previously.
So
if
there
is
no
chance
that
the
string
would
never
have
have
these
extra
values,
it
would
make
sense
to
just
have
a
boolean
attribute
instead
of
a
string
attribute.
A
So
that
is
something
that
we
wanted
to
discuss
and
get
your
opinions
on
yeah,
but
other
than
that
I
think
yeah.
This
is
the
proposal.
In
a
nutshell,
awesome,
thank
you.
I'm
stopping
recording.