SEO audit, prioritized by payoff

How the fetch works

Three routes race at once: a first-party proxy on this domain that resolves the target's DNS and validates it is a public address before fetching (so it cannot be pointed at internal infrastructure), a direct request from your browser, and one public relay (allorigins.win) as a backup. Whichever answers first with usable HTML wins; the others are cancelled. If all three fail within 10 seconds, the tool shows a curl command and a paste-HTML box instead of stopping dead. The log above the results shows exactly which route won, or why each one failed.

The proxy caches a successful fetch for 60 seconds (by URL, so re-running the same audit twice in a row does not hit the target site twice) and rate-limits requests per visitor. Nothing is retained past that window.

Core Web Vitals proxies, not field data

Real LCP, CLS, and INP need a rendering browser and real users. A static HTML fetch cannot produce them, so this tool measures structural proxies that correlate with them:

• HTML document weight (correlates with time to first render)
• Render-blocking stylesheets and synchronous head scripts (delay first paint and LCP)
• Images without width and height attributes (the most common layout-shift source)
• Total DOM element count (large trees slow style, layout, and interaction)
• Native lazy-loading adoption on images

Deep audit: real Lighthouse data, still lab data

The optional deep audit calls Google PageSpeed Insights, which runs a real Lighthouse pass and returns real measured LCP, CLS, and TBT (Total Blocking Time). That replaces the structural proxies above for the categories it covers; they are removed from the findings list rather than shown twice.

"Real" does not mean "your visitors." Lighthouse lab data is a single run against a simulated device profile with simulated network and CPU throttling, executed on Google's own test hardware, not a real phone or a real network, and not your actual traffic. A single run also carries normal run-to-run variance; treat one result as a snapshot, not a certified average. INP has no lab equivalent at all — it can only be measured from real user interactions, so it is never shown here regardless of device or run count; TBT is Lighthouse's own lab proxy for responsiveness, not INP itself.

Device strategy defaults to mobile and is selectable (mobile or desktop) at the deep-audit button; the metrics strip and every deep-audit finding are labeled with whichever was used. Results are cached for 24 hours per URL and strategy, and a cached result may be served to a different visitor auditing the same URL in that window — the response is labeled "served from a cached run" when that happens. Field data (real Chrome User Experience Report measurements from actual visitors, when a site has enough traffic for Google to report it) is a planned addition, not yet surfaced here; everything currently shown under a deep audit is lab data.

Scoring

Each check carries an impact weight (1 to 5, how much it moves rankings or user experience) and an effort estimate (1 to 5, typical time to fix). Priority is impact × (6 − effort), so a high-impact one-line fix scores 25 and a low-impact rebuild scores 1. The health score is the impact-weighted share of passing checks; warnings count half.