Host migration

Slow after moving from SiteGround to Cloudways

This page is part of our guide to WordPress sites that got slow after moving host. Start there for the general checks. This page covers what's specific to a move from SiteGround to Cloudways.

People post about this exact move on r/Wordpress. The site was fine on SiteGround, then felt slower in the days after moving to Cloudways. Both hosts cache WordPress well. They just do it in different ways, and the SiteGround setup doesn't carry across.

Run a free scan Talk to us
01What SiteGround was doing for you
02What Cloudways uses instead
03What to check after the move
Scroll ↓

01

What SiteGround was doing for you

SiteGround's documentation describes a server caching system called SuperCacher with several layers:

  • Dynamic Caching: full-page caching powered by NGINX, on by default for every SiteGround site, even without the plugin installed.

  • Memcached: object caching for database queries, switched on in Site Tools and then in the Speed Optimizer plugin.

  • The Speed Optimizer plugin (formerly SG Optimizer), which controls those layers and adds front-end settings.

SiteGround's docs say plainly that Dynamic Caching and its Memcached service are only available to SiteGround clients. Once the site leaves SiteGround, those layers are gone. Speed Optimizer can still do file-based caching elsewhere, but its server features have nothing to connect to.

02

What Cloudways uses instead

According to the Cloudways help centre:

  • Varnish comes pre-installed on Cloudways servers as a server-side page cache.
  • Breeze is their caching plugin. It comes preconfigured to work with Varnish and purges the Varnish cache when you publish or update content. Without Breeze or a similar plugin, Varnish doesn't know when content changes and keeps serving the cached page until its TTL runs out.
  • Redis is enabled by default on new servers and powers object caching through the Object Cache Pro plugin. On older servers you may need to switch Redis on in Manage Services.
  • Memcached is also listed as a service you can manage.

03

What to check after the move

  1. Deactivate Speed Optimizer. It was built for SiteGround's servers. Running it alongside Breeze means two plugins trying to manage caching and front-end settings.

  2. Clear out leftover cache settings. Look in .htaccess and wp-config.php for rules or constants the old setup added, and remove anything that refers to SiteGround's cache.

  3. Set up Breeze and confirm Varnish is running. Check in the Cloudways panel that Varnish is enabled, then check the response headers of a logged-out page load to see whether it's cached.

  4. Turn on object caching. Make sure Redis is enabled and Object Cache Pro is active. If there's an old object-cache.php drop-in in wp-content from the Memcached setup, it may be trying to reach a server that doesn't exist.

  5. Compare PHP versions. Check which PHP version the new Cloudways server is running and make sure it matches what the site ran before and what your plugins support.

  6. Check the server location. Cloudways lets you choose the cloud provider and region. If your visitors are in one country and the server sits far away, uncached requests will be slower.

  7. Check DNS and the CDN. Make sure the domain points to the new server and that any CDN in front isn't still using the old origin.

Related

Free scan

Get a free scan

A free CrawlCare scan gives you an outside view of your site after a move. If you'd rather a developer looked at the caching setup directly, have a chat with us.

Talk to us