Common image optimisations - PageSpeed and beyond

In my day job, I think about video and related optimisations, but I regularly see people go wrong with images. I am anchoring this post on PageSpeed and images. It’s safe to say that most experienced web developers have reviewed PageSpeed or Lighthouse recommendations. These tools analyze site performance and often focus on images. On almost any webpage, images are typically the largest downloads, so performance or optimization tools emphasize them.

I have listed some standard image optimizations below:

• Optimize image size
• Use correct dimensions
• Lazy load images
• Optimise format (Chrome/Android renders WebP faster than PNG)
• Use client-side cache
• Using CSS sprites
• Small images can be data images.
• Use fonts for icons

Considerations for Mobile and TV apps

Original suggestions were created for websites, but many apply to mobile and TV apps as well. Using a small, right-sized image in the best format for the device (Android, iPhone, Android TV) ensures faster downloads and rendering. TV apps often lag because Smart TVs have less memory and CPU power than PCs or high-end phones.

Client-side image caching is powerful because these apps already have local caches, and most popular image libraries support HTTP cache headers. These apps often use images (such as logos or loaders) bundled with the app binaries.

Mobile apps are ideal for lazy loading images. Only load images in the viewport as customers scroll.

Impact of these optimisations on CDN performance

I understand that not everyone needs to worry about CDN performance, but most large customer-facing applications should actively monitor it as part of their engineering KPIs. Image CDN performance (and associated cost of delivery) is directly dependent on the number of requests served and the total data transferred.

PageSpeed recommendations work on both of these parameters. I have listed how these recommendations affect CDN performance:

• Optimize size
  • Small objects, such as compressed images, are more straightforward to cache and transfer. Cache performance alone can make a massive difference in TTFB (time to first byte, the time it takes for the first byte of data to arrive from the server) for an image request. Optimize your images with tinypng or a similar tool.
• Use correct dimensions
  • Correct dimensions may not directly affect CDN performance, but smaller dimensions lead to less CDN usage.
  • Reducing resource size can free bandwidth for other critical assets.
• Lazy load images
  • Lazy loading prevents unnecessary image downloads for images that users might not view. Only load what’s needed.
• Optimise format (Chrome/Android renders WebP faster than PNG)
  • I would argue that serving different formats reduces the CDN cache hit rate, increases cache size, and has a negative overall impact. However, the app's image rendering performance remains a worthwhile optimization target.
  • Client shares critical information, such as acceptable image formats, via the Accept header when fetching images. Pick the most optimised format that helps us save data transferred. CDNs usually handle this step automatically.
• Use client-side cache
  • If your images are not changing, we should let the browser or app cache them. CDNs enable excellent edge and client caching, and the absence of requests is always a good thing.
  • UX is significantly improved because clients don’t have to wait for images to download.
• Using CSS sprites
  • I hear that HTTP2 makes this recommendation obsolete, but HTTP2 adoption across apps is likely still below 30%. Until adoption increases, CSS sprites remain an effective way to reduce the number of CDN requests.
• Small images can be data images.
  • Let’s say you have a 1200-byte image. Compress the image using tinypng or a similar tool, convert it to base64, and deliver it as HTML/JS/JSON, which can be further compressed for network transfer based on the Accept-Encoding header. You will transfer significantly less. Now, imagine ten such pictures on your page, and you can see how the number of requests is reduced.
• Use fonts for icons
  • A font like Font Awesome offers thousands of icons, all accessible in a single download. If Font Awesome doesn't suit your needs, consider creating a custom font with your most-used icons.

Googly from 404s

I must call out one caveat: if your app or website requests an incorrect path, your CDNs will respond with 404, and the browser/app won’t be able to cache these images. It hurts to pay for “Not found” images; please avoid this costly mistake. At the same time, user experience would suffer, as a broken image would take up space on their screen.

It is good practice to include fallback logic when images are dynamic.

Caching Best Practices

We now know that 404s on images are bad. Let’s talk about what else can be done here. We need to understand the reason why this might happen. If we were to keep updating images on the same path, it might lead to one of the following issues:

• The old image gets cached on the device. So, instead of a new image, they keep seeing the same old image.
• That path was being used elsewhere, and the owner wasn’t aware of it. One change would be reflected in all those places where the image was used.

A simple way to avoid such a scenario is by keeping the image asset immutable. Once uploaded, no image path will be updated, so a new image will be created for each iteration.

CDN vs. downstream cache

Most CDNs allow granular cache settings. They can keep or drop upstream cache headers and manage which headers are passed to downstream clients.

Your app’s logo doesn’t change frequently. This image can be cached by CDNs and will probably also be cached by any browser/apps that have downloaded the logo once.

Image URL version

We discussed that your app’s logo doesn’t change frequently, but what if it does? If clients were not caching the logo, you could still purge the CDN edge cache. An even better strategy is to ensure that all images have unique URLs. When the contents of your logo change, the URL should change too. This allows you to set up very large caches without getting stuck with an old image.

App image cache

Most image libraries also allow you to configure a preheated/bundled cache. If the image URL doesn’t change, the local copy can be used.

Work with user perception

If you load a webpage with nothing on it, customers will definitely perceive your website as slow; they won't know whether it's  loading. Often, displaying a loading state, a shimmer, or a low-quality thumbnail before the real image improves your customer's experience. Some teams also use progressive images.

An Audit Checklist for you

We all learn these best practices and sometimes don’t follow them. Hopefully this is a reminder for you. Image optimization is an integral part of SDLC (Software Development Life Cycle). From design, development, manual QA (Quality Assurance), automation, and monitoring, correctly sized images with good caching offloads are considered at every step. Maybe write a Claude/Codex skill for ensuring these best practices are followed.

You don’t need to do everything; do what makes sense at your scale and for your business type.

• For Small Startups
  • Minify your images
  • If you are using a lot of images on your homepage, act like a larger company.
  • Use font icons whenever possible.
• For a relatively large company/Startup
  • Use an image optimisation SAAS (or build your own)
  • Ensure images are delivered from a CDN.
  • Version your images
  • Ensure images also have a downstream cache.
  • Consider data images within HTML for super small images.
  • Implement progressive image loading or display thumbnails, then load images asynchronously to improve user experience.

What's your image optimisation story and