GUIDE

Why is my WordPress site slow? What to check before buying more hosting

· 5 min read

“The site feels slow” is where most performance projects start, and it is not enough to act on. Slow at what? For whom? A homepage that renders in six seconds and a checkout that hangs are different problems with different fixes. Hosts are happy to sell a bigger plan either way, and half the time the bigger plan changes nothing because the bottleneck was never the server. Here is the diagnostic order we use before recommending anyone spend money.

Quick answer: Measure first. Run PageSpeed Insights and note whether the delay is server response or page rendering. Slow response points to hosting, caching, or a heavy plugin. Slow rendering points to images, the theme, and scripts. Most sites get meaningfully faster with page caching, image compression, and removing two or three plugins.

How do I measure what slow means?

Run your key pages, home, a product or service page, the contact page, through PageSpeed Insights. Two numbers tell you where to look. Time to first byte (TTFB) is how long the server takes to start answering: high TTFB is a server-side problem. Largest Contentful Paint (LCP) is when the main content finishes appearing: a high LCP with a fine TTFB is a front-end problem, images and scripts. Check the field data at the top of the report when available, because that reflects real visitors rather than one lab test.

What causes slow server response?

  • No page caching, so WordPress rebuilds every page from PHP and the database for every visitor.
  • Overloaded shared hosting, where hundreds of sites share the resources yours needs.
  • A plugin doing expensive work on every request: some security scanners, related-post generators, and anything calling external APIs during page load.
  • A bloated database, especially autoloaded options left behind by deleted plugins.
  • An outdated PHP version. Each major PHP release runs WordPress noticeably faster.

What causes slow rendering?

  • Images uploaded at camera resolution and displayed at a fraction of it. This is the single most common finding.
  • Script weight: every marketing pixel, chat widget, and slider adds JavaScript the phone must download and run.
  • Page builder output. Builders like Elementor add markup and assets, which is manageable with restraint and caching, and heavy when stacked with addon packs.
  • Fonts loaded in five weights from two services.
  • Autoplaying video or carousels above the fold.

What can I fix myself today?

  1. Install a caching plugin and enable page caching. On decent hosting this alone can halve load times.
  2. Compress and resize images with an optimization plugin, and set it to handle new uploads automatically.
  3. Deactivate and delete plugins the site does not use. Then look hard at the ones it barely uses.
  4. Ask your host to move you to the current PHP version, after checking the site on staging.
  5. Turn on lazy loading for images and remove autoplay media from the top of pages.

When is hosting the real problem?

When TTFB stays high with caching active, when the site slows at predictable busy hours, or when your traffic has plainly outgrown a starter plan. The test is comparative: put a copy of the site on a better host’s trial and measure the same pages. If a cached page still takes over a second to start responding on current hosting, the server is earning the blame. Moving a WooCommerce store off bargain shared hosting is often the highest-value change available, but it is the conclusion of the diagnosis, not the starting assumption.

Why did the site get slower over time?

Because sites accrete. Every year adds plugins nobody removed, tracking scripts marketing asked for, a media library of full-size photos, and database tables from tools long deleted. No single addition felt slow. The sum is. An annual cleanup pass, remove, compress, update, catches it before visitors do.

What if you want it handled?

Performance work is measurable, which is why we like it: before and after numbers on the same pages, and the changes documented. If the checks above did not move the site or you would rather not run them, reach out through the contact form with your domain and where it feels slow, and we will take a look.

Frequently asked questions

Does Elementor make sites slow?

It adds weight, and a well-built Elementor site with caching and optimized images still loads fast. The slow ones usually combine a heavy theme, several addon packs, and unoptimized media. The builder is a factor, and rarely the whole story.

How many plugins is too many?

Count is the wrong measure. Twenty small single-purpose plugins can outperform five heavy ones. What matters is what each does on every page load. Audit by asking what happens if a plugin is removed, and remove the ones without a good answer.

Will a CDN fix a slow site?

It speeds up asset delivery, especially for visitors far from your server, and takes load off the origin. It does not fix slow PHP, database bloat, or an overloaded host. A CDN belongs in the stack after caching works, and it is a complement rather than a cure.

What is a good TTFB?

Under about 600 milliseconds in field data is acceptable, and cached pages on solid hosting commonly answer in under 200. If your TTFB sits above a second with caching enabled, focus on hosting and server-side causes.

Do PageSpeed scores affect Google rankings?

Core Web Vitals are a real but modest ranking input. The stronger reason to care is visitors: slow pages lose them before content appears, which costs conversions directly and depresses the engagement signals rankings do respond to.

Is upgrading PHP safe?

Usually, and worth it, since newer PHP versions run WordPress measurably faster. Test on a staging copy first, because very old plugins and themes can break on a major PHP jump. Your host’s control panel typically makes the switch reversible.