All 24 checks with why-it-matters prose, severity, and cross-references to related audits.
Largest Contentful Paint is Google's primary user-experience signal for search ranking and a direct measure of ISO-25010 time-behaviour. When LCP exceeds 2.5s, Google's data shows bounce rates climb sharply — 53% of mobile visitors abandon a page that takes more than 3s to load. For a marketing page, that abandoned visit represents lost acquisition revenue. An unoptimised hero image served over full SSR with no CDN is the most common culprit: it stacks TTFB latency on top of image download time, guaranteeing a failing score on both real-user monitoring and Lighthouse CI. Failing LCP also signals poor Core Web Vitals to the Google Search Console, which feeds directly into ranking demotion in the Page Experience system.
Why this severity: Critical because a failing LCP score simultaneously harms Google search rankings and increases visitor bounce rates, making it the highest-leverage performance metric for marketing ROI.
marketing-page-speed.core-web-vitals.lcp-thresholdSee full patternCumulative Layout Shift above 0.1 — Google's 'needs improvement' threshold under ISO-25010 time-behaviour — causes visible content jumps that erode user trust and trigger accidental clicks. A hero image without explicit dimensions reserves no space in the layout; when it loads, everything below it shifts down. A cookie consent bar using `position: relative` shoves the page body down every time it appears. Beyond user frustration, high CLS is a Core Web Vitals failure that degrades page experience scores in Google Search and can reduce organic rankings for the affected URL. Marketing pages built with AI tools are especially prone to this — image dimensions are frequently omitted and cookie banners are injected as afterthoughts.
Why this severity: Critical because visible layout shifts destroy user trust and directly lower Google Core Web Vitals scores, reducing organic search rankings for the affected marketing page.
marketing-page-speed.core-web-vitals.cls-thresholdSee full patternInteraction to Next Paint (INP) measures how quickly a page responds to any user gesture — click, tap, or keyboard input. Google replaced FID with INP as a Core Web Vitals metric in March 2024 because INP captures the full session, not just the first interaction. INP above 200ms is classified as 'poor' and is driven almost entirely by long JavaScript tasks blocking the main thread. Marketing pages are high-risk: analytics, chat, heatmap, and ad pixel scripts are routinely copy-pasted from vendor docs as synchronous `<script>` tags in `<head>`, each forcing the browser to stop parsing HTML until the script downloads and executes. On mid-range Android, three synchronous third-party scripts can easily add 300–500ms of blocking time, breaching the INP threshold and degrading the Core Web Vitals page experience score.
Why this severity: High because synchronous third-party scripts cause measurable INP degradation on mid-range mobile devices, creating Core Web Vitals failures that feed into Google's Page Experience ranking signal.
marketing-page-speed.core-web-vitals.fid-inp-thresholdSee full patternTime to First Byte is the foundation every other performance metric builds on — a slow TTFB adds its full penalty to LCP, FCP, and INP simultaneously. ISO-25010 time-behaviour defines server response time as a core quality characteristic, and marketing pages violate it most commonly by using full server-side rendering with no caching on a single-region origin. A user in London hitting a server in us-east-1 with no CDN experiences 150–250ms of raw network latency before the server even starts generating HTML, plus server processing time. TTFB above 800ms is a direct cause of poor Core Web Vitals scores across all categories and signals to Google's Page Experience system that the server infrastructure is underperforming for users.
Why this severity: High because TTFB directly sets a floor under LCP, FCP, and INP — a slow origin server makes all downstream performance optimisations less effective regardless of their quality.
marketing-page-speed.core-web-vitals.ttfb-thresholdSee full patternFirst Contentful Paint at 1.8s or below is Google's 'good' threshold and directly correlates with user-perceived responsiveness as defined under ISO-25010 time-behaviour. FCP above 1.8s is most commonly caused by render-blocking resources: CSS stylesheets in `<head>` that the browser must fully download and parse before it can paint anything. A 120KB unoptimised CSS bundle plus two Google Font `<link>` tags without `font-display` can push FCP past 2.5s on a 4G connection, producing an invisible page that users perceive as broken. Every additional 100ms of FCP correlates with a measurable increase in bounce rate on marketing pages, reducing the number of users who reach the conversion CTA.
Why this severity: Medium because FCP delays are user-visible and increase bounce rates, but the impact is partially mitigated when TTFB is already good — the combined failure is more severe than either alone.
marketing-page-speed.core-web-vitals.fcp-budgetSee full patternCore Web Vitals targets are only useful if you know whether you're meeting them in production. Lab scores from a single Lighthouse run miss real-user variance across device classes, connection speeds, and geographic regions. Without monitoring — a `reportWebVitals` hook, `web-vitals` instrumentation, or Lighthouse CI asserting thresholds in CI — regressions introduced by new features or third-party script additions go undetected until Google Search Console flags a ranking demotion. ISO-25010 time-behaviour quality cannot be assured without a measurement mechanism. Teams that don't measure CWV routinely discover they've been failing for months when they first run a Lighthouse audit.
Why this severity: Info because absent monitoring doesn't immediately harm users, but it guarantees that performance regressions go undetected until they've already damaged search rankings.
marketing-page-speed.core-web-vitals.cwv-monitoringSee full patternHero images are the single most common LCP element and the single largest contributor to page weight on marketing pages — a 1.2MB JPEG hero consumes more bandwidth than the entire rest of a well-optimised page combined. ISO-25010 resource-utilisation measures how efficiently a system uses network bandwidth; serving a full-resolution uncompressed JPEG to every visitor regardless of device is a direct violation. WebP at quality 80 is typically 60–70% smaller than an equivalent JPEG; AVIF can reach 80% smaller. On a 4G connection, the difference between a 200KB WebP and a 1.2MB JPEG is approximately 800ms of LCP penalty — enough to move a page from 'good' to 'needs improvement' on Google's scale.
Why this severity: High because an unoptimised hero image is the most common single cause of LCP failure, directly harming both Core Web Vitals scores and search rankings.
marketing-page-speed.resource-optimization.hero-image-formatSee full patternTotal page weight directly governs how long a marketing page takes to load on the mobile devices that now account for the majority of web traffic. ISO-25010 resource-utilisation defines bandwidth consumption as a key quality attribute. Google's research pegs 1.6MB as the point at which bounce rates on mobile 4G connections begin to climb non-linearly — above that threshold each additional 100KB correlates with a measurable user drop-off. Marketing pages built with AI coding tools frequently blow past this budget by combining an unoptimised hero image with multiple third-party analytics SDKs and an unpurged CSS framework, each of which individually seems harmless but collectively produce a 3–5MB page that loads in 8–12s on a 4G connection.
Why this severity: High because total page weight exceeding the 1.6MB mobile budget directly increases bounce rates and degrades Core Web Vitals scores across LCP, FCP, and INP simultaneously.
marketing-page-speed.resource-optimization.total-page-weightSee full patternEvery external `<link rel="stylesheet">` in `<head>` adds at minimum one additional network round-trip before the browser can render a single pixel — this is the definition of a render-blocking resource as measured by ISO-25010 time-behaviour. On a 4G connection, one round-trip is approximately 80–120ms; three blocking stylesheets add 240–360ms to FCP before any page content appears. This is distinct from CSS file weight: even a 1KB external stylesheet blocks paint if it's in `<head>` without a non-blocking loading pattern. Marketing pages accumulate these most often from third-party widget CSS (chat, cookie consent, marketing pixels) pasted in verbatim from vendor documentation.
Why this severity: High because each render-blocking stylesheet in `<head>` adds a full network round-trip to FCP regardless of the file's size, making this a pure latency tax with no user benefit.
marketing-page-speed.resource-optimization.critical-css-inlinedSee full patternA synchronous `<script>` tag in `<head>` without `async` or `defer` halts the HTML parser entirely until the script downloads, parses, and executes — this is the most severe form of render-blocking resource under ISO-25010 time-behaviour measurement. Google Tag Manager, Hotjar, and Meta Pixel are frequently copied from vendor docs as bare `<script src>` tags, each adding its full download time as a sequential blocking delay before any page content renders. Two synchronous third-party scripts on a 4G connection can add 400–600ms of blocked parser time, pushing FCP and LCP into 'needs improvement' territory and penalising the page in Google's Page Experience scoring.
Why this severity: High because a single synchronous script in `<head>` blocks HTML parsing for the duration of its download, adding its full latency directly to FCP and LCP regardless of the script's functional purpose.
marketing-page-speed.resource-optimization.render-blocking-resourcesSee full patternAn `<img>` tag without `width` and `height` attributes is a direct cause of Cumulative Layout Shift — the browser allocates zero space for the image before it loads, then expands the layout when the dimensions are known, shifting every element below it. This is a mechanical cause of CLS as measured under ISO-25010 time-behaviour, not a heuristic concern. Marketing pages with feature grids, testimonial carousels, and team sections frequently contain dozens of images, each a potential layout shift event. A CLS score above 0.1 classifies the page as 'needs improvement' in Core Web Vitals, which reduces the page experience signal Google uses for search ranking decisions.
Why this severity: Medium because missing image dimensions mechanically cause layout shifts that degrade CLS scores, but the ranking impact is bounded to pages with significant above-fold image content.
marketing-page-speed.resource-optimization.image-dimensions-reservedSee full patternCustom web fonts are a dual CLS and FCP risk: without `font-display: swap`, the browser hides text entirely until the font loads (FOIT — Flash of Invisible Text), delaying FCP and making the page appear blank. When the font finally loads and text reflows to a different line-height or character width, it produces layout shift that contributes to CLS. Google Fonts loaded via external `<link>` tags compound this by adding an extra DNS lookup and cross-origin connection before the font file starts downloading. ISO-25010 time-behaviour covers both of these: rendering delay and post-render layout instability. Marketing pages with two or more font families at multiple weights can accumulate 300–600ms of font-related latency on slow connections.
Why this severity: Medium because font loading strategy affects both FCP (invisible text delay) and CLS (text reflow on font swap), but the impact is bounded to pages using custom web fonts and is fully remediable.
marketing-page-speed.resource-optimization.font-loading-strategySee full patternLoading the hero image lazily — whether by setting `loading="lazy"` directly or by omitting an explicit priority signal — instructs the browser to deprioritise it until the image enters the viewport. Since the hero is almost always already in the viewport, this creates a paradox: the element that determines LCP is the last one the browser fetches. The result is typically a 1–2s LCP penalty on mobile, which is the difference between 'good' and 'poor' in Google's Core Web Vitals classification system. ISO-25010 time-behaviour defines response time as a critical quality attribute for user-facing interfaces; the above-fold content is exactly where time-behaviour matters most. Google Search Console tracks this at a per-URL level and uses it as a Page Experience ranking input.
Why this severity: Critical because lazy-loading the LCP element is a direct 1–2s LCP penalty — the single change most likely to push a marketing page from 'good' to 'poor' CWV classification.
marketing-page-speed.loading-strategy.above-fold-prioritySee full patternMarketing pages accumulate third-party scripts faster than any other page type — analytics, heatmapping, chat, A/B testing, and advertising pixels each run JavaScript on the main thread, and their combined effect on ISO-25010 resource-utilisation is additive. Five third-party script domains loading synchronously or with `beforeInteractive` strategy can contribute 300–500ms of main thread blocking time on a mid-range Android device, which directly causes INP failures above the 200ms threshold. Beyond user experience, each additional third-party domain adds a DNS lookup and TLS handshake — typically 100–300ms per new origin — before any bytes are received. Google's CrUX data consistently shows that pages with four or more synchronous marketing scripts have significantly worse INP distributions.
Why this severity: High because synchronous third-party marketing scripts collectively cause main thread blocking that exceeds Google's INP threshold on mid-range mobile, degrading Core Web Vitals and page experience rankings.
marketing-page-speed.loading-strategy.third-party-impactSee full patternService workers enable the browser to serve cached assets without hitting the network on repeat visits — a capability that directly reduces ISO-25010 resource-utilisation for returning users. Marketing pages attract a significant proportion of return visitors from email campaigns, social retargeting, and direct traffic, yet without a service worker those visitors re-download every JavaScript bundle, CSS file, and image on each visit as if they've never been to the site. On an 800KB page, that's approximately 400ms of avoidable latency on 4G. Service worker caching also enables offline-capable page loads, which improves perceived reliability and supports scenarios like email campaigns opened in low-signal environments.
Why this severity: Medium because absent service worker caching wastes bandwidth on repeat visits and adds unnecessary latency, but the impact is bounded to returning users rather than affecting first-visit acquisition.
marketing-page-speed.loading-strategy.service-worker-cachingSee full patternEvery new third-party origin a marketing page connects to requires a TCP handshake plus TLS negotiation before any bytes are received — typically 100–300ms per origin at 4G speeds. This is a pure latency overhead measured under ISO-25010 time-behaviour that `<link rel="preconnect">` eliminates by establishing the connection during browser idle time, before the resource is actually requested. A marketing page loading fonts from `fonts.gstatic.com` and data from an API domain without preconnect hints adds two sequential connection costs to FCP, each 100–300ms. The fix requires three lines of HTML. The absence of preconnect on high-frequency origins is the lowest-effort, highest-impact optimisation frequently left unconfigured.
Why this severity: Medium because the absence of preconnect hints adds 100–300ms per third-party origin to FCP, but the impact is bounded to origins used early in the page load and is trivially remediable.
marketing-page-speed.loading-strategy.preconnect-prefetchSee full patternBelow-fold images that lack `loading="lazy"` force the browser to initiate download requests for all images simultaneously on page load, regardless of whether the user ever scrolls to see them. This wastes bandwidth — an ISO-25010 resource-utilisation concern — and competes for network bandwidth with the above-fold images that actually determine LCP. A marketing page with a 6-panel feature grid and a testimonial carousel can easily have 12–15 images below the fold; without lazy loading, those downloads start in parallel with the hero image download, increasing LCP by crowding the network queue. On a 4G connection with 6Mbps bandwidth, 15 simultaneous image requests significantly reduce the throughput available to the critical LCP image.
Why this severity: Low because missing lazy-load on below-fold images wastes bandwidth and mildly increases LCP by competing with critical resources, but the impact is secondary to above-fold optimisations.
marketing-page-speed.loading-strategy.below-fold-lazy-loadSee full patternSpeculative prefetch turns navigation between marketing pages — homepage to pricing, pricing to signup — from a network-dependent operation into an instant cache hit. Without prefetch, clicking a CTA initiates a full page load cycle: DNS, TCP, TLS, request, response, parse, render. With prefetch, the browser fetches the next page during idle time after the current page loads, so the navigation appears instant. ISO-25010 time-behaviour quality applies to navigation response time as well as initial page load. In Next.js, this capability is built into `<Link>` with zero configuration — the only failure mode is using plain `<a href>` tags on conversion CTAs, which disables the automatic prefetch without any explicit opt-out.
Why this severity: Info because speculative prefetch is an enhancement that improves perceived navigation speed, but its absence doesn't harm initial page load metrics or search rankings directly.
marketing-page-speed.loading-strategy.speculative-prefetchSee full patternA CDN is the most impactful infrastructure decision for marketing page performance and has no substitute — it is the mechanism by which TTFB for users far from the origin drops from 500–1500ms to under 50ms. ISO-25010 time-behaviour quality for global users is impossible to achieve without geographic distribution of content. A marketing page served from a single-region VPS or single-region cloud deployment fails TTFB for any user outside that region, and since marketing pages target geographically distributed prospects, most visitors will be geographically distant from a single-region origin. Critically, this isn't just an average performance issue: users in slow-TTFB regions have lower engagement rates, lower conversion rates, and generate less revenue per visitor.
Why this severity: Critical because no application-level optimisation can compensate for the physical latency of serving from a single-region origin to geographically distributed users — CDN is the only fix.
marketing-page-speed.infrastructure.cdn-usageSee full patternServing images as static files from `public/` without an optimisation pipeline means every visitor — regardless of device, screen resolution, or browser — downloads the same full-resolution, original-format file. A desktop hero image at 2400×1600 sent to a mobile user at 375px width wastes 85–90% of the downloaded pixels. ISO-25010 resource-utilisation explicitly covers this kind of inefficiency: transferring significantly more data than the client can use. An image CDN or optimisation pipeline automatically serves WebP to browsers that support it (95%+), resizes to the requested display size, and compresses to the optimal quality — typically reducing hero image payload by 60–80% compared to an unoptimised JPEG.
Why this severity: High because an absent image optimisation pipeline forces every visitor to download full-resolution source files, wasting bandwidth and adding hundreds of milliseconds to LCP on mobile.
marketing-page-speed.infrastructure.image-cdn-pipelineSee full patternUncompressed text assets — HTML, CSS, and JavaScript — transfer at their full source size over the network. Brotli compression reduces text payload by 15–25% compared to gzip, and 60–80% compared to uncompressed, which directly maps to the ISO-25010 resource-utilisation quality attribute. A 200KB JavaScript bundle served uncompressed arrives as 200KB; with Brotli it arrives as approximately 45KB. At 4G speeds, that's roughly 250ms of avoidable download time per bundle. Marketing pages with multiple JS chunks and third-party scripts compound this: every uncompressed text resource adds to the total transfer time that feeds into FCP and LCP. Serving `compress: false` without an external compression layer is an explicit choice to send more bytes than necessary.
Why this severity: Medium because disabling compression adds 60–80% to text asset payload, measurably increasing FCP and LCP, but Brotli is automatic on modern hosting platforms so the failure only occurs on custom server configurations.
marketing-page-speed.infrastructure.compression-brotliSee full patternBrowser cache headers control whether a returning visitor re-downloads assets on every page load or serves them from the local disk cache in milliseconds. Without `Cache-Control: public, max-age=31536000, immutable` on hashed static assets, every visit — including from users who visited yesterday — initiates fresh network requests for all JavaScript bundles, CSS, and images. ISO-25010 resource-utilisation covers this: downloading the same unchanged 200KB bundle on every repeat visit is pure waste. Modern frameworks (Next.js, Vite, webpack) include content hashes in filenames, making year-long browser caches safe — changing any file produces a new filename, so stale cache never serves outdated content.
Why this severity: Medium because absent long-lived cache headers cause repeat visitors to re-download all assets unnecessarily, increasing page load times and bandwidth costs, but the impact is limited to returning users rather than first-visit acquisition.
marketing-page-speed.infrastructure.static-asset-cachingSee full patternNetwork latency is bounded by the speed of light — a request from a user in São Paulo to a server in Singapore must traverse approximately 18,000km of fibre, which takes at minimum 120ms at the speed of light in glass, often 200–400ms in practice when routing overhead is included. ISO-25010 time-behaviour cannot be met for geographically mismatched deployments without a CDN, and for hosting platforms that don't include built-in CDN (Fly.io single region, Railway, bare VPS), the chosen region directly determines TTFB for non-local users. A US-focused marketing site deployed to `ap-southeast-1` will consistently fail the 800ms TTFB threshold for US visitors, regardless of how well the application itself is optimised.
Why this severity: Low because region mismatch only affects non-CDN hosting configurations, and the fix (switching region or adding a CDN) is straightforward — the scope is limited to non-standard deployment setups.
marketing-page-speed.infrastructure.ttfb-server-locationSee full patternMarketing page HTML served without edge caching forces every visit — including from users in the same CDN region as a previous visitor — to hit the origin server and wait for a full server-rendered response. With ISR or `s-maxage` cache headers, the CDN serves the pre-generated HTML directly from an edge node, making repeat visits within the cache window as fast as static file serving (TTFB under 50ms). ISO-25010 time-behaviour quality for HTML responses is identical to static assets when edge caching is configured. Marketing pages have no per-user dynamic content, making them ideal candidates for edge caching — yet `Cache-Control: no-store` or `force-dynamic` rendering defeats this capability entirely.
Why this severity: Info because edge caching for HTML is an enhancement over ISR that further reduces origin load and TTFB variance, but its absence is less severe than the underlying TTFB and CDN checks it depends on.
marketing-page-speed.infrastructure.edge-caching-configSee full patternRun this audit in your AI coding tool (Claude Code, Cursor, Bolt, etc.) and submit results here for scoring and benchmarks.
Open Page Speed Audit