Performance Glossary
.htaccess, and the Price of Reading It Every Time
You want redirects, headers and rewrite rules live without a restart, without paying for a directory walk on every asset the page pulls in.
The short answer
.htaccess is a per-directory configuration file that Apache and LiteSpeed re-read on every request, which is precisely why a rule you save is in force on the next page load with nothing to reload or restart.
That same design is the cost. The server checks for the file in every directory along the path to the requested resource, so a rule set worth having belongs at the document root, not scattered five levels deep.
By the HostingFast team · Reviewed 12 August 2026
0
Terms, measured not asserted
100+
Entries wired together
Real
Working configuration snippets
Free
Free to read, always
WordPress writes its permalink rules here. Redirects accumulate here. Hardening measures — blocking direct access to files, forcing HTTPS, setting security headers — are applied here. There is no service to restart and no deploy step, which makes it the fastest configuration surface most site owners will ever touch.
The reach that makes it useful makes it sharp. A malformed directive returns 500 for the entire tree beneath it until somebody reverts the change, so the safety procedure is one line long: keep a copy before you type.
What the server does on each request
For a request to /wp-content/themes/x/style.css the server looks for .htaccess in the document root, then in wp-content, then in themes, then in x. Each of those is a filesystem check, repeated for every asset on the page. On NVMe those checks are cheap, but they are not free and they scale with tree depth.
That is the argument for consolidation rather than avoidance. One rule set at the root beats four sets sprinkled down a path, and directives that never change — long cache lifetimes for static assets, for instance — are better still when they live in server configuration you are not re-reading.
The rules that earn their place
Cache-Control and Expires headers for static assets are the highest-value block you can add, because they take repeat requests off the network entirely. Compression directives are next, then the security headers, then the redirects. Order matters: put the cheapest matches first, because the file is evaluated top to bottom on every hit.
Keep the WordPress permalink block where WordPress expects it, between its own markers. Rules dropped inside those markers get overwritten the next time permalinks are saved, and the resulting mystery costs far more time than the two lines saved.
Debugging a 500 you just caused
The error log names the offending line — check the log in your panel before touching anything else, because the message usually reads 'Invalid command' followed by the exact directive. A typo in a module-specific directive is the classic cause, especially when a snippet assumed a module the server does not load.
Wrap anything module-dependent in an IfModule test so a missing module degrades quietly instead of taking the site down. And restore your copy first, investigate second: the site should be answering while you read the log, not after.
Confirming the headers you think you set
curl -I against a static asset shows you exactly which headers the server is emitting. If Cache-Control is missing, the directive did not apply — either the module is absent, or another block further down is overriding it, or the request never reached the directory you edited.
Repeat the check after every edit rather than trusting the file. On our platform LiteSpeed reads .htaccess the Apache way, so published recipes work here unchanged, and the response header is the only proof that a given line is doing anything at all.
Configuration answers, with the caveat attached
Snippets are easy to find and hard to trust. Each entry here says what the directive does, which module it needs, and how to check that the server actually applied it.
You get SSH, Git and Composer on the developer-focused plans, so the file you are editing is one you can version, diff and restore rather than one you overwrite in a browser textarea.
- Directives with their modules named
- The header check that proves it applied
- Failure modes before you hit them
- Written from real ticket traffic
Why HostingFast
Standard on every plan
Snippets with their prerequisites
Every directive is paired with the module it needs, so a copied recipe fails loudly instead of silently.
The verification step included
A rule is not done when it is saved. Each entry names the curl or panel check that proves it took effect.
Per-request cost explained
Why .htaccess applies instantly, what the server does to make that true, and where the overhead lives.
Recovery before experimentation
How to get a site answering again after a bad directive, in the order that gets you there fastest.
LiteSpeed compatibility spelled out
Which Apache behaviour carries over on our platform, so published recipes can be trusted as written.
Linked to the next configuration file
Where a rule belongs somewhere else entirely, the entry points at the term that covers it.
Quick Start
From order to online
- 1
Copy the file before you open it
One command over SSH, or one download from File Manager. This is the entire disaster recovery plan for the next ten minutes.
- 2
Add one block and reload
Save a single change, load the site, and confirm a 200. Two blocks at once turns a five-second diagnosis into a bisect.
- 3
Prove it with curl -I
Request the affected URL and read the response headers. If the header you added is not there, the directive is not applying, whatever the file says.
Built In
Loaded onto every plan
- LiteSpeed compiled into the server, not a caching plugin bolted on afterwards
- SSH, Git and Composer on the developer-focused plans
- PHP version selectable per site, switched from the control panel in seconds
- Staging you can clone, break and throw away before anything reaches live
- NVMe on every tier — the entry plan runs the same drives as the top one
- Free SSL on every plan, reissued automatically well before it can expire
- Daily backups with a self-service restore you run yourself from the panel
- A human on support at any hour, including for the awkward questions
- DDoS filtering absorbed at the network edge, before it reaches your workers
- Money-back cover: 30 days on hosting plans, 7 on reseller
Frequently Asked
What people ask us most often
Is .htaccess slower than putting the same rules in server config?
Marginally, and the difference is measurable rather than theoretical: the server performs a lookup in each directory on the path for every request. Consolidate at the document root and the cost is negligible on NVMe. Scatter rules through a deep tree and you have created work for every asset the page loads.
Do my Apache rules still work on LiteSpeed?
Yes — LiteSpeed reads .htaccess with Apache semantics, which is why the ecosystem's rewrite, header and redirect recipes run here without translation. What differs is the caching layer in front, so purge after a rule change or you will keep testing against the previous response.
Is staging an add-on, or part of the plan?
Part of it, on the plans that carry it. Clone the live site, do the work on the clone, then push it live once it behaves. That is the whole difference between hoping an update survives contact with production and knowing it does before a visitor ever meets it.
Do I get shell access on shared hosting?
On the developer-focused plans, yes — SSH, Git and Composer included. Every account runs isolated, so a shell session reaches your files, your databases and your processes and nothing beyond them. That is what makes WP-CLI and push-to-deploy workflows practical without renting a VPS.
Keep reading
301 Redirect
The permanent forward, and what each hop in the chain costs in round trips.
HTTP Status Codes
The three-digit verdict on every response, and which ones your logs should never show.
How to Harden a Site With .htaccess
Rules worth adding, in order, with the one that quietly breaks WordPress flagged.
VPS Hosting
KVM virtual servers with root access, DDoS filtering and one flat monthly price.
OpenCart Hosting
One-click OpenCart on storefront-tuned PHP, with free SSL and staging included.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Edit the file, reload the page, read the header.
LiteSpeed with full .htaccess support, SSH on developer plans, and staging to try the rule on first.
View VPS Hosting plans