►
From YouTube: André/Andrew discuss SpeedIndex, GitLab.com Perf, Frontend Optimisation & Serverside Rendering
Description
Discussion follows on from the issue https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/7201 "Prepare on OKR for improving SpeedIndex on a benchmark of URLs compared to similar URLs on GitHub"
-----------------------------------------------------------
@andr3 (the Scalability Team's frontend counterpart) and I had a great call about this topic today: https://youtu.be/e2iccdgrY5s
Some points from the call:
1. Optimisations to GitLab.com's SpeedIndex benchmark would mostly fall on frontend teams
1. Breaking our Javascript bundles down into smaller components to reduce compile times
1. Ensuring that Javascript bundles are effectively cached between releases (ie, production deploy doesn't invalidate cache)
1. Is there more performance that we can squeeze out by taking advantage of our new Cloudflare setup?
1. Is a target SpeedIndex of 1000 a reasonable goal? @andr3 think's its possible
1. Serverside Rendering GitLab: https://gitlab.com/gitlab-org/gitlab/-/issues/215365
1. Managing frontend performance and bringing into Prometheus
B
Okay,
so
the
media,
the
reason
we
decided
to
have
this
meeting
is
I
was
just
explaining
before,
but
I'll
run
through
it
again
quickly.
We
were
having
a
discussion
around
and
okay
our
by
performance
and
that
discussion
originated
in
the
infrastructure
area,
because
people
often
think
a
lot
of
things
are
running
slow.
It
must
be
the
infrastructure,
but
the
the
benchmark
that
were
using
to
do
this.
Optimization
is
speed.
Index
and
I
happen
to
be
quite
a
big
fan
of
it,
because
much
of
it
is
perceived.
Speed
and
perceived.
B
A
Perceptive
performance-
and
we
think
is
performance,
is
a
very
complex
topic
that
goes
through
many
disciplines
like
it
can't
be
just
one
so
I
agree,
it
can't
be
just
infrastructure,
sorting
it
out,
and
this
feedback
that
we've
gotten
from
from
the
user
recently
is
something
that
we
have
been
working
on
and
working
towards,
improving.
So
the
point
that
he
or
the
area
that
he
pointed
out
on
the
foul
tree,
something
that
we
have
been
refactoring
into
view
to
make
it
more
performant.
A
Now
it
allows
us
to
do
clever
stuff,
because
performance
is
not
just
a
load
is
also
how
you
handle
stuff
later,
how
the
user
directs
with
it,
how
we
potentially
do
virtual
scrolling
how
we
control
all
of
that.
That
kind
of
requires
us
to
have
that
part
in
view,
but
having
said
that,
the
way
we're
doing
it
right
now.
It
precludes
JavaScript
kicking
in
JavaScript
running
and
even
in
the
smaller
pages
like
the
smaller
folders.
Where
has
where
there
has
like
only
a
dozen
of
files,
we
still
lose
in
comparison
with
competition
and
I.
A
Think
that
has
to
do
with
the
fact
that
we
are
rendering
everything
in
JavaScript
and
which
is
not
bad
per
se.
But
it
does
take
time
to
be
to
put
it
all
up
and
if
you
do
in
the
direct
come
direct
contrast
with
the
competition
that
he
was
there
on
the
day
on
the
table,
I
think
you've
already
I.
Think
it
was
you
or
someone
identified
on
the
issue
as
well,
is
that
those
competitors
are
doing
server-side,
rendering,
which
we
are
not
right.
A
Yeah
server-side
rendering
has
always
been
like
a
dream
for
us,
but
it's
never
really
feasible
well,
most
of
all
most
because
mostly
because
it's
a
sub
that
is
very
native
to
node
servers,
but
we're
using
a
rail
stack
and
introducing
something
like
that
has
always
been
like.
Oh
that's
a
big
dependency
to
add
to
the
project.
It's
not
just
because
we
get
Lancome,
but
also
once
you
go
into
self-hosted
instances.
A
It's
another
piece
of
the
puzzle
that
another
cog
in
the
machine,
but
in
the
end
goal
like
for
us
on
the
front
end
team
we've
always
talked
about
this
topic
as
something
that
would
potentially
go
somehow,
but
how
we
get
to
that.
That's
the
big
question,
because
then
we
go
into
infrastructure
realm
again
to
your
first
point.
This
cannot
be
just
one
section
tackling
because
at
this
point,
there's
there's
some
things.
A
We
can
improve
on
the
front
end
to
kind
and
make
the
score
look
better
and
we
can
do
some
management
in
terms
of
how
many
data
we
load
at
a
time
because
we're
not
we're
not
there.
Yet
we
just
finished
the
refactor,
the
first
iteration
of
the
refactor.
We
want
to
get
to
a
point
where
we
don't
don't
just
render
the
five
thousand
or
fifty
thousand
files
on
a
folder.
We
progressively
load
them.
A
We
we
take
peas,
which
is
kind
of
the
experience
we've
been
having
on
the
merge
request
is
first,
we
load
all
the
data,
the
browser
would
collapse
and
then
we
started
rendering
in
batches
and
things
got
a
little
bit
better
and
we
are
progressively
improving
on
that
set
on
that
part.
But
it's
not
something
out
of
the
box.
That's
for
the
later
life
part
of
the
lifecycle
of
the
page
right,
the
rendering,
which
is
what
speeding
speed
index
tackles
it
it.
It
is
being
affected
by
the
fact
that
we
have
to
load
the
page.
A
B
B
Because
he's
promoting
a
product-
and
you
know
this
is
totally
fair
like
I-
would
be
the
same-
he's
promoting
a
product
that
has
got
certain
features,
and
so
the
features
that
he's
chosen
to
promotes
are
the
ones
that
are
associate
like
that
that
his
product
raised
more
focused
on
right,
where
we've
much
more.
You
know
here
to
think
about
what
the
most
important
part
of
our
product
is
merge.
B
Request
page
is
probably
it
and
so
I
think
we
should
use
like
a
blended
score
across
a
whole
bunch
of
pages,
to
kind
of
promote,
like
a
like
a
more
holistic
view,
rather
than
just
trying
to
optimize.
You
know
one
single
page,
like
I,
think
if
we
could
get
if
we
could
squeeze
a
faster
page
render
out
across
the
entire
application.
That
would
be
much
better
than
than
optimizing
on
a
single
repository
or
a
single.
B
You
know
one
of
the
range,
what
a
few
apps
yeah,
what
about
one
of
the
apps
yeah?
And
so
that's
that's
the
first
point
and
so
I
started
thinking
about
that
I
had
friends
about
to
die.
The
second
point
is
that
I
think
that
it
was
a
going
with
the
second
point:
yeah
I'll
get
back
to
it
in
a
second
all
our
remembers
yeah
that
they
was
it
again
but
yeah.
So
the
the
most
important
thing
I
think
is:
we've
got
to
kind
of
spread
it
around
and
kind
of
look
at
solutions.
Oh.
B
My
second
point
was
that
I
I
don't
know
the
state
of
the
fronton
code
with
with
Giddha.
That
was
really
the
last
time.
I
was
like
heavily
involved
in
front
end.
End
and
I
know
how
much
work
it
is
to
move
across
the
server-side
rendering
and
get
her
was
when
I
was
working
on.
It
was
all
back
burn
and
we
invented
the
world's
most
scary,
like
homegrown
server-side,
rendering
on
backbone,
and
it
was
it
was
nasty,
but
it
didn't
make
a
huge
difference
to
kind
of
pre-rendering
pages.
B
It
really
did
Sumeet
things
up
tremendously,
but
it
was
horrible
because
it
was
always
janky
and
breaking
and
but
I
do
understand.
You
know
to
kind
of
represent
the
entire
page
and
get
that
whole
thing
rendered
like
on
the
server
is,
is
a
huge
amount
of
work,
and
you
know
get
is
a
tiny
application
community.
B
So,
but
but
I
I
do
also
think
that
there
is
an
argument
kind
of
in
there
very
long
term
that
we
should
consider
kind
of
having
almost
like
a
proxy
that
we
could
route
request
through
optionally.
That
is
no
server-side
rendering.
If,
if
that
was
you
know,
if
we
felt
that
that
we
could
get
the
entire
application
rendered
server-side,
then
that
would
be
something
that
we
could
possibly
consider
talking
about.
A
That's
that's
a
good
point,
I
think.
If
we
make
it
optional,
make
it
as
an
optional
component,
then
we
can
potentially
sell
it,
as
is
an
optional
complexity,
that
clients
can
opt
into
which
doesn't
sound
bad
to
me,
but
I
have
fairly
limited
visibility
to
to
clients,
needs
and
everything,
but
you
did
touch
on
a
point.
The
way
that
it
would
live.
Seen
mostly,
this
done
is
like
the
rails.
B
A
A
B
A
We're
using
two
state
management,
libraries
so
using
view
X,
that's
the
one
that
I've
been
using
the
most
for
a
longest
time
and
more
recently,
since
we
jumped
over
the
graph
QL
we're
using
the
paulo,
which
simplifies
a
lot
of
the
handling
of
state
for
a
bunch
of
cases
and
and
we're
living
in
this
scenario,
where
graph
QL
apps
like
design
management,
for
example,
they're
using
Apollo
for
sake
management,
older
apps,
are
using
recipe
eyes.
They
usually
go
for
a
few
X,
that's
kind
of
like
the
scenario
as
for
next,
which
was
your
question.
A
A
A
A
A
I
was
just
going
to
say
that
the
server-side
rendering,
if
we,
if
we
ever
choose
to
go
down
that
path,
which
that's
what
I
was
saying
you
were
to
you
earlier.
That
is
something
that's
been
on
my
mind
because
we're
revisiting
and
rethinking
a
bit
of
the
merge
request,
stiffs
app,
which
is
very
complex,
hard
to
maintain
and
everything
and
the
topic
came
up
like
what,
if
we
could
do
server-side
rendering
for
this.
How
would
that
look
like
and
it's
something
that
I've
been
discussing?
But
we
don't?
A
B
Of
view,
I
would
I
would
say
that
if
we
can
make
it
optional-
and
you
know,
if
you
don't
have
it-
you
just
get
a
blank
page
and
it'll
mount
on
the
clients.
I
would
I
would
be
really
happy
to
kind
of
help.
Push
that
forward
from
an
infrastructure
point
of
view,
and
you
know
I've
used
side,
rendering
I
know
that
there
there
isn't
an
alternative
to
that
right,
like
you,
can't
build
this
in
Ruby
like
there.
B
That
is
not
going
to
happen
right
unless
you,
you
maintain
yeah
stacks
and
you
keep
them
up-to-date,
and
that
was
kind
of
one
of
the
things
that
we
were
doing
a
lot
with
Kidder.
Like
sometimes
someone
would
you
know
because
it
was
a
super
janky,
server-side
rendering
you
know,
someone
would
make
a
change
and
they
wouldn't
change
like
the
server-side
rendering,
and
maybe
you
know,
merge,
request
review
you'd
go
like.
B
B
So
if
we
can,
if
this
had
to
be
essential,
part
of
the
stack
I
think
we
would
come
up
against
a
lot
of
a
lot
of
opposition
if
this
was
something
that
was
an
optional
feature,
which
I
think
a
lot
of
people
would
opt
for
because
of
the
performance
that
we
give.
You
I
think
there's
a
there's,
a
really
good
argument
for
fighting
for
that.
Okay,.
A
I,
do
I
do
fear
for
like
the
additional
resources
that
this
will
imply
for
clients.
But
if
it's
an
optional
thing
and
if
we,
if
we
take
on
server-side
rendering
from
the
start,
thinking
that
it's
an
optional
thing,
we
will
repair
the
code
so
that
hey,
if
the
app
is
not
mounted
on
the
server
you're
gonna,
have
to
mount
it
on
the
client.
But
if
it's
already
there.
A
That
sounds
like
a
good
thing,
and
that's
that
was
my
second
point
earlier,
which
is
whatever
we
do.
I,
don't
expect
us
to
be
able
to
grab
what
we
have
now
and
put
it
server-side
rendering
right
from
the
start.
This
would
have
to
be
new
development
say
that
having
all
coming
along
or
we
want
to
adapt
an
existing
app.
There's
gonna
be
an
effort
of
refactoring
it
to
a
shape
that
it
can
be
server-side
rendered,
especially
because
of
the
data
flow,
because
we
don't,
we
have
to
choose
for
each
one
of
the
apps.
A
What's
the
part
that's
going
to
be
server-side
rendering
and
once
the
part
is
going
to
be
just
in
a
synchronous
requests
once
the
page
loads
which,
honestly,
if
we
want
to
get
to
the
point
of
like
an
overall,
better
perceived
performance,
this
will
be
like
the
first
page
so
to
speak.
Of
contents
would
come
server-side
rather
with
data
and
then
would
request
further
data
from
the
server
after
the
page
load.
B
A
If
this
apply,
this
thing
introduces
some
complexity,
not
not
complexity,
but
a
problem.
That
kind
of
made
us
steer
away
from
hammer
which
is
the
load
on
the
server
we're
looking
for,
like
500
millisecond
requests
to
the
page,
your
pages
and
servers.
But
now,
if
that
requests
is
gonna,
have
to
render
the
app
get
the
data
from
the
back
from
the
database
and
push
that
in
all
in.
B
B
A
I
do
I
do
so,
I,
don't
think
that's
a
fixed
rata
jacket,
I!
Guess
we
have
some
right
maneuverability
we
can
trusted.
So
we
can.
We
could
do
it
and
put
it
on
this
on
the
page,
so
that
the
JavaScript
and
pick
it
up
but
I,
think
the
most
efficient
way
would
be
ask
graph
Gale
for
the
first
five
items.
For
example,
yeah
yeah.
B
A
The
app
right
right
on
the
server
push
that
out
and
then
Java
kicks
in
and
requests
from
5
to
100
or
something
and
then
batches
from
there.
Yeah
I
feel
like
that
would
be
the
most
efficient
because
he
wouldn't
put
that
much
strain
on
the
graph
QL
requests.
It
would
be
faster
yeah.
We
put
that
on
the
servers.
A
A
B
A
Me
so
let
me
explain:
oh
look
or
have
the
front
and
ecosystem
right
now.
So,
if
you
think
about
the
the
the
repository
tree,
which
is
what
the
reuse
are
highlighted
on
hacker
news,
but
it's
also
one
of
the
recent
works
we've
been
doing
on
source
code,
so
the
whole
page
is
rendered
in
rails
right
and
when
you
get
to
the
repository
tree
container.
Okay,
hear
me
yeah,
okay,.
B
A
To
the
repository
tree
container,
it
just
happens
that
it's
an
empty
div
and
then
the
JavaScript
will
just
bind
to
that
div
and
then
kickstart
a
view
up
there.
There
might
be
other
view
apps
in
other
parts
of
the
of
the
page
right
and
those
will
kick
off
dependently.
Sometimes
they
will
share
state
like,
for
example,
the
merge
request
page.
A
We
have
the
discussions
app
and
the
diffs
app
and
they
share
a
state,
but
okay,
they're,
all
kind
of
independent
and
each
page
at
people
that
might
have
one
to
three
to
four
view:
apps
on
their
own,
with
their
own
individual
state
management
with
their
own
individual
network
requests.
So
that
is
something
that
we
have
currently
across
get
lock.
So
we
don't
have
a
single.
B
Page
of
finger
will
that
add
a
lot
of
complexity
to
something
like
this
like,
as
opposed
to.
If
it
was
like
a
single
kind
of
application
on
each
page,
we
would
do
you
see
like
having
to
load
multiple
applications
being
more
complex,
which
always
it
not
really
going
to
make
it
more
complex
on
time.
That's
a.
B
A
Each
of
the
view,
apps
being
server-side,
rendered
triggering
requests.
The
database
will
make
the
page
load
slower,
but
I
think
from
the
moment
that
server-side
rendering
is
a
conscious
thing.
Once
we
make
our
view
app
opt
into
server-side
rendering
performance
is
already
in
our
heads
right
well,
I
would
say,
for
the
beginning
say
that
we
turn
on
the
key
for
server-side
rendering
none
of
the
view
apps
have
been
opted
in,
nothing
changes,
I
would
expect
and
then
I
go
into
one
of
the
pages
that
have
three
view.
Apps.
A
On
the
first
view,
app
say
that
I
say
alright
that
will
be
server-side
rendered.
That
alone
will
be
the
weight
on
the
server
response.
The
other
two
will
be
no
weight
because
they
will
just
be
kicking
in
JavaScript,
so
I
think
the
complexity
is
there
you're
right,
but
I
think
will
be
consciously
yeah.
B
B
A
B
B
A
A
B
Front
of
the
whole
application
now
and
I,
don't
know
if
we've
done
an
audit
of
how
well
we
cashing
our
clients,
I
assets,
and,
if
there's
like
a
when
so
there's
a
few
things,
the
first
one
is
is
the
caching
the
second
one
is:
how
much
do
you
know
of?
Are
we
kind
of
breaking
out
javascript
up
into
async
async'
loaded
modules?
Obviously,
please
forgive
me
because
my
front-end
tech
is
like
what
three
years
out
of
date.
B
A
A
different
nature,
because
in
in
big
lab,
we
had
mostly
just
like
page
reloads,
except
for
the
web
IDE,
for
example,
that's
kind
of
like
our
most
similar
to
an
SP,
a
which
is
everything
it
is.
If
you
have
but
to
your
question,
we
do
have
the
the
bundles
our
splits,
so
we
have
code
splitting
so
that
were
so.
If
you
go
to
one
page,
you're,
not
loading
everything
on
the
other
page
and
we're
looking
right
now
heavily
into
the
topics
that
you
just
mentioned
like.
How
big
are
these
bundles?
A
Can
we
bring
them
down
and
that
is
on
the
newly-formed
front,
end
foundation
team
that
is
led
by
Lukas,
IP,
okay
and
I.
Think
that
would
be
a
great
topic
for
you
to
bring
up
with
him
because
he's
looking
into
that
topic
specifically
now
about
the
size
of
the
bundles
and
the
caching
goes
hand
in
hand.
So
I
would
say
our
session
I
had.
A
B
You,
but
it
sounds
like
Lukas,
is
the
right
guy
to
talk
to
you.
The
question
is-
and
this
was
something
this
is
also
just
from
experience
with
Kido.
As
we
increase
the
number
of
deployments,
we
did
a
day.
We
were
changing
hashes
on
JavaScript,
bundles,
that
we're
not
changing
and
we
were
in
validating
all
of
those
caches,
and
that
was
like
a
huge
performance
loss
and
one
of
the
things
that
I
always
wanted
to
do,
and
we
might
have
even
got
it
done
before.
B
As
it
seems
and
the
same
things
happening
at
gitlab
right,
we
are
we
deploy
more
frequently
and
if
we
are
throwing
away
what
the
browser
has
in
his
cache,
because
we've
done
in
a
ploy
we're
losing
a
lot
of
performance
there
as
well,
so
aren't
those
hashes
controlled
by
Rails.
The
so
I
mean
we
had.
You
know
we
built
all
of
this
before
there
was
a
lot
of
tooling,
like.
B
Grass,
it
was,
it
was
a
bunch
of
work
to
do
that.
You
know
if
rails
and
web
pack
are
kind
of
working
together
to
to
give
you
consistent,
consistent,
bundles
that
are
also
cashable
across
deploys.
Obviously,
if
nothing's
changed
in
that
bundle,
then
that's
great,
but
it's
something
and
I'll
take
a
look
at
like
in
just
trying
for
you
yeah.
A
A
A
Good
win,
if
we're
not
doing
it
for
sure
yeah
the
same
thing
for
caching
and
the
splitting
we're
looking
at
into
the
duplicating
some
data
that
is
going
into
so,
for
example,
and
notice.
He
mentioned
that
some
of
the
emojis
are
being
called
by
a
bunch
of
bundles.
So
you
can
totally
improve
that
part.
Yeah
and.
B
You
know
some
of
it
is
like
the
network
download
time,
but
equally
it's
about
the
compile
time
right
so
you're
trying
to
like
if
there's
function,
I
see
that
people
don't
need
at
page
load
time.
You
know
get
it
out
of
that.
First,
like
synchronous
load
and
into
you
know.
So,
if
there's
like
a
button
that
you
click
right
one-fifth
of
the
time,
then
you
know
a
Sinkler
whatever
the
functionality
there
is,
but
obviously
I
understand
that
the
decisions
are
very
different
when
you're
building
an
SPI
yeah.
B
A
Most
of
the
scenarios
that
we
have
don't
they're,
just
gonna
be
reloading
the
page
except,
for
example,
for
example.
The
the
merge
request,
if
like
a
big
app,
has
a
bunch
of
interaction
but,
for
example,
say
that
I
was
only
gonna
load.
The
data,
the
the
assets
for
the
batch
comments,
like
the
merge
request
reviews
once
they
click.
A
If
the
bundle
was
already
cached
from
the
get-go,
then
loading
them
asynchronously
would
be
just
another
extra
time
for
the
performance
that
would
make
the
interface
slower
so
I
definitely
delegate
or
defer
that
to
Lucas
on
how
we're
handling
the
but
the
bundles
and
indefinitely
it's
all
we're
all
part
of
it,
but
we're
not
building
an
sba.
That's
my
bottom
line.
A
B
Know
what
I'm
talking
about
like
as
the
external
plugins
and
stuff
so
yeah,
so
we
had
this
with
sorry
I'm
using
a
lot
of
getter
stuff
yeah.
Thank
you
today,
but
it
is.
It
is
a.
It
is
a
easy
win
right,
and
so
you
take
I,
don't
know
whatever
we
use
view
I'm,
just
I'm
gonna
use
a
bunch
of
old
names
to
show
you
how
my.
B
Is
you
know,
you
underscore
backbone,
all
of
the
libraries
right
like
I'm,
gonna,
say
j.crew,
because
we
probably
still
got
some
jQuery
in
there
somewhere
right
and
you
put
all
of
those
things
into
a
bundle
when
a
page
loads
it
loads
to
JavaScript
bundle,
it
always
loads
synchronously
to
JavaScript
bundles,
the
the
one
for
you
know.
That's
got
that
and
that's
common
across
all
pages
and
it's
it's
obviously
compiled
once
for
every
page,
yeah.
A
B
A
A
A
J/S
core
jeaious,
each
hard,
slow,
underscore
a
bunch
of
things
they're
all
there,
so
I
think
that's
what
we're
doing,
but
definitely
something
to
keep
in
mind.
Ring
yeah
when
you
bring
up
with
locals
yeah
in
terms
of
actionable
things
for
the
OPR.
Is
there
anything
else
that
we
need
to
discuss
at
this
point,
because
I
feel
like.
B
And
I
think
it's
personally
and
I'd
like
to
get
your
opinion
on
this
I
think
it's
it's
way
too
too
optimistic
I.
Don't
it's
basically
having
the
speed
index
of
the
sites
and
I
think
we
should.
You
know
likes
it
says:
okay,
I
should
be
70
percent
probability
of
achieving
them,
I
kind
of
get
the
feeling
from
everything.
I've
looked
at
and
I
need
to
quantify
this
a
lot
more,
but
before.
A
B
Sort
of
propose
anything
but
I
get
the
feeling
that
I
don't
think
that
we
will
be
able
to
do
that.
You
know
without
server-side
rendering
with
you
know,
we
can
really
what
we
can
tweak
now
is
some
optimizations
around
page
load
times
around
caching,
maybe
around
these
bundles,
but
I,
don't
think
we're
going
to
have
the
speed
index
off
of
these
pages
yeah.
A
That's
so
the
thing
about
the
speed
index
is
that
it
were
working
with
time
and
if
we
find
clever
ways
to
bring
in
again
speed
index
is
a
kind
of
mix
between
the
perceived
performance
on
the
viewport
right
and
a
lot
of
the
things
we've
done
successfully
in
terms
of
performance
have
been
delegating
the
heavy
loading
for
later
and
stuff.
Like
hey,
if
it's
below
the
fold,
the
not
really
caring
about
that,
so
we
can
just
not
load
it
right
away,
we
load
it
later.
A
B
A
Initially,
make
that
much
faster
and
I
can
give
you
the
example
of
the
merge
request
page
on
the
diffs
that
we
recently
did
a
work
where
you're
still
from
that
time.
But
there
was
a
time
when
we,
when
we
refactor
interview,
we
had
one
dip,
JSON
request
for
the
whole
page,
and
now
we
book
that
off
into
two
kinds
of
requests.
One
is
the
metadata
of
the
diff
and
the
other
is
the
actual
content
of
the
diff.
A
The
rest
I
feel
like
we
might
be
in
a
position
to
half
that
and
again
I
always
like
okay.
Ours
are
very
ambition
of
ambitious,
so
I
feel
like
that
would
be
a
good
metric
to
go
for.
I
would
love
for
us
to
keep
the
topic
of
server-side
rendering
in
in
in
flight
and
investigating
that,
but
I'm,
not
sure.
If
a
quarter
is
it
time
yeah,
it's
it
that
rolled
out
yeah,
but.
B
A
B
For
certain
things,
not
everything
and
the
the
final
thing
that
I
just
want
to
share
how
to
bring
up
was
that
this
whole
little
exercise
is
brought
up
and
I
know.
We
over
time
has
brought
up
that
the
the
front-end
team
have
got
kind
of
their
own
little
silo
of
metrics,
which
is
great,
like
I'm,
really
happy
that
this
has
been
set
up
and
that's
the
speed
index.
B
The
the
part
about
it
that
I,
maybe
like
would
like
to
iterate
on,
is
that
it
would
be
really
good
if
this
was
in
prometheus
and
we
had
same
kind
of
monitoring
and
like
eyeballs
on
it
from
our
side
as
well.
You
know
we
have.
We
have
a
lot
of
kind
of
second-order
metrics,
so
we
have
stuff,
like
you
know,
is
the
webserver
functioning
within
acceptable
latency
thresholds.
But
then
we
also
have
second
level
metrics,
which
is
like
how
much
of
the
time
is
each
component
within
the
system
within
its
thresholds?
A
B
On
do
any
of
that
stuff
and
it's
very
petitioned
you
know,
I
kind
of
I
was
vaguely
aware
of
it,
but
I
never
really
dug
into
it,
and
so
I
would
really
like
to
kind
of
look
at
bringing
this
integral
fauna
and
having
like
a
single
set
of
metrics.
But
that's
probably
I,
don't
know,
I've
got
a
I've
got
a
propose
something
so.
A
A
B
A
B
B
B
A
B
To
look
through,
they
don't
support
Prometheus,
and
so
it's
kind
of
tricky
I
think
what
might
end
up
happening
is.
It
might
just
be
easiest
to
run
the
two
alongside
one
another,
so
almost
set
up
like
a
like
I've
got
a
tool
that
I
built
back
years
ago.
Forget
lab
that
actually
exports
the
same
metrics,
the
speed
index
and
all
of
that
into
Prometheus.
But
what
I
want
to
do
is
I
just
want
to
I
want
to
have
like
really
good,
metrics
and
I
want
to
learning
like
that.
B
Okay,
so
there's
a
whole
bunch
of
there
is.
You
know,
after
after
kind
of
saying
that
I
I
think
we've
got
enough
tools.
I
do
think
there
is
work
that
we
can
do
on
tools,
but
it
that
that
is
just
to
kind
of
help
us
improve.
We
do
have
a
lot
of
data
about
the
things
that
we
that
we
can
fix
already,
especially
ya,
know.
A
B
A
B
So
this
is
this:
is
it's
got
a
it's
got
a
sort
of
snowflake
backend
of
Graphite's,
and
the
only
things
that
that
graphite
has
got
in
it
is.
Is
these
metrics,
so
we
can't
kind
of
integrate
it
so,
with
the
rest
of
our
dashboards,
it's
all
managed
and
get
now.
We
can't
really
get
the
graphite
stuff
in
there
in
the
same
way
it
doesn't
it's
not
really
compatible
without
a
lot
of
work,
so
yeah.
A
B
B
I
forgot
what
it's
called
a
page
speed,
so
we've
got
page
speed,
we've
got
speed
index,
we've
got
something
else
called
a
black
box
exporter,
which
is
something
else.
We've
got
something
called
Pingdom,
which
is
another
tool
that
we
use
and
we've
got
all
of
these
things
and
they're
all
monitoring
slightly
different,
but
slightly
similar,
URLs
right
and
like
there's.
No,
we
can't
do
a
lot
of
analysis
because
they're
all
kind
of
similar
bit
different,
and
so
what
I've
been
trying
to
think
about
is
like.
B
There's
lots
and
lots
of
URLs
and
kind
of
built
up
this
thing
where
we've
got
all
the
different
tools
and
we
can
export
the
urls.
You
know
for
speed
index
for
paint
Pingdom
for
black
box
exporter
for
the
google
page
index,
page
speed
exporter,
all
of
these
different
tools
and
what
I
could
do
with
it
is
I
could
tag
each
one
of
these
things
with
a
feature
category.
So
we
could
say
that's
the
tree
in
the
tree
view
source.
A
B
B
A
That
sounds
great
Andrew,
because
I'm
just
sending
a
link
on
chat
because
we're
doing
the
management
of
the
URLs
that
get
grabbed
on
to
that
site.
Speed
through
that
repo,
and
it
seems
very
similar
to
what
you're
doing
we
have
a
distinction
between
login
URLs
and
not
logged
in
here.
Also
that
we
can
access
I
start.
A
B
B
A
A
So
if
we
need
to
get
someone
on
the
source
code
team
to
work
on
this
as
a
deliverable
I'm
all
for
it,
you
have
my
support,
so
I
feel
like
that
would
be
the
greatest
candidate,
something
in
source
code
to
get
experimenting
with
the
with
the
server-side
rendering
ends
the
file
tree.
The
repository
file
tree
seems
like
the
greatest
candidate,
because
it's
simple,
it
doesn't
have
a
lot
of
interaction,
but
it's
yes.
We
need
to
be
super
snappy.
A
The
other
aspect
we
didn't
cover
by
the
way
Andrew
is
that
one
thing
is
performance
of
rendering
the
page
right
doing
it
very
fast,
but
then
render
performance
of
interactions.
So
once
you
go
from
you
traverse
the
file
tree,
you
go
from
folder
to
folder
to
folder
to
folder.
That
is
not
being
tracked,
I
think
anywhere,
but
it
is
something
that
improved
significantly
once
we
did
this
refactor,
so
the
page
load
was
kind
of
like
the
same,
but
moving
from
folder
to
folder
were
like
five
hundred
percent
faster,
just.
B
A
B
B
A
Tell
you
that
there's
like
a
so
we
can
track
those,
because
those
are
usually
the
ones
that
have
the
the
router
handling
on
on
the
front
end.
So
we
have
a
view
router
and
only
a
handful
of
applications
have
of
your
router
installed.
That's
one
of
the
others.
The
design
management
looks
like
the
designs
tab
on
the
issues
and
there's
not
much
else.
It
has
it.
B
Very
important
for
us
to
have
channels
which
is
optimized
right
and
as
soon
as
that
got
slow,
because
it's
long
in
the
application
we
would
care
about
it
and
people
would
complain
and
and
and
so
that
was
critical
to
us.
So
it
builds
up
a
very
small
piece
of
infrastructure
that
was
kind
of
like
startup
upper
like
it
was
just
an
API
and
you
could
say
start
of
operation,
end
of
operation
and
and
then
what
would
happen
is
we'd
use
the
send
beacon
API
to
send
those
back
to
the
server
you
know.
B
So,
even
if
you
changed
page
at
the
end
of
it,
it
would
still
you
know
the
browser
make
sure
that
it
go
back
and
and
then
on
the
server
side.
We
basically
had
a
very
simple
restful
endpoint,
because
you
don't
have
much
control
with
send
beacon.
It's
just
a
post
and
we
would
take
that
and
all
we
do,
that
is,
is
drop
it
into
our
metrics
platform,
which
was
dated
up
there.
But
it's
no
different
that
the
technology
will
be
exactly
the
same,
and
so
that
was
a
critical
metric
to
us.
A
B
A
B
A
B
Second
issue:
what
we
did
this
is
just
like
a
little
thing
to
kind
of
look
at
or
experiment
with.
We
did
some
stuff
with
kind
of
hacking
web
pack-
and
maybe
this
is
a
better
conversation
to
have
with
with
Lukas
again,
but
we
had
it
that
we
had
two
compiles:
a
debug
compile
and
a
non
debug
compile,
and
that's
all
those
performance
marks
and
the
console
logs
and
everything
basically
resolved
answered
nothing
in
the
production
compile
and
a
debug
compile
they.
They
were
all
in
there.
So
that's.
A
B
A
A
B
A
You
you
know
what
I
I
come
from
a
time
where
JavaScript
wasn't
even
a
thing
and
I
keep
seeing.
So
we
went
through
all
those
stages
of
unobtrusive
JavaScript's,
making
sure
that
the
page
that
is
there
and
then
we
just
go
and
hide
it.
We
did
this
in
2003
right.
The
thing
is
the
industry
went
far
out
into
the
JavaScript
spectrum,
but
the
concepts
like
the
browser,
the
timing,
they're
still
the
same,
the
HTTP
still
the
same.