How to Make Cloudways Faster for WordPress

Cloudways is already one of the faster managed hosting platforms available, but there is real headroom to push WordPress performance further. For every second your page takes to load you lose roughly 7% of potential conversions, so getting your site as fast as possible has a direct impact on revenue.

Below are practical steps you can take to improve Cloudways WordPress speed, from quick wins like cache activation to longer-term moves like server upgrades. Start by measuring your current speed to have a baseline for comparison after each change.

Measure Your Speed Before You Start

Before making changes, record your current performance numbers. Two free tools cover the most important metrics:

• GTmetrix - Run a test from a server location near your main audience. Record the Time to First Byte (TTFB), Largest Contentful Paint (LCP), and Total Blocking Time. GTmetrix shows a waterfall view that makes it easy to spot which requests are the slowest.
• Google PageSpeed Insights - Tests both mobile and desktop. Provides Core Web Vitals data from real Chrome users if your site gets enough traffic, plus lab data otherwise. Focus on LCP and TTFB under the Diagnostics section.

GTmetrix: The Right Way to Configure a Test

GTmetrix defaults to a Canadian test server, which skews results for sites with mostly US or European visitors. Before running your baseline, click the gear icon on the test page and switch the test location to the city nearest your largest audience segment. Also set the browser to Chrome (desktop) and connection speed to "Unthrottled" for a consistent baseline you can reproduce later. Save a PDF of the waterfall after each major change so you have a record of what shifted and by how much.

Google PageSpeed Insights vs GTmetrix: Which to Trust

Both tools measure the same page but produce different numbers, which confuses a lot of site owners. PageSpeed Insights shows real-user data from the Chrome User Experience Report (CrUX) when available, meaning the scores reflect actual visitors on real devices and network conditions. GTmetrix shows lab data from a controlled environment. For diagnosing server configuration (like TTFB and cache headers), GTmetrix is more useful because the test conditions are consistent. For understanding whether real visitors have a good experience, PageSpeed Insights is more accurate. Use GTmetrix to verify that your changes are working; use PageSpeed to track real-world Core Web Vitals over time.

TTFB Benchmarks: What Are Good Numbers on Cloudways?

Write down your TTFB before any changes. A well-configured Cloudways site with Varnish active typically delivers TTFB under 200 ms for cached pages and under 600 ms for uncached PHP requests. Here is how to read your numbers:

• Under 200 ms TTFB: Varnish is working and your server is properly tuned. Focus on LCP and asset optimization instead.
• 200 to 600 ms TTFB: PHP is processing the request. Enable Varnish, check PHP version, and look for slow database queries.
• Over 600 ms TTFB: A server-level problem. The bottleneck is likely insufficient RAM/CPU, a slow database query, or a misconfigured plugin.
• Over 1 second TTFB: Server resources are probably exhausted. Check CPU and RAM graphs in the Cloudways panel before doing anything else.

Retest with the same tool and location after each step so the comparison is consistent.

Choose a Better Cloud Provider and Server Location

Cloudways lets you deploy servers on DigitalOcean, Vultr, Linode (Akamai), AWS, and Google Cloud. Not all of these perform equally for every use case. DigitalOcean and Vultr are consistently fast for most WordPress sites and come at a lower price point. AWS and Google Cloud offer more headroom for high-traffic applications but cost more per gigabyte of bandwidth.

Beyond the provider, server location matters just as much. If most of your visitors are in the UK, a server in London or Amsterdam will cut latency compared to one in New York or Dallas. Log in to Cloudways, check your analytics for where traffic originates, and make sure your server region matches. See our guide on why cloud hosting outperforms shared hosting for more on how infrastructure choices affect speed.

Provider Speed Comparison for WordPress Sites

Independent benchmarks consistently place DigitalOcean and Vultr as the fastest providers for low-to-mid traffic WordPress sites on Cloudways. Both offer NVMe SSD storage on their current-generation droplets, which cuts disk I/O compared to SATA-based instances. Vultr High Frequency instances in particular offer higher single-core clock speeds, which benefits PHP processing since WordPress is largely single-threaded. AWS and Google Cloud are more suitable when you need specific regions not covered by DigitalOcean/Vultr, advanced networking features, or compliance requirements. The performance difference between providers narrows significantly once Varnish is enabled, because cached pages never touch PHP regardless of provider.

How to Check Where Your Traffic Comes From

In Google Analytics 4, go to Reports, then User Attributes, then Demographic Details. Switch the primary dimension to Country or City. In Google Search Console, go to Performance, click the Queries tab, then switch to Pages and filter by your highest-traffic posts. GSC does not show geographic data directly, but GA4 combined with your top-performing URLs gives you a clear picture of which countries drive most of your organic traffic. Once you know your top two or three countries, check the Cloudways server region list for the nearest available data center to each.

Increase Server Resources

Cloudways makes it straightforward to scale CPU, RAM, storage, and bandwidth without any server migration. If your site is growing or you are running WooCommerce, the default starter plan can become a bottleneck.

To scale up, log in to Cloudways and go to Servers, select your server, open Server Management, then click Vertical Scaling. Move the slider to the right to increase resources. You will see the revised monthly cost update in real time. Click Scale Now when you are happy with the selection. The process takes a few minutes and requires a brief restart.

Signs You Need to Scale vs Signs You Need to Optimize

Scaling your server costs money every month, so it is worth ruling out configuration problems first. These patterns suggest a configuration fix will solve the problem without scaling:

• TTFB is high but CPU and RAM graphs show plenty of headroom (under 40% sustained usage)
• Speed is slow on specific pages only, not site-wide
• Performance dropped after installing a new plugin or theme
• Query Monitor shows one or two queries taking over 500 ms

These patterns suggest scaling is the right move:

• CPU sits above 70% consistently during normal traffic (not a traffic spike)
• RAM usage is consistently above 85%
• TTFB is high even on cached pages (Varnish is active but the server is too loaded to respond to Varnish requests quickly)
• The site slows down as traffic increases, not just at specific times

For a full walkthrough, see our guide on how to scale a Cloudways server.

RAM vs CPU: Which Bottleneck Hits First

On a standard WordPress blog, RAM is usually the first resource to run out. PHP-FPM workers each consume roughly 30 to 60 MB of RAM, and a 1 GB server running multiple applications can exhaust available memory quickly. On WooCommerce sites with many product variations or session-heavy traffic, CPU becomes the bottleneck instead, because each request involves more complex PHP processing. A good rule of thumb: check your Cloudways graphs at peak traffic time. If RAM is above 85% and CPU is under 50%, add RAM. If CPU is above 70% and RAM is comfortable, add CPU. If both are high, move to the next plan tier entirely rather than trying to tune individual resources.

Update PHP Version

Running WordPress on an outdated PHP version is one of the easiest performance problems to fix. PHP 8.1 and 8.2 are significantly faster than PHP 7.4, and the difference in real-world page generation time is measurable.

To update, go to Servers > Server Management > Settings & Packages > Packages, then select the latest stable PHP version from the dropdown. Before making the change, check your application logs for PHP deprecation warnings. If your theme or plugins use deprecated functions, a PHP upgrade can cause errors. Test on a staging clone first if you are not sure.

Check That OPcache Is Active

Cloudways runs PHP-FPM with OPcache enabled by default, but it is worth confirming OPcache is actually working on your installation. OPcache stores compiled PHP scripts in memory so they do not need to be parsed on every request, which cuts PHP execution time by 30-50% on a typical WordPress site.

To check, install the OPcache Manager plugin by Louis Cuny from the WordPress plugin directory. It shows whether OPcache is active, the hit rate (aim for above 90%), and memory usage. If OPcache is not active or the hit rate is low, contact Cloudways support as any misconfiguration is on the server side rather than something you can fix from the WordPress dashboard.

PHP-FPM Workers: How Many Does Cloudways Assign?

Cloudways sets PHP-FPM's pm.max_children automatically based on your server's RAM. The formula is roughly:

max_children = (RAM_MB - 256) / 40

Where 256 MB is reserved for system overhead and 40 MB is a typical worker memory footprint. That gives:

• 1 GB server: (1024 - 256) / 40 = approximately 19 workers
• 2 GB server: approximately 44 workers
• 4 GB server: approximately 94 workers

If your site runs WooCommerce with many product variations or heavy custom post type queries, the real footprint per worker can be 60 to 80 MB rather than 40 MB, which reduces the effective concurrency. You cannot edit PHP-FPM configuration directly on Cloudways, but knowing this formula helps you understand when adding RAM actually increases throughput (when workers are the bottleneck) versus when it does not (when the bottleneck is a slow query or a bloated plugin).

Update MariaDB Version

Cloudways uses MariaDB rather than MySQL. MariaDB is faster for read-heavy workloads and is generally the better choice for WordPress sites. For compatibility reasons, your server may be running an older version.

You can update it from the same Settings & Packages > Packages screen where PHP versions appear. The MariaDB dropdown sits directly below the PHP selection. Updating to the latest stable version reduces query execution time and improves overall throughput, particularly on sites with large post counts or complex custom queries.

How to Identify Slow Queries Before Updating

Before updating MariaDB, it is worth knowing which queries are already slow, because a version upgrade will not fix a query that is slow due to a missing index or a poorly written plugin. The fastest way to identify slow queries on Cloudways is with the Query Monitor plugin. Install it, then load the pages that feel slowest in your browser. Query Monitor shows every database query that ran during the page load, how long each took, and which plugin or function triggered it.

Look for queries over 100 ms. If you see the same query running 50 or 100 times per page load, that is a WordPress transient problem (Redis will fix it, covered below). If you see one query taking 500 ms or more, that usually points to a missing database index or a plugin doing a full table scan. Updating MariaDB will improve the server's general query throughput but will not fix structural query problems. Diagnose first, then update.

Enable Varnish Cache on Cloudways

Varnish is Cloudways' built-in full-page cache. When Varnish is active, it stores a complete copy of each rendered page and serves it directly from memory on repeat visits, bypassing PHP and the database entirely. This is the single biggest speed gain available on Cloudways for most WordPress sites.

To enable Varnish, go to Applications, select your WordPress application, then open Application Management > Application Settings. Toggle Varnish Cache to On. You do not need a third-party plugin for this; it runs at the server level.

It is worth understanding how Varnish differs from Redis. Varnish is a page cache: it serves entire HTML pages without touching PHP or the database. Redis is an object cache: it stores the results of database queries in memory so PHP does not have to run the same queries repeatedly. Both can be active at the same time, and they complement each other. Varnish handles anonymous visitors at high speed; Redis speeds up logged-in requests and complex pages that Varnish cannot cache.

How to Confirm Varnish Is Serving Cached Pages

Run curl -I https://yoursite.com from a terminal and look for the X-Cache header in the response. A result of X-Cache: HIT from <server> confirms Varnish served the page from cache. X-Cache: MISS means PHP processed the request, either because it was a first visit or because a cookie bypassed the cache.

If you never see a HIT, the most common causes are:

1. A session cookie set by a plugin, which prevents Varnish from caching the response
2. Breeze is not installed or has not been configured to work with Varnish
3. The page is on the Breeze exclusion list

You can also verify in Cloudways under Server Management > Settings: the "Purge Cache" button only appears when Varnish is actually active on that server.

Varnish Grace Period: How It Handles Server Restarts

Cloudways configures a Varnish grace period of 2 hours by default. This means that if your origin server goes down during a restart or a PHP crash, Varnish continues serving the last-cached version of pages for up to 2 hours rather than returning 503 errors to visitors.

In practice, during a PHP update or server restart, your site stays visibly fast to most visitors because cached pages serve instantly from Varnish memory. Once the origin recovers, Varnish automatically validates and updates its cache. For a site with significant traffic, this grace period is one of the underrated stability benefits of using Varnish, not just a speed feature.

WooCommerce Cache Exclusions for Varnish

Varnish and WooCommerce require a specific exclusion list. Cart, checkout, and my-account pages must never be cached at the full-page level, because full-page caching of those pages causes visitors to see each other's cart contents.

Breeze handles this automatically for standard WooCommerce URLs (/cart/, /checkout/, /my-account/). But if you have a custom checkout URL or a membership plugin that creates account pages under a different path, you need to add those paths manually to the Varnish exclusion list in Breeze under Advanced > Exclude URLs. Failing to do this on a site with custom account paths is one of the most common WooCommerce caching bugs, and it is not immediately obvious because it only affects logged-in users.

Install Redis Object Cache

Redis reduces database load by storing query results in memory. On a busy WordPress site, the same database queries run hundreds of times per minute. Redis means those queries only run once; every subsequent request pulls from memory instead.

To install Redis on Cloudways, go to Servers > Server Management > Packages and enable Redis from the list. Once it is installed at the server level, you need to activate it inside WordPress. Install the Redis Object Cache plugin (by Till Kruss), then go to Settings > Redis in your WordPress dashboard and click Enable Object Cache. The plugin will confirm whether the connection to the Redis server is active.

Redis is reversible. If you notice any unexpected behaviour after enabling it, you can disable the plugin and remove the package from the Cloudways panel.

Redis vs WordPress Transients

WordPress transients are temporary data stored in the database. When you activate Redis Object Cache, WordPress shifts transient storage from the database to Redis memory. On a content-heavy site with many plugins, the database can accumulate tens of thousands of transient rows over time, and each transient read or write adds a database query to every page load.

Redis eliminates that overhead entirely. Transients that would have caused repeated database writes now live in memory and expire cleanly. Before enabling Redis, run the following WP-CLI command on a Cloudways SSH session to see how many transients your site currently holds (you will need your Cloudways application folder name for the full --path flag if running WP-CLI outside the WordPress root):

wp transient list --allow-root

If the count is in the thousands, Redis will have a measurable impact from day one. If the count is low (under a few hundred), other optimizations will deliver bigger gains first.

Redis Memory Sizing for WordPress

Redis has no memory limit configured by default on Cloudways, which means it can use all available server RAM if left unchecked. For a standard WordPress or WooCommerce site, 64 to 128 MB of Redis memory is enough to cache the full object set.

If you add Redis to a 1 GB server, set a memory cap through the Redis plugin settings or by requesting a configuration change from Cloudways support. The eviction policy Cloudways uses is allkeys-lru (least-recently-used), which automatically evicts older cached objects when memory fills up. This is safe for WordPress, but it does mean a sudden burst of new content can push frequently-accessed objects out of the cache until traffic normalizes. On sites with large content libraries, 128 MB is a safer starting point than 64 MB.

Install a CDN and the Breeze Caching Plugin

A content delivery network (CDN) stores static assets like images, CSS, and JavaScript files on servers around the world. When a visitor loads your site, those assets are served from the nearest CDN node rather than your origin server, which cuts load times for visitors who are geographically distant from your server.

Cloudways has its own built-in CDN, available from Application Management > CDN. It is powered by StackPath and costs $0.06 per GB of bandwidth. For a low-traffic site, the monthly cost is minimal and it is the easiest option to activate.

If you prefer a free alternative, Cloudflare with Cloudways adds CDN caching and DDoS protection in one step at no cost. The trade-off is that configuration is more involved.

For the caching plugin, Breeze is the right choice for Cloudways users. It is developed by Cloudways, is free, and is designed to work in tandem with Varnish. Breeze handles browser caching, minification of CSS and JavaScript, and Gzip compression. The Breeze + Varnish combination is the recommended default setup for any WordPress site on Cloudways. Install Breeze from the WordPress plugin directory, then go to Settings > Breeze and enable the options that match your setup. If Varnish is active, Breeze will also send cache purge signals to Varnish when you update a post.

If you are on Kinsta rather than Cloudways, see our guide on how Kinsta handles CDN at the hosting level through its built-in Cloudflare integration.

Cloudways CDN vs Cloudflare: When to Use Each

The Cloudways CDN (StackPath) and Cloudflare serve different purposes, and the right choice depends on what you need:

• Use the Cloudways CDN when you want the simplest setup with no DNS changes. It activates from inside the Cloudways panel, takes about 5 minutes to configure, and costs a predictable amount per GB. It handles static asset caching only, not full-page caching.
• Use Cloudflare when you want free CDN coverage, DDoS protection, and the option to enable Cloudflare's proxy (which hides your origin IP and adds a layer of security). Cloudflare's free tier includes unlimited bandwidth. The trade-off is that you need to change your nameservers or add a CNAME, and misconfiguring Cloudflare caching on top of Varnish can cause double-caching issues.
• Use both (Cloudways CDN for assets, Cloudflare for DNS/security) when you need origin IP protection and want asset delivery from Cloudflare's larger network. Set Cloudflare to "DNS only" mode to avoid proxy conflicts with Varnish.

Breeze Configuration: The Settings That Actually Matter

Breeze has many settings, but three have the biggest performance impact:

1. Enable Cache: Turns on browser caching headers. Keep this on at all times.
2. Minify HTML: Strips whitespace from HTML output. The benefit is small (1 to 3%) but consistent across all pages.
3. Minify CSS/JS: Combines and minifies stylesheets and scripts. This setting can break plugins that load scripts conditionally. Enable it on a staging site first, then check each page type carefully before pushing to production.

Under Advanced settings, the Gzip toggle compresses responses before they leave the server, reducing bandwidth by 60 to 80% for HTML and CSS. This is the single highest-impact toggle in Breeze after enabling Varnish and the page cache. If your hosting provider does not have Gzip enabled at the server level (Cloudways does by default), enabling it in Breeze ensures it is on regardless.

Optimize Images on Cloudways

Images are frequently the largest assets on a page and the biggest contributor to slow Core Web Vitals scores, particularly Largest Contentful Paint (LCP). Unoptimized images on Cloudways will drag down performance regardless of how well everything else is configured.

The most practical approach is to install an image optimization plugin on WordPress. Two well-regarded options are ShortPixel and Imagify. Both can bulk-compress your existing image library and automatically compress new uploads. More importantly, both convert images to WebP format, which is 25 to 35% smaller than JPEG or PNG at equivalent visual quality. WebP is now supported by all major browsers and is one of the fastest ways to improve your LCP score.

Choosing Between ShortPixel and Imagify

Both plugins produce similar output quality, but they differ in pricing and approach:

• ShortPixel charges per image optimized, with a free allowance of 100 images per month and credit packs starting from around $9 for 10,000 images. It stores the original files locally and lets you restore uncompressed versions if needed. ShortPixel's lossy compression is among the most aggressive available without visible quality loss.
• Imagify uses a monthly quota model with a free tier (25 MB per month) and paid plans. It integrates tightly with WP Rocket (same company) if you use that plugin. Imagify's interface is slightly simpler for bulk processing large libraries.

For a new site or a site with under 1,000 images, either works well. For large existing libraries, ShortPixel's credit pack pricing is usually more cost-effective. Both support WebP conversion, lazy loading via the plugin itself, and automatic compression on upload.

Lazy Loading: When It Helps and When It Hurts LCP

Lazy loading delays image loading until the image is about to enter the viewport, which reduces the initial page weight and speeds up perceived load time. WordPress enables lazy loading natively on all images since version 5.5 by adding loading="lazy" to image tags.

The problem is when lazy loading is applied to the LCP image, which is usually the largest visible image above the fold. If the hero image or featured image at the top of your post has loading="lazy" applied, Google measures a delayed LCP and penalizes the score. To fix this, either remove the lazy attribute from your hero/featured image in the theme template, or use a plugin like Perfmatters that lets you exclude specific images from lazy loading. For any image that appears in the top half of the page on desktop, remove lazy loading. Apply it only to images that start below the fold.

Additional steps that help:

• Set image dimensions in HTML so the browser can reserve space before the image loads (reduces Cumulative Layout Shift)
• Avoid uploading images wider than 1200px for standard content areas

Check Your WordPress Theme and Plugins

Server configuration and caching can only do so much. If your WordPress theme loads 15 external scripts or you have 40 active plugins, performance will suffer regardless of your server plan.

Start with your plugin list. Deactivate plugins one at a time and test load time after each deactivation to identify which ones have a measurable impact. Page builder plugins, slider plugins, and some contact form plugins are common culprits. If a plugin is not actively used, remove it.

Using Query Monitor to Find Slow Database Queries

For diagnosing slow database queries, Query Monitor is the tool to use. It shows you which queries are running on each page load, how long each takes, and which plugin or theme component triggered it. If a single query is taking more than 100 ms, that is worth investigating. Before changing server settings, reviewing your application logs alongside Query Monitor data gives you the full picture.

Common patterns to look for in Query Monitor:

• Duplicate queries: The same query running 20 or more times per page load. This is almost always a plugin that is not caching its own results. Redis will solve it.
• Slow meta queries: Queries against wp_postmeta with no index match. These appear in Query Monitor as taking 200 ms or more and often involve meta_key lookups across large post sets. A plugin like WP Query Monitor or a direct database index can help.
• Missing object cache: If the same query appears in the "Not Cached" section of Query Monitor, it means no caching layer is intercepting it. Enable Redis to address this.

Database Cleanup: When and How Often

For database performance, install WP-Optimize. It cleans up post revisions, spam comments, and transient data that accumulate over time and slow down database queries. Running a clean on a site that has been live for a year can remove thousands of stale rows.

A reasonable maintenance schedule:

• Post revisions: Clean monthly. WordPress saves a revision on every save, and a high-traffic blog can accumulate 50,000 revisions within a year. Set a revision limit in wp-config.php (define('WP_POST_REVISIONS', 5);) to stop accumulation going forward.
• Transients: Clean weekly if you have not yet enabled Redis. Once Redis is active, transients no longer write to the database, so the old ones still need one final cleanup pass.
• Spam comments: Clean monthly. Unmoderated spam sits in the database and is loaded into memory on admin pages.
• Auto-drafts and trashed posts: Clean quarterly. These are forgotten drafts that consume space and add noise to database queries.

Common Cloudways Speed Mistakes to Avoid

Even with the right settings in place, a few common mistakes undo the gains:

• Enabling Varnish without configuring Breeze - Varnish and Breeze need to work together. If you run Breeze without telling it Varnish is active, it will not send purge signals and visitors will see stale cached pages after you update content.
• Picking the wrong server region - A server in New York serving mostly European visitors adds 80 to 120 ms of latency per request regardless of how optimized everything else is. Check your traffic's geographic distribution before deploying.
• Scaling RAM but not CPU - On WooCommerce sites, CPU is usually the bottleneck before RAM. Check your CPU usage graph first rather than defaulting to adding RAM.
• Using WP Super Cache or W3 Total Cache alongside Varnish - These plugins conflict with Varnish at the server level. Breeze is the correct caching plugin for Cloudways; other caching plugins should be deactivated.
• Not testing on mobile - GTmetrix and PageSpeed Insights both test desktop by default. Mobile performance often looks quite different, and Google uses mobile TTFB for Core Web Vitals scoring.

Cloudways WordPress Speed Checklist

Work through these steps in order. Each builds on the previous one, and completing all ten will give you the best possible performance on Cloudways:

1. Measure your baseline TTFB with GTmetrix from the server location nearest your audience. Record the numbers before making any changes.
2. Choose the right server location and provider. DigitalOcean or Vultr in the region closest to your main audience. Change provider or region before any other optimization if the current setup is far from your visitors.
3. Update PHP to 8.2 (or the latest stable version) and verify OPcache is active with the OPcache Manager plugin. Aim for a hit rate above 90%.
4. Update MariaDB to the latest stable version from the Packages screen. Run Query Monitor first to identify any slow queries that need fixing before the update.
5. Enable Varnish Cache from Application Settings. Confirm it is working with a curl header check and verify X-Cache: HIT on your homepage.
6. Install and configure Breeze. Enable HTML minification and Gzip. Enable CSS/JS minification only after testing on staging. Set up WooCommerce exclusions if needed.
7. Install Redis Object Cache from Cloudways Packages and activate the Redis plugin in WordPress. Check the transient count beforehand to estimate impact.
8. Activate a CDN. Use the Cloudways built-in CDN for simplicity, or Cloudflare for the free option. Set Cloudflare to DNS-only mode if Varnish is active.
9. Optimize images. Install ShortPixel or Imagify, bulk-compress your library, enable WebP conversion, and remove lazy loading from your LCP image.
10. Audit plugins and database. Deactivate any plugin that is not actively used. Run WP-Optimize to clean revisions and transients. Set a revision limit in wp-config.php.

Running a WordPress website on Cloudways gives you access to all of these tools. For the full overview of how every cache layer fits together, see our Cloudways performance and speed guide. If you have worked through all of these steps and performance is still limited, the next move is to scale your Cloudways server to a higher CPU and RAM plan.