Here we are looking at Usage DD. A free utility plugin from the WordPress repository that allows us to monitor the server resources used in a WordPress install.  It’s a simple and lightweight and  gives us key performance indicators wherever we happen to be in WordPress.

What happens when Usage DD is activated?

It simply adds a small transparent bar to the bottom of every page when you are logged in as a WordPress administrator. It shows regardless of whether you are in the front or back and when even editing with a Page Builder (I tested with Beaver Builder, Elementor, Brizy and Oxygen builder).

The page information it gives for left to right is (1) number of queries  (2) execution time of those queries (3)  “time to first byte” (TTFB) and (4) Memory usage.

 

Note: you need to be running a standard WordPress install with PHP 5.4+ and consider the accuracy of the information given.  I found Memory Usage would suddenly show a high figure. Resetting the php version on my server corrected this and saved me jumping to wrong conclusions over some plugins.  Also the plugin claims that the query count is 100% accurate, but noted it seem to count a higher number than two other plugins:  Query Monitor and Black Bar.

Why bother if page load scores are great?

Like many others, I spend most of my time in places like Pingdom tools, GTMetrix and my favourite Web Page Test.org looking at the results of cached pages.  Generally, if the actual load times are good I don’t get too hung up about Google PageSpeed score.

Mostly I will have a quick look at the load waterfall for heavy images and  check the “Time to First Byte” which usually tells me whether it was showing a cached version. If there’s time I will look at the video recording Web Page Test.org produces as this gives me an idea of the perceived load time for a visitor. Sometimes that last .js file, that is slowing the load, is just not going to be needed by the visitor immediately and it is not worth the worry. Anyways, I think there are a few reasons why we should not only focus on page load and consider using tools like Usage DD…

1. Page caching plugins don’t solve all our speed issues

Certainly the serving up of HTML versions of a page is quicker than having the server do all the processing that a WordPress install requires and particularly it speeds up that “time to first byte”, but:

• Caches need to be reset (sometimes automatically with plugin updates) so not all visitors get the cached version.
• Dynamic pages like e-commerce cart and checkout pages can’t be cached
• Actions with require dynamic backend functionality like adding a product to a cart or submitting a form still require processing time.
• It does not speed up the backend or logged in experience.

2. It could save us some hosting problems and expense

With shared hosting we are at the mercy of  hosting companies when it comes to how much RAM we are given. Even if all seems good now some hosts are generous while attracting customers and then they later optimize for profit. Along with that many popular plugins keep adding more features eventually we could feel the pinch.

But even if, like me, you have VPS solution and the RAM under your control you may want to keep plenty of server resources in reserve.

In my case I find I am encouraging more clients to use a page builder than before so I am looking to see whether I have unneeded plugins activated or can swap and under use “heavy” plugin with a lighter alternative.

3. It might make us a little wiser over our software choices 

True story: I bought a WooCommerce theme that I thought was beautiful and absolutely perfect for a rebuild of a shop we ran. It took literally hours to set up and I was thrilled.

Then I added our products, previous orders, customer data and things got slow. Then I add my WooCommerce extensions and security, SEO, and Backup plugins and it was clear processing and order was going to more an more painful as we got more orders.  No problem – I like this theme so I upgraded my VPS. Then, came a series of updates of which improved front end loading with clever caching but only slowed the backend and ordering process.

I could see where this was going more requested updates were sure to come so I rebuilt using  Genesis.  It was the right move as the author pulled the theme about 18 months later.

I am not saying “all in one” solutions are bad. Some careful to modularize features, but generally as WordPress users we are implementing solutions build for many types of people and projects and need to balance the tools we use against others and think about long term running cost.

How to read the numbers?

The lower the numbers the better, but it all needs setting in context. Usage DD gives some guidance which is similar to what I have read more generally:

•  Number of queries: ideally under 50 and if over 150 you could have a theme/plugin issue.
• Execution time of queries:  queries are not equal so looking at the time maybe better than the numbers
• “Time to first byte” (TTFB) should be under 0.2 seconds.
• Memory usage: ideally under 32 MB (which is the default amount set in WordPress).

I think the best way to use this plugin is to not get too hung up on the actual numbers, but look at the relative different as you add plugins and new element to a page.

So far  I have seen my number of queries are never under 50 and often over 150 without issue. The minimum I could get with the Twenty Nineteen theme WordPress was 13Q  (with WordPress widget removed)

What I have found is that I can do quite complex sites with the memory usage under 32MB, but, not if adding heavy plugins like E-commerce or Learning Management Systems.

What I did with my initial testing

I cover this in the video above. I am not comparing competitor plugins there as I think it would be wrong without full context.  But adding Usage DD has made me reevaluate my stack and what a project actually requires.  I won’t be leaving unused plugins activated or adding pro addons unless I know the features will be used.