Improving Your Core Web Vitals Score
How to read a PageSpeed report and fix the most common performance issues.
What SiteWatch checks
SiteWatch uses the Google PageSpeed Insights API to analyze your site's performance. It measures the Core Web Vitals — the metrics Google uses to evaluate user experience and influence search rankings.
| Metric | What it measures | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | How fast the main content loads | < 2.5s | 2.5-4s | > 4s |
| FID (First Input Delay) | How fast the page responds to interaction | < 100ms | 100-300ms | > 300ms |
| CLS (Cumulative Layout Shift) | How much the layout shifts while loading | < 0.1 | 0.1-0.25 | > 0.25 |
SiteWatch also reports the overall Performance score (0-100), which combines all metrics with Google's weighted formula.
How to read your results
- Score 90-100: Good. Your site is fast.
- Score 50-89: Needs improvement. Users may notice delays.
- Score 0-49: Poor. Your site is slow and losing visitors.
SiteWatch alerts when the score drops below a critical threshold or degrades significantly from the previous check.
Common performance issues and fixes
Large Contentful Paint (LCP) is slow
LCP measures how long it takes for the biggest visible element (usually a hero image or heading) to render. To improve it:
Optimize images:
- Use modern formats: WebP or AVIF instead of PNG/JPEG
- Serve responsive sizes with srcset
- Lazy-load images below the fold: <img loading="lazy">
- But do NOT lazy-load the hero image (it's above the fold)
Improve server response time: - Enable server-side caching (Redis, Varnish, or CDN) - Optimize slow database queries - Use a CDN to serve static assets closer to users
Remove render-blocking resources:
- Defer non-critical JavaScript: <script defer>
- Inline critical CSS and lazy-load the rest
- Remove unused CSS and JavaScript
Cumulative Layout Shift (CLS) is high
CLS measures unexpected layout movements — when elements jump around as the page loads. This is frustrating for users.
Common causes and fixes:
- Images without dimensions: Always set width and height on <img> tags
- Ads or embeds loading late: Reserve space with a fixed-size container
- Web fonts causing flash: Use font-display: swap and preload key fonts
- Dynamic content injected above existing content: Insert new elements below the fold or use CSS contain
Render-blocking resources
JavaScript and CSS files in the <head> block rendering until they're downloaded and parsed.
Fix:
<!-- Defer JavaScript -->
<script src="app.js" defer></script>
<!-- Preload critical fonts -->
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>
<!-- Async non-critical CSS -->
<link rel="preload" href="non-critical.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
Uncompressed resources
If your server doesn't compress responses, every page load transfers more data than necessary.
nginx gzip configuration:
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;
gzip_comp_level 6;
No caching headers
Without cache headers, browsers re-download every resource on every page load.
nginx caching for static assets:
location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff2)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
Quick wins checklist
- Enable gzip/brotli compression on your web server
- Set cache headers for static assets (1 year for hashed filenames)
- Use a CDN (Cloudflare free tier is excellent)
- Optimize and properly size images
- Defer non-critical JavaScript
- Set explicit dimensions on images and embeds
- Preload your primary web font