Your Website Is Slow and You Don't Know Why: A 10-Minute Triage Checklist

Your website feels slow. Users complain, bounce rates climb, and every "speed up your site" guide throws twenty things at you at once. Before you rewrite anything, spend ten minutes triaging. Most slow sites have one dominant cause, and this checklist finds it fast.

Minute 0–2: Measure first, guess never

Open your site in an incognito window and run a quick test with your browser's built-in tools (F12 → Network tab, throttled to "Fast 4G" if you want realistic mobile numbers) or any free speed test. Write down three numbers:

• Time to First Byte (TTFB) — how long before the server responds at all.
• Largest Contentful Paint (LCP) — when the main content appears.
• Total page weight — how many megabytes the browser downloads.

If TTFB is over 600ms, the problem is server-side: slow hosting, no caching, or a database query doing too much work. Skip the image-optimizing guides — they won't help you yet. If TTFB is fine but LCP is slow, the problem is on the page itself. That one distinction saves you hours.

Minute 2–4: Find the heavyweight

In the Network tab, sort by size. On most slow sites, the top three entries tell the whole story:

• One giant hero image. A 4MB PNG where a 200KB WebP would do. Resize it to the dimensions it actually displays at, convert it, and you just cut seconds.
• A video autoplaying in the background. Replace it with a poster image and a click-to-play button. Nobody asked for the video; everybody pays for it.
• Third-party scripts. Chat widgets, analytics, ad tags, social embeds. Each one is a separate request to a server you don't control. Disable them one at a time and re-test — the culprit usually reveals itself immediately.

A good rule of thumb: if your page downloads more than 2MB on first load, something on it doesn't need to be there yet.

Minute 4–6: Check what blocks rendering

Still slow with a light page? Look at the waterfall for render-blocking resources: CSS and JavaScript files the browser must download and process before it can paint anything.

• CSS: One big stylesheet in the <head> blocks everything. Split off the critical above-the-fold styles inline and load the rest after.
• JavaScript: Any script tag without defer or async stops the page from rendering while it downloads. Add defer to anything that doesn't need to run before the page appears.
• Web fonts: A font that loads late causes a flash of invisible text. Use font-display: swap so the fallback font shows immediately.

You don't need to understand all of this deeply — just look for long bars at the start of the waterfall and ask whether each one earns its place.

Minute 6–8: Rule out the server

If TTFB was the problem, check three server-side things:

1. Caching. Is your server sending cache headers for static assets? A returning visitor should barely download anything.
2. Compression. Brotli or gzip should be on. An uncompressed HTML file is often 3–4x larger than it needs to be.
3. Location. If your server is in Frankfurt and your users are in Singapore, physics is your bottleneck. A CDN puts copies near your visitors.

Shared hosting with a slow database is the most common version of this story. A quick test: load a plain static HTML file from the same server. If that's fast and your real pages aren't, the server hardware is fine — your application is the problem.

Minute 8–10: Write down the one fix

You now know which of these is true:

• The server is slow → fix hosting, caching, or the database.
• The page is heavy → compress the top three assets.
• Rendering is blocked → defer scripts, split CSS.
• Third parties are the problem → remove or lazy-load them.

Pick the single biggest one and fix it first. Re-run the test. If the number moves, you found it. If it doesn't, you just eliminated a suspect in ten minutes instead of a weekend.

Why triage beats optimization

Optimization guides assume you already know what's slow. Most people don't — they guess, usually wrong, and spend a day minifying files on a site whose real problem is a 4MB hero image or a database query with no index. Measure, sort by size, and let the waterfall tell you where the seconds go.

I keep a longer version of this checklist, plus hands-on troubleshooting walkthroughs for servers, networks, and everyday IT problems, on my knowledge base at TargetKB — practical notes from real incidents, written for people who have to fix things, not just read about them.