In this article I will answer these questions:
- What is the best stack (performance-wise, scalability-wise, and compatibility-wise)?
- The rivalry between Nginx and Litespeed/Openlitespeed, which one is better?
- Should you be using Apache in 2025?
- The pros and cons of each stack
- What hosting platforms choose and why?
The Best WordPress Stack (Performance Wise)
Options | |
---|---|
Web Server | Apache < Nginx < OLS =< Litespeed |
PHP version | The latest and the stable one (Might revert to a lower version if you get errors) |
Database | MySQL < MariaDB (latest version is preferred) InnoDB < MyISAM |
Database caching | WP Object Cache (default) < Memcache < Redis Object Cache |
PHP OPcode Accelerators | APC < eAccelerator < XCache < Zend OPcache (comes preinstalled in PHP 5.5) (Ioncube loader doesn’t work with OPcache) |
PHP Handlers | Traditional CGI < mod_php/prefork < mod_fcgid < mod_fastcgi < FastCGI via SpawnFCGI < Apache + PHP-FPM < Apache + LSAPI < mod FastCGI via PHP-FPM < LSAPI |
Static resources optimization | CDN (Cloudflare etc.) < mod_pagespeed < Custom Plugin |
Page Caching | WordPress default (no caching) < simple disk cache < mod_cache (apache) < Varnish (best for complex) < FastCGI cache via PHP-FPM (best for static) = LSPHP (best for dynamic/uncached) |
Data Compression | Gzip < Brotli (3 to 7 level) |
HTTP protocol | Http1.1< Http2.0 < Http3.0 |
Cache Plugins (if needed) | Ngnix Helper (for Nginx) = Litespeed (For Litespeed) = FlyingPress (For Apache) |
CDN | CloudFront = BunnyCDN = MyCDN = Quic.cloud (good for LiteSpeed) < Cloudflare (Apache and Nginx) |
1) HTTP Web Server
Four web servers are used for WordPress:
Apache
Apache (open-source) is the most compatible with WordPress and its plugins. The plugins are able to make quick changes in htaccess files and are implemented without any soft restart and errors. An example would be WordPress security firewall plugins and cache plugins quick changes. That is why it is the easiest web server to make changes when it comes to WordPress and only WordPress.
However, Apache is resource-intensive in comparison to the much newer Nginx and Litespeed and also isn’t the fastest when it comes to HTTP requests and PHP management.
Nginx
Nginx (open-source) is probably the fastest and the lightest free web server out there. As a web server only, it exceeds Apache’s performance, and for static content and non-PHP apps, it’s way better than Apache and even Litespeed. However, when it comes to only WordPress with dynamic content such as PHP, it is behind Litespeed and even Apache (with PHP-FPM.
Nginx is for you if you are a sys-admin and love:
- Setting up reverse proxies and headers
- Manage caching (FastCGI via PHP-FPM) directly from the web server instead of a WordPress plugin
- Scalability without paying for a license
- Easier to configure a web server for a newbie (not familiar with Apache)
- Way better debug logs, and better documentation support than Litespeed
Meanwhile, Nginx is not for you if you are more of a WordPress guy and love:
- Using plugins to control server settings and changes
- Would like the best performance out-of-the-box, without going deep into the server files and settings
- Familiar with Apache rulesets and htaccess edits
Litespeed
Litespeed (licensed) is a drop-in replacement for Apache. Think of it as Apache but without the high resource usage and a performance at the level of Nginx but with better compatibility with WordPress plugins. Moreover, Litespeed is a webserver made specifically for WordPress and that is why it has way better performance out-of-the-box than the default Nginx.
Apart from this, Litespeed like Apache completely supports htaccess without any restarts like you would do in OLS and http/3 support. It has a dedicated WordPress plugin called Litespeed Cache which is an all-in-one solution for managing caching including disk and memory (redis/memcache), image optimization, CDN, cleanups, and content optimization. Now this certainly doesn’t mean that it is also better than other plugins. With so many features to offer it also gets buggy from time to time. For OLS/LS and quic-cloud CDN combination, it is the only best solution.
However, the problem with Litespeed is that it’s not free and if you have multiple servers, the licensing fee could cost you a lot. Also apart from the licensing fee, the support is also paid.
Openlitespeed
Openlitespeed or OLS (open-source) is the free version of Litespeed offering almost the same out-of-the-box performance, Litespeed cache, but with partial support for htaccess and an OLS service restart required every time you make a change. The restart downside is already solved by either auto restarting when changes are made to the htaccess or adding a cron job. But for a server with multiple users and apps, this is not the best solution because the service will restart on the entire web server.
The Openlitespeed GUI panel is the icing on the cake making it easy to make changes and enable/disable features like http/3, php-ini edit, vhost changes, etc if you don’t want to do it in your web panel or the CLI. Documentation is good but similar to Litespeed I see some important pages redirected to the homepage.
Here’s a summary provided in the table for each web server (for WordPress usage only):
Features | Web Server |
---|---|
Plugin compatibility | Nginx < OLS < Litespeed < Apache |
Performance | Apache < Nginx < Litespeed = OLS |
Caching | Apache < Nginx (static) < Litespeed/OLS (dynamic) |
Ease of Use (WordPress) | Nginx < OLS < Litespeed < Apache |
Scalability | OLS < Litespeed < Apache < Nginx |
2) PHP Version
WordPress is written in PHP. Always go for the latest version of PHP which is more efficiently written than the previous version. However, make sure that the version is stable as well and it doesn’t break your website. Also, remember that OPcache comes by default with PHP 5.5 so do enable it and edit the php.ini.
3) Database
WordPress stores all the queries and settings in the SQL database. For that, we have MySQL (proprietary) and MariaDB (open source). Now, the speed and competition between both of them will change from version to version. At the moment, MariaDB is slightly faster in performing queries than MySQL. Open-source is what most people prefer especially when it comes to scalability and fees.
Regardless of what you choose, it is important to select InnoDB as the storage engine rather than MyISAM.
4) Database Caching
For WordPress, database queries and connections with the website can become a bottleneck especially if you have consistent requests between the website and the database. For that in-memory cache is needed that stores the database queries in system memory and executes them from there.
For that, WordPress has three in-memory solutions which are:
- WP_Object_Cache
- Memcache
- Redis Object Storage
All of them are open-source and free to use. Redis object cache is the fastest and most efficient among all three, however, if you are using this on multiple websites make sure that you don’t go out of memory. If on a shared hosting with limited RAM, Memcache is the best alternative, and then WP object cache.
5) PHP OPcode Accelerators
Similar to the database, PHP also needs to be cached to decrease load and improve speed. Ideally what happens is that when a PHP script runs, it first tokenizes, parses, compiles, and stores on disk as OPcache and then gets executed. These PHP Accelerators cache the operation code (OPcache) not on the disk but on memory (way faster read and write times) so that the whole conversion doesn’t need to be made again.
For WordPress, we have four PHP accelerators:
- APC
- eAccelerator
- XCache
- Zend OPcache
Zend OPcache is the fastest one of them all and comes preinstalled in PHP 5.5 and above. Make sure it is enabled and present in the php.ini file.
6) PHP Handlers
There are many ways on how a server can process PHP requests. Since we are on WordPress and it’s PHP, I have ranked different server-app protocols according to that on the table above. For non-PHP apps the ranking is different.
Here are the php handlers from the worst to the best:
- Traditional CGI
- mod_php/prefork (Apache)
- mod_fcgid (Apache)
- mod_fastcgi (Apache)
- FastCGI via SpawnFCGI or others
- Apache + PHP-FPM
- Apache + LSAPI
- FastCGI via PHP-FPM
- LSAPI (Litespeed and OLS)
It should be noted that from Apache 2.4 and onwards, PHP-FPM already comes as a package but is not pre-configured. Also, there’s no point in using mod_php, mod_fcgid, and mod_fastcgi on Apache since PHP-FPM solves all the cons of each module. Still, a few websites use mod_php because of its easier configuration.
Whether it be LSAPI or PHP-FPM running on Apache, they can’t beat a pure FastCGI via PHP-FPM on Nginx (for dynamic content) or LSAPI on Litespeed and OLS (for static content). Yet, for pure PHP performance, Apache (resource-intensive) and Litespeed will always be faster than Nginx.
As for Nginx (FastCGI via PHP-FPM) vs Litespeed (LSAPI), and keeping WordPress in mind, PHP apps like WordPress perform slightly better on Litespeed. If you have a lot of dynamic content (user customization, social feed, products shop) then Nginx is preferred and if you have a lot of static content (HTML files and images like a blog) then Litespeed/OLS is preferred. However, it should be noted that both need to be tuned manually and the ease of tunning depends on the web panel. If no web panel, OLS/Litespeed has an upper hand on configuration for beginners because of the Openlitespeed GUI.
7) Static Resources Optimization
WordPress isn’t 100% optimized especially when it comes to themes and plugins which are written by both experienced and inexperienced developers. In fact, I must say that it is barely optimized at all out-of-the-box.
Images, stylesheets, fonts, javascript, and so on, everything needs to be optimized. This can be done by:
- CDN level (Cloudflare etc)
- Server-level (mod_pagespeed)
- WordPress level (plugin)
Only Use One Optimization
Please use only one type of static content optimization. Using multiple tools for the same optimization can lead to slower speed and even website breaks.
Server-level static content optimization is the fastest and best for scalability but is limited in functionality when compared to WordPress level (using plugins). Each website is different and that is why I usually use plugins to optimize each website separately rather than just doing an entire server optimization or domain base. CDN level is also good but quite limited and irrelevant if you are already doing it on your server.
8) Page Cache
Moving to one of the most important parts of WordPress is the caching of WordPress pages which includes the HTML, CSS, JS, fonts, etc. By default, WordPress doesn’t come with page caching enabled. There are 6 page caching solutions arranged from the worst to the best in performance:
- WordPress Default (no caching)
- Simple Disk cache (advanced-cache.php)
- mod_cache
- Varnish (best for complex caching)
- FastCGI cache via PHP-FPM (best for static)
- LS cache for Litespeed/OLS (best for dynamic/uncached)
Simple disk cache is the easiest to set up and control. You can enable disk caching by using any cache plugin that writes ‘advanced-cache.php’ and sets ‘WP_CACHE’ true. The plugin is used to tune the caching (expiration, rebuilt interval, exclusions, etc.) and purging. For most simple websites this just works effortlessly and generates a lot less caching issues than the other mentioned. Moreover, for shared hosting with low resources, this may be the best caching solution. The cons of disk cache include low performance (slower reads and writes), increased disk space (usually because of caching conflicts), and less scalability (not for high-traffic websites that need complex caching solutions).
The default caching module used by the Apache server is mod_cache. Though a few websites on Apache still use this but most of them have moved to FastCGI or using Nginx as a reverse proxy.
Varnish is the most customizable caching solution on the list acting as a reverse proxy and having Edge Side Includes (ESI) but is memory-intensive, slightly difficult to configure, and doesn’t support HTTPS protocol. In raw performance, it might not be able to beat FastCGI micro caching, but still a good configured Varnish is more versatile and can handle thousands of requests per second easily.
FastCGI caching is the default caching module for Nginx. It is highly customizable and the least resource-intensive in the list. It also supports HTTPS protocol but doesn’t have Edge Side Includes (ESI) support making it only deal with static websites.
LS cache plugin is Litespeed’s official plugin for controlling website caching. This is probably the easiest to set up after disk caching plugins in a similar way and controls the Litespeed server directly as well as the quic-cloud CDN. However, it does have drawbacks as a WordPress plugin in the form of time-to-time security vulnerabilities and a few glitches. The reason why most WordPress setups have this is that it is a really good all-in-one plugin offering the most in-depth WordPress optimization (auto purges object cache and OPcode as well), has Edge Side Includes (ESI) similar to Varnish and the fact that most hosting platforms are moving from Apache to Litespeed.
Features | Caching Solution |
---|---|
Performance | WordPress default (no caching) < simple disk cache < mod_cache < Varnish < FastCGI cache = LS Cache |
Customizability | Simple disk cache < mod_cache < FastCGI cache < Varnish < LS Cache |
Ease of Use (WordPress) | Varnish < FastCGI cache < mod_cache < LS Cache < Simple disk cache |
Scalability | Simple disk cache < mod_cache < FastCGI cache < LS Cache< Varnish |
Don’t Use Two or More Caching Solutions For The Same Assets
Most sys-admin usually end up in chaos trying to use multiple caching solutions in the race to make the website faster. While multiple caching solutions can be set for static and dynamic content as well as fallback caching if one fails, the problem is purging them at the same time or even auto-purging when any changes are made on the website.
So, it is recommended to use only one caching solution or use two but to cache different assets. Disk caching can be used as a fallback cache.
9) Data Compression
Similar to compressing files and images on your computer, the website needs to be compressed as well for faster loading and a reduction in page size. WordPress relies on two data compression tools:
- Gzip
- Brotli
Brotli is better than Gzip simply because it compresses the data much more efficiently saving file size from 10% to 40% depending on the compression level set. In 2024, every browser supports it apart from Opera Mini and IE but no one uses them anymore. And even if someone uses them to open the website, it will not tell them a broken website.
Don’t Set Compression Level Too High
Don’t set the compression level of Brotli too high because even though it will compress more but reduces the compression speed resulting in a lower website speed. On a scale of 0 to 11, it is recommended to set it between 3 to 7. Just test the speed at different levels and retain what level works best for you.
10) HTTP protocol
HTTP is a protocol in which how your data communicates with the world-wide web (www). Since WordPress has multiple files to be loaded, multiple requests have to be made.
HTTP/1.x has a major drawback of handling only one request at a time and no prioritization. As a result on a waterfall test, you would see one request loading after the previous one ends. This is why you should never be using this protocol for WordPress and by default all servers have moved to HTTP/2 and HTTP/3.
HTTP/2 solved this issue by handling multiple requests at the same time along with prioritization of what to fetch and render first, header compression, and server push. Currently, all newly deployed servers have HTTP/2 enabled by default.
HTTP/3 (recommended) is the latest protocol that moves away from TCP to UDP/QUIC. This is faster in terms of the initial connection of the website with TLS1.3 enabled, eliminating the need for a separate TLS handshake. Moreover, it reduces latency to a previously visited server and reduces head-of-line blocking issues. At the moment, Nginx and Litespeed/OLS support HTTP/3 while Apache will release it once matured enough. Also, only Litespeed/OLS has HTTP/3 enabled out of the box.
11) Cache Plugins
Most stacks come with pre-installed caching plugin in a default WordPress installation. Selecting a caching plugin is your choice but remember not to use different caching plugins for the same thing. And if you are choosing server-level caching, make sure that you have a WordPress plugin to manage it. Here are the recommended cache plugins for each server:
- Apache – Almost every plugin works fine.
- Nginx – If you are using FastCGI cache, use Nginx Helper or Nginx Cache to auto and manually purge.
- Litespeed/OLS – LS Cache. The only plugin to work with the LSAPI.
12) CDN
This is also optional. Usually one selects the server location nearest to the targeted area, but if you have a global audience, using a CDN can make your website load fast in every corner of the world. CDN stores the copy of your website on their clouds and when a request is made they serve your website from the nearest cloud available.
I prefer Cloudflare and QUIC.cloud. Cloudflare has the fastest DNS and has a free package. With the help of Cloudflare Super Page Cache, you can enable full-page caching on Cloudflare and serve it over their clouds
QUIC.cloud just works exceptionally well with Litespeed and LS Cache. They also have a free quota.
If you are on Nginx or Apache you can go for Cloudflare and if on Litespeed/OLS Quic-cloud CDN is the best.
Best WordPress Stack According To Server Resources & Traffic
Low server resources include: Shared Hosting or VPS below 2GB RAM, <2 core and under 2.0GHz frequency
High server resources include: Dedicated Hosting or VPS above 2GB RAM, >2 core and above 2.0GHz frequency
Low Traffic includes: below 100,000 visitors or 100,000 unique hits
High Traffic includes: above 100,000 visitors or 100,000 unique hits
Note: Caching is important for any server regardless of the traffic and resources.
Low server resources Low Traffic | Low server resources High Traffic | High server resources High Traffic | |
Web server | Any | Nginx/LS/OLS | Nginx/LS/OLS |
Database | Latest (InnoDB engine) | ||
OPcode caching | Zend OPcache | ||
PHP handler | Your Choice | ||
Static Content Optimization | |||
Page Caching | Disk | Disk, FastCGI, LS cache | Varnish, FastCGI, LS cache |
Data Compression | Brotli (3 to 7) | ||
HTTP protocol | Http 2.0 Http 3.0 (preferred) | Http 3.0 | Http 3.0 |
Cache Plugin | Your Choice (Use plugin with compatibility with the selected page caching) | ||
CDN | Your Choice |
Summing It Up
In the end, choosing a stack depends on many factors including server resources, application, traffic, level of expertise, and the list goes on. I have noted that majority of the WordPress users love to use plugins and want to spend more time at managing the website rather than the server (hence that’s why they choose WordPress on the first place).
Why Litespeed?
Litespeed is gradually replacing Apache for most web hosting providers since it’s much easier to configure, already has major performance tweaks done by default, and has a WordPress plugin that does almost every optimization (from the WordPress backend, preferred by many WordPress users). Also, it’s as lightweight as Nginx and beneficial for shared hosting providers since they are notorious for putting hundreds of websites in one server.
Why Apache?
Apache is the most mature one and still the most compatible with WordPress. Hence that is why many hosting companies are using Apache + PHP-FPM + Varnish to avoid Litespeed licensing and avoid headaches coming from Litespeed and Nginx WordPress plugin issues.
Why Nginx?
Nginx works way better for non-PHP apps. It is more secure and lightweight than the other two. It is recommended for people who are just getting started and are not familiar with Apache. An open-source alternative between the old Apache and the paid Litespeed. You will see Nginx + PHP-FPM (with FastCGI caching) on hosting platforms that offer more than hosting PHP apps like WordPress, Joomla, etc, and a simple, scalable and lightweight approach.
Why OLS?
Openlitespeed is the open-source version of Litespeed. This is the best choice for personal websites and unmanaged server. It has the speed of Litespeed and a brilliant GUI for tuning (apart from the server panel). But on a scalability point and with multiple clients, it just forces you to go back to Apache or move to the paid Litespeed.
Other Add-Ons
Use of Memcache or Redis is a must and the choice depends on the server memory and number of websites hosted. Redis does performance better than Memcache.
Zend OPcaching, static and dynamic resources optimization, database optimization (InnoDB), http protocol version (http/2 and http/3), Brotli compression are what every WordPress stack must have despite fighting over having a LEMP or LAMP or LOMP setup.
Hope this article helps you in selecting the best WordPress stack for your scenario. Still need to know about anything regarding the stack? Let me know in the comments.