Measuring Front-End Performance

How do you measure good front-end performance as a developer? What are the most common metrics in use? What front-end performance optimization tools should you use? What are the best front-end performance optimization techniques to learn? Let’s find out!

Common Performance Metrics

These are metrics which many of the top web performance tools (more on these later) use to gauge how fast a website loads.

Time to First Byte

This metric is used to measure the responsiveness of a web server. So when you visit a website, how long does it take the webserver to respond to requests made by the browser. Bad server config or poor back-end coding would be responsible for poor performance in this metric, rather than front-end code. (Have you considered going serverless to enjoy the benefits?)

First Contentful Paint

First contentful paint is a metric measuring from typing in the URL and keying enter to the point where the browser starts to render the first bit of visible content. Think of it as the time spent on the blank, white loading screen before the website loads the first bit of content.

First Meaningful Paint

This is another paint-oriented metric that measures how long it takes a browser to render the majority of above the fold content, including any web font dependencies (Google fonts, Typekit, etc) the website has. Think of this as how long it takes the browser to load something recognizable and expected.

Speed Index

Speed index measures generally how long it takes for all of the pages content to become visible during load. The lower the speed index metric, the better the website’s performance. Specifically its perceived loading time.

First CPU Idle

This metric measures when a web page becomes minimally interactive, in that users can begin to use some - but not all - on page UI components and have them respond to input and actions in a reasonable amount of time.

Time to Interactive

This is very similar to the First CPU Idle metric but requires a more complete level of page interactively. For this to trigger, a page must display the majority of its useful content and register most of the page’s event listeners. In addition, any user input or actions must be responded to within 50 milliseconds.

Estimated Input Latency

Estimated Input Latency measures how long your website takes when responding to any user input. It’s measured in milliseconds and during the most intensive 5s of page load. If this latency figure is over 50 milliseconds, this may result in laggy interactions for the user.

Last Painted Hero

This metric tracks how long it takes for the more important elements of the page to render. In a typical page layout, not all elements are created equal because as designers, we want to guide the user down a certain journey. Depending on the tool, this may be triggered when the biggest image is rendered, or the headline text in a <h1> for example.

Document Complete

Document complete tracks the time it takes for the browser’s onLoad event to fire, which happens when all static assets, such as images, CSS, JavaScript have loaded. This is a useful metric to get an overview of how fast a website is loading.

Fully Loaded

This isn’t too dissimilar from the document complete event, except that it factors in any asynchronous activity which occurs (via 3rd party scripts) after the browser’s onLoad event has come and gone. Typically a measurement is finally captured when network activity has ceased for around 2 seconds.

This is useful because it allows you to get an idea of the impact 3rd party scripts are having on a website’s loading, which is something the Document Complete metric typically wouldn’t cover.