EN
Webmail

Apache or Nginx for WordPress: Choosing and Tuning a Web Server

Apache or Nginx for WordPress: Choosing and Tuning a Web Server

Apache or Nginx is one of the first decisions when you run your own server for WordPress, and it is also one of the most argued about. Both are mature, widely used, free web servers that can serve a business site very well. The better question is not which one wins in a benchmark, but which one fits your team, your hosting setup and the way your site is built. A well-tuned Apache setup will beat a badly configured Nginx one, and the other way round.

This guide explains how the two servers differ in practice, what that means for WordPress, how PHP fits in, which settings matter most for performance and how to change from one to the other without downtime. It supports our server administration work and assumes you have shell access to a Linux server, whether it is a virtual private server or a dedicated machine.

What a Web Server Does for WordPress

A web server accepts connections from browsers, serves static files such as images, stylesheets and scripts directly and passes requests for dynamic pages to PHP. For WordPress, almost every page view involves PHP and the database, so the web server is only one part of the chain. Much of the speed you see depends on PHP, the database, caching and the theme and plugins, rather than the web server itself.

That is worth remembering before you change anything. If your pages are slow because of heavy plugins or missing caching, switching from Apache to Nginx will not fix it. Check where time is spent first. Our guide to website caching explains the layers that usually matter more than the choice of web server.

What the web server does decide is how connections are handled, how configuration is organised, how much memory it uses under load, how it talks to PHP and which modules are available. Those points drive the choice.

How Apache Works

Apache HTTP Server is the older of the two and has a very large ecosystem. It uses multi-processing modules, known as MPMs, to decide how it handles connections. The three well-known ones are prefork, worker and event. The Apache MPM documentation describes them. Prefork uses a process per connection and is needed by some older PHP module setups. Worker and event use threads and handle many connections with less memory, and event is designed to make better use of idle keep-alive connections.

A key feature of Apache is the .htaccess file, which allows per-directory configuration without touching the main server configuration. WordPress uses it by default for pretty permalinks, and many plugins write rules into it for redirects, caching headers and security. This is convenient, especially on shared hosting where users cannot edit the main configuration. The cost is that Apache must check for these files on every request in every directory along the path, which adds overhead.

Apache supports a large set of modules, including mod_rewrite for URL rewriting, mod_headers, mod_expires and mod_security as a web application firewall option. If your stack depends on rules written for Apache, staying on Apache avoids translating them.

How Nginx Works

Nginx was designed around an event-driven model in which a small number of worker processes handle thousands of connections. It is very efficient at serving static files and at acting as a reverse proxy or load balancer. Its configuration is kept in the main files, organised in server and location blocks, and it has no equivalent of .htaccess. Changes require editing the configuration and reloading the server, which needs administrator access.

Nginx does not run PHP inside itself. It passes requests to a separate PHP FastCGI Process Manager, called PHP-FPM, over a socket or a local network port. This separation is a strength, because you can tune, restart and limit PHP independently of the web server, and it is also available for Apache. The Nginx documentation covers the directives and modules, and WordPress publishes its own guide to configuring Nginx for WordPress.

Because there is no .htaccess, rules that plugins would write for Apache are not applied automatically. Permalinks, redirects, security rules and caching headers must be written into the Nginx configuration by an administrator. This makes Nginx less friendly for site owners who change settings through plugins, and more predictable for administrators who manage the configuration in version control.

Apache and Nginx Compared for WordPress

TopicApacheNginx
Configuration styleMain files plus per-directory .htaccessCentral configuration with server and location blocks
WordPress permalinksWork out of the box through .htaccess and mod_rewriteNeed a try_files rule in the server block
Plugin-written rulesApplied automatically when they write to .htaccessNot applied; an administrator must translate and add them
Static file handlingGood, especially with the event MPMVery efficient with low memory use
PHP integrationModule or PHP-FPM through FastCGIPHP-FPM through FastCGI
Memory under many connectionsDepends on MPM; prefork uses the mostGenerally lower for the same number of connections
Built-in page cachingThrough modules or external layersFastCGI cache and proxy cache are built in
Shared hosting fitCommon, because users can manage .htaccessLess common for end users without server access

The practical picture is that neither is fundamentally slow or fast for WordPress when PHP, the database and caching are set up properly. The main differences are in configuration style, memory use under high concurrency and how easily non-administrators can change behaviour.

PHP-FPM: The Part That Often Matters More

Whichever web server you pick, use PHP-FPM for PHP on a modern setup. Running PHP as a module inside Apache with the prefork MPM ties PHP’s memory to every Apache process, including those that only serve images. With PHP-FPM, static requests do not touch PHP at all, and you control the number of PHP workers separately.

The main PHP-FPM settings are the process manager mode and the number of child processes. The usual modes are static, dynamic and on-demand. Dynamic keeps a number of workers available and adjusts between a minimum and a maximum. A common mistake is setting the maximum too high for the available memory, so that a traffic spike pushes the server into swapping. To size it, measure the average memory used by a PHP worker on your site and divide the memory you can spare for PHP by that figure.

Enable OPcache, which keeps compiled PHP code in memory, and give it enough space for your plugins and theme. Watch the slow log for requests that take a long time and the status page for queue length. A queue of waiting requests means workers are busy, either because there are too few or because some requests are slow. Our overview of server capacity planning shows how to work out how much headroom you need.

Caching at the Web Server Level

For most WordPress sites, page caching delivers the largest speed gain. A cached page is a ready-made HTML file that the web server can send without running PHP or the database. You can achieve this through a WordPress caching plugin, through a server-level cache or through a content delivery network in front of the site.

Nginx has built-in FastCGI caching, which stores responses from PHP-FPM and serves them directly. It needs rules to avoid caching pages that must stay dynamic: logged-in users, carts, checkouts and forms. If those rules are wrong, a customer may see another visitor’s content, so test them carefully. Apache can do similar work with modules or with a caching layer in front of it, and a plugin-based cache works with both.

Set long cache lifetimes for static assets such as images, fonts, scripts and stylesheets, and use versioned file names so that updates take effect. Enable compression for text content, with gzip or Brotli where available. These settings are simple and apply to both servers.

Security and Maintenance Differences

Both servers can be run securely, and most real-world problems come from outdated software, weak passwords and vulnerable plugins rather than from the server brand. Keep the operating system packages and the web server updated, disable modules you do not use, hide version details if you wish and restrict access to sensitive files. Our guide to server security hardening lists the basics.

With Apache, take care that .htaccess rules from plugins do not introduce conflicts or expose files. With Nginx, make sure that all the protections you previously had in .htaccess, such as blocking access to configuration files, logs and backup archives, are rewritten as location rules. A frequent migration mistake is leaving backups or configuration files accessible because an Apache rule was not translated.

Always validate configuration before reloading. Apache provides apachectl configtest and Nginx provides nginx -t. Reload, not restart, to avoid dropping active connections. Keep configuration under version control so that you can see what changed and revert quickly.

Common Setups

  • Apache with event MPM and PHP-FPM. A flexible, familiar option that keeps .htaccess compatibility and avoids the memory cost of the prefork MPM.
  • Nginx with PHP-FPM. A lean option for administrators who manage configuration centrally and want built-in FastCGI caching.
  • Nginx in front of Apache. Nginx handles static files, connections and caching, and passes dynamic requests to Apache, which keeps .htaccess behaviour. This combination is common on hosting control panels, at the cost of running two servers.
  • A CDN in front of either. A content delivery network serves static files and cached pages near the visitor and reduces load on your origin server, whichever web server you use.

Other servers exist, such as LiteSpeed and OpenLiteSpeed, which are compatible with Apache rewrite rules and often bundled with specific hosting products. They are worth a look if your host offers them, but they are a separate choice with their own documentation.

How to Decide

Start with who will manage the server. If site owners or developers change settings through plugins and rely on .htaccess, Apache fits better. If a dedicated administrator controls the configuration and wants central, version-controlled files, Nginx is attractive.

Then look at the load. For a small business site with moderate traffic, either server on a properly sized machine is more than enough. If you expect heavy concurrency, many static assets or you need a reverse proxy and load balancing, Nginx has advantages. If you host many separate sites for different owners, Apache’s per-directory configuration is convenient.

Finally, consider the stack you already have. A control panel that manages Apache for you, existing rules written for Apache and a team that knows it well are strong reasons to stay. The cost of switching includes translating rules, retesting every redirect and security rule and retraining people. Do not switch for a small theoretical gain.

If you are choosing a hosting type at the same time, our article on choosing between shared, VPS and dedicated hosting helps with the larger question.

Switching Without Downtime

  1. Build the new configuration on a staging server or a separate port, with the same PHP version and the same site files.
  2. Translate every rule: permalinks, redirects, security blocks, caching headers, compression, upload limits and timeouts.
  3. Test with a list of important URLs: the home page, posts, category pages, search, the admin area, login, the REST API, feeds, sitemaps, image files and any custom endpoints.
  4. Check that sensitive files are not served: configuration files, logs, backups and version control folders.
  5. Compare response headers and status codes between old and new for each test URL.
  6. Run a load test appropriate to your traffic and watch memory, CPU and PHP-FPM queue length.
  7. Plan the switch for a quiet period, lower DNS lifetimes in advance if the address changes and keep the old configuration ready for a quick rollback.
  8. After the switch, watch error logs, response times and the results in Search Console for a week.

A server change is a good moment to review your patch management routine as well, since new configuration needs a maintenance plan to stay healthy.

Frequently Asked Questions

Is Nginx faster than Apache for WordPress?

Not by itself. Nginx uses less memory under many connections and serves static files efficiently, but for WordPress most of the time is spent in PHP and the database. Caching and PHP-FPM tuning usually matter more than the web server.

Can I use .htaccess with Nginx?

No. Nginx ignores .htaccess. Rules must be written in the Nginx configuration, and changes need administrator access and a reload.

Which is better on shared hosting?

Shared hosting usually runs Apache or a compatible server because users can manage .htaccess without server access. On a VPS or dedicated server you can choose freely.

Do I need PHP-FPM?

For a modern setup, yes. It separates PHP from the web server, lets you tune workers on their own and avoids loading PHP into every web server process. It works with both Apache and Nginx.

Can I run Nginx in front of Apache?

Yes, and it is a common setup. Nginx serves static files and caches, while Apache runs the dynamic parts and keeps .htaccess support. The price is more components to maintain.

How do I check my configuration before applying it?

Use apachectl configtest for Apache and nginx -t for Nginx. Then reload the service rather than restarting it, so that active connections are not dropped.

The Bottom Line

Apache or Nginx is a choice about management style and fit, not a race. Apache offers familiarity and .htaccess flexibility, and Nginx offers lean, central configuration and built-in caching. Whichever you pick, use PHP-FPM, enable OPcache, add a sensible page cache, keep software updated and test every configuration change before it goes live. If you would like an experienced administrator to review or migrate your WordPress server, get in touch through our contact page.