Performance Score

How SitePulse measures page performance using Lighthouse and Core Web Vitals.

The Performance score is a direct pass-through of the Lighthouse Performance score (0–100). By default this runs via a local headless Chrome instance — no setup required. If you add your own free PageSpeed Insights API key from your project's Settings page, SitePulse switches to Google's servers instead, which is faster and more reliable and adds real-user Core Web Vitals (CrUX field data) on top of the same lab score.

What it measures

Lighthouse Performance weights six lab metrics:

MetricWeightGoodNeeds improvementPoor
First Contentful Paint (FCP)10%≤ 1.8s1.8–3.0s> 3.0s
Largest Contentful Paint (LCP)25%≤ 2.5s2.5–4.0s> 4.0s
Total Blocking Time (TBT)30%≤ 200ms200–600ms> 600ms
Cumulative Layout Shift (CLS)15%≤ 0.10.1–0.25> 0.25
Speed Index (SI)10%≤ 3.4s3.4–5.8s> 5.8s
Interaction to Next Paint (INP)10%≤ 200ms200–500ms> 500ms

SitePulse also records page weight (total transfer size) and request count as informational metrics — they do not directly feed into the score but help diagnose the underlying cause of poor FCP/LCP.

In plain terms: FCP/LCP measure how quickly something (and then the main thing) appears on screen, TBT/INP measure how quickly the page responds when a visitor tries to interact, and CLS measures how much the layout jumps around while loading. Full definitions live in the glossary.

Why it matters

Performance directly affects user experience and SEO. Google uses Core Web Vitals — its measurements of loading speed, responsiveness, and visual stability — as ranking signals. A page that loads in 4+ seconds loses roughly 80% of mobile visitors before they even see the content.

How to interpret your score

A Performance score of 90+ means your page loads quickly across connection types and devices. Anything below 50 indicates one or more metrics are in the Poor band.

The most impactful metric to fix first is almost always LCP — it carries the highest weight and is most directly affected by image optimization, server response time, and render-blocking resources.

Common causes of low scores

MetricCommon causes
FCPRender-blocking CSS/JS, slow server TTFB, no CDN
LCPUnoptimized hero images, lazy-loaded above-fold images, slow server
TBTLarge JavaScript bundles, long tasks on the main thread
CLSImages without width/height, ads injecting above content, web font FOUT
SICSS animations during page load, unoptimized critical path

How to improve

Performance improvements are infrastructure and code changes — they are not surfaced as Rewrite suggestions. Instead, the Performance tab of your audit shows the underlying evidence directly:

  • Opportunities — the specific savings Lighthouse identified (e.g. "Eliminate render-blocking resources", "Serve images in next-gen formats"), each with an estimated time or byte savings so you can prioritize the ones worth the most.
  • Diagnostics — page-level bottleneck detail: main-thread work breakdown, third-party script impact, DOM size, and render-blocking resources.
  • LCP breakdown — your Largest Contentful Paint time split into TTFB, load delay, load time, and render delay, so you know exactly which phase is slow instead of just that LCP is slow.
  • Image SEO — which images are flagged for modern formats, compression, missing dimensions, or lazy-loading, with sample URLs.

Desktop vs. mobile

Every URL audit now captures both a mobile and a desktop Lighthouse pass. Use the Desktop / Mobile toggle above the evidence tables to switch views. Mobile remains the pass your score is based on — desktop is shown for comparison only, since simulated mobile throttling is the stricter, more representative bar for most real-world traffic.

Desktop is informational

The desktop pass doesn't have its own score or count toward your overall Performance number — it exists purely to help you see whether a slowdown is mobile-specific (often throttling and image weight) or shows up on desktop too (often a genuine code or server issue).

Last updated: 2026-08-20