There's a genre of Reddit post I keep an eye on: "roast my website." Most replies are opinions about colors. I do something different - I open DevTools, measure, and report numbers. Yesterday I did five sites in one day, and the pattern was so consistent it's worth writing down.
Not one of the five had a framework problem. Every real issue was something the builder had stopped looking at.
Site 1: The SaaS landing page with a 1080px logo in a 28px slot
A polished Next.js landing page, 467KB total - genuinely light. But:
- The nav logo was a 1080x1080 PNG rendered at 28x28. That's ~1,500x more pixels than displayed.
- The favicon was a 48KB SVG - 10% of the entire page weight, in the tab icon.
- The load event fired at 4.4s, almost entirely because of the analytics stack: session recorder, surveys module, exception capture, plus a chat widget iframe still downloading at the 11-second mark.
That last one deserves its own sentence: the site was shipping more tooling to record visitors who don't convert than it would take to fix why they don't convert.
Site 2: The cafe page that hides itself for 30 seconds
My favorite of the day. The page finished loading in 2.9 seconds (664KB, network idle). Then a "BREWING THE RUSH... 0% FUELED" preloader sat on top of the finished page for roughly thirty more seconds, crawling to 100% on a timer.
The loader wasn't loading anything. It was a door held shut with the room ready behind it.
If you ever add a branded preloader: cap it at 1-2 seconds, and drive it from real load progress. If your page is ready in 3 seconds, the best loading animation is none.
Site 3: The joke site that beat everyone
A "roast my SaaS" gag site: 19KB total, 9 requests, loaded in 0.9s, vanilla JS. The only thing I could find to burn was a 360ms TTFB from an un-cached HTML document.
I mention it because it's the control group. No framework, no build pipeline, no optimization work - and it outperforms almost every funded SaaS landing page I've measured. Weight you never add is the only optimization that's free forever.
Site 4: The 32MB portfolio
A video production company's portfolio - the site itself is the product demo. Total transfer: 32MB. Two thumbnail JPEGs were 15.9MB each - 98% of the entire page. They were 2668x3840 exports displayed at roughly 380x680, and one of them wasn't even visible on screen; it downloaded anyway.
The fix took one sentence: re-export those two files at 800px wide, quality ~80. Page goes from 32MB to under 1MB, visually identical.
The lesson generalizes: when a page is heavy, it's almost never "everything" - it's two or three files. Sort your network tab by size before you touch anything else.
Site 5: The cinematic site where 4 files missed the pipeline
A beautifully built scroll-story site for a premium food brand: 11.2MB, load event at 15 seconds, TTFB 2.9s. Everyone in the thread was debating the scroll pacing. Nobody had opened the network tab.
The interesting part: 30 of the site's images were properly compressed WebP. Four photographic backgrounds were PNG - 7.1MB between them. The developer clearly had an image pipeline; these four files just never went through it.
That's the most common failure mode I see in real audits, and it's not a knowledge problem. It's an inventory problem. You don't need to learn image optimization - you need to notice which files skipped the process you already have.
The pattern
Five sites, five different stacks (Next.js x2, vanilla JS, a no-code builder, custom), and every substantive finding was one of these:
- A few oversized files - not systemic bloat. Two images were 98% of a 32MB page. Four PNGs were 63% of an 11MB page.
- Self-inflicted waiting - a fake preloader, an analytics pile, an un-cached HTML document. Time the visitor spends waiting on things that aren't the product.
- Assets that skipped an existing pipeline - the site already optimizes images; these specific files missed it.
None of this requires expertise to find. It requires opening the network tab, sorting by size, and believing the numbers over your memory of the site. The builders I replied to fixed most of these within a day - one cut their page by 98% overnight.
Measure before you redesign. It's usually two files.
I do this kind of audit constantly, so I packaged the checklist I use into SpeedKit for Claude Code - it walks Claude through measuring any site the way I did above and outputs the fix list.
Top comments (0)