White Paper

How Fast Does Your

Website Need to Be?
Data, rules, and methodologies to help benchmark and improve
web and mobile performance
 How Fast Does Your Website Need to Be?

Customers are always interested in improv-

General Rule #1: Use more than one
ing the speed and performance of their web
metric to measure page performance
and mobile apps. In many cases, they’ve
already spent time, effort, and money to To really understand how customers experience your pages, you

move to the cloud. They’ve also fundamen- need to measure a few important themes of user experience.

tally changed the way their teams deliver Choose a few categories from different components of your page

software, and might even use Kuberne- experience. Listed below are some of those categories, with New

tes to scale faster. They face tons of com- Relic’s metrics and their definitions:

plexity already, which is why they’d prefer

Page Load Experience
simple answers to the inevitable question
about web performance: “How fast do we • First paint (FP): How long until the first pixel of a back-
need to be?” ground renders

Our answer is usually the same: “It depends.” • First Contentful Paint (FCP): How long until content
begins to render
Admittedly, that’s not a response anyone
• Largest Contentful Paint (LCP): How long until the largest image
wants to hear. Unfortunately, the truth is
or video begins to render
that—while uptime is easy to quantify—
there is no single metric to clearly define User Interactivity
page performance.
• First Interaction: Measures when a user first engages
Studies point to the fact that “faster is bet- with your page
ter.” Gomez, the web performance division
• First Input Delay (FID): The time from when the user engages
of Compuware, found that after three sec-
until the web browser processes the interaction
onds of waiting, up to 40% of users aban-
don a site. Additionally, Walmart found that Visual Stability
improving page speed by even 100ms saw
• Cumulative Layout Shift (CLS): Measures how end users
revenue increase 1%. However, while speed
experience sudden unexpected shifts from your content
is a critical component, it’s only one part of a
dynamically resizing
dynamic page experience.
• Long Tasks: Measures JavaScript code that blocks the
Customers navigate your site on a dizzying
main thread
combination of web browsers (and their dif-
ferent versions), devices (both new and old),

02
 How Fast Does Your Website Need to Be?

and networks (from high-speed to sluggish hotel internet). Each person tolerates speed and perfor-
mance in their own way. Luckily for us, we have data and some general rules to inform the optimi-
zation process.

While “it depends” can be frustrating to hear, it’s a great opportunity to explore web page fun-
damentals, customer happiness, and creating a performance-focused culture throughout a
digital business. Here’s New Relic’s approach to page speed and performance using Full-Stack
Observability, some general rules to follow, as well as a step-by-step guide to creating your
own dashboards to keep tabs on your digital properties.

The right metrics to monitor

There’s no single metric to define page performance. For years, there’s been a prolonged reliance on
page load time (window.onload) as a catchall for measuring and reporting end-user performance.
While that metric was useful for Web 1.0, it’s often misleading when trying to understand mod-
ern pages.

To more precisely measure performance, it’s helpful to capture metrics that reflect how users
perceive the experience your pages deliver. User-centric perceived performance metrics help
site owners understand key components of their page experience, such as how fast they deliver
visual content, how fast their pages respond to user interaction, and how their page creates a
smooth experience when loading.

Google’s Core Web Vitals

LCP
(loading)

We recommend standardizing on Google’s Core Web Vitals for select-

ing and benchmarking performance. Google recommends three mea- Largest Contentful Paint
surements to define page health: Largest Contentful Paint (LCP), First
Good Needs improvement Poor
Input Delay (FID), and Cumulative Layout Shift (CLS). The correspond-
2.5 sec 4.0 sec
ing rankings of “Good,” “Needs Improvement,” and “Poor,” are shown

FID
alongside each measurement. For each measurement, Google recom- (interactivity)

mends the following thresholds for “good,” “needs improvement,” and

“poor” performance across the 75th percentile of your users. New Relic First Input Delay
offers full support for Google’s Core Web Vitals. Here’s how to use our
Good Needs improvement Poor
PageViewTiming event to create dashboards for them.
100 ms 300 ms

How to visualize your page

CLS
(visual stability)

performance with dashboards Cumulative Layout Shift

New Relic is all about your data. Our Real User Monitoring agent offers Good Needs improvement Poor

0.1 0.25
eight total event types, each with dozens of attributes to help mea-
sure, benchmark, and alert on JavaScript errors, single-page appli-

03
 How Fast Does Your Website Need to Be?

cation (SPA) pages’ details, AJAX requests, spans in distributed tracing,

geographical performance, and more. For load timing data specifically,
we have two major event types: PageViewTiming event and Browser-
General Rule #2: Measure
Interaction. Both have the same set of default attributes, but Browser- backend vs. frontend
Interaction has extra features that include AJAX response times and
route changes. For troubleshooting, it’s helpful to
quickly compare server-side and cli-
Let’s use our PageViewTiming event to dashboard all three Core Web ent-side performance. Because New
Vitals and visualize page performance. Relic connects your full stack, we recom-
mend adding TimeToFirstByte (TTFB)
Largest Contentful Paint
(length of time from user’s navigation
1. Use this NRQL query: to first byte of the response) to measure

SELECT percentile(largestContentfulPaint, 75) FROM web server performance. “Good” TTFB

PageViewTiming WHERE appName = 'insert your app performance is generally .2 seconds

name' AND timingName = 'largestContentfulPaint' (200ms) or faster, and “poor” is gener-

ally slower than 1 second. Standardizing
2. Add thresholds recommended by Google’s Core Web Vitals:
on TTFB + LCP + FID + CLS helps align
with Google’s Core Web Vitals, while
also measuring backend performance.

(Note: We need to load large images much faster, because we’ve passed the “poor” threshold.)

3. Quantify good, tolerable, or poor experiences relative to loading visual content:

SELECT percentage(count(*), WHERE largestContentfulPaint < 2.5) AS

'good', percentage(count(*), WHERE largestContentfulPaint >= 2.5 and
largestContentfulPaint < 4) AS 'needs improvement', percentage(count(*),
WHERE largestContentfulPaint >= 4) AS 'poor' FROM PageViewTiming WHERE
appName = 'insert your app name' AND timingName = 'largestContentfulPaint'

04
 How Fast Does Your Website Need to Be?

First Input Delay

1. Use this NRQL query:

SELECT percentile(firstInputDelay, 75) FROM PageViewTiming WHERE appName

= 'insert your app name' AND timingName = 'firstInteraction'

2. Add thresholds recommended by Google’s Core Web Vitals:

05
 How Fast Does Your Website Need to Be?

3. Quantify good, tolerable, or poor experiences relative to page interactivity:

SELECT percentage(count(*), WHERE firstInputDelay < 100) AS 'good',

percentage(count(*), WHERE firstInputDelay >= 100 and firstInputDelay <
200) AS 'needs improvement', percentage(count(*), WHERE firstInputDelay
>= 200) AS 'poor', percentage(count(*), WHERE firstInputDelay is null) AS
'unknown' FROM PageViewTiming WHERE appName = 'insert your app name' AND
timingName = 'firstInteraction'

(Note: Our page is extremely fast responding to user engagement.)

Cumulative Layout Shift

1. Use this NRQL query:

SELECT percentile(cumulativeLayoutShift, 75) FROM PageViewTiming WHERE

appName = 'insert your app name' AND timingName = 'pageHide' SINCE
2 week ago

06
 How Fast Does Your Website Need to Be?

2. Add thresholds recommended by Google’s Core Web Vitals:

(Note: We need improvement; the metric is yellow because we’ve passed the warning threshold.)

3. Find how many users are having good, tolerable, or poor experiences:

SELECT percentage(count(*), WHERE cumulativeLayoutShift < 0.1) AS

'good', percentage(count(*), WHERE cumulativeLayoutShift >= 0.1 AND
cumulativeLayoutShift < 0.25) AS 'needs improvement', percentage(count(*),
WHERE cumulativeLayoutShift >= 0.25) AS 'poor', percentage(count(*), WHERE
cumulativeLayoutShift is null) AS 'unknown' FROM PageViewTiming WHERE
appName = 'insert your app name' AND timingName = 'pageHide' SINCE
2 week ago

(Note: There is a segment of “unknowns” because not all web browsers provide CLS.)

07
 How Fast Does Your Website Need to Be?

View them together:

The importance of lab and field data

So far we’ve talked about data from real users, otherwise known as field data. Lab data is use-
ful for understanding optimal performance and to help find and eliminate poor performance
before you deploy.

Lab data collected from synthetic monitors is useful for optimizing page performance through-
out the DevOps process. It’s called lab data because you’re using a predefined set of conditions
(typically across fast networks, with specific browsers or devices) to simulate user engagement
and measure feedback. Synthetic monitors help tune performance because you can find latency
and errors before releasing to production.
Also, developer-focused synthetic solu-
tions provide the ability to use JavaScript
to fully recreate all page components and
dependencies, therefore site operators can General Rule #3: Be as fast, if not 20% faster,
understand the health of their functionality
than your competition
and performance beyond uptime. Given a limited amount of developers, time constraints, and the
resources deemed necessary to track and measure your online
Modern web pages rely heavily on APIs and
business, it might not be possible to achieve a “good” score in all of
third parties to deliver information. Syn-
Google’s Core Web Vitals. The 20% rule says that in order for users
thetics’ scripted API monitor goes beyond
to barely notice a difference in time duration, it has to be changed by
uptime to show request/response times,
a minimum of 20%. Therefore, we can create synthetic monitors and
connection times, and information on pay-
leverage paint timing metrics (FP, FCP) to compare, and set objective
load size.This helps you determine if your
targets for how quickly we deliver visual content vs. our competition.
APIs are up, fast, and returning valid results.

New Relic One automatically displays third-

party performance in the “resources” sec-
tion of each monitor, and users can leverage
NRQL to further isolate performance outliers.

08
 How Fast Does Your Website Need to Be?

To further tune performance, web developers access Long Tasks, bytes transferred (aka page
weight), page resource performance, and resource waterfall charts for each monitor result.

(Detailed waterfall chart of long tasks, bytes transferred, and requests made)

09
Take action
If you want to create a culture of performance, you must first start with measuring a
few core components of your page experience.

While “it depends” can be frustrating to hear—especially for managers who have enough com-
plexity across backend services and infrastructure—it’s also an opportunity to understand how
sites impact end users, and what drives their online satisfaction. “How fast do we need to be?”
can also result in clearer goals and increased understanding between engineering and market-
ing teams, and better business results.

We encourage you to set up dashboards in

alignment with Google’s Core Web Vitals
and rely on their guidance for thresholds.
Create a few monitors to understand how More helpful resources
quickly you display visual content (FP, FCP)
vs. your competition. Aim to be at least 20% There are also lots of great resources to help inform page

faster. Understand the impact that APIs speed and performance. For general best practices, the

and third parties have on your page perfor- folks at web.dev are your best bet. Rick Viscomi’s chapter

mance. Use New Relic and other great tools on performance from 2019’s Web Almanac is a super-de-

such as Google Lighthouse to find perfor- tailed guide to understanding “where to start.” To help

mance bottlenecks and ensure successful embed performance into your builds and development

deployments. culture, consider establishing a performance budget.

Make sure you follow JavaScript best practices; The Cost
Wherever you are in your page performance of JavaScript by Addy Osmani is a tremendously helpful
journey, remember that web performance resource. Lara Hogan’s Designing for Performance is a help-
is both a science and an art. It’s an examina- ful companion for learning the basics. Tammy Everts’ book,
tion of slivers of time in your web browser, Time Is Money, and her web page WPO stats, help quantify
and an exploration of human behavior. the impact of web performance on business outcome.
However, the most important thing to
remember is that you can’t improve what
you don’t measure. So jump in! Your cus-
tomers are waiting (hopefully not too long).

Experience Full-Stack Observability

See how New Relic can give your end users a better experience with your web and application
properties with our Full-Stack Observability offering, which also includes APM, Infrastructure
Monitoring, Logs in Context, and more.

Sign up for free at newrelic.com/platform/full-stack-observability

© Copyright 2020, New Relic, Inc. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies. 11.2020