The Tab They Closed Before Your Page Loaded

We moved this whole site to the edge and never told you why — Today’s drill is the same audit I ran on this operation last month, right down to the tool. Pulled the network off one tired server and onto Cloudflare’s edge, then went through every image and script asking if it earned its spot. Same voice, same words, none of it waiting on a slow origin server on the other side of the country anymore. Here’s what actually changed.

Clarity Counts by A.R. Hampton — A short, sharp guide to cutting the clutter out of your own sentences, no grammar-school lecture attached. Same instinct as today’s drill: find the one thing dragging the page down, then cut it. (Affiliate link, the building takes a cut.)

The Ten-Minute Speed Audit

Miss 2.5 seconds on mobile and the reader’s already gone before the page finishes painting.

Morning, fam. You’ve read the page-speed think-pieces, sure, but have you actually run the test on YOUR page this week, with real numbers instead of a vibe? Didn’t think so. (I know, I know, sounds like homework. Stick with me anyway.) Ten minutes, one free tool. You don’t need to touch a line of code to find the problem. Here’s the drill.

1 // Run the real test, not your gut

Skip your own eyeballs, they lie. Go to pagespeed.web.dev, paste in your homepage and whatever page makes you money, best post or product page, doesn’t matter. Read it on mobile first, that’s the score your real traffic hits, not the desktop one sitting pretty on your dev monitor.

2 // Find the ONE thing dragging

Scroll to Opportunities and ignore anything under half a second, that’s noise. Circle the single biggest number on the list. That’s your whole job today, not the entire report. Nine times out of ten on a one-person site it’s an oversized hero image or a font file loading before anything else can.

3 // Fix that one thing, nothing else

Oversized image? Compress it and set the width and height so the page stops jumping while it loads. That jump has a name, CLS, and it’s why your buy button moves right as somebody clicks it. A slow font gets font-display: swap, or you stop loading four weights you never use in the first place. And that tracking script you forgot was even sitting there? Delete the damn thing!

4 // Re-run it and prove the fix worked

Same tool, same two URLs. Put the before and after load time side by side. Number didn’t move? You fixed the wrong thing. Go back, circle the next biggest offender, try again.

Standard: under 2.5 seconds to load on mobile is a pass. Anything past that, you’ve still got homework.

Run the test tonight. Whatever you find, ship the fix before lunch tomorrow.

THE TIP. Half the reason you had a fix to make today is some builder reached for a bloated framework by default, before anybody needed one. A font kit nobody chose. A tracker nobody asked for, sitting there eating milliseconds for free. (We ran this same audit on this network last month and gutted half our own scripts, it was a pain in the ass.) Static HTML skips the pile-up. Nothing extra is bolted onto the page waiting to slow it down. Publishing From a Static Site (free guide)

DEAD AIR · SERVER ACCESS LOG / LOAD TIMESTAMP

The access log times every request to the millisecond, same as it’s supposed to. One page on this site has loaded in negative time twice this month, the response timestamp printed before the request timestamp, four seconds apart both times, same page, no pattern to the hour. The hosting panel calls it clock drift and moves on. Clock drift doesn’t run on just one page. This one does, and nobody’s explained why.

Reply with your before and after load time, I want real numbers off real sites, not just mine. ~ J.D.