In this article, we will explore each of the components that make up the optimized WordPress Servers Hosting stack, point out a few potential pitfalls, and explain how each of the components work. Our goal: to get a potential WordPress site owner or webmaster up-to-speed on the important points of this new platform and provide tools to tackle potentially more complex challenges they might later encounter.
WordPress Hosting Stack Overview
Those already familiar with cPanel, the popular web hosting control panel, will feel right at home. Still at the heart of each server, cPanel allows simple (but powerful) control over everything from email account creation to SSH key management. Site owners can add domains, subdomains, and parked domains via the cPanel interface, and the Apache and NGINX configurations will reflect these changes.
NGINX handles all inbound requests for each website. It checks each incoming request for a match in the domain’s page cache. If it finds a match, the cached page displays for the site visitor. In so doing, the server does not have to run any PHP code or execute MySQL queries, making for a speedy response. When possible, NGINX directly serves static assets (such as CSS, scripts, and images).
On the other hand, should NGINX fail to find a cached page matching the request, it passes the request along to Apache and waits for the response. Apache continues to serve as the origin for site content, meaning you can continue to use .htaccess files (e.g., permalinks and redirects will work without a problem, in most cases). Next, the server passes page requests along to a PHP-FPM pool allocated for each domain. The PHP-FPM pool delegates the request to an available worker that executes the actual PHP code (such as WordPress itself). The server then feeds the result back up the chain, and NGINX saves a copy of the response in its cache, speeding up future requests.
- ➊ User’s web browser makes request to NGINX to fetch a webpage.
- ➋ If NGINX fails to find a cached version of the page, or the page has been excluded from caching, NGINX requests the content from Apache.
- ➌ If a PHP script handles a page, Apache sends the request to the domain’s PHP-FPM pool. The PHP-FPM pool takes
.htaccessrewrites and other rules into account, allowing for the use of “pretty URLs” or permalinks. - ➍ The PHP-FPM pool then dispatches the request to an available worker (or spawns a new worker if one is not available). The worker then executes the PHP code.
- ➎ The response travels back up, in reverse, through each of the previous steps, until it returns to the user’s web browser for display.
NGINX
NGINX, a high-performance web server, can completely replace Apache or run alongside it in a reverse-proxy configuration. The WordPress Optimized stack uses the reverse-proxy configuration, meaning that NGINX requests the actual content from Apache. This configuration allows us to perform full-page caching, as well as serve static content (such as images and stylesheets) directly from NGINX. This results in significant speed increases and limits the number of connections to Apache. In other words, this configuration allows the server to deliver cached and static content to the user very quickly.
Caching: How it Works
As mentioned above, when a user visits a page on your website, NGINX first determines whether or not it has a page available in its cache. If so, it checks to see if that page remains valid and has not expired. Note, site owners can control this expiration period via the Cache Manager Plugin. By default, your site will set the expiration time to 4 hours. If a page does not exist in the cache, or you have identified it to the system as a page that should bypass the cache (like a login or checkout page), then the server sends the request to Apache and PHP-FPM, as illustrated above.
To determine which pages NGINX can cache, it examines the headers returned by the server. By default, NGINX ignores Expires and Cache-Control headers. Many WordPress pages return a negative cache time, preventing pages from caching effectively. However, the NGINX Cache Controller WordPress plugin can send X-Accel-Expires headers, which the server will use to set and enforce cache times for specific pages.
By default, certain pages will never cache — specifically, pages that send cookies or use PHP sessions. Therefore, where possible, have any cookies or other dynamic content load asynchronously (via admin-ajax.php). In the Cache Manager Plugin, you also have the ability to match against cookies sent from the user’s browser. This allows us to bypass the cache for logged in users, or for users who have added an item to their shopping cart on a WooCommerce site, for example.
Clearing the Cache
When making changes to your site, or troubleshooting a problem, you may benefit from either clearing a single page or purging the entire cache. In either case, you can easily accomplish this via the Cache Manager Plugin. You can also quickly clear a single page from your browser by prepending /purge to the URI portion. You will then see either a Purge Successful page, or a 404 Not Found page (indicating the page did not exist in the cache). The table below lists a few examples:
| URL | Purge URL | Notes |
|---|---|---|
| https://example.com/ | https://example.com/purge/ | Purges the homepage for example.com |
| https://example.com/2017/01/cool-article | https://example.com/purge/2017/01/cool-article | Purges the page at /2017/01/cool-article |
PHP-FPM
An optimized PHP handler, PHP FastCGI Process Manager (PHP-FPM) provides high performance and lower latency page execution. It does this by maintaining and adjusting an on-demand pool of workers for each domain.
Each PHP-FPM master controls a group of pools, with each pool associated with a single domain or virtual host. Each of these pools then handles a group of workers — the processes that handle the actual execution of PHP code. When the server sends a request to a particular FPM pool, the pool delegates the work to an available worker or spawns a new worker if an existing one is not available (with the on-demand management type). This allows sites that receive a steady stream of traffic to load quicker, as there will typically be a worker available to handle the request. In addition, this architecture allows the workers to share a common pool of memory, permitting the use of opcode caching.
Opcode Caching
By default, your server enables Zend OpCache, PHP’s built-in opcode caching system, for PHP 5.5 and above. Opcode caching works by storing pre-compiled PHP code, which subsequent visitors can later execute again. This saves significant time, CPU usage, and I/O, since PHP does not need to re-interpret and re-compile your PHP code on every single execution.
PHP Configuration
When you add a new user or domain, the server uses the default PHP version. If you wish to experiment with a newer PHP version, or if your application requires an older PHP 5.x version, you can manually select these options from the MultiPHP Manager in cPanel. You can also configure custom PHP options via the MultiPHP INI Editor, or by creating a php.ini file.
Overall, this new platform should offer significant performance gains for most websites (compared to the previous Apache + suPHP stack). The addition of the Cache Manager Plugin will also allow users to further tweak the performance of their sites, to suit their particular needs.
Learn more from our WordPress Hosting Product Guide.
Improve the performance and security of your WordPress website with our new Managed WordPress Hosting plans. Get 40x faster speeds with dedicated resources, server caching, and optimization tools.
High-Performance VPS 99.99% Uptime Free SSL & Dedicated IP Advanced Server Caching
This talks about server-side page caching, but what about browser caching? I’ve read that NGINX ignores Expiry directives in .htaccess – is this true? Is it possible to configure browser caching rules on a shared NGINX server on InMotionHosting?
You should be able to use the mod_expires code in your .htaccess file and our NGINX configuration still pass those on to Apache. If you need a more customizable solution though, you may consider a Cloud VPS or Dedicated server environment where you would have more control over the NGINX configuration. Not that even though NGINX is providing the code to Apache, the browser ultimately decides whether or not to respect your cache requests.
Would the WordPress Optimized stack be recommended for Joomla sites as well?
Since this server setup is optimized for all PHP powered applications, Joomla sites should benefit from the features. Please let us know if you have any further questions.
Thank you,
John-Paul
Where is the process to move an existing wordpress install over to this new stack?
Hello,
Thanks for asking the question about migrating to the WordPress optimized stack. You have to talk with our Customer Service team as it changes your hosting account type. They should then provide a ticket to have your site moved after updating your billing information.
So, how does one set this up on a Dedicated server? Do I just need to turn on the PHP-FPM option under the PHP settings in WHM and then add the NGINX Plugin to my WordPress site?
You would need to request for the WordPress optimized stack. It’s not set up for all hosting solutions nor can it be setup in our other hosting environments.
What needs to be done on a dedicated server to be able to use this functionality?
Since our WordPress Stacks are pre-configured you can simply host your WordPress site on the server. We do recommend using the NGINX Helper WordPress plugin to automatically purge cached pages after making changes.
Thank you,
John-Paul
Sorry, but your answer isn’t very clear. Please clarify: If we need to switch to this new hosting option, how – or where – do we do that? I can’t find anything in my C-Panel that mentions NGINX or WordPress Hosting Stack.
In another response you mentioned that “everything is pre-configured on the server,” but it still isn’t clear if this option automatically happens for those of us with WordPress sites, or if/how/where we need to change something from our end.
Please make your responses clear and specific. Vague and incomplete answers are not helpful.
Hello,
Thanks for asking the question about using the WordPress optimized stack and using the same IP. You have to talk with our Customer Service team as it changes your hosting account type. They should then provide a ticket to have your site moved. The IP address would need to be changed as you would using a different server.
If you are an existing customer on a different hosting plan, then you would need to speak with our Customer Service team as they would need to change your account to the new hosting solution. They would then provide a ticket to have your site moved to the new hosting type. We have several different types of hosting solutions. If you are a new customer then you would request that hosting type and your account would be created with that specific hosting solution. I hope this helps to clarify the confusion.
Hi –
If we currently have a VPS running WordPress sites, what is the best way to migrate to the WordPress Hosting Stack? Could we keep our same IP address?
Thanks, Neal
In my WP i have WP Fastest Cache plugin. In the above article, is Inmotion saying i need or should install this plugin? if yes, i’m not sure i) what the plugin name is ii) does it go on/in my WP site iii) or is it something that is on my inmoation cpanel.
can you clarify? give me advice?
I answered this question earlier. We have a follow-up article in the works that will detail configurations for WordPress caching. For now, the recommendation is to use the NGINX helper which will ensure that pages get cleared from the cache when changes are made. You can still use W3TC — we believe W3TC specifically has an option to purge nginx’s cache, but you’ll need to check their documentation. Usually you wouldn’t really want to use additional caching in WordPress, unless you get a lot of members-only traffic, since users who are logged in will bypass any caching.
Hi! This sounds great. As a reseller hosting WordPress sites, do we need to make any special requests, or is this now implemented across the board? Thanks.
Hello Avi,
You can use the stack for installations other than what Softauclous provides. We do not have a guide on installing other programs, but it would be like any server installation. Follow the installation instructions for the application want to use. If you require further assistance, then please contact our live technical support team (contact info below).
You would need to request for the WordPress optimized stack. It’s not set up for all hosting solutions.
Thanks for the question about using WordPress caching. We have a follow-up article in the works that will detail configurations for caching. For now, the recommendation is to use the NGINX helper which will ensure that pages get cleared from the cache when changes are made. You can still use W3TC — we believe W3TC specifically has an option to purge nginx’s cache, but you’ll need to check their documentation. Usually you wouldn’t really want to use additional caching in WordPress, unless you get a lot of members-only traffic, since users who are logged in will bypass any caching. Hope that helps!
The configuration detailed above is how the WordPress optimized stack is configured. You just have to select the option for your hosting solution.
The configuration detailed above is how the WordPress optimized stack is configured. You just have to select the option for your hosting solution.
There is no additional configuration required in the cPanel, everything is preconfigured on the server.
The WordPress solution is not set up specifically as a reseller solution but you can opt for the VPS version and set it up for reseller purposes.
Will this work with the WordPress plugins like W3 Total Cache or WP Super Cache? Which provides the fastest service?
thanks for this update
1. can I take advantage of this stack for WP installations that are NOT listed with Softaculous?
2. if yes, how? can you please point to a guide on how to set an installation that uses this stack.
Thanks
Avi
So, does all of this happen automatically, or do I have to do something like regenerate WordPress using the new stack?
Is this already active, or do I have to switch to it?
is this available to resellers?
Is any configuraion in the cPanel required for the new platform? If so, are there instructions, tutorial for setting it up?