A common L3 problem at SMBs: the website is suddenly slow, or randomly slow, or has just crossed the threshold from "okay" to "noticeably bad." Customers are complaining or — more commonly — silently abandoning carts and bouncing. Your developer (if you have one) says "works for me." Your hosting provider's status page says all systems normal.
The temptation is to start changing things. "Let's switch hosting." "Let's redo the database." "Let's hire someone to rebuild the site." Each of these costs weeks and thousands of dollars. None of them are likely to fix the actual problem, because the actual problem hasn't been identified yet.
This article is the systematic diagnostic process. It's written so a non-technical SMB owner can run it without engineering help. It catches the most common causes in 80% of "suddenly slow" incidents.
Step 1: Define the slowness
Before diagnosing anything, characterise the slowness:
When did it start? Today? Last week? Has it been getting worse over months? "It started about 4 days ago" is a very different problem than "it's been getting slowly worse for 6 months."
Is it consistent or intermittent? Always slow, or sometimes slow? Slow at specific times of day? Slow only for certain users? Intermittent issues are the hardest because they're hard to reproduce.
What's slow specifically? The whole site? Specific pages (product pages, checkout, search)? Specific actions (logging in, submitting forms)? Different "slow" categories have different causes.
Slow for whom? All visitors? Visitors in specific countries? Logged-in users only? Mobile users?
Get specific. "The site is slow" gives you no diagnostic information. "Product pages take 6 seconds to load on mobile in Australia, but only 2 seconds on desktop in the US, and only since last Tuesday" gives you a starting point.
Step 2: Test from outside
Use an external service to measure your site's performance from outside your own network. This eliminates "your home internet is slow" as a cause.
Free tools:
- PageSpeed Insights — Google's tool. Tests from multiple locations. Gives you Core Web Vitals scores.
- GTmetrix — measures load time and breaks down what's slow.
- WebPageTest — most detailed. Shows the waterfall of every request.
- my SEOCheck — covers basic technical performance issues alongside SEO checks.
Run all four. Note the load time numbers. If they're consistently bad (> 3 seconds for the page to be usable), the slowness is real and visible to all users.
Step 3: Check the obvious things first
Before deep diagnosis, eliminate the common silent causes.
Is the CDN working?
If you use Cloudflare, BunnyCDN, AWS CloudFront, or similar:
- Log in to the dashboard. Is the CDN status "active"?
- Is your domain showing as "proxied" (Cloudflare specifically)?
- Has anyone disabled or paused the CDN recently?
A CDN that's been silently disabled means every request is hitting your origin server, which is much slower. This is the #1 most common "suddenly slow" cause I encounter.
Are there new third-party scripts?
Open your homepage in Chrome. Press F12 → Network tab → reload the page. Look at the list of requests. Are there new ones you don't recognise? Marketing tools, analytics tools, popup tools, chat widgets — each one that was added "just because" can add 0.5–2 seconds of load time.
Common culprits:
- A new chat widget (Intercom, Drift) loaded on every page including those that don't need it
- Multiple analytics tools running in parallel (Google Analytics + Mixpanel + Heap + a heatmap tool + a session replay tool)
- A newly-installed CRM tracking script
- A re-targeting pixel that doesn't time out properly
If any of these were added recently, that's likely the cause.
Did your hosting plan get downgraded?
Some hosting providers automatically downgrade your plan if a credit card fails or you exceed your contract terms. Log in and verify your current tier matches what you're paying for.
Are you over your traffic limits?
Cheap shared hosting throttles you when you exceed bandwidth or request limits. If your site genuinely got more popular, you might be hitting those limits. The site isn't "slow" — it's being deliberately throttled by your hosting provider.
Is something blocking your country?
If the slowness is only in specific countries, check whether your CDN or hosting provider has blocked traffic from those regions for security reasons. This can happen automatically during DDOS protection.
Step 4: Check the server itself
If the obvious things check out, look at the server.
For most SMB hosting (Vercel, Render, Heroku, DigitalOcean App Platform):
- Dashboard metrics: log in and look at CPU, memory, response time graphs for the last 7 days. Anything that started increasing recently?
- Recent deployments: was there a deploy in the last week? Did slowness start after a specific deploy? If so, check what changed in that deploy.
- Resource limits: are you hitting CPU or memory limits during peak traffic? Many hosting plans have soft limits where they throttle your application when it hits 80% of allocated resources.
For traditional VPS or dedicated server hosting:
toporhtopif you have SSH access: shows current CPU and memory usage by process- Hosting provider's monitoring dashboard: shows historical resource usage
- Server load history: most providers show 7- or 30-day graphs
Usually one of:
- CPU is constantly pegged at 100% → application is doing too much computation
- Memory is constantly near limit → application has memory leak or insufficient resources
- Disk I/O is high → database queries are slow, or logs are filling disk
- Network is constantly busy → too much external API traffic, or DDOS
The pattern points to where to dig deeper.
Step 5: Check the database
For most SMB applications, the database is the most common slow component.
Things to check:
- Database CPU utilization: in your cloud provider's dashboard, look at the database's CPU. Pegged near 100%? You have query problems.
- Database connection count: too many concurrent connections can cause queueing. Most cloud database services show this metric.
- Slow query log: most databases have a "log queries that take longer than N seconds" feature. Enable it temporarily, see which queries are slow.
- Recent schema changes: did anyone add a new table, column, or index recently? Or forget to add an index that should have been added?
The most common database issue I see at SMBs: a table that's been growing for years (orders, events, logs) hits a size where queries that used to be fast (< 100ms) become slow (multiple seconds) because there's no index supporting them. The fix is a single CREATE INDEX command and a few hours of careful application.
Step 6: Check third-party API dependencies
If your application calls third-party APIs (Stripe, Mailchimp, third-party shipping calculators, AI services), one of those APIs being slow makes your application slow.
Most SMB applications make external API calls synchronously — the user waits while your server waits for the API response. If the API is having a bad day, your site has a bad day.
Things to check:
- API status pages for every third-party service you depend on (Stripe, your email service, your payment processor, your shipping calculator).
- Application logs for "API timeout" or "external request failed" errors. If they've increased recently, that's the problem.
- Request waterfall in WebPageTest (from Step 2). Slow requests to external services show up here.
When to call for help
Most "suddenly slow" issues can be self-diagnosed through Steps 1–6. Bring in L3 help when:
- The diagnostic surfaces a database problem that requires query analysis or indexing decisions
- The diagnostic surfaces an architectural problem (caching, queue management, third-party API handling) that requires real engineering
- The slowness is intermittent and you can't catch it in the act
- You've tried the obvious fixes and the problem persists
- The cost of slowness (lost conversions, lost customers) is significant enough to justify expert help
What to bring to the L3 conversation:
- The performance numbers from external tools (PageSpeed, GTmetrix)
- Server metrics for the last 7 days
- A list of what's been tried already
- Recent changes (deployments, plugin installs, new features)
- The pattern of slowness (always vs sometimes, all users vs subset, all pages vs specific)
Without this context, the L3 person spends their first 2–3 hours doing the diagnostic you could have done yourself. With this context, they go straight to the deep work.
When the answer is "your platform is the problem"
Sometimes the diagnosis points at the platform itself. WordPress with too many plugins. Shopify with too many apps. A custom application that's outgrown shared hosting.
In these cases, the fix isn't a tweak — it's a meaningful architectural change. Either:
- Migrate to a faster platform (often the answer for WordPress with 30+ plugins)
- Move to dedicated hosting (often the answer for shared hosting that's hit limits)
- Refactor problematic parts of the application (often the answer for custom apps that scaled badly)
Each of these is a real project, not a quick fix. But they're the right answer when the platform is genuinely the problem. The diagnostic above tells you whether you're in this category or whether the issue is actually fixable in place.
What to do next
The companion articles cover related L3 problems:
- Why Your AWS Bill Keeps Going Up — performance issues sometimes correlate with cost issues
- Migrating Without Downtime — when the answer is "migrate"
- WordPress to Custom Stack Migration — when the platform is the problem and WordPress is involved
If you'd like a second pair of eyes on a slow site, the Lead Steer monthly retainer handles diagnostic work as part of ongoing L3 support.
---
Part of the Level 3 Tech Support pillar guide.