Use httpd.conf to put any needed WordPress rules. Some studies show it performs up to 6% faster than having Apache run through directories chasing down .htaccess files.
Don’t believe me?
- Why you should not use .htaccess (allowoverride all) in Production
- Performance impact of .htaccess and rewrite rules?
- Daniel Morell’s awesome Don’t Use .htaccess Unless You Must
First, at Performant Press, we give love to our server. Not hate.
Hatred is making our server work harder on every page load just because we didn’t want to do things like identify the server to the code, use reasonable constants, or basically, be a developer.
Initially, WordPress doesn’t include an .htaccess file, but it’s created during install, and updated whenever you update your Permalink structure.
It does this through the use of several files in Wordpress:
There are two corresponding class files:
Additionally, there are two network files for those running WordPress on a network of other WordPress sites:
All of these will need to be cleaned out or modified. Why?
Astute observers will just remark that they can set this directive in httpd.conf:
That will prevent Apache from looking for .htaccess files. Which will make Apache more performant before WordPress even comes into the picture.
However, WordPress will continue to modify and run unnecessary PHP to build out an .htaccess file.
Worse, Wordpress won’t help those who are not Apache experts as to what code they should put in their httpd.conf file.
Even though WordPress won’t have access to httpd.conf or be able to write to it ever, it should still not waste time writing to a non-usable .htaccess file, but instead instruct the WordPress administrator on what to put into httpd.conf and how to restart the server (which is required to have changes to httpd.conf recognized by Apache).
There are three main reasons WordPress uses .htaccess.
No access to httpd.conf
Most shared hosting customers don’t have access to httpd.conf and therefore, won’t be able to use anything but “ugly” URLs.
However, that’s a ‘design’ fault of WordPress, I feel, and I have an even faster solution to that (to be shared later).
WordPress strives to be mostly server-agnostic. In theory, it’s more inline with WordPress’s philosophy of “democratizing publishing” to make it’s software more easily portable to any server.
This, however, is best for bloggers and small business websites, but not so great for larger, more highly visited websites. They already have complex server management scenarios. Portability isn’t a requirement or need for them.
For instance, take a look at Syed’s recent post about how he runs WPBeginner fast: How We Made WordPress Faster than Static Site Generators
At one point, he’s got an image showing some of the backend operations used to keep WPBeginner zipping along:
Does that look like a website setup where portability is a consideration? They’ve already spent hundreds of hours setting that up, and thousands of dollars per month to fine-tune that operation. Keeping Apache from having to seek .htaccess or WordPress from having (now bloated) code to write .htaccess files would only take an hour, especially if there were a Performant Press version of WordPress that did that already for them.
WPBeginner is hardly alone. Democratizing Publishing is a great motto for bloggers, but for the millions of businesses who run critical operations on their WordPress website, it’s out of touch with their needs. They need fine-tuned, fast, performant installations of WordPress.
WordPress was an early adopter of mod_rewrite, the Apache module that allowed internal links to hide their true nature, and instead to use what we now call “pretty” permalinks.
However, due to the way WordPress and other PHP content management systems initially created links from database queries, the thinking at that time was to simply “hide”, via mod_rewrite, links that would otherwise look like this:
Go ahead and click that. That’s the real URL of this post. It’s a query string call to a post with an ID of 24 in the wp_posts database. Which is this post.
Nothing wrong with it, but it’s not quite as catchy or memorable as the Permalink version of this post, which contains the title:
However, the second one absolutely relies upon mod_rewrite being enabled, and of course Apache using some muscle to do the heavy lifting.
We will talk about Permalinks later and how WordPress could even more performant, but for now, just realize that WordPress’s love of friendly permalinks set in motion the idea that WordPress administrators would one day be able to just click an option right in the Admin panel to setup what kind of permalinks they wanted.
In other words, the GUI (Graphical User Interface) of the WordPress administration section would allow anyone with an Admin role to be able to setup, and later alter, the permalink structure of WordPress. Quite literally, on the fly.
For that to work, WordPress would need immediate write access to some place where the server would recognize any changes to the Permalink structure (which precluded httpd.conf), and of course, the server could not reboot (which would be required for an httpd.conf change).
It all had to work here:
Performant Press needs a better option
However, if you want to run a more performant WordPress installation, you don’t need the GUI admin panel to define your permalink structure, nor do you need the code in the files above.
You can put your rewrite rules in httpd.conf (or in the VirtualHosts file if you’re running more than one website on the server)
Conclusion: If you’re paying for managed WordPress hosting, a VPS, a dedicated server, or anything more complicated, you should not be then setting your site backwards on performance by continuing to use .htaccess.