New Hosting Revenue — Unlocked!
Launch your own professional WordPress services without upfront
investment or headcount. Powered by Seahawk — Branded as you.

Introducing HTCache in MAx Cache: Faster Apache Page Loads by Caching .htaccess in Memory

htcache_in_max_cache

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 HTCache, 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.

HTCache 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 HTCache 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 HTCache.

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.

 

What HTCache Does

HTCache 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. HTCache 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 HTCache 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), HTCache 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 HTCache 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: HTCache is on by default. The watcher starts automatically. Most servers need no tuning at all.

 

Better Together: HTCache + MAx Cache Page Caching

HTCache and the MAx Cache page caching engine tackle different bottlenecks, and they stack:

  • HTCache eliminates the disk I/O cost of reading .htaccess files on every request.

  • MAx Cache page cache eliminates PHP execution for cached WordPress pages.

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

HTCache 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

HTCache ships inside the ea-apache24-mod_maxcache package. If you already have MAx Cache for Apache, just update the package. HTCache 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.

  • HTCache is enabled by default. No additional steps required.

For advanced configuration options, see the HTCache documentation.

 

Looking for Feedback

We're eager to hear how HTCache performs in your hosting environment. As this is a beta release, your feedback helps us refine HTCache before general availability. Please share your experience through the CloudLinux Feature Portal.

Follow our blog for updates on our progress and the latest releases.

Introducing HTCache in MAx Cache: Faster Apache Page Loads by Caching .htaccess in Memory

htcache_in_max_cache

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 HTCache, 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.

HTCache 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 HTCache 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 HTCache.

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.

 

What HTCache Does

HTCache 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. HTCache 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 HTCache 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), HTCache 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 HTCache 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: HTCache is on by default. The watcher starts automatically. Most servers need no tuning at all.

 

Better Together: HTCache + MAx Cache Page Caching

HTCache and the MAx Cache page caching engine tackle different bottlenecks, and they stack:

  • HTCache eliminates the disk I/O cost of reading .htaccess files on every request.

  • MAx Cache page cache eliminates PHP execution for cached WordPress pages.

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

HTCache 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

HTCache ships inside the ea-apache24-mod_maxcache package. If you already have MAx Cache for Apache, just update the package. HTCache 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.

  • HTCache is enabled by default. No additional steps required.

For advanced configuration options, see the HTCache documentation.

 

Looking for Feedback

We're eager to hear how HTCache performs in your hosting environment. As this is a beta release, your feedback helps us refine HTCache before general availability. Please share your experience through the CloudLinux Feature Portal.

Follow our blog for updates on our progress and the latest releases.

imunify-logo

WEB SERVER SECURITY BLOG

Subscribe to CloudLinux Newsletter