AI Website Speed Diagnosis & Audit
Scan your website to receive an executive plain-English diagnostic report, root-cause bottleneck breakdown, and conversion impact analysis.
Understanding This Diagnosis and When to Use It
📌 On this page
1. What actually happens when you run a scan
The server performs one real, timed HTTP fetch of your URL and measures how long the first byte took to arrive (TTFB) — this is a genuine, live measurement of your server's response latency. That single number is then used to derive estimated LCP, INP, and CLS values via fixed multipliers, and if a Gemini AI model is available, all of this is passed to it to generate a plain-English narrative explaining what the numbers mean and what to do about them. If the AI model is unavailable, a rule-based heuristic engine produces a comparable narrative from the same TTFB data.
2. Why TTFB alone is still a useful signal
Time to First Byte is a genuinely meaningful metric on its own — it reflects how quickly your server (or edge cache) can begin responding to a request, which is foundational to every other loading metric that follows. A slow TTFB (over 600ms) reliably indicates real server-side or database-query bottlenecks worth investigating, even without a full Core Web Vitals suite. That said, TTFB alone cannot tell you about client-side rendering issues, image optimization, or JavaScript execution problems, which is exactly why the estimated LCP/INP/CLS figures should be treated as illustrative rather than authoritative.
3. Translating metrics for non-technical stakeholders
Raw Core Web Vitals numbers ("LCP: 2.4s, CLS: 0.08") mean very little to a business owner or marketing stakeholder without context. This tool's plain-English executive summary and business impact framing exist specifically to bridge that gap — translating "your TTFB is high" into "your server takes too long to start responding, which research links to higher bounce rates and lost conversions." Use this narrative framing when communicating with non-technical colleagues, and pair it with real PageSpeed Insights data when the audience needs to trust exact numbers.
4. When this tool is the right choice vs. PageSpeed Insights
Use this tool for a fast first pass, a plain-English summary to share with stakeholders, or a quick TTFB sanity check across several URLs. Use Google PageSpeed Insights when you need authoritative, field-verified Core Web Vitals numbers — for reporting to leadership with hard figures, for tracking real user experience over time via the Chrome UX Report, or for verifying whether a page actually passes Google's Page Experience thresholds. The two tools serve different jobs; neither replaces the other.
5. What to do after getting your diagnosis
If the diagnosis flags TTFB as the primary bottleneck (a common outcome for unoptimized WordPress installs), investigate server-side causes: unoptimized database queries, missing page caching, an underpowered hosting plan, or excessive plugin overhead on every request. Once you've addressed the server-side issue, run a real PageSpeed Insights test to confirm the improvement and check the client-side metrics (image sizes, render-blocking resources, JavaScript execution) this tool doesn't independently measure.
Frequently Asked Questions
How does the AI Website Speed Diagnosis work?
The tool performs a live HTTP diagnostic fetch to measure origin TTFB, then analyzes Core Web Vitals telemetry through an LLM synthesis model to generate plain-English explanations and business impact metrics.
What is the difference between this AI diagnosis and standard Lighthouse?
Standard Lighthouse outputs technical raw metric numbers that non-technical stakeholders struggle to interpret. This tool translates metrics into business impact, conversion risk, and plain-English action items.
Is my scanned URL data stored on your servers?
No. All scans are executed ephemerally in-memory and results are returned directly to your browser session.
Are the LCP, INP, and CLS figures shown here real Core Web Vitals?
No — only TTFB is a genuine live-measured value, taken from a real timed fetch of your URL. LCP, INP, and CLS shown here are estimated using fixed mathematical multipliers applied to that single TTFB reading (for example, LCP is modeled as roughly 3.5× TTFB), not independently measured. They are directional signals meant to support the plain-English narrative, not a substitute for genuine PageSpeed Insights or Chrome UX Report data. Use the "(est.)" labels in the results as your guide to which numbers are estimated versus live.
What happens if the AI model is unavailable when I run a diagnosis?
The tool falls back to a rule-based heuristic engine that still produces a genuinely useful, plain-English report using the same live TTFB measurement — the badge changes from "AI Model: Gemini 2.0 Flash" to "Heuristic Engine (AI unavailable)" so you always know which path generated your report. Both paths give directionally similar guidance since they are both interpreting the same TTFB-driven signal, but the AI path can tailor its language more specifically to your situation.
Where should I go for a fully accurate Core Web Vitals audit?
Google's own PageSpeed Insights tool (or the Chrome UX Report / CrUX data it surfaces) is the authoritative source for real, field-measured Core Web Vitals — it's the same data Google uses for the Page Experience ranking signal. This diagnosis tool is designed for a fast, plain-English first pass and business-impact framing, not as a replacement for that authoritative measurement.