Serving Images Fast Without an Image CDN

You can optimise images without cdn by resizing assets once at build time, storing them in modern formats like WebP or AVIF, and serving them with long-lived cache headers. This approach eliminates the overhead of dynamic processing on every request, making it ideal for static sites and applications with predictable image dimensions.

Pre-generate, Do Not Process

Running image resizers in a live server process forces the CPU to work on every unique image request. On a single VPS, where processes compete for memory and CPU cycles, this creates unnecessary latency. Instead, generate the specific sizes you need during the build step. For our Android wallpaper app, PracandyWalls, we know exactly which screen resolutions matter. We generate those fixed dimensions ahead of time. This means the server simply reads a file from disk and sends it. There is no calculation, no decoding, and no re-encoding at request time.

Cache Headers and Formats

Modern browsers handle WebP and AVIF efficiently, but the network layer still matters. Set long cache-control headers for static image assets. If an image does not change, the browser should never ask the server for it again. Caddy, which terminates TLS for all our sites, makes this straightforward. It serves static files from disk with minimal overhead. For dynamic content, such as user-uploaded avatars in our Instagram scheduling tool, Instalaz, we still pre-generate thumbnails. We do not rely on on-the-fly resizing for public-facing assets. The trade-off is simple: use a bit more disk space to save significant CPU cycles and improve perceived speed for the end user.

When On-the-Fly Resizing Makes Sense

Dynamic resizing is worth it only when you cannot predict the required dimensions. This is common in e-commerce platforms where users can crop images in arbitrary ways. In those cases, a library like Sharp or Libvips can handle the work. However, for a film publication like PracandyFlix, the layout is fixed. We know the aspect ratios for article headers and thumbnails. Generating these sizes once ensures that the next time a user visits, the image is already in the browser cache or the local disk cache. This reduces the load on the single PostgreSQL database and the Node.js processes running on the same machine. The system remains responsive because the heavy lifting happened before the user ever requested the page.

Static Builds and Simple Infrastructure

Some of our products, like GamingCap and Invoiceful, are static builds served directly by Caddy. They have no server process and no database. For these, image optimisation is purely a matter of file preparation. You compress the assets, convert them to efficient formats, and deploy them. The simplicity of this setup means there is no room for complex image pipelines. You do not need a queue, a worker, or a CDN. You need a build script that runs reliably. If you are running a small stack on a single VPS, this method keeps the system stable and the costs low. The goal is to do the work once, store the result, and serve it quickly.