How to Improve Website Performance and Page Speed

Improve page speed by measuring real user experience first, identifying the specific bottleneck, and fixing the metric that is failing. A fast page is not just one that displays something quickly: it should load its main content promptly, respond to input, and avoid unexpected layout shifts.

Google’s Core Web Vitals measure those three parts of experience: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). The recommended “good” targets are LCP at or below 2.5 seconds, INP below 200 milliseconds, and CLS below 0.1. Treat these as experience targets, not a promise of a search ranking increase. Google says Core Web Vitals align with what its core ranking systems seek to reward, alongside other aspects of page experience. See Google’s Core Web Vitals guidance.

1. Measure before changing the page

Start with representative pages and devices. Use both field data, which reflects visits from real users, and lab diagnostics, which help reproduce and investigate a problem. A single performance score cannot tell you which user experience is failing.

Run PageSpeed Insights on important URLs. Review the reported user-centric metrics and diagnostics. Start with a page that represents a template or user journey, then check other materially different pages. PageSpeed Insights accepts a URL for analysis.
Check Search Console’s Core Web Vitals report. It groups pages using real-world user data. Use it to see whether a problem affects a set of URLs, not just one test run. Some pages or groups may not appear when there is not enough data; a missing group does not prove the pages are fast. Details are in Google’s reporting guidance.
Reproduce the issue in Chrome DevTools. In Network, inspect which resources load and their timing. In Performance, record a page load or interaction to inspect network and main-thread activity. Use Memory when there is evidence of excessive JavaScript memory use. See the web.dev performance overview and its links to metric-specific guidance.
Record a baseline. Note the URL, test conditions, LCP, INP, CLS, and the suspected cause. For field data, note the page group and date range. Repeat the same measurements after a change.

Compare like with like: the same page or template, similar device conditions, and the same metrics. Separate a repeatable lab finding from a field-data trend. A lab result helps diagnose; field data tells you how visitors are experiencing the site.

2. Identify which part of the experience is slow

Metric	What it describes	What to investigate
LCP	How soon the largest visible content element is rendered.	Find the LCP element and inspect what delays it: its resource, when that resource is discovered, and the work required to render it.
INP	How responsive the page is to user interactions.	Reproduce the slow interaction and inspect main-thread work and JavaScript activity around it.
CLS	How much visible content shifts unexpectedly.	Identify which elements move and what enters, loads, or changes size immediately before the shift.

Use the metric that is actually failing to choose the investigation. A large image may be relevant to LCP, but it will not explain every slow interaction. Deferring scripts may help some pages and hurt others if it delays important content. Verify the cause before choosing a remedy. Google’s LCP, INP, and CLS guides cover their respective optimization paths.

3. Improve LCP when the main content appears late

First identify the element reported as the LCP element. It may be an image, a block of text, or another large visible element. Then trace its path: when the browser can discover it, when its required resource finishes loading, and when the browser can render it.

Inspect the Network panel for slow or delayed resources needed by the LCP element.
If the element depends on an image, check the image’s size and delivery, and whether the browser can discover it early enough.
Check whether server response time or render-blocking work delays the page before the element can appear.
Make changes only when the trace or report points to that cause. Recheck the same URL and compare the LCP result.

Do not optimize an unrelated asset just because it is large. The useful question is whether it delays the largest visible content on the affected page.

4. Improve INP when interactions feel delayed

INP concerns responsiveness after a visitor interacts with the page. Identify a slow interaction, then inspect what the browser is doing at that moment. Long or heavy main-thread work can prevent the page from responding promptly.

Use a Performance recording around the interaction that feels slow.
Look for substantial JavaScript or other main-thread work that overlaps the delay.
Check whether the interaction triggers more work than the page needs, or waits on work that could happen later.
Reproduce the same interaction after changing code and review both the trace and the metric.

A faster initial render does not by itself establish that interactions are responsive. Assess loading and interaction separately.

5. Improve CLS when content jumps

Unexpected movement makes a page difficult to use, especially when a visitor is reading or about to select something. Use a recording or a reproducible visit to find the elements that move, then check what changed just before the shift.

Reproduce the affected page and note which content moves.
Inspect what loads or changes size around that moment.
Check whether the shifting element or the content around it changes its layout after the initial render.
Repeat the visit after the change and verify that the movement and CLS have improved.

Do not assume that a page with a good loading metric has stable layout. CLS measures a separate part of the experience.

6. Use browser tools to investigate, not just score

Chrome DevTools provides different views for different questions:

Network: Which resources are requested, when they start, and how long they take.
Performance: What the browser and main thread are doing during a load or interaction, along with network activity.
Memory: JavaScript memory use when memory behavior is part of the observed problem.

Start from a specific field or lab finding, record a relevant page action, and inspect the time window where the issue occurs. The web.dev performance guide links to diagnostic and optimization guidance for each Core Web Vital. As web.dev puts it, “You can’t improve your website’s performance without first measuring it.”

7. A repeatable optimization workflow

Choose representative URLs. Include pages with different templates or important user tasks.
Collect field and lab evidence. Review Search Console where data is available and run PageSpeed Insights for page-level diagnostics.
Pick one failing metric and page group. LCP, INP, and CLS represent different problems.
Reproduce and locate the cause. Use DevTools to inspect the relevant resource, interaction, or layout change.
Make a focused change. Keep track of which change is intended to address which finding.
Measure again. Compare the same pages, metrics, and conditions, then review field data over time as it becomes available.

When comparing two proposed fixes, consider loading, responsiveness, and stability separately. Check whether the affected pages and devices improved, and do not treat one Lighthouse or PageSpeed score as a substitute for real-user evidence.

8. Troubleshooting common measurement problems

Symptom	Likely explanation	What to do
A URL or page group is missing from Search Console’s Core Web Vitals report.	There may not be enough real-user data for that URL group.	Do not interpret absence as proof of good performance. Use PageSpeed Insights and reproduce the page in DevTools while gathering field data.
PageSpeed Insights looks different from a visitor’s experience.	A page analysis and field data answer different questions; conditions and page state can also differ.	Compare the report with Search Console and reproduce the behavior on the affected page and device.
A score improved, but users still report a slow page.	The score may not reflect the affected interaction, page group, device, or real-user behavior.	Check LCP, INP, and CLS individually, then use field reporting and a targeted DevTools recording.
Several URLs show the same issue.	The pages may share a template or common loading behavior.	Use the report’s page grouping to identify the shared pattern, then inspect representative URLs before changing the template.
A change improves one metric but worsens another.	The change may affect a different part of the loading or interaction path.	Review all three metrics and the affected user task. Keep or revise the change based on measured page experience.
The problem cannot be reproduced in one lab run.	The cause may depend on the page state, device, network, or interaction being tested.	Use real-user reporting when available, repeat the relevant user journey, and inspect the same action in DevTools.

9. Screenshot visual changes during performance work

Screenshots can help compare what a page looks like before and after a change, or document a layout shift that is visible at a particular point in a workflow. They do not measure LCP, INP, CLS, network timing, or real-user performance; use PageSpeed Insights, Search Console, and browser diagnostics for those questions.

ScreenshotNeo is a website screenshot API and MCP server for developers. Its API can capture a page as an image or PDF, which can be useful for visual review alongside performance measurements. See the ScreenshotNeo documentation for its API options.

Or skip the browser setup

For a visual capture, make one request to ScreenshotNeo’s API. This captures a page for comparison; it does not replace performance measurement. The request options include image format, viewport, full-page capture, and waiting behavior. See the API documentation for available parameters.

cURL

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

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)

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 (await import('node:fs/promises')).writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

ScreenshotNeo accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and responses identify the page verdict and billing status in headers. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for AI agents. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month, with no card required.

10. Performance, reliability, and cost considerations

Performance: Diagnose the actual bottleneck before spending time on a change. Check whether it affects the reported metric and the pages visitors use.
Reliability: Use more than one observation. A lab diagnostic helps reproduce a cause; field reporting helps show whether visitors experience it. Missing field data is inconclusive.
Cost: Prioritize work by affected pages and user impact. The sources here do not establish a universal return on investment for any specific optimization, so measure the result on your own site rather than assuming a score increase produces a business outcome.
Search: Good Core Web Vitals are aligned with what Google’s core ranking systems seek to reward, but Google considers other page-experience aspects too. Meeting the thresholds does not guarantee a ranking change.

FAQ

Do Core Web Vitals cover every part of website performance?

No. They cover loading performance, responsiveness, and visual stability as experienced by users. Use the browser’s network, performance, and memory diagnostics to investigate the causes behind a result.

Should I optimize every URL separately?

Start with representative pages and page groups. When multiple URLs share a pattern, investigate the common template, then verify the change on affected pages.

Does a good PageSpeed score guarantee better rankings?

No. Google says Core Web Vitals align with what its core ranking systems seek to reward, but they are part of a broader page-experience picture and do not guarantee a ranking increase.

Can a screenshot tell me whether a site is fast?

No. A screenshot records appearance. Use performance reports and browser diagnostics to assess loading, interaction responsiveness, and layout stability.