Image optimisation for websites: why photos decide your page speed
On a site made of text, styles and photographs, the photographs are the heavy part, so image handling is where page speed is won or lost. On a new build it is not an extra: it is scoped into every step from EUR 600-900 for a single-page landing upward, and fixing images on an existing site is quoted after scoping.
You can check this on your own site: open the network panel in your browser on any page and sort the downloads by size.
Why images are the heavy part
The code behind a brochure site or a small shop is text, and text compresses well on its way to the browser. Photographs are already compressed, so the server cannot shrink them further in transit, and one photo uploaded straight from a phone can outweigh all the code on the page combined.
Size on screen and size on disk are also unrelated. A phone photo has far more pixels than a laptop shows in a content column, yet the browser downloads all of them and then scales the image down. A visitor on mobile data pays for pixels they never see.
Google's Core Web Vitals make this visible. Largest Contentful Paint records when the biggest element in view finishes rendering, and on a page with a hero photo, that element is the photo. Cumulative Layout Shift records content jumping around, which is what images without reserved space cause as they arrive.
Where the weight comes from
| Problem | What a visitor notices | The fix |
|---|---|---|
| Original uploads served as they are | A slow hero and a heavy page on mobile data | Resized versions for each screen width, picked by the browser through srcset and sizes |
| Old formats only | Larger files for the same picture | AVIF or WebP, with a JPEG fallback |
| Everything loads at once | A slow start on long pages and galleries | Lazy loading for images below the first screen |
| Hero image lazy loaded | The main image appears last | The hero loads first, with priority |
| No width and height set | Text jumps while reading | Space reserved for each image in the layout |
| Logos and icons saved as photos | Soft edges on sharp screens | SVG for anything drawn rather than photographed |
| Animated GIFs and carousels | Stutter, and unseen slides still download | Muted video instead of GIFs, and one strong image instead of a carousel |
| Caching switched off | Every visit downloads the same images again | Long cache lifetimes on versioned files, served from a CDN |
The part that breaks after launch
A site can be fast on launch day and slow later, and when that happens, check the content before the code. From then on, new photos arrive through the CMS straight from a phone, and a template that trusted its launch images serves them as they are.
The fix is a pipeline instead of a rule. You upload the best original you have, and the site generates resized, converted versions on its own, so nobody on your team needs to know what AVIF is. In a Next.js build the framework's image component does this together with an image service, which is how we set up image handling in our Next.js projects.
Hosted image services bill by usage, so transformed images should be cached and reused, not regenerated on every request. Where the site and its images are hosted is agreed per project.
What it costs at each step
Image handling is part of the fixed quote for your step. What changes between steps is where the images come from and who uploads them.
| Step | Price | Image work in scope |
|---|---|---|
| 01 Single-page landing | EUR 600-900 | Hero and section images resized, converted and loaded in the right order |
| 02 Mini-site | EUR 900-1.500 | The same across 2-3 pages, with CMS uploads that resize themselves |
| 03 Business website | EUR 1.500-3.500 | A full CMS image pipeline for service pages, team photos and galleries across 4-7 pages |
| 04 Advanced site / web app | EUR 3.500-7.500 | User uploads and product images in a shop with payments, processed on upload and cached |
| 05 Custom SaaS platform | from EUR 7.500 | Image upload, storage and delivery across the platform, scoped during discovery |
For an existing site, the quote follows a look at how images reach the page. Replacing a few oversized files is a small job. A theme that serves originals everywhere needs the pipeline described above, and on an old theme that is the moment to compare fixing with rebuilding. Every step is on the packages page.
Process and timeline
Images run through the whole project, inside the timeline for your step: 1-2 weeks for a single-page landing, 2-3 weeks for a mini-site, 3-6 weeks for a business website and 6-12 weeks for an advanced site or web app.
- Scoping. Which pages carry photography, where the images come from and who uploads them after launch.
- Design. Crops are decided for phone and desktop, so a wide hero still shows its subject on a narrow screen.
- Content. You supply the best originals you have. This is the part that waits on you, and placeholders cannot stand in for it at launch.
- Build. The pipeline, formats, loading order and reserved space go in with the templates, not after them.
- Launch check. Pages are tested on a throttled mobile connection and against Core Web Vitals, and after launch the real-visitor data in Search Console is the measure that counts.
After launch, Care at EUR 100-300/mo covers updates, monitoring, backups and small fixes, and replacing an oversized file that slipped through is a small fix. A redesign or a new gallery feature is not part of Care.
When to spend less
- Do not rebuild for a few photos. If a speed test points at a few oversized images, resizing and replacing them is the fix. A new site answers a broken pipeline, not a heavy file.
- Do not chase a perfect lab score. A lab test simulates one device, while Google looks at data from real visitors. A page that shows its hero quickly and holds still is doing its job.
- Skip the paid image service on a small site. A landing page or mini-site whose images rarely change can have them prepared once at build time, with nothing running to pay for.
- Fix indexation before speed. If Google barely knows your site exists, faster images will not change that. The SEO foundation, EUR 450-750 one-off, covers Search Console, indexation and technical hygiene.
Frequently asked questions
Can a compression plugin fix this?
A plugin that compresses uploads helps, and on a simple site it can be enough. It cannot always serve the right size for each screen, reserve space in the layout or stop a hero from being lazy loaded, because those decisions live in the theme. Run a speed test after installing one and look at what it still flags.
Will optimised images improve my Google ranking?
Page experience is one signal among many, and it will not lift a page that has nothing else going for it. What faster images change for certain is what happens after the click: a visitor on a phone sees your offer instead of an empty box.
Which format should I upload?
Upload the largest, best-quality original you have, such as the JPEG from the camera or your photographer's full-size export. The site creates the AVIF or WebP versions. Pre-shrinking files yourself throws away detail the pipeline needs for sharp screens.
Does optimisation make photos look worse?
It should not be visible. Compression quality is set by eye against the original, and high-density screens get larger versions so detail holds up. Where photos carry the sale, such as a portfolio or product pages, quality can be set higher for those images alone.
Do I need a CDN for images?
Serving images from locations close to your visitors, with long cache lifetimes, is part of a well set-up site. Whether that runs through the host or an image service is agreed per project along with hosting, and neither is included unless the quote says so.
If you are planning a site that should stay fast after the first upload, tell us about it.
Building something?
JP Studio designs and builds websites, storefronts and product interfaces.