Optimised asset

Definition and scope

In web performance, an optimised asset is a static resource that has been prepared to meet a specific delivery context with minimal overhead. For images, that typically includes appropriate dimensions and density variants, modern codecs (for example AVIF or WebP) at a chosen quality, stripped metadata, and cache headers. For scripts and styles, it involves minification, bundling or splitting, and prioritisation. For fonts, it covers subsetting, WOFF2, and fallback behaviour. Effective optimisation also extends to delivery—HTTP compression, CDN caching, request prioritisation, and immutable URLs.

Scope is lifecycle‑wide: build‑time transforms (e.g. encoding and subsetting), run‑time selection (e.g. responsive srcset, variable font axes), and network controls (e.g. Cache-Control, preloading, and priority hints). The intent is not only to shrink files but to ensure fast discovery, efficient transport, predictable rendering, and minimal CPU/GPU cost on the client. An asset is considered optimised only if its visual or functional outcome remains acceptable for the context in which it is used.

Performance goals

Optimised assets aim to reduce transfer size, request overhead, and main‑thread work while improving cache hit rate and resource prioritisation. Typical objectives include faster start render (FCP), reliable hero rendering (LCP under 2.5 s on median mobile), stable layout (zero CLS contributions from media), and minimal input delay (no long tasks from heavy scripts). For frequently reused assets, a high cache hit ratio (e.g. 85–95% at the CDN edge) is a practical target that reduces time to first byte and bandwidth.

Image payloads often see 30–80% byte savings with modern codecs and resizing, though results vary by content. For critical imagery, the effective target is perceptual quality at the smallest viable byte size, not a fixed kilobyte cap. Delivery objectives include fewest round trips (HTTP/2 or HTTP/3), correct priority (via fetchpriority or Priority Hints), and long‑lived immutable caching for versioned files so that repeat visits avoid re‑transfer.

Optimisation techniques

Images and media

Common methods include responsive images (srcset and sizes) with exact width and height attributes to reserve space; modern formats such as AVIF and WebP, and SVG for resolution‑independent vector artwork; perceptual compression with tuned quality; metadata removal; and colour‑space consistency. Lazy‑loading for non‑critical media reduces initial bytes, while placeholders (blur or solid dominant colour) improve perceived performance. For video, bitrate ladders, codec selection (e.g. AV1/H.265 where supported), and streaming with byte‑range requests and caching are typical.

Fonts, scripts, and styles

Font optimisation covers subsetting glyphs, variable fonts to consolidate families, WOFF2 encoding, and render strategy (font-display). Scripts and styles benefit from tree‑shaking, minification, code splitting, and deferring non‑critical work. Delivery techniques include resource hints (preload/preconnect), HTTP compression (Brotli for text), content hashing for immutable caching, and CDN edge caching with origin shielding. Priority Hints and fetchpriority can elevate critical assets (e.g. hero image) above other resources under HTTP/2 or HTTP/3 multiplexing.

Quality and trade-offs

Balancing byte size and perceptual quality is central. Aggressive compression can introduce banding, ringing, or text artefacts that erode trust or accessibility. Objective metrics (SSIM, PSNR, and for video VMAF) provide baselines, but human perception and the content’s purpose remain the deciding factors. Decode and render cost also matter: formats with excellent compression ratios may increase CPU usage on low‑power devices, affecting battery life and interaction latency. For images that drive conversions (e.g. product shots), a slightly larger file at higher quality may be justified.

Technique selection has secondary effects. Progressive JPEGs can improve perceived rendering over slow connections, but may not always compress as efficiently as single‑pass encodes. AVIF offers strong compression at the cost of slower encoding, which can affect on‑the‑fly pipelines. Excessive lazy‑loading can delay LCP if applied to above‑the‑fold media, and omitting intrinsic dimensions can introduce CLS. The optimal approach is context‑specific, balancing quality, throughput, device capability, and development complexity.

SEO and crawl efficiency

Optimised assets contribute to search visibility by improving Core Web Vitals—particularly LCP and CLS—which influence rankings. Smaller, cacheable files reduce server load and speed up page rendering, improving overall user signals. Efficient caching and stable URLs reduce repeated transfers for crawlers, while correct status codes and CORS headers help search engines fetch and index images. Image sitemaps, descriptive file names, and alt attributes support relevance, while structured data clarifies context for product and recipe imagery.

Crawl efficiency improves when assets are versioned immutably and long‑cached, because bots avoid re‑downloading unchanged files. Robots rules should not block essential assets needed for rendering, otherwise Google may misjudge layout or content. Excessive URL churn from parameterised transforms can inflate crawl, so stable canonical URLs for primary variants are preferable, with responsive selection handled via srcset rather than frequent server‑side negotiation. Above‑the‑fold media should be promptly discoverable to avoid delaying critical rendering for both users and bots.

Measurement and validation

Validation blends lab and field data. Lighthouse, PageSpeed Insights, and WebPageTest reveal opportunities and visual waterfalls, while the Chrome UX Report and RUM capture real user distributions for LCP, CLS, and INP. Browser DevTools help verify file sizes, content‑type, cache headers, priority, compression (Brotli/Gzip), and whether srcset selects the intended variant. Synthetic tests should cover mobile throttling, cold and warm cache runs, and different network conditions to surface bottlenecks in discovery, negotiation, or decoding.

Quality gates keep regressions in check. Performance budgets in CI can alert on total image bytes, number of requests, or LCP timing. Visual diffs detect over‑compression artefacts, and error budgets track image 404/5xx rates from the CDN. Server logs and analytics can report cache hit ratios, edge vs origin traffic, and median transfer sizes by asset type. Periodic reviews of decoding time and main‑thread long tasks identify heavy formats or scripts that undermine perceived speed despite byte reductions.

Implementation notes

Robust pipelines commonly generate multiple variants at build or on demand: by width, DPR, and format (e.g. AVIF, WebP, fallback JPEG/PNG) for images; by subset and weight for fonts; and by modern/legacy bundles for scripts. Immutable, content‑hashed filenames enable long Cache‑Control lifetimes with safe cache busting on deploy. CDN configuration typically includes origin shielding, tiered caching, and normalised query parameters for transforms, while keeping canonical URLs stable for primary variants to limit cache fragmentation and crawl churn.

Format negotiation via the Accept header can complicate caching because a single URL may vary by client support; explicit URLs per format (or query‑keyed variants with proper Vary headers) tend to cache more predictably at the edge. For critical images, priority controls (e.g. fetchpriority) and preload can ensure early delivery under multiplexed connections. Placeholder generation and intrinsic size extraction at encode time help prevent layout shifts and improve perceived speed without additional runtime work.

Comparisons

Optimised asset vs compressed asset vs minified asset

Compression or minification targets file size, while optimisation encompasses end‑to‑end delivery and rendering outcomes. A compressed image may still be unoptimised if it is oversized for its slot, poorly cached, or discovered late. Conversely, a minified script can remain a bottleneck if it blocks rendering or executes heavy work on the main thread. An optimised asset accounts for the right format, dimensions, priority, caching, and execution characteristics for the specific context in which it is used.

Optimised image vs responsive image

Responsive images address selection—choosing the best variant for the viewport—while optimisation also covers encoding choices, caching, and priority. A responsive setup that serves bloated encodes or omits cache headers is only partially optimised.

FAQs

Is an optimised asset always smaller than the original?

Usually, but not invariably. An asset might become marginally larger if a different format or encoding yields faster decoding or better caching behaviour that improves overall page speed. The goal is fastest useful rendering at acceptable quality, not a strict kilobyte minimum.

Should AVIF be served to all browsers by default?

No. AVIF support and decode performance vary by browser and device. A common approach is to provide AVIF and WebP variants with a JPEG/PNG fallback, allowing the browser to choose via picture/srcset. For critical content, test decode times and quality on target devices rather than assuming one format is universally best.

Do optimised assets improve Core Web Vitals directly?

They influence Web Vitals by reducing transfer and processing time, prioritising critical resources, and preventing layout shifts. For example, an appropriately sized, prioritised hero image with intrinsic dimensions can materially improve LCP and avoid CLS. Lighter scripts and deferred non‑critical work can reduce long tasks and improve INP.

Does using a CDN mean assets are optimised?

A CDN improves proximity and caching, but it does not ensure correct formats, dimensions, priorities, or execution behaviour. Encoding choices, responsive variants, cacheability (e.g. immutable versioned URLs), and HTML integration remain essential. CDN configuration complements, rather than replaces, asset optimisation.

What is a reasonable target size for a hero image on mobile?

Targets depend on content and device density. Many sites achieve 60–150 KB for photographic heroes with AVIF/WebP at typical mobile breakpoints, but high‑detail scenes or brand constraints may require more. The practical aim is to render LCP within 2.5 seconds for the 75th percentile of mobile users in the target markets.