Field notes · 2026-05-04

What I check first when a site is slow.

Five minutes with DevTools beats an hour of debate. The order I look in, in case it helps you skip the debate.

Open the site on a real phone, on real cellular, not on the office wifi. Just the home page. Watch what happens with your eyes before you open any tools.

If the page takes longer than two seconds to show anything, it's not a "small optimization" problem. It's structural.

Then, in this order:

PSI report. Paste the URL into pagespeed.web.dev. Mobile tab. Read the LCP number out loud. Anything over 2.5 seconds is where the conversation actually starts.
Network tab. Open DevTools, throttle to "Fast 3G," hard reload. Sort by size. The biggest single thing on most slow pages is one image that should have been 30 KB and is 800 KB.
Coverage tab. DevTools → Coverage. Hit reload. Anything labeled "Unused" above 60% is JavaScript or CSS the page shipped but never executed. That's the real cost of plugin sprawl — the unused code dragging the page through the cellular pipe.
Page weight. Total transfer for the home page on first load. Above 1 MB is heavy. Above 2 MB is unfit for cellular. Above 5 MB is malpractice.
Critical render path. How many requests block the first paint? Anything above three render-blocking requests is fixable with a fonts and CSS reorganization that takes an afternoon.

Five steps, fifteen minutes. After this you know whether the problem is "remove three plugins" or "rebuild the stack." That diagnosis alone is worth more than most agency proposals I've reviewed.

Michael 2026-05-04 · Athens

What I check first when a site is slow.

Read next