Performance Basics

It’s Black Friday. A fashion shop launches a new product page with a gorgeous full-screen photo. On the office Wi-Fi it looks perfect. On a phone on a train, customers stare at a blank white screen for six seconds, then the photo slowly paints in, then a promo banner pops in and pushes the “Add to cart” button down just as they tap it. They tap the banner by mistake. Many of them leave.

Nothing was “broken” in the functional sense. Every button worked. But the page failed for the people who mattered most. That’s why performance is a quality issue, and why testers should notice it, measure it and report it well.

Why it matters

• Users leave. Google’s research found that as mobile page load time goes from 1 to 3 seconds, the chance that a visitor bounces rises by about a third. Slow checkouts mean abandoned carts.
• Frustration and mistakes. Content that jumps around makes people tap the wrong thing: the wrong product, the wrong amount, an ad.
• Search ranking. Google uses page experience signals, including Core Web Vitals, as part of its ranking.
• Cost and fairness. Many users are on cheap phones and expensive mobile data. A 4 MB image costs them real money and battery.

Perceived vs real performance

There are two kinds of “fast”:

	Real performance	Perceived performance
What it is	Measured time: how many seconds until things load	How fast it feels to the user
Examples	Load time, bytes transferred, server response time	Something useful appears quickly, skeleton screens, instant feedback on taps
Example bug	The page needs 7.4 MB and 14 requests to show a product	The page shows a blank screen for 3 seconds, even though the total load is only 4 seconds

A page that shows the main content in 1 second and finishes loading the footer later feels faster than one that shows everything at once after 3 seconds. Testers should report both: the numbers, and how it felt.

Core Web Vitals in one table

Core Web VitalsCore Web VitalsGoogle's key page experience metrics: loading (LCP), responsiveness (INP) and visual stability (CLS).Open in glossary → are Google’s three key metrics for user experience. Learn these thresholds; you’ll see them in every tool:

Metric	Measures	Good	Needs improvement	Poor
LCP: Largest Contentful Paint	Loading. When the biggest visible element (hero image, headline) appears	≤ 2.5 s	2.5–4 s	> 4 s
INP: Interaction to Next Paint	Responsiveness. How long the page takes to visibly react after a tap, click or key press	≤ 200 ms	200–500 ms	> 500 ms
CLS: Cumulative Layout Shift	Visual stability. How much content unexpectedly jumps around	≤ 0.1	0.1–0.25	> 0.25

Page load lab

This lab simulates loading a shop page. It starts on Fast 4G with a 4× CPU slowdown. (Lighthouse’s mobile test uses the same 4× CPU slowdown with an even slower network, similar to Slow 4G, to imitate a mid-range phone.) Try this:

Page load lab

A simulated load of a shop page. Throttle the network and CPU like in DevTools, switch fixes on, and watch the waterfall and Core Web Vitals react.

NetworkNo throttlingFast 4GSlow 4G3GCPUNo CPU throttling4× slowdown6× slowdown

Fixes

Compress imagesWebP at the right size: hero 2.5 MB → 110 KBLazy-load below the foldloading="lazy" on products 3–6Defer & split JavaScriptdefer + ship less code: 480 → 140 KBReserve spacewidth/height on images, min-height for the bannerRepeat visit (cache)static files come from the browser cache

Turn all fixes off

LCP

3.2 s

Needs improvement

INP (Add tap)

680 ms

Poor

CLS

0.28

Poor

FCP

3.0 s

Poor

Requests

14

on first load

Transferred

7.4 MB

over the network

Network waterfall

FCP LCP Fully loaded waiting

NameSize02.0 s4.0 s6.0 s

• shop.example.com30 KB
• styles.css60 KBblocking
• app.js480 KBblocking
• inter.woff240 KB
• logo.svg4 KB
• hero.jpg2.5 MB
• api/products25 KB
• promo.js (ads cdn)45 KB
• product-1.jpg700 KB
• product-2.jpg700 KB
• product-3.jpg700 KB
• product-4.jpg700 KB
• product-5.jpg700 KB
• product-6.jpg700 KB

ShopCo

Free delivery over €30 · today only

Summer sale
up to −30%

Bestsellers

Linen shirt

€29Add

Straw hat

€19

Sandals

€39

Sunglasses

€24

Beach towel

€15

Tote bag

€22

Layout shift +0.04

When products appear, tap “Add” and feel the delay

Replay load7.6 s

Filmstrip

1.3 s

2.5 s

ShopCo

Free delivery over €30 · today only

Summer sale
up to −30%

Bestsellers

Linen shirt

€29Add

Straw hat

€19

Sandals

€39

Sunglasses

€24

Beach towel

€15

Tote bag

€22

Layout shift +0.14

3.8 s ⚡shift

ShopCo

Free delivery over €30 · today only

Summer sale
up to −30%

Bestsellers

Linen shirt

€29Add

Straw hat

€19

Sandals

€39

Sunglasses

€24

Beach towel

€15

Tote bag

€22

5.1 s

ShopCo

Free delivery over €30 · today only

Summer sale
up to −30%

Bestsellers

Linen shirt

€29Add

Straw hat

€19

Sandals

€39

Sunglasses

€24

Beach towel

€15

Tote bag

€22

6.3 s

ShopCo

Free delivery over €30 · today only

Summer sale
up to −30%

Bestsellers

Linen shirt

€29Add

Straw hat

€19

Sandals

€39

Sunglasses

€24

Beach towel

€15

Tote bag

€22

Layout shift +0.04

7.6 s ⚡shift

• +0.14at 3.2 s: Hero image loaded without reserved space and pushed the text down
• +0.10at 3.3 s: Promo banner was inserted above the content
• +0.04at 7.6 s: Product images without width/height made the cards grow

Simplified model for learning: real browsers prioritize requests and calculate CLS in time windows, but the cause and effect is the same.

What manual testers can observe and measure

The waterfall (DevTools Network panel)

The Network panel (new to it? see DevTools for Testers) lists every request the page makes, with a waterfall showing when each started and finished. Read it like this:

• Long bars = slow downloads (big files) or slow servers (long waiting time).
• Waiting (TTFB) in the Timing tab = the server is slow. Report to the backend team.
• Many bars stacked one after another = requests that depend on each other (a “chain”): script → API → images.
• Size column: anything over a few hundred KB for an image is suspicious. “(memory cache)” or “(disk cache)” means it wasn’t downloaded.
• Repeated rows with the same URL = the same data fetched many times.
• At the bottom: total requests, transferred bytes, and Load time.

Common things to look for

#	Problem	What you see	Typical severity
1	Huge images	A 3–5 MB photo for a 400 px wide slot. Hurts: LCP	High
2	Render-blocking scripts or CSS	Blank screen until a large file in the head downloads. Hurts: FCP, LCP	High
3	Slow API or server	Long “Waiting (TTFB)” bar; spinner for seconds. Hurts: Perceived speed (LCP if it holds the main content)	High
4	Layout shifts	Content jumps when an image, ad, banner or font loads. Hurts: CLS	Medium–High
5	Too many requests	Dozens of small files, or the same call repeated. Hurts: Load time, server load	Medium
6	Slow interactions	Tap “Add to cart”, nothing happens for half a second. Hurts: INP	High
7	No caching	Second visit downloads everything again. Hurts: Load time, data usage	Medium
8	Memory leak	The tab gets slower and slower after 20 minutes of use, then crashes. Hurts: Responsiveness, crashes	Medium–High

Lab data vs field data

• Lab data comes from a test you run in a controlled setup: Lighthouse, DevTools, WebPageTest. It’s repeatable and great for debugging, but it’s one device, one network, one moment.
• Field data comes from real users on real devices. Google’s Chrome UX Report (CrUX) collects it from Chrome users who opted in, and PageSpeed Insights shows it at the top of the report (for pages and sites with enough traffic), based on the last 28 days. Core Web Vitals are judged at the 75th percentile: 3 out of 4 visits should be “good”.

If lab and field data disagree, both can be right: maybe your test was on a fast network but real users are on slow phones, or the slow part only happens after interactions that Lighthouse doesn’t do.

Find the culprits

Here’s a recorded waterfall from a slow sneaker product page, as you’d capture it in DevTools. It has five performance problems. Use the filters, sort by size or time, and click requests to read their details.

🐞 Bug hunt: Sneaker product page waterfall

This demo has 5 hidden bugs. Explore it like a tester, then check your findings.

Found0/5

Lighthouse-style summary · Fast 4G, 4× CPU

LCP

5.0 s

Poor

CLS

0.19

Needs improvement

FCP

2.4 s

Needs improvement

Requests

33

5.7 MB transferred

LCP element: img.hero

AllDocCSSJSImgFetch/XHRSortWaterfallSizeTime

NameSize02.0 s4.0 s6.0 s

• product/sneakers-x232KB
• styles.css58KB
• app.bundle.js1.1MB
• logo.svg3KB
• hero-sneakers.jpg4.2MB
• inter.woff246KB
• analytics.js24KB
• promo-banner.js42KB
• api/recommendations18KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• api/cart/count0KB
• product-1.webp38KB
• product-2.webp39KB
• product-3.webp41KB
• product-4.webp42KB

Layout shifts⚡

Click a request to see its details, like the Headers and Timing tabs in DevTools. The ⚡ marker on the bottom track is a layout shift.

⚡ Layout shift at 5.7 s (Performance panel)Show

1. 1

   Hint: Sort by Size. Then check which element is the LCP element.

   A 4.2 MB hero image is the LCP element

   hero-sneakers.jpg is 4.2 MB and takes about 4.4 s to download on Fast 4G. It is the LCP element, so LCP is 5.0 s (poor). A correctly sized WebP or AVIF would be around 100–250 KB.

   Reveal answer✓ I found this
2. 2

   Hint: Which file must finish before anything is painted? Look at the Render-blocking field.

   A 1.1 MB JavaScript bundle blocks rendering

   app.bundle.js is loaded with a plain <script> in the head, without defer. The screen stays blank until it downloads and runs, so FCP is 2.4 s. Its long tasks also slow down taps (INP).

   Reveal answer✓ I found this
3. 3

   Hint: Filter by Fetch/XHR and look at the Waiting (TTFB) time of each request.

   The recommendations API waits 3.1 s for the server

   api/recommendations spends 3,080 ms waiting for the first byte and only 30 ms downloading. The problem is on the server, not the network. The "You may also like" section stays empty, and the product images can only start after it.

   Reveal answer✓ I found this
4. 4

   Hint: Look at the Layout shifts track and open its details.

   A late promo banner causes a big layout shift

   At 5.7 s a script from cdn.adsnet.example inserts div.promo-banner above the product, pushing everything down by 120 px. CLS is 0.19 (needs improvement). The space should be reserved in advance.

   Reveal answer✓ I found this
5. 5

   Hint: Filter by Fetch/XHR and count the rows with the same name.

   The cart count is requested 20 times

   api/cart/count is called 20 times during one page load by CartBadge.render(), probably once per re-render. One request is enough. It wastes data, battery and server capacity, and under load it can take the API down.

   Reveal answer✓ I found this

Now decide what to do about each problem:

🔧 Match the fix

For each culprit from the waterfall, choose the best fix and the Core Web Vital it improves.

1. 1hero-sneakers.jpg is 4.2 MB

   Fix for hero-sneakers.jpg is 4.2 MBChoose a fix…Resize and compress it (WebP/AVIF, srcset), keep it eagerAdd defer, split the bundle, ship less codeReport to backend: speed up or cache the endpoint, show a skeletonReserve space (min-height) or show it as an overlayRequest once and share the result (dedupe or cache)Metric improved by fixing hero-sneakers.jpg is 4.2 MBMetric it helps…LCPINPCLSNone of the three directly

2. 2app.bundle.js (1.1 MB) is render-blocking

   Fix for app.bundle.js (1.1 MB) is render-blockingChoose a fix…Resize and compress it (WebP/AVIF, srcset), keep it eagerAdd defer, split the bundle, ship less codeReport to backend: speed up or cache the endpoint, show a skeletonReserve space (min-height) or show it as an overlayRequest once and share the result (dedupe or cache)Metric improved by fixing app.bundle.js (1.1 MB) is render-blockingMetric it helps…LCPINPCLSNone of the three directly

3. 3api/recommendations waits 3.1 s for the server

   Fix for api/recommendations waits 3.1 s for the serverChoose a fix…Resize and compress it (WebP/AVIF, srcset), keep it eagerAdd defer, split the bundle, ship less codeReport to backend: speed up or cache the endpoint, show a skeletonReserve space (min-height) or show it as an overlayRequest once and share the result (dedupe or cache)Metric improved by fixing api/recommendations waits 3.1 s for the serverMetric it helps…LCPINPCLSNone of the three directly

4. 4Late promo banner shifts the page by 0.19

   Fix for Late promo banner shifts the page by 0.19Choose a fix…Resize and compress it (WebP/AVIF, srcset), keep it eagerAdd defer, split the bundle, ship less codeReport to backend: speed up or cache the endpoint, show a skeletonReserve space (min-height) or show it as an overlayRequest once and share the result (dedupe or cache)Metric improved by fixing Late promo banner shifts the page by 0.19Metric it helps…LCPINPCLSNone of the three directly

5. 5api/cart/count is requested 20 times

   Fix for api/cart/count is requested 20 timesChoose a fix…Resize and compress it (WebP/AVIF, srcset), keep it eagerAdd defer, split the bundle, ship less codeReport to backend: speed up or cache the endpoint, show a skeletonReserve space (min-height) or show it as an overlayRequest once and share the result (dedupe or cache)Metric improved by fixing api/cart/count is requested 20 timesMetric it helps…LCPINPCLSNone of the three directly

Check my answers Reset

Answer all five to check.

Writing a useful performance bug report

“The page is slow” can’t be fixed. A good performance report is specific and measurable, so a developer can reproduce it and confirm the fix. Include:

• Conditions: device (or “MacBook, Chrome 4× CPU throttling”), browser and version, network (Wi-Fi, “Fast 4G” throttling), cache disabled or not, logged in or not, first or repeat visit.
• Numbers: LCP, CLS, INP or TBT, load time, transferred size, and the slow request with its timings. Measure 3–5 times and give the median, because single runs vary.
• The culprit, if you found it: “hero-sneakers.jpg is 4.2 MB”, “api/recommendations TTFB 3.1 s”.
• Before/after or comparison: “Was 2.1 s LCP in release 4.12, 5.0 s in 4.13”, or “Competitor page loads in 1.8 s on the same setup”.
• Evidence: a screen recording or the Performance panel’s screenshots, a Lighthouse report (save as HTML or JSON), and a HAR fileHAR fileA file that records every network request and response a web page made.Open in glossary → exported from the Network panel.

See How to Write Bug Reports for the general structure.

Tools and how to use them

Lighthouse (in Chrome DevTools)

DevTools Network panel

• Tick Disable cache to simulate a first visit (only while DevTools is open).
• Use the throttling dropdown (Fast 4G, Slow 4G, 3G, or custom) to simulate slow networks. See network throttlingNetwork throttlingDeliberately slowing the connection to test how an app behaves on poor networks.Open in glossary →.
• Filter by type (Fetch/XHR, JS, CSS, Img…), sort by Size or Time, and click a request to see Headers and Timing (Queueing, Waiting for server response, Content download).
• Right-click › Save all as HAR (sanitized), or use the ↓ export icon, to attach the full recording to a bug.

DevTools Performance panel

• Open the Performance panel. Its landing view shows live LCP, CLS and INP for your own interactions on the page, so you can measure INP manually: click around and watch the number.
• Use the CPU throttling setting (4× or 6× slowdown) to imitate a mid-range or low-end phone.
• Click Record and reload to capture a load with screenshots (a filmstrip), long tasks on the main thread, and a Layout shifts track.
• In More tools › Rendering, tick Layout shift regions to flash a highlight wherever content shifts.

PageSpeed Insights

Go to pagespeed.web.dev and enter a public URL. The top section shows field data from real Chrome users (if the page has enough traffic); the bottom shows a Lighthouse lab run from Google’s servers. It’s the quickest way to see whether real users have a problem.

Example test cases

Checklist

Performance test checklist

0 of 13 checked

Copy

• Tested with network throttling (Fast 4G / Slow 4G) and CPU slowdown, not only on fast Wi-Fi
• LCP is 2.5 s or less on a mobile profile (median of several runs)
• CLS is 0.1 or less: no content jumps when images, ads, banners or fonts load
• Interactions (add to cart, open menu, filter) respond within 200 ms
• No screen stays blank for long: something useful appears quickly
• Images are compressed and sized for their slot; below-the-fold images lazy-load
• The hero / LCP image is not lazy-loaded
• No large render-blocking scripts in the head
• No duplicate or unnecessary API requests
• Slow server responses (high TTFB) are reported with timings
• Repeat visits load static files from the cache
• Long sessions do not keep growing memory (Performance monitor)
• Field data (PageSpeed Insights / CrUX) checked for key pages, if available

Check your understanding

Quick quiz

0/5 answered · 0 correct

1. 1.What is the "good" threshold for Largest Contentful Paint?

   A1 second or lessB2.5 seconds or lessC4 seconds or lessD10 seconds or less

2. 2.A banner appears late and pushes the product down. Which metric gets worse?

   ALCPBINPCCLSDTTFB

3. 3.In the Network panel, a request spends 3 s in "Waiting for server response" and 20 ms downloading. What is the likely cause?

   AThe file is too bigBThe user's network is slowCThe server or API is slow (high TTFB)DThe browser cache is full

4. 4.Lighthouse shows LCP 1.8 s, but PageSpeed Insights field data says real users see 4.2 s. Which statement is best?

   ALighthouse is brokenBField data is always wrongCReal users probably have slower devices or networks than your test setup; investigate with heavier throttlingDThere is no problem because the lab score is good

5. 5.Which detail makes a performance bug report most useful?

   A"It feels slow to me"BThe exact conditions (device, browser, throttling, cache) and measured numbers from several runsCA screenshot of the finished pageDThe Lighthouse score only

Key takeaways

• Performance is a quality issue: slow and jumpy pages lose users and cause mistakes.
• Know the Core Web Vitals: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1.
• Always test with network and CPU throttling: your laptop is much faster than most users’ phones.
• In the waterfall, look for huge files, render-blocking scripts, slow server waits (TTFB), repeated requests and late content that shifts the layout.
• Lab data (Lighthouse, DevTools) helps you debug; field data (PageSpeed Insights / CrUX) shows what real users experience.
• Report performance bugs with conditions, numbers from several runs, the culprit, a comparison and evidence (Lighthouse report, HAR, recording).
• Load and stress testing (JMeter, k6) is a separate specialty.