Slow Site: How to Read a PageSpeed Report

Slow Site: How to Read a PageSpeed Report

Google PageSpeed Insights gives your site a score from 0 to 100. A low score means your site is slow, which hurts user experience, conversion rates, and search rankings. This guide helps you understand the report and prioritize fixes.

Understanding the Score

• 90-100 (Green): Good. Your site is fast.
• 50-89 (Orange): Needs improvement. Users notice the slowness.
• 0-49 (Red): Poor. Users are leaving before the page loads.

Tip: The score is based on lab data (simulated conditions) and may differ from real-world performance. Focus on the Core Web Vitals section, which uses real user data when available.

PageSpeed tests on a simulated mid-tier phone with a slow 4G connection. If your site scores well under these conditions, it will feel fast for most visitors.

The 3 Core Web Vitals

Google uses three metrics to measure real user experience:

LCP — Largest Contentful Paint

What it measures: How long until the biggest visible element (hero image, headline) appears.

• Good: under 2.5 seconds
• Needs improvement: 2.5 - 4.0 seconds
• Poor: over 4.0 seconds

Common causes of bad LCP: - Unoptimized hero images - Slow server response time (TTFB) - Render-blocking CSS and JavaScript - Web fonts that delay text rendering

CLS — Cumulative Layout Shift

What it measures: How much the page layout shifts while loading. This is the annoying experience of clicking a button that moves at the last second.

• Good: under 0.1
• Needs improvement: 0.1 - 0.25
• Poor: over 0.25

Common causes of bad CLS: - Images without width/height attributes - Ads or embeds that load late and push content down - Web fonts that change text size when they load - Dynamic content inserted above existing content

INP — Interaction to Next Paint

What it measures: How quickly the page responds when a user clicks, taps, or types.

• Good: under 200 milliseconds
• Needs improvement: 200 - 500 milliseconds
• Poor: over 500 milliseconds

Common causes of bad INP: - Heavy JavaScript blocking the main thread - Too many event listeners - Large DOM size slowing down rendering

Top 5 Quick Wins

These fixes give you the biggest improvement for the least effort:

1. Compress and Resize Images

Images are the number one cause of slow pages. Most sites serve images that are 5-10x larger than needed.

# Convert to WebP (modern format, 30% smaller)
cwebp -q 80 photo.jpg -o photo.webp

# Resize to the actual display size (don't serve 4000px images for 800px containers)
convert photo.jpg -resize 800x -quality 85 photo-800.jpg

Use <picture> tags to serve WebP with a JPEG fallback:

<picture>
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="Description" width="800" height="600">
</picture>

Tip: Always include width and height attributes on images. This prevents layout shift (CLS) by reserving space before the image loads.

2. Enable Gzip/Brotli Compression

Text-based resources (HTML, CSS, JS) compress by 70-90%.

Nginx:

gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml text/javascript image/svg+xml;
gzip_min_length 1000;

Apache:

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json text/xml image/svg+xml
</IfModule>

3. Cache Static Assets

Tell browsers to cache CSS, JS, images, and fonts:

Nginx:

location ~* \.(css|js|jpg|jpeg|png|gif|webp|svg|woff2|woff)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

4. Defer Non-Critical JavaScript

JavaScript blocks rendering. Defer everything that isn't needed for the initial view:

<!-- Before: blocks rendering -->
<script src="analytics.js"></script>

<!-- After: loads without blocking -->
<script src="analytics.js" defer></script>

For third-party scripts you don't control, use async:

<script src="https://cdn.example.com/widget.js" async></script>

5. Use a CDN

A Content Delivery Network serves your static files from servers near your visitors. This dramatically reduces latency for geographically distributed audiences.

Popular CDN options: - Cloudflare (free tier available, easiest setup) - Bunny CDN (affordable, European-based) - AWS CloudFront (best for sites already on AWS)

How to Prioritize Fixes

The PageSpeed report lists "Opportunities" and "Diagnostics" sorted by estimated impact. Focus on:

1. Opportunities with the largest estimated savings (measured in seconds)
2. Core Web Vitals that are in the red — these directly affect SEO
3. Fixes that apply site-wide (like enabling compression) over page-specific fixes

Tip: Don't chase a perfect 100. Going from 30 to 70 is transformative for users. Going from 90 to 100 often requires disproportionate effort for marginal gain.

Tools Beyond PageSpeed

• GTmetrix (gtmetrix.com) — More detailed waterfall charts, test from multiple locations
• WebPageTest (webpagetest.org) — Advanced testing with filmstrip view, shows exactly what loads when
• Chrome DevTools Lighthouse — Same engine as PageSpeed, but run locally with no network variability

# Run Lighthouse from the command line
npx lighthouse https://example.com --output html --output-path report.html

How SiteWatch Helps

SiteWatch tracks PageSpeed scores over time for your entire client portfolio:

• Automated daily scans catch performance regressions before they affect users
• Score trending shows whether a site is getting faster or slower over time
• Portfolio overview lets you see which client sites need attention first
• Alerts on score drops notify you when a deploy or change hurts performance