[Support request] Site Audit

Home Forums Support [Support request] Site Audit

Home Forums Support Site Audit

Viewing 15 posts - 1 through 15 (of 19 total)
  • Author
  • #1661193

    Hi team

    I’m currently working through a site audit and would appreciate your assistance on a few items:

    Site Audit Report:

    I’ve run a site audit that has returned the below on many pages/posts.

    1. “404 not found” error


    Based on something I read in another thread I switched to SVG in Customizer but this hasn’t fixed it.

    Note this issue also arose in the lighthouse report below.

    Lighthouse report:

    1b. Browser errors were logged to the console


    Failed to load resource: the server responded with a status of 404 ()

    2. Ensure text remains visible during webfont load

    Warnings: Lighthouse was unable to automatically check the font-display values for the origin https://**mydomain**.com.au.

    Leverage the font-display CSS feature to ensure text is user-visible while webfonts are loading.


    340 ms

    3. Image elements do not have explicit width and height

    Failing Elements = My site logo

    As far as I can see the logo does have height and width specified. Is there somewhere else I should specify this?

    4. Largest Contentful Paint

    4.5s (on mobile)

    I suspect this relates to the featured image on the Page Hero. Is there a way to deliver a much smaller version of the featured image in the page hero when users visit on mobile?

    Customer Support

    Hi there,

    Quite a lot in one topic, lets try to break things down.

    1.a & 1.b) I don’t see these errors on Google PSI. Have you resolved this already? And yes that’s right this is generally addressed by changing fonts to SVG rather than using the old font icon sets.

    2.) Have you resolved this? I don’t see this anymore when I’ve ran the site through Google PSI. But to answer the question, we generally solve this by either preloading the fonts or by adding font display swap to the google font request.

    Preload text – You can try David’s answer found here:

    Filter adding font display swap –

    add_filter( 'generate_google_font_display', function() {
        return 'swap';
    } );

    3.) You can do this by filtering the logo output, see David’s code here:

    4.) LCP from images usually are addressed by optimizing them. Try using Optimole or Smush plugin to try to optimize them.

    More this: Your site is getting Avoid an excessive DOM size flag.

    This is addressed by trying to remove unnecessary contents within your page. This basically means “hey, your site may be bloated with too many HTML elements, consider removing a few things”.

    This is quite common for sites that use page builders. You’re mostly getting this from using Elementor. You can ignore this if you wish to keep using Elementor.

    A wise man once said:
    "Have you cleared your cache?"


    Hi Elvin

    Thanks for the reply.

    Note I’ve just switched my site details to a blog post as it looks like you are trying to replicate the issues on the home page. Apologies for that.

    1. This error is still appearing in my lighthouse report under Best Practices > Browser errors were logged to the console.

    2. I’m still getting “Ensure text remains visible during webfont load” on PSI.
    For clarification, do I need to use the Adding Local Fonts guide + David’s Hook element + your Filter adding font display swap?

    3. I’ve added David’s PHP using Snippets and changed the height and width attributes but am still receiving the error in Lighthouse.

    4. I use Shortpixel to optimise all images. Lighthouse is saying the LCP is “Element div.page-hero.grid-container.grid-parent.” Will this be the Hero Image? It has been compressed and is 72KB.

    I note that the individual post does not have the DOM size flag, but thanks for the heads up regarding Elementor on the home page. I do plan to move away from this soon.

    Customer Support

    1.) I believe you’ve added this? <link rel="preload" as="font" href="https://homemuse.com.au/wp-content/themes/generatepress/fonts/generatepress.woff2" crossorigin="">

    The path is wrong. Change it to this:
    <link rel="preload" as="font" href="https://homemuse.com.au/wp-content/themes/generatepress/assets/fonts/generatepress.woff2" crossorigin="">

    2.) If you’re locally hosting fonts, you don’t need the filter as you can just do it on the @font-face importation.

    As for the error specifically. You have this CSS that imports the .woff files that are being flagged by PSI. As you can see, the URL on the @import doesn’t have &display=swap.

    The theme doesn’t add this. The customizer has its own indicator which should look like this
    <link rel="stylesheet" id="generate-fonts-css" ...>

    You should check for any plugins that add this in.

    3.) It didn’t seem like it was applied properly as I don’t see the attributes being added. How are you adding the PHP?

    4.) It’s the background. Is it a custom image or a featured image? We can try preloading it.

    A wise man once said:
    "Have you cleared your cache?"


    Thanks for the reply Elvin.

    1. Fixed! This was in the Preload settings in WP-Rocket so have updated as you suggested.

    2. Sorry I don’t really follow this. Is there anything you can point me to that simplifies it? Or could you take a look? I’ve included login details.

    3. I added it with Snippets but had deactivated as it didn’t seem to fix the problem. However, I’ve now reactivated and it seems to be fixing the issue with the logo. Maybe I forgot to clear the cache last time.

    I’m still getting a “Image elements do not have explicit width and height” error in PSI for all other images on the post. Does this have something to do with lazy loading?

    4. The background is a Featured Image + Background Overlay. Keen to try and preload if this is an option.

    5. I’ve removed elementor from the site but am still getting the excessive DOM size flag. Any other tips there?

    Thanks for your help!

    Customer Support

    1.) Nice one! Glad you got it sorted.

    2.) To pinpoint you to the issue, you have this CSS on your site within <style type="text/css">..</style>

    @import url('https://fonts.googleapis.com/css?family=Roboto:700:700,700,700,700,700,700,700,700');@import url('https://fonts.googleapis.com/css?family=Roboto:400:700,700,700,700,700,700,700,700');

    As shown here: https://share.getcloudapp.com/L1uNRoBd

    This is actually the .woff file being flagged when you check lighthouse. I’m not exactly sure what’s adding it as this isn’t the normal way the theme adds Google font requests.

    Perhaps you have a plugin that does this redundant @import of fonts as this isn’t something the theme adds in or controls. (Not sure but I think Qubely’s doing it.)

    3.) That’s something you fix within Gutenberg Editor. You’ll have to check if the images within your content has width and height set on it. You may also have to check if you’ve added any custom HTML with <img> elements as they can cause issues as well.

    Note: <img> element attributes within the content isn’t something the theme controls as Blocks are either from WP core or a plugin. Their specific settings are their own.

    4.) You can try David’s solution here:

    A wise man once said:
    "Have you cleared your cache?"


    2. Thanks for the extra detail. I’ve tested disabling Quebly and you are correct. I’ll either remove the plugin or contacting their support.

    3. I always thought the images did have these attributes, as the numbers appear in the Width and Height boxes of the Gutenberg Image block. However, it sounds like WordPress hasn’t been applying these attributes until v5.5 and still won’t do so to previously loaded images.


    I’ve taken the below code from the second link that attempts to solve this issue. Where should I add this?

    	function( $content ) {
    		if ( false === strpos( $content, '<img' ) ) {
    			return $content;
    		if ( ! preg_match_all( '/<img\s[^>]+>/', $content, $matches ) ) {
    			return $content;
    		foreach ( $matches[0] as $image ) {
    			if ( false === strpos( $image, 'width=' ) && preg_match( '/wp-image-([0-9]+)/i', $image, $image_class_id ) ) {
    				$attachment_id = absint( $image_class_id[1] );
    				$src = wp_get_attachment_image_src( $attachment_id, 'full' );
    				if ( ! empty( $src[1] ) && ! empty( $src[2] ) ) {
    					$image_with_width_height = str_replace(
    						sprintf( 'width="%d" height="%d" src=', $src[1], $src[2] ),
    					$content = str_replace( $image, $image_with_width_height, $content );
    		return $content;

    4. I’ve applied David’s code using Snippets. I ran 3 Lighthouse test before activating and 3 after and the average LCP has increased. I can tell that is being applied though, as the background colour overlay is being removed from the page hero (I had background Overlay set with colour = rgba(28,28,28,0.52)).

    I’ve deactivated the Snippet for the time being as it washes out the Post title.

    For context, when I run the Lighthouse report for Desktop, the LCP is still the div.page-hero.grid-container.grid-parent but it loads in ~1.1sec while on mobile it’s ~5sec and fails the performance metric.

    Customer Support

    Hi there,

    First off:
    3. The Image being flagged is actually the placeholder image that you’re lazy loader is using – its the second image ‘Hozelock Auto Reel with 20 m Hose’ thats off screen when the lighthouse test is run. So that code you mention is not required. You would need to check with the Lazyloader plugin author to ask why its being flagged with no width/height attributes…. before doing so – these are my thoughts.

    1. I would begin by disabling all Cache/Preloaders/Lazyloaders and clear any server caches. Retest the site to make sure you’re seeing the actual network requests and not some cached instanced such as the generatepress.woff icon font that is still being requested.

    2. Review the needs of your site – its currently loading 4 x Font Awesome Icon fonts for what looks like just a couple of icons – i believe this is coming from the Quebly plugin. If you can replace the need for FA that would be great as those files account for around a 3rd of your initial load file size ( they total 250kb for a few icons! ).

    3. Fonts – there are several Roboto fonts being requested, if you can minimise the number of variants you’re using then that would be best – you can deselect variants in the Customizer that you’re not using:


    Font swapping can be a pain – if the fallback font does not have the same structure as Roboto you will get CLS issues. Maybe hosting them locally and preloading them is the best method. The OMGF plugin is great for serving them locally and adding the Preload font request.

    Alternatively and the fastest option is to use the System font instead. It has no font requests.

    4. General – reducing DOM elements where you can – the less HTML the quicker the initial load, the less CSS parsing has to occur therefore the less render blocking. So if theres any other things you can cut back on then its best to do so.

    Retest without your cache plugins enabled and check what are the main issues. Then selectively add the various options so you can see what improvement or negative impact they are causing.


    Hi David

    Thanks for your input, that is all very helpful.

    So, it looks like I should see some improvement by removing Qubely and also switching to system fonts. I’m going to work on this.

    Image Height and Width
    Regarding the Image Height and Width issue, on the post I had included this issue had been rectified for all locally hosted images (the one you mention is hosted on Amazon) because I manually went into the Post and changed the size to Medium or Full Size for all images which seems to give them these attributes.

    I’ve included a new URL where this hasn’t been done and all images are returning this error. Even with lazy loading turned off they are being reported as Failing Elements. The issue appears to be that they have (max width: ###px) and opposed to Width:###px Height:###px.

    I’ve included a screenshot of the error with lazy loading turned off.

    Any idea for a site-wide fix for this?

    Largest Contentful Paint element
    I’m still failing core web vitals LCP due to div class=”page-hero grid-container grid-parent”.
    Do you recommend preloading the Page Hero Featured Image + Background Overlay or any other methods to make this smaller?

    Customer Support

    There must be something else effecting that output – as any tests i have completed ALL Images displayed using an Image Block have both the Width and Height Attributes… whereas those images only have the width.

    Are you using any plugins that ‘effect’ images ?


    Hi David

    I’ve disabled everything that could impact the images and the error persists.

    Someone here mentions “image block itself is still not adding height/width attributes to the markup generated by the block”.

    Also here: “Historically the classic editor has always provided these attributes, but that was changed in Gutenberg, where now the majority of images is without width and height”

    Is this the same issue? Would the code in that second link help?

    I’ve noticed that when I choose a specific Image Size in the block, the HTML “is-resized” disappears – could this be causing it?

    I’ve included a video showing the change in HTML when an Image size is selected.

    Customer Support

    Aah don’t use the size fields in the Block Settings. For example just choose Medium and remove any values from the size fields.


    The numbers in the size fields just appear there by default when the image is uploaded – I haven’t entered anything manually.

    Also, I have hundreds of posts with thousands of images – any idea how to add attributes to all of them?

    Lead Developer
    Lead Developer

    Strange one. If you edit the image block as HTML in the editor – do both fields exist? Trying to figure out whether the attributes are being filtered out on the front-end, or if they just don’t exist at all in the HTML.


    Hi Tom
    Only the Width attribute exists in HTML – see attached.

Viewing 15 posts - 1 through 15 (of 19 total)
  • You must be logged in to reply to this topic.