When a WordPress site feels slow (pages take several seconds, Admin drags, or phones bounce before the form appears), the site is usually still “up.” Something in the stack is adding wait time: heavy plugins, oversized images, third-party trackers and chat widgets, a cold cache, or a host that answers slowly (high TTFB). Treat this as a performance problem, not an outage.
Work this checklist in order. Prefer staging when you can reproduce the slow path there. Take a backup before mass-deactivating plugins or changing cache/host settings on production. This article is about pages that load slowly: the site loads, but too slowly. If the site is offline, times out, or returns host errors, use site down or not loading first. If you mainly need to interpret a Core Web Vitals grade, use Core Web Vitals test for WordPress. If edits save but the public page looks old, use changes not showing / cache. If one covered WordPress issue is clearly to blame and you want help, use the $99 one-time fix. We confirm the scope before work begins.
Define what “slow” means
- Note whether the pain is the public site,
/wp-admin, or both. Admin-only slowness often points at plugins or database queries; front-end-only slowness often points at images, scripts, or cache.
- Note one URL that feels slow (homepage or a paid landing page), and whether the problem is worse on mobile.
- If the page never finishes loading, returns errors, or is blank, stop and use site down.
- If you only care about what LCP/CLS/TTFB labels mean, use the Core Web Vitals test article. This checklist is about fixing a slow site after you have a measurement.
Quick triage map
| What you observe | Likely layer | First useful check |
|---|
| Front end slow; Admin fine | Images, front-end scripts, page cache, CDN | Speed test on the public URL + Network waterfalls for large images/scripts |
| Admin slow; front end OK | Plugins, queries, object cache | Test plugins in groups on staging; Query Monitor on a slow Admin screen |
| Both slow; TTFB high before HTML arrives | Connection delays, cache, or server-side work | Check redirects and request timing; compare cached and uncached responses |
| Many third-party hosts (ads, chat, pixels) | External scripts | Remove or defer unused tags; retest load time |
| Site offline / errors, not merely slow | Outage path | Site down checklist |
Safe diagnostic order
- Measure the slow task first. For a slow public page, test that exact URL with our free website speed test or another PageSpeed tool. Record when the main content appears, whether the layout shifts, and the time to first byte (TTFB). If only Admin is slow, record the affected screen and action, then use the plugin and query checks below; a public-page test does not measure your signed-in Admin session. For what Core Web Vitals labels mean, see Core Web Vitals test for WordPress.
- Separate “never loads” from “loads slowly.” Timeouts, 5xx, blank pages, and DNS failures belong on the site down path. Soft delays with a finished page stay on this checklist.
- Inspect the heaviest assets. In the browser Network panel (mobile throttle if phones are the complaint), note oversized images, render-blocking CSS/JS, and third-party scripts (pixels, tag managers, chat, A/B tools). Third-party scripts are a common drag even when WordPress itself is lean; check the network report for scripts you no longer need.
- Test plugins in groups on staging. With a backup, deactivate non-essential plugins in groups, then one at a time, retesting the same URL after each change. Note any plugin that adds global scripts on every page. Avoid leaving checkout, forms, or security plugins off on production longer than a controlled test.
- Use Query Monitor (or host slow-query tools) when Admin or uncached pages crawl. Look for slow database queries, remote HTTP calls during page render, and autoloaded options bloat. Fix or replace the plugin causing the worst query before buying a larger host plan.
- Confirm page cache and CDN behavior. Public pages that show the same content to everyone can often use page caching. Keep cart, checkout, account, and other personalized pages out of shared page caching, following your host or plugin’s guidance. Purge, retest logged out, and confirm you are not chasing a stale cache when content “looks” wrong; use changes not showing / cache if the issue is stale content rather than speed.
- Compress and resize images. Serve appropriately sized images (srcset/WebP where your stack supports it), avoid multi-MB heroes above the fold, and lazy-load below-the-fold media. Re-run the speed check after the largest image fixes.
- Trim third-party tags you do not need. Remove unused pixels, duplicate tag managers, and chat widgets on pages that do not need them. Retest script count and load time. Keep only vendors you still use for ads, analytics, or support.
- Investigate slow server responses before buying an upgrade. If the main page has a high TTFB, check redirects, connection delays, page-cache behavior, and slow PHP or database work. Ask your host to review resource limits and logs when those checks point to the server. Compressing images or removing browser scripts can improve page loading, but does not by itself diagnose the server’s response time. Upgrade only when the evidence supports it.
- Retest the same URL on mobile and desktop. Keep the durable fixes (cache rules, image settings, removed tags). Restore temporary plugin changes that were only for diagnosis. For mobile-specific conversion pain, see also WordPress site slow on mobile.
Common causes
- Too many active plugins loading CSS/JS on every page.
- Unoptimized or oversized images and background media.
- Third-party trackers, tag managers, and chat widgets.
- Missing or misconfigured page cache / CDN on public pages (or caching personalized pages that should stay dynamic).
- Slow server response (high TTFB) from redirects, connection delays, uncached PHP, or limited host resources.
- Slow Admin from heavy queries, remote API calls, or autoload bloat, without the same pain on a cached front end.
- Confusing a full outage with slowness, or chasing CWV labels without fixing the assets that create them.
When a $99 one-time fix fits
Request the $99 one-time WordPress fix if you want help on one WordPress site with a repeatable slow page or Admin task: measuring that page or task, identifying the top cause (plugins, images, third-party scripts, cache, or server response time), applying the agreed fix, and retesting load time. Paste the public URL or Admin screen, whether Admin is also slow, a speed-test link if you have one, and when it got worse. We confirm the scope before work begins. Send credentials only through the private access link provided after your request is accepted.
Full redesigns, ongoing retainer optimization, multi-site fleets, and sites that are down rather than slow are outside this offer. Use site down for outages and Core Web Vitals test for WordPress when you only need the measurement explained.
Related checks
If the same URL stays slow after image compression, testing plugins in groups, third-party tag cleanup, working page cache on public pages, and a host-confirmed server-response review, send your host the URL, speed-test results, and the start time of the regression. Suspected compromise needs a security investigation as well as performance work.