User guide
What this tool does
The Website Audit gives one page a full health check and puts the results in one report:
- Lighthouse scores for Performance, Accessibility, Best Practices and SEO, from Google’s PageSpeed Insights.
- Core Web Vitals from real visitors: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, as Chrome users experienced them over the last 28 days. This is the data Google uses in ranking.
- The speed fixes worth most, sorted by the time each could save.
- Search basics: title, meta description, canonical,
noindex, share image and other page tags. - Security headers, graded A+ to F.
- robots.txt: whether Googlebot may crawl the page, and whether the file lists a sitemap.
At the top, What to fix first puts the most important problems from all of these in order. Copy report gives you the whole audit as Markdown for a ticket, a pull request or an email to a client.
When to use it
- Before and after a release: catch speed or tag regressions.
- When pitching or onboarding a client: a quick, shareable picture of where a site stands.
- When Search Console reports poor Core Web Vitals: see which metric fails and which fixes help it.
- For a quick check of an AEM page: speed, tags and Dispatcher headers in one go.
How to use it
- Enter the page’s address. It must be public, because Google runs the test from its own servers.
- Choose Mobile (the default, and what Google uses for ranking) or Desktop, then press Run audit. The Lighthouse test takes 15 to 40 seconds; the other checks finish sooner.
- Read What to fix first, then the tabs for detail. Each speed opportunity, accessibility issue and best-practice issue has an explanation and a link to Google’s guidance.
- Use Copy report or Download .md to share the results, or open the full PageSpeed Insights report.
To share a result, press Copy link. The link runs the same audit, on the same device type, when opened.
Reading Core Web Vitals
| Metric | Good | Poor | What it measures |
|---|---|---|---|
| Largest Contentful Paint (LCP) | 2.5 s or less | over 4 s | When the main content shows |
| Interaction to Next Paint (INP) | 200 ms or less | over 500 ms | How quickly the page responds to taps and clicks |
| Cumulative Layout Shift (CLS) | 0.1 or less | over 0.25 | How much the layout jumps while loading |
A page passes when all three are good for at least 75% of visits. The coloured bar under each metric shows the share of good, needs-improvement and poor visits.
Real-visitor data only exists for pages and sites with enough Chrome traffic. Without it, the tool shows data for the whole site, or none.
Lab scores vs real visitors
The Lighthouse score comes from one simulated visit on a mid-range phone over a slow connection. It’s good for finding causes and comparing changes, but it varies by a few points between runs. Real-visitor data is what users actually experienced. When the two disagree, trust the real-visitor data for priorities, and use the lab report to find causes.
Common fixes on AEM sites
- Slow LCP: preload the hero image, serve it as WebP or AVIF in the right size (Dynamic Media or the Core Components image servlet), and don’t lazy-load it.
- Render-blocking CSS and JavaScript: split client libraries by template, load JavaScript with
deferorasync, and inline only the critical CSS. - Poor INP: large tag-manager containers and analytics scripts run on every interaction. Audit Adobe Launch rules and remove unused ones.
- Caching: set long
Cache-Controllifetimes for versioned client libraries (/etc.clientlibs) in Dispatcher, and keep HTML short-lived. - Layout shift: give images and embeds a width and height, and reserve space for cookie banners and personalised content.
Using your own API key
Without a key, the tool uses Google’s small shared allowance for PageSpeed Insights, which can run out at busy times. If you host this tool yourself, create a free API key in Google Cloud and enable the PageSpeed Insights API for it. Restrict the key to your domain and to that one API, then set it as PUBLIC_PSI_KEY when building the site.
Limits
- It tests one page at a time. Templates differ, so audit a few typical pages (home, listing, article, product).
- Lighthouse doesn’t log in or click through cookie banners. A banner covering the page can affect the scores.
- The search, security and robots.txt checks are quick versions. For full detail, the tool links to the Meta Tag Previewer, the Security Headers Auditor and the Robots/Sitemap Inspector.
FAQ
- Why is my Lighthouse score different every time?
- Lab tests vary by a few points between runs because of network and server timing. Compare several runs, and rely on the real-visitor Core Web Vitals, which average 28 days of visits.
- My score is low but Core Web Vitals pass. Which matters?
- Core Web Vitals from real visitors are what Google uses for ranking. The Lighthouse score is a lab test on a slow simulated phone, useful for finding causes. Fix the opportunities that affect a failing real-visitor metric first.
- Why is there no real-visitor data?
- The Chrome UX Report only includes pages and sites with enough Chrome visitors who share usage statistics. New or low-traffic pages fall back to data for the whole site, or have none.
- Can I audit a staging site or a page behind a login?
- No. Google runs the test from its own servers, so the page must be public. Run Lighthouse in Chrome DevTools for private pages.
- Is the site I check stored anywhere?
- This site doesn’t keep the address you check: it is sent to Google’s PageSpeed Insights, which runs the test, and the other checks go through a small proxy that keeps no logs. Site analytics count visits and which tool was used, never what was checked.