Quantum Ink

Writing about the future as it unfolds.

.htaccess file optimizing WordPress performance on Linux servers

Understanding .htaccess Performance Rules for WordPress

, , , ,

Series: WordPress Performance on DirectAdmin (Rocky Linux 9)

Phase 5: Apache & Server Layer — Part 18 of 30

Introduction

WordPress relies heavily on its .htaccess file for URL rewriting, caching, and other performance-related directives when running under Apache. On DirectAdmin-managed servers with Rocky Linux 9, understanding and optimizing .htaccess content is critical for site speed and reliability. This article provides sysadmins with a practical approach to tuning .htaccess for WordPress performance, with special attention to DirectAdmin specifics, safe starting values, and reproducible testing.

.htaccess and DirectAdmin: Key Considerations

DirectAdmin typically provisions each WordPress domain with its own Apache virtual host. By default, DirectAdmin uses PHP-FPM pools for each domain on Rocky Linux 9, potentially with NGINX as a reverse proxy. The .htaccess file is honored only by Apache; NGINX ignores it. Key paths for a DirectAdmin WordPress install on Rocky 9 are usually:

  • /home/USERNAME/domains/DOMAIN/public_html/.htaccess
  • Apache configs: /etc/httpd/conf/extra/httpd-includes.conf (or panel-managed templates)

Changes to .htaccess take effect immediately after saving, but certain template or server-level changes may require an Apache reload. For per-domain tuning, always edit the specific site’s .htaccess file.

Default WordPress .htaccess Rules

A standard WordPress .htaccess on DirectAdmin looks like:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

This enables “pretty permalinks” and routes all non-existent files or directories to index.php. These rules are required for basic WordPress operation but do little for performance.

Performance-Related .htaccess Directives

To improve performance, consider the following .htaccess directives:

  • Browser Caching (mod_expires, mod_headers): Instructs browsers to cache static assets.
  • Compression (mod_deflate): Enables gzip compression for text assets.
  • Conditional Rewrites: Reduces backend load by serving static files directly.
  • Hotlink Protection: Prevents external domains from consuming bandwidth.

Good Starting Values

Below is a safe, idempotent set of rules to add just above the WordPress block in .htaccess. Adjust paths and MIME types as needed for your site:

# BEGIN Performance
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpg "access plus 1 month"
  ExpiresByType image/jpeg "access plus 1 month"
  ExpiresByType image/gif "access plus 1 month"
  ExpiresByType image/png "access plus 1 month"
  ExpiresByType text/css "access plus 1 week"
  ExpiresByType application/javascript "access plus 1 week"
</IfModule>

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/json
</IfModule>

# END Performance

Applying .htaccess Changes Safely

  1. Backup current .htaccess: 
    sudo cp /home/USERNAME/domains/DOMAIN/public_html/.htaccess /home/USERNAME/domains/DOMAIN/public_html/.htaccess.bak
  2. Edit .htaccess: 
    sudo vi /home/USERNAME/domains/DOMAIN/public_html/.htaccess
  3. Insert or update performance rules as shown above.
  4. Test Apache configuration syntax (no downtime): 
    sudo apachectl configtest

    If errors are reported, revert to the backup:

    sudo mv /home/USERNAME/domains/DOMAIN/public_html/.htaccess.bak /home/USERNAME/domains/DOMAIN/public_html/.htaccess
  5. No need to reload Apache for .htaccess edits; changes are immediate.

Warning: Editing .htaccess incorrectly can break site functionality. Always validate syntax and have a backup before applying changes.

Testing .htaccess Performance Impact

Checklist for Validation

  • Verify site loads (front and admin URLs).
  • Test cache headers:
    • curl -I https://yourdomain.com/wp-content/themes/your-theme/style.css
    • Look for Expires: and Cache-Control: headers.
  • Test gzip compression:
    • curl -H 'Accept-Encoding: gzip' -I https://yourdomain.com/
    • Confirm Content-Encoding: gzip is present.
  • Run a simple load test (non-destructive):
    • wrk -t2 -c20 -d30s https://yourdomain.com/
  • Check Apache and error logs for issues:
    • sudo tail -f /var/log/httpd/error_log
    • sudo tail -f /home/USERNAME/domains/DOMAIN/logs/error.log
  • Use WP-CLI to verify WordPress isn’t broken:
    • sudo -u USERNAME wp --path=/home/USERNAME/domains/DOMAIN/public_html core check-update

DirectAdmin, Templates, and .htaccess

DirectAdmin manages Apache virtual host templates via /usr/local/directadmin/data/templates/. If you wish to apply performance rules globally (to all new WordPress sites), you can customize these templates. Example (editing the virtual_host2.conf custom template):

  1. Copy the template to the custom directory: 
    sudo mkdir -p /usr/local/directadmin/data/templates/custom
sudo cp /usr/local/directadmin/data/templates/virtual_host2.conf /usr/local/directadmin/data/templates/custom/
  2. Edit to include global .htaccess snippets or server-level equivalents.
  3. Rebuild configs and reload Apache (risky, causes brief downtime): 
    sudo /usr/local/directadmin/custombuild/build rewrite_confs
sudo systemctl reload httpd

Warning: Changing templates impacts all future virtual hosts and may affect all hosted sites. Test on a non-production server first.

Advanced: Move Performance Rules to Server Level

For best efficiency, move common performance directives from .htaccess to the main Apache config or per-site <Directory> blocks. This reduces per-request file parsing overhead. However, this approach requires server admin access and careful editing:

  1. Edit the main config or use DirectAdmin’s custom vhost includes (e.g. /usr/local/directadmin/data/users/USERNAME/httpd.conf or via panel customizations).
  2. Insert the performance rules inside the relevant <Directory /home/USERNAME/domains/DOMAIN/public_html> block.
  3. Syntax check and reload Apache:
  4. sudo apachectl configtest
sudo systemctl reload httpd
  5. Validate as above with curl and WP-CLI.

Common Pitfalls and Mitigation

  • Placing rules in the wrong order can break permalinks or plugin rewrites. Always keep the standard WordPress block intact.
  • Overly aggressive caching can prevent updates from appearing. Use moderate cache lifetimes initially (1 week for CSS/JS, 1 month for images).
  • DirectAdmin’s NGINX reverse proxy does not read .htaccess. For NGINX, similar rules must be added to NGINX config templates, which is outside this article’s scope.

Summary Checklist

  • Backup .htaccess before editing.
  • Apply safe, tested performance rules as shown above.
  • Validate with curl, load testing, and WP-CLI.
  • Monitor logs for errors after changes.
  • For global changes, use DirectAdmin templates with caution.

Note: This article offers general technical guidance. Validate all configurations in a safe environment before applying them to production.

Previous: Apache Performance Tuning for WordPress on DirectAdmin

Next: HTTP/2 and HTTP/3 on WordPress: What Actually Improves Speed

Smart reads for curious minds

We don’t spam! Read more in our privacy policy