►
From YouTube: 2021-07-29 Frontend Performance Discussion: Source Editor (with Monaco) in Blob viewer refactor
Description
On July 29, 2021 we had a discussion about the recent developments.
Discussed REST/GraphQL endpoints still in use and the reasons for it.
Adding tracking to sitespeed at the earliest moment possible.
Discussed a spike detected in recent days and possible causes.
And discussed a progressive enhancement tweak we're exploring for the Blame page that could prove useful in other contexts.
A
B
Yes,
it
was
just
one
observation,
while
I
was
reviewing
jock's
mr,
I
noticed
there
is
one
instance
in
this
new
view:
refactoring
application,
that
we
are
actually
using
the
rast
endpoint
to
get
the
blob
data,
so
I
was
wondering
whether
we
could
could
actually
use
graphql
to
not
mix
up
the
the
things,
especially
since,
since
it's
a
new
application.
Apparently
we
have
some
flexibility
there
and
it's
it's
it's
related
to
performance,
in
my
opinion,
because
it's
gonna
be
faster
to
fetch
the
data
with
graphql.
C
C
Yet
I
just
decided
to
use
the
existing
rest
endpoint
and
then
with
the
idea
that
over
time
will
migrate
all
of
the
viewers
over
to
view
anyway
and
then
get
rid
of
that
end
point
over
time,
but
I
think
it
I
think,
you're
right
if
it
would
be
beneficial
to
add
those
fields
to
the
graphql
input.
I
don't
think
it
will
be
on
the
back
end
side.
I
don't.
I
can't
see
that
it'd
be
much
work,
but
I'll
create
an
issue
for
that
and
then.
B
C
So
currently
so
the
graphql
endpoint
fetches,
the
existing
hammel
fragments,
so
the
ammo,
let's
say
we're
viewing
a
file
that
plays
audio.
It's
not
yet
migrated
to
the
view
app,
so
you
haven't
written
any
view
code
for
that
yet
and
then
it
fetches
the
actual
haml
file,
the
rendered
content
rendered
html.
B
B
That's
that's
like,
after
I
heard
that
I
I
don't
think
I
would
suggest
that,
because,
like
I,
I
thought
there
is.
There
are
some
data
bits
right,
but
I
definitely
I
wouldn't
suggest
adding
that
that
monsters
thing
into
graphql
that
that
would
be
a
bit
too
much
of
a
stretch,
especially
considering
like
you've
mentioned
one
one
important
point.
B
C
B
Right:
okay,
now
that
that
that
that
then
yeah,
then
sticking
with
sticking
to
rust
probably
makes
sense
in
this
particular
case,
because
adding
this
information
to
graphql
doesn't
make
a
lot
of
sense
on
its
own.
But
considering
that
it's
going
to
be
the
temporary
thing,
then
it's
just
just
a
red
flag.
Apparently
so
sticking
to
rest
is
totally
fine.
Thanks
for
for
the
for
the
explanation
that
that
makes
sense,
I'll
write
down
the
summary.
A
A
It
won't
be
probably
positive,
I'm
expecting
because
we're
loading,
the
blob,
the
monaco
and
everything.
So
we
are
already
expecting
that.
But
we
are,
we
have
to
start
looking
at
that
too,
because
that's
going
to
be
an
important
part
of
the
story-
and
this
is
a
missing
task
here-
for
the
for
the
test
for
the
quality
team
to
kind
of
update
the
tests
in
a
way
that
reflects
the
pre-loading
of
that
and
it
might
or
it
might
be-
that
we
just
update
the
explore
page
to
also
pre-load
the
source
editor.
A
B
Just
one
note
I've
again
while
reviewing
jacques
mar
yesterday
and
today
it's
actually
quite
noticeable
that
the
the
new
application
is
slower
like
it
has
worse
loading,
at
least
loading
performance
comparing
to
the
hammer
application
and
it's
not
related
to
source
editor
right.
It
is
reload
to
the
fact
that
we
are
wrapping
things
into
the
view,
application
and
view
application
is
bootstrapped
later
in
the
process.
It's
discovered
later
in
the
process.
B
A
B
So
what
I
can
tell
you
is
that
we
have,
I
think
we
have
implemented
this
user
matrix
in
the
in
the
blog
viewer,
so
the
it
might
be
that
sort
of
we
reduce
the
server
time
right.
We
reduce
the
server
time
by
not
requiring
this
huge
generated,
html
content
right,
but
at
the
same
time,
on
the
front
end,
we
delay
the
things
because
we
are
moving
to
view.
B
B
A
Yeah,
it's
a
large
percentile,
yeah
yeah.
However,
we
do
have
to
be
aware.
One
of
the
motivations
for
this
is
the
workflow
going
from
the
file
tree
to
the
blob
viewer,
rather
than
rendering
a
new
page
in
that
sense
that
that
flow
will
be
and
feel
faster.
So
that's
that's
why.
I
think
this
is
very
very
very
crucial
to
this
project
is
to
start
start
working
on
the
story
of
the
metrics,
so
the
earlier
we
have
it
the
earlier
we
can
work.
A
We
can
start
working
on
that
in
preparing
and
and
also
just
prioritizing
work
to
improve
that
because
it's
probably
like
you
said,
there's
many
things
that
are
not
even
related
to
the
source.
Editor
that
we
can
probably
do.
I
don't
know
if
we're
already
loading
those
requests
on
startup.js,
like
a
bunch
of
things,
bunch
of
things
that
we
can
do
to
start
tweaking
the
page
to
make
it
faster
as
fast
as
we
can
so
and
also
update
the
testing
themselves.
So
wait.
B
B
A
A
B
B
A
B
B
A
A
A
B
B
B
A
A
A
A
B
B
A
A
B
Over
no
our
hopes
on
that.
I
would
look
into
into
some
first
thing
I
would.
I
would
look
into
would
be
the
back
end
time
I
have.
As
I
said,
I
haven't
checked
that
back
in
time
whether
we
have
any
differences
in
the
back
end
time.
If
it's,
if
we
don't
and
if
it's
purely
the
front
end,
then
I
would
just
I
don't
know,
then
then
it
would
require
some
analysis,
but
from
what
we
have
from
what
we
we
know
of.
There
were
no
changes
that
could
affect
that.
B
A
It
so
that's
not
behind
the
feature
flag.
Is
it
no?
No,
it's
not!
Okay!
It's
just
css,
because
we
we
shipped
something
that
we
thought
was
going
to
make
timings
better
and
it
didn't
so
we
wrapped
it
behind
a
feature
flag
too.
To
kind
of
like
this
is
trickier
because
it's
css
based
on
css,
but
we
should
still
keep
an
eye
on
this
and
then
later,
if
it
comes
to
it,
we'll
probably.
B
A
No,
I
think
I'd
rather
do
the
investigation
outside
of
the
call
yep
yeah,
but
it
is
something
for
us
to
keep
in
mind
that
it's
not
solved
and
it's
it's
a
significant
jump.
It's
like
more
than
more
than
50
of
a
jump.
So
it
was
it's
not
good.
So
we'll
definitely
keep
an
eye
on
this
and
keep
checking
this
back
again.
Once
we
have
the
new
call
in
two
weeks
I'll
be
off
next
week.
A
My
initial
assumption
is
if
we
have
something
that
we
shipped
in
the
code
new
and
recall,
and
there
was
a
spike
regardless
of
that
being
a
chrome,
we
need
to
isolate
that
and
you
need
to
check
whether
that
was
it
or
not
and
there's
two
ways
one.
The
easiest
way
is
we
revert
the
mr
we
ship
it
see
if
it
works
see
if
it
doesn't
move.
A
If,
if
it
doesn't
move,
we
revert
the
revert,
that's
the
easiest
way,
the
other
would
be
to
wrap
it
behind
the
feature
flag
and
then
turn
it
on
and
off
to
see
whether
the
spike
goes
up
or
not.
That
would
be
one
way,
but
the
thing
is
we're
probably
going
to
be
doing
some
investigations
regarding
the
chrome
upgrade
and
everything,
but
this
is
the
one
that
we
can.
Control
is
on
our
side
of
the
code,
so
as
much
as
doesn't
make
sense,
it
would
still
be
something
that
I
would
check.
A
B
A
B
The
the
interesting
thing
is
that
there
is
no
no
correlation
between
lcp
and
the
tbt,
so
the
lcp
hasn't
been
hasn't
got
any
spike,
it's
only
the
tbt,
so
it
cannot
be
something
related
to
some
visual
thing.
It's.
It
has
to
be
related
to
some
some
to
the
main
thread
being
blocked
by
some
javascript
computation
or
something
like
this.
A
But
we
did
so
it's
so
I
get
your
point.
It's
weird
I
I
agree
it's
weird,
but
we
haven't.
We
haven't
shipped
anything
recently
to
that
page.
We
thought
that
we
thought
the
blob
editor
without
the
new
blob
refactor
enabled
so
for
the
hammer
version
we
haven't.
I
don't
think
anything
else
was
shipped
there.
B
A
A
A
A
A
Yeah
and
given
that
that
thing
was
it's
emerged,
I
really
need
a
time
of
merge
at
the
emerging
quest
widget,
so
it
was
merged
26th
at
9,
00
pm,
so
it
is
reasonable
to
have
it
included
on
the
nightly
of
26
to
27
it
was
tested
on
27..
I
think
it's
worth
having
a
look,
but
we
can
take
it
whenever
we
have
time
and
we're
gonna
have
to
rush
it,
but
it
would
probably
something
that
I
would
still.
A
A
A
B
That's
already
there
like
yeah,
that's
that
was
part
of
the
like
the
class
toggle
hasn't
wasn't
even
the
part
of
of
the
performance
emerging
quest
last
week.
It
was
there
for
like
forever,
but
what
I
did
in
the
performance,
related
merch
request
was
moving
this
to
the
request
idle
callback.
I
think
that's
that's
the
only
change.
B
So
if
you,
if,
like
I'm
looking
at
the
dashboard
for
this
page
for
the
results,
so
all
the
all
the
things
actually
are
very
stable.
Some
go
down
some
stay
on
the
same
page
level,
and
it's
only
the
tbt
that
that
is
going
crazy.
I'm
trying
to
figure
out
how,
where
I
can
find
the
side,
speed,
results
and.
B
B
A
B
A
A
Even
more
weird
weirder,
all
right
we
have
to,
I
think
we
just
have
to
keep
an
eye
on
this.
We
can't
figure
out
everything
on
the
call
so
I'll
I'll
I'll
just
suggest
we
keep
an
eye
on
this
and
keep
sharing
on
it's
like
whatever
we
find
thanks
for
the
link
on
the
agenda,
that
was
good
thanks
and
I'll.
Just
yeah
go
move
on
to
your
point.
I
think
it's
better.
C
Yeah
so
in
this
milestone,
I'm
playing
around
a
bit
with
increasing
the
tbt
on
the
on
the
blame
page.
So
it's
not
really
related
to
like
the
blob
discussion
we're
having
at
the
moment,
but
maybe
I
think
it's
worth
highlighting,
dennis
and
feel
free
to
comment
on
the
merger
quest
as
well,
but
I'm
playing
around
with
content
visibility
which
basically
renders
whatever
the
user
is
currently
seeing
in
the
in
the
viewport
and
not
rendering
anything
else.
C
C
C
B
B
This
fix
fixes,
specifically
the
rendering
and
rendering
technically
rendering,
does
require
some
computing
power
right.
So
there
are
some
things
that
are
related
to
rendering,
like
recalculation,
of
the
style
styling
and
that
does
block
the
does
increase
the
total
walking
times.
But
the
the
thing
is
that
for
the
for
the
for
the
blob
view,
we
have
solved
this,
but
by
not
showing
like
not
using
the
conversability,
but
we
just
don't
show
any
lines
that
are
not
essential
right
away
right,
so
we
limited
70
70
lines
on
on
the
first
load.
A
C
B
A
So
it
would
be
nice
to
see
yeah
the
improvement
this
has
on
the
current
page,
together
with
your
with
your
solution
and
we'll
see,
we'll
see,
yeah
the
the
downside
of
not
having
it
supported
by
many
browsers
by
some
browsers.
I'm
I'm.
Okay
with
the
question
we
need
to
see
is,
as
you
scroll
down
the
page.
Does
it
have
a
negative
impact
on
that
experience,
because
the
rendering
has
to
be
done
at
some
point,
so
the
question
is:
do
you
feel
anything
else
different
on
the
page.
A
C
C
A
C
A
All
right,
I'll
I'll
I'll
still
want
to
see
this
ship,
especially
being
on
the
plane
page.
It's
a
it's
another
approach
and
we're
experimenting
and
learning,
and
I
feel
this
page
is
a
little
bit
more
complex
because
it
has
a
little
bit
of
a
some.
Some
rose
pens
happening
over
there,
so
it
is
more
costly
to
render
so
yeah
I'll
yeah
test
it
and
get
it
through
ux
review
and
and
let's
ship
it
and
see
how
it
how
it
behaves.
A
B
A
I
think
I
think
it
will
be
interesting
and
I
like
that,
we're
exploring
different
avenues.
We
have
the
full-on
virtual
scrolling.
We
have
your
your
your
trick
with
this
with
the
rows
and
now
we
have
this
option,
so
we
exploring
many
options
because
I
think
the
more
we
understand
the
mitigation
things
for
the
high
tpts,
the
better.
We
can
apply
them
to
each
page,
so
the
other
part
will
be
to
circulate
this
across
the
team,
but
we'll
get
there
all
right,
and
then
I
guess
that's
it.