cft

Don’t Forget About Web Performance!

A guide for how to track and boost critical performance metrics


user

Bowei Han

2 years ago | 4 min read

Amazon released a famous statement in the late 2000s stating that every hundred milliseconds of latency cost them 1% of sales.

Akamai performed a study in 2017 and found that a hundred-millisecond delay can hurt conversion rates by 7%.

Google determined that the probability of bounce increases by 32% as page load time goes from 1 second to 3 seconds.

Bounce Rate vs. Page Load Time (source: Google/SOASTA Research, 2017)
Bounce Rate vs. Page Load Time (source: Google/SOASTA Research, 2017)
As an internet company, you should probably be more concerned about web performance.

How do you know if your site is fast enough?

Tough to say…without knowing your use-case.

However, it’s almost always better to have a site that feels faster. Perceived performance is impacted by metrics like:

  • How long a page stays blank.
  • How long it takes for a page title to show up.
  • How long it takes before a user can read the critical content of a page.
  • How long it takes before a user can interact with the page.

You might experience significant improvements in user behavior if you spend some time tracking and improving your site metrics. So why not give it a shot?

Here are some metrics to get you started!

Metric: Page Load

The overall load time for a page; traditionally measured when window.onload is fired. The onload event fires at the end of the document loading process when [1] all of the objects in the document are in the DOM, and [2] all of the images, scripts, links, and sub-frames have finished loading.

Page load is readily measured by leveraging the browsers’ performance API along with a window event handler.

window.onload = function(){
setTimeout(function(){
let t = performance.timing;
console.log(t.loadEventEnd - t.startTime); // PAGE LOAD
}, 0);
}

Page load code (source: author)

Target: Less than 2 seconds.

Improve this metric by…

  • Optimizing image delivery and asset size
  • Reducing the number of blocking HTTP requests
  • Minifying code and reducing payload sizes
  • Leveraging a content delivery network (CDN)
  • Eliminating redirects

Metric: Time to Interactive (TTI)

The time it takes for a user to be able to interact with a web page in a meaningful way for at least 5 seconds. TTI typically occurs after a page begins to render but before it has fully loaded; it can be a decent indicator for user-perceived performance.

Measuring TTI can be a bit complex…but thankfully we have tools such as Google’s Lighthouse. Check out this snippet of a lighthouse report.

Lighthouse report showing TTI (source: author)
Lighthouse report showing TTI (source: author)

Target: Less than 5 seconds.

Improve this metric by…

  • Minimizing main-thread work
  • Minifying code and reducing payload sizes
  • Preloading key requests
  • Reducing the use of third-party code
  • Reducing JavaScript execution time

Metric: Time to First Paint (TTFP)

The time it takes for a user to see something other than a blank screen after navigating to a page. This is one of the biggest factors that affect the perceived performance of a web page!

TTFP can be measured by using the browsers’ performance API and the Paint Timing API.

// Create the Performance Observer instance.
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntriesByName('first-contentful-paint')) {
const { startTime } = performance.timing;
console.log(entry.startTime - startTime); // TTFP / FCP
observer.disconnect();
}
});
// Start observing paint entry types.
observer.observe({
type: 'paint',
buffered: true,
});

TTFP code (source: author)

Target: Less than 1 second.

Improve this metric by…

Metric: Time to First Byte (TTFB)

The time it takes for the browser to receive the first byte of data from a web server when requesting a new page.

TTFB is important because the first byte of data will almost always be part of the base HTML of the site. A delay in TTFB can result in slow page title loads — sometimes known as Time to Title — which can damage the perceived legitimacy of your web page!

TTFB can be measured by using the browsers’ performance API.

const { responseStart, startTime } = performance.timing;
console.log(responseStart - startTime); // TTFB

TTFB code (source: author)

Target: Less than 200 milliseconds.

Improve this metric by…

  • Eliminating redirects
  • Caching all static content
  • Reducing the amount of required dynamic content
  • Improving web server performance
  • Optimizing blocking database queries

Metric: DNS Lookup Time

The time it takes for a domain name to be translated into an IP address.

DNS lookup can take as long as seconds in extreme cases if you have a slow DNS provider. This process completely blocks a web page from loading so it’s safe to say that a slow DNS lookup will result in a slow web page.

DNS Lookup Time can be measured by using the browsers’ performance API.

const { domainLookupEnd, domainLookupStart } = performance.timing;
console.log(domainLookupEnd - domainLookupStart); // DNS Lookup Time

DNS lookup time code (source: author)

Target: Less than 100 milliseconds.

Improve this metric by…

  • Getting a faster DNS provider
  • Choosing better DNS cache TTL
  • Eliminating requests to different domains
  • Using a CDN
  • Prefetching DNS

Metric: Network Payload Size

The amount of data requested by a web page.

Larger network payload sizes mean slower load times, higher storage costs, and higher data usage for your users.

Similar to TTI, network payload size can be measured using Lighthouse. You can also find the sizes of individual request payloads directly in the developer tools of most common browsers.

Lighthouse payload diagnostics (source: author)
Lighthouse payload diagnostics (source: author)

Target: Less than 1600 kilobytes.

Improve this metric by…

  • Reducing image and asset sizes
  • Caching and pre-caching expensive requests
  • Deferring certain requests using the PRPL pattern

Metric: Time to Critical Feature (TTCF)

The time it takes to render the critical feature of your web page.

Examples of a critical feature could include the top-rated youtube video or the trending tweet of the week. The important thing to remember is that TTCF is user-defined — it’s up to you to track the most important element on your page.

TTCF can be measured using the Element Timing API. Note — this API is still in draft.

<div elementtiming='important'>
My Critical Feature
</div>
...
<script>
const observer = new PerformanceObserver((list) => {
let perfEntries = list.getEntries();
// find your entry
console.log(entry.renderTime || entry.loadTime); // TTCF
});
observer.observe({type: 'element', buffered: true});
</script>

TTCF Element Timing code (source: author)

An alternative to using the Element Timing API is to leverage onload for supported HTML tags: <body>, <frame>, <iframe>, <img>, <input type=”image”>, <link>, <script>, <style>

<img
src="https://www.apple.com/ac/structured-data/images/open_graph_logo.png?202003072104"
onload="console.log(performance.now())" // TTCF
/>

TTCF Onload code (source: author)

Target: Less than 2.5 seconds.

Improve this metric by…

  • Finding and speeding up the critical rendering path (again, PRPL)
  • Improving page load time

Thanks For Reading.

Upvote


user
Created by

Bowei Han


people
Post

Upvote

Downvote

Comment

Bookmark

Share


Related Articles