Facebook Pixel
Join our Facebook Community

How to Know Which Plugins are Killing Your Site’s Performance

Posted By Guest Blogger 8th of December 2011 Blogging Tools and Services 0 Comments

This guest post is by Matthew Setter of Malt Blue.

You know the situation: your site’s been slowing down for a while, but you just can’t put your finger on why. Then you get a tweet, an email, or a comment on your Facebook page mentioning it. Even worse, you see someone talking about your site in your niche’s main online forum—they’re not impressed with your sites performance.

What was once an amazingly quick-loading site has slowed and slowed to a crawl. Your visitors are growing unhappy and may even be starting to look for alternative sites. To be honest, who could blame them for wanting to seek out someone else that serves their needs better, in less time?

What makes things worse is that you’re not really a geek or a tech-head and you don’t know what to do about it.

You ask yourself:

  • How can I find out what’s killing my sites performance?
  • How do I know where the issues are?
  • How can I give someone the right information to help me?

Well in this post, I want to help you do just that, by giving you a quick introduction to analyzing your site’s performance using one of the simplest, free, tool package of all—Google Chrome’s Developer Tools.

Now I appreciate that we’re not all geeks or tech heads, and that more than likely, this isn’t something that you’d do on a regular basis. But that needn’t stop you. You can be partially autonomous without being either a nerd or programmer.

So I am going to show you, quickly, just how easy it is to use the developer tools available in Google Chrome, to work out which components of your blog are causing you issues. With that information, you’ll be able to take action yourself if you host your own blog, or report this to your tech support if you don’t.

What are the Developer Tools?

The official Developer Tools blog describes them as follows:

The Developer Tools, bundled and available in Chrome, allows web developers and programmers deep access into the internals of the browser and their web application … The Developer Tools are organized into task-oriented groups that are represented by icons in the toolbar at the top of the window. Each toolbar item and corresponding panel lets you work with a specific type of page or app information, including DOM elements, resources, and scripts.

Now okay, there’s a bit to take in there, but if you’re not comfortable with all that, don’t worry: it simply means that these tools provide a way of finding out specific details about each component of the web page that you’re currently viewing.

They allow you to filter by category, and sort the available information by a simple set of key criteria, such as size, time and type. The image below shows you a working example.

 How to Know Which Plugins are Killing Your Site's Performance

Step 1. Open Developer Tools

The first thing that we want to do is to display the Developer Tools window in Google Chrome. After opening Google Chrome, click on the wrench icon on the right-hand side of the main Chrome window. In the menu that pops up, move your mouse over the Tools option and in the next window that pops up, click Developer Tools (this is second from the bottom).

How to Know Which Plugins are Killing Your Site's Performance

Step 2. Get familiar with the Developer Tools window

All being well, you’ll see the Developer Tools main window, which looks similar to the screenshot above. You’ll see a set of tabs across the top, including:

  • Elements
  • Resources
  • Network
  • Scripts
  • Timeline
  • Profiles
  • Audits
  • Console.

How to Know Which Plugins are Killing Your Site's Performance

The one that we’re focusing on is Network, so go ahead and click that tab. Now you’re going to see what seems like a large amount of information, but don’t worry—before you’ve finished this article, you’re going to be an ace at making sense of the parts that are most important.

Step 3. Filtering options

Now, take a closer look at the footer> of the window, right down the bottom. You’ll see a set of menus, which include:

  • All: Displays all the components in the page
  • Documents: Displays only HTML output
  • Stylesheets: Display CSS stylesheets
  • Images: Display all images (.png, .jpeg, .gif, etc.)
  • Scripts: Display all Javascript (inline, external).

These options allow you to filter the components that make up the current page. In this case, it’s the Facebook fan page of my first blog, Malt Blue.

By default, the All option is selected. This shows you everything in the page. This is a bit much to work with, so go ahead and click each option and notice how the list can dramatically change in size.

Now take a closer look at the row under the main menu. It has a series of columns that allow you to sort the available information. They include:

  • Name: the name of the HTML page, image, stylesheet, etc.
  • Method: whether the item was requested with GET or POST
  • Status: some information about status of the item
  • Type: a text description of the item’s type
  • Initiator: what requested the item
  • Size: the size of the item
  • Time: the time taken to retrieve the item displayed in text
  • Timeline: the time taken to retrieve the item displayed as a graph.

The key columns, however, are Name, Size, Time, and Timeline. By focusing on these columns, you can see that of the eight displayed, the first one took 1.57 seconds to load with a size of 65.40KB. Not too bad overall. If you’re a visual person, like me, then sort using the Timeline tab.

Okay, so you’re now more familiar with the available options. But for the quickest assessment, the two key columns to look at are time and size. Let’s consider each in turn.

Step 4. Sort by time

This one is probably the best one to use when it comes to finding rogue components. It was a god-send recently when it was able to tell me that a MailChimp sign-up widget in my sidebar was taking over 15 seconds to fully load.

So click on the Time column until it has a downward facing arrow next to it. Then, you’ll see the components in the page, displayed from slowest to fastest. In the column, you’ll see two numbers for each component, one in grey and one in black.

The number that you want to focus on is the top number in the black font. This shows you the total time that the component took to load, right from when it was requested by the browser, to when it was displayed on the page.

Step 5. Sort by size

This is probably the second-best option to sort by, especially if you’re more of a numbers than a graphics person. As you did with sorting by Time, click on the Size column until it has a downward facing arrow next to it.

Then, you’ll see the components in the page, displayed from biggest to smallest. In the column, you’ll again see two numbers for each component. Once again, focus on the number in the black font. This is the total size of your component.

Step 6. What To Do

So far, we’ve opened the Developer Tools, familiarized ourselves with the Network window, played around with its key options, and finished up by getting to know the components in our web page.

But what do you do now?

Based on time and size, take an inventory of the biggest and slowest loading elements of your page. Then look to see what you can do to reduce these points. To save you time, here are my top suggestions for speeding up your site with this new knowledge:

  • See if the elements relate to plugins or widgets that you’ve installed. If so, consider disabling them or finding an alternative that loads faster.
  • Look at the slowest loading or biggest images. Maybe you’ve set the width and height to make them appear smaller. Could you:
    1. optimize them for displaying on the net?
    2. scale them down in size without losing quality?
    3. remove unnecessary parts of the image?
    4. use another image format, producing a smaller file size?
  • Do you load a lot of CSS stylesheets or Javascript files? Could you:
    1. combine them in to one file?
    2. load some from external, faster, sources, such as Google?
    3. shrink the Javascript and CSS files with online services such as jscompress.com or minifycss.com?

Don’t manage the site?

What if your site’s managed for you by someone else?

In that case, get in touch with your tech support and tell them all that you can about the slow components that you’ve found. Tell them what they are, how long they’re taking to load, the size of them, and so on. An even simpler option may be to send them an annotated screenshot of the developer tools window where you’ve highlighted the results that you’ve found.


Like all new things, give yourself time to become familiar with the tool. As you do so, you’ll grow a proper appreciation for what’s fast and what’s not, what’s a good size for a file or an image and what’s not, and so on.

Then, as this knowledge builds, you’ll be increasingly autonomous and better informed about the state of your site.

I hope that you’ve found this helpful and that in future, when your site’s exhibiting poor performance, you’ll be in a much better position to perform the initial diagnostics yourself. You’ll be both better informed and more able to let your tech support know when issues need to be addressed and where.

Matthew Setter is a passionate writer, educator and software developer. He’s also the founder of Malt Blue, dedicated to helping people become better at web development.You can connect with him on Twitter, Facebook, LinkedIn or Google+ anytime.

About Guest Blogger
This post was written by a guest contributor. Please see their details in the post above.
  1. Thank you! From a definite non-tech head this was incredibly helpful. Thanks :)

    • Matthew Setter says: 12/18/2011 at 7:39 pm

      Hey Amie,

      glad that you liked it. Any suggestions for what to write next?


  2. Thanks so much! I was really struggling with slow site speed a few months ago and this would have helped so much . . . now I’m going to see if I can speed things up some more!

    BTW, this is the type of post I really find useful! A serious, in-depth how-to.

    • Matthew Setter says: 12/18/2011 at 7:40 pm

      Hey Carolyn,

      Really glad it’s helped you out. Have you had any success in speeding up your site?


  3. Unfortunately, this guide does not give much info about plugins running strictly on the server which do not output html/css/js, ex: tiny links, related posts, etc… But it is a good starting point to see if you should start spriting your images and packaging CSS/JS files.

    • Agreed. The title is a bit misleading in that it doesn’t tell me about plugins. So I was disappointed to read the entire thing and find nothing specific about WordPress Plugins. It’s good for novices though.

      I tend to use http://www.webpagetest.org/ to see what is causing load issues if it’s a certain add code or third-party widget.

      • Matthew Setter says: 12/22/2011 at 10:45 pm


        sorry about the title being a bit off-base; but I’m glad that, as Alain said, it’s a good starting point. I didn’t want to pitch it too high, yet at the same time, I didn’t want to be condescending either. Thanks for the feedback. I’ll be more on target with the title next time.

  4. This is a fantastic walk-through; easy enough for newbies to understand and I’m going to send a long a link to all of my clients who do a fair share of their own site management.

    Question: how do you suggest improving performance in situations where the lion’s share of load time is occupied by the webpage and not a stylesheet or plugin element?

    For example, at my blog homepage, the stylesheet (from woothemes) only took 930ms; it was the second highest time item but the bulk of time was the actual page, a text/html item with a size of 15.98KB and a load time of 2.77sec.

    • Hi Drew,

      Since you have quite a few images on your home page, you might think about creating a subdomain to host your images. It creates an extra “pipe” so your images will load in parallel with your html/CSS. I show how to do it on my blog:


      • Interesting solution and a nice option to something like a CDN – thanks!

        • My pleasure! Thanks for checking it out.

        • Matthew Setter says: 12/22/2011 at 10:53 pm

          Sorry for giving feedback so late. I’ve had some issues being able to do so until now. Bryan said it well, in that if you have a separate domain, or sub-domain for your images (and your CSS as well) you can take advantage of the ability of browsers to download multiple items simultaneously.

          I’ve run a quick analysis on your site (nice one by the way) and there are a few things you can do to speed up the site further:
          – Put your CSS links before your Javascript. This will enable the browser to render the page faster from the perspective of a user, even if it’s still working in the background
          – Consider combining a number of the CSS and Javascript files that you have in to one, or fewer. This way, there’s less network overhead involved in retrieving and rendering them all.

          I hope this helps – you’ve got a new reader.

          • Matthew Setter says: 12/22/2011 at 10:55 pm

            Actually, have you considered the cloud options, such as Amazon EC2 or Rackspace?

  5. Great explanation other use of developer tools. This is something that seems so complicated for many of the way you explain it makes it seem very easy. Thanks for a great explanation

    • Matthew Setter says: 12/22/2011 at 10:54 pm

      Thanks Steve.

      Are there other topics that you’d like covered or explained?

  6. This is a really cool “how to” to play around with Matthew. I can now see what is loading the slowest on my site.

    Thanks man!

  7. OK, but you still need to be techy to actually do anything with the results which is where I got stumped. I guess to shring my CSS files I’ll need to ftp in to them, download them, use the compression service and then upload them to overwrite the original uncompressed file. All a little scary a fraught with danger.

    My report told me a number of my jpegs were not optimal, even though I had sized them specifically in Photoshop. My only guess is that instead of compressing to a level 7 that the report was telling me a higher compression – say a 5 or a 4 would be adequate. As a photog its kind of tricky to know because if someone uses a photo zoomer then the lesser quality of more highly compressed image might become more noticeable.

    My point is that it’s a tricky, iterative and time consuming challenge. My recommendation is that you look at the overall page speed and decide from there if you want to dive into specific components. When I last checked several pages on my site they were coming back with overall ratings in the high 80’s – low 90’s with most of the report referring to minifying css, improving JPEG compression and something about asynchronous Java loading.

    That last one, changing the Java to asynchronous, I couldn’t figure out how to achieve. Any help on how to address the Java loads would be appreciated!

    • Matthew Setter says: 12/23/2011 at 6:01 am

      Hi Richard,

      sorry for taking so long to get back to you. Generally speaking, if you’re using external CSS and Javascript libraries, such as jQuery, they often come in both compressed/minified versions and non-compressed/normal ones.

      Also, a lot of the good ones and bigger ones are hosted by companies, including Google. So to start using them, all you likely will need to do is to change one of the header templates in your WordPress/Blog setup. Failing that, yes, you may need to do some FTP work.

      With images, you can look at different options, such as hosting these on sub-domains, allowing the speed up of the download speed. I’ll come back to you shortly on the asynchronous Javascript.

  8. this looks a bit hi fi and technical stuff. but sure a help. thanks for the share.

    P.S.— you missed point #4..is that intentional or you missed it knowingly?

    • Georgina Laidlaw says: 12/12/2011 at 7:09 am

      Oops! Thanks for the headsup Tushar :) That was an editorial error…

  9. http://www.webpagetest.org does the same thing, but better. You can see your Time to First Byte and a very detailed breakdown of the time required to download each element. The interface is somewhat similar to Chrome’s Dev Tools but with a lot more info.

    • Matthew Setter says: 12/23/2011 at 6:04 am

      Hey AC,

      thanks for the link to webpagetest.org. I gave it a try and I completely agree that it’s very very informative indeed.

  10. Thanks Matthew. This is reason enough for me to download and start playing with Chrome. Another useful tool to help diagnose slowdowns is Google’s Page Speed Online:


    • Matthew Setter says: 12/23/2011 at 6:04 am

      Excellent Bryan. Thanks for the recommendation. I’ll be checking it out shortly.

      • Matthew Setter says: 12/23/2011 at 6:05 am

        I do ok on that report – hmmm, now to make it exceptional.

  11. Great article, and how to pin point and test to find out what wet clothing you need to remove/replace.

  12. Hey Matthew
    I love it when people make complicated technical things simple for me because I’m an old school. non technical guy. This is also a huge issue for some as people get less and less tolerant of slow load times and it’s only going to get worse
    BTW it would be an awesome info product to “simplify” the top 20 technical thing’s that keep non technical people from succeeding online. I think you’d kill it with that product (if you’re so inclined..)

    • Matthew Setter says: 12/23/2011 at 6:07 am

      Hey there Mark,

      thanks for the feedback. I try my best to take what I know and communicate it as clearly and concisely as I can. And in an age where we’re all trying to make our site/service/product as good as we can, I don’t see a lot of time for mucking about.

      Hmmm, I like your point about the top 20 technical things. What would be your suggestions for the top 5? Maybe we can start from there.

  13. Thank you so much for this post! Even though I was a web developer in my former life (aka. Before Kids!), I still feel overwhelmed sometimes by all the new tools available for building/maintaining a website. Thank you for introducing us to this tool and for showing us exactly how to use it.

  14. Good to know, never took the time to look into this, but with the latest Google update, apparently speed means a lot for SEO, so I’ll take the time to check each one of my sites and try and make them faster.

    Thanks for sharing the info for Developpe Tools.

  15. Great stuff Matthew. My only trouble is that my site loads pretty quick in Chrome. It’s IE that is really slow!

    • Matthew Setter says: 12/23/2011 at 7:08 am

      Hey there Paul,

      Google put a lot of work in to the architecture of Chrome. If you have some time to kill, they’ve put out a comic that shows how it works in a pretty clear manner. To be fair to IE, they have a lot of legacy to support, but the nature of Chrome lends itself to very quick page rendering times. What versions of Chrome and IE do you have?

      If you’re keen, then I’d definitely recommend IE 8 & 9 if you’re wanting to stay with IE. However, this naturally is also dependent on your audience profile as well. If I may ask, what percentage of your audience uses IE?

  16. Never realize how plugins can harm, good content by Metthew and agree with Paul Munford as it takes more time in IE. More comprehensive info for non techies who can easily manage the steps by absorbing above lines..Thanks for sharing!!!


    • Matthew Setter says: 12/23/2011 at 7:10 am

      An absolute pleasure Hina. I’d love to share more if it will help people get the best out of their sites. All too often I hear people talking about getting bigger and better hardware before looking at how to make the best out of what they already have. I’m fortunate in that the majority of my audience uses a combination of Firefox and Chrome, so I’m not too concerned about IE.

      Are there any further topics that I can help you with?

  17. hello,

    have a quick question about some of the WordPress blogs that are available to be downloaded for free. I noticed that after installing some of the WordPress plug-ins on your personal dedicated server are not able to be deleted, if you want to remove them from your WP plug-ins list in the root of your server. My guess is that some of the plug-in developers use sneaky tactics to force their plug-in to stay on your server, so that they can get that back only an benefit from increased “search engine optimization”. When this happens to a person that owns a WordPress blog and can’t remove the WP plug-in, how can one go about successfully removing the WP plug-in, though it is not able to be deleted? Is there something within the PHP code that can be edited, so that the file can be deleted by chance? :-)

    • Matthew Setter says: 12/23/2011 at 7:11 am

      Hi Drewry,

      sorry to take so long to get back to you. Do I understand you correctly that you have a self-hosted WordPress install, instead of a WordPress.com account? If so, the usual process is to first deactivate the plugin, then to delete it. You can’t delete it without first deactivating it. Give that a go and let me know how it goes. If you’re still having trouble, we can investigate further then.

  18. So, so, so glad this came across my feed today. I have been in the exact position you describe (not a techie, disappointed that my site is running slowly, and overwhelmed by the prospect of checking each plug-in.) Thanks, Matthew!

    • Matthew Setter says: 12/23/2011 at 7:12 am

      Anytime Heidi. I’m really glad that the post helped you out. It’s definite encouragement to write much more.

  19. Good idea. I might try it soon. But I feel like all my plugins are “Essential” and have no alternatives… ah well! Maybe if I see very bad stats I’ll feel otherwise.

    • Matthew Setter says: 12/23/2011 at 7:13 am

      You can have a lot of plugins Alisha. The key is to keep a running benchmark on your sites performance and know if it’s slipping and the action to take to rectify it.

      The second aspect is to know a set of good rules of thumb on how to tune and optimise your blogs performance. I’m not talking about massive work, but the key things to keep in mind.

      All the best.

  20. very detailed post, Mathew.

    I do not have Google Chrome, so I am stuck with a very average looking Web Developer consul.

    I once had an immediate increase in site speed, by simply removing one of my sidebar widgets.

    It went from taking ages to fully load, to being fully loaded in no time at all.

    Unfortunately, with my constantly adding widgets, ad-dons and extensions, I have gone and slowed my site down noticeably, again.

    Also, there are free online Template error checks(Audits) that can be done, that give some interesting details about what is causing issues. How accurate they are, is another question altogether.

    • Matthew Setter says: 12/23/2011 at 7:15 am

      Hey there Daniel,

      I can totally relate to the performance ebbs and tides when you’re playing around with blog configurations, options and settings. After you’ve got the combination of features sorted out, then’s the time to get in and look to tune it up. Keep at it.

  21. Thanks for the great post! I was wondering how my site was loading and your explaination was very easy to understand and do. Thank you!!

  22. I haven’t yet encountered this problem yet but who knows in future it might be. I’ve saved this page for future reference in case I need it and the way it is all described, I’m sure I’ll be able to handle it myself. Thanks for a great post.

  23. Thanks Matthew. You just made this look easy. I have often wondered if I have plugins that are affecting my performance.

    • Matthew Setter says: 12/23/2011 at 7:16 am

      From time to time I’m sure we all do. Glad to be of assistance.

  24. Hi, Thanks for the post.

    My problem is a long latency (sometimes even 15 seconds). Should I change the web host I’m using?

    • Matthew Setter says: 12/23/2011 at 7:17 am

      What’s the element that’s causing the latency? That’d be the first point to check. Sometimes plugins such as Twitter, Facebook, LinkedIn and Google+ etc can cause these issues. Can you get back to me as to what’s causing it – then we’ll nip it in the bud.

  25. Hi
    That is some great tips you provide here. I have from time to time had problems with WordPress Plugins or widgets slowing down my blog. I have often use Pingdoms free online tool for troubleshooting those kinds of problems. You can check it out here: http://tools.pingdom.com

  26. Might have to get Chrome on my laptop after all! I have had numerous issues with my site speed, and recently moved to a faster server, removed some files, got rid of the SSL verification script and still I find it is somewhat slow. Perhpas your advice can highlight some other issues. Thanks…

    • Matthew Setter says: 12/23/2011 at 7:17 am

      I hope that it has Steven. Did you find out what the cause was?

  27. Thanks for this useful information. I found my way here via a share on G+. It is great when there is a place that will share important information like this. Thanks again for sharing. I think you made the steps very easy to follow, and very useful for site creators.

  28. Thanks for this wonderful and comprehensive tips. I will just direct this link to whoever who asked me issues related to their plugin :)

    • Matthew Setter says: 12/23/2011 at 7:18 am

      That’s music to my ears Ricardus. Happy to help wherever I can.

  29. Exactly what I have been looking for. My site has been slow the past week and I initially thought it was just slow access from the server but it has steadily got worse so I am suspecting it’s one of the recent plugins I installed.

A Practical Podcast… to Help You Build a Better Blog

The ProBlogger Podcast

A Practical Podcast…