Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

WordPress Performance Improvements That Can Go Wrong

If you’ve searched recently for tips on optimizing WordPress’ performance, then you have definitely come across various techniques that people recommend. These include all sorts of caching mechanisms, such as reverse proxies, object caching and cache plugins, CSS minification, using sprites for images, and so on. All of them are viable and effective ways to speed up a WordPress website’s performance. However, be careful when implementing any of these techniques, and always test their effect on your particular website.

In this article, we’ll cover some of the most common issues with various speed boosters that I have encountered and share solutions to help you fix those problems or find ways around them.

Further Reading on SmashingMag: Link

Possible Problems When Using Reverse Proxies Such As Varnish And Nginx Link

I will start with the reverse proxies because, when used correctly, they can give you the biggest speed boost and, when used improperly, can cause serious problems, such as making your website inaccessible or showing the wrong information to the wrong visitors.

How Do Reverse Proxies Work? Link

Reverse proxies, like Varnish and Nginx, stand between your visitors and your Web server. When a request for one of your pages is made, your Web server usually has to execute the PHP service that makes calls to the database and then provides the page output and the static resources needed to visualize the page. With a reverse proxy enabled, this result is cached, and the next time someone requests that page, the ready output will be delivered by the reverse proxy, which is much faster and causes no load on your server.

This is great, but to operate correctly, the cache must be purged every time something on the page has changed. This is where things can go wrong, mostly because WordPress does not natively support reverse proxies and requires additional tweaks for the cache to be cleared correctly. Usually, such tweaks rely on WordPress’ default core hooks (think of them as events) to purge the cache when necessary — when a post is updated, when a comment is added, when a post is created, etc. However, if an important hook is missed in the implementation of the reverse proxy that you’re using, then you might have a problem. Additionally, numerous events — ones not a part of WordPress’ core hooks but rather performed through plugins — could change the content on your website.

Possible Problems During WordPress Updates Link

When updating, WordPress puts your website in maintenance mode, updates its files and then disables maintenance mode. The reverse proxy could possibly cache some of your pages while your website is in maintenance mode. This means that if the cache is not purged, then this maintenance page would continue being served to visitors, actively preventing them from reaching your website even when it is operational on the Web server.

When you update a plugin, WordPress disables it, deletes its entire folder and then adds the new files. During that time, the plugin does not actually work. If it’s a big plugin that adds a lot of functionality, such as a gallery or online store, then your reverse proxy could cache pages with errors on them, instead of the actual content.

When you update manually, the easy fix is either to disable the cache during the update or to purge the cache manually once you are ready with the update. However, when you use WordPress’ native automatic update, these solutions are not very practical. What a good reverse proxy should do instead is automatically purge the cache on each update event. Because both core and plugin updates have hooks in the core, this is easily achievable and should be done by you (if you are implementing the reverse proxy yourself) or by your hosting provider (if you rely on the host’s implementation).

Problems With Online Store Plugins for WordPress Link

No matter which WordPress plugin you use for your online store, you should be very, very careful when implementing reverse proxy caching.

For example, you could create a lovely mess with a shopping-cart widget that displays the products that a customer has selected to buy. If that content is cached by the reverse proxies, then all of your visitors would see the products that the first customer has selected for purchase. Things could get even worse if pages containing personal information, such as thank-you pages, are cached and displayed incorrectly to the wrong visitor. Needless to say, this should be avoided at all costs.

The safest way to avoid such problems is to exclude the entire e-commerce part of your website from the cache. Usually, reverse proxies implemented by hosting companies exclude the most common WordPress e-commerce plugins from the cache by default.

If excluding the whole e-commerce part of your website does not sound to you like an elegant solution — because you would obviously lose the speed benefits — then, theoretically, there is a more intricate way around: using Edge Side Includes (ESI) to specify that parts of your pages should not be cached. In theory, you would simply surround your HTML with ESI tags:

<esi:include> Dynamic content <esi:remove>

Then, the content between those tags would be dynamically retrieved every time this page is requested.

Unfortunately, implementing ESI with WordPress is not straightforward at all, due to WordPress’ lack of native support for reverse proxies. Thus, ESI is usually not a viable option with hosts that support reverse proxies. But it is worth considering if you have an online store built with WordPress and you are implementing the reverse proxy yourself.

Problems With Rating Plugins Link

When you use a rating plugin on a WordPress website that is cached by a reverse proxy, chances are that visitors will often see an incorrect cached rating, instead of the real up-to-date rating. The reason is that a visitor’s vote given through such a plugin is not part of WordPress’ default hooks and will not trigger a cache purge.

Similar to the e-commerce issues, you could either exclude pages that you collect rankings for from the cache or implement the ESI model for those pages, if feasible.

Issues With Full-Page Caching Plugins Link

In case your hosting provider doesn’t provide you with a reverse proxy caching service, you could rely on one of the so-called full-page caching plugins for WordPress. When a visitor requests a page, the plugin would save the actual HTML output in a physical file on your server. The next time someone requests that page, it would be served as a static HTML file, which is much slower than a reverse proxy but still faster than not caching at all.

Unfortunately, due to the caching technique being used, all of the possible problems I’ve explained for reverse proxies hold true for the full-page caching plugins, plus some new ones.

Be careful using such caching on a website with many posts or pages. When you create content on a WordPress website, more pages are automatically created than just the one you’re working on directly: category pages that list all posts in that category, tag pages, archives, author pages, pages for uploaded images, etc. All of these add up to a big number of URLs that your website serves. Now, imagine all of those URLs being turned into HTML files in some folder (usually the uploads folder) on your Web server. When thousands of files are in a single directory, even listing those files is difficult, and we’re talking about the Linux OS here. The result for a big website is usually a huge number of files, a heavy I/O load on the server and, eventually, a slower website and problems with the hosting provider.

There is no exact number of posts above which you should not incorporate this method, and it also depends on the particular way the plugin stores the cache — using multiple folders instead of one, for example, would be more efficient, but still might not be enough for a really large website. Just bear in mind that if you use such a caching technique and your website starts slowing down, then this might be the reason.

Object Caching (Memcached) And How To Break It Link

Object caching is great for a website that gets a lot of requests to its database, and it can really speed up some websites. Memcached stores the result of the most commonly executed queries to your database in the server’s RAM and serves the cached results instead of querying the MySQL server each time. Unfortunately, in some scenarios, you could actually decrease your website’s performance, and here is why.

Some WordPress plugins are coded (badly) to store a huge amount of data in the application database. The Memcached service has a limited amount of memory for caching. Imagine what happens when a plugin stores huge images in the database. Memcached will try to store the result of this query in its buffer but will run out of space. Then, it will start to delete previously cached content on a first-in, first-out basis. If the query’s results are big enough, then no actual content would be cached because it would be removed before being served a second time. In this case, your website would actually slow down because not only would you fail to spare this load on the MySQL service, but you would add another service in the process that requires its own computing time.

If you find your website is working more slowly after enabling Memcached, then unfortunately your only solution is either to disable all plugins that store a huge amount of data in the database or to disable the Memcached service itself.

Sprites: Yes, You Can Go Wrong With Them, Too Link

I love sprites for the performance boost they give to a website when used correctly. This is why, when we redesigned SiteGround6 recently, we moved all navigation and UI elements and many other page elements to sprites. Our website became much faster, and we were quite happy with the result. Then, we continued adding elements to the sprite image, until at some point we noticed problems when some pages loaded on iOS devices.

This happened because we hit mobile Safari’s limit on the maximum number of decoded pixels that can be displayed. This limit is different for different devices. You could easily generate a sprite with a lot of pixels, and if it reaches the size limit, then the browser won’t load it, which will leave your website without all of the elements contained in that sprite. Of course, you don’t want this to happen.

A good man by the name of William Malone has crafted a nifty tool7 to check whether a sprite image will display correctly on all iOS devices. Enter the dimensions of your sprite image in the calculator, and the answer will appear.

If your sprite is too big, a possible solution is to split it into two images. If you have to do this, my advice is to relegate only the newest elements to a new image; otherwise you would have to adjust all of the CSS code that uses the sprite, a task that you’d want to avoid if possible.

Risks With CSS And JavaScript Minification Link

CSS and JavaScript minification is another of the most common techniques for speeding up a website. Generally, minifying these files entails removing all unnecessary symbols (new lines, semicolons after the final CSS property, comments, etc.), thus reducing the size of the files. This technique applies not only to WordPress but to any page that uses CSS and JavaScript.

Many tools and plugins will automatically minify files. However, some minify more aggressively than simply removing empty symbols. Some tools will rearrange CSS selectors, for example, grouping them by property, etc. In some cases, this could break the entire logic of a CSS file and turn your website into something that merely resembles the original.

To avoid such problems, use basic non-aggressive minification tools that remove only unnecessary data from JavaScript and CSS files, without reordering properties. In addition, always keep a copy of your unminified files because, after minification, they will become practically unreadable, making any further changes much harder. I use either a plugin or the online FreeFormatter8.

Gzip: Can’t Go Wrong Here, But We Can Do It Better Link

Enabling Gzip for WordPress will greatly improve loading speed. Gzip compresses a page’s output and transfers it to the visitor’s browser, like a regular ZIP file, whereupon the browser decompresses and renders it. It’s great because the time a browser takes to decompress archived content is many times less than the time needed to physically transfer the uncompressed content from the server to the browser.

Most WordPress users rely on plugins when they can — at least the ones who can’t or don’t want to code — including for Gzip. Unfortunately, Gzip plugins run through PHP, which, although fast, is not as fast as running directly from the Apache server. All you need to do is install mod_deflate (ask your hosting provider if it is available — it should be because it is pretty much an industry standard) and add a few lines to your .htaccess file:

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

Conclusion Link

Knowing all of the risks involved in optimizing the speed of your WordPress website should not stop you from experimenting. To achieve the best results, just follow few simple principles: don’t change too many things at once, benchmark your loading speeds, use staging copies when possible, and test the website’s functionality after applying each new technique. In doing so, you will speed up your website without breaking any functionality or causing problems for visitors.

(dp, al, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8

↑ Back to top Tweet itShare on Facebook

Hristo is a big WordPress enthusiast and has been fortunate to have his passion for all things WordPress and his job overlap at SiteGround web hosting company. He has done it all: supported WordPress clients, built websites, played around with WordPress themes, wrote tutorials, built some plugins and helped for the various in-house performance boost solutions to make WordPress websites faster and more secure.

  1. 1

    Prasad Ajinkya

    March 21, 2014 5:30 am

    Good points, all of them. Have bragged and burned on some of them in the past!

  2. 2

    Mark Gavalda

    March 21, 2014 5:52 am

    Excellent collection Hristo. I especially liked the first one, because it’s really really tricky to set up a reverse proxy/caching system that works well in all situations, mainly because there are so many plugins one can use with WordPress that chances are you’ll (or one of your users if you’re hosting more people’s sites) end up with outdated content being cached and served to visitors.

    The best solution is a fine-tuned WP object caching system with Memcached or Redis (Redis is the one that we at Kinsta favour) or anything similar as a backend plus correctly written themes and plugins. Of course the latter is hard to achieve and impossible to control for the everyday users.

  3. 3

    Patrick Whitty-Clarke

    March 21, 2014 6:02 am

    Great article. I didn’t know about the PHP vs Apache gzip speeds.

    • 4

      Hristo Pandjarov

      March 21, 2014 6:42 am

      It’s not a huge difference in the speed of the two but if gZIP is the only thing you’re about to add a plugin, then it’s much better to use the .htaccess rules instead :)

      • 5

        Ihor Vorotnov

        March 31, 2014 2:17 pm

        There is a difference. Running gzip via PHP uses extra CPU cycles and memory, while part of the optimization and speed-up process is actually reducing usage of both. You probably won’t notice anything on a shared hosting if the server is half-empty with low load or on your own VPS with more than 4Gbs of RAM. But today it’s common to use your own low-end VPS with 512Mb – 1Gb – 2Gb (Digital Ocean, for example) and on this type of servers it really makes a difference, even on Nginx instead of Apache.

  4. 6

    Don’t forget about misconfiguration: once I saw a developer that tried to make his website faster by making Nginx serving the static files. Sadly he used just using a regex to select those: if you access “/wp-config.php?.txt” it will return a text/plain file with the wp-config.php contents.
    This error is still alive: when I reported that to him he ignored me :( … if you will use nginx or plugins to increase performance at least use in the right way.

  5. 7

    People seem to forget the obvious ways to speed up a website. keep it simple, keep HTML request low, keep fancy scripts to a minimum, and optimize images. The first golden rule(s) in my book…

  6. 8

    I have a question regarding compression. So far, I’ve been using this in my .htaccess:

    <FilesMatch “.(css|htm|html|ico|js|json|markdown|md|php|txt|xml)$”>
    Header set Content-Length “gzip”
    SetOutputFilter DEFLATE

    What are the differences between this and the method mentioned in the articles (pro/contra)?

    • 9

      Hristo Pandjarov

      March 21, 2014 11:56 pm

      I don’t think there’s any difference in terms of speed. However, what to be parsed through Mod Deflate is matched in a different way – the one in the article will match based on the MIME type of the content, while your’s match extensions. Just two ways to achieve practically the same result :)

  7. 10

    I personally ran into a caching problem using the Cart66 shopping cart. The developer was very responsive, though, but said it is not recommended to using a cache plugin with Cart66.

  8. 11

    Michael Neil

    March 21, 2014 3:50 pm

    In the end it all comes down to configuration and doing it right. I think it’s great that you covered these pitfalls of misusing techniques. But, I wouldn’t mind at least seeing some recommended links on how to actually set these up right. Obviously, a novice developer shouldn’t try configuring Varnish on a server in hopes of speeding up a blog. But, little things like compression, and partial caching can be achieved pretty easily.

    To shamelessly plug my own plugin,, simply looks for files included in a request and minifies/concatenates the files and caches the results. You can pick and choose which files to combine or compress and in most situations it just works.

    • 12

      I wish you had included HTML minification in your plugin too. I am using plugin and really loving it.

  9. 13

    Another must have performance boost is compressing the images using something like smushit.

  10. 14

    I’ll definitely have to test again, but: in my experience, having a page-caching plugin is not slower in any way compared to a Varnish/Memcache setup.

    When I tested this with SiteGrounds GoGeek hosting with everything Supercacher offers turned on, page access was always significantly faster for single pages as well as for load testing with 100 VUs when I additionally had W 3 Total Cache or Cachify activated and caching full pages (to disk, not to RAM).

    Also, I’ve always wondered what exactly Nikolay meant when he wrote in the comments to the Supercacher introductory blogpost “SuperCacher has been tested with most popular WordPress plugins, such as W3 Total Cache. We even recommend it for Memcached service.” Unfortunately, I haven’t found any Tutorial on how Siteground recommends W3TC to be used with Supercacher.

    • 15

      Hristo Pandjarov

      March 25, 2014 3:34 am

      On our servers, if you want to use our dynamic caching (Varnish powered) you need to add a plugin to your WordPress site. We’ve tested our plugin in combination with different popular plugins including W3TC to make sure that our customers sites won’t be broken when other plugins are enabled.

      We don’t recommend using W3TC together with our SuperCacher for caching because it won’t imrpove your site speed. However, you can still use its features for minifying, monitoring, etc.

    • 16

      Paul Davidson

      July 27, 2015 3:58 pm

      Does anyone know where I can find a blank “2014 IRS W-3” to fill out?

  11. 17

    Yeah, that’s what I do with my clients’ website, make small changes step by step.

  12. 18

    Great article. I am still learning nginx and its really fast. But you will have a lot of work when running wordpress in multisite network mode.

  13. 19

    Interesting read. But to me it looks like the AddOutputFilterByType syntax is deprecated and has been superseded by mod_filter syntax.

    So your example could read (shortened for readability):

    <IfModule filter_module>
    FilterDeclare COMPRESS
    FilterProvider COMPRESS DEFLATE resp=Content-Type $text/html
    # Insert other mime types here
    FilterChain COMPRESS
    FilterProtocol COMPRESS DEFLATE change=yes;byteranges=no

    • 20

      Hristo Pandjarov

      March 25, 2014 3:43 am

      You can use mod_filter if you’re on Apache 2.4 :) In that case your lines will work just fine.

  14. 21

    I wish I would have found these tips sooner, could have saved a lot of time and aggravation. There were a few things here that will probably save me from learning the hard way :)

  15. 22

    frank goossens (futtta)

    March 26, 2014 1:31 am

    Interesting read, but I’m not sure the part about files in one directory on Linux slowing down Apache is entirely correct.

    When you have a directory with thousands of files, there is a problem if:
    you’re on ext3 (without dir_index option)
    you execute commands that require to read the directory contents (e.g. ls on CLI or glob, scandir and readdir in PHP but I guess also anything involving globbing)

    As far as I know (and this seems to be confirmed when Googling) there is no problem if;
    you’re on other filesystem types (reiserfs, ext4, xfs, …) or ext3/4 with dir_index
    you’re not reading directory contents but rather using direct references to a file

    So yes, one should take the number of files per directory into account but it does not necessarily mean “a heavy I/O load on the server and, eventually, a slower website and problems with the hosting provider”?

    • 23

      Hristo Pandjarov

      March 27, 2014 7:53 am

      Many hosting accounts and Linux distributions come with ext3 by default :)

  16. 24

    I recently ran into many of these problems particularly with varnish caching old themes etc. I am having trouble finding resources on how to purge varnish on update. Could you refer me to some resources. I would like to write my own wordpress plugin to do this.

  17. 26

    Ohh an article read a bit to late. Lessons learned and some new ones. Thanks for the read.

  18. 27

    It worked for me to dramatically improve WP Performance by making these simple adjustments in the .htaccess file following this tutorial:

  19. 28

    This is exactly what I am experience right now, I upload a new website, then I make a lot of improvement to make it faster and right now the css is not refreshing so not sure if it is the CDN or the .htaccess not sure, I will follow the article to check it out.

  20. 29

    Used theme and number of installed plugins can have a huge impact on the sites’ speed. I decided to test themes and plugins (almost 30.000 in total) and published results on There some plugins and they load huge number of images and javascript files. Be careful what you install.


↑ Back to top