How to Improve Website Performance and Page Load Times

To improve website performance, start with real-user data for the affected page and device type, identify which metric is failing, then use a browser trace to find the cause. Make one targeted change at a time and remeasure. A generic speed score does not tell you whether the problem is server response, late resource discovery, large downloads, main-thread work, or layout shifts.

Google’s Core Web Vitals measure loading with Largest Contentful Paint (LCP), responsiveness with Interaction to Next Paint (INP), and visual stability with Cumulative Layout Shift (CLS). At the 75th percentile, the good thresholds are LCP ≤2.5 seconds, INP ≤200 milliseconds, and CLS ≤0.1. Evaluate mobile and desktop separately: a good result does not promise that every visit is fast. Google’s Core Web Vitals guidance explains the metrics and thresholds.

1. Measure the page visitors actually use

Choose a specific URL and segment. Start with a page that matters to visitors, and distinguish mobile from desktop. A site-wide average can hide a slow template or device-specific problem.
Check field data. In PageSpeed Insights, check whether the data shown is for the URL or the origin. CrUX field data reflects eligible real visits; a URL may not have enough coverage to show URL-level data.
Record the failing metric and percentile. Use the 75th percentile, not only the average. Note the device segment and whether field data says the metric is good, needs improvement, or poor.
Run a repeatable lab diagnosis. Use Lighthouse or Chrome DevTools on the same page. Inspect the network waterfall and performance trace; repeat under comparable conditions before concluding that a change helped.
Change one cause, then remeasure. Keep the URL, device, test conditions, and measurement source consistent where possible. Check field data again after enough real visits have accumulated.

Field and lab results can differ because of connection latency, test location and device, cache state, redirects, personalized content, screen size, or user interactions. If they disagree, field data is usually a better representation of actual visitors; use the lab trace to investigate plausible causes. Lighthouse measures initial-load layout shifts and does not directly measure INP. It reports Total Blocking Time (TBT) as a lab clue for main-thread blocking, not as a replacement for field INP. Core Web Vitals and Google’s lab and field data guidance describe these limits.

2. Diagnose the failing metric

Slow main content: LCP

LCP records when the largest visible image or text block is rendered. If LCP is slow, identify the LCP element in DevTools or PageSpeed Insights and break its timing into four parts. The fix depends on which part consumes time; an oversized image is only one possible cause. See Google’s LCP optimization guide.

Timing part	What it means	What to inspect
Time to first byte (TTFB)	Wait from navigation until the first HTML response byte.	Redirect chains, origin response time, cache misses, network conditions, and distance between visitors and origin.
Resource-load delay	Time from the first response byte until the browser discovers and starts the LCP resource.	Whether JavaScript inserts the image, CSS hides its URL in a background, or lazy loading delays discovery.
Resource-load duration	Time spent transferring the LCP resource.	Its dimensions, format, byte size, and competing downloads using bandwidth.
Element-render delay	Time after the resource is ready until the element is painted.	Render-blocking CSS or scripts, long main-thread tasks, and code that hides or reveals content late.

Make the LCP resource discoverable early. When it is an image, include its URL in the initial HTML where practical and do not lazy-load it. You can selectively set fetchpriority="high" or preload the likely LCP image when diagnostics support it. Do not mark many images as high priority; they compete for bandwidth. If TTFB is the dominant part, investigate the server, redirects, caching, and whether a CDN addresses the measured origin-distance problem. Optimizing one part can expose another as the new bottleneck.

Slow interaction: INP

INP reflects responsiveness across a visitor’s interactions, not just the first load. If field INP is above 200 ms at the 75th percentile, inspect the work triggered by the slow interaction and look for JavaScript that blocks the main thread.

Remove unused JavaScript and split code that is not needed for the initial view.
Defer noncritical work so interaction and rendering work can run sooner.
Break up long tasks and yield between chunks. Google’s guidance treats tasks longer than 50 ms as long tasks.
Use field observations to identify the actual interaction. A low lab TBT does not prove that field INP is good.

See Google’s guidance on optimizing long tasks and the INP guide.

Unexpected movement: CLS

CLS captures layout instability during a visit. If field CLS is above 0.1 at the 75th percentile, inspect real page experiences and identify the elements that move. Images, embeds, ads, and dynamically inserted content can shift surrounding content.

Reserve space for images and embeds when their dimensions or aspect ratio are known.
Check whether late content insertion pushes visible content down.
Compare field observations with a lab run: a page-load-only lab pass may miss shifts that happen later in the visit.

Use the CLS guidance to interpret the metric and investigate shifts.

3. Prioritize changes by evidence

Use the failing metric and its size, field versus lab behavior, mobile versus desktop, the diagnosed timing or interaction cause, likely visitor impact, and implementation effort to choose what to fix first. Prefer a relevant fix the team can implement and verify. A CDN, cache plugin, image compression, or a new host is not a universal performance solution: use one when measurements point to the corresponding bottleneck.

Evidence	Possible action	How to verify
High TTFB is the largest LCP component.	Investigate origin response time, redirects, cache behavior, and geography; consider CDN delivery if distance is a cause.	Compare response timing and field LCP for the same page and segment.
LCP image starts late.	Expose its URL in initial HTML, remove lazy loading from that image, and consider selective preload or high fetch priority.	Check the waterfall for earlier discovery and compare LCP.
LCP image transfer dominates.	Review dimensions, format, file size, and competing requests.	Confirm the resource transfer shrank without changing the intended visible content.
Resource is ready but LCP paint is late.	Reduce render-blocking CSS and scripts, avoid unnecessary synchronous head scripts, and reduce main-thread work.	Inspect the trace for earlier paint and compare LCP.
Field INP is poor and an interaction has long tasks.	Reduce unused code, defer noncritical work, and break up long tasks.	Recheck field INP; use lab traces to confirm the relevant work changed.
Field CLS is poor and content shifts.	Reserve layout space and review dynamic insertions.	Inspect field shift diagnostics and recheck field CLS.

4. Keep measurements reliable

Separate field and lab conclusions. Field data describes actual eligible visits; lab runs help reproduce and diagnose. Do not treat a single Lighthouse score as a guarantee of user experience.
Control test conditions. Device, network, location, cache state, redirects, and page content can change timings. Compare like with like.
Measure the same page after each change. Keep a small record of the URL, device segment, metric, test source, and change so improvements and regressions are attributable.
Allow field data to catch up. A deployment will not instantly replace the rolling sample of real visits. Use lab checks for immediate regression detection and field data for visitor outcomes.
Check the full visit for stability and interaction. Initial-load checks alone may miss later layout shifts or interactions that drive INP.

5. Performance, reliability, and cost tradeoffs

Performance work has tradeoffs. Preloading or raising priority for too many resources can make them compete. Deferring JavaScript can affect code that a page expects to run immediately. Caching can serve stale content if its invalidation rules do not match the site’s update behavior. Reserve time to check functionality and content after a targeted change.

For reliability, keep changes narrow, use a repeatable lab check before release, and monitor the corresponding field metric afterward. For cost, compare the engineering and infrastructure expense with the diagnosed user-facing problem. A CDN or hosting change adds configuration and ongoing cost, so it is justified when origin response or geography is a demonstrated constraint. Do not assume a score improvement or business conversion gain without measuring it on the site.

6. Troubleshooting common performance investigations

Symptom	Likely cause or interpretation	Next step
PageSpeed Insights shows no URL-level field data.	The URL may not have sufficient CrUX coverage.	Check whether origin-level data is available, label it as origin data, and use a controlled lab run for the page.
Lighthouse is good but visitors report slowness.	Lab conditions may not represent their devices, networks, location, cache, content, or interactions.	Review field data by device and metric, then trace the affected page under realistic conditions.
Field and lab LCP disagree.	They measure different visits and conditions; redirects, cache, or test location may differ.	Use field data to establish the visitor problem and the lab waterfall to investigate possible causes.
Compressing the LCP image barely changes LCP.	Transfer duration may not be the dominant LCP component.	Inspect all four LCP timing parts; address late discovery, TTFB, or render delay if those dominate.
Preloading an image makes other resources slower.	Too many high-priority resources may compete for bandwidth.	Prioritize only the likely LCP resource and check the waterfall again.
TBT looks acceptable, but INP is poor.	TBT is a lab proxy and does not directly measure real interactions.	Use field interaction data and investigate the slow interaction’s main-thread work.
Lab CLS is low, but field CLS is poor.	Shifts may occur after initial load or under content and ad conditions absent from the lab pass.	Inspect field observations across the visit and reserve space for late content.
A CDN does not improve the score.	Origin distance may not be the dominant bottleneck, or another LCP component now dominates.	Compare TTFB and the other LCP timing parts before making further infrastructure changes.

7. Inspect a page with a screenshot

A screenshot can help compare what a page visibly renders across runs, but it does not replace field metrics, a network waterfall, or a performance trace. You can capture a page with a browser automation setup or send it to a screenshot API.

DIY browser capture with Playwright

Install Playwright and its Chromium browser, then save this as capture.mjs. Run it with node capture.mjs https://example.com. It saves a full-page PNG after the page reaches the load event. This is a visual inspection aid, not a Core Web Vitals measurement.

import { chromium } from 'playwright';

const url = process.argv[2];
if (!url) throw new Error('Usage: node capture.mjs https://example.com');

const browser = await chromium.launch({ headless: true });
try {
  const page = await browser.newPage({ viewport: { width: 1440, height: 900 } });
  await page.goto(url, { waitUntil: 'load', timeout: 60000 });
  await page.screenshot({ path: 'page.png', fullPage: true });
} finally {
  await browser.close();
}

Capture with cURL

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

Capture with Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Capture with Node.js

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Its one-call API can return PNG, JPEG, WebP, or PDF. Cookie banners are accepted and removed before the shot, along with known newsletter popups and chat widgets; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers say the page verdict and whether it was billed. An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 shots a month with no card; paid plans start at $5 for 3,000. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.

Frequently asked questions

How often should I check Core Web Vitals?

Check after meaningful page, code, or infrastructure changes, and monitor field data over time. Lab checks help catch immediate regressions; field data reflects eligible visits as they accumulate.

Does a perfect Lighthouse score guarantee a fast site?

No. Lighthouse is a controlled lab diagnostic. Real visitors use different devices, networks, locations, and interactions, so field data is needed to assess their experience.

Which metric should I fix first?

Start with the metric that fails for the page and visitor segment you care about, then fix the diagnosed cause. There is no universal order that fits every page.

Can a screenshot tell me why a page is slow?

A screenshot shows rendered appearance at a moment. Use field metrics, a network waterfall, and a performance trace to diagnose timing and interaction causes.