[Hummingbird] site down twice

i was speaking to someone on chat a few minutes back when we got disconnected. this site has been down twice, he explained the delay in uptime hence it could be false positive. the site has a low score in long loading time in gtmetrix. he did some tests and several images show non compressed. Not sure why wpsmuch will not compress them. I use WP-rocket on other sites and added your plugins on this site for testing after sign up. GTmetric score have been great with Wp-rocket. But with humming bird js, css will not minify and compress, score is not that great. We would like to get this to work before moving other sites to your plugins.

  • Adam Czajczyk

    Hi John Reddy

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

    I checked the site with GTMetrix so let me start with this. There 5 areas reported that, according to the test, could use some major improvements and 3 that may need minor tweaking. Let's first go through the major ones.

    1. Optimize images

    Most of the images reported there are actually coming from external sources. They are some YoutTube images (probably some video thumbnails) and from gopth domain. These images are served from external servers so unless you "proxy" them through your own server there's no way to optimize them.

    There are also some images reported from your site. If you look closer at filenames of these images you will notice that there are three of them that are "original size" images and currently smushing original full size images is disabled on your site in WP Smush configuration - so they weren't optimized with smush. The 4th one is of 400x250 pixels size which, apparently, is not currently registered with your site.

    When you're uploading images to WordPress, WordPress is storing such uploaded image "as is" but also automatically creates number of smaller images out of it, based on "sizes" registered - by WP core, by some plugins and by the theme. Sometimes it happens that after e.g. changing or updating the theme or removing some plugin some of these sizes become "unregistered" - but that never removes (or resizes) images themselves. So, such images stay on site and if they are used anywhere on site, they are detected by tests. Smush, however, processes only those that are of registered images.

    The solution for both these cases are:
    - enable "Smush my original full-size images"
    - either register 400x250 image size or replace that particular image where it's used on site with it's other version (using one of the available registered sizes).

    2. Save resources from a consistent URL

    There's one resource (related to Slider Revolution) reported and it seems to be the very same resources served from the same URL but test detects that it's called in different ways in different places - with and without so called query string. This doesn't have any significant impact on a real loading time in my opinion, personally I would just ignore it. But if you want to take care of it, it might be necessary to play with Slider Revolution settings a bit. However, there's a good chance that Asset Optimization might solve that as well (but I'll get to Asset Optimization later again).

    3. Defer parsing of JavaScript

    You do currently have Asset Optimization tool enabled in Hummingbird but it's not configured at all. This part is strictly related to how this tool is set up and at this very moment apart from being switched on it does practically nothing and you'd need to configure it. I'll get back to it.

    4. Serve scaled images

    This basically means that there are images on site that are dynamically resized by browser according to CSS rules or HTML markup. For example, an image might be of 480x360px and is served to the browser as such but then on page it's displayed as 240x180px. This results in two things: a) it takes more time to send bigger image file than smaller and c) browser has to scale image which also takes time.

    Can it be addressed? Yes and no. Nearly all of these images (except one) are fetched from YouTube servers so they cannot be optimized by Smush but still - that's more of a resizing issue. In fact, in this case the 480x360 px images are displayed as 61x46px images. Depending on how those thumbnails are handled on the site you might try to fetch smaller thumbnails from YT. Those that are fetched are using file name: "hqdefault.jpg"; fetching exactly the same URLs but with "default.jpg" file name would fetch 120x90px images which should increase the score in that area.

    Other way, like in case of optimization, would require actually downloading these images to your server and resizing them there to the target 61x46pixels. Or, you can actually make the site to display them in their original 480x360 pixels if that won't break your layout - that would also increase the score in that area.

    5. Leverage browser caching

    All the resources detected here are from external resources. They are some of aforementioned YT images, they are Google Fonts resources and they are actual YT video player files. There's no way to affect browser caching settings for such resources as you don't have any access to the sources server configuration.

    As for the 3 other, minor, improvements areas:

    1. Inline small CSS

    There are 3 CSS files listed and all are local to your site. It might be possible to "inline" them ("inline" means making them a part of HTML site source instead of fetching from a separate file) without breaking the site but that will require setting up Hummingbird's "Asset Optimization" configuration.

    2. Minify JavaScript

    Apart from some external resources that are listed - such as some Gogole scripts fetched from Google domains - that's again a matter of configuring Asset Optimization.

    3. Minimize request size

    All the resources listed here are actually YouTube video player instances so not really a thing to deal with as it's again an external resource which you can't change.

    That being said, this all comes down mostly to two things: image optimization and Asset Optimization configuration. As I already addressed image optimization, let me move on to Asset Optimization.

    At the moment it's not configured at all. If you go to the "Hummingbird -> Asset Optimization" page you'll see a list of CSS and JS files along with a set of buttons next to each of them and those buttons are switched off (except a few that are "grayed out" - that means that they are unavailable for a specific resource on this specific site). The Hummingbird plugin gives you a granular control over Asset Optimization, unlike most of the plugins that provide similar feature, but while that can give really great results it also comes with a "twist" which is: you need to give it some time to set it all up. This can be a daunting task, I'm afraid, and is more of a "trial and error" process but it's well worth giving a shot.

    For each file you got a set of buttons (ignore the last one that says "don't load the file"):

    - "compress", "combine", "move to footer", "inline" - for CSS files
    - "compress", "combine", "move to footer", "force load this file after the page has loaded"

    The goal is to get as many of them enabled as possible without breaking the site. The more complex the site the more critical it is and that's where the "trial and error" part comes in. It's best to start with 2-3 files form the top of the list and experiment with these options until you get all possible enabled and the site is still working. Then move on to next ones and so on until you reach the end of the list. Please note: after making changes to these options the site has to be visited at least ones for changes to be processed.

    This process can take time but will let you "squeeze" as much optimization of these all resources as possible at all without actually re-developing parts of the site code (plugins and themes).

    Once that's done, it's worth testing whether enabling WPMU DEV CDN in Asset Optimization helps or not - that's different with different sites, hence you can switch it on and off at anytime.

    Then, after that's done the Page Cache should be enabled and once the site builds-up the cache it should get much better results and better performance.

    Kind regards,
    Adam

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.