Independent comparison · no paid rankings
Home / Blog / Why a WordPress site stays slow after changing hosts
Guide

Why a WordPress site stays slow after changing hosts

Changing host rarely fixes a poorly optimised WordPress site. Slowness often comes from theme, plugins, database or cache — not just the server.

3 min read Updated Jul 19, 2026

Migration went well. SSL OK, DNS propagated, responsive support. Yet the site still loads in four seconds — sometimes worse than before. Temptation is to blame the new host. Often the server does exactly what you ask: serve a heavy WordPress, without coherent cache, with a database growing for years.

Changing hosting moves the problem. It does not fix it if application debt travels with the files.

Most frequent post-migration causes

SymptomLikely causeWhere to act
High TTFB (> 600 ms)Slow PHP, SQL queries, no page cacheDatabase, plugins, server cache
Heavy page (> 3 MB)Uncompressed images, fonts, scriptsTheme, media, CDN
Admin slowness onlyBackend plugins, heartbeat, autoloadPlugins, wp-config
Geographic slownessNo CDN, distant datacenterCDN, region
Random spikesCron, backups, security scanScheduling, off-peak hours

Faster host without diagnosis is a new address for the same overloaded engine.

Diagnostic checklist in useful order

Measure properly with WebPageTest, Lighthouse or GTmetrix. Check cache: does new host offer server cache? Is your plugin compatible? Audit plugins in staging. Inspect database: large autoload, expired transients, unlimited revisions. Move to PHP 8.1+ if compatible.

What new host changes — and what it does not

CPU/RAM help if old shared hosting was saturated. Integrated edge cache helps if enabled. Page builder theme, forty active plugins, 4000 px images: no — they travel with migration.

Classic errors: old host cache plugin misconfigured, Redis not enabled though offer includes it, database imported without cleanup. Each adds latency that no datacenter move alone will fix.

The peak: migration reveals debt, does not create it

Teams sometimes buy premium VPS instead of plugin audit. VPS helps — if someone cleans autoload, configures object cache and lightens theme. Schedule a quarterly review of plugin count and deactivate anything without clear business owner.

Decide and move forward without blind spots

Measure TTFB and page weight before and after migration. Configure one coherent page cache layer. Clean autoload and transients in staging first. Reduce plugins to business essentials. Add CDN if audience far from datacenter.

Reduce plugins to business essentials — marketing, chat and popup stacks often add more JavaScript than value. Add CDN if audience sits far from datacenter; European shoppers abroad feel database latency more than locals do.

Compare WordPress hosts via directory and Managed WordPress.

Frequently asked questions

How long after migration to judge performance?

Wait for stable DNS and cache. If after forty-eight hours TTFB stays high without traffic, look at application and configuration.

Can faster host compensate for ten heavy plugins?

Not sustainably. CPU masks debt temporarily, then SQL queries and frontend scripts take over.

Enable all available caches?

No. Coherent strategy beats stacked caches creating conflicts and stale content.

How to know if database is the cause?

Watch slow queries, large autoload (> 1 MB), uncleaned transients — they slow every page.


Changing host without WordPress audit is moving a cluttered attic into a newer garage. The garage is better — so is the clutter.

Compare European hosts

Filter by compliance, location and use case — then open the sheets to verify the real scope.

Browse the directory
Blog

Related reading

All articles →