Digital Asset Audit: Confidential Website
A governance-framed Lighthouse audit of a live site. Core Web Vitals are treated as an audited control set.
Why this matters
A website is a digital asset like any other, carrying real operational and reputational risk. This audit applies the same controls-assessment logic used in financial and compliance audits. The full method is set out in the Methodology document.
Audit date: 4 July 2026. Method: Google PageSpeed Insights (Lighthouse 13.4.0, desktop, custom throttling, single-page session).
1. Overall scorecard
| Category | Score | Rating |
|---|---|---|
| Performance | 63 / 100 | Needs improvement |
| Accessibility | 93 / 100 | Good |
| Best Practices | 73 / 100 | Needs improvement |
| SEO | 85 / 100 | Good |
| Agentic browsing readiness | 2 / 3 | Partial |
| Core Web Vitals assessment | — | Failed |
Risk read: the site fails Google's Core Web Vitals assessment on desktop, driven almost entirely by loading performance (LCP, FCP, TTFB). Accessibility and SEO are in good standing, which limits legal and discoverability exposure but does not offset the user-experience and conversion risk created by slow loading.
2. Core Web Vitals: the pass/fail control set
Core Web Vitals are the three metrics Google uses to certify ‘good’ page experience at the 75th percentile of real user visits. All three must pass for a page to be certified good overall.
| Metric | Measures | Result | Threshold | Status |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | Time until the largest visible element renders | 6.5 s | ≤ 2.5 s | Fail |
| Interaction to Next Paint (INP) | How quickly the page responds to input across the visit | 98 ms | ≤ 200 ms | Pass |
| Cumulative Layout Shift (CLS) | Unexpected movement of visible elements during load | 0.01 | ≤ 0.1 | Pass |
2.1 Largest Contentful Paint (LCP): the primary finding
LCP tracks the moment the largest content element (image, video poster, or block of text) becomes visible. It is the metric users equate with ‘did the page load’. At 6.5 s, this site loads well past the ‘poor’ threshold of 4 s, let alone the 2.5 s ‘good’ bar. Google classifies a 75th-percentile LCP of around 5 seconds as poor.
Root causes identified in this audit: render-blocking requests (est. 1,280 ms of savings available), an oversized network payload (5,294 KiB total), inefficient image delivery (122 KiB of savings available), and heavy JavaScript execution (1.4 s).
- Preload the hero/LCP image with <link rel="preload" as="image" fetchpriority="high">.
- Compress and serve images in modern formats (WebP/AVIF) at correctly sized dimensions.
- Eliminate or defer render-blocking CSS/JS above the fold.
- Move to a CDN or improve server response time (TTFB is currently 2.9 s, itself a major contributor).
2.2 Interaction to Next Paint (INP): passing, but monitor
INP measures the delay between a user's interaction and the browser's next visual update, sampled across the entire session and reported at the worst representative percentile. 98 ms is comfortably under the 200 ms ‘good’ threshold.
Governance note: even a passing metric needs periodic re-testing. INP is sensitive to third-party scripts such as chat widgets, analytics, and ad tags, so a future audit should re-check this metric whenever new tracking scripts are added.
2.3 Cumulative Layout Shift (CLS): passing
CLS quantifies unexpected movement of visible elements, such as a banner pushing text down after it loads. That movement causes mis-clicks and a perception of instability. At 0.01, this site sits well within the 0.1 ‘good’ threshold.
Maintenance recommendation: keep explicit width and height attributes (or aspect-ratio in CSS) on all images and embeds going forward, since this is the most common regression cause.
3. Supporting loading metrics (diagnostic, not pass/fail)
These are not part of the Core Web Vitals pass/fail set, but Google uses them to diagnose why LCP is failing.
| Metric | Measures | Result | Interpretation |
|---|---|---|---|
| First Contentful Paint (FCP) | Time until any content first renders | 4.5 s | Poor. Users see a blank screen for too long. |
| Time to First Byte (TTFB) | Server response time | 2.9 s | Poor. It consumes over half the good LCP budget before rendering starts. |
| Speed Index | How quickly page content is visually populated over time | 3.6 s | Poor. It reinforces the loading-speed finding above. |
Recommendation: TTFB should be the first fix prioritised, since it is a hard floor under every other loading metric. No amount of front-end optimisation can overcome a slow server response.
4. Prioritised findings & opportunities
Ranked by estimated impact, as a risk register would be.
| Priority | Finding | Estimated impact | Recommended action |
|---|---|---|---|
| High | Minimise main-thread work | 4.0 s of main-thread time | Break up long JavaScript tasks; defer non-critical scripts |
| High | Reduce JavaScript execution time | 1.4 s | Code-split, remove unused libraries, lazy-load non-critical scripts |
| High | Render-blocking requests | 1,280 ms savings available | Inline critical CSS, defer/async remaining JS and CSS |
| High | Reduce unused JavaScript | 663 KiB savings available | Audit and remove dead code / unused third-party scripts |
| Medium | Use efficient cache lifetimes | 625 KiB savings available | Set long Cache-Control / Expires headers on static assets |
| Medium | Avoid enormous network payloads | Total size 5,294 KiB | Compress assets, lazy-load below-the-fold content |
| Medium | Reduce unused CSS | 286 KiB savings available | Purge unused CSS rules, split by page/component |
| Medium | Improve image delivery | 122 KiB savings available | Use responsive srcset, modern formats, correct compression |
| Low | Images missing explicit width/height | — | Add explicit dimensions to prevent future CLS regressions |
| Low | Minify CSS/JS | 3–5 KiB savings available | Enable build-time minification |
5. Non-performance categories
- Accessibility (93/100): a good baseline. This indicates reasonable adherence to WCAG-aligned checks such as alt text, contrast, and ARIA. Recommend a full manual WCAG 2.2 AA review, since Lighthouse only automatically tests a subset of accessibility criteria.
- Best Practices (73/100): needs improvement. Typically flags outdated libraries, console errors, or missing security headers such as HSTS and CSP. A follow-up security-header review is worthwhile, as this sits closer to genuine risk and compliance territory than pure UX.
- SEO (85/100): good. Technical SEO fundamentals such as meta tags, crawlability, and mobile-friendliness are largely in place.
- Agentic browsing (2/3): an emerging Lighthouse category assessing how well the page is structured for AI browsing agents to read and act on. A partial score suggests some machine-readability gaps that may matter more as agentic browsers become common.
Governance takeaway
This audit demonstrates a repeatable, evidence-based method for assessing a digital asset:
- Baseline: capture Core Web Vitals + Lighthouse category scores on a fixed date, tool version, and testing conditions (recorded here for reproducibility).
- Classify: map each metric to Google's published Good / Needs Improvement / Poor thresholds, not subjective judgment.
- Prioritise: rank remediation by estimated impact (time/KiB savings), the same way a risk register ranks findings by severity.
- Re-test on a cadence: Core Web Vitals reflect a rolling 28-day window of real user data, so re-audits should be spaced at least monthly to see the effect of any fix.
Sources & reference for future audits
All thresholds and definitions in this document are drawn from Google's official documentation, which should remain the fallback reference any time this audit is repeated.
- Web Vitals overview and thresholds: https://web.dev/articles/vitals
- How the Core Web Vitals thresholds were determined: https://web.dev/articles/defining-core-web-vitals-thresholds
- Google Search Central, Understanding Core Web Vitals: https://developers.google.com/search/docs/appearance/core-web-vitals
- Run your own audit: https://pagespeed.web.dev/
Note: Google states Core Web Vitals thresholds and the metric set itself are reviewed periodically (no more than once per year for stable metrics), so always confirm current thresholds against the links above before citing them in a new audit.