Asset and font loading for web apps

Where loading order hurts apps

Google breaks Largest Contentful Paint into four subparts: how long the first byte takes, how long before the browser starts fetching the LCP resource, how long that fetch lasts, and how long the element then waits to paint (source 1). In client-rendered and partly hydrated apps, the second and fourth parts are often the large ones. The hero image is not in the initial HTML, so the browser cannot discover it until JavaScript runs; or it downloads quickly but cannot paint until a render-blocking stylesheet or a client render finishes. Google's guidance suggests that resource load delay and element render delay should each be a small share of LCP, under about 10 percent, with most of the time spent on the first byte and the download itself (source 1).

Fonts cause a different problem. When a web font replaces a fallback with different metrics, text reflows and nearby content moves. That counts towards Cumulative Layout Shift unless it happens within 500 ms of a user input, which page loads are not (source 2).

What we review

• Discovery. Whether the LCP resource appears in the server HTML, is preloaded, or is only found after scripts run.
• Priority. Use of fetchpriority, preload hints and lazy loading, including images lazy-loaded above the fold, which delays them.
• Image delivery. Formats, responsive sizes and whether the image served matches the size displayed.
• Font strategy. Number of families and weights, subsetting, font-display choices, preloading, and fallback metric overrides such as size-adjust that reduce reflow.
• Icon systems. Large icon fonts or sprite bundles loaded for a handful of icons.
• Code chunks. Route chunks and shared chunks requested late because they sit behind other chunks in a waterfall.
• Caching headers. Whether hashed assets are cached for long periods and HTML is revalidated sensibly.

How the engagement runs

1. 01

   Waterfall capture

   Network waterfalls and LCP breakdowns for the main routes on fast and throttled profiles.

2. 02

   Find late discoveries

   Every critical resource found later than it could be, with the reason.

3. 03

   Plan the order

   A proposed loading order per route with the hints, attributes or code changes needed to get there.

4. 04

   Font and fallback tuning

   Where fonts shift layout, suggested fallback metrics and loading settings, tested against your own typefaces.

What you receive

Annotated waterfalls, the LCP breakdown per route, a loading plan, and font settings ready to paste into your CSS where we could test them. This service is narrower than a full rendering analysis and is often added to one.

An invented example

A client-rendered app shows a large hero image on its landing route. The image is set as a background in a component that renders only after the main bundle runs, so the browser discovers it late; in the LCP breakdown, resource load delay is the largest part. The plan: render the hero image as an img element in the server-sent HTML, add fetchpriority="high", serve responsive sizes, and remove the lazy-loading attribute a shared image component had added. The font fix on the same route: subset the brand font to the characters used, drop two unused weights, preload the one weight used above the fold, and add size-adjust and related overrides so the fallback matches the web font's metrics.

None of these changes touches the app's logic, which is why loading work is often a quick first win alongside deeper rendering changes.

Layout stability while assets load

Loading order and layout stability are linked. Cumulative Layout Shift groups shifts into bursts that end after a one-second gap or five seconds at most, and the page's score is the worst burst (source 2). Images and embeds without reserved dimensions, late-loading components inserted above existing content and fonts that change line lengths are the common sources in apps. The loading plan therefore covers space as well as time: width and height or aspect-ratio on media, placeholders sized to the final component, and fallback fonts tuned to the web font's metrics so text keeps its shape when the swap happens.

How this fits with other work

Asset loading sits early in the page's life, before most JavaScript has run, so its changes rarely conflict with rendering or hydration work. It is a good first stream while a strategy review or hydration plan is still being discussed, and it gives your team quick, measurable changes to ship. In field data, the effect shows up in LCP and CLS rather than INP; we say so in the report so expectations stay accurate.

What we need from you

Access to the routes, the font files and licences you use (to confirm that subsetting is allowed), and the image pipeline or CDN settings. If your design system controls image and font loading centrally, a look at its components helps, because one change there can fix every route at once.

Questions about asset loading