Image and Font Delivery at the Edge: The Quiet Speed Win
Serve images and fonts from the edge in modern formats, sized to the slot they fill, with long cache lifetimes and content based file names. The bytes live one short hop from the shopper instead of crossing the internet from your origin, and repeat visits skip the download almost entirely.
Ask a storefront team where their page weight lives and the answer is rarely the JavaScript they argue about. It is the hero image, the product gallery, and three font files in formats chosen a decade ago. Those assets are also the easiest to fix, because they change rarely and cache beautifully.
Edge delivery suits static assets perfectly. The first request warms a nearby cache, and everyone after that gets the file from next door. This post walks through the format, sizing, and caching decisions that turn images and fonts from a liability into background infrastructure.
Formats and sizes do the heavy lifting
Convert product photography to WebP or AVIF at the edge and serve the format each browser supports. The same photo that left the studio as a two megabyte JPEG often lands under two hundred kilobytes with no visible difference on a phone screen, which is where most shoppers will judge it.
Resize to the slot, not the source. A thumbnail grid does not need the full resolution master, and serving it anyway multiplies bandwidth across every listing page. Generate the handful of sizes your templates actually use and let the edge pick, instead of shipping one giant file and scaling it in the browser.
Fonts deserve the same discipline
Self host your fonts at the edge rather than calling a third party service from the browser. Every external origin adds DNS, connection, and TLS time before the first glyph arrives, and text that waits on fonts either hides or jumps, both of which shoppers read as slowness.
Subset aggressively and ship WOFF2 only. Most stores use a fraction of each font character set; a subset covering Latin characters and punctuation cuts font payloads dramatically. Preload the one weight used for headlines and let the rest load without blocking, with a sensible fallback stack so a slow font never blanks the page.
Cache like you mean it
Give versioned asset files cache lifetimes measured in months. When the file name carries a content hash, a new version is simply a new URL, so nothing stale can ever be served. Short lifetimes on unversioned assets are the usual compromise, and they quietly surrender most of the repeat visit benefit.
Measure the win where it lands: largest contentful paint on product and category templates, split by new and returning visitors. Edge asset delivery shows up within a day in those numbers, which makes it the rare optimization you can verify before and after with no ambiguity.
Related reading
Readers working through this topic often find these earlier guides useful as well: How Edge Personalization Works Without Slowing the Storefront Down, Edge Observability: Seeing Storefront Errors Where They Actually Happen, and Cutting Checkout API Latency With Edge Proxies and Connection Reuse.
Frequently asked questions
Will shoppers notice a difference from WebP or AVIF images?
At matched quality settings, no. The formats compress photographic detail more efficiently, so the same visual quality arrives in far fewer bytes. Side by side comparisons at storefront sizes are effectively indistinguishable, including on retina screens.
Why does my site still feel slow if images are cached?
Caching fixes repeat delivery, not first view rendering. Check whether images are sized correctly for their slots and whether fonts block text rendering; a fast cache serving oversized files still produces slow pages on first visits.
Should I preload fonts on every page?
Preload only the critical weight used above the fold, typically the headline font. Preloading everything competes with images and scripts for early bandwidth and can make the page slower, not faster.
How often should image caches be purged?
Almost never, if file names are versioned. New product photos publish as new URLs and old ones age out on their own. Purges are for the rare case of a wrong image under an existing name, which versioning prevents by design.