[Hummingbird] Hummingbird & Smush Pro inconsistencies

Hi guys,

I'm quite disappointed in Hummingbird's performance tests and reporting. I'm seeing similar things on numerous sites and it creates unnecessary concern for clients, and frankly is just wrong.

The first issue is the absolutely stupid percentage calculations for performance test results. For example, on this particular site I have scores of between 96 - 100 for all except "Improve Server Response Time", which according to Hummingbird is 79, then "Optimise Images" supposedly scores 29, telling me there are 7 images that aren't compressed - out of a total of nearly 370 images on the site, yet Smush Pro tells me ALL images have been Smushed, then it tells me there are 8 images which need resizing. So there are a total of 15 images out of nearly 370 that Hummingbird believes aren't optimised, 7 of which Smush Pro believes ARE optimised, and somehow this equates to a ludicrous score of 29% for image optimisation? Those two elements then impact the total performance score of the site massively, dragging it down to 64/100, which is just stupid.

I have enabled support access on this site and I needn't remind you that this is a LIVE client site, so I expect it to be handled as such. I'm unconcerned for this particular ticket about the "Server Response Time" issue, only the images and the obvious issues with Hummingbird and / or Smush Pro.

For the reports and Performance Score to be taken seriously, these issues need to be corrected.

Thanks,
Steve

  • Adam Czajczyk

    Hello PrositesAU

    I hope you're well today and thank you for your question!

    As for Performance Test. This is actually a Google PageSpeed Insights test. Hummingbird is using their API to perform all these tests so the suggestions and scores come from them, though the plugin is only using "Desktop" test for now (though a "mobile" one should be added in future).

    The fact is that Google has just recently changed PageSpeed slightly and HB is still using their previous API, which actually in many cases gives a bit lower scores than the current one (but for the site in question the score is the same). We should be updating it in future.

    Still tho, the test and score calculations come from Google API.

    As for the Smush/image optimization issues reported. I checked your site and there are currently 14 images reported (I'll go from the top of the list):

    1. There's one (the 1st one) image that is reported as needing compression. This is an image of 480x285 pixels size and it seems that this image size is not currently registered on your site. It might be some "left over" from a theme that might have been used in the past or from some plugin that's no longer active or installed but Smush only processes images that are registered on site. You'll see those on "Smush Pro -> Bulk smush". THe 480x285 image size is not listed there and that means it's not registered, thus this particular image was not smushed.

    The solution to this would be either to register such image size or to re-upload the particular image (original, full-size) and replace it on site with one of the automatically generated "thumbnails" as WP will automatically create additional images out of the originally uploaded one and it will use those registered image sizes for this. Such image will be optimized.

    2. Next are 8 images marked as "Compress and resize" and those are that were detected as being bigger than the containers they are displayed in. Those would have to be resized to match their containers. There's a tool in Smush that you can enable to help you identify those images on site.

    3. Images number 10 and 14 on the list are coming from theme so this is something that could only be optimized (compressed) using "Directory smush" option - they won't be automatically optimized or "bulk smushed".

    4. Images 11, 12 and 13 on the current list are also of sizes that are not registered so they weren't processed (the same case as point 1 above).

    Now, I realize that this might seem "stupid" that just that few images that "drastically lower" the score but as I already explained that's how Google calculates that score but it's also important to know that there's no "direct relationshiop" of a number of images that might need some optimization (compression or resizing or both) and the number of images on site. If there's 100 images on site and 10 are reported as requiring optimization it doesn't mean the 90% score for image optimization. Images can have various impact on site performance and that might be scored differently.

    What's even more important: that score and those suggestions are only recommendations on what could possibly speed up the site. I've seen blazing fast sites with really low score and unacceptably slow sites with a score near to perfect. So what should ultimately matter the most would be whether the site does load fast or not and and how, subjectively, the rendering (which is not exactly the same as full load) speed is perceived by end users.

    Kind regards,
    Adam

  • Steve H

    Hi Adam,

    Thank you for taking the time to send your explanation. There are a few things arising from that explanation, though. For example, the image:

    https://yourpinnacle.com.au/wp-content/uploads/pilates-2-480x285.png

    : by the assertions of your explanation, is not "registered" anywhere. Yet that image is one of the generated image sizes created by WordPress when the original image was uploaded and attached to the "Free Pilates Exercise!" post, to which is it attached. So I'm not understanding how it isn't "registered"? All the other images that are 480px wide, that also are being reported as not having been compressed, would also equate to images created during the upload process.

    As for the images that require "resizing" according to Hummingbird, they are also the 480xZZZ images created by WordPress when they're uploaded to posts. That size is designated by the theme. So again, I'm unsure how they're being seen as needing resizing as they're the sizes the theme actually creates for its use.

    What these issues effectively mean, though, is those reports are quite useless for sending to the end user, because even though the site may be "blazingly fast", an end user who sees a score of 63% will never be convinced that result is really only being caused by a few elements that are irrelevant to the loading speed of the site. So it significantly reduces the attractiveness of running those tools in order to be able to generate the reports for clients.

    Regards,
    Steve

  • Adam Czajczyk

    Hello PrositesAU

    There are a few things arising from that explanation, though. For example, the image:

    https://yourpinnacle.com.au/wp-content/uploads/pilates-2-480x285.png

    : by the assertions of your explanation, is not "registered" anywhere. Yet that image is one of the generated image sizes created by WordPress when the original image was uploaded and attached to the "Free Pilates Exercise!" post, to which is it attached. So I'm not understanding how it isn't "registered"?

    When you install "clean WordPress" at first it comes with 4 "built-in" image sizes: a full size - original - image (so that one is exactly what you uploaded) and then "large", "medium" and "thumbnail". In case of your site "large", "medium" and "thumbnail" are, accordingly: 1024 x 1024, 300x300 and 150x150 pixels.

    These are maximum dimensions, except for thumbnail which is set to be cropped to the set size exactly. You can confirm that on "Settings -> Media" page in your site's back-end.

    Let's say that you upload an image named "myimage.jpg" of 1920x1000px to the site:

    - an original one is stored as "myimage.jpg" (1920x1000px size)
    - a "large" one is created out of it and is stored as "myimage-1024x1024.jpg" (even though it's real size will be 1024x533 px because it's resized proportionally, maintaining aspect ratio)
    - a "medium" one is created and stored as "myimage-300x300.jpg" (while it's real size is 300x156px for the same reason as above)
    - a "thumbnail" one is created and stored as "myimage-100x100.jpg" (and 100x100px is it's real size because in addition to being resized it's also cropped to get these exact dimensions).

    This is with "default" images but then the theme adds (registers) some sizes and some plugins might do that too. The same rules apply to them. Regardless of a "real size" of an image, the "registered size" is what you see in a file name.

    The Smush Pro plugin detects all the registered sizes and you can see them on the Bulk Smush configuration page. The 480x285px size is not there and that means that it currently is not registered. I understand that it's been generated by WP but that only means one of two things:

    - it either has been registered but no longer is
    - or the theme or some plugin is not following WP standards and creates that size without registering it.

    There's also no relation between image size being registered or not and the image being attached to the post/page. If it was registered and created, then added to post and then the size is no longer registered, image still stays on site and is still attached to the post it was attached previously.

    All the other images that are 480px wide, that also are being reported as not having been compressed, would also equate to images created during the upload process.

    Width is only one dimension. A "registered size" is always two dimensions. You got currently 5 sizes registered on site of 480 pixels width and with different heights. But if you look into images reported as needing compression, none of them is of any of these sizes if it comes to height (look sizes stated in file names). Note please: I'm talking about those images that are reported as needing "Compression" only but not "Compress and Resize". The "Compress and Resize" is a different thing and in most cases means that image has actually been already compressed but just has to be resized to fit it's container on the site. So, for example:

    an image that has real size of 500x500 pixels is displayed on site as 400x400 pixels image; such image would be reported as "Compress and Resize" and it has to be resized to become 400 x 400 to get better score.

    The fact that theme registers some specific size doesn't necessarily mean that it's a proper size. Image might have been made to be smaller while added to be post (e.g. with CSS or by simply resizing it in post editor or some page builder), some themes also just don't register all the image sizes they are actually using. Furthermore, it's a common issue also with responsive themes where the "biggest necessary size" is registered and added on site but then it gets dynamically resized by the browser depending on device. If that's the case, there's no easy way out of this apart from changing theme to some that better handles responsive images or actually developing you own custom theme.

    What these issues effectively mean, though, is those reports are quite useless for sending to the end user, because even though the site may be "blazingly fast", an end user who sees a score of 63% will never be convinced that result is really only being caused by a few elements that are irrelevant to the loading speed of the site. So it significantly reduces the attractiveness of running those tools in order to be able to generate the reports for clients.

    Performance tests like this were initially created for developers' use mostly as they do give suggestions of what possibly could be improved on site. I'm honestly not quite sure what to respond to you here. We've made Performance Reports available in the reports that you can send from The Hub because Members wanted them to be there but the whole performance aspect of the site (not only performance test grade but performance in general) is really a very complex thing and very individual to the setup (taking theme, plugins, configuration, server and so on into account).

    Kind regards,
    Adam

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.