Measure first: is it the server or the page?
A slow website is usually one of five things: a slow server response, oversized images, render-blocking scripts, no page cache, or a heavy plugin stack. Time to first byte (TTFB) separates the first cause from the rest. It measures how long the server takes to start answering, before the browser has any HTML to work with.
High TTFB means the request waited in a queue: an overloaded host, a slow database query, or PHP doing too much before it prints anything. Low TTFB with a slow finished page means the server was quick and the browser spent its time downloading and rendering images, fonts and scripts. Fix the wrong half and nothing improves.
Read these five numbers in this order
Free tools report the same handful of numbers. Read them in this order, because the first one narrows everything after it.
| Number | Good | What a bad number accuses |
|---|---|---|
| TTFB | 800 ms or less | The host, PHP, the page cache or the database |
| LCP | 2.5 s or less | The hero image, a blocking stylesheet, server response |
| INP | 200 ms or less | Long JavaScript tasks, page-builder scripts |
| CLS | 0.1 or less | Images without dimensions, ads and embeds inserted late |
| Page weight | About 1.5 MB or less | Images, fonts and third-party tags |
PageSpeed Insights shows a lab score and, when the URL has enough traffic, field data from real Chrome users. The lab score is a diagnostic. The field data is what Google uses, and it can disagree: a site can score 95 in a lab and still feel slow on a congested mobile network in India.
Check the five causes in the order that finds them fastest
Each check rules something out. Stop when one of them explains the delay, then fix that and re-measure before moving on.
- Upload a 1 KB static HTML file to the same host and open it. If it also takes a second, the server is the problem and no plugin will help.
- Read TTFB on three templates: home, a post or product, and a category. If only the search or category page is slow, the database is the suspect, not the host.
- Open the browser network panel, sort by size, and reload. Photos above 300 KB, PNG screenshots and unused font weights are the usual top three.
- Disable plugins one at a time on a staging copy, re-measuring the same page after each. Turning them all off proves nothing about which one is guilty.
- Confirm a page cache is actually serving HTML, and that its hit ratio is above 80%. A cache plugin that is installed but bypassed is common.
- Check PHP is 8.x rather than an old 7.4, autoloaded options are under about 1 MB, and post revisions and expired transients have been cleaned.
The WordPress causes, specifically
On WordPress, five faults account for most slow sites, and they overlap.
- A page builder plus thirty plugins, each loading its own CSS and JavaScript on every page.
- Photographs uploaded straight from a phone at 4000 px wide, then displayed at 800 px.
- A chat widget, two pixels and an embedded map loading before the content does.
- Two cache plugins fighting, so neither serves a cached page.
- A database carrying years of revisions, expired transients and orphaned meta rows.
None of this is exotic. The WebP conversion walkthrough fixes the second fault in an afternoon, and the cache guide covers the fourth.
When the host is the cause, and how to prove it
Hosting is the cause when the static file is slow, when TTFB stays above 800 ms from several locations, when every page on the account slows at the same moment, or when speed drops at the same hour each day because backups or cron jobs are running.
Prove it before you migrate. Measure the same three pages for a week and note TTFB at 10 am and at 8 pm. Then run the same test on a trial account elsewhere and compare. A faster host will not fix 4 MB images, and moving a slow theme to a faster server only moves the delay.
What not to do when the site feels slow
Installing three caching plugins makes things worse, because each writes its own rules. Deleting plugins at random breaks features without proving anything. Adding a CDN before compressing images moves the same payload to more places. And one lab score is not a trend.
Change one thing, measure the same page, and write the number down. If it does not move, undo the change. That habit finds the cause faster than any checklist. If the cause is page-side and you would rather not do it yourself, the WordPress speed optimization service runs this sequence and reports before and after.
Frequently Asked Questions
Why is my website slow?
Usually one of five causes: a slow server response, oversized images and fonts, render-blocking JavaScript, no page cache, or too many plugins. Measure TTFB first; it tells you whether the fault is above or below the server.
How do I know if my hosting is the problem?
Upload a 1 KB static HTML file to the same host and open it. If that file takes a second or more, TTFB is high and the server is the problem. If it loads instantly but your pages do not, the fault is in the theme, plugins or database.
What is a good TTFB?
Google treats 800 ms or less as good and anything over 1.8 seconds as poor. On an Indian connection, a well-cached page on an Indian server usually answers in 200–500 ms. Measure three templates, not only the home page.
Do images really slow a website down?
Yes. Images are the heaviest part of most pages. A phone photo can be 4 MB where 150 KB would look the same on screen. Compress, resize to the displayed width, serve WebP or AVIF, and set width and height so the layout does not jump.
Will a caching plugin fix a slow site?
Only if the delay comes from building the page on every request. Caching does little for 4 MB images, a blocking font or a 900 ms TTFB. Install one cache plugin, not three, and check that the hit ratio is above 80%.
How long does a fix take to show?
A lab test changes immediately. Field data in Search Console and PageSpeed Insights rolls over a 28-day window, so a real improvement appears gradually. Judge a fix after four weeks, not after one afternoon.