Introducing .htaccess Caching in MAx Cache: 20% Faster Apache Page Loads

Hosting servers with Apache can now handle 18% more traffic with 20% faster response times, without any configuration changes. Today we’re announcing the beta release of .htaccess cache, a new feature in MAx Cache that compiles .htaccess files into memory, eliminating the per-request disk I/O that slows down every page load on a server.

This new feature builds on the MAx Cache for Apache module we released in December 2025 and the MAx Cache for Nginx module that followed in early 2026. If you already run MAx Cache for Apache, you get .htaccess caching with a single package update. No new packages, no new configuration.

This release also adds CloudLinux 10 support across the entire MAx Cache stack: Apache module, Nginx module, and .htaccess caching..

Why .htaccess Files Are a Performance Problem

On hosting servers with Apache, .htaccess files are everywhere. WordPress uses them for permalinks. AccelerateWP uses them for caching rules. Security plugins, control panels, and custom configurations all add their own directives.

The problem is that Apache re-reads and re-parses these files on every single request. It walks the directory tree from top to bottom, opening each .htaccess along the way. A single page load can trigger half a dozen disk reads before Apache even begins serving content. Multiply that by every visitor, every page, every site on the server, and the overhead adds up fast.

How .htaccess Caching Works

It compiles .htaccess files once and keeps the result in memory. On subsequent requests, Apache applies the cached rules directly. No disk reads, no re-parsing.

The cache fills itself automatically as traffic arrives. There is no startup cost and nothing to pre-configure. The first request to any path compiles its .htaccess chain into memory, and every request after that skips the disk entirely.

Instant Change Detection

Caching is only useful if changes still take effect immediately. The new feature includes a lightweight watcher daemon (htcache-watchd) that monitors the filesystem for .htaccess changes in real time. When a WordPress admin updates permalink settings or a control panel modifies access rules, the watcher picks up the change and signals Apache to recompile, typically within milliseconds.

On CloudLinux 9 and 10, the watcher detects all types of changes: edits, deletes, renames, and moves. On CloudLinux 7 and 8, the watcher detects edits in real time, while a periodic fallback check catches deletes and renames (default: 60 seconds).

Performance Gains

We benchmarked .htaccess caching on a 3,000-vhost server with 100 concurrent users, which is representative of a production shared-hosting environment. All tests ran over HTTPS with Apache Worker MPM.

With a realistic workload (page + all assets)

When each page load includes CSS, JS, and images (~78 static asset requests per page), .htaccess caching adds on top of MAx Cache page caching:

• +18% requests per second (19,660 → 23,172 RPS)

• 20% faster average TTFB (25.7 → 20.5 ms), 20% faster at p95

• 22% less CPU per request (39,332 → 30,568 µs)

The gain is large because .htaccess elimination speeds up every request, both cached pages and static assets alike. With ~78 asset requests per page, the savings multiply across the entire page load.

What  .htaccess Caching Costs

~19 MB shared memory for 300 active domains (~65 KB per domain). Memory scales with active sites, not total configured sites. Inactive domains consume nothing.

What This Means for Hosting Providers

• Higher hosting density: 18% more throughput and 22% less CPU per request means more sites on the same hardware. The cost: ~65 KB shared memory per active domain.

• Faster page loads: 20% lower TTFB translates directly into better user experience, even for requests that still go through PHP.

• Zero configuration:  .htaccess caching is on by default. The watcher starts automatically. Most servers need no tuning at all.

Better Together: MAx Cache Page Caching + .htaccess Caching 

The MAx Cache page caching and .htaccess caching engines tackle different bottlenecks, and they stack:

On a server running both, a request for a cached page never touches the disk for .htaccess and never invokes PHP. The entire response is served from memory.

OS Support

 .htaccess caching supports CloudLinux 7, 8, 9, and 10.

This release also brings full CloudLinux 10 support to both MAx Cache for Apache and MAx Cache for Nginx.

How to Get Started

The feature ships inside the ea-apache24-mod_maxcache package. If you already have MAx Cache for Apache, just update the package, and .htaccess caching enables itself automatically.

New Installation

1. To install packages, run the following commands:

yum install libmaxcache maxcache-htcache-watchd --enablerepo=cloudlinux-updates-testing

yum install ea-apache24-mod_maxcache --enablerepo=cl-ea4-testing


That’s it. After installation:

• The module loads into Apache automatically.

• The filesystem watcher starts monitoring for .htaccess changes.

•  .htaccess caching is enabled by default. No additional steps required.

For advanced configuration options, see the documentation.