Key front-end performance metrics and how to capture them
Recently I began to look into how an application was performing, on the front-end.
I was frustrated how much time it took me to work out which metrics I should use but mainly to obtain those stats. So this post is an attempt to try and save somebody else the same effort.
Which Metrics
These were calculated using several different sources including the CPP (content performance policy) spec, as well as a couple of ‘FE Performance Checklist’ articles (e.g. SmashingMag).
It was important to remember that browser Extensions (e.g. AdBlock) can have a big (usually) negative impact on performance, so turning them off before profiling is crucial.
The metrics I decided on were:
First Meaningful Paint:
Indicates when the user can first see something rendered on the page. This is the Paint following the layout with a high “Layout Significance”.
Time to Interact:
Indicates when the page will respond to a users action so they can interact with page objects. Taken from the DomInteractive event from the Navigation Timing API.
Interaction frame rate:
A users device typically runs a screen refresh rate of 60fps. Anything which runs on the screen below this has the possibility of appearing juddery or janky.
A common cause of low frame rate is un-optimised Javascript or excessive writing/reading of the DOM (thrashing).
Interaction response time:
The lower this is, the faster it will appear to happen for the user. This metric is not very concrete as often there are delays set onto animations by design.
This includes the time for; click->process->rasterize→GPU redraw.
OnLoad finished:
The onLoad event is triggered when the entire page has finished downloading/parsing/rendering everything. This does not include any assets loaded asynchronously via async/defer attributes.
DOM Processing:
Includes parsing the HTML into the DOM and CSSOM plus executing any Javascript.
Page rendering:
Handles downloading images and any other resources (fonts) for the page. The fewer resources, the lower this will be.
Gethering these metrics
Through a mixture of Chrome devtools and Navigation Timing API we can gather all of them mentioned above. Nav Timing API calculations below can be copy-pasted into your websites console and run from there.
Metric | How to obtain
First Meaningful Paint | (via Chrome Devtools) Timeline -> Event Log -> filter ‘firstMeaningfulPaint’
Time to Interact | (via Nav Timing API) performance.timing.domInteractive — performance.timing.navigationStart
Interaction frame rate + Response time | (via Chrome Devtools) Timeline -> start/click/stop (Observe the green and red bars just below the time bar. Green for ok frame-rate, red for high frame-rate. Hover your cursor over the bar for the FPS result).
OnLoad | (via Nav Timing API) performance.timing.loadEventEnd — performance.timing.navigationStart
DOM processing | (via Nav Timing API) performance.timing.domContentLoadedEventEnd — performance.timing.domLoading
Page rendering | (via Nav Timing API) performance.timing.loadEventEnd — performance.timing.domContentLoadedEventEnd
Industry defined targets
Its important to measure the results against some KPI (key performance indicators) but here is a list of a couple of general industry standard targets to help you get started.
First Meaningful Paint <1.25 seconds
Time to Interact <1.5 seconds
Interaction frame rate 60fps
Interaction response time <100ms
Quick wins
- Make external scripts async.
- Make external styles media=”print”.
- Measure JS bundle and its dependencies.
I hope this article has been useful in someway, its tricky to keep a grasp on whats important to measure, why and how. But for now, these seem like the safest bet.
Im aware none of this includes how to fix any potential problems, but that will be a future post.
