Black Friday sale! Get up to 25% off GP Premium! Learn more ➝

[Resolved] Correct image thumbnail size not used on mobile and iPad: larger image resized

Home Forums Support [Resolved] Correct image thumbnail size not used on mobile and iPad: larger image resized

Home Forums Support Correct image thumbnail size not used on mobile and iPad: larger image resized

Viewing 15 posts - 1 through 15 (of 18 total)
  • Author
  • #1112842


    I did some speed tests using gtmetrix and (mobile) and noticed that a larger image size is being pulled and scaled down to 300×225 for the thumbnail on the home page on mobile.

    300xAuto is specified in the settings for featured images on archive pages.

    I verified this using Chrome on my Android mobile and on Safari on an iPad Mini 5.
    Size 768×576 is being pulled on both and then resized.
    Webpagetest even pulls the largest size, 1024 pixel wide when set to a Galaxy S7

    On desktop Chrome and Firefox, the correct image size (300×225) is being pulled.

    Originally I had this CSS active, but that always used the largest image size and resized it, which is a pity.

    (min-width: 769px) {
    .post-image-aligned-left .post-image img {
    max-width: 300px;

    I like this function, but I have removed this for the time being because of performance consideration.

    So in essence: The pulled thumbnail size only seems to be the correct 300 pixels wide on desktop. On mobile it is sized like on the desktop but a larger image is being used.
    This can be quite a performance hog.

    Could you please advise, what is going wrong?

    Many thanks for taking the time.

    Lead Developer
    Lead Developer

    Hi there,

    We use the standard WP function to display featured images, which use srcset to serve different sized images at different screen sizes. Your srcset seems to be set up correctly – I’m not seeing any obvious issues.

    Are we sure GTMetrix etc.. take srcset into account when running their tests?


    Hi Tom,

    thanks for the reply.

    It is not GtMetrix I am concerned about. I am not focused on these services, they just alerted me that there may be a problem and a performance issue. I tested it with real devices.

    As I have written in my original post, it is my own mobile phone (Galaxy J7, Chrome and Firefox) and my iPad Mini 5 (safari) that are being served these larger images and then resized to the small thumbnail size while on desktop the correct size (300px) is being served.

    I assume if you try it with a phone you’ll notice something similar.

    I would be grateful if someone could look into this. (I have attached a link to the site.)

    I absolutely understand that you guys can likely only get to this after Christmas.

    Many thanks and merry Christmas.

    PS: I have removed the above-mentioned CSS and set it in the customizer to 300 px to test this.

    Lead Developer
    Lead Developer

    Merry Christmas!

    How are you telling which size is being used on your mobile device? I just loaded up your site on my phone and all seemed to load super fast.


    Merry Christmas Tom.

    On both Chrome and Firefox on an Android mobile, when I attempt to download the image (long press and then select download image), it shows which size it is going to download. (Btw, that size matches exactly the size you see being mentioned by these speedtest sites, i.e., GTMetrix, Webpagetest, and Google Pagespeed.)

    On the iPad, I send the image to Evernote and then inspect it on a PC.

    Update: I just found a method to directly see what has been loaded into the cache. In Android Firefox (URL field) I typed about:cache
    This provides a link to the disk cache. I cleared the cache, then downloaded the site’s home page, then listed the cache content: it is indeed the larger images mentioned above I find there.

    Yes, the site is fast with three thumbnails.

    But it is a test site to get the theme, plugins, and performance right.

    When I have 10 or 20 images on a blog home page and archive pages, on a mobile, the difference between 300×225 and 768×576 (or even 1024..) can become significant, considering that the image is only displayed at 300×225.
    (Otherwise we wouldn’t even need these smaller thumbnail sizes, just resizing on the device would do it.)

    All the best.

    Customer Support

    Hi there,

    have you considered the device resolution? Is it a x2/retina screen?
    If so the browser may request x2 pixels hence it chooses the larger image size.


    Hi David,
    the Galaxy J7 doesn’t have a Retina screen. The iPad Mini 5 has.

    [Also, all performance test sites report the same result and suggest serving a smaller size, so I get consistency no matter from where I try that.
    For example, GtMetrix, Android mobile for each of the images on the homepage:
    XXX.jpg is resized in HTML or CSS from 768×576 to 300×225. Serving a scaled image could save 55.2KiB (84% reduction).]

    The result is always the same for mobile. Image is downloaded at a larger size and resized (scaled down) to 300×225.
    Perhaps you guys could try it (e.g., with your phones)? What result do you get?
    What result should be expected when the thumbnail size is set to 300xAuto in GeneratePress?
    (I don’t see where I can specify a separate size for mobile in GP.)

    Currently the page size (with only 3 thumbnails for mobile is 311 kb, while for desktop it is 90 kB. On desktop the 300×225 thumbnails are used.

    Thanks and all the best.

    Lead Developer
    Lead Developer

    Hi there,

    I don’t know enough about srcsrt to give a perfect answer, unfortunately. For example, I imagine that downloading the image on your phone will download the full image, but srcset itself should make it so that smaller image is served on the browser side of things.

    It may be worth asking over on something like – I would be interested in seeing what someone with srcset experience says about this.


    Tom, I cleared the cache on my phone then went to the website’s home page. (Just to be clear: I don’t download any files before looking at the cache.)

    I looked at the browser cache, as described above and it has the larger images in the cache. I have even described how to get to that cache. On a mobile it has a large image (and resizes it to thumb size), on a PC it has the small thumb. You could do that too to check that.
    This is not related to actually downloading the image at all, just going to the web page.

    I have given all the input I can. Have you actually taken a look at what is going on?

    Honestly, I feel disappointed now, having spent all that time giving input. I made it clear that I am of course fine with you guys checking this after Christmas. It is not about giving some fast guesses.

    This is exactly the kind of issue people need support with with a theme.

    Furthermore, this can have a large impact on the performance on mobile.

    While I am willing to learn something, I am not a WordPress expert and I don’t know how a certain function is being implemented by a theme.

    (PS: small thumbnails are being served on mobile by the theme I am trying to replace with GP.)

    Customer Support

    GP doesn’t do anything to interfere with how the WP srcset function operates.
    The markup your site is generating looks correct to me. It is specifying the various srcs and the size attributes.

    My understanding of SRCSET browser side: On DOM load the browser checks the device viewport/resolution and image size attributes. It then requests the src that best fits the requirements.

    There are some caveats:

    1. The <meta name="viewport" content="width=device-width"> has not been set so the physical device resolution / device zoom has not been considered. This is not the case on your site as the viewport meta is specified.

    2. There is CSS or JS interfering with the ‘size’ – again not a case on your site.

    3. Device resolution (DPI) – the pixel density of the device affects the image size requested. The Samsung J7 is listed as a 2 XHDPI device – so in theory it would request an x2 image:

    Other Tests:

    Google Pagespeed Insight requests 768×576 images – it does not flag them as an issue or a requirement to rescale. I assume it defaults to a x2 DPI device for testing.

    Chrome Dev Tools Lighthouse Audit – same as Google Pagespeed Insight.

    Pingdom requests 300×225 image.

    GT Metrix – Chrome Desktop requests 768×576 and complains of scaling.
    GT Metrix – Firefox Desktop requets 300×225 image. No complaints of scaling.

    Other reading suggests that Chrome interprets srcset different to FF. Whereas the latter will most likely request all various sizes if needed, Chrome opts for a ‘larger’ image size to cover all bases ( which in an odd way sort of makes sense…. )

    My overall conclusion is that WP is outputting the correct markup, GP does not interfere with that and browsers across the various device configurations seem to do as they please with FF being more reliable for benchmarking.


    Hello David,
    thanks a lot for taking the time to take a look.

    Let me add the following
    If you set GTMetrix to Chrome Mobile (you have to choose Vancouver), it will serve the large images as well and resize.
    Dito Webpagetest (e.g., Chrome on Oneplus 5)

    The same happens when I use the real Firefox for mobile (and I suspect Chrome as well) (like on my phone). It serves the large images and resizes them.
    If you have Firefox on mobile, you can type “cache:about” and see what happens on your real mobile device.

    My current theme serves small thumbnails on both mobile and desktop, so resizing is not necessary. I don’t know how they implemented this function.
    Perhaps they are not using srcset to accomplish this, but using srcset is not really a requirement for me. As a theme user I worry about what happens to size and speed.

    What worries me:
    Using GP, with 10 images (or more) this would lead to a lot more image data being served to mobile than desktop for all category pages, tag pages and the home page.

    Google has switched most sites to mobile first indexing a while ago and mobile speed is a ranking factor.
    Speed is why I was considering GP in the first place.

    I was going to replace my current theme with GP because my current theme has other performance issues and incompatibilities with plugins.

    I’ll see how I go.


    Customer Support

    Are you able to share a link to your ‘current’ theme so we can take a look at what the difference is?


    Hi David,

    I have added a link->blog homepage using my current theme to the first post. As it looks to me, it is always the same thumbnail size that is being used (desktop, iPad, mobile).
    If I see it correctly, srcset is not being used, which would be OK for me.
    In fact, (while not a must) I would also prefer that theme’s layout for iPad portrait, because more space is available for showing posts and the featured image can be kept small and still look good (because it is left aligned and surrounded by text).

    Lead Developer
    Lead Developer

    Let’s see if disabling srcset fixes the issue:

    add_filter( 'wp_calculate_image_srcset', '__return_false' );

    Looking at your HTML, the images should be 300px by default, so the other sizes shouldn’t even be necessary.

    Let me know if that makes a difference at all 🙂


    Hello Tom,
    thank you for the code.

    Indeed, when I add this, only one image size is being served on all devices.
    Unfortunately this seems to be always the largest size, i.e., the size with which the image was uploaded, so the page size gets larger on all devices.

    And it affects both the blog home page/archive pages and individual blog posts in the same way.

    What could work well:
    One fixed (small) thumbnail size for the home page/archive pages.
    Srcset for individual posts / pages.

    Ideally for me, there would be a distinction between thumbnails (preview images) and normal images.

    I don’t know whether GP can work this way.
    But I appreciate that you have taken a look.

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