PageSpeed Analyzer

PageSpeed Analyzer: Measure and Fix Your Google Lighthouse Score

Every second of load time costs conversions. Google''s own research shows that as page load time increases from one to five seconds, the probability of a mobile visitor bouncing increases by 90%. Yet most teams only discover their PageSpeed score the day a stakeholder runs a Lighthouse audit and shares a screenshot of a red "32". This tool puts a continuous, zero-setup Lighthouse runner in your browser so you can check any URL in seconds and understand exactly what the score means.

What Is Google Lighthouse and Why Does It Matter?

Google Lighthouse is an open-source automated auditing tool built into Chrome DevTools and powering the PageSpeed Insights API. It simulates a mid-tier Android device on a throttled 4G connection, loads your page, and measures six performance metrics. From those metrics, it calculates a single weighted Performance Score from 0 to 100.

Since June 2021, Core Web Vitals — a subset of Lighthouse metrics — are an official Google ranking factor. A poor mobile Lighthouse score is therefore not just a UX problem; it is a direct SEO liability.

The Six Lighthouse Metrics and Their Weights

TBT has the highest weight at 30%. This surprises teams that focus exclusively on network metrics. TBT is dominated by JavaScript execution — long tasks that block the main thread and make the page feel frozen even after it visually loads. Every JavaScript bundle you ship contributes to TBT.

This tool surfaces FCP, LCP, and Speed Index — the three metrics with the strongest correlation to perceived load speed and the easiest to understand without deep Lighthouse expertise.

Google''s Threshold System: Good, Needs Improvement, Poor

Each Core Web Vital has three performance ranges:

First Contentful Paint

• Good: ≤ 1.8 s
• Needs improvement: 1.8–3.0 s
• Poor: > 3.0 s

Largest Contentful Paint

• Good: ≤ 2.5 s
• Needs improvement: 2.5–4.0 s
• Poor: > 4.0 s

Speed Index

• Good: ≤ 3.4 s
• Needs improvement: 3.4–5.8 s
• Poor: > 5.8 s

A page with all three metrics in the "Good" range will almost always score 90+. Conversely, a single metric deep in the "Poor" range can collapse an otherwise acceptable score because the weighted formula is unforgiving at the extremes.

The Lighthouse Scoring Algorithm in Detail

The score is not a simple average. Each metric is converted to a 0–1 value using a log-normal distribution calibrated against real-world performance data from the HTTP Archive. The resulting metric scores are then multiplied by their weights and summed.

What this means in practice:

• Improving a metric from "Poor" to "Needs improvement" yields a much larger score jump than improving from "Good" to "Perfect". The curve is steepest in the middle ranges.
• A score of 90 does not mean you are 10% below perfect. It means you are faster than approximately 90% of pages in the HTTP Archive reference dataset for that metric.
• Because TBT has the highest weight, JavaScript-heavy pages (SPAs, heavy third-party scripts) are systematically penalised even when their network metrics look acceptable.

Why Mobile Performance Is the Primary Target

Google uses mobile-first indexing for all websites. The Googlebot crawls the mobile version of your page to determine rankings. Desktop performance is irrelevant to Core Web Vitals ranking signals.

The simulation parameters that Lighthouse uses for mobile:

• Device: Motorola Moto G4 (mid-2016, ~1.6× CPU slowdown versus a 2023 flagship)
• Network: Slow 4G (10 Mbps download, 40 ms RTT, 0.15 Mbps upload)
• Viewport: 412×823 at 1.75× device pixel ratio

These parameters are intentionally conservative. If your score is 90+ under this simulation, your real-world mobile users — who often have newer devices and better connections — will have an even better experience.

The Eight Most Common Causes of Low Lighthouse Scores

1. Unoptimised hero images A full-resolution JPEG hero image that is not resized, compressed, or converted to WebP is the single most common cause of a high LCP. A 2 MB JPEG loaded before the LCP element can push LCP past 6 seconds on a throttled connection. Solution: next/image, responsive srcset, WebP/AVIF encoding, and explicit width/height attributes to prevent layout shift.

2. Render-blocking scripts Synchronous <script src="..."> tags in <head> halt HTML parsing until the script is downloaded, parsed, and executed. Lighthouse penalises this directly in TBT. Solution: add defer or async to non-critical scripts, or move them before </body>.

3. Excessive JavaScript bundle size Every kilobyte of JavaScript that ships to the browser must be parsed and compiled before it can run. A 1 MB (compressed) JavaScript bundle adds approximately 1.5–2 s of TBT on a mid-tier mobile CPU. Solution: code-splitting with dynamic imports, tree-shaking unused code, and auditing third-party script payloads.

4. No CDN or server too far from the user A 150 ms round-trip time to origin adds 150 ms to every uncached resource request. For a page with 20 requests, that is 3 seconds of pure latency overhead. Solution: Vercel, Cloudflare, or any global CDN that serves assets from the nearest edge node.

5. Missing Cache-Control headers Without proper caching, every navigation forces a full re-download of unchanged assets. This penalises return visitors who have the worst connection speeds. Solution: Cache-Control: public, max-age=31536000, immutable for hashed static assets; stale-while-revalidate for HTML documents.

6. Web font loading Loading a web font without font-display: swap blocks text rendering until the font is available. On a slow connection, this can push FCP past 3 seconds. Additionally, loading a 200 KB font file for 12 characters of heading text wastes bandwidth. Solution: font-display: swap, <link rel="preload"> for critical fonts, subsetting, and self-hosting rather than Google Fonts CDN.

7. Third-party scripts Analytics, chat widgets, A/B testing tools, and social media embeds are among the leading contributors to TBT. A single GTM container loading 10 marketing tags can add 400–800 ms of TBT alone. Solution: audit and remove unused scripts, load non-critical tags after the page is interactive using requestIdleCallback.

8. No server-side rendering or static generation Client-rendered SPAs (React, Vue, Angular without SSR) ship a mostly empty HTML document and then use JavaScript to build the DOM. FCP does not fire until that JavaScript has run. Solution: server-side rendering (Next.js, Nuxt) or static generation pre-renders HTML so FCP fires as soon as the first bytes arrive.

How Vector Input Achieves 100/100 on Every Project

Every site we build ships with performance treated as a non-negotiable requirement, not an afterthought:

• Next.js App Router with React Server Components — components that have no client-side interactivity are never shipped as JavaScript. The browser downloads zero-JS for static content sections.
• Automatic image optimisation via next/image — WebP/AVIF conversion, responsive srcset, lazy loading, and explicit dimensions are enforced at the framework level.
• Vercel Edge Network — assets are served from the nearest of 100+ global CDN nodes. Average TTFB for UAE users is under 30 ms.
• Font preloading and subsetting — only the Unicode ranges used on each page are downloaded, reducing font payload by up to 80%.
• Bundle analysis on every deploy — a size-limit budget gate fails the CI build if any JavaScript chunk exceeds its budget, catching regressions before they reach production.
• Third-party script isolation — analytics and tracking scripts are loaded via a custom Partytown worker that moves them off the main thread, eliminating their contribution to TBT.

If your site scored below 90, request a free technical audit. We will run a full Lighthouse trace, identify every metric contributing to your score deficit, and deliver a prioritised remediation plan.

Interpreting Your Results

Score 90–100 (Green) — Your site is performing well. Focus on maintaining this score as features are added. Monitor Core Web Vitals in Google Search Console to detect field data regressions.

Score 50–89 (Orange) — Meaningful performance issues exist. Users on slow connections will notice delays. The most impactful fixes are likely in image optimisation and JavaScript bundle size.

Score 0–49 (Red) — Significant performance problems that will affect rankings and conversions. Immediate action is recommended. Common causes: large unoptimised images, heavy JavaScript, no CDN, render-blocking resources.