How to speed up WordPress

This guide will show you how to take most WordPress sites to a maximum of 1-2 second load time. If your resources are very well optimized along with your hosting, you can reach fractions of a second load times per page. Please note that you may need to sacrifice functionality to fully optimize your site’s performance.

What this guide will not do is help you fix problems with your hosting provider’s configuration or issues with plugins or themes that could be heavily slowing things down. For example many plugins and themes make external resource calls that you cannot control, which will inherently bring down the speed of your site. Click here for help troubleshooting issues with suddenly very slow loading pages. Similarly you may need to disable parts of your theme in order for it to play nicely with your caching plugin. If you’re using themes and plugins that optimize for performance (not many do), then you’ll find that enabling caching will work perfectly without much fiddling.

If you are comfortable with all of the instructions in this article, then you should do them all to improve the performance of your website. If you’re a basic user, it’s also OK to only complete the sections you’re comfortable with. You’ll still see a performance improvement, just not as much as when you are able to complete all options. Some parts will provide massive load time improvements while others will be negligible. Some parts will make a synthetic speed test like Google’s PageSpeed or GTMetrix speed test think highly of your site but may not create a difference in real-world load times. Such is the nature of synthetic benchmarking tools.

Update History:

  • Dec 3, 2018: Reformatted post for better understanding of difference between browser cache vs. nginx->php-fpm direct mode. Use Plesk recommended rewrite rules for nginx.
  • Jul 4, 2017: Added ShortPixel as an image compression option, reformatted post.
  • Feb 20, 2016: Added commercial option, WP Rocket, as a great paid replacement for WP Super Cache + WP Minify.
  • Jun 16, 2017: Added some hosting/server tips.

Without further ado, here’s 8 things you can do to dramatically improve your website performance:

1. Use a web host that cares about performance

If your shared web hosting provider loads down their servers with thousands of websites, it’s inevitable that you’ll get frequent slowdowns. Be sure your host artificially limits the total number of sites per server to ensure your site will have the resources it needs to perform well. If you’re very concerned about performance then it’s recommended to obtain a VPS of your own to ensure your site has dedicated resources. We often recommend trying out our artificially limited shared hosting first and if you find you need even greater performance, you can always move on up to a VPS.

2. Use PHP 7 (with opcache)

You can take a look at some of the metrics here. With opcache enabled (it is by default when using PHP 5.6+ in Plesk) you can see anywhere from a 2 – 4x improvement in site speed. And all you need to do is ensure your web host, theme, and plugins support it. That’s it! If they do then it should be a very simple flip of the switch to better performance.

That sounds great… but how do I use it?

  • First, log into Plesk
  • Under the domain in question, go to “PHP Settings”
  • There will be two dropdowns at the top of the page; one for PHP Version, one for the PHP Handler. For the version, try 7.2, 7.1, or 7.0. Compatibility-wise, 7.0 will be more likely to play nice with some things, but 7.2 will get a bit better performance.
  • Scroll to the bottom and click “OK” or “Apply”

3. Enable Gzip Compression

 Are you using Websavers’ shared hosting or managed VPS services? If so, we’ve already enabled Gzip compression for you! It’s active on all shared hosting and Platinum Management VPS offerings. Not experiencing the Websavers difference yet? Well, we’ll hopefully see you soon

Meanwhile, you can use these apache .htaccess tweaks to add Gzip to your site:

<IfModule mod_deflate.c>
# Compress HTML, CSS, JavaScript, Text, XML and fonts
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml

This tells Apache to compress all compatible content before sending it – saving time and bandwidth!

Using Nginx only? Use this in your Nginx directives (not .htaccess):

gzip on;
gzip_disable "MSIE [1-6]\\.(?!.*SV1)";
gzip_proxied any;
gzip_comp_level 5;
gzip_types text/plain text/css application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon image/bmp image/svg+xml;
gzip_vary on;

4. Enable Browser Caching

In a later section we’ll talk about using a Caching Plugin for WordPress; any of these should also enable browser caching for you. That said, if you want to set up browser caching manually, here’s how you do it!

First it’s important to understand what exactly browser caching is. Ever have someone tell you to ‘clear your cache’ on your browser? That’s because modern browsers are configured to download copies of resources (HTML/CSS/JS/Images) to speed up page speeds on subsequent visits. By default, though, some of these items are set to ‘expire’ very quickly – which doesn’t help with speed much!

This is not recommended if you’re still developing your site as it makes it a bit of a pain.

That said, if your site is fully built, and you want to squeeze a bit more performance out of it, you can configure your server to tell visitors how long to hold on to certain resources.

Here’s how to do it with Apache using your .htaccess file:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/html "access plus 1 week"
ExpiresByType application/x-compressed "access plus 1 week"
ExpiresByType application/x-gzip "access plus 1 week"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 1 week"

This tells the browser how long to ‘hold on’ to various file types, and you can change those periods to your heart’s content.

If you’re using nginx-only mode:

Enter the following under Additional nginx directives to increase cache times for static files.

location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
    expires max; log_not_found off;

It’s important to note that you must uncheck “Serve static files directly by nginx” when inserting this rule: The static files nginx setting must be unchecked because this specifies the same thing — that nginx must respond to these types of files — except ours has the increased expiry time (the important part). If you leave the nginx rule enabled it will take precedence because it comes first, and thus your cache expiry entry will not apply.

You may wish to extend the list of file types found between the parentheses above to include the full list as shown within the “Serve static files directly by nginx” rule so that they match in terms of exhaustive filetypes that this rule applies to.

5. Use a Server-side Page Cache Plugin

We recommend WP Rocket (commercial) OR WP Super Cache + WP Minify (free)

Either combination of plugins can allow your site to handle massive spikes in traffic without breaking a sweat even on our shared hosting services! They are easy to set up compared to the more advanced server configurations described below. We’ve used these configurations to bring a site to over 500k daily unique page views at an average load of 1.0.

Some people prefer the combined functionality of a server page cache and minifcation available within W3 Total Cache and others like WP Fastest Cache. In general I’m sure that these plugins are great at handling performance enhancements, however I’ve never been able to get the free plugins to work as well as WP Super Cache + Minify (or Autoptimize). We’ve also never got any of the paid plugins to work as well as WP Rocket does.

 Tip: as of Dec 2018 we’re using custom nginx directives across all of our servers to auto-detect the use of the most common server-side page caching plugins and automatically serve their static html files directly with nginx without having to funnel through to apache or the PHP processor. Neat, huh? This includes WP Rocket, WP Super Cache, WP Fastest Cache, and W3 Total Cache.

WP Rocket (our favourite)

After lots of time spent with WP Super Cache and WP Minify, we made the switch to the paid plugin, WP Rocket at the start of 2016, and haven’t looked back since. It’s capability to enable caching and greatly improve performance by simply checking some boxes has us hooked! Granted it does cost some money, which is why I’m keeping both options available here for you to select from.

Be sure to only be using WP Rocket OR WP Super Cache + WP Minify; do not try to use all three. WP Rocket has the functionality of WP Super Cache and WP Minify combined.

WP Rocket is pretty solid right out of the gate, but they don’t automatically enable some things which can cause problems on sites. The latest versions go even farther with being able to nip some of Google PageSpeed’s nit-pickier items.

The configuration here is the most exhaustive configuration — it might break your website (as WP Rocket will even explicitly warn you when you activate those options). You have been warned!

Basic Settings:

Enable Lazyload for images and videos (not always recommended, but try it!)
Enable mobile caching

Static Files:

Minify – Activate for all (this can cause display issues)
Render-blocking CSS/JS: Activate for both and optionally enable safe mode for Javascript (it is, after all, safer, and less likely to break your site).
Use the Critical Path CSS Generator to create your Critical Path CSS to put where specified. Failing to do that can cause some issues.

It’s also worth noting you can use Autoptimize with WP Rocket to squeeze out just a teensy bit more performance 🙂

WP Super Cache + WP Minify

To get started, log in to your WordPress installation and go to Plugins > Add New. Install both WP Super Cache and WP Minify plugins.

Configuring WP Super Cache

Head to Settings > WP Super Cache to get started! The first thing to do is to “Turn Caching On” and press the Update Status button. Click on the Advanced tab and check off everything with “Recommended” next to it. This now includes the option to “Use mod_rewrite to serve cache files”. Press the Update Status button.

Scroll down to the “Expiry Time & Garbage Collection” section and set the interval to either once or twice daily, then press the “Change Expiration” button.

Configuring WP Minify

[Update April 15 2015] WP Minify hasn’t been updated in some time and is probably  not working as well as it once did. I have been having better luck with Better WordPess Minify, although I must admit its advanced configuration options UI is quite confusing (ie: for configuring whether scripts should be in the header or footer. I’m happy it’s an option, but man is it ever hard to navigate).

Go to Settings > WP Minify and make sure that Javascript, CSS and HTML minification are enabled. For Google speed tests, it’s beneficial to tell WP Minify to load the files in the footer, however be warned that this may break scripts on your site! You can test it out by pressing the “Show Advanced Options” button, then checking the “Place Minified JavaScript in footer” box. If you see things broken on the site, disable this option.

It’s also possible you will see other broken elements on the site, depending on plugins used, your theme, and a variety of other things. If you do, I suggest disabling each of the types of minification one-by-one until you see the problem go away.

If you’re an advanced user, then you can re-enable the type of minification that didn’t work for you, then use a web inspector to inspect the page and find out which file is causing the problem, then exclude just that singular file within the WP Minify settings.

Also for advanced users, you may simply need to specify where WP Minify is to be loaded in the process of the browser reading the page. You can do that by unchecking the option to load minified files in the footer and instead opening your template file and inserting the following where you would like the minified files inserted:

<!-- WP-Minify JS -->
<!-- WP-Minify CSS -->

For example, you may need to have these appear after the <?php wp_footer(); ?> call. Play around and check your results by running the Google developer page speed test on your site.

6. Compress image files

This is only going to give you a small noticeable speed boost (unless you’re on a very slow Internet connection), but it can improve your Google page speed score a surprising amount.

 Please note that you should expect a drop in image quality for the images on your site if you truly want to optimize the site to its max. On the flip side, definitely feel free to keep the image quality high, you’ll simply have to do so at the expense of page load times on slower connections and synthetic benchmark scores like Google PageSpeed. You simply have to choose which you prefer.

Original manual method: Run all PNG files through a compressor then upload them overtop of their prior versions. You may not have these tools available, but I opened all PNG files in Photoshop and exported them for web. If you do this make sure that the files do not include Metadata as this can eat up large portions of the files — especially for icons.

[Update Jun 16, 2017]: We now use Imagify to handle this for us, all server-side. It’s a fantastic plugin provided by the same folks as WP Rocket that will automatically manage the compression of your images either as a one-shot deal or ongoing (it’s up to you!)

[Update Jul 4, 2018] Another option is the plugin ShortPixel, it works just as well as Imagify in our testing and also offers very fair pricing.

Check out all of our recommended resources here.

7. Using nginx direct to php-fpm on Plesk 11.5+ [Advanced]

Requires Plesk Admin Access (VPS Only)

[Note: this performance enhancement is only available to Plesk admin users. If you have a shared hosting account you cannot make this change. Only those with their own VPS and Plesk 11.5 or higher can do so.]

Note that if you do not already have support for php-fpm installed on your server, enabling it will require the use of PHP 5.4 or higher. Upgrading to PHP 5.4 should only be done after ensuring all PHP code is compatible. 

As of Plesk 11, all web traffic is first picked up by nginx, a web server engine designed purely for performance. For compatibility with most web applications, by default it will pass most requests through to Apache for standard processing, but certain things it can handle faster are simply responded to by nginx rather than funneling to Apache.

With Plesk 11.5 we’re now provided the option to handle all PHP requests via nginx direct to php-fpm, bypassing apache. This is the same combination that those ‘premium’ WordPress hosting providers use to offer extreme speed improvements with their hosted WordPress installs. Here’s how to do it (note that you must be a Plesk admin user to see these options):

  1. Log in to Plesk
  2. Choose the Websites & Domains tab
  3. Click on the domain you wish to adjust server settings for
  4. Click the “Web Server Settings” icon
  5. Scroll down to nginx settings and check off all three options. Specifically the last one -> process PHP by nginx

At this point your WordPress install will work great if you do not have permalinks enabled. However if you do (which most WordPress installs should, at the very least for SEO purposes), then you’ll need to provide a little extra info to nginx to inform it how to handle seo and human friendly URLs. Without setting this info, most of your pages other than the home page will probably fail to load with a 404 error.

Under “Additional nginx directives” place the following rewrite code [source]:

if (!-e $request_filename) { 
  set $test P; 
if ($uri !~ ^/(plesk-stat|webstat|webstat-ssl|ftpstat|anon_ftpstat|awstats-icon|internal-nginx-static-location)) { 
  set $test "${test}C"; 
if ($test = PC) { 
  rewrite ^/(.*)$ /index.php?$1; 

This is the same location where you can add the custom nginx gzip compression code as well as the code to increase static resource browser cache lifetime, found earlier in this guide.

Configure nginx to load static cache files (WP Super Cache)

Remember above when we told WP Super Cache to use mod_rewrite to serve our cache files? This is pretty much automatic if you’re using apache because in a good quality hosting environment WP Super Cache will prompt you to automatically modify your .htaccess file to include the necessary mod_rewrite rules. However with nginx, we must configure them manually.

 Note that if you do not include the following values in your nginx configuration, you’re better off leaving the WP Super Cache setting to “Use PHP to serve cache files” as without these rewrite rules caching is essentially disabled.

### WP Super Cache Below ###
set $cache_uri $request_uri;
# POST requests and urls with a query string should always go to PHP
if ($request_method = POST) {
    set $cache_uri 'null cache';
if ($query_string != "") {
    set $cache_uri 'null cache';
# Don't cache uris containing the following segments
if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
    set $cache_uri 'null cache';
# Don't use the cache for logged in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
     set $cache_uri 'null cache';
# Use cached or actual file if they exists, otherwise pass request to WordPress
location ~ / {
   try_files /wp-content/cache/supercache/$http_host/$cache_uri/index.html $uri $uri/ /index.php ;

One thing to watch out for here is that the first nginx directive we entered to handle permalinks properly is replaced by the part that says “# all other requests go to WordPress” so make sure those are not used at the same time.

It’s important to note that you may have some issues with the supplied nginx rules if you’re using WordPress in a subdirectory install, especially if you have a ‘nested’ install (with WordPress in the base directory and another WordPress installation in a subdirectory). It can be done with a lot of tricky changes to the supplied rules, but it’s definitely easier on all counts if you either:

  • Use a subdomain installation
  • Use apache if you must use a subdirectory setup

The reason for this is that .htaccess files are completely bypassed by nginx and the nginx directives are used instead. Apache’s .htaccess files allow for very simple per-directory settings, and without a similar system for nginx it really doesn’t work nicely at all.

Configure nginx to load static cache files (WP Rocket)

We made use of this handy WP Rocket nginx config by generating a config (follow the installation instructions), then pasting the result into the advanced nginx configuration directives location in Plesk 11.5+. Note that we have made adjustments to the configuration that we’ve found have worked best for our environment; if you’d like to take advantage of our optimizations, look into hosting with Websavers! It’s also important to note that this configuration has gzip compression and static file cache time increases built in, so you don’t need those directives above. That said, you *should* need the “all other requests go to WordPress” part somewhere in the config 😉

8. Disable unused PHP modules [Advanced]

Plesk Admin Access Required (VPS Only)

If you have full admin access to your VPS, you can actually disable PHP modules you don’t need. Less things to load into memory, less memory use, less intensive processing, and faster performance. This is very advanced stuff, though, so make sure you either know what you’re doing or aren’t doing it on a live server so you’re not breaking anything 😉

  • Go to Tools and Settings in Plesk
  • Under General Settings click PHP Settings
  • Select the PHP version and handler you want to change settings for
  • Toggle PHP modules off that you’re not using
  • Click OK or Apply to save

Now go back to your website and make sure nothing’s broken! You may not know what modules are used in every aspect of your website, so there could be a fair bit of trial and error to get this right.

Jordan is a computer, security, and network systems expert and a lover of all things web and tech. Jordan consults with project management for software companies. Jordan is a founder and managing partner at Websavers Inc.


  1. Kevin on February 20, 2016 at 2:51 pm

    Hi Jordan,

    thanks for this great tutorial.

    If i use the code to avoid if statements for performance the /wp-admin link gets too many redirections.

    With the if statement everything works fine.

    Can you help me with that?


    • Jordan Schelew on February 20, 2016 at 2:58 pm


      Honestly we’ve just been using the if statement on all our sites! I tried switching back and forth and running speed tests and the difference never showed itself. I suppose it would actually be in terms of CPU usage on the server side, but even that hasn’t presented issues on shared hosting.

  2. Jordan Schelew on July 21, 2015 at 7:59 pm

    Hey there Sahil,

    That does make sense! HTTP authentication either manually configured or using Plesk probably only gets set up via .htaccess file or specific apache config file, which is not read by nginx. While I haven’t tested this, a quick check of the nginx documentation indicates that the following should work. Add it to the same place you put the nginx supercache config:

    auth_basic “Restricted”;
    auth_basic_user_file {PATH_TO_.htpasswd};

    Note that you have to include the path to your .htpasswd file that was set up to work with Apache. If you created it through Plesk, then the path to the .htpasswd file should be located within the apache config file for the domain here:


    Open up that file and look for a reference to .htpasswd — copy the directory path and use it in the nginx code above. Any remaining issues would have to be permission related.

    All that said… if you DID create your http authentication via Plesk, you should let them know that they’re not configuring nginx at the same time, as this should be up to them to do!

  3. Sahil on June 24, 2015 at 11:52 am

    Having problem with http authentication with wp supercache in plesk panel.
    When i enable supercache with nginx and write the above code with nginx my http authentication for login page not working. 401 authentication page comes but after entered details it started downloding that page.
    Please send me the proper code for using supercache with http authorization for login page.


  4. Renzo on May 18, 2015 at 11:17 pm

    Hi, how can I setup fastcgi_cache with conditional purging ( In plesk. its going fine till i get this error when I copy this part;

    set $skip_cache 0;

    # POST requests and urls with a query string should always go to PHP
    if ($request_method = POST) {
    set $skip_cache 1;
    if ($query_string != “”) {
    set $skip_cache 1;

    # Don’t cache uris containing the following segments
    if ($request_uri ~* “/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml”) {
    set $skip_cache 1;

    # Don’t use the cache for logged in users or recent commenters
    if ($http_cookie ~* “comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in”) {
    set $skip_cache 1;

    location / {
    try_files $uri $uri/ /index.php?$args;

    location ~ .php$ {
    try_files $uri =404;
    include fastcgi_params;

    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;

    fastcgi_cache WORDPRESS;
    fastcgi_cache_valid 60m;

    location ~ /purge(/.*) {
    fastcgi_cache_purge WORDPRESS “$scheme$request_method$host$1”;

    location ~* ^.+.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
    access_log off; log_not_found off; expires max;

    location = /robots.txt { access_log off; log_not_found off; }
    location ~ /. { deny all; access_log off; log_not_found off; }

    I get this error : Invalid nginx configuration: nginx: [emerg] unknown directive “fastcgi_cache_purge” in /var/www/vhosts/system/ nginx: configuration file /etc/nginx/nginx.conf test fail

    How can I make it work?

    • Jordan Schelew on May 19, 2015 at 12:35 am


      It looks like you need to install a custom build of nginx that supports it. They have the details in the URL you provided under the header “Check if your nginx has fastcgi_cache_purge module”. If you can’t find a custom build for your OS (looks like they only support Ubuntu / Debian) you can probably do a custom recompile, but that’s something we tend to avoid with production servers.

  5. Ben on April 11, 2015 at 2:31 am


    I found this tutorial a big help but after all implementing the guide, i found out that WP Minify isnt working. but then again the guide gives me a +5 on google speed

    • Jordan Schelew on April 16, 2015 at 1:58 am

      Thanks Ben! Spurred by your comment, I updated it today to quickly indicate that I’ve been testing out the “Better WordPress Minify” plugin for the last couple of months. So far so good, though I find in general it’s tricky to get minification working with everything (like Google seems to really want). This is partly because of their new CSS inlining requirements and mostly thanks to them wanting to force all Javascript to the footer, even if it uses document.onload.

  6. Nikita on April 9, 2015 at 12:37 pm

    Really Good Tutorial Regarding Caching And Page Speed…

  7. Kingsley on December 27, 2014 at 6:46 am

    Great tutorial, this seems to work for me without 404 errors


    • Jordan Schelew on December 29, 2014 at 8:57 pm

      Thanks Kingsley!

  8. Artur on August 14, 2014 at 7:30 pm

    Thanks God I found your post 😀

    I was serching for a way to enable this with ssh but
    unfortunatly my host do not let me in as admin.

    It was so easy, thank you 🙂

    My pagespeed over google insights went from 33 to 75

  9. Ryan Williams on December 18, 2013 at 11:40 am

    Scratch that, turns out a vhost issue was the problem. I was (temporarily) accessing my domain via IP which seemed to trip up the Nginx proxy and just routed everything directly to Apache.

  10. Ryan Williams on December 18, 2013 at 9:22 am

    I wasn’t able to get the gzip part to work in my Plesk 11.5 Nginx directives input. It literally did nothing at all, yet when I used gzip in my .htaccess file they started being gzipped — even though they’re being served by Nginx, which I know because it says so in the HTTP header.

    Not sure what the deal is there. Maybe Plesk now ignores any gzip-related directives and just passes through whatever Apache returns, gzipped or not?

  11. R. Anthony Solis on November 20, 2013 at 7:08 pm

    For us, this almost worked. We had to use

    if (!-e $request_filename){
    rewrite ^(.*)$ /index.php break;

    instead of the rewrite – our admin URL was inaccessible.

    And we opted to check the box for static files served by NGinx and no we did not insert the code:

    location ~* ^/(.*.(js|css|png|jpg|jpeg|gif|ico))$ {
    expires 2w;
    log_not_found off;

    What we didn’t realize was adding the PHP-FPM and modules to support, would upgrade PHP to 5.4. Caused havoc on our end for some WP sites. 🙂

    Thanks for the post and tutorial.


    • Jordan Schelew on December 3, 2013 at 10:36 pm

      Thanks for the tip Anthony! I’ve added a notice to the guide indicating that upgrading to PHP 5.4 could be problematic for older software / php code.

  12. Javier on October 10, 2013 at 11:42 am


    Thank you for this little guide WPO WordPress installed on Plesk servers.

    I tried the settings and work very well, loading times have been reduced.

    My clients will be happy with the loading speed of your websites.

    Thanks again

    • Jordan Schelew on October 10, 2013 at 11:51 am


      Happy to have helped! If you’re ever looking for hosting (shared, VPS, radio, etc.), come see us again.



  13. Ben May on September 21, 2013 at 6:07 am


    Thanks for this post. I was looking for the nginx rule for WordPress and Plesk. Perfect!


    Plesk 11.5 has got me really excited in terms of performance and WordPress hosting. Starting to port my Plesk 10.x client sites over and test!

    • Jordan Schelew on September 26, 2013 at 10:41 am


      Me too! I’m a little surprised they made this move as Parallels has been pretty cautious about changes like this in the past. I’m happy to see them slowly providing admins with more tools to play with without requiring minor hacks to config files and Plesk itself.

      It’s especially nice to know that we can easily compete with specialized services like WP Engine.

  14. bob veris on August 13, 2013 at 5:31 pm

    Hi Jordan,

    I wish I had a nickel for every time someone asked me about nginx. (Okay, I had to run over to wikipedia just to find out) But, it begs the question as an open-source reverse proxy server, is it better than Apache on Linux? I host at godaddy for the while until I find a better place (Websavers is looking awfully good right now).

    The problem with Apache is it repeatedly throws the error Internal Error message at Port 80. Godaddy, who is well aware of the problem, says it must be WordPress plugins. When asked for a solution/workaround, they sheepishly advise to disable every plugin and then start testing them one-at-a-time. Right!??

    Best, Veris

    • Jordan Schelew on August 13, 2013 at 6:27 pm

      Hey Bob,

      I’ve wondered the same thing for quite some time now. When Plesk integrated it as a reverse proxy in Plesk 10, It didn’t really seem to do much for me to impress other than to add complexity to troubleshooting. But with Plesk 11.5 I can definitely see the improvements in performance. With Plesk 11.5 they’ve made it so that:

      1. We have the reverse proxy like in Plesk 10 as the default. This means all incoming requests are handled via threads rather than full-weight processes like Apache normally uses (when supporting PHP — it’s important to note that you can run apache in a threaded mode without mod_php support). This makes for reduced memory usage, especially with a high traffic server. Because nginx also uses less files (it refuses to support things like .htaccess) it means less IO load on the server for every single request.

      2. As of Plesk 11, you can now specify that all static files be handled directly by nginx rather than everything being funnelled to Apache. This makes for really efficient management. You get all the traditional benefits of the tried and tested Apache for running scripts of any kind when needed, but all static content like images, html, css, javascript, etc. are all handled by the nginx thread rather than funneling it through to apache to process. This makes for great performance improvements.

      3. And finally with Plesk 11.5 we can also have nginx pass PHP processing directly from nginx to php-fpm (similar to php-cgi used by Apache). The biggest benefit of this being that a single nginx thread can pass it over to php-fpm, meaning rather than loading an nginx thread, an apache process and finally a php-cgi process, we can simply have the nginx thread and the php-fpm process. It’s considerably easier on disc IO and even better on memory.

      The Internal Server Error can indeed be any number of things. In some cases it can be incorrectly configured server software, in others a plugin misbehaving (although this is less likely — that’s more likely to result in a clear error in your apache error log), or as with us recently, a misconfigured php.ini file that doesn’t work nicely with the latest version of PHP.

      We’ve also seen similar errors as a result of low bandwidth or connection limiting being enabled on a server to try and artificially keep its load low by basically tossing your customers away for the greater good. This is something we don’t typically do unless someone is running a heavily out of date script that’s causing problems (wherein a simple upgrade would be the solution).