Running a site through Google PageSpeed Insights and seeing a low score is discouraging, especially when the report is full of terms that are not immediately meaningful. LCP, CLS, INP, TTFB, unused JavaScript — none of it is intuitive on first encounter.
The good news is that the report is structured and the fixes it recommends are mostly well-defined. Most of the meaningful improvements do not require writing code. They require understanding what is being measured, identifying which issues are causing the largest drops, and applying a short list of well-established fixes.
This guide explains what each core metric means, how to read the report, and how to act on it — with specific steps that work whether the site is on WordPress, Webflow, Wix, Netlify, or a custom setup.
What this covers:
The Core Web Vitals and what they measure
How to read the PageSpeed Insights report
Practical fixes: image optimization, caching, CDNs, minification, and layout stability
Monitoring progress over time
Step 1: Understand the Core Metrics
PageSpeed Insights scores a site from 0 to 100 and breaks performance down into Core Web Vitals plus additional diagnostics. The three Core Web Vitals are the metrics that carry the most weight for both user experience and Google search rankings.
LCP (Largest Contentful Paint)
LCP measures how long it takes for the largest visible element on the page to finish loading. This is usually a hero image, a large heading, or a video thumbnail. It represents perceived load speed from the user's perspective.
Target: under 2.5 seconds. Above 4 seconds is considered poor.
CLS (Cumulative Layout Shift)
CLS measures visual stability. It captures how much the page layout shifts while loading — elements jumping around as images, fonts, or ads load in. A high CLS score is the experience of clicking a button and having the page move just before the click registers.
Target: under 0.1. Above 0.25 is considered poor.
INP (Interaction to Next Paint)
INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. Where FID only measured the delay before the browser began processing the first interaction, INP measures the full duration of every interaction throughout the page session. It is a more comprehensive measure of how responsive the page feels during use.
Target: under 200 milliseconds. Above 500 milliseconds is considered poor.
Performance Score
The overall score is calculated from a weighted combination of these and additional metrics. A score of 90 or above is considered good. Scores below 50 indicate significant performance problems worth addressing.
The report also distinguishes between lab data (simulated, run in a controlled environment) and field data (aggregated from real Chrome users visiting the site). Field data is what Google uses for search ranking signals. Lab data is useful for diagnosing and testing fixes because it is reproducible.
Step 2: Read the Report
Run the site URL through pagespeed.web.dev. The report is divided into several sections worth understanding.
Performance summary: The top of the report shows the overall score and the individual Core Web Vital values, each color-coded green (good), amber (needs improvement), or red (poor). Check both the mobile and desktop tabs — mobile scores are almost always lower and are the priority for search ranking purposes.
Opportunities: This section lists specific changes the report believes would have the highest impact on the score. Each opportunity includes an estimated time saving. Start with the opportunities offering the largest savings.
Diagnostics: This section lists issues that do not directly affect the score but indicate underlying problems worth addressing: oversized images, unused JavaScript, unused CSS, inefficient cache policies, and similar. These often contribute indirectly to poor Core Web Vital scores.
Passed audits: Issues the report checked for and found no problem with. These can be ignored unless the score improves elsewhere and a further pass is needed.
The most productive approach is to work through Opportunities in order of estimated savings, then review Diagnostics for related issues.
Step 3: Apply the Most Impactful Fixes
Optimize Images
Uncompressed or oversized images are the most common cause of poor LCP scores and slow overall load times. The fix is straightforward but frequently overlooked.
Before uploading images, compress them using a tool such as Squoosh, TinyPNG, or any image editor with export quality settings. Aim for the smallest file size that preserves acceptable visual quality.
Use WebP format rather than JPEG or PNG where the site and its visitors' browsers support it. WebP produces significantly smaller files at comparable quality. Most modern hosting platforms and CDNs handle WebP conversion automatically.
Always define explicit width and height attributes on image elements in HTML:
<img src="hero.webp" width="1200" height="600" alt="Hero image">
Without explicit dimensions, the browser does not know how much space to reserve for an image while it loads, which causes layout shifts and contributes to a poor CLS score.
Enable a Content Delivery Network (CDN)
A CDN serves site assets from servers geographically closer to each visitor, reducing the time it takes for files to travel across the network. For sites with any international audience, a CDN is one of the higher-impact changes available.
Cloudflare offers a free plan that works with any site by proxying traffic through its network after a DNS change. Netlify and Vercel include CDN delivery by default for sites hosted on their platforms. WordPress.com handles CDN automatically on paid plans.
Enable Browser Caching
Browser caching instructs visitors' browsers to store assets locally after the first visit, so returning visitors load the site significantly faster without re-downloading unchanged files.
On Netlify or GitHub Pages, add a _headers file to the project root:
/*
Cache-Control: max-age=31536000, immutable
On WordPress, plugins such as WP Rocket, W3 Total Cache, or LiteSpeed Cache configure caching through the admin interface without any code changes. On Wix, Webflow, and Squarespace, caching is managed automatically by the platform.
Minify CSS, JavaScript, and HTML
Minification removes whitespace, comments, and formatting from code files without changing how they work, reducing file sizes and therefore load times.
Most modern hosting platforms minify assets automatically as part of the build process. Netlify and Vercel both do this by default. For WordPress, caching plugins such as WP Rocket and Autoptimize include minification as a feature. For manual projects, tools such as HTMLMinifier, CSS Minifier, and JS Minifier process files individually.
Fix Layout Shifts (CLS)
High CLS scores are usually caused by a small number of identifiable issues.
Images without defined dimensions shift the layout as they load, because the browser cannot reserve the correct amount of space in advance. Adding explicit width and height attributes, as described in the images section, addresses this.
Web fonts cause layout shifts when the fallback system font is replaced by the downloaded font mid-render. Using font-display: swap in the font CSS allows text to display immediately in the fallback font and transitions to the web font once it has loaded, rather than hiding text entirely or shifting layout.
Embedded content — ads, iframes, social media widgets — causes shifts when the container has no defined height before the content loads. Setting explicit minimum heights on containers that hold embedded content prevents the shift.
Step 4: Monitor and Maintain
Performance improvements made once will degrade over time as new content, plugins, and scripts are added. Establishing a routine review process prevents the score from drifting back down.
A practical maintenance approach:
Re-run PageSpeed Insights after each significant change to confirm the improvement and check whether it introduced new issues
Run a full audit every three months covering images, scripts, and caching configuration
Use the Lighthouse panel in Chrome DevTools for local testing without waiting for the PageSpeed Insights web interface
Check both mobile and desktop scores, since the two can diverge significantly as content changes
Small improvements compound. A site that consistently addresses new issues as they arize tends to maintain a strong score more easily than one that lets issues accumulate and requires a large corrective effort.
Key Takeaways
Core Web Vitals (LCP, CLS, INP) directly affect both user experience and Google search rankings. INP replaced FID as a Core Web Vital in 2024.
The Opportunities section of the report is the most useful starting point: it prioritizes changes by estimated time saving.
Image optimization addresses the most common cause of poor LCP scores. Compress images before uploading and define explicit dimensions in HTML to prevent CLS.
Browser caching and a CDN require minimal setup and produce meaningful improvements in load time for returning visitors and international audiences.
Minification is handled automatically by most modern hosting platforms. Manual tools are available for custom setups.
Schedule a performance review every three months to prevent scores from degrading as content and plugins accumulate.
Conclusion
A low PageSpeed score is almost always fixable without a developer and without rewriting the site. The report is specific about what is causing the problem and reasonably clear about what to do about it. Working through the Opportunities section in order of estimated savings addresses the largest issues first, and most of the individual fixes have straightforward implementations available for every common hosting platform.
Performance is not a one-time task. Sites that stay fast do so because their owners revisit the basics periodically and address new issues before they accumulate. The time investment is modest compared to the compounding return in user experience and search visibility.
Run your site through PageSpeed Insights and find something in the report confusing or unexpectedly high? Share it in the comments.
