Google PageSpeed Insights gives your page a score from 0 to 100. A score in the red (0-49) or amber (50-89) range isn't just a number - it means real visitors are waiting longer, leaving sooner, and converting less.
The score is a symptom. The causes are what you need to fix.
What Is Google PageSpeed Insights?
Google PageSpeed Insights (pagespeed.web.dev) is a free tool that analyses a single page and returns:
- A performance score (0-100) for both mobile and desktop
- Your Core Web Vitals results - the three speed and stability metrics Google uses as a ranking factor
- A list of opportunities (specific changes that would improve your score most)
- Diagnostics (additional issues worth addressing)
One important note: the score shown is a lab score - run in a controlled environment. The "field data" section above the score shows real-world data from actual Chrome users visiting your page. That field data is what Google actually uses for ranking decisions.
The Biggest Wins
These are the issues that appear most often and have the biggest impact.
1. Optimise Your Images
Images are the single most common PageSpeed problem. A single uncompressed hero image can add several seconds to your load time.
What to do:
- Compress images before uploading - tools like Squoosh (squoosh.app) or TinyPNG reduce file size without visible quality loss
- Convert to WebP format - typically 25-35% smaller than JPEG or PNG at the same visual quality
- Add explicit
widthandheightattributes to all images so the browser reserves the right space (this prevents layout shift while the page loads) - Use
loading="lazy"on images below the fold so they only download when the visitor scrolls to them
2. Eliminate Render-Blocking Resources
Render-blocking resources are JavaScript or CSS files that must fully download before the browser can display the page. Visitors stare at a blank or partially rendered screen until they finish.
What to do:
- Add
deferorasyncattributes to non-critical JavaScript so it loads in the background - Avoid loading large third-party scripts (chat widgets, analytics, ad tags) in the page
<head>where they block rendering - Identify critical CSS - the styles needed for the above-the-fold content - and inline it directly in the
<head>
3. Enable Text Compression
All text-based files - HTML, CSS, JavaScript - can be compressed during transfer so they download faster. A typical JavaScript file compresses to around 30% of its original size.
What to do: Enable Gzip or Brotli compression on your web server. This is usually a one-line configuration change in your hosting settings or .htaccess file. Many hosting providers enable it by default; if yours doesn't, it's worth switching or raising it with support.
4. Reduce Server Response Time (TTFB)
TTFB (Time to First Byte) is how long it takes for your server to start sending data after a visitor's browser makes a request. A slow server adds latency to every subsequent step.
What to do:
- Choose a fast hosting provider - shared hosting on a busy server is the most common cause of slow TTFB
- Enable server-side caching so repeated requests are served from memory rather than reprocessed each time
- Use a CDN (Content Delivery Network) to serve your files from servers physically closer to your visitors
5. Remove Unused JavaScript and CSS
Many websites load large JavaScript frameworks and CSS libraries but only use a fraction of them. All of that unused code still downloads and delays rendering.
What to do: This typically requires developer help, but the approach involves code splitting (loading only the JavaScript needed for the current page), auditing and removing unused third-party scripts, and checking plugins or theme code for unnecessary bloat.
6. Fix Cumulative Layout Shift (CLS)
CLS measures how much the page layout jumps around while loading - when images pop in and push text down, or a cookie banner loads and moves the button you were about to tap.
What to do:
- Add
widthandheightattributes to all images and video embeds so the browser reserves the correct space before they load - Avoid inserting content (banners, adverts, notifications) above existing page content after the page has appeared
- Use CSS
min-heighton containers that load dynamic content
For a full explanation of all three Core Web Vitals, see what are Core Web Vitals.
What Score Should You Aim For?
- 90-100 (green): Good. The focus now is keeping it here as you make other changes.
- 50-89 (amber): Needs improvement. Real users are noticing the delay.
- 0-49 (red): Poor. This is affecting your conversions and your rankings.
Mobile scores are almost always lower than desktop - that's normal and expected. A mobile score of 65-75 with green Core Web Vitals field data is a solid result for most small business sites.
Don't Chase the Score
The score is a useful indicator, not the end goal. A site with a 73 that loads fast on real devices beats a site that's been over-optimised to score 92 in a lab test but delivers a poor experience in the real world.
Focus on the field data and the specific items listed under "Opportunities" in your PageSpeed report. Fix the highest-impact items first, then run the test again. Small, consistent improvements compound over time - and that's what why website speed matters really means in practice.
How AuditCrow Helps
When you run an AuditCrow scan, we flag the most common PageSpeed issues in plain language: unoptimised images, render-blocking scripts, missing compression, layout shift problems, and more. Each issue comes with a difficulty rating so you know what to tackle first - without needing to interpret a Lighthouse report yourself.
Start with one fix. Run the scan again. See the difference.