Responsive Images Done Right, and the Rest
A production frontend got its responsive images right — explicit sizes, priority hints, preloading of the next slide — while loading fonts through two mechanisms and depending on an external icon CDN. The image work is worth copying; the rest is worth auditing.
· The RECNOS Engineering Team
The sizing attribute that prevents the wrong download
An image with `fill` and no `sizes` attribute forces the browser to assume the image spans the full viewport. It then downloads the largest candidate in the source set — often a file several times larger than the space it occupies.
This build sets an explicit `sizes` value describing the actual rendered width at three breakpoints, so the browser picks the correct candidate for the viewport.
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 650px"Priority hints on the first slide only
The first two slides carry a priority hint, and the rest do not. That is the right shape for a carousel: the initially visible creative should not be lazy-loaded, and the third slide should not compete with it for bandwidth.
The next image is also preloaded manually before the transition begins, so the crossfade does not stall on a network request. The combination — eager for what is visible, preload for what is next, lazy for everything else — is the pattern worth reusing.
Two font-loading mechanisms in one document
The layout loads two families through the framework's font pipeline, which self-hosts them, generates the `@font-face` rules, and applies `display: swap` with CSS variables. That is the recommended approach and it is implemented correctly.
The same document then adds a raw stylesheet link for four more families from Google's CDN. Two mechanisms means two request paths, two caching stories, and a render-blocking stylesheet that the self-hosted fonts were meant to avoid. Preconnect hints are set for both hosts, which reduces the cost without removing the dependency.
An icon CDN in the critical path
A third-party icon stylesheet is loaded from a public CDN, and icon classes are used in component markup. This puts a third-party origin in the render path for a handful of glyphs.
The dependency is also a correctness risk. A stylesheet that fails to load leaves empty boxes where icons should be, with no fallback, because the markup relies on classes rather than inline SVG.
One image bypassing the optimiser
One component uses a plain `img` element where the rest of the codebase uses the framework's image component. That image gets no resizing, no format conversion, and no responsive source set — it is served at its original size to every viewport.
The project's own wrapper component handles external URLs by marking them unoptimized deliberately. The difference is that the wrapper makes that decision explicitly and applies a fallback; the plain element makes it by omission.
What to take from this
Performance work is rarely uniformly good or bad. The image handling here is careful and specific: correct sizing, deliberate priority, manual preloading, and a cache policy set at both the framework and the reverse-proxy layer.
The remaining issues are all the same kind — a second way of doing something that was already solved, which adds a dependency without adding a capability. Auditing for duplicates tends to find more than auditing for omissions.