How to Speed Up WordPress on a VPS: Nginx, PHP-FPM, Redis, Cache, and CDN

Speeding up WordPress on a VPS should start with diagnostics, not with installing yet another caching plugin or upgrading the plan. One site may be slow because of an underpowered CPU, another because of slow SQL queries, and a third because of a heavy theme, oversized images, or external scripts.

The right optimization sequence is as follows:

1. Measure TTFB, Core Web Vitals, and the load speed of key pages.
2. Check CPU, RAM, disk, PHP-FPM, MySQL, and logs.
3. Enable page cache for public pages.
4. Check and configure OPcache.
5. Enable Redis object cache if the site makes heavy use of the database.
6. Configure PHP-FPM based on the actual amount of RAM available.
7. Identify slow queries and resource-heavy plugins.
8. Clean up unnecessary autoload data in the WordPress database.
9. Optimize images, CSS, JavaScript, and external scripts.
10. Set up a CDN for static assets and, if needed, HTML caching.

TTFB shows how quickly the server starts responding. If it is high even for a simple page, you should first look at the VPS, PHP, database, and cache. If TTFB is normal but the page still loads slowly, the problem is more likely to be images, JavaScript, CSS, fonts, or third-party widgets.

Page cache usually delivers the fastest improvement for a blog, corporate website, or news site. It allows the server to return a ready-made HTML page without running WordPress again. OPcache speeds up PHP execution, while Redis reduces the number of repeated database queries.

A CDN helps reduce latency and load on the VPS, especially if the site has an audience across multiple regions or contains many images. However, a CDN will not fix a slow database, overloaded PHP-FPM, or conflicting plugins.

The main mistakes when speeding up WordPress are running multiple caching plugins at the same time, starting with CSS minification before checking the server, ignoring slow queries, and trying to solve every problem by upgrading the plan.

A VPS upgrade is needed when the site has already been optimized but the CPU, RAM, disk, or database is still regularly operating at its limit. If the slowdown is caused by a single plugin, autoload data in the database, or unoptimized images, a more expensive plan will only mask the problem temporarily.

Why WordPress Runs Slowly on a VPS

Server and Resource Constraints

WordPress can slow down because of the VPS itself: an underpowered CPU, insufficient RAM, a slow disk, or an overloaded network. In this case, the issue appears not just on a single page, but across almost the entire site.

Common symptoms include high TTFB, a slow admin dashboard, 502 or 503 errors, heavy swap usage, and delays when running background tasks.

Resource constraints are especially noticeable during updates, backups, product imports, cache clearing, or sudden traffic spikes. Under normal conditions, the site may perform acceptably, but during peak load it can quickly hit CPU or memory limits.

However, you should not upgrade your plan right away. First, check whether the database, PHP processes, or specific plugins are creating unnecessary load.

Slow database

WordPress makes heavy use of MySQL or MariaDB: it stores posts, pages, settings, users, products, orders, sessions, and plugin data. The larger the tables and the heavier the queries, the more the database affects site performance.

Problems often arise from a large number of revisions, transients, old plugin data, unoptimized tables, and an excessive volume of autoloaded options.

If the database responds slowly, page cache may hide the issue on public pages, but the admin area, search, WooCommerce, user account pages, and background tasks will still be slow.

For diagnostics, you need to review slow queries, MySQL load, table sizes, and the queries executed by plugins. If the database regularly becomes a bottleneck, the next component to check is PHP-FPM.

PHP-FPM and the Request Queue

PHP-FPM is responsible for executing WordPress PHP code. Each dynamic request occupies a separate process for the duration of page processing.

If there are too few processes, requests start waiting in the queue. If there are too many, the server can quickly exhaust its RAM. PHP-FPM configuration should therefore match the actual amount of memory and the average memory consumption of a single process.

The issue often appears like this: static files are served quickly, but WordPress pages load slowly or periodically return 502 Bad Gateway.

OPcache helps speed up PHP execution, but it does not fix poorly written code, heavy plugins, or an overloaded database. After checking PHP-FPM, you should therefore look at what WordPress is actually executing when generating a page.

Heavy plugins and a heavy theme

The theme and plugins can put more load on the site than WordPress itself. This is especially true for page builders, WooCommerce, product filters, analytics, security, backups, multilingual functionality, and complex recommendation blocks.

The problem is not always the number of extensions. A single heavy plugin can generate more SQL queries and consume more memory than several simple ones.

A heavy theme also affects performance: it can load unnecessary styles, scripts, fonts, widgets, and dynamic blocks. In the admin area, this appears as slow page editing; on the frontend, it results in long rendering times and poor Core Web Vitals.

After server-side and backend diagnostics, you need to check the frontend: images, fonts, JavaScript, and external services.

Images, fonts, and external scripts

Even a fast VPS will not save a page if it loads large images, multiple font sets, advertising scripts, maps, social media widgets, and trackers.

In this case, TTFB may be normal, but the user still sees slow loading, delayed rendering, and layout shifts. This is less of a server issue than a frontend issue.

Common causes:

• Images that are not compressed or properly sized;
• No lazy loading;
• Heavy web fonts;
• Render-blocking JavaScript;
• Unnecessary CSS files;
• Third-party analytics, advertising, and chat scripts;
• Too many requests for a single page.

Optimizing CSS and JavaScript is important, but you should not start there before checking the server. If PHP and the database respond slowly, minifying CSS will not fix a high TTFB.

There is one more layer that affects speed before the page itself loads: DNS, CDN, and the network route.

DNS, CDN, and Network Latency

Sometimes a site is slow not because of WordPress, but because of the distance between the user and the server, slow DNS, incorrect CDN configuration, or an overloaded external service.

If the audience is spread across multiple countries while the VPS is located in a single region, latency can be noticeable even with a well-performing server. A CDN helps deliver images, stylesheets, scripts, and sometimes HTML from a location closer to the user.

However, a CDN must be configured carefully. Incorrect caching rules can serve outdated pages, break authentication, interfere with WooCommerce, or hide real errors from the origin server.

DNS also affects the initial connection to the site. A slow or unstable DNS provider increases the time before the connection can begin, especially for new visitors.

That is why WordPress diagnostics should be performed layer by layer: server, PHP, database, plugins, frontend, and network. From there, it is useful to consolidate these causes into a diagnostic map and determine which symptoms point to which issues.

Diagnostic Guide: Where to Look for the Cause

Before optimizing, you need to determine at which layer the delay occurs. The same symptom can be related to the server, PHP, the database, the frontend, or external services.

It is best to diagnose issues from the server to the browser: start with TTFB and the backend, then move on to rendering, images, CSS, JavaScript, and external scripts.

High TTFB

TTFB (Time to First Byte) shows how long it takes for the first byte of the server response to arrive. If it is high, the browser has not even begun loading the page properly, but the user is already waiting.

High TTFB most often points to backend issues: an underpowered VPS, overloaded PHP-FPM, a slow database, no page cache, or heavy plugins.

For public WordPress pages, a good page cache usually reduces TTFB significantly because the server returns ready-made HTML without running the core, theme, or plugins.

If page cache is enabled but TTFB is still high, check whether the page is actually being served from the cache and whether cookies, authentication, URL parameters, or exclusion rules are interfering.

When the server starts responding quickly but the page still appears to load slowly, the cause is often in the frontend.

Slow page rendering

Slow rendering means that the HTML has been delivered, but the user does not see a usable, stable page for too long. This affects Core Web Vitals: LCP, CLS, and INP.

The causes are usually related to heavy images, render-blocking CSS and JavaScript, web fonts, ads, widgets, chats, and analytics.

For example, a VPS may serve the HTML quickly, but the first large content block on the page may appear late because of a multi-megabyte image or a script that blocks rendering.

In this case, upgrading the plan is unlikely to help much. You need to optimize images, resource loading order, critical CSS, fonts, and third-party scripts.

If not only the frontend is slow, but also the admin panel, search, or product pages, database queries should be checked separately.

Long-running database queries

Slow SQL queries are especially noticeable in WooCommerce, catalogs, filters, search, user account areas, and the admin panel.

The issue may be caused by a large volume of data, missing indexes, a resource-intensive plugin, bloated tables, or too many autoloaded options.

A page cache can hide a slow database on regular pages, but it will not fix the problem in dynamic scenarios. The cart, checkout, admin area, and background tasks will still access MySQL or MariaDB.

For diagnostics, it is useful to review the slow query log, reports from profiling plugins, and the size of the wp_options table. If autoloaded data is too large, WordPress loads unnecessary data on every request.

However, sometimes the database performs normally, while the queue forms at the PHP level.

Overloaded PHP

PHP-FPM can become a bottleneck if there are too few processes, each process consumes a large amount of memory, or requests take too long to complete.

When there are not enough processes, users have to wait for an available PHP worker. If the pool is too large, the server can exhaust its RAM and start using swap.

Common symptoms include intermittent 502 Bad Gateway errors, a slow admin panel, delays when saving pages, and increased response times under concurrent traffic.

OPcache reduces the overhead of compiling PHP files, but it does not fix slow plugins or reduce the execution time of a heavy request indefinitely.

PHP-FPM settings should be tuned based on actual memory usage, not copied from a generic guide. After that, you can move on to issues that arise in the user’s browser.

Browser-Side Issues

If the server responds quickly but the page still feels slow, check the waterfall chart in developer tools or performance testing services.

The culprit is often the frontend, not WordPress or the VPS:

• Oversized images;
• Excess JavaScript;
• Heavy fonts;
• Third-party ads;
• Maps;
• Social media widgets;
• Live chats;
• Analytics and pixels.

These resources may be loaded from external domains and depend on the speed of third-party servers. As a result, a site can have a fast TTFB but perform poorly on LCP or INP.

CDNs, lazy loading, and image optimization help, but you first need to identify which elements are actually slowing down the page. Otherwise, you may spend time minifying CSS when the main delay is caused by an ad script or a huge hero image.

Once you have a diagnostic map, you can move on to a practical optimization sequence: first measurements and server-side metrics, then caching, PHP, the database, images, and the CDN.

Where to Start with WordPress Optimization

Measure TTFB and Core Web Vitals

The first step is to test the speed of several representative URLs, not just the homepage:

Up to €20,000 in EU-Based IaaS Credits

Frankfurt infrastructure, predictable pricing, and expert migration support.

Get


• Homepage;
• Popular article or landing page;
• Category page;
• Product page;
• Cart or account area, if WooCommerce is installed;
• Admin area, if the issue is noticeable in the dashboard.

TTFB shows how quickly the server starts returning a response. If TTFB is high, you should first check the VPS, PHP, MySQL, cache, and plugins. If TTFB is normal but the page still takes a long time to become usable for visitors, the issue is more often related to images, CSS, JavaScript, fonts, and third-party scripts.

Core Web Vitals—Google’s user experience metrics—help evaluate how users perceive page speed. LCP (Largest Contentful Paint) shows how quickly the main content appears, CLS (Cumulative Layout Shift) shows how much the page shifts during loading, and INP (Interaction to Next Paint) shows how quickly the site responds to user actions.

It is important to run measurements several times and under different conditions. A single test may coincide with a cold cache, a temporary network delay, or a background task on the server.

After external measurements, move on to the VPS itself and check whether it has sufficient resources.

Check CPU, RAM, disk, and logs

If the server is overloaded, WordPress will be slow even with a lightweight theme and properly optimized images. You therefore need to see what is happening on the VPS during normal operation and when slowdowns occur.

The first things to check are:

• CPU load;
• Available RAM;
• Swap usage;
• Free disk space;
• Disk I/O;
• MySQL or MariaDB load;
• PHP-FPM status;
• Nginx and PHP errors;
• Slow SQL queries.

Swap usage is especially important. If the VPS regularly uses swap, it means there is not enough RAM and some data is being moved to disk. For WordPress, this almost always causes noticeable delays.

Logs help distinguish resource shortages from configuration errors. For example, 502 Bad Gateway may indicate a problem with PHP-FPM, while repeated PHP Fatal errors may point to a plugin conflict, an insufficient memory limit, or an incompatible PHP version.

If the server metrics are normal, do not upgrade the plan right away. The slowdown may not be in the backend, but in the page itself in the browser.

Separate server-side and front-end issues

The biggest mistake when optimizing WordPress performance is mixing different types of latency. High TTFB, slow LCP, and poor INP may feel the same to users, but they are addressed in different ways.

If the first HTML response is slow to arrive, you need to investigate the server: page cache, OPcache, PHP-FPM, Redis, MySQL, slow queries, and heavy plugins.

If the HTML arrives quickly but the page takes a long time to render, you need to look at the front end: images, CSS, JavaScript, fonts, ads, maps, widgets, and third-party scripts.

If the site is fast for guests but slow in the admin area or user account, the problem may be dynamic requests, the database, Redis object cache, PHP-FPM, or specific plugins.

This separation saves time. There is no point minifying CSS if the server takes two seconds to respond. Conversely, upgrading the VPS will not fix oversized images, blocking scripts, or layout instability.

After the initial diagnostics, you can move on to the tools that deliver the quickest server-side gains: page cache and OPcache.

Page Cache and OPcache

Page caching for rendered HTML pages

A page cache stores the rendered HTML version of a page and serves it to the visitor without bootstrapping WordPress again. The server does not need to execute PHP code, query the database, render the theme, or load plugins each time.

For a blog, corporate website, landing pages, and news pages, this is usually the fastest way to reduce TTFB and lower the load on a VPS.

Page caching is especially useful when most visitors view the same public pages. In this scenario, a single generated HTML page can serve hundreds or thousands of requests.

However, not everything can be cached. The cart, checkout, user account area, pages with personal data, and some AJAX requests must remain dynamic. If caching is configured too aggressively, a user may see someone else’s cart, an outdated price, or an incorrect order status.

Therefore, page caching should be enabled together with the appropriate exclusions. This is especially important for WooCommerce, user account areas, and sites with authentication.

If page caching reduces the number of times WordPress runs, OPcache speeds up the cases where PHP still has to be executed.

OPcache for Speeding Up PHP

WordPress consists of a large number of PHP files. Without OPcache, the server reads these files, compiles them, and only then executes the code on every request.

OPcache stores compiled PHP code in memory. As a result, dynamic pages, the admin area, background tasks, and non-cacheable requests are processed faster.

OPcache does not replace a page cache. It does not serve ready-made HTML and does not eliminate database queries. Its purpose is to speed up PHP code execution where WordPress still has to run.

On a VPS for WordPress, OPcache is almost always worth enabling. The important thing is to allocate enough memory to it and make sure the cache does not fill up too quickly.

If OPcache is enabled but the site is still slow, you need to look for the cause elsewhere: in PHP-FPM, the database, plugins, the theme, or the frontend.

At the same time, caching must be managed properly. One common mistake is trying to speed up a site by using several caching plugins at once.

Why You Should Not Use Multiple Cache Plugins at the Same Time

Multiple cache plugins do not speed up WordPress in proportion to their number. In practice, they often conflict with each other: each one tries to manage the HTML cache, minification, preloading, lazy loading, cache headers, and file cleanup.

As a result, the site may start serving stale pages, break styles, fail to clear the cache correctly after updates, or cache content that should remain dynamic.

Conflicts in WooCommerce are especially risky. If different plugins handle the cart, cookies, and checkout pages differently, this can lead to issues with products, prices, and user sessions.

It is better to choose one primary tool for page cache and complement it with separate system-level mechanisms: OPcache at the PHP level, Redis for object cache, a CDN for static assets, and proper Nginx configuration.

If the site becomes unstable after enabling caching, you should not add a second plugin. Instead, check the exclusion rules, cache purging, cookies, the mobile version, authentication, and form behavior.

After page cache and OPcache, the next logical step is to move on to Redis and the database, because they are often where the load remains on dynamic pages.

Redis Object Cache and the Database

When Redis Is Actually Needed

The Redis object cache stores the results of repeated operations in memory. WordPress and its plugins can retrieve already prepared data faster without querying MySQL or MariaDB every time.

Redis is especially useful for:

• WooCommerce;
• User account areas;
• Large catalogs;
• News websites;
• Multilingual projects;
• Websites with filters and search;
• Projects with a large number of logged-in users.

On a small blog with a good page cache, the impact may be less noticeable. If almost all pages are served as ready-made HTML, the database already receives very few requests from regular visitors.

Redis should not be enabled blindly on a VPS with limited RAM. It stores data in memory, so when resources are constrained, it can compete with PHP-FPM and MySQL.

After enabling Redis, you need to verify that the object cache is actually active and that the site has not started running into memory constraints more often. When Redis is working correctly, it reduces some repeated database calls, but it does not fix slow SQL queries.

Slow queries and MySQL load

Slow queries are SQL queries that take too long to execute. They can be caused by heavy plugins, filters, search, large tables, missing indexes, or poorly designed theme logic.

These issues are especially common on sites with WooCommerce, catalogs, imports, reports, statistics, and complex recommendation blocks.

Page caching can hide slow queries on public pages, but they will still run in the admin area, cart, checkout, and user account.

For troubleshooting, it is useful to enable the slow query log, review the heaviest queries, and correlate them with specific plugins or pages. Sometimes a single widget, filter, or “related products” block generates dozens of unnecessary database calls.

Addressing slow queries by upgrading the hosting plan is a poor strategy. A more powerful VPS may temporarily smooth out the issue, but if the queries are inefficient, they will become a bottleneck again as data volume and traffic grow.

It is also worth checking the wp_options table, because this is where excessive autoload data often accumulates.

Cleaning up autoload data in the WordPress database

In WordPress, some settings are loaded automatically on every request. This data is stored in the wp_options table and marked for autoloading.

If there is too much autoload data, WordPress pulls in unnecessary information every time, even when a particular page does not need those settings. This increases response time and database load.

Autoload bloat is often caused by plugins that store temporary data, settings, logs, or cache in wp_options and do not fully clean it up after they are removed.

Autoload data must be reviewed carefully. You cannot simply delete all large entries: they may include important settings for the theme, plugins, WooCommerce, or security.

The process is as follows:

1. Create a fresh database backup.
2. Find the largest autoload entries.
3. Identify which plugin or function they belong to.
4. Delete only data that is clearly unnecessary and obsolete.
5. Check the site, admin area, cart, forms, and integrations.

If the database becomes leaner and slow queries are eliminated, dynamic pages start working more reliably. After that, you can move on to PHP-FPM and Nginx: they determine how the server handles PHP requests and serves static files.

Configuring PHP-FPM and Nginx

PHP-FPM Processes and Memory Limits

PHP-FPM manages the processes that execute WordPress PHP code. Each dynamic request uses a separate PHP process: while it is processing a page, another request must use a different available process or wait in the queue.

If there are too few processes, the site starts to slow down when visitors access it simultaneously. If there are too many processes, the VPS can quickly exhaust its RAM and start using swap.

For this reason, PHP-FPM settings should not be chosen arbitrarily. You need to take into account:

• The total amount of RAM on the VPS;
• How much memory a single PHP process consumes;
• How much memory MySQL, Redis, Nginx, and the system require;
• Whether WooCommerce, Elementor, WPBakery, or resource-intensive plugins are installed;
• How many dynamic requests the site receives concurrently.

For example, if each PHP process consumes a large amount of memory, a high pm.max_children value will not make the site faster; instead, it will lead to a RAM shortage. As a result, the server will run more slowly than it would with a smaller but stable process pool.

It is also important to check memory_limit, max_execution_time, and file upload settings. Limits that are too low can cause resource-intensive operations to fail, while limits that are too high can allow a single request to consume too many resources.

After configuring PHP-FPM, make sure Nginx is not forcing WordPress to do unnecessary work when it could serve a cached response or a static file instead.

FastCGI Cache and Serving Static Files

Nginx can do more than forward PHP requests to PHP-FPM; it can also efficiently serve static files such as images, CSS, JavaScript, fonts, and documents. These files should not be routed through WordPress.

When static assets are served directly by Nginx, the VPS uses fewer resources and pages load faster.

For HTML pages, you can use FastCGI cache. In this setup, Nginx stores the completed response from PHP-FPM and serves it on subsequent requests without running WordPress again.

Full Control Over Your Kubernetes Infrastructure

Deploy production-ready Kubernetes with full control over nodes, storage, and networking on predictable-cost EU infrastructure with direct access to your resources.

Get

FastCGI cache is especially useful for public pages such as posts, categories, landing pages, news pages, and documentation. It can reduce TTFB even more than a caching plugin because it works at the web server level.

However, this type of cache has one important requirement: exclusions must be configured correctly. You must not cache the cart, checkout, user account pages, the admin area, pages containing personal data, or requests from authenticated users.

You also need to plan cache purging after posts are updated, prices change, new content is published, or templates are edited. Otherwise, users will see an outdated version of the page.

Once PHP and caching are configured, the remaining task is to optimize data transfer from the server to the browser.

Gzip, Brotli, and HTTP/2 or HTTP/3

Gzip and Brotli compress text-based resources before they are sent to the browser. This reduces the size of HTML, CSS, JavaScript, SVG, and JSON files.

Brotli typically provides better compression, especially for text files, but support depends on server and CDN configuration and on the browser. Gzip remains the baseline, widely compatible option.

Compressing formats that are already compressed, such as JPEG, PNG, WebP, AVIF, ZIP, or MP4, usually does not make sense. It will barely reduce the file size and will add unnecessary work for the server.

HTTP/2 makes it possible to transfer many resources more efficiently over a single connection. This is useful for WordPress, where a page often loads stylesheets, scripts, images, and fonts.

HTTP/3 can further reduce latency on unstable networks, but its benefit depends on support from the provider, the CDN, and the site’s audience.

These settings help speed up resource delivery, but they do not replace image, CSS, and JavaScript optimization. If a page is too large or loads dozens of unnecessary scripts, the transport protocol will not fully solve the problem.

Optimizing Images, CSS, and JavaScript

Even if the VPS serves HTML quickly, a WordPress page can still be slow because of a heavy frontend. Large images, unnecessary styles, render-blocking JavaScript, web fonts, and external scripts directly affect Core Web Vitals.

Therefore, after configuring caching, PHP-FPM, and the database, you need to check exactly what loads in the user’s browser.

Image Compression and Modern Image Formats

Images often account for most of a page’s size. This is especially noticeable on homepages, landing pages, product pages, portfolios, and news articles with many illustrations.

The first step is not just to compress images, but to resize them to their actual display dimensions. If a section on the site displays an image at 800 pixels wide, there is no point in loading a 3000-pixel-wide file.

For new images, it is worth using modern formats such as WebP or AVIF. They typically produce smaller files at comparable quality. At the same time, it is advisable to keep a fallback for older browsers if the site’s audience requires it.

Compression should be applied carefully. Overly aggressive optimization can degrade photos, logos, and product images. This is especially important for online stores: poor-quality images may speed up loading, but they can reduce trust in the page.

After optimizing image format and file size, you need to make sure the images load at the right time.

Lazy Loading and Image Dimensions

Lazy loading defers the loading of images below the fold. This allows the browser to fetch the resources needed for the initial page render more quickly.

However, lazy loading should not be enabled indiscriminately for all images. The main above-the-fold image, the logo, and the key hero section should be loaded immediately; otherwise, LCP may worsen.

It is also important to specify image dimensions in the markup. If the browser knows the width and height of a block in advance, the page shifts less during loading. This helps reduce CLS.

For responsive layouts, it is useful to provide different versions of images for different screen sizes. Mobile users do not need to download the same file intended for a large desktop monitor.

Once images have been put in order, it is worth moving on to CSS, JavaScript, and external scripts. These are often what delay rendering even after images have been compressed.

CSS, JavaScript, and external scripts

CSS and JavaScript can block page rendering. If the browser has to download and process a large set of styles and scripts first, the user will see the main content later.

Optimization typically includes removing unused CSS, deferring non-critical JavaScript, reducing the number of requests, and checking the scripts loaded by plugins and the theme.

However, you should not start by minifying CSS before checking the server. If TTFB is high because of PHP, the database, or the lack of a page cache, minifying styles will have a limited effect.

External scripts should be checked separately:

• Analytics;
• Advertising pixels;
• Live chats;
• Maps;
• Social media widgets;
• Forms from third-party services;
• A/B tests;
• Anti-fraud and marketing trackers.

These scripts are loaded from third-party servers, so the site owner does not always control their speed. A single slow external service can degrade rendering and the page’s response to user actions.

It is better to keep only the external integrations that are truly needed, and to defer loading non-critical scripts or load them only on the pages where they are required.

After optimizing images, CSS, and JavaScript, you can add a CDN: it will help deliver static assets to users faster and reduce the load on the VPS.

CDN for WordPress

When a CDN speeds up a website

A CDN speeds up WordPress when users are located far from the VPS or when the site serves many static files, such as images, CSS, JavaScript, fonts, and documents.

Without a CDN, every visitor sends requests to the origin server. If the VPS is located in a single region, users in other countries may experience higher page load latency.

A CDN stores copies of assets on edge servers closer to the audience. As a result, the browser receives static content faster, and the VPS has fewer requests to process.

A CDN is especially useful for:

• Sites with audiences in multiple regions;
• Media sites and blogs with a large number of images;
• Online stores with product catalogs;
• News projects with sudden traffic spikes;
• Landing pages where LCP and fast above-the-fold loading are important.

However, a CDN does not fix slow PHP, heavy SQL queries, or PHP-FPM issues. If the origin server takes a long time to generate HTML, a CDN will help only after caching is configured correctly.

That is why it is important to understand which assets can be safely served through a CDN and which should remain dynamic.

What to serve through a CDN

Static assets are the first thing you should serve through a CDN. They rarely change and are the same for all users.

A CDN is typically used to serve:

• Images;
• CSS files;
• JavaScript;
• Fonts;
• SVG;
• PDFs and other documents;
• Video and media files, if the infrastructure supports them.

For these files, you can set a long cache duration, especially if the URL includes a version or hash. In that case, the browser and CDN know that a new file will have a new address, and the old one can be safely stored for longer.

HTML pages can also be cached through a CDN, but with more caution. For blogs, documentation, news content, and landing pages, this can work well.

On dynamic sites, you need to define exceptions in advance: authentication, the shopping cart, checkout, the user account area, personalized pages, forms, and AJAX requests.

If the CDN is configured incorrectly, it may not speed up the site and can instead add a new layer of problems: stale content, broken forms, incorrect cookies, and authentication errors.

How to avoid breaking caching for dynamic pages

The key rule: do not cache personalized or changing pages as shared HTML for all users.

In WordPress, you need to be especially careful with WooCommerce, user accounts, restricted sections, forms, subscriptions, and pages that contain user data.

The following are usually excluded from the CDN cache:

• /wp-admin/;
• /wp-login.php;
• Cart;
• Checkout;
• Account area;
• Pages with nonces and forms;
• AJAX requests;
• Requests from authenticated users;
• Pages with cart or session cookies.

It is also important to configure cache purging after changes. If a new article is published, a product price is changed, or a template is updated, the CDN must receive the current version of the page.

To verify the configuration, open the site in different scenarios: as a guest, as an authenticated user, with a product in the cart, after submitting a form, and after updating content.

It is best to connect a CDN after completing basic WordPress optimization. This way, it strengthens the cache that is already configured, reduces the load on the VPS, and speeds up resource delivery instead of masking problems with PHP, the database, and plugins.

WordPress Optimization Workflow on a VPS

It is best to optimize WordPress in a structured sequence: start with diagnostics, then move on to the server, database, cache, frontend, and CDN. If you change everything at once, it will be difficult to determine what actually improved performance and what broke the site.

The sequence is as follows:

1. Measure the current speed. Check TTFB, LCP, CLS, INP, and the load time of key pages. Review the homepage, articles, categories, product pages, cart, user account, and admin panel separately.
   
2. Check VPS resources. Assess CPU, RAM, swap, disk, I/O, and the Nginx, PHP-FPM, and MySQL logs. If the server is already operating at its limit at this stage, optimization should start with the infrastructure and PHP settings.
   
3. Enable the page cache. For public pages, this is usually the fastest way to reduce TTFB. It is important to configure exclusions for authentication, the cart, checkout, the personal account area, and forms right away.
   
4. Check OPcache. OPcache must be enabled and have sufficient memory. It speeds up PHP code execution wherever WordPress is still run.
   
5. Configure PHP-FPM. The number of processes must be selected based on the actual amount of RAM. A pool that is too small creates a queue, while one that is too large leads to memory exhaustion and swap usage.
   
6. Check the database. Enable or review the slow query log, identify heavy queries, check the tables, the size of wp_options, and the amount of autoload data.
   
7. Enable Redis object cache if needed. Redis is especially useful for WooCommerce, user accounts, catalogs, search, and sites with a large number of dynamic requests. On a small blog with good page cache, the effect may be minimal.
   
8. Clean up unnecessary data in the database. Delete old revisions, temporary records, leftover plugin junk, and unnecessary autoload options. Be sure to create a backup before cleaning.
   
9. Optimize images. Resize images to their actual display dimensions, compress them, use WebP or AVIF, configure lazy loading, and check the LCP image above the fold.
   
10. Audit CSS, JavaScript, and external scripts. Remove anything unnecessary, defer non-critical scripts, and check fonts, analytics, ads, maps, chats, and third-party widgets.
    
11. Connect the CDN. First, serve static assets via the CDN: images, CSS, JavaScript, fonts, and documents. Enable HTML caching via the CDN only after configuring exclusions for dynamic pages.
    
12. Repeat the measurements. After each major change, you need to check TTFB, Core Web Vitals, logs, and site behavior again. Otherwise, it is impossible to understand which setting actually made WordPress faster.

The key point is not to start with cosmetic fixes. If the server takes two seconds to respond, CSS minification will not solve the problem. If TTFB is normal but LCP is poor, upgrading the VPS will not fix a heavy above-the-fold image.

High-Performance Virtual Machines

Deploy in seconds with full root access, reserved resources, built-in high availability, and predictable monthly pricing.

Get

WordPress optimization works best when each action addresses a specific bottleneck.

Common Speed Optimization Mistakes

Speeding up WordPress often turns into a chaotic set of actions: installing a caching plugin, enabling minification, upgrading the hosting plan, disabling a couple of scripts, and hoping the site will become faster.

The problem is that these actions may not address the root cause of the slowdown. Sometimes they even make troubleshooting more difficult: the site starts behaving unpredictably, and it becomes harder to determine which setting is responsible.

Installing five caching plugins at once

Multiple caching plugins do not compound their effect. If one plugin already manages the page cache, minification, preloading, and lazy loading, a second plugin may start doing the same thing on top of it.

This can lead to conflicts: styles break, JavaScript runs in the wrong order, the cache is purged unpredictably, and dynamic pages start serving stale data.

This is especially risky for WooCommerce. The cart, checkout, and account area require carefully configured exclusions. If different plugins handle cookies and the HTML cache differently, you may encounter issues with products, prices, or user sessions.

It is better to choose one primary tool for the page cache and avoid combining multiple solutions with the same features. OPcache, Redis, a CDN, and server-side caching can be used together, but each layer should have a clear, well-defined role.

Optimizing CSS Before Checking the Server

Minifying CSS, removing unused CSS, and deferring JavaScript loading can indeed improve Core Web Vitals. But this should not be the first step if the server itself is slow to respond.

If TTFB is several seconds, the user is already waiting before the styles even load. In this situation, you should first check the VPS, PHP-FPM, MySQL, page cache, OPcache, and slow queries.

CSS optimization makes sense when the server is already delivering HTML quickly enough, but the page takes a long time to render in the browser. At that point, you can analyze critical CSS, script loading order, fonts, and render-blocking resources.

Otherwise, it is just a cosmetic fix layered on top of a server-side problem: the report may show a slight improvement, but the user will still be waiting for the site’s first response.

Ignoring slow queries

Slow SQL queries can undermine some of your optimizations. Page caching can help on public pages, but the admin area, search, filters, cart, checkout, and user account pages will still query the database.

If you do not check for slow queries, you can spend a long time tuning PHP-FPM settings, installing caching plugins, and upgrading your plan, even though the actual latency is caused by a single expensive query from a plugin or theme.

Pay especially close attention to the database on sites with WooCommerce, catalogs, filters, imports, reports, and a large number of records.

Slow queries need to be linked to a specific scenario: which page was opened, which plugin executed the query, how much data was processed, and whether the issue recurs under load.

Trying to fix everything by upgrading the plan

Upgrading a VPS is sometimes genuinely necessary. If the site is optimized, caching works, the database is in good shape, and CPU and RAM still regularly hit their limits, moving to a more powerful plan is justified.

The mistake begins when the plan is upgraded instead of diagnosing the problem. A more expensive VPS may temporarily hide a resource-heavy plugin, bloated autoload data, slow queries, or oversized images, but it will not fix them.

After a while, the problem will return: the amount of data will grow, traffic will increase, plugins will add new tasks, and the site will start slowing down again.

The right approach is to identify the bottleneck first, fix the obvious issues, and only then scale resources. In that case, an upgrade becomes a deliberate step rather than a way to mask poor WordPress configuration.

WordPress Performance Optimization Checklist

Before optimization:

• Measure TTFB on the homepage, posts, category pages, product pages, and dynamic pages;
• Check Core Web Vitals: LCP, CLS, and INP;
• Check CPU, RAM, swap, disk, and I/O usage on the VPS;
• Check the Nginx, PHP-FPM, and MySQL logs;
• Separate server-side issues from frontend issues.

For the server side:

• Enable page caching for public pages;
• Configure exclusions for the cart, checkout, account area, and logged-in users;
• Verify that OPcache is enabled and not running out of capacity;
• Configure PHP-FPM based on the actual amount of RAM available;
• Check for slow queries;
• Identify resource-intensive plugins and database queries;
• Remove unnecessary autoload data from wp_options;
• Enable Redis object caching if the site makes heavy use of dynamic queries.

For the frontend:

• Compress images;
• Use WebP or AVIF;
• Verify that image dimensions match the actual page blocks;
• Configure lazy loading for images below the fold;
• Do not defer loading the main LCP image;
• Remove unnecessary CSS and JavaScript;
• Check fonts, ads, maps, chats, analytics, and other third-party scripts.

For the CDN:

• Serve images, CSS, JavaScript, fonts, and documents through the CDN;
• Do not cache personalized pages as shared HTML;
• Configure cache purging after content updates;
• Test the site as a guest, as a logged-in user, and as a shopper with an item in the cart.

Repeat measurements after every major change. If performance has not improved, the change may not have addressed the actual bottleneck.

Conclusion

Speeding up WordPress on a VPS starts with diagnostics. You cannot know in advance whether a specific site is slow because of an underpowered plan, a heavy theme, the database, images, or external scripts. First, you need to measure TTFB, Core Web Vitals, and server load, and only then choose an optimization approach.

For public pages, page caching and OPcache usually deliver the quickest results. They reduce the number of times WordPress has to run and speed up PHP execution. For dynamic sections, Redis object cache, database health, slow queries, and PHP-FPM settings are more important.

The frontend cannot be ignored either. Even a fast server will not make a page user-friendly if it loads oversized images, unnecessary JavaScript, heavy fonts, and dozens of external scripts.

A CDN helps speed up asset delivery and reduce load on the VPS, but it is not a substitute for properly configuring WordPress. If the origin server is slow to generate HTML, you should first address caching, PHP, the database, and plugins.

You should not optimize everything indiscriminately; focus on the specific bottleneck. This makes the site faster without randomly installing plugins, creating cache conflicts, or overspending on a plan that only masks the problem.

FAQ

What speeds up WordPress the most?

In most cases, page caching delivers the most noticeable improvement. It allows a prebuilt HTML page to be served without re-running WordPress, PHP, the theme, plugins, or database queries.

However, this primarily applies to public pages: posts, landing pages, categories, and standard informational sections.

For dynamic pages, other measures are more important: OPcache, Redis object cache, PHP-FPM tuning, database optimization, and eliminating slow queries.

If TTFB is high, start with the backend. If TTFB is normal but the page still appears to load slowly, optimizing images, CSS, JavaScript, fonts, and external scripts will be more effective.

Does every WordPress site need Redis?

No, not every site needs Redis.

For a small blog or corporate website with an effective page cache, the impact of Redis may be minimal. If most pages are served as ready-made HTML, the database already receives very few requests from regular visitors.

Redis is more useful for WooCommerce stores, catalogs, user accounts, multilingual sites, search, filters, and projects with a large number of authenticated users.

Before enabling Redis, you need to consider the amount of RAM available on the VPS. Redis stores data in memory, so on a low-resource server it may compete for resources with PHP-FPM and MySQL.

Which is more important: a CDN or a good VPS?

A CDN and a VPS solve different problems.

A good VPS is needed so WordPress can generate pages quickly, process PHP requests, work with the database, and handle the load. A CDN is needed to deliver assets to users faster and reduce the number of requests to the origin server.

If the server takes a long time to generate HTML, a CDN will not fully address the root cause. It can speed up static assets, but slow PHP, slow queries, and an overloaded MySQL server will remain.

If the VPS is configured properly and the audience is distributed across different regions, a CDN can significantly improve the loading of images, CSS, JavaScript, fonts, and cacheable HTML pages.

Why is the website slow even with a caching plugin?

A caching plugin does not speed up every use case. It may not work for logged-in users, the cart, checkout, the account area, search, filters, AJAX requests, and pages with cookies.

The cache may also be configured incorrectly. For example, a page may not be cached, the cache may be cleared constantly, there may be a conflict with another plugin, or exclusions may be configured too broadly.

Another common reason is that the problem is not HTML generation but the frontend. If a page loads large images, blocking JavaScript, ads, chats, and third-party widgets, a caching plugin will not eliminate those delays.

That is why, after setting up caching, you should measure TTFB again, check whether pages are being served from the cache, and review Core Web Vitals separately.

When should you upgrade your VPS plan?

You should upgrade your plan when the website has already been optimized, but the server still regularly runs at its limit.

Signs:

• CPU usage stays high for extended periods;
• RAM is almost fully used;
• the VPS is constantly using swap;
• 502 or 503 errors appear;
• PHP-FPM builds up a queue;
• MySQL responds slowly even after optimization;
• backups, imports, or updates interfere with normal website operation.

If the cause is a heavy plugin, slow queries, bloated autoload data, unoptimized images, or conflicting cache plugins, a new plan will only mask the problem temporarily.

First, identify the bottleneck, then fix the obvious issues, and only then scale the resources.

Sources

1. WordPress Advanced Administration Handbook — Cache

2. Make WordPress Hosting Handbook — Performance

3. Google Search Central — Core Web Vitals and Search results

4. Web.dev — Web Vitals

5. Nginx Documentation — gzip module

6. Nginx Documentation — HTTP/2 module

7. Nginx Documentation — Brotli module