Support » Plugin: Recent Posts Widget With Thumbnails » Images served uncompressed

  • Resolved igb10


    I love your widget and it works fine. But 1 problem I noticed is increased loading time. Then I measured at pingdom and I noticed that my images are loading at full resolution weight of around 600 – 700 kb each.

    My thumbnail settings for this widget are 372px width and 0 height while keeping aspect ratio. So if you look to the page that I provided above, you can see that images are loading at the correct size of 372 width and automatically resize the height based on keeping aspect ratio. So it looks good.

    However the images come from “Featured Images” which are either 2000 x 1200 or very close to that. Although they are resized to 372 width on screen, they are served at full weight of 700 kb or so. If you go to that page and right click on the image and “Open image in new tab” – it will open at full 2000 x 1200 resolution – because it will be un-resized in the new window.

    Normally my other images are automatically compressed to much lower weight. Is there a work around?
    Thank you,

    The page I need help with: [log in to see the link]

Viewing 15 replies - 1 through 15 (of 15 total)
  • Plugin Author Martin Stehle


    Please set a height larger than 0 because the plugin uses a WordPress core funtion to get the images, and WP tends to choose the full size if one of the dimensions is set to 0. In the case of your website I think a height of 210 px would match the most images. The aspect ratios keep untouched.

    That didn’t help, even made it worse. If I specify height and width, and don’t check-mark “Keep aspect ratio” – all the images are still served at fill weight. But now.. the image loses it’s ratio on the resize or serving at smaller screen – and they start to look really bad. So I went back to height 0 and 372px wide and checked to keep aspect ratio no matter what.

    But now I noticed something really weird: on my home page all images in this widget are resized down to approx. 768px width. Still not compressed to 371px that I want… but much better than 2000 px width. Also my other categories/ archives pages serve the same reduced to 768px or so. However if I go to the Post page… all the images in the widget are still serving at full 2000 px!

    So what is the difference on how this widget works differently on archive pages.. comparing to the Post pages? Because it serves the same images at different weight.

    Thank you,

    Plugin Author Martin Stehle


    Please set the width and height again with keeping of the aspect ratio activated.

    Ok, so now I specified the size 372×209 and check-marked to keep aspect ratio. So my home page, archive pages and search pages continue to serve at reduced size, but only reduced to 768×432 resolution, while displaying 372×209 correct size on the screen – so the same thing.

    However something changed on my Post pages, so there is a little progress. Featured images with original size of 2000×1125 are now served at reduced 1024×577 size, which is still very high… but much better than 2k! But if original featured size is 1280×720 – then image is NOT reduced at all and continues to be served at original size.

    So there is a difference at service on archive pages and Post pages.
    Here is HTML of the image when I click Inspect on Archive page:

    <img width="372" height="209" src="" class="attachment-372x209 size-372x209 wp-post-image" alt="Mercedes C-Class Sport" srcset=" 768w, 300w, 1024w" sizes="(max-width: 767px) 89vw, (max-width: 1000px) 54vw, (max-width: 1071px) 543px, 580px">

    Here is HTML of the image when I click Inspect on Post page:
    <img width="372" height="209" src="" class="attachment-372x209 size-372x209 wp-post-image" alt="Mercedes C-Class Sport" srcset=" 768w, 300w, 1024w" sizes="100vw">

    Plugin Author Martin Stehle


    I can not comprehend how you see the use of 1024 px and 1280 px. Take a look at the src attribute of the img element:

    That image has a dimension of 768 x 432 px. Compare that with the images listed in the srcset attribute, sorted by width:
    300 x 169 px
    768 x 432 px
    1024 x 577 px

    The first dimension is too small, so the next dimensions are tried, and the second dimension is the one which fits your specified size at the closest, and that is used as the displayed image.

    So I see the plugin working correctly.

    I know… I’m puzzled myself. But click on the link I provided above on top in the first post and open this page. On the right side you’ll see 5 posts in the widget of the side bar.

    Then if you use Chrome – right-click on the image and click on “Open image in new tab”. All of them will open in either 1024 or 1280 resolution.. You can also Inspect it right there.

    On my home page and archive pages it works as you described at 768. I already cleared cache on website and Cloudflare.

    Plugin Author Martin Stehle


    Please right-click on the image again and call “Inspect…” or take a look at the HTML code. The huge image with 1280 px width and mentioned in the srcset attribute is not used in the posts list but the image of 525 x 295 px and mentioned in the src attribute. Again the plugin works correctly.

    Instead of right-click and “Inspect”, right click and “Open image in new tab” and see the uncompressed size.

    Or you can do it easier. Look at Pingdom website speed report here:!/bv9a3C/

    Scroll down and check “File Requests”, you can click on “Size” to filter by size. You can see some images served are over 300kB! And the whole page grew to 2 MB. Then click on one of this images files name. For example click on “2019-C63-AMG.png” and it will open in the new tab – and then just look at the size.

    Plugin Author Martin Stehle


    Ok, I can see that now and we both are right: the plugin returns the correct HTML code and the browser uses the bigger image sizes. I do not know why the browser or Pingdom does not request the image file as defined in the src attribute but requests another one. That behaviour is not a fault of the plugin.

    I’m trying to understand how it is possible myself. Also I don’t think that both browser and Pingdom don’t know what they are doing..

    Clearly I can see from 2 HTML results that I provided from above that there is a difference in HTML of the same image serving at different pages. Bot codes look exactly the same… except the ending:

    Here is the ending of HTML code image served at Archive page:
    sizes="(max-width: 767px) 89vw, (max-width: 1000px) 54vw, (max-width: 1071px) 543px, 580px"

    Here is the ending of HTML code image served at Post page:

    Everything else between 2 CSS codes is the same. The only difference are SIZES attribute. The second image is served at 100 Viewport – 100vw. That’s why it serves 1024px wide or even 1280 if it’s the original size as long as it fits in 100 viewport.. Obviously 2000 will not fit in vw and it is resized to nearest 1024.

    Can you fix your plugin that it can serve the same CSS for Post pages as it serves for Archive pages?

    Plugin Author Martin Stehle


    The plugin uses a WordPress core function to get the HTML of the IMG element, and that function also calculates the srcset and sizes values. I prefer to keep on using that function to support responsive image sizes.

    But there is a way for you to control the values of the attributs srcset and sizes. Open the file “functions.php” of the theme, insert these lines at the end and save it:

    add_filter( 'wp_calculate_image_srcset', '__return_false', 10, 0 );
    add_filter( 'wp_calculate_image_sizes', '__return_false', 10, 0 );

    That will remove any output of srcset and sizes attributes of images in your theme. The image file as defined in the src attribute will be taken definitely. The disadvantage will be the lack of supporting responsive image sizes in your theme.

    One last question: do you have any suggestions how to force this missing CSS line for your widget’s images:

    sizes="(max-width: 767px) 89vw, (max-width: 1000px) 54vw, (max-width: 1071px) 543px, 580px"

    I’m not very good with CSS and can’t figure it out.
    Thank you,

    Plugin Author Martin Stehle


    You can not alter that attribute with CSS. What do you want to achieve?

    As you know Google isn’t a big fan of slow loading pages, especially they test the speed using slow mobile platform. I’m not even mentioning the bad user experience where you have to wait 10-15 sec for the page to load. I have a lot of media on the page, but when I have 5-10 images on the page at 1k or above resolution… not a lot of people have the patience to wait, plus there is a slide in Google positioning as a result.

    I set your widget to serve at 371px width, but it serves at 768 on my home and archive pages. I guess I can live with that. But my most important Post pages are served at 1024 and 1280 – that is excessively high. My Post pages are usually landing pages. I really appreciate your help and responses, but if I can’t reduce the resolution of images, I would need to look maybe for another solution.

    I wouldn’t want to lose the responsiveness of images either, but I must limit the served size.

    Plugin Author Martin Stehle


    Those are issues for what the plugin is neither the reason nor the solution. There is another approach: read that answer and change the values for width and height to 372 × 209 px.

Viewing 15 replies - 1 through 15 (of 15 total)
  • The topic ‘Images served uncompressed’ is closed to new replies.