Coder Legion - Recent posts tagged lcp

Critical CSS and Render-Blocking Resources: Faster First Paint Without Guessing

Wed, 28 Oct 2026 07:59:06 +0000

Lighthouse keeps recommending “Eliminate render-blocking resources,” and the usual response is to inline more CSS or defer everything in sight. That can help First Contentful Paint. It can also ship a Flash of Unstyled Content, bloat the HTML response, or leave Largest Contentful Paint worse than before.

Critical CSS is a narrower job: ship only the styles needed for the first viewport as soon as HTML arrives, then load the remainder without blocking that first paint. The method is measurable. Chrome’s Coverage tab shows what was used on load; guessing from a theme “optimise” toggle is not the same work.

The sections below walk through extraction and deferral for agency sites. For what First Contentful Paint and Total Blocking Time mean in lab reports, keep FCP and TBT: Supporting Metrics Beyond Core Web Vitals open. For Largest Contentful Paint thresholds and fixes, see LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It. Resource hints that pair with deferred CSS are covered in Preload, Prefetch, and Preconnect: Resource Hints for Faster Core Web Vitals. The full browser critical rendering path (DOM, CSSOM, layout, paint) is a separate map; here the focus stays on CSS extraction and render-blocking stylesheets.

What critical CSS is (and what it is not)

Critical CSS is the subset of rules required to render content that is visible in the initial viewport (sometimes called above the fold). Google’s performance guides describe it as styles needed so the browser can paint meaningful content without waiting for every stylesheet on the network. That definition is deliberately smaller than “the CSS file the theme already ships.”

It is not “all CSS for the homepage,” and it is not a substitute for removing unused CSS from the full bundle. It is also not the same as understanding every stage of the critical rendering path. Critical CSS answers a shipping question: which rules must travel with the first HTML response so first paint is not stuck behind a large link rel="stylesheet"?

When the critical set is too large, you pay HTML bytes on every document request, often with a short cache lifetime. When it is too small, users see unstyled or partially styled content until the deferred sheet arrives. The useful size is usually the Coverage-green set for the templates you care about on mobile, plus a margin for the Largest Contentful Paint element’s layout.

How render-blocking CSS delays First Contentful Paint and Largest Contentful Paint

By default, CSS is render-blocking. The browser builds the CSS Object Model before it paints, so it avoids a Flash of Unstyled Content. That behaviour is intentional. The cost appears when a large shared stylesheet must finish downloading and parsing before any text or hero layout appears.

In Lighthouse and PageSpeed Insights, that cost shows up as the Eliminate render-blocking resources opportunity: stylesheet (and script) URLs that sit on the critical path to first paint. First Contentful Paint moves when those bytes clear earlier. Largest Contentful Paint can improve when the LCP element’s styles and related layout rules are available sooner, but LCP still depends on the LCP resource itself (image, text block, or video poster). Fixing render-blocking CSS does not replace image optimisation for a heavy hero.

Scripts marked without async or defer can block parsing as well. Stylesheets are the subject here. Script deferral and Interaction to Next Paint belong on a separate main-thread checklist; not every render-blocking URL in the audit is a CSS problem.

How to find critical CSS with Chrome DevTools Coverage

Extraction works best from evidence, not from a plugin default. Theme toggles that claim to eliminate render-blocking resources rarely show which rules still matter for first paint. A practical Coverage pass looks like this:

Open the page on a representative mobile viewport (or device mode that matches your lab strategy).
Open DevTools → Command Menu → Show Coverage, then reload so the report captures the initial load.
Inspect each stylesheet URL. Green marks rules used for that load; red marks unused rules in that file for that load.
Treat green rules that style above-the-fold content (header, hero, primary text, navigation chrome) as candidates for the critical set. Red rules for below-the-fold accordion bodies, footers, and dormant components usually belong in the deferred sheet.

Coverage is a laboratory sample. A cookie banner that appears after consent, or a mega-menu that opens on hover, may need styles that were red on a cold load. Those rules still belong in the critical set when they affect first paint or first interaction on real client templates. For portfolio work, Coverage on home and on the conversion URL, then a careful merge of the two sets, beats inlining two full themes.

Automated extractors (for example the Critical tooling family referenced in Chrome’s render-blocking docs) can speed the cut when the architecture allows it. The output still needs a Coverage check and a visual pass. Automated critical CSS that omits font-face or hero layout rules is a common FOUC source, and that failure usually shows up on mobile first.

How to inline critical CSS and defer the rest

A common pattern, documented on web.dev, looks like this:

Place the critical rules in a <style> block in the document <head> (minified).
Load the full stylesheet asynchronously so it does not block first paint, for example with rel="preload" as style and an onload handler that switches it to a stylesheet, plus a <noscript> fallback for browsers without script.
Keep the inlined block small enough that the HTML response stays lean.

<head>
  <style>/* minified critical rules only */</style>
  <link
    rel="preload"
    href="/css/site.css"
    as="style"
    onload="this.onload=null;this.rel='stylesheet'"
  />
  <noscript><link rel="stylesheet" href="/css/site.css" /></noscript>
</head>

Production sites often wrap the preload pattern in a small helper (loadCSS-style) so Content Security Policy and older browsers behave predictably. The principle stays the same either way: critical styles travel with HTML, and the bulk of the CSS arrives without blocking the first paint. The helper exists for edge cases; the measurement still comes from Coverage and a dated lab run.

Deferred CSS pairs well with honest resource hints when the full sheet is still important soon after paint. A preload for the stylesheet is part of that story; preloading every font and hero image at once usually blows the budget. The decision table in the resource-hints guide keeps those choices from competing with each other.

Media-query stylesheets as a lighter alternative

Not every render-blocking sheet needs full critical-CSS extraction. Styles that only apply to print, or only above a large breakpoint, can stay in separate files with a media attribute. The browser still downloads them according to its rules, but it does not block first paint on media that do not match.

<link rel="stylesheet" href="/css/site.css" />
<link rel="stylesheet" href="/css/print.css" media="print" />
<link rel="stylesheet" href="/css/wide.css" media="(min-width: 64em)" />

This approach helps when print or desktop-only rules inflate a shared bundle. It does not replace critical CSS when the default (always-matching) sheet is still huge. Media splits suit conditional CSS; extraction suits the case where the main all stylesheet is the blocker Lighthouse names.

Mistakes that make “critical CSS” slower

Inlining the entire theme. Critical CSS that is “most of app.css” increases HTML weight on every navigation and often cannot be cached as aggressively as a hashed stylesheet. First paint may still improve on a cold cache, but TTFB and transfer size can suffer on repeat views and multi-page sessions.

Guessing without Coverage. Theme or page-builder toggles that claim to eliminate render-blocking resources often defer styles the first paint still needs. The result is FOUC, layout thrash, or a late Cumulative Layout Shift when the full sheet arrives.

Forgetting the Largest Contentful Paint element. If the LCP node is a text block or image whose dimensions depend on deferred rules, a generic render-blocking audit can go green while LCP stays red. LCP styles belong in the critical set, and the LCP resource itself still needs its own optimisation. Agency reports that celebrate a cleared opportunity while LCP stays amber lose credibility fast.

Skipping noscript or CSP-safe loading. Async CSS patterns that rely only on inline onload handlers can fail under strict Content Security Policy. A fallback matters when the client’s security headers are strict. Test the pattern under the same CSP the production site already ships.

Treating one homepage pass as the portfolio. Agency sites share templates. Critical CSS extracted only from a brochure home can miss booking or checkout chrome. Coverage on the conversion URL before you declare the set done catches that gap.

How to verify the change in Lighthouse and monitoring

After critical CSS ships, a useful verification loop looks like this:

Record the laboratory tool, URL, strategy (mobile or desktop), and date for a before baseline.
Re-run Lighthouse or PageSpeed Insights on the same URL and strategy. Check Eliminate render-blocking resources, First Contentful Paint, and Largest Contentful Paint together.
Visually confirm first paint on a throttled mobile profile: no long unstyled flash, hero and header readable early.
Watch Cumulative Layout Shift if late styles change dimensions after paint.
Put a follow-up lab run on the calendar, and on other templates that share the CSS pipeline.

A single green opportunity row is not a portfolio proof. Scheduled lab tests catch the next theme update that reintroduces a blocking sheet. Budgets on FCP or LCP make that regression visible without waiting for a client complaint.

FAQ

Is critical CSS the same as eliminating unused CSS?
No. Unused CSS removal shrinks the full stylesheet. Critical CSS chooses which rules travel with the first HTML response. Teams usually need both over a quarter: unused CSS for transfer size, critical CSS for first paint timing.

Will critical CSS always improve Largest Contentful Paint?
Not always. It helps when LCP is waiting on stylesheet work. If LCP is a large image or a slow server, those paths still need work. Reading FCP and LCP together after the change shows which lever moved.

Can we defer all CSS to the bottom of the body?
Moving the link lower can change priority, but the browser may still treat the stylesheet as high priority and you risk FOUC. An explicit critical set plus async load of the remainder, with a noscript fallback, is the more reliable pattern. Position alone rarely matches what Coverage would have selected for above-the-fold paint.

Do WordPress or Shopify “defer CSS” plugins replace Coverage?
They can automate a pattern, but they still need verification. Coverage plus a dated lab test on home and the conversion URL after enabling a plugin, with a rollback ready if FOUC appears, is the safer agency habit. Plugin defaults rarely know your booking or checkout chrome.

How does this relate to the critical rendering path?
Render-blocking CSS is one stage of the path from HTML to pixels. Extraction and deferral are the shipping half of that story. A deeper pass on DOM, CSSOM, layout, and paint belongs in a critical rendering path guide; web.dev’s Critical Rendering Path is the map when you need those stages named in order.

Measure first, then inline

Critical CSS works when the critical set is measured, small, and verified. Coverage decides what is above the fold; the inline block carries that set; an async pattern loads the rest. First Contentful Paint and Largest Contentful Paint on the same client URLs show whether the change stuck, and a follow-up lab run after the next theme update shows whether it stayed stuck.

If those lab checks need to run on a schedule across many domains, try Apogee Watcher or run a free domain check before and after the CSS change.

References

Eliminate render-blocking resources (Chrome for Developers)
Extract critical CSS (web.dev)
Defer non-critical CSS (web.dev)
Render-blocking CSS (web.dev)
Critical Rendering Path (web.dev)
Optimize resource loading (web.dev)
FCP and TBT: Supporting Metrics Beyond Core Web Vitals
LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It
Preload, Prefetch, and Preconnect: Resource Hints for Faster Core Web Vitals

Originally published on Apogee Watcher.

Preload, Prefetch, and Preconnect: Resource Hints for Faster Core Web Vitals

Sun, 18 Oct 2026 06:51:44 +0000

Resource hints are declarations in HTML or HTTP headers that ask the browser to prepare work before it would otherwise discover it. Four names show up in almost every PageSpeed Insights audit and WordPress “optimisation” plugin: dns-prefetch, preconnect, preload, and prefetch. They are not interchangeable, and they are not a substitute for making the Largest Contentful Paint (LCP) resource discoverable in the initial HTML.

What follows is a decision guide for agencies and product teams: which hint to use, how to preload an LCP image when the browser cannot discover it early, when preconnect helps cross-origin performance, how prefetch differs from preload, and where font preloads stop helping. For metric thresholds, keep What Are Core Web Vitals? A Practical Guide for 2026 and LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It open. Image sizing and lazy-loading rules belong with preload work, so use Image Optimisation Strategies for Better LCP Scores and Lazy Loading for LCP and CLS: When to Use loading="lazy" (and When Not To) beside this guide.

What resource hints change for Core Web Vitals (and what they do not)

Hints change when the browser starts DNS, TCP/TLS, or a fetch. They do not compress files, resize a hero image, or fix a render-blocking stylesheet on their own. Google’s resource hints course and preload critical assets guidance treat them as assists for late-discovered critical work, not as a general “speed up everything” layer.

LCP benefits most when the LCP image or font is discoverable early, or when a carefully scoped preload with fetchpriority="high" covers a late-discovered candidate. Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS) usually move for other reasons (busy main thread, missing reserved space). Adding twenty preconnect tags will not repair a 4 MB hero or a lazy-loaded above-the-fold banner.

For agencies, the reporting risk is the same as with other lab tips: a plugin adds hints sitewide, Lighthouse’s unused-preload warnings appear, and the client report claims “we implemented preconnect” without naming origins or measuring before and after. Label the hint, the origin or URL, and the dated lab row. Without those labels, the next person on the account cannot tell whether the change was real or only cosmetic.

dns-prefetch vs preconnect vs preload vs prefetch: which hint to use

Use one decision table when a client asks which tag belongs in <head>. The rows match what web.dev’s preconnect and dns-prefetch article and the resource hints learning path describe. Put the table in the client report once so the team stops arguing over tags that mean different things.

Hint	What it starts early	Best when	Avoid when
`dns-prefetch`	DNS lookup only for a cross-origin host	You will request that host soon, but it is not among the most urgent early requests	You need an early TLS connection for a known critical origin (use `preconnect` instead)
`preconnect`	DNS + TCP + TLS to a cross-origin origin	Exact URL is unknown yet, but a critical fetch will hit that origin soon (for example an image CDN)	You already know the exact critical URL (prefer `preload`); or you are opening connections to many origins at once
`preload`	Fetch of a specific current-document resource	Late-discovered critical asset for this page load (LCP image not in HTML, `@font-face` file, CSS `@import`)	The resource is already discoverable in HTML; or you preload speculative next-page URLs
`prefetch`	Low-priority fetch likely needed on a future navigation	Next-page document or asset with clear probability	You need the resource for the current LCP; or you confuse it with Speculation Rules prerender

dns-prefetch versus preconnect is a cost trade-off. preconnect is stronger for a critical third-party origin and more expensive if overused. Prefer a short list of critical origins for preconnect, and dns-prefetch for the rest, then measure. That pairing is the practical answer when someone asks “dns-prefetch vs preconnect.”

How to preload the LCP image (and when preload is the wrong fix)

The first rule for preload LCP work is still discoverability. Optimize Largest Contentful Paint asks whether the LCP resource appears in the initial HTML so the preload scanner can see it. An <img> with src or srcset in the document usually does not need a duplicate preload. A CSS background-image, an image injected only after JavaScript runs, or a late-discovered responsive candidate often does.

When you preload, set as="image", match the real URL (or responsive attributes), and use fetchpriority="high" on the preload. Chrome’s LCP request discovery insight still expects high fetch priority on the preload and on the image element when both exist. For responsive heroes, follow web.dev’s caution: use imagesrcset / imagesizes on the preload and avoid a bare href that downloads the wrong fallback on browsers without responsive preload support.

<link
  rel="preload"
  as="image"
  href="/media/hero-1200.webp"
  type="image/webp"
  fetchpriority="high"
>
<img
  src="/media/hero-1200.webp"
  width="1200"
  height="675"
  fetchpriority="high"
  alt="…"
>

If the LCP image is already in HTML with fetchpriority="high" and without loading="lazy", skip the preload and fix file size, dimensions, or CDN latency instead. Preload is the wrong fix when the real problem is a lazy-loaded hero (see the lazy-loading guide linked above) or a 3 MB unoptimised file. Same-origin delivery still beats a third-party image host plus preconnect when you can arrange it.

Preconnect for performance on cross-origin origins

Preconnect performance gains show up when an important early request must open a new origin before the real URL is known. Classic cases include an image CDN whose path depends on breakpoints, or a font host you will hit after CSS parses. Preconnect to required origins in Lighthouse flags missing connections; it does not mean every third party deserves a tag.

Keep the list short. Each preconnect spends time on DNS, TCP, and TLS, and too many compete for limited connections. Prefer same-origin or proxied assets for LCP when the platform allows it. When a cross-origin LCP host is unavoidable, one early preconnect to that host is often enough, with dns-prefetch for analytics or chat widgets that load later.

Cross-origin font files also need CORS-aware loading when you preload them. Pair font preconnect / preload with subsetting and font-display choices from Font Subsetting for Web Performance: 4 Tools to Reduce Font File Size and Improve LCP. Preloading full family files on every template usually wastes more bandwidth than it saves.

Prefetch versus preload is the comparison that most plugin marketing pages blur. preload is for a resource required to render or complete the current page load at high priority relative to its type. prefetch is a low-priority hint for something the user is likely to need on a later visit. Using prefetch for the current LCP image gives that image too low a priority. Using preload for speculative next-page HTML can take bandwidth away from the current hero.

Document-level rel=prefetch is also not the same product as Speculation Rules prefetch or prerender, which WordPress and Chrome have been expanding. For CMS plugin behaviour and when speculative loading helps or hurts, see WordPress Speculation and Prerender Plugins vs Core Web Vitals. Keep classic resource-hint language separate from speculation JSON in client reports so nobody thinks a link rel=prefetch row is the same as a prerender.

Font preload limits (pair with subsetting, not instead of it)

Fonts defined in CSS @font-face rules are late-discovered until the stylesheet arrives, so a single WOFF2 preload can help text LCP candidates and shorten the time when text stays invisible. Limits matter more than most theme defaults admit. Preload only the faces used above the fold on that template. Prefer WOFF2. Include crossorigin when the font is cross-origin so the preload and the CSS request share a cache entry. Do not preload every weight in the brand kit “just in case.”

If the font file is still hundreds of kilobytes after preload, the real gain is subsetting and fewer families, not more hints. Unused preload warnings in Lighthouse often mean a template preloads a face that page never uses. Agencies should treat font preload as a per-template list in the performance budget, reviewed when themes or design systems change.

Resource-hint mistakes that hurt lab and field scores

Hint sprawl. Ten preconnect origins and a dozen preload rows fight the browser’s own prioritisation. Start from the LCP request chain in PageSpeed Insights or Chrome DevTools, then add the minimum hints that close a real gap. If you cannot name the request each hint helps, delete the hint.

Preloading what HTML already discovers. Duplicate work and unused-preload audits follow. Prefer fixing markup so the scanner sees the image. A redundant preload is not harmless spare capacity.

Lazy-loading the LCP candidate while preloading something else. The hero still waits; the client sees green tips that do not move field LCP. Fix lazy rules first. Only then revisit preload.

Confusing prefetch with preload. Next-page speculation belongs in a separate task from current-page LCP. Mixing the words in a status report is how wrong priorities get released. Keep the vocabulary aligned with the decision table above.

Untested plugin defaults. Many “enable all resource hints” toggles invent origins from third-party scripts. Audit the rendered <head> on revenue and conversion templates, not only the plugin settings screen. A settings screen can look clean while a theme filter still injects tags later.

No-Vary-Search for prefetch and speculation (short note)

When you prefetch or prerender documents, query strings often break cache hits: /product and /product?utm_source=newsletter look like different URLs by default. The HTTP No-Vary-Search response header tells caches which query parameters do not change the response, so a prefetched document can still satisfy a navigation that adds tracking parameters. Speculation Rules can also declare an expected value via expects_no_vary_search.

Treat that as a checklist item beside speculation work (see the WordPress speculation post and MDN’s No-Vary-Search page), not as a replacement for choosing preload versus prefetch on the current page. Only ignore parameters that truly leave the HTML unchanged. A deeper Speculation Rules how-to is planned later on the Watcher calendar; keep this section short on purpose.

How to verify resource hints after you deploy them

Make one change at a time on a labelled URL. Capture mobile and desktop lab rows in PageSpeed Insights or Lighthouse with the same strategy before and after. Confirm the LCP element and request chain still match the story you told the client. Watch for unused preload warnings and for regressions in Total Blocking Time when too many early fetches compete.

Field Core Web Vitals move on their own clock. A correct preload can still take weeks to show in CrUX. Keep synthetic budgets on the journey URLs that matter, and re-read field categories on a schedule rather than after every deploy. The same logic as synthetic versus real-user monitoring applies here: hints are how you implement the early fetch; dated lab history is how agencies prove that fetch worked.

FAQ

Should I always preload the LCP image?
No. Preload when the LCP resource is not discoverable in the initial HTML, or when you need an early high-priority fetch the scanner cannot see yet. If the hero <img> is already in the document with fetchpriority="high" and without lazy loading, fix file weight and discovery first. Preload is a fix for late discovery, not a default for every template.

Is preconnect better than dns-prefetch?
For a critical cross-origin origin on the LCP or font path, preconnect does more (TCP and TLS as well as DNS). It also costs more if you overuse it. Use preconnect sparingly and dns-prefetch for lower-priority hosts, then re-test the same URL.

What is the difference between prefetch and preload?
preload targets a resource for the current page load. prefetch targets a likely future navigation at lower priority. Do not prefetch the current LCP image when you meant to preload it. If the goal is next-page speed, say so in the task title.

Can resource hints fix a poor INP score?
Rarely by themselves. INP is about interaction delay and main-thread work. Hints mainly change early network timing for loads and navigations, so keep INP work on scripts and long tasks.

Do WordPress optimisation plugins handle this safely?
Sometimes. Audit the rendered head on key templates. Sitewide “add all hints” modes often create unused preloads and excess preconnects. Prefer explicit lists for LCP and font origins, reviewed per theme update.

CTA

Pick the hint from the table before you paste tags into <head>. Preload only late-discovered critical assets for the current page, keep preconnect lists short, leave prefetch for likely next navigations, and verify with dated lab runs on the URLs clients actually care about. For portfolio monitoring across many domains after those fixes, start with Apogee Watcher or run a public check from the homepage tools.

References

Assist the browser with resource hints (web.dev)
Preload critical assets to improve loading speed (web.dev)
Establish network connections early to improve perceived page speed (web.dev)
Optimize Largest Contentful Paint (web.dev)
LCP request discovery (Chrome for Developers)
Preconnect to required origins (Chrome for Developers)
No-Vary-Search header (MDN)
What Are Core Web Vitals? A Practical Guide for 2026 (Apogee Watcher)
LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It (Apogee Watcher)
Image Optimisation Strategies for Better LCP Scores (Apogee Watcher)
Lazy Loading for LCP and CLS: When to Use loading="lazy" (and When Not To) (Apogee Watcher)
Font Subsetting for Web Performance: 4 Tools to Reduce Font File Size and Improve LCP (Apogee Watcher)
WordPress Speculation and Prerender Plugins vs Core Web Vitals (Apogee Watcher)

Originally published on Apogee Watcher.

Lazy Loading for LCP and CLS: When to Use loading="lazy" (and When Not To)

Sun, 11 Oct 2026 07:34:31 +0000

Lazy loading images and a fast Largest Contentful Paint (LCP) pull in opposite directions when the same rule is applied to every <img>. Deferring offscreen bytes is usually right, but deferring the hero that PageSpeed Insights later names as LCP is usually wrong. The loading="lazy" attribute is only a browser hint for that trade-off. It is not a global “make the site faster” switch that themes and optimisation plugins can sprinkle without review.

What follows is a decision guide for agencies and product teams: when lazy loading images helps, when it hurts LCP or Cumulative Layout Shift (CLS), and how to prove the change with scheduled lab checks rather than one green Lighthouse run. For the wider image pipeline (formats, sizing, CDN), keep Image Optimisation Strategies for Better LCP Scores open beside this piece. When text paint competes with the hero, Font Subsetting for Web Performance: 4 Tools to Reduce Font File Size and Improve LCP still belongs in the same sprint.

What the `loading="lazy"` attribute does

The HTML loading attribute on <img> and <iframe> tells supporting browsers whether to fetch the resource immediately or wait until it is near the viewport. Per MDN’s lazy loading guide and web.dev’s browser-level image lazy loading article, loading="lazy" is the deferred path and loading="eager" (or omitting the attribute for images that default to eager) is the immediate path. Native lazy loading replaced most custom Intersection Observer snippets for ordinary image galleries, yet the browser still decides how far ahead of the viewport it starts the fetch.

That nuance matters for agency audits. “We enabled lazy loading” can mean native attributes, a WordPress filter that injects loading="lazy" on every attachment, a Shopify theme setting, or a JavaScript library that swaps data-src after scroll. All of those can defer the LCP candidate if the first screen image is included, so the mechanism belongs in the ticket before anyone blames hosting.

Native lazy loading is progressive enhancement: older browsers ignore unknown attributes and load images normally. That is fine for bandwidth on modern Chrome and Safari, yet it does not excuse shipping a hero with loading="lazy" on the browsers that dominate your CrUX population. Progressive enhancement is not permission to defer the element field users actually paint as LCP.

Why lazy-loading the LCP image hurts Largest Contentful Paint

LCP marks when the largest above-the-fold content element becomes visible. On marketing and commerce pages that element is often a hero image, product photo, or poster frame. If that resource is marked loading="lazy", the browser may delay the request until layout work suggests the image is “near” the viewport, even though it already is. The result shows up as higher resource load delay in Lighthouse and PageSpeed Insights, and as a worse lab LCP, which Google’s common LCP misconceptions post still flags as a frequent own-goal.

Search threads for “lazy load LCP” are full of Elementor, WordPress, and theme support tickets for the same pattern: a plugin or theme applied lazy loading sitewide, the logo or banner became LCP, and scores collapsed until someone excluded the first image. Weston Ruter’s comparison demos of lazy-loaded versus eager LCP images make the timing difference visible without arguing theory. Disabling lazy load on the LCP image is a first triage step in those threads, not a last resort after a CDN rewrite.

The fix is usually boring. Once PageSpeed Insights or Chrome Performance names the LCP element, remove loading="lazy" from that image (and any identical mobile/desktop sources in <picture>). fetchpriority="high" fits when you know the LCP URL early; a preload fits only when the markup path cannot put that URL in the initial HTML. Preloading and lazy-loading the same URL fights itself.

When lazy loading images is the right default

Lazy loading images is the right default for content that starts offscreen: article body photos after the fold, related-product grids, footer badges, long category galleries, and comment avatars. Those bytes should not compete with the critical path on first paint. On a twenty-image blog post, native lazy loading can cut early bandwidth sharply on mobile without changing the story the user sees first.

On retainer sites we treat eager versus lazy as a short policy, not a plugin toggle. Eager (no lazy, or explicit eager) covers the LCP candidate, a logo when it is LCP, the primary above-the-fold product image, and any image inside the first viewport on common breakpoints. Lazy covers everything that requires scroll or a tab change before it matters.

That policy needs a mobile-width check as well as desktop. An image that looks “below the fold” on a large monitor can sit in the first screen on a phone, and that phone traffic often dominates CrUX. Audits that only run at 1440px tend to lazy-load the wrong assets for the field population.

Above-the-fold images, `fetchpriority`, and eager loading

“Above the fold” is not a CSS property; it is a judgement about what appears in the initial viewport for your primary breakpoints. When that judgement is wrong, lazy loading above the fold recreates the LCP delay problem even if the CMS labelled the block “content” rather than “hero.” Breakpoints disagree more often than teams expect, especially between a design mockup and a phone-width lab run.

For the confirmed LCP image, loading="lazy" comes off (or loading="eager" overrides a stack that injects lazy by default), accurate width and height or aspect-ratio CSS reserve layout space, and fetchpriority="high" fits when the image is the clear LCP candidate and other resources are not already marked high. An appropriately sized file matters so eager does not mean downloading a 4000px PNG; the image optimisation post linked above covers formats and srcset. Theme and page-builder defaults often invert that list: every attachment gets lazy, none get fetch priority, and the hero is still a huge JPEG. Attribute policy belongs ahead of another CDN plan. A smaller eager hero usually beats a huge lazy hero on LCP, even when the waterfall looks “optimised” in a plugin dashboard.

Iframes, video, and other lazy media caveats

The loading attribute also applies to <iframe>, so below-the-fold embeds (maps, secondary YouTube players, chat widgets) are usually sensible lazy candidates. A first-screen video iframe that is also your LCP or a large layout box can delay paint and still risk CLS if dimensions are missing. A facade (poster image + click-to-load) fits heavy third-party players when the embed is not required for the first view. That pattern pairs with Cross-Origin YouTube Embeds and CLS.

Background images in CSS cannot use loading="lazy". If the LCP element is a CSS background, attribute fixes will not help; you need a real <img> or <picture> in the document, or a different LCP strategy. JavaScript lazy libraries that leave src empty until hydration can also create late discovery worse than native lazy, especially when the library bundle itself is deferred. Video posters and <video> elements have their own preload behaviour, so “lazy images are on” does not automatically cover posters and iframes. The LCP node type in the trace matters, because a poster frame can win LCP while the checklist only mentions <img loading>.

Lazy loading and CLS: reserve space first

Lazy loading does not cause CLS by itself; missing dimensions do. When a lazy image finally loads into a box with no reserved height, the page shifts and CLS rises. That failure mode is easy to miss in a lab run that never scrolls to the image, then appears in field data when users do scroll.

Lazy loading images still needs intrinsic size hints: width and height attributes, width/height in CMS media metadata, or CSS aspect-ratio on the container. Responsive srcset still needs a consistent aspect ratio across candidates. If a theme wraps images in a collapsing container until load, the container belongs in the ticket before anyone argues about Core Web Vitals thresholds. Hero images that are eager still need reserved space: eager versus lazy is an LCP timing decision, while dimensioning is a CLS decision, so agencies should treat them as two checklist rows rather than one vague “images” ticket.

Lab vs field when lazy loading hides LCP regressions

A single PageSpeed Insights run on the homepage can look fine after you “enable lazy loading,” especially if the lab viewport and your CMS preview disagree about what is on screen. Field LCP in CrUX or the PageSpeed Insights field section can still worsen when real devices, slower networks, and cookie banners change which element wins LCP. Mobile users may also hit a lazy hero that desktop lab never marked as LCP, so one desktop screenshot is not proof.

Scheduled lab checks on money URLs (home, category, product, key landing pages) before and after attribute changes, on both mobile and desktop strategies, keep the claim honest. LCP element identity matters more than the score alone. If the LCP node switches from a heading to an image after a deploy, that image’s lazy attribute is the next place to look. For portfolio monitoring across many client sites, Apogee Watcher keeps those lab histories in one place so an attribute change does not vanish into a one-off PDF.

Lab green and field amber can both be honest, because lab may scroll less, block third parties differently, or use a colder cache. When lazy loading is in the diff, read resource load delay for the LCP URL in the lab diagnostics before you close the ticket. If load delay stays high after “optimisation,” suspect the attribute before you rewrite the media query set.

Agency checklist before you ship “lazy everything”

Before a theme update or “speed plugin” goes to production, a short pass usually pays for itself. The current LCP element and time on mobile and desktop for each money URL set the baseline, then templates and plugin settings get a search for global loading="lazy" injection. The LCP candidate (and logo if needed) stays off the lazy list, and width/height or aspect-ratio get confirmed on lazy and eager images alike. Lab checks run again until the LCP element and load delay move the right way; field LCP is watched for the 28-day window after release rather than declared fixed on day one; and the exclusion list is written down so the next plugin install does not re-lazy the hero. That pass is cheaper than a month of “we improved PageSpeed” conversations while CrUX stays amber, and it gives the next developer a written exclusion list instead of tribal knowledge about “the hero must stay eager.” The list belongs in the repository or the retainer runbook so plugin reinstalls do not undo it quietly.

FAQ

Should every image use loading="lazy"?

No: lazy loading images is for offscreen content, while the LCP image and other critical above-the-fold images should load eagerly. Sitewide lazy defaults from CMS plugins are a common source of LCP regressions on retainers.

Does loading="lazy" on the LCP image always break field data?

Not always, because browsers and viewports differ, but it is a high-risk pattern that Lighthouse and many case studies associate with longer LCP. The LCP candidate usually stays eager unless you have measured no harm on mobile and desktop for that template.

Is native lazy loading better than a JavaScript lazy library?

For ordinary images, native lazy loading is usually enough and avoids waiting on a script. Libraries still appear for older patterns or fancy placeholders; they must not leave the LCP src undiscovered until late JavaScript runs.

Can lazy loading improve CLS?

Indirectly, only if it reduces contention and you already reserve space. Lazy loading without dimensions often worsens CLS when images pop in during scroll, so sizing belongs ahead of another lazy-loading toggle.

What about logos?

If the logo is the LCP element (common on simple brochure sites), it should stay eager. If a large hero is LCP and the logo is small, the logo can follow normal theme defaults, but still reserve space to avoid header shift.

Ship eager heroes, lazy galleries

Lazy loading images remains one of the strongest bandwidth defaults on long pages, as long as the LCP image stays eager, dimensions protect CLS, and iframes or video facades are handled on purpose. The loading="lazy" attribute is a scalpel for offscreen media, not a blanket for every attachment ID in the CMS. The exclusion list travels with the theme update so the next speed plugin cannot quietly reverse it.

For format and sizing work around the same LCP element, continue with Image Optimisation Strategies for Better LCP Scores. When font files compete with the hero, use Font Subsetting for Web Performance: 4 Tools to Reduce Font File Size and Improve LCP. To keep attribute changes honest across a client roster, start a free trial or run a check on a money URL before and after you remove lazy from the hero.

References

Browser-level image lazy loading for the web (web.dev)
Lazy loading (MDN)
Common misconceptions about how to optimize LCP (web.dev)
HTML attribute: loading (MDN)
Image Optimisation Strategies for Better LCP Scores (Apogee Watcher)
Font Subsetting for Web Performance: 4 Tools to Reduce Font File Size and Improve LCP (Apogee Watcher)
Lighthouse: Don't lazy load Largest Contentful Paint image (GTmetrix / Lighthouse audit explanation)
Cross-Origin YouTube Embeds and CLS: What Publishers Can Actually Fix (Apogee Watcher)

Originally published on Apogee Watcher.

Brotli and Gzip Compression: Shrink Text Assets Without Breaking PageSpeed Scores

Sun, 04 Oct 2026 06:55:41 +0000

The CDN dashboard shows compression enabled. A host panel lists Brotli as on. A lab run on the priority URL still flags Enable text compression, or the Performance score barely moves while Time to First Byte gets worse after someone raised the Brotli level on dynamic HTML. In our experience the gap is rarely “nobody turned compression on.” It is a mismatch between which responses are compressed, which layer applies Content-Encoding, and what Lighthouse actually measures on that URL.

What follows is a delivery guide for teams who already walk DNS, TLS, HTTP, and cache rules in Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules. That piece explains where edge and origin sit on the path to first byte. Here the focus is Brotli compression and gzip for text assets: how teams enable Brotli with a safe fallback, and how to keep PageSpeed Insights and Lighthouse honest after the change. Pair it with Cache-Control Headers for Web Performance. Caching decides whether bytes are reused; compression decides how small those bytes are on the first download.

What Brotli and gzip change on the response path

HTTP compression shrinks the body of a response before it travels over the network. The client advertises what it accepts in Accept-Encoding (commonly br, gzip, and deflate). The server or CDN chooses an encoding and returns Content-Encoding: br or Content-Encoding: gzip when it compresses. The browser decompresses before parsing HTML, CSS, or JavaScript. Transfer size drops; the uncompressed size the parser needs does not.

That distinction matters for Core Web Vitals work. Smaller transfer size can shorten download time for render-blocking CSS and for JavaScript that sits on the critical path. It does not rewrite a slow origin query, a third-party script, or an oversized Largest Contentful Paint image. Compression is a bandwidth and decode trade-off on text responses. It sits beside Time to First Byte and LCP resource priority; it is not a substitute for the fixes in A Quick Way to Fix LCP: Four Changes That Cut Time to Paint.

Lighthouse and PageSpeed Insights surface missing compression under audits such as Enable text compression (uses-text-compression). Google’s older Enable Compression guidance still frames the same idea for agencies reading mixed reports: text resources that benefit from gzip or Brotli should arrive compressed when the client supports it. Gzip compression on the web is still the safety net when Brotli is unavailable on a hop; both belong in the same verification pass.

Brotli vs gzip for web delivery (and when gzip still wins)

Brotli versus gzip is not a purity contest. Brotli usually produces smaller text payloads than gzip at comparable quality settings, especially for HTML, CSS, and JavaScript. Gzip is older, universally supported for compressed HTTP responses, and cheap to encode at moderate levels. Most modern browsers prefer Brotli when the server offers br and the negotiation succeeds.

Dimension	Brotli (`br`)	Gzip
Typical text ratio	Often smaller than gzip at similar effort	Good baseline; larger than Brotli for many CSS/JS bundles
Encode CPU	Higher at high quality levels on dynamic content	Lower at common levels (for example gzip 4–6)
Browser support for HTTP	Broad for current Chrome, Firefox, Safari, Edge	Universal for compression-capable clients
Best use	Precompressed static assets; edge or origin for text	Fallback when `br` is unavailable; always-on safety net
Risk if mis-set	High dynamic Brotli quality can inflate TTFB	Double-gzip or gzip on already-compressed binary wastes CPU

For static fingerprinted files, precompressing at build time (.br and .gz siblings) and serving the matching encoding avoids burning origin CPU on every request. For HTML that changes per request, compression at the CDN or reverse proxy with a moderate quality setting usually works better, with gzip kept as the fallback for clients or intermediaries that do not take Brotli. That split (offline high effort for static, moderate online effort for HTML) is what keeps transfer size down without quietly raising Time to First Byte.

Zstandard (zstd) appears in some CDN and origin stacks as another encoding. It is useful optional coverage where the edge already supports it. Brotli and gzip remain the baseline pair until client and intermediary support for your traffic mix is proven. Delivery checklists we use with client sites still verify gzip, Brotli, and zstd where the stack claims them.

Which responses to compress (and which to leave alone)

The responses that benefit are those whose payload is mostly text and is not already in a compressed container. A practical allow-list looks like this, and it is what we expect to match Lighthouse’s text-compression audit when the page is otherwise healthy:

text/html
text/css
text/javascript / application/javascript / application/x-javascript
application/json / application/ld+json
image/svg+xml
text/xml / application/xml (where XML is not already packaged)
Often font/woff is already compressed; woff2 is compressed by design, so wrapping it again rarely helps
application/wasm may benefit in some stacks once size and CPU are checked on a representative URL

Brotli or gzip as a blanket over JPEG, PNG, WebP, AVIF, MP4, or other already-compressed media rarely shrinks transfer size and can add latency and CPU. Agencies still hit this when a “compress everything” host preset includes image/* or when a plugin gzip-filters the whole response stack. The win is smaller text on the wire, not a second envelope around media that is already compressed.

Partial compression is another common miss. HTML compressed at the edge while CSS and JavaScript miss Content-Encoding still fails Lighthouse’s text-compression audit for those URLs. The audit looks at individual text resources above a size threshold, not at a single dashboard toggle labelled “Brotli.”

How to enable Brotli with a gzip fallback at origin and CDN

Enabling Brotli only helps when negotiation survives to the browser. Clients send Accept-Encoding with br and gzip. Stacks that prefer Brotli when available, and fall back to gzip without serving identity encoding for large text bodies, clear audits more reliably than a lone dashboard switch.

Origin and reverse proxy patterns

Common patterns we see work in delivery:

NGINX with Brotli module. Configuration that turns brotli on; for the MIME types above, sets a moderate brotli_comp_level for dynamic responses, and keeps gzip on; with overlapping types so clients without br still compress. Google’s ngx_brotli and NGINX Brotli docs cover module loading; production still needs a check that the module is loaded, not only present in a staging snippet.
Apache. mod_brotli / mod_deflate with explicit AddOutputFilterByType (or equivalent) for the text MIME list works when filter chains do not compress twice.
Application middleware. Express compression, Laravel or Rails middleware, and similar helpers often default to gzip. Brotli belongs here only when the library and deployment target support it; otherwise compression at the proxy in front of the app is the cleaner path.
Precompressed static assets. Emitting .br / .gz at build, mapping Accept-Encoding to those files, and setting Vary: Accept-Encoding keeps shared caches from mixing encodings.

CDN and edge

Many CDNs offer automatic Brotli and gzip for cacheable text. Three facts in the live response matter more than the marketing checkbox, because PageSpeed Insights tests the hostname you give it, not the checkbox label in a vendor UI:

The origin response for HTML, CSS, and JavaScript either arrives compressed or is compressible at the edge without being marked uncacheable for the wrong reason.
The edge returns Content-Encoding: br or gzip on a cold and warm fetch from a client that sends both encodings.
Vary: Accept-Encoding (or CDN-equivalent vary behaviour) is present so caches store separate variants.

Cloudflare and similar platforms document serving Brotli from origin and compression rules. Reading the vendor guide is not enough if an origin Cache-Control: private or a page rule disables optimisation on the hostname you test in PageSpeed Insights. Compression and caching interact; the Cache-Control post covers HTML versus fingerprinted assets in more depth.

Fix Lighthouse “Enable text compression” without breaking PageSpeed scores

The Lighthouse audit Enable text compression fails when text resources are large enough to benefit from compression and arrive without a recognised Content-Encoding. Clearing the audit means those URLs gain compression on the lab client’s path. It does not mean raising Brotli quality to the maximum on every HTML response.

A workflow that keeps scores honest usually looks like this:

Pull the audit URLs from the Lighthouse JSON or PageSpeed Insights diagnostics list (HTML document, CSS, and JavaScript files named in the audit).
Request each URL with Accept-Encoding: br, gzip and inspect Content-Encoding, Content-Type, and transfer size in DevTools or curl -H "Accept-Encoding: br, gzip" -I.
Turn compression on for the MIME types that failed, while leaving images and already-compressed fonts alone.
Re-run the same lab profile (same device and throttling) after deploy, watching Performance score and Time to First Byte / LCP, not only the green tick on the audit.
If Time to First Byte rises while transfer size falls, lower dynamic compression quality or move compression to precompressed static files and edge caching so origin CPU is not on the critical path for every HTML hit.

PageSpeed scores break when teams chase the audit alone: double compression, compressing PDFs or images, or saturating the origin so first byte suffers. The audit is a checklist item. The score reflects the full lab experience. Both belong in the same verification loop.

Compression mistakes that hurt TTFB, LCP, or lab scores

These failure modes show up repeatedly on agency portfolios:

Double compression. Origin gzip plus CDN Brotli on an already-encoded body, or a plugin that gzip-filters output already compressed by the proxy. Symptoms include unexpected Content-Encoding chains, larger transfer sizes, or decode errors. One compression layer per response class, with a clear owner (origin or edge), avoids that class of failure.

Wrong MIME allow-list. Compressing image/jpeg or skipping text/css because a preset used outdated type strings. Allow-lists that match what Lighthouse actually requests on the page clear the audit faster than generic host presets.

High Brotli quality on uncached HTML. Quality 11 on every HTML response can cost more CPU milliseconds than the download saves on a fast connection. Moderate levels suit dynamic HTML; high effort fits offline precompression of static assets.

Missing Vary: Accept-Encoding. Shared caches serve a gzip body to a Brotli-capable client (or the reverse), which produces confusing lab versus browser results and intermittent audit failures.

Assuming the CDN checkbox covers third-party hosts. Lighthouse flags text files on your origin and on hosts you control in the waterfall. A script or stylesheet on a tag manager domain you do not configure will keep failing until that host compresses or the file leaves the critical path.

Expecting compression alone to fix LCP. If the LCP element is a hero image, Brotli on HTML and CSS helps the document and styles, but the image path still dominates. Compression works alongside the LCP levers in the quick-fix guide, not instead of them.

Verify Content-Encoding on live URLs after every deploy

Compression belongs in the same habit as Cache-Control: prove it on the live hostname after release, then watch it on a schedule so a platform default does not silently revert.

A useful checklist per priority URL:

The HTML document and two to three render-blocking CSS/JavaScript URLs from the lab waterfall.
Content-Encoding of br or gzip from a client that sends both in Accept-Encoding.
Transfer size materially smaller than content size for those text files.
LCP images left alone by the compression layer (no accidental re-encoding).
A PageSpeed Insights or Lighthouse run before and after so the Enable text compression audit and the Performance score share the same baseline.
A re-check after CDN rule changes, host panel toggles, and major theme or plugin releases.

Apogee Watcher fits as the scheduled lab layer across client sites. After Brotli and gzip are configured correctly, scheduled re-tests on priority URLs catch a host migration or “optimisation” plugin that drops Content-Encoding without a ticket. Monitoring layers onto the stack you already run; a single red audit is not a reason to rip out an existing CDN.

For a starting point on one URL before you standardise a portfolio, apogeewatcher.com/check is enough. For ongoing multi-site schedules and budgets after compression and cache work, start a trial. Either path keeps the same question in view: does Content-Encoding still match what you configured last week?

FAQ

What is Brotli compression on the web?
Brotli is a compression format (content coding br) commonly used for HTTP responses. For web performance it mainly shrinks text assets such as HTML, CSS, and JavaScript when the client advertises support in Accept-Encoding. MDN’s glossary entry is a short reference; production work still needs header checks on live URLs.

Should I enable Brotli or gzip?
Both. Brotli when negotiation succeeds, gzip when the client or path cannot use br. Disabling gzip solely because Brotli exists leaves older clients and some intermediary hops on identity encoding for large text bodies.

Why does Lighthouse still say Enable text compression?
A dashboard toggle is not enough. Individual text resources above the audit threshold must arrive with Content-Encoding: br or gzip on the lab request path. Headers and MIME type on each failing URL usually explain the miss faster than another host-panel screenshot.

Does Brotli improve Core Web Vitals?
It can reduce download time for text on the critical path, which may help LCP and related lab metrics when those files were the bottleneck. It will not fix a slow origin alone or an uncompressed LCP image. Before-and-after runs on the same lab profile show whether the change mattered.

Can compression make PageSpeed scores worse?
Yes. Excessive dynamic compression CPU, double compression, or compressing the wrong asset types can raise Time to First Byte or add work without shrinking useful bytes. Lab tests after every change, with precompression preferred for static files, catch those regressions early.

Do I need zstd as well?
Only when your CDN and clients benefit from it in production. Brotli and gzip remain the baseline pair for agency portfolios until zstd support is verified for your traffic.

Compression belongs in the same delivery contract as caching and CDN rules. Naming the layer that owns encoding, limiting it to text that benefits, and verifying Content-Encoding on live URLs after every deploy keeps the setup honest. When Brotli and gzip are configured that way, Lighthouse’s Enable text compression audit tends to clear without trading away Time to First Byte or inventing a false PageSpeed win.

Ready to keep compression and Core Web Vitals honest across a client portfolio? Start a free trial of Apogee Watcher or run a single URL check.

References

Enable text compression (Lighthouse) (Chrome for Developers)
Enable Compression (PageSpeed Insights / Google)
Brotli compression (MDN Glossary) (MDN)
gzip compression (MDN Glossary) (MDN)
NGINX Brotli module (NGINX Docs)
google/ngx_brotli (GitHub)
google/brotli (GitHub)
Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules
Cache-Control Headers for Web Performance: CDN and Browser Caching That Sticks
A Quick Way to Fix LCP: Four Changes That Cut Time to Paint

Originally published on Apogee Watcher.

A Quick Way to Fix LCP: Four Changes That Cut Time to Paint

Thu, 09 Jul 2026 12:39:00 +0000

Largest Contentful Paint (LCP) fails when the browser is still waiting on the server, fighting for bandwidth, or blocked on JavaScript before it can paint the biggest thing in the viewport. You do not need a six-week performance programme to move the needle. In our delivery work, four changes cover most urgent LCP regressions: fix Time to First Byte (TTFB), remove competing work from the path to the LCP element, prioritise that element with fetchpriority="high", and schedule low-value JavaScript after the load event. What follows is a practical order of operations, with enough detail to implement without re-reading a full Core Web Vitals textbook.

For background on thresholds and the four LCP sub-parts, see LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It. For image-specific tuning when the LCP element is a hero photo, see Image Optimisation Strategies for Better LCP Scores. Both posts go deeper on sub-parts and formats; here we stay focused on the fastest fixes.

What is the path to LCP?

LCP is not one timer. It is a chain from first request to final paint of the largest visible element. Google’s documentation breaks the chain into TTFB, resource load delay, resource load duration, and element render delay. The path to LCP is everything the browser does before that element paints: HTML download, discovery of the LCP resource, competing requests, font and script work on the main thread, and layout.

When teams say “LCP is slow but the hero image is only 200 KB,” the bottleneck is usually earlier in the chain. TTFB adds blank time. Icons, analytics, web fonts, and below-the-fold images steal connection slots. JavaScript runs before the browser can commit the LCP paint even after the asset has arrived. The four fixes below map directly to those failure modes.

Step 1: Improve TTFB (Time to First Byte)

TTFB is pure page-blank time. Nothing in the viewport can render until the first byte of HTML arrives. If TTFB is 800 ms on mobile lab tests, every downstream optimisation starts late.

Treat TTFB as a caching and origin problem first:

Cache database queries on CMS and ecommerce routes that build the HTML shell. Object caches (Redis, Memcached) and query result caching cut repeated work on popular templates.
Cache full pages or page fragments at the edge. A CDN or reverse proxy (Cloudflare, Fastly, Varnish, nginx proxy_cache) should serve anonymous HTML for marketing and category pages where content is not user-specific.
Cache generated code paths where applicable. Opcode caches (OPcache on PHP), template compilation caches, and warmed application caches reduce CPU time per request.

Also check the basics: slow upstream APIs in the critical path, cold serverless instances, and TLS or DNS misconfiguration. TTFB improvements often drop LCP by hundreds of milliseconds without touching front-end assets at all, which makes this step worth doing even when the design team is already compressing heroes.

Run PageSpeed Insights and note TTFB in the diagnostics. If it is high, fix origin and caching before optimising images. Our Core Web Vitals guide lists the “good” LCP band at 2.5 seconds or less in the field; shaving TTFB is the fastest way to buy headroom when you are close to the line.

Step 2: Remove anything in the path to LCP that matters less than the LCP element

Once HTML starts arriving, the browser schedules dozens of requests. Anything that competes with the LCP resource for bandwidth or main-thread time extends resource load delay and render delay. The rule is simple: if it is not required to paint the LCP element, it should not run or download ahead of it.

Icons and decorative assets

Favicons, sprite sheets, and small UI icons often sit early in the document or load from high-priority stylesheets. They rarely affect LCP directly, but they consume connections and parser attention. Inline critical icon SVGs only when needed above the fold; otherwise load icon fonts and sprite bundles after the LCP resource is underway or from low-priority async paths.

Third-party scripts

Analytics, chat widgets, A/B testing snippets, and personalisation tags are common LCP killers. They execute in the head or early body and block parsing. Audit with the Network panel: sort by start time and see what fires before the LCP image or text block.

Practical moves:

Load tag managers and non-essential vendors after the LCP resource is discoverable (see Step 4 for load-based scheduling).
Self-host or proxy only what you truly need on first paint.
For deeper triage patterns, see Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders.

Below-the-fold images

Lazy-loading is correct for content lower on the page, but never lazy-load the LCP candidate. Conversely, do not let below-the-fold tags without loading="lazy" sit in the head of the queue with fetchpriority defaults that compete with the hero. Ensure decorative and content images that are not LCP use lazy loading and lower priority so the hero wins the network race.

Fonts that are not needed for the LCP element

Web fonts are often requested from CSS before the LCP image is even parsed. If the LCP element is a photograph, decorative display fonts do not need to block the chain. If the LCP element is a headline, only the weights used in that headline need early loading.

The goal is not “delay until interaction” tricks that hide text until a user taps. The goal is enqueue order: make sure font files for secondary UI copy enter the pipeline after the LCP resource is requested and ideally after it has started downloading. Techniques include splitting @font-face rules into non-critical stylesheets loaded later, subsetting fonts (font subsetting guide), and using system font stacks for non-LCP text on first paint.

Step 3: Prioritise the LCP element with fetchpriority="high"

Browsers schedule requests with heuristics. Hero images discovered late in HTML or hidden behind CSS may get default priority while less important assets jump ahead. The fetchpriority attribute lets you mark what matters.

For an image LCP element:

Pair with in when the LCP image is known at build time and appears late in the markup. Preload is not a substitute for fixing TTFB or removing competing scripts, but it removes discovery delay when the hero sits below inline styles or markup generated by JavaScript.

Do not set fetchpriority="high" on everything. If every image is high priority, none are. Reserve it for the single LCP candidate PSI reports in Lighthouse diagnostics.

For text or video LCP elements, the same principle applies: ensure the resource that feeds the largest paint is discoverable early and not deprioritised by lazy attributes or late injection.

Step 4: Schedule less important JavaScript after the load event

Even when the LCP asset has downloaded, element render delay can balloon if the main thread is busy executing JavaScript. Parsing, compilation, and long tasks defer layout and paint, which is why deferral belongs in the same checklist as caching and fetch priority.

defer and async help for scripts that must run before interaction, but many apps bundle analytics, carousels, and enhancement code that can wait until the page has fully loaded. The load event fires when the document and its subresources (images, stylesheets) have finished loading. Scheduling non-critical work there keeps the main thread freer while LCP is still forming.

Example pattern:



  window.addEventListener('load', function () {
requestIdleCallback(function () {
  initNonCriticalWidgets();
  loadDeferredAnalytics();
}, { timeout: 2000 });

});

Use requestIdleCallback where supported so you do not immediately replace one long task with another. Framework-specific code splitting (dynamic import() on load or on first interaction) achieves the same outcome: the LCP element paints before megabytes of client-side routing and chart libraries execute.

This is distinct from deferring fonts until interaction, which can harm readability. Here we defer JavaScript functions that do not affect first paint: heatmaps, chat bubbles, personalisation hooks, and secondary carousels below the hero.

A one-hour LCP fix workflow

Use this sequence when you have a red LCP on a priority URL and limited time:

Identify the LCP element in PageSpeed Insights or Lighthouse (Diagnostics → LCP element).
Record TTFB on mobile lab. If it is above ~600 ms, open caching and origin tickets first.
Waterfall audit: list every request and script that starts before the LCP resource. Remove or postpone icons, third parties, lazy-competing images, and non-LCP fonts.
Add fetchpriority="high" (and preload if needed) on the LCP node only.
Move non-critical JS to load + idle callbacks; retest.
Set an LCP budget in your monitoring tool so the fix survives the next deploy. See Performance Budget Thresholds Template.

Agencies managing many client homepages and landers should run mobile and desktop lab tests on the same URL after each change. One-off PSI tabs miss regressions when a plugin reintroduces a head script. PageSpeed Insights vs automated monitoring explains why scheduled tests and alerts matter once the quick fix ships.

What these four steps do not replace

These changes target the delivery path to LCP. They do not replace image compression, responsive srcset, CDN tuning, or server-side rendering when the LCP element itself is too large or injected only after client-side hydration. When the LCP element is an image, combine this checklist with the image optimisation guide. When third parties dominate the waterfall, the third-party scripts post goes deeper on vendor policy.

LCP also differs between mobile and desktop strategies. A fix on one may not carry to the other if different heroes or ad slots apply. Monitor both; see Mobile vs Desktop Core Web Vitals.

FAQ

Should I fix TTFB or the LCP image first?

Fix TTFB first when it is high. Blank time before HTML cannot be recovered by compressing a hero image. If TTFB is already healthy, focus on the path to LCP and the LCP resource itself.

Does fetchpriority replace preload?

No. fetchpriority="high" adjusts priority once the browser discovers the resource. Preload starts discovery earlier when the URL is known at build time. Use both on image heroes that appear late in the document.

Is lazy-loading the LCP element ever correct?

No. Never lazy-load the element PageSpeed Insights reports as LCP. Lazy-load below-the-fold images only.

Why defer JavaScript to load instead of using defer on every script?

The defer attribute preserves execution order before DOMContentLoaded for scripts that still run during the critical path. Analytics, widgets, and enhancement bundles that do not affect first paint can wait until load, which reduces main-thread contention while LCP is still forming.

How do I know the fix worked?

Re-run PageSpeed Insights on the same URL and strategy (mobile vs desktop). Compare LCP time and the filmstrip. For production confidence, schedule lab tests with budgets in Apogee Watcher so the next theme or tag-manager change triggers an alert if LCP drifts back above your threshold.

Can Apogee Watcher fix LCP automatically?

No. Watcher schedules PageSpeed lab tests, stores LCP and other vitals over time, and emails you when budgets breach. You still implement caching, prioritisation, and script deferral in the codebase; Watcher tells you when those fixes slip on priority URLs across client sites.

TTFB, a clear path to the LCP element, fetchpriority="high", and JavaScript deferred until after load are the four changes we reach for first when LCP is red and the release window is small. Ship them in that order, re-test on mobile lab, then lock the win with budgets and scheduled monitoring so the metric stays green after the next deploy. Start a free Apogee Watcher account to track LCP on priority URLs with mobile and desktop schedules and vitals budgets, or run a free domain PageSpeed check before you change caching or script order.

Font Subsetting for Web Performance: 4 Tools to Reduce Font File Size and Improve LCP

Tue, 02 Jun 2026 10:47:00 +0000

In web development, every millisecond on the critical path matters. Typography is part of your visual identity, yet a single self-hosted family can add hundreds of kilobytes before the browser paints the hero line clients actually see. That cost often shows up as slower First Contentful Paint (FCP) and a worse Largest Contentful Paint (LCP) when the LCP element is a headline set in a custom face.

Font subsetting is the practical fix: ship only the characters (glyphs) each page or component needs instead of entire typefaces built for every language and symbol you will never render.

What font subsetting is

A typical desktop font file contains thousands of glyphs: Latin extended, Cyrillic, ligatures, numerals, punctuation, and symbols you may never use on a marketing site. When you @font-face that file or pull it from a CDN, the browser still has to download and parse the whole package unless you split it.

Subsetting creates a smaller font file that includes a defined subset of Unicode code points. Examples:

A display font used only on one H1 might need fewer than 40 characters.
A Latin-only blog body font does not need CJK tables on every article.
UI labels in English can omit unused weights and scripts.

The browser downloads less data, spends less time decoding, and can apply the face sooner. You keep the look; you drop the dead weight.

When font subsetting improves web font performance and LCP

Subsetting pays off fastest in these cases:

Situation	Why subsetting helps
Display or hero typography	Few unique characters, high visual impact, often on the LCP text node
Single-language sites	Remove unused scripts and diacritic ranges you do not publish
Icon or logo fonts misused as full fonts	Replace with SVG where possible; subset if you must keep a font icon set
Multiple weights loaded globally	Subset per weight, or load weights only on routes that need them

It is lower priority when you already use a system font stack for body copy and only load one small variable font with modern compression. Still measure: “small” on disk is not always small on a slow mobile connection.

Pair subsetting with loading discipline: font-display: swap or optional, preload only the file that blocks the hero, and avoid loading six weights site-wide because the brand guide lists them. Our image optimisation strategies for better LCP guide covers the image side of the same paint problem; fonts are the other half of many hero templates.

Font subsetting example: hero display copy without the full font file

Imagine a campaign landing page with one H1 in a distinctive display face: “Summer sale ends Sunday”. The full commercial font might be 180 KB of WOFF2 per weight. The string uses letters, a space, and basic punctuation: perhaps 28 glyphs.

Subsetting to those glyphs (plus a few extras you reserve for CMS edits, such as 0123456789 and -%) might produce a file under 15 KB. Same aesthetics on the title; far less work for the network and font loader on first visit.

Always keep a slightly wider subset than the literal string if editors can change copy without redeploying. A common pattern is “characters used on site” plus a safety buffer of numerals and common punctuation, or a per-locale subset file.

Four tools for font subsetting

You do not need to hand-edit binary tables for most projects. These four tools cover the usual workflows.

Google Fonts

Google Fonts hosts families with many axes and scripts. When you embed through the Google Fonts CSS API, you can limit what Google serves:

Use the text= parameter to request only the characters in a string (useful for fixed hero copy).
Choose only the weights and styles you need in the embed code generator.
Prefer display=swap (or optional where appropriate) so text stays visible while the file loads.

Self-hosting a Google Font download is also valid: download the family, subset locally, and serve WOFF2 from your own CDN for stricter cache control.

Font Squirrel Webfont Generator

Font Squirrel’s Webfont Generator is the familiar upload-and-convert workflow. Upload your source (check your licence allows web embedding), choose “Expert” mode, and define custom subsets: Unicode ranges, specific glyphs, or language presets. It outputs WOFF2/WOFF kits with a starter @font-face block.

Good for agency teams without a font toolchain in CI: one-off subsets for a client launch, then store the outputs in the repo or asset pipeline.

Everything Fonts Subsetter

Everything Fonts Subsetter accepts uploaded TTF/OTF/WOFF files and builds a reduced file from the characters you paste or select. Useful when you already know the exact glyph list from a design export or when you are trimming an existing self-hosted file after an audit.

FontForge

FontForge is desktop software for creating and editing fonts. Use it when you need precise control: merge subsets, remove tables, or build a custom subset for a product name baked into a brand face. The learning curve is steeper than a web generator, but it is the right tool when the font is yours to modify or when legal subsetting must be documented for the client.

How to implement font subsets (`@font-face`, `unicode-range`, `font-display`)

After you have a smaller file, wire it so the browser does not download the old full font by mistake.

@font-face {
  font-family: "Brand Display";
  src: url("/fonts/brand-display-hero-subset.woff2") format("woff2");
  font-weight: 700;
  font-style: normal;
  font-display: swap;
  unicode-range: U+0020-007F;
}

unicode-range tells the browser to skip downloading this file for characters outside the range. You can split one family into multiple files (Latin hero, Latin body, numerals-only) so each page loads only what it needs.

For variable fonts, subsetting is trickier but still worthwhile on high-traffic templates. Test on real devices: some older browsers handle unicode-range plus variable fonts differently than a static WOFF2 subset.

Document subsets in your client handover: which file applies to which template, and how to regenerate when marketing changes the hero string.

Reduce font file size: less data per page view

Subsetting is a technical optimisation first. Smaller font files mean less data over the wire per page view. On a site with 50 000 monthly sessions and a 150 KB font removed from the critical path, you avoid gigabytes of transfer over a year without changing the design.

That matters for:

Mobile users on metered or weak connections
CDN and origin egress costs at scale
Battery and CPU spent decoding fonts that never render

We avoid treating that as vague “eco” marketing. The measurable claim is simpler: you sent fewer bytes for the same page. If sustainability reporting matters to your client, subsetting is one line item next to image compression and script audits.

How to verify LCP and FCP after font subsetting

Subsetting is not done when the file size looks smaller in Finder. Verify in the browser and in your monitoring rhythm.

Network panel: Confirm the subset WOFF2 is requested (not the legacy full file). Check transfer size and that the request sits early enough for the hero.
PageSpeed Insights or Lighthouse: Compare FCP and LCP before and after on the same URL and throttling profile. Lab scores move for many reasons; keep one change per deploy when you are proving cause.
Filmstrip or trace: Ensure the hero text does not flash invisible for long periods. If font-display: swap causes a large layout shift when the custom face arrives, fix CLS separately (reserved space, fallback metrics).
Production monitoring: If you run automated PageSpeed monitoring, add the template to a performance budget so a future CMS or plugin change does not reintroduce the full font on every page.

Agencies maintaining many sites benefit from the same loop as images: fix the asset, prove it in lab, then watch scheduled tests so the regression does not return quietly on the next theme update.

Pick one high-traffic URL where the LCP node is text in a custom font. List the characters that can appear in that block (or export copy from the CMS). Generate a subset with Font Squirrel or Everything Fonts, deploy with font-display: swap, and re-run PSI. If LCP improves, roll the same pattern to other display templates and document the glyph list for the client.

Common font subsetting mistakes

Subsetting too aggressively so editors cannot type an em dash or an accented character without tofu squares.
Loading both subset and full font because an old enqueue line was left in WordPress or the tag manager.
Subsetting body fonts but still loading five weights on pages that use one weight.
Ignoring licensing; not every foundry permits subsetting or self-hosting. Read the EULA before Font Squirrel or FontForge exports go to production.
Skipping fallbacks; use a similar system stack in font-family so text stays readable if the subset fails to load.

Typography should not be the reason a fast layout scores poorly on paint metrics. Subsetting keeps the brand face while respecting the budget the network actually has.

Create a free account to track LCP and FCP across client sites with scheduled PageSpeed tests and performance budgets.

FAQ

Does font subsetting affect SEO?

Not directly. Search engines care about experience signals and crawlability. Faster paint and stable layout support the page experience story; subsetting is one input, not a ranking lever on its own.

Can I subset Google Fonts without self-hosting?

Yes, partially. The CSS API text= and family/axis parameters reduce what Google sends. For maximum control and caching, download and self-host a subset you generated.

Will subsetting break translations?

It can if you subset for English only and later add a Greek or Japanese locale. Plan per-locale subset files or a wider subset for multilingual templates.

WOFF2 only, or still ship WOFF?

For modern browsers in 2026, WOFF2 alone is usually enough. Keep WOFF only if you must support legacy clients named in the client’s browser support policy.

How does subsetting compare to using a system font stack?

System fonts add zero webfont bytes. Subsetting is the middle path when brand guidelines require a custom face but you refuse to ship an entire foundry file on every route.

Should I subset icon fonts?

Prefer SVG icons. If you remain on an icon font, subset to the icons in use or migrate to inline SVG to remove font decoding from the critical path entirely.

Image Optimisation Strategies for Better LCP Scores

Sat, 25 Apr 2026 06:55:16 +0000

On many marketing and product pages, Largest Contentful Paint (LCP) is not abstract. It is a hero photograph, a product shot, or a full-width banner. The metric tracks when that largest visible element finishes rendering; if the element is an image, your optimisation work is mostly bytes, dimensions, and discovery order—not another round of “general speed tips”.

This guide assumes you already know what LCP measures. If you need the full picture first, read What Are Core Web Vitals? A Practical Guide for 2026 and LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It. Here we go deep on image-specific strategies that move LCP toward the “good” band (≤ 2.5 seconds in the field), and how to pair them with performance budgets so improvements stick.

Start by identifying the real LCP element

You cannot optimise “the page” in the abstract. LCP is tied to one element in the viewport. In PageSpeed Insights or Lighthouse, open the diagnostics and note which node is reported as LCP—often an , sometimes a text block or a background.

If the tool points at an image:

Confirm the URL you are actually serving (CDN vs origin, srcset winner, and any CMS transforms).
Check the file size after compression. A 2.5 MB hero on a 360 px wide phone viewport is a sizing problem first, not a format problem.
Trace load order: is something else blocking discovery (late CSS, client-rendered markup, or a lazy attribute on the hero)?

Skipping this step is how teams ship a perfect WebP pipeline and still fail LCP because the LCP element was a different image—or text—than they assumed.

Pick modern formats and tune quality deliberately

AVIF usually beats WebP on file size at comparable visual quality; WebP still beats most JPEG for photos. The practical approach for 2026:

Serve AVIF with WebP or JPEG fallbacks using or rely on your CDN’s automatic format negotiation if you trust its tests.
Avoid shipping a single giant JPEG “because it works everywhere” unless you have measured that the conversion pipeline genuinely cannot run yet.
For illustrations with flat colour, SVG or optimised PNG can win; for large photographic heroes, raster formats dominate.

Quality settings are not universal. A quality of 75 in one encoder is not the same as 75 in another. Pick a default (for example AVIF at a sensible quantiser, WebP at 75–80), then visually compare at real display widths. Automated tools help, but a human glance at banding on skies and skin tones still catches regressions.

When you change format, re-measure LCP on the same URL. Lab scores can move for reasons unrelated to user-perceived quality, so keep before/after filmstrips or screenshots for stakeholders.

Match dimensions to rendered size, not to the asset library

LCP often fails because the browser decodes a 4000 px image into a 400 px slot. Responsive design does not mean “one huge master file for all breakpoints”.

Export or generate variants at the maximum CSS width they will occupy, per breakpoint, with a small margin for DPR (device pixel ratio). A 2× retina asset should be roughly 2× the CSS pixels, not 5× “for safety”.
Strip metadata you do not need; it is wasted bytes on every request.
If your CMS offers “automatic resizing”, verify the actual output dimensions in Network, not the checkbox in the admin UI.

If you only do one thing after reading this section: open DevTools → Network, click the LCP image, and compare Intrinsic size (natural width/height) to Rendered size. If the intrinsic side is many times larger than rendered, fix that before touching anything else.

Use `srcset` and `sizes` so the browser picks a sane file

Giving the browser a range of widths beats a single src for almost all content images.

srcset lists candidate widths or descriptors (480w, 800w, …).
sizes tells the browser how wide the image will be in the layout at different viewport widths, so it can pick the right candidate before downloading the wrong one.

Common mistakes:

sizes="100vw" on an image that is only half the layout width—so the browser pulls an unnecessarily large file.
Omitting sizes when using w descriptors, which can lead to poor selections.
Using loading="lazy" on an image that is above the fold and is your LCP element. The browser may defer work you needed immediately.

For a full-width hero, sizes="100vw" is often correct. For a card grid, describe the column width at each breakpoint. MDN’s documentation on responsive images is worth bookmarking for copy-paste patterns you can adapt.

Loading order: preload, priority, and lazy boundaries

Preload the LCP image when you know the URL early in the document:

Use this when the hero URL is stable and not swapped by heavy client-side logic. If the URL only appears after JavaScript runs, preload may fire too late—fix when the URL is known, not only how it is loaded.

fetchpriority="high" on the LCP nudges the browser to fetch that image sooner relative to other images. Use it sparingly (setting high on more than one or two images is usually not helpful) and pair it with not marking that same image as lazy.

Lazy loading belongs on below-the-fold images. For anything in the first screen, omit loading="lazy" or you risk delaying the very resource that defines LCP.

Decoding: decoding="async" can help keep the main thread responsive; test on low-end hardware if you are borderline on LCP.

CSS background images and LCP

Background images set in CSS are not elements. They are still eligible for LCP, but the browser can’t reliably discover the underlying image URL until after CSS is parsed—so you can end up with extra LCP resource load delay. You also lose straightforward alt semantics for critical content.

If your hero is purely decorative, a background can be fine—but you still pay the same byte and timing costs. If the hero carries meaning (product, banner text is not enough), prefer semantic or so preload and priority hints map cleanly to the resource.

When you must keep a background, preload it explicitly (e.g. link rel="preload" with fetchpriority="high" or a matching Link header) so it starts fetching early, and make sure the CSS/JS that reveals it doesn’t block rendering.

Third-party CDNs and transforms

Image CDNs that resize, reformat, and cache at the edge can shrink time-to-bytes dramatically. When you adopt one:

Lock URL parameters (width, quality, format) so marketing edits in the CMS do not silently generate new uncached variants.
Watch cache hit ratios after deploys; a “small” config change can bust effective caching.
Align transforms with your srcset strategy—duplicating the same logical image under twenty unbounded parameter combinations is a recipe for cache fragmentation.

CMS uploads and the “full size” trap

Many CMS/theme setups default new uploads to full resolution and then display them small. The HTML still references a massive file unless your theme registers proper image sizes and the markup uses them.

If you inherit a WordPress or similar build, check: (1) registered image sizes for hero slots, (2) whether the template uses wp_get_attachment_image with a named size or blindly outputs the original, (3) whether page builders inject full URLs into inline styles. One corrected template often beats dozens of hand-compressed assets nobody uses.

Verify in the lab, then confirm in the field

After changes:

Run PageSpeed Insights (or Lighthouse) on mobile and note LCP and the LCP element breakdown (TTFB, resource load delay, duration, render delay).
Compare field data (CrUX) where available—lab wins do not always match real users on slow networks.
If you use automated monitoring, add or check budgets for LCP on key templates so regressions surface when someone ships a new hero asset.

For a before/after story, WebPageTest filmstrips or Lighthouse’s View Trace help show whether you shortened resource load duration or merely shifted work. If TTFB or render delay still dominates, image tweaks alone will not get you to green.

Document one baseline number (median LCP or Lighthouse LCP) per template so the next redesign has a reference point.

Tie optimisation to budgets and ownership

Image work is easy to undo: a new campaign drops a 4 MB PNG into the hero and nobody notices until Search Console complains. Add a simple budget per template: maximum dimensions, maximum encoded kilobytes, and allowed formats. Our Performance Budget Thresholds Template is a starting point if you do not have internal standards yet.

Assign who approves hero assets in the CMS—often a designer uploads once and the performance contract is forgotten. A short checklist in the handover doc beats a post-launch fire drill.

What to do next

Identify the LCP element on your top templates.
Resize and re-encode; wire srcset/sizes correctly.
Remove lazy loading from above-the-fold heroes; add preload or fetchpriority where appropriate.
Re-test in the lab and watch field metrics after release.

Small, measurable steps beat a sweeping “image audit” that never ships.

FAQ

Is the hero image always the LCP element?

No. LCP is the largest visible element in the viewport; it can be a headline block, a video poster, or another image. Always confirm in your tooling before optimising the wrong asset.

WebP or AVIF first?

Prefer AVIF with a WebP or JPEG fallback for broad support, or use CDN negotiation if you have verified behaviour across browsers you care about.

Does lazy loading hurt LCP?

Lazy-loading your actual LCP element can delay LCP. In practice, omit loading="lazy" for the first-screen hero (and for any image the diagnostics report as LCP).

Do I need a CDN to pass LCP?

Not always, but a CDN often cuts latency and improves repeat visits. If TTFB or download time dominates your LCP breakdown, origin geography and caching deserve attention alongside image bytes.

Mobile vs Desktop Core Web Vitals: Why You Need to Monitor Both

Mon, 13 Apr 2026 23:52:33 +0000

Most teams treat Core Web Vitals like one scoreboard. They run a quick test, pick a single set of scores, and move on. The problem is that Core Web Vitals are defined per page load; device shows up in how you measure—mobile versus desktop in lab emulation, or in field data grouped by form factor. The same URL can therefore produce different LCP, INP, and CLS results across those contexts. Mobile and desktop travel different routes through your UI, assets, network conditions, and interaction patterns. If you monitor only one side, you will miss regressions that matter—and you will struggle to justify prioritisation when clients ask, “Why did this change?”

The trap: one device, one story

It’s easy to fall into a workflow like this:

Mobile is “important”, so you track mobile CWV only.
Desktop is “nice to have”, so you leave it until later.
When something breaks, you re-run tests and pick the latest scores to explain the incident.

This approach has two predictable failure modes:

Hidden regressions — A fix that improves desktop experience can still leave mobile failing (or vice versa).
Unclear communication — You end up explaining different symptoms with one set of numbers. Clients rightly lose confidence.

If you want monitoring that supports real delivery and client-ready reporting, you need a repeatable paired view: mobile + desktop for the same pages, the same cadence, and the same triage rules.

If you need a quick primer on the metrics themselves, start with What Are Core Web Vitals?.

Why mobile vs desktop Core Web Vitals diverge

Core Web Vitals can look “similar” at a headline level, but the underlying causes often differ. The most common reasons:

Different rendering and loading conditions

Mobile is constrained: less CPU headroom, different caching patterns, and more aggressive resource variation. That shows up strongly in:

LCP (Largest Contentful Paint): often driven by large images, fonts, or other heavy elements on the critical path (the LCP element can also be a text block or a video poster, depending on the page). If those pieces behave differently across breakpoints, LCP will diverge.

Different interaction patterns (INP)

INP captures interaction responsiveness, which often behaves differently by device due to:

Touch vs pointer interactions
Different event targets and UI density
Varying execution cost on lower-end hardware

If you only look at one device’s INP, you can miss “works on desktop” but “feels slow on phones” issues.

Different layout stability (CLS)

CLS is highly sensitive to responsive layout, late-loading elements, and dynamic components that appear only under certain breakpoints (ads, banners, late injected UI, etc.). A page can be stable on desktop and still shift on mobile.

For a deeper explanation of what each metric actually means, see LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It.

What to monitor in practice (beyond the total score)

Monitoring both devices is necessary, but it’s not sufficient by itself.

You also need to monitor the right dimensions:

1. Treat each device as its own budget

Instead of one “CWV target” for the page, define device-specific thresholds for the metrics you care about. A pass on desktop should not automatically compensate for a fail on mobile.

This keeps decisions defensible when you propose fixes to stakeholders.

If you want a structured way to set thresholds, use our Performance Budget Thresholds Template.

2. Compare by change, not by absolute numbers alone

Absolute CWV numbers can vary slightly run-to-run. What should drive action is:

What changed since the last known good period
Which metric moved first (LCP vs INP vs CLS)
Which device changed (mobile-first incidents vs desktop-only issues)

3. Triage using “worst metric per device”

A practical triage rule:

For mobile: focus on the single worst metric (LCP/INP/CLS) and the reason it is failing.
For desktop: do the same.

Then decide whether you have a shared root cause (both devices fail similarly) or breakpoint/device-specific problems.

A practical monitoring workflow for agencies

If you want this to work across clients and pages, keep it repeatable. Here’s a workflow you can run every week:

Choose pages that reflect real funnel risk
- Homepage (first impression)
- Key category or service pages (high intent)
- Conversion pages (where UX pain becomes business cost)
Run paired analysis for the same pages
- Mobile + desktop tests on the same cadence
- Stable analysis conditions (avoid mixing “random checks” with planned ones)
Record findings in the same order
- Mobile: LCP → INP → CLS (and a quick “what it likely affects” note)
- Desktop: LCP → INP → CLS
Assign device-specific priority
- If mobile fails and desktop passes, your “first fix” should usually start mobile unless you have a desktop-only user segment.
Set alerts that match the story
- Budget breaches on a device should trigger the device’s reporting, not just the overall page score.
Deliver client-ready reporting
- Give clients a paired narrative: “what you saw” and “what you changed next”.

For the setup side of automated monitoring across multiple sites, see How to Set Up Automated PageSpeed Monitoring for Multiple Sites.

And if you’re turning this into deliverables, the Client-Ready Core Web Vitals Report Outline helps you package the evidence into something stakeholders actually read.

Interpreting results: three common scenarios

When you review mobile vs desktop CWV together, you’ll usually fall into one of these buckets:

Scenario	What it often means	How you should respond
Mobile failing, desktop ok	Mobile critical path or interactive cost is the bottleneck	Prioritise mobile-first fixes (hero/LCP and interaction latency)
Desktop failing, mobile ok	Desktop-only layout or heavy JS path	Focus on desktop breakpoints, scripts, and layout stability
Both failing consistently	Shared design debt or performance regressions	Treat it as a system-level problem, then verify with paired reruns

The important part is that you avoid the “one score explains everything” habit. Paired monitoring turns CWV from a vanity chart into a decision system.

What your client update should say (example wording)

When clients ask “why are there two scores?”, they usually want a single paragraph that explains what changed and what you will do next.

Here’s a simple template you can reuse:

Mobile-first incident (mobile fails, desktop ok):

“Mobile performance is out of budget right now (LCP/INP/CLS), while desktop is within budget. This pattern usually points to a mobile-specific bottleneck: hero rendering timing, touch interaction cost, or a late-loading component that behaves differently on smaller breakpoints.”
“Next step: we’ll apply a targeted first-fix on the affected mobile path, then re-run the same paired checks to confirm both the device budget and the user-story are improving.”

Shared incident (both devices failing in a similar way):

“Both mobile and desktop are currently out of budget for the same metric area. That usually means a shared component, shared asset, or shared build/deploy change rather than a single device quirk.”
“Next step: we’ll verify what changed in the release window, then test the fix with paired checks to ensure the improvement holds across devices.”

If you include field data (for example, when you do CrUX-aware reporting), keep the wording consistent: explain what your lab checks caught, and how the field view supports the same story. The goal is less debate and more action.

A quick consistency check for every report

Before you send your update, run this quick self-check:

Are you using the same page set for both devices (so the comparison is fair)?
Did you name the first metric to fail on each device (so the triage is clear)?
Does your next step match the device that is failing (or explain why you’re fixing something shared first)?
Did you state how you will verify after changes (re-run paired checks, not “we’ll look later”)?

Client-ready reporting: avoid confusion with one sentence

Clients often ask why you’re reporting two device scores.

Your answer should be simple:

“Mobile and desktop measure different experiences. We monitor both so we catch issues that only appear on one device and so our fixes stay prioritised and verifiable.”

When you present this in a consistent report format, it is easier for stakeholders to focus on the next actions instead of arguing over a single headline score.

Operational checklist for your next report

Pick the same set of pages every reporting cycle
Confirm mobile + desktop are both included in the schedule
Use device-specific thresholds for LCP/INP/CLS
Triage by worst metric per device, then explain likely root cause
Reference a repeatable next step (fix + verify, not just “we will look into it”)
Share a paired narrative that stakeholders can understand in under two minutes

FAQ

Do I need to monitor both mobile and desktop if mobile gets most traffic?
Yes. Even if mobile dominates, desktop still represents business risk for a portion of your audience. More importantly, fixes can improve one device while leaving the other failing. Paired monitoring prevents blind spots.

Which metric should I start with: LCP, INP, or CLS?
Start with the worst metric on each device (mobile and desktop separately). In many audits, improving LCP is the fastest high-impact win, while INP usually surfaces interaction pain and CLS highlights layout instability—but the right first lever depends on what is actually failing.

How often should we review paired CWV?
For most agency workflows, weekly review is a good starting point. For active releases or client campaigns, you may need tighter cadence to verify that fixes actually hold.

What if a page behaves differently by device (e.g. different layout/components)?
That’s exactly why paired monitoring helps. Explain the difference in your report: the breakpoint experience is part of the user journey, and device-specific findings lead to device-specific fixes.

Will paired monitoring slow down the workflow?
It shouldn’t. The operational cost should live in automation, not manual re-checks. If your monitoring is scheduled and your reporting is templated, you get more reliable evidence without extra churn.

If you want a repeatable way to monitor mobile and desktop Core Web Vitals across client portfolios (with paired evidence, budgets, and client-ready reporting), Apogee Watcher is built for that workflow.

Coder Legion - Recent posts tagged lcp

Critical CSS and Render-Blocking Resources: Faster First Paint Without Guessing

What critical CSS is (and what it is not)

How render-blocking CSS delays First Contentful Paint and Largest Contentful Paint

How to find critical CSS with Chrome DevTools Coverage

How to inline critical CSS and defer the rest

Media-query stylesheets as a lighter alternative

Mistakes that make “critical CSS” slower

How to verify the change in Lighthouse and monitoring

FAQ

Measure first, then inline

References

Preload, Prefetch, and Preconnect: Resource Hints for Faster Core Web Vitals

What resource hints change for Core Web Vitals (and what they do not)

dns-prefetch vs preconnect vs preload vs prefetch: which hint to use

How to preload the LCP image (and when preload is the wrong fix)

Preconnect for performance on cross-origin origins

Prefetch versus preload: current page versus next navigation

Font preload limits (pair with subsetting, not instead of it)

Resource-hint mistakes that hurt lab and field scores

No-Vary-Search for prefetch and speculation (short note)

How to verify resource hints after you deploy them

FAQ

CTA

References

Lazy Loading for LCP and CLS: When to Use loading="lazy" (and When Not To)

What the loading="lazy" attribute does

Why lazy-loading the LCP image hurts Largest Contentful Paint

When lazy loading images is the right default

Above-the-fold images, fetchpriority, and eager loading

Iframes, video, and other lazy media caveats

Lazy loading and CLS: reserve space first

Lab vs field when lazy loading hides LCP regressions

Agency checklist before you ship “lazy everything”

FAQ

Ship eager heroes, lazy galleries

References

Brotli and Gzip Compression: Shrink Text Assets Without Breaking PageSpeed Scores

What Brotli and gzip change on the response path

Brotli vs gzip for web delivery (and when gzip still wins)

Which responses to compress (and which to leave alone)

How to enable Brotli with a gzip fallback at origin and CDN

Origin and reverse proxy patterns

CDN and edge

Fix Lighthouse “Enable text compression” without breaking PageSpeed scores

Compression mistakes that hurt TTFB, LCP, or lab scores

Verify Content-Encoding on live URLs after every deploy

FAQ

References

A Quick Way to Fix LCP: Four Changes That Cut Time to Paint

What is the path to LCP?

Step 1: Improve TTFB (Time to First Byte)

Step 2: Remove anything in the path to LCP that matters less than the LCP element

Icons and decorative assets

Third-party scripts

Below-the-fold images

Fonts that are not needed for the LCP element

Step 3: Prioritise the LCP element with fetchpriority="high"

Step 4: Schedule less important JavaScript after the load event

A one-hour LCP fix workflow

What these four steps do not replace

FAQ

Font Subsetting for Web Performance: 4 Tools to Reduce Font File Size and Improve LCP

What font subsetting is

When font subsetting improves web font performance and LCP

Font subsetting example: hero display copy without the full font file

Four tools for font subsetting

Google Fonts

Font Squirrel Webfont Generator

Everything Fonts Subsetter

FontForge

How to implement font subsets (@font-face, unicode-range, font-display)

Reduce font file size: less data per page view

How to verify LCP and FCP after font subsetting

Common font subsetting mistakes

FAQ

Image Optimisation Strategies for Better LCP Scores

Start by identifying the real LCP element

Pick modern formats and tune quality deliberately

Match dimensions to rendered size, not to the asset library

What the `loading="lazy"` attribute does

Above-the-fold images, `fetchpriority`, and eager loading

How to implement font subsets (`@font-face`, `unicode-range`, `font-display`)

Use `srcset` and `sizes` so the browser picks a sane file