Before you touch any settings, find out which half of the load is slow: the server generating the page (TTFB) or the browser rendering it (frontend). They have completely different fixes, and guessing wrong wastes hours. Open your browser's dev tools, go to the Network tab, reload the page, and click the first document request. If Time to First Byte is under 200ms, your server is fine and the problem is in the page itself: too many requests, huge images, blocking scripts. If TTFB is 500ms or higher, the problem is upstream of the browser: your application code, your database, or your hosting.
Read the waterfall first
The Network tab waterfall is the single most useful diagnostic tool you have. Reload with cache disabled and look at the shape of the requests:
- One long bar before anything else starts - that's TTFB. The server took a while to build the HTML. Skip to the TTFB section below.
- A pile of small bars all starting late - the HTML arrived fine but the page then fetches dozens of CSS, JS, and font files, often blocking render. Look for opportunities to combine or defer them.
- A few huge bars - usually images. Check their file sizes; anything over a few hundred KB on a hero image is worth compressing or serving in a modern format like WebP or AVIF.
- Requests that don't start until late - render-blocking CSS or synchronous scripts in the
delaying everything after them.
Do this on both a fresh (uncached) load and a repeat load. A big gap between the two tells you caching isn't working the way you think it is.
TTFB: it's the app or the database, almost never the network
If TTFB is consistently high, the delay is happening before the server even starts sending HTML. That's application logic: database queries, uncached template rendering, or a slow external API call the page depends on. Check what's actually slow rather than guessing:
- Turn on error logging and look for PHP notices or warnings that indicate retries or fallback paths being hit on every request.
- If your app talks to a database, check for slow queries: missing indexes are the most common cause of a page that used to be fast and now isn't.
- Check whether the page is generating fresh output on every request when it could be cached. Static or semi-static content (a homepage, a product listing) rarely needs to hit the database live for every visitor.
- Test the same page from a different network or region. If TTFB is fine from nearby but bad from far away, that's latency, not server processing time, and points at your DNS or CDN setup rather than the app itself.
A TTFB spike that appeared suddenly, rather than one that's always been there, is also worth treating as a red flag rather than just a performance issue. Unexplained slowness combined with unusual server load can be a symptom of compromise, not just inefficiency. If you see spiking CPU with no matching traffic increase, run a scan; see scanning your website for malware for the options.
Frontend: requests, weight, and blocking
If TTFB is fast but the page still feels slow, the bottleneck is what the browser does after it gets the HTML. Common culprits, roughly in order of impact:
- Unoptimized images. This is the most common cause by far. Resize images to the dimensions they're actually displayed at, don't ship a 4000px photo into a 400px box, and use WebP or AVIF where you can.
- Render-blocking CSS and JS. Anything loaded synchronously in
delays first paint. Move non-critical scripts to load withdeferor at the end of. - Third-party scripts. Chat widgets, analytics, ad tags, and font embeds each add their own connection and execution time. Audit what's actually loading and cut anything you don't use.
- Too many requests. Dozens of separate CSS or JS files each cost a connection. Bundling reduces overhead, though HTTP/2 and HTTP/3 make this less critical than it used to be.
- Web fonts. Multiple font weights and families, loaded without
font-display: swap, can block text from rendering at all until they arrive.
Run the page through a free tool like PageSpeed Insights or WebPageTest alongside your own dev tools check. They'll flag most of the above automatically and give you a prioritized list.
Hosting vs. application: how to tell which one is actually at fault
A quick test: request a plain static HTML file or a PHP file that does nothing but echo "ok", hosted in the same account as your site. If that loads near-instantly, your hosting environment is fine and the slowness lives entirely in your application code, theme, or plugins. If even that trivial file is slow, something at the account or server level deserves a closer look, and that's worth raising with support rather than continuing to chase it in application code.
When to contact support
If you've isolated the delay to the server side (high TTFB even on a minimal test file, or CPU/resource usage that looks abnormal for your traffic), open a ticket from the portal under Support → New ticket. Include the waterfall screenshot, the TTFB numbers you measured, and what you tested. Live chat works too for a quicker first look. Either way you'll get a real person, not a script, and they can check server-side metrics you can't see from the browser.