Follow BlogTips via RSS Get BlogTips updates via Email Follow @SM4NP - Social Media for NonProfit

How one small plug-in can slow down your blog

Posted on Jan 11th, 2011 by

question mark

Well I’ll be darned. I am never too old to learn.

Over the past two weeks, I migrated seven blogs from Tumblr to WordPress, onto my VPS (Virtual Private Server) on Hostgator. Concerned about the performance of the server, I scrupulously monitored the CPU, memory and traffic load, as I redirected the domains and as the traffic started to flow in.

There is quite a bit of traffic on those seven blogs, so I use aggressive caching on WordPress, using WP Super Cache.

WP Super Cache has the option to pre-load a set number of posts into a cache: At pre-set intervals, it reads the posts from the SQL database, and converts them to plain HTML files. This way, any visitor gets the pre-cooked HTML file. This creates quite a bit of files, but offloads the server as it does not have to look up each page on the SQLserver. Important for me, as space and bandwidth is not a problem. CPU power is.

That being said, I was astonished to see the CPU load of the server to grow up to the point where everything slowed down. The “Load Average” on the server showed an average of six to ten process waiting to be served. Monitoring the load, I could still see a lot of SQL access happening.

How was that possible? I cached every single page, so no SQL access was needed. I checked and double checked everything. Could not see what caused it these SQL queries. I had everything cached?!?!

Until I found the culprit. I had a plugin “WordPress Popular Posts”, which checked which posts were being accessed, so I could put a “Most Popular Posts” widget in my side column. Thought that would be a cool idea and installed it on all seven migrated blogs.

A cool idea it is, as I use it here on BlogTips. But that is not a cool idea apparently for a high volume site, with limited resources. My poor server was sweating like hell, as apparently all visits are being logged into the database..

I disabled the plugin, cleared the caches, rebuilt them, and voilĂ .. Almost on the spot the CPU load went down from six to ten processes in the waiting queue to less than two. As anything less than four queued processes per CPU (I have one CPU) is acceptable, my server is a happy camper, I am a happy camper, and my visitors are served with faster websites.

Lessons learned: blog performance is sometimes a matter of plain logical thinking. And often the solution is not in “blaming it on the server”, but looking at the blog in front of you. The “adder under the stone” might be right in front of you, with the venom in juuuust a small plug-in.

And I don’t mean to blame this “Popular Post” plugin. It does what it is supposed to do. But it does not work for high volume sites.

24 Comments to “How one small plug-in can slow down your blog”

  1. That plugin should have cached it’s output. It doesn’t make sense for it to calculate stuff on every request, that’s just asking for trouble as you’ve found out.

    Collecting stats data is very expensive, regardless of what plugin. You’re probably better off using Analytics or the stats plugin. That’s what I do. If you’re collecting stats the benefits of caching are nullified because the server either has to write to a log file or a database table on each request which is expensive.

  2. ID says:

    Nice Post.. thanks..

  3. Mathew L says:

    Lots of wordpress plug-ins re-calc everything on the fly — a lot of naive programming out there. Part of the problem is that WordPress provides no easy way for a plug-in to periodically run to update something like popular posts. The only way to do it is a cron() job, which is difficult to set up at many hosters… and each hoster tends to do it differently.

    I use a related-posts plug-in that only runs when you enter a new post. Posting is now slower, but that beats the alternative. Most of the other related posts plug-ins run every time someone views the post!

  4. Donncha says:

    Mathew – you can use wp-cron too. A cron system inside WordPress rather than depend on what the system provides! :)

  5. Mathew L says:

    Cool! I stand corrected…

  6. Daniel says:

    Great post, thanks!!
    I’m having the same problem with my site but I cant figure out which plugin is slowing it down. My first instinct is to blame the hosting company but I’m probably off base. Any idea which plugin would be slowing me down??…maybe the Tag Cloud?

    Any help is appreciated…THANKS!!!!

    • Peter says:


      From here, I can not see which plugins you use, but I took a look at the page speed.

      The tools I use to analyze loading speed are the Firebug and PageSpeed modules for Firefox.

      At first glance:
      - yes, the page could load faster
      - total size of the home page is 1 Mbyte. This is rather big
      - the WordPress loading is about 6-7 seconds while typically it should be 3 or less (which indeed points to bottleneck at server level – this might be the server, a plugin, PHP access?)
      - Is this a selfhosted blog? If so, I don’t see any traces of a cache. Are you using a cache? You should! (and pre-load as many pages as possible)
      - there are six 404′s on your home page (items which were called but not found – mostly icons). These will slow down the loading, for sure

      - I took a random page. which was 1.3 Mbyte. This is too large to load fast. There were the same 404′s. The map takes time to load.
      - there were two errors loading the page

      My overall recommendations:
      - debug the loading using a similar tool, and take out all errors
      - capitalize on caching
      - balance pictures size/quality and loading size
      - balance functionality (map e.g.) with load speed.

      Hope this helps,


      PS: no, the tagcloud does not slow down the blog.

  7. Daniel says:

    Hi Peter,
    Thanks for all the help!!!
    I think Ive got it loading faster now. To get it faster I did the following:
    - Remove WP Thumbie (related posts) plugin. That was a slow one!
    - Update all my other plugins and updated to the most recent verion of WordPress
    - Reinstalled my WP Super Cache
    - Limit the size of photos being uploaded

    Thanks for all the help!!….I owe you a beer :)


    • Peter says:


      Glad you got it resolved. As you use Supercache, play with the preload (preload all of your posts) too. For BlogTips, I preload all posts (with a high expiration time). The more posts cached, the faster the loading of the posts.


  8. Tammi says:

    I came to this post on a search, great information!
    I have been trying to find the culprit on my blog
    My site seems to load fast at times, but it’s my dashboard and editing that takes so long, it times out before it can load.
    I’ve taken a look at all my plug-ins, widgets?
    I’ve also repaired in cPanel, optimized, supercached, and deleted revised posts…
    anyone have any suggestions for me?? I’m at a loss here…

    One last thing, I installed Plugin Hog Detector, and though it says it’s installed, it’s not on my plug-in list, nor anywhere for me to look. Odd that it’s installed, but not showing up at all..

    Can anyone take a crack at mine?

    • Peter says:


      If your wordpress dashboard loads slow, then this is a sign your server is slow. I can see you are hosted on Bluehost, probably a shared server. Shared servers typically have an up-and-down performance. That would be the main culprit. Nothing much can be done about that, except changing to a faster hosting.

      To leverage the slow server performance, I would use more aggressive caching. I can see you are using Supercache, but for every page I view, I see a dynamic page is generated.. so you would have to tweak your cache settings. Try the pre-load mode, and preload all posts, giving a re-load timeout of 24 hours or so.
      if you don’t change your content a lot, put a large life time.


      • Thanks for the reply Peter!
        I am new to Super Cache, just installed it {I just set it to 400 minutes} Would Super Cache be the best one to use? I also see Hyper Cache too, wonder if this one is better?

        And I do add content almost daily, maybe I should upload png photos and not jpeg?

        It’s so super slow to today I can’t stand it. I contacted BlueHost and they said that it’s not an issue on the shared server, but rather my own CPU issue…?


        • Peter says:


          Supercache is fine as a cache! Make sure you set all parameters and test if it works (look at the bottom of the html source file for a page which is supposed to be cached). It looks like your cache is working, but the timeout seems to be too small (any post i check, i see the cache is newly generated). I suggest to use the preload.

          png or jpg does not matter, as long as the pictures are as compressed as possible, and uploaded in the size they are displayed.

          If you have a shared server, you also share the CPU, so their answer seems bullocks to me…
          Again, to me, if your site is already very slow while using the dashboard, then there is little doubt it is your server which is slow. Good caching will hide quite some of the signs of a slow server, but in the end, they will need to do something about it.


          • Tammi says:

            It seemed odd to me that they passed over the ‘shared server’ question so quickly, you think they’d want me to consider getting my own server…?! Very odd.

            I searched online for setting for SuperCache and they seem to be all old versions. None of the ‘help tips’ I found even resemble the settings in SuperCache. I set it to preload, and save, but then when I go back to the settings, it’s unchecked again. Not sure what other settings to test.
            It’s still loading at a snails pace, site and within the dashboard, going on 4 days now. There is nothing more frustrating!!

          • Peter says:

            I had the same experience with Godaddy shared servers… It was “never their problem”… I switched to Dreamhost shared servers, and to HostGator VPS hosting (for my more critical blogs) and saw a real difference!

            I have no explanation why the preload mode would not save… That seems to be a problem… You might try the WordPress user forum to see if anyone there could help you…

          • Tammi says:

            Well, I just deleted Super Cache and am trying W3 Cache. Know anything about which setting I should try??
            I’ve also deleted some plug-ins – I’ll give anything a shot at this point.
            Loading so slow you want to poke out your own eyes due to the boredom, is NEVER good! lol

          • Peter says:

            I tried W3 cache on several of my sites, but did not get the same results as Supercache, so I reverted back to Supercache…
            I just checked your site… seems all php calls to your server take a long time….

            I’m thinking of writing a short tutorial for people on the right settings for supercache…. Some settings might indeed not be obvious to many…

          • Tammi says:

            I’m still not sure how to tell it’s working….it’s not faster, so I guess not?
            And you should write that post {let me know if you do!}
            Like I said, everything else written seemed to be on older versions, not very helpful at all.
            And, the settings make or break the plugin, right?

  9. Marce says:

    Wow, a very informative post, really helps, but i have some questions remaining

    1) Response time… i have 1.733 ms… a big number… but after added wp-cron and wp-log…. goes to 4.000ms… well i don’t know if because the plugin or i get traffic those days.

    Takes 4.6 seconds
    Takes 23 seconds

    Same page, same content, just one difference on the url, the endind bar,

    with “/” at the end take less time… why? and how can i solve this getting every url with “/” at the end

    3) Hypercache, better than supercache? I test both and with W3 and supercache i get higher response times i dont know why… i running this on a windows server

    4) I used to get 2000 visit at the same time without crash… now i have 200 at the same time and… i get a timeout for about 20 minutes (checked with pingdom) or some error like “The FastCGI pool queue is full”… but
    nowdays only timeout

    5) i install wp-cron and i see a Hook Name repeating everytime

    Hook Name Arguments Next Run Recurrence Actions
    dsq_sync_post ["229"] (now) Non-repeating Edit Do Now Delete
    dsq_sync_post ["4659"] (now) Non-repeating Edit Do Now Delete
    dsq_sync_post ["2720"] (now) Non-repeating Edit Do Now Delete
    dsq_sync_forum [] (now) Non-repeating Edit Do Now Delete
    dsq_sync_post ["2682"] (now) Non-repeating Edit Do Now Delete
    dsq_sync_post ["426"] (now) Non-repeating Edit Do Now Delete
    dsq_sync_post ["4712"] (now) Non-repeating Edit Do Now Delete
    dsq_sync_post ["2845"] (now) Non-repeating Edit Do Now Delete

    could be that the problem?

    Can disqus updates only when a new comment is added?

    • Peter says:

      Sorry for the late reply, Marc.. Your comment was stored in the Spam queue… :-(

      From your point 2, it looks like none of your time measurements will be reliable, as there is something else which determines the response time, other than “page reload”. There is no difference between pages ending with “/” and those that don’t.. And you’re getting 20 seconds difference between both. so also your timings for point 1 will not be reliable..

      You say you run on a Windows server. In all the time i have been doing WordPress blogs, I have never seen a WordPress blog running reliably on a Windows server, I am sorry to say. Your point 4 might indeed point to a problem at the server level.
      You did not say if this is a shared or a dedicated Windows server. If it is a shared server on one of the cheap services (e.g. GoDaddy), the performance will go up and down, and response time measurements might never be reliable, unless if you do loads of them, spread over time…

      On the different caching systems: I used all 4 at one point in time. Have found Supercache to be well supported, fastest and most stable (and not too complicated to configure)… But no matter how easy to configure, it looks like every caching system has to be properly configured, tailored to the traffic pattern and publishing pattern of your blog. (do you publish/update old posts a lot? Do the comments clear the cache? Which plugins do you use?…)

      Hopes all of this helps a bit..


  10. Druv says:

    Great tips. however i chose to build my blog with no plugins at all and use every thing that comes with wordpress. I am pretty happy with the results!

Leave a Comment