►
From YouTube: Navigation caching and bundle splitting
A
Right
so
I
want
to
show
this.
This
update
that
Mark's
done
for
the
for
the
performance
of
the
super
cyber.
It's
it's
a
subtle
change,
it's
really
sort
of
like.
If
you
look
at
the
changes,
there's
there's
not
a
lot
of
code
change,
but
this
this
actually
makes
a
huge
Improvement,
the
the
tldr
of
what
this
does
is
we
take
all
the
JavaScript
that
renders
the
sidebar
and
we
separate
it
out
and
treat
it
completely
separately
to
the
rest
of
the
JavaScript
on
the
page
has
a
number
of
benefits.
A
Firstly,
we
can
make
sure
that
javascript's
rendered
first
so
that
the
navigation
is
kind
of
always.
The
first
thing
to
render
is
always
there
when
we
need
it,
and
it
really
helps
with
caching
as
well,
which
is
the
second
part.
What
we
do
with
webpack
currently
is
in
order
to
reduce
the
bundle
size
so
that
we're
not
shipping
all
of
the
JavaScript
ever
written
for
gitlab.
In
one
package
we
use
code
splitting
so
that
we
can
ship
just
the
JavaScript
that
that
particular
page
needs.
A
So
if
you're
on
the
boards
page,
you
only
get
the
JavaScript
that
needs
that's
needed
to
render
the
Bold
page.
You
don't
get
the
JavaScript
for,
like
the
pipeline,
editor
the
pipelines,
the
merge
requests
whatever
it
is
right.
This
is
great.
It
reduces
our
bundles.
We
ship
a
lot
less
code
to
the
user,
a
lot
less
useless
code,
I
should
say,
and-
and
it's
it's
great
for
our
performance.
A
What
it's
not
great
for
is
with
things
like
the
sidebar,
the
common
elements,
so
because
we
have
essentially
a
different
bundle
of
JavaScript
for
every
page
that
you
look
at
even
though
the
the
code
for
the
the
navigation
is
the
same
on
every
single
page.
It's
part
of
a
different
bundle
for
every
single
page,
so
that
when
we
go
to
Cache
it
we're
just
caching
the
JavaScript
for
the
issue
page
we're
caching,
the
JavaScript
for
the
epics
page.
A
So
what
was
basically
happening
is
you
would
load,
and
this
is
kind
of
what
I
was
trying
to
show
in
in
this
video
that
I
recorded
before.
If,
if
you
go
to
page
that
you've
not
been
on
before,
like
I
think
this
one
here
are
thrilled
it
to
slow
3G
to
really
highlight
the
point,
but
what
I
did
here
was
I
went
over
to
the
pipeline
editor
and
because
I'd
never
been
on
the
pipeline
at
a
page.
In
this
instance,
you
see
that
the
navigation
on
the
left
hand
side
is
just
totally
blank.
A
So
basically,
the
main
content
of
the
page
is
blocking
the
navigation
from
rendering
you
see,
eventually
it
loads
in,
and
then
we
get
the
data
that
did
take
quite
a
while
I
know,
I've
throttled
it
to
like
super
slow,
3G
speeds.
But
that
kind
of
illustrates
the
point
now,
if
I
go
over
here,
I
can
basically
do
the
same
thing
again.
So
you
know
if
I
refresh
this
particular
page,
you
know
it's
cached.
A
So
it's
pretty
quick
and
then,
if
I
go
on,
render
exactly
the
same
pipeline
editor
and
then,
as
soon
as
it
comes
back
from
the
server
we've
already
got
the
JavaScript
for
the
sidebar,
even
though
this
JavaScript
for
the
pipeline
editor
takes
a
while
to
load,
it
doesn't
affect
the
sidebar,
which
is
amazing,
and
it
means
the
navigation
has
a
lot
higher
priority
and
you'll
see
it's
still
loading,
but
we've
we've
got
the
the
editor
here,
the
sidebar,
sorry!
A
So
yeah!
It's
it's
a
small
change,
but
it
has
big
impacts
right
and
I.
Guess
the
other
side
of
it
as
well,
which
is
a
little
harder
see,
is
that
it
it
does
execute
first,
so
yeah,
thanks
Mike
for
for
looking
into
this.
The
you
know,
the
the
speed
of
the
the
super
sidebar
should
be
a
lot
quicker
now
of
the
seed
speed,
at
least
all
thanks
to
caching
and
and
getting
you
right.