In this article, you can learn about the following:
This article explains the relationship between NGINX and WordPress Hosting. It also describes what the NGINX Cache Manager advanced options (in cPanel) do. By the end of this article, you will be familiar with how to configure these settings to optimize WordPress website performance.
WordPress Hosting and NGINX
NGINX is the MVP (Most Valuable Program) of the WordPress Hosting stack by InMotion Hosting. As a reverse proxy, NGINX improves website performance by managing cached content.
In a standard LAMP stack, Apache is in charge of processing PHP scripts and delivering website content to the user’s browser. This setup can potentially cause a bottleneck during heavy traffic. Alternatively, the WordPress Hosting stack developed around NGINX manages cached content and serves the webpage to reduce Apache’s workload.
Out of the box, NGINX and Apache work well enough together to serve your website faster. However, tweaking the Cache Manager settings can exponentially improve load time. Read on to learn more about the NGINX Cache Manager advanced settings and how they can improve your website’s performance.
Advanced Options
Follow the steps below to navigate to where the advanced options are available.
- Log into your cPanel.
- Click on Cache Manager under the Software heading.
- Be sure to select the correct domain from the Domain drop-down menu. Then, click on the Options tab.
- Scroll down and then click on the Show Advanced Options button.
Proxy Protocol: This setting allows you to select whether your website should force HTTP or HTTPS. To use the secure protocol (https://), you must have a valid SSL Certificate installed.
ModSecurity Response Cache Time: By default, ModSecurity (406) errors are not cached. If your website is receiving an influx of connections blocked by ModSec, then you can mitigate excessive resource usage by caching the response for the specified amount of time.
404 Error Cache Time: Here, you can set how long the cache will wait before NGINX sends a request for content with a 404 error. A higher number helps mitigate excessive usage from bots crawling your website. A lower number helps clear out 404s for content served up by a third-party Content Delivery Network (CDN).
Max requests per minute and Rate limit Path: These settings work in tandem to reduce the frequency of fulfilling specified requests. For instance, to mitigate excessive resource usage generated by WordPress’s xmlrpc.php script.
First, enter the path to the xmlrpc.php file in the Ratelimit Path: field. Next, set the maximum number of requests per minute that will be allowed, in the Max requests per minute: field.
Enable gzip compression: The level of gzip compression determines how compressed the data is. The levels of gzip compression limit how compressed the data is. The values range from one to nine (1-9), nine (9) being the most compressed. This setting requires a delicate balance of compression with server resources and transfer speed with bandwidth.
For instance, a value of nine (9) requires the most server resources for compression but the least bandwidth to transfer; whereas a value of one (1) requires the least amount of server resources for compression but the most bandwidth to transfer.
Error Page: Use this field to set a custom error page for a 503 (Service Unavailable) or 504 (Gateway Timeout) error. Enter the path to the custom error page file you created, starting from the home directory of the domain. For instance, if you enter the value error-page, then these errors will be redirected to https://yourdomain.com/error-page.
Now that you are more familiar with these advanced options, you can reduce your website’s load time. Keep in mind that the optimal settings can vary based on the website.
Sort of useful, but interested in recommended settings or more advice on how to adjust and know if it helped. Also, there are some bits in the configuration that aren’t described here. Such as accelerate static content. I’m trying to determine if NGINX caused my CSS to fail to render.
Hello Bill,
I spoke to one of the senior engineers that handle our configurations and they told me that any file with the .CSS extension is not cached. So it would not be causing your CSS to fail. However, if you’re using CSS through PHP, then it can be cached, and that may the source of the issue. I hope that helps to clarify the issue.