►
From YouTube: TPAC WebPerfWG 2021 10 27 - renderblocking attribute
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
A
So
right
now,
in
current
browsers,
we
already
have
a
vendor
blocking
mapping.
So,
for
example,
if
we
have
some
external
style
sheets
in
a
page
and
also
on
scripts
and
then
a
typical
timeline
in
current
process
is
like,
after
navigation,
we
block
rendering,
while
loading
the
scripts
and
style
sheets
and
only
when
they
are
all
loaded
and
when
the
scripts
are
executed,
then
we
start
rendering
them.
A
While
we
already
have
such
a
vendor
blocking
mechanism,
it
has
some
fallbacks
or
limitations.
So
the
first
one
is
it's
just
a
common
practice,
but
it's
not
really
a
well
specified
behavior.
So
brussel
behavior
actually
differ
slightly.
For
example,
while
rendering
is
blocked,
does
a
request,
animation
frame
call
back
fire.
A
It's
actually
a
good
question,
because
if
we
check
the
html
stack,
it
says
this
callback
fires
only
when
we
are
rendering
but
yeah.
We
don't
have
a
stack
of
what's
when
it
blocking
and
the
second
one
is
this:
vendor
block
magazine
mechanism
only
supports
stylesheets
and
scripts,
and
sometimes
we
might
want
to
log
on
some
other
types
of
resources
and
the
last
one
is
it
only
supports
parsing
parsing,
sorted
resources.
A
The
way
we
do
it
is
we
preload
a
web
font
and
we
put
vendor
block
network
on
that
preload
link.
How
does
it
work
so?
Typically
a
web
font
works
like
so.
We
first
render
the
page
with
a
fallback
font,
while
the
weapon
is
loading
and
after
the
web
font
is
loaded,
we
do
a
phone
swap,
so
we
change
it
into
the
web
font.
We
render
the
page,
and
this
causes
a
layer
shift.
A
But
we
don't
really
know
if,
when
it's
executed,
so
it's
executed
once
it's
loaded
and
in
some
cases
there
are
some
scripts
like,
for
example,
it
a
b
testing
framework
that
it's
not
that
important
so
that
we
can,
it
doesn't
have
to
block
better,
but
so
it
doesn't
have
to
block
parsing,
but
we
would
like
it
to
be
executed
before
rendering
starts
so
that
we
can
do
some
certain
tasks
we
can
set
up.
A
The
next
use
case
is
to
prevent
a
flash
of
unstyled
contents
when
we
have
a
loader
script.
So
here
we
have
a
animation
of
it's,
it's
just
actually
a
screen
recording
from
a
real
website,
and
this
is
what
happens
when
the
website
loads.
A
The
reason
is
that
this
group,
this
website,
is
using
a
loader
script
so
that
all
the
style
sheets
and
the
framework
code
etc
are
inserted
by
the
script
so
that
they
do
not
block
rendering.
So
when
we
load
the
page,
we
just
first
render
everything
without
styling
and
then
styles
and
framework
code
is
loaded
and
and
everything
got
restarted
and
shifted
around,
which
is
pretty
bad
and.
A
Before
going
into
the
detailed
proposal
here,
we
have
some
prerequisite,
which
is
what
is
render
blocking,
as
I
mentioned
earlier.
Actually,
the
render
blocking
concept
is
not
specified,
so
we
need
to
standardize
this
concept.
A
A
And
by
standardizing
this
concept,
actually
we
have
a
side
effect
or
side
product
which
is
actually
a
good
side
product.
So
we
can
actually
have
a
javascript
listener
of
when
the
rendering,
when
the
first
rendering
starts
so
the
listener
is
just.
A
We
just
need
to
register
a
request,
animation
frame
callback
in
the
document
head,
so
that
when
the
callback
fires
is
at
the
first
limit
cycle
and
with
this
callback
we
can,
we
can
do
things
like,
for
example,
examining
when
the
first
venue
starts
or
examining
what
resources
are
loaded
where
rendering
starts
or
even
say,
put,
progress
bars.
Whatever.
A
Okay,
so
the
technical
details,
so
finally
the
technical
details
of
this
proposal.
So
it's
a
boolean
attribute.
It
has
to
be
put
on
elements
in
head
and
it
works
on
the
work
zone.
So
and
the
element
must
be
inserted
before
parsing,
so
its
body,
which
means
it
must
be
head
and
and
it
doesn't
care
whether
the
element
is
parsley
inserted
or
scripted.
A
It
works
on
both
types
and
if
it's
on
the
link-
and
it
has
to
be
stylesheet
or
preload-
and
if
it's
on
script
element,
it
must
not
be
a
deferred
script,
because
different
means
to
language
document,
content,
low
loaded
event,
and
this
doesn't
really
work
together.
A
And
of
course,
the
other
attribute
on
that
element
should
allow
the
usa
agent
to
fetch
the
resource.
For
example,
it
has,
it
must
not
be
a
disabled
resource
and
or
if
it's
a
style
sheet,
the
media
code
must
be
evaluated
to
true
and
etc.
A
And
here
are
some
extensions
of
this
proposal
we
considered
but
didn't
put
into
the
initial
proposal,
so
the
first
one
is
before
before.
First
render
event.
So
this
event
fires
when
we
are
about
to
run
the
first
rendering
cycle,
but
it's
just
the
same
as
putting
a
request,
animation
frame
callback
in
document
head.
So
it's
just
a
pure
syntactic
shooter.
A
The
second
one
is
render
blocking
equals
false,
so,
which
means,
if
we
put
this
on
an
element,
put
it
on
the
resource,
then
it's
not
a
vendor
blocking
resource,
so
it's
mainly
for
async
asynchronous
style
sheets,
but
currently
we
we
already
have
some
workarounds
that
are
slightly
more
complicated
but
not
really
too
complicated.
A
Just
we
just
use
javascript
to
load
the
resource
or
preload
below
the
style
sheet
and
use
javascript
to
enable
it
when
it's
loaded,
not
too
complicated
or
we
can
set
when
the
blocking
equals
500
milliseconds,
which
means
the
resource
is
render
blocking.
But
if
it
loads
for
it,
takes
more
than
500
milliseconds
to
load,
then
after
500
milliseconds
it
doesn't
block
rendering
anymore
it
can
still
load,
but
just
doesn't
block
it.
A
So
this
allows
developers
to
decide
on
what
the
user
experience
is
like.
If
the
network
connection
speed
is
low,
but
the
problem
is
it's
hard
to
decide
so
so
we
think
it's
not
not
really
a
core
part
of
the
proposal
so
didn't
put
it
in
and
finally
so
it
can
be
put
in
a
actually
larger
scope.
A
A
A
We
can
synchronize
loading
of
resources
to
before
or
after
after
the
the
milestones,
for
example,
first
paint,
which
is
essentially
the
same
as
first
vendor
or
dcl
or
load,
or
a
lot
more.
A
Oh
actually,
let
me
finish
this
since
we
have
time
so
so
so
this
is
what
I
call
a
weapons
trilemma.
A
From
trilama,
so
when,
when
using
web
font,
the
typical
user
experience
expectation
is
like
we
want
it
to
be
as
fast
and
as
stable
as
a
locally
installed
phone,
but
it's
actually
not
achievable.
A
So
we
cannot.
So
there
are
three
three
goals
of
so
we
want
the
weapon
to
be
consistently
used.
We
want
no
layout
shifting.
We
want
to
know
rendering
delay
just
like
a
local
font,
but
we
can
actually
just
achieve
two
of
them.
A
So
if
we
so
if
we
want
no
layout
shifting
and
no
rendering
delay,
then
there
is
from
display
option,
which
means
which
means
the
font
is
not
guaranteed
to
be
used
or
if
we
can
tolerate
some
layout
shifting,
then
it's
pretty
much
just
the
kind
of
behavior
just
the
default
behavior,
and
we
have
some
some
other
techniques
to
align
the
metrics
of
fallback
font
and
the
actual
web
fonts,
so
that
the
layer
shape
can
be
sort
of
minimized.
But
it's
not
just
not
eliminated,
because
the
two
fonts
are
still
different.
A
You
can
perfectly
align
to
different
fonts,
and
so
this
proposal
is
the
the
last
edge
of
this
parameter.
So
if
we
can
allow
some
rendering
delay,
then
we
can
achieve
the
font
being
consistently
used,
and
you
know
that
that's
it.
A
Yeah
and
yeah
just
a
sec.
Let
me
stop
the
recording.