DEV Community

NOGUCHILin
NOGUCHILin

Posted on

3 patterns I keep finding when I actually measure "slow" landing pages

TL;DR

I spend a chunk of most weeks replying to "roast my website" posts with real numbers instead of opinions. This week's batch turned up the same three problems, over and over, on completely unrelated sites (a SaaS API, a kids' chore app, a local service business). If you only fix one thing on your landing page this month, it's probably one of these three.


1. The one oversized image that's secretly most of your page

Pattern: a single image — usually a logo, hero photo, or video poster — accounts for 40-90% of total page weight, because it was uploaded at its original resolution instead of resized for where it's actually displayed.

Two real examples from this week:

  • A logo displayed at 167x72px in the header, shipped at its original 2726x1177px — about 16x more pixels than anyone would ever see. It alone was 143KB of a 195KB page (73%).
  • A profile photo displayed at 56x56px, shipped at 1080x1080px. 911KB of a 2.1MB page (43%) was that one photo.

The fix is boring and doesn't require touching your framework: export images at roughly 2-3x their actual display size, not their original camera/design resolution. If you're not sure what's oversized, open DevTools -> Network, sort by size, and look at whichever request is way bigger than you'd expect for what it visually is.

// quick check in the console: rendered size vs actual file size
[...document.querySelectorAll('img')].map(i => ({
  rendered: `${i.clientWidth}x${i.clientHeight}`,
  natural: `${i.naturalWidth}x${i.naturalHeight}`,
}));
Enter fullscreen mode Exit fullscreen mode

If natural is more than ~2x rendered in either dimension, that image is a resize-before-upload candidate.


2. Lossless formats for photographic content

Related but distinct from #1: a correctly-sized image can still be bloated because it's saved as PNG when it's a photo or screenshot.

One site had a video poster frame — a UI screenshot, basically a photo — saved as a 1920x1080 PNG at 293KB (47% of the page's total weight). PNG is lossless, which is right for logos/icons/flat graphics with sharp edges, but wasteful for anything photographic. Re-exporting the same image as WebP or an optimized JPEG typically gets you 80-90% smaller with no visible difference, because you're finally using a format designed for what the image actually is.

Rule of thumb: flat graphics (logos, icons, illustrations with few colors) -> PNG or SVG. Photos, screenshots, anything with gradients/noise -> JPEG or WebP.


3. JS weight that doesn't match what the page does

The last pattern is less visual and more structural: a landing page that's mostly static content (headline, a few sections, a CTA) shipping 200-300KB of JavaScript across a dozen-plus chunks, because the framework's default code-splitting wasn't reconsidered for a page that doesn't need much client-side interactivity.

One example: 66% of a 379KB landing page was JS, split across 12+ separate chunks, for a page whose actual job is "explain what this API does in five seconds." None of that JS was doing anything wrong exactly — it's just what you get by default from a JS framework's build if nobody goes back and asks "does this page need to be this dynamic?"

Same audit also turned up a broken analytics call (503 then 404 on the tracking init) — worth checking your Network tab for red rows even when the page feels fine, because a broken analytics pixel fails silently and you just... don't get the funnel data you think you're getting.


Why this matters more than it sounds

None of these are exotic. They're the kind of thing that gets waved off as "we'll optimize later" — except later rarely comes, and in the meantime every visitor on a slow connection is paying for it in bounce rate before they've read a single word of your copy. The fix for all three is usually a few hours, not a rebuild.

If you want a free pass on your own site — no pitch, just the actual numbers — I still do this on Reddit/X most days (search "roast my landing page"). If it turns out the problem is bigger than a few images (routing, architecture, a full rebuild), that's the kind of thing I take on as paid work:

Top comments (0)