Site-Speed That Sticks

site-speed that sticks

hi, i’m harry

five key topics

1. metrics 2. localhost 3. backstops 4. monitoring 5. playbook

metrics

not all metrics are born equal

different metrics for different people on different occasions with different
levels of disclosure

kpis, enablers, predictors

definition + target

what are we working toward?

of interest to the business

core web vitals

‘which number on which dashboard of which service?’

“We want a one-second improvement in Largest Contentful Paint.” —
My Client

enablers

metrics that directly influence kpis

of interest to engineering teams

ttfb, input delay

predictors

signals of good/bad performance

highly quantitative

of interest to engineers

bundle size, long tasks, blocking css

great for root-causing and reverse engineering

localhost

localhost is: seldom live-like, pretty dang fast, un-bundled

know your tools inside out

csswz.it/perfnow25

one weird trick…

// plugins/delay.server.ts export default defineNuxtPlugin(async () => { await new
Promise(resolve => setTimeout(resolve, 900)) })

core web vitals are too big for localhost

if you’re working locally, measure locally

bare-metal metrics

external: 1842ms inlined: 1250ms

these are very private metrics

backstops

…and budgets

what is the worst possible performance we will accept?

set it to the worst reading in the last release
cycle

this is where synthetic testing comes into it

synthetic testing; real user monitoring

when to fail a release

predictors as tripwires

budgets versus targets

budgets are backstops; targets are ambitions

target == kpi

monitoring

the m in rum stands for monitoring

“Insanity is doing the same thing over and over again
and expecting different results.” — Rita Mae Brown

it’s the exact same file

you’re monitoring variation in tests

only alert on your kpis

0.9952409649

always follow the numbers

playbook

“Fighting regressions took priority over optimizations […]” — Michelle Vu,
Pinterest

it’s all for nothing if you don’t have a plan

response = f(severity, duration)

severity

acceptable: <10%

moderate: 10–25%

severe: 25–50%

critical: >50%

duration

temporary: 24–48hr

sustained: >48hr

long-term: >1 release cycle

unresolved: many release cycles

a kpi regression of over 10% for one week requires
remediation in the next sprint

a kpi regression of over 100% for one hour requires
rollback immediately

a kpi regression of over 25% for one day requires
remediation in the current sprint

an enabler regression of over any% for any time needs
the team’s attention over the next sprint

a predictor regression of over any% for any time needs
my attention over the next sprint

you need a framework to fill in these blanks

early triage

who, what, when, where, and why?

what has regressed?

when did it start? is it still like that?

where?

is it a business-critical part of the site?

who owns the problem?

can you conduct early triage?

key takeaways

increase confidence

use the right tool for the right job

have a plan of attack

agree; commit

thank you

harry.is/for-hire

Site-Speed That Sticks

Site-Speed That Sticks

More Decks by Harry Roberts

Other Decks in Technology

Featured

Transcript