Hummingbird claims a wrong Pagespeed of 93/100

We optimized our wordpress site with Hummingbird to 93/100! Great job so far, but https://developers.google.com/speed/pagespeed tells something different with 43/100. I think it's because of lighthouse analytics. How can I improve this with Hummingbird, because our client ckecks Google Pagespeed and not at the score from Hummingbird in the backend.

  • Adam Czajczyk
    • Support Gorilla

    Hello INTOUCH

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

    There are two issues here.

    One is that Hummingbird testes “desktop” mode only (though we are planning to add “mobile” as well in future) while PageSpeed tests both but by default shows mobile so you need to switch to d

    desktop mode to see that result.

    The second one is that Hummingbird score in fact… comes directly from Google because we are using Google PageSpeed API. However, as you already know Google has changed their PageSpeed recently (and quite unexpectedly in fact) so they are testing site’s differently and presenting scores differently. Hummingbird, however, is still using previous API – if PageSPeed didn’t change what they show on site, both these scores would actually be consistent. We’re looking into updating that as well but I’m not able to give you an ETA.

    To be honest, I’m actually quite surprised with that big difference because in most cases after that PageSpeed change the score on PageSpeed site is actually better than in Hummingbird :slight_smile:

    Still though, I checked the PageSpeed Insights and from what I see being reported there, I think there are things that could be changed and improved to get the score better, most of them most likely with Hummingbird, but I’d need to check the site – to check it’s configuration.

    That said, could you please enable support access to the site? To do so, go to the “WPMU DEV -> Support” page in your site’s back-end, click on “Grant support access” button there and let me know here once done.

    I’ll then access the site and check it to see what could be done here (please note: except from running performance test and, possibly, clearing cache I will not do any changes to any aspects of configuration without your prior consent).

    Best regards,

    Adam

  • Adam Czajczyk
    • Support Gorilla

    Hi INTOUCH

    Thank you for granting access.

    I checked the site and although the score from HB and PageSpeed currently is different, the recommendations are quite consistent in nature. That’s a good thing.

    I’d start with two things: images and asset optimization.

    1. Images

    It seems that some of the images on your site are already optimized but Google Page speed still suggests resizing 3 of them and Hummingbird detects 13 in total that needs smushing. I see that only some of image sizes are set in Smush to be optimized and I believe there’s a reason for this but still – you might want to review these settings to see if you can safely optimize more of them.

    The three images reported by PageSpeed (check the “Desktop” test result on PageSpeed page) seem to be “full-size” images and it seems that the problem is that they are used on site within containers that are smaller than images themselves. For example: a 1000 x 800 px image might be displayed as 500 x 200px image. I “made up” these dimensions but I hope that explains the idea :slight_smile: Basically, it’d be best to identify where these images are used on site and resize them manually to better fit their containers – or replaces with one of automatically generated smaller sizes.

    2. Asset Optimization.

    This seems to be a “big thing” here. Both Hummingbird (so “previous PageSpeed engine”:wink: and PageSpeed report that quite a lot of JS and CSS files should benefit from some optimization. I checked and on your site currently there is “Asset OPtimization” enabled in Hummingbird but… it’s not configured at all. It’s just “doing nothing”.

    I realize that the feature might be slightly confusing as upon activation it scans the files and that might look like it optimizes them. But it’s not quite how it works: it scans the files to make a list of what could be optimized but then you need to take some time to actually configure it.

    When you go to “Hummingbird -> Asset Optimization” page you’ll notice a list of CSS and JS files and there are 4 buttons next to each of them (ignore the fifth one). For CSS files they are (from left to right): “compress”, “combine”, “move to footer” and “inline” and for JS files they are: “compress”, “combine”, “move to footer” and “load after the page is loaded”.

    The point is, to put it simple, to get as many of them enabled as possible without breaking the site. It’s a bit easier in this case because you can also ignore the 2nd one (“combine”:wink: as it’s already automatically disabled because site uses HTTP/2 protocol which makes all the assets’ downloads parallel – thus combining files is not necessary and wouldn’t make the difference because they are all fetched at the same time.

    That leaves 3 other to configure then. The compression makes files smaller so they load faster. Moving file to footer causes it to be fetched after most of the HTML and other resources has been fetched which also speeds up rendering speed. Making CSS file inline casues it to be actually included in page source instead of being loaded as separate file which in turn reduces number of requests (which, again, affects performance positively) and setting “JS” file to be loaded after the page is loaded ‘”delays” loading and executing JS scripts to the moment after the entire page is already loaded to the browser – that too speeds up page rendering and reduces the “render blocking scripts” amount.

    Setting that up, however, is a bit “tricky” because every site is different and can “react” differently and there are also quite complex relationships between all these assets. As a result there’s no way to fully and 100% fail-proof automate it. That means that it has to be configured manually and the best way to do this is to go in small parts: start from the top of the list and experiment with combinations of these options being enabled/disabled for 1-3 files at the time, all time checking the site to see if nothing goes wrong – and if anything does, tweak these options for these files until as many of them are enabled as possible while the site works fine. Once you got that set, proceed with the next few files and so on until the end of the list. There’s a chance that at some point you might also need to get back a a bit but there’s really no “ready to use recipe” for that.

    But in the end that should give you as good asset optimization as possible (it’s really a powerful tool). Once you got it all configured, you would then also want to test whether using WPMU DEV CDN helps more or not – but I’d recommend doing that only after Asset Optimization options are fully configured. Then you just switch WPMU DEV CDN there and see if that helped more. If not (or it makes it worse – which shouldn’t happen but there are exceptions) just disable that option.

    As a small additional “tweak” I’d also recommend increasing WP memory limit. Your server currently allows up to 500M of RAM memory to be used for PHP scripts (and WP is built with PHP) while your WP install is still limiting it to default 40M. You can add following line to the “wp-config.php” file, right above “/* That’s all, stop editing */” one:

    define( 'WP_MEMORY_LIMIT', '256M');

    and that would increase WP memory limit from 40 to 256M, which should be a good enough for that kind of setup in my opinion. That probably won’t cause any noticeable speed boost but should help a bit with performance and stability.

    Aside of this all, our developers are looking into that Google API change to update it in the Hummingbird plugin as soon as possible and that should make it all together more reliable and accurate as well. So, after that’s done it would be worth to do checks again (though I don’t have an ETA).

    Best regards,

    Adam

  • INTOUCH
    • WPMU DEV Initiate

    Hi Adam!

    Thanks for your great diagnosis. I will try to optimize the assets and the three pictures. So I will compress and move 1-3 files at the same time and will check the site every time. Do I have to purge the html cache every time after publishing the changes as well or does hummingbird this automatically?

    Regards

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.