This article is based a NGINX reverse proxy setup explained here.
NGIINX is no doubt a lot faster than Apache. In terms of performance and high traffic handling, NGINX wins every time. In the previous article, we have explained that we should still use Apache with WordPress together because the way WordPress build it very tight to Apache, especially the way it handles rewrite in .htaccess. But this shouldn’t apply the serving static content.
Let’s think about what happen when a user visit to your website. The browser first request the html of the url. The request will hit the Apache server, and the Apache server will fire up the php-fpm CGI process manager to handle the request in WordPress and PHP level. This is going to initialize the whole WordPress life cycle to server the process, including checking all the hooks, making database call, and etc.
After the browser has received the first html payload, the HTML will indicate that there are lots of other static contents need to fetch. Those are image, Javascript, and CSS files. A lightweight site can easily required over 50 static files. Your browser will fire request for each of them, and each of them will go through the same route to hit the WordPress process again, and this is completely necessary.
Unlike dynamic content, your WordPress process doesn’t give any benefit of serving static content. The only result you get is slow. NGINX is built for this. It’s even loop architecture can quickly handle static content in not only fast, but also minimal OS resources.
Our task here is to make NGINX to handle the static content from file system directly, without every touching Apache and WordPress. By doing this, you are going to eliminate 90% of your Apache and WordPress request. That’s a serious performance boost you can get with such a simple change.
The NGINX Configuration
location ~.*\.(3gp|gif|jpg|jpeg|png|ico|wmv|avi|asf|asx|mpg|mpeg|mp4|pls|mp3|mid|wav|swf|flv|html|htm|txt|js|css|exe|zip|tar|rar|gz|tgz|bz2|uha|7z|doc|docx|xls|xlsx|pdf|iso|woff|ttf|svg|eot|sh|webp)$ {
root /home/my_site/public_html;
expires max;
try_files $uri $uri/ @backend;
}
location @backend {
internal;
proxy_pass http://localhost:8181;
include proxy.inc;
}The above configuration will do that magic. Let’s take a look at what it does.
- We define a list of file extensions. These includes most of the common static files.
- The root is set to the root of your WordPress directory. Since all static files are under the path /wp-content in WordPress. This setting will be sufficient enough for NGINX to find the file in the right place.
- The try_files directive will first try to get the file from file system. If fails, it will fall back to the @backend directive, which is the Apache handling.
About Uyond Hosting
WordPress is a powerful CMS, and it can perform very well if you do it right. In Uyond, we have done all these for you by default. We guarantee all WordPress on Uyond will have all these configuration done correctly. Check more about our hosting solution for details.
Recent Comments