BLOG
Site Speed
You've spent months building your product. The landing page is clean, the copy is sharp,. But visitors are bouncing before they ever reach your CTA — and you can't figure out why.
Here's a likely culprit: your images.
For most web pages, images account for 50–75% of total page weight.
This isn't a minor UX inconvenience — it's a direct hit to your bottom line. Here are four engineering fixes that will stop it.
The data here is unambiguous — and it should alarm every startup founder.
According to Google, 53% of mobile users abandon a site that takes longer than 3 seconds to load. And images are almost always the reason a page crosses that threshold.
Portent research found that a site loading in 1 second converts 3x better than one loading in 5 seconds. Deloitte found that improving mobile load speed by just 0.1 seconds boosted retail conversions by 8.4%. For a startup doing $500K in annual revenue, that's $42,000 in additional revenue from a tenth of a second.
Amazon famously calculated that every 100ms of latency costs them 1% in sales. While your scale is different, the underlying psychology is identical: slow pages signal an untrustworthy, low-quality product — and users leave.
The relationship between page speed and SEO compounds this further. Google's Core Web Vitals now directly tie image performance to search rankings. Largest Contentful Paint (LCP) — which measures how long the largest visible element (usually an image) takes to render — is a confirmed ranking signal. A slow hero image doesn't just hurt conversions. It buries your organic traffic, too.
Most startup engineering teams optimize their APIs, cache database queries, and fine-tune JavaScript bundles. Images get added to the repo and forgotten. The average web page transfers over 2.5 MB of data — with images making up the largest share. A single unoptimized hero image can easily reach 3–5 MB, larger than the rest of the page combined. Images also block the critical rendering path when not handled correctly, directly delaying Largest Contentful Paint (LCP) and hurting your Core Web Vitals score.
The good news: image optimization has the highest ROI of almost any frontend performance fix. Here's how to do it right.
Here's something most early-stage teams never stop to question: where are your images actually being served from? If the answer is your origin server, that's your first problem.
A CDN for images works by copying your assets to servers distributed around the world. So when someone in Manila loads your page, they're pulling images from a node close to them — not waiting on a round trip to a data center thousands of miles away. That distance adds up fast.
The better CDNs — Cloudflare Images, Imgix, Cloudinary — do a lot more than just move files closer to users. They also handle the stuff you'd otherwise have to build yourself:
Automatically resize images to match the requesting device's screen dimensions
Convert images to next-gen formats (WebP, AVIF) on the fly based on browser support
Compress images without visible quality loss
Cache images at the edge with long TTLs, reducing origin load
Setup is genuinely low-lift. Swap your static image URLs for CDN-proxied ones, and most of the optimization happens automatically. If you're on Next.js, Nuxt, or Remix, there are native integrations already waiting for you.
The results speak for themselves — teams making this switch routinely cut image payload by 40–70% and shave 1–2 seconds off their LCP. That's not a rounding error. That's real money.
Think about what happens when someone lands on your page. They see the top — the hero, the headline, the CTA. Everything below that fold? They haven't seen it yet. But your server is already loading it. All of it.
Lazy load images fixes this by holding off on loading anything the user can't see yet. Images load as they scroll into view — not all at once on arrival. Your initial page weight drops, your above-the-fold content renders faster, and your Time to Interactive improves.
The implementation couldn't be simpler. One HTML attribute — loading="lazy" — works natively in every modern browser, no JavaScript needed:
<img src="product-shot.jpg" loading="lazy" alt="Product" />
Using Next.js? It handles this for you through the <Image> component. Need more control? The Intersection Observer API is your next stop.
Best practices for lazy load images:
Never lazy-load above-the-fold images — especially your LCP element. This is a common mistake that actually hurts Core Web Vitals
Set explicit width and height attributes on all images to eliminate Cumulative Layout Shift (CLS)
Preload your hero image using <link rel="preload"> to prioritize it in the browser's fetch queue
Get this right and you're typically looking at a 20–40% improvement in initial load time — which translates directly into fewer bounces and more users actually reaching your CTA.
Most teams are still shipping JPEGs and PNGs because that's what they've always done. It's a habit worth breaking.
Newer formats like WebP and AVIF look identical to the user but weigh dramatically less:
WebP delivers 25–35% smaller files than JPEG at equivalent quality, with broad browser support (95%+)
AVIF is even more efficient — 50% smaller than JPEG — and is now supported by all major browsers as of 2024
That 500 KB hero JPEG you've been serving? It could be 200 KB as a WebP, or 100 KB as an AVIF. Your users won't notice the difference in quality — but they'll feel the difference in speed.
How to make the switch:
Use an image CDN (see Fix #1) that auto-converts to the best supported format per browser
In HTML, use the <picture> element with multiple <source> tags to serve AVIF with WebP and JPEG fallbacks
In build pipelines, use tools like Sharp, Squoosh CLI, or ImageMagick to convert assets during CI/CD
If rebuilding your image pipeline sounds like a lot, start at the CDN level. Format conversion there is a configuration change — no code, immediate results.
You can nail the first three fixes and still have a slow page. If your server is dragging its feet, everything else waits.
Your TTFB — Time to First Byte — is how long it takes your server to respond at all. If that number is sitting above 600–800ms, the browser is just sitting there waiting. No amount of CDN magic fixes a slow response at the source.
For startupson Node.js, server-side response time is often the thing nobody's watching. The usual suspects: database queries firing on every page render, synchronous code blocking the event loop, and missing cache headers forcing repeat fetches that should have been free.
Spending time on image formats while your TTFB is 900ms is the wrong order of operations. Get the server responding fast first — then the rest of your optimizations actually land.
Here's the playbook:
Audit your current state — Use Google PageSpeed Insights or WebPageTest to identify your LCP element, image sizes, and format breakdown
Deploy a CDN for images — Start with Cloudflare or Cloudinary; the ROI is immediate
Enable lazy load images — Add loading="lazy" to all below-the-fold images today
Convert to next-gen image formats — Migrate to WebP now; prioritize AVIF for your highest-traffic pages
Audit your TTFB — Fix server-side response time before declaring victory
These aren't nice-to-haves. At the pace your competitors are shipping, performance engineering is a growth strategy.
The startups pulling ahead aren't always the ones with the best product — they're the ones with the fastest, most reliable experience. Growth engineering at PubGenius is built around exactly this principle: that technical performance and business outcomes are inseparable.
A one-second improvement in load time can be worth tens of thousands of dollars in recovered conversions. The fix is not complicated. The cost of inaction is.
October 08, 2026
