Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2020-09-22 10:05:54

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

srcset/sizes head scratcher

This is doing my head in. I’m using smd_thumbnail to offer responsive images. I’ve only defined two profiles so far – Landscape and Portrait – but I think I need to make a few more to handle various situations. Trouble is I can’t figure out what I need to do to make it work well.

The situation is that I have a landscape ‘hero’ article image that, at portrait tablet and below is 100% wide. Any greater viewport widths display the image inline at about 35% with floated text around it. Pretty standard.

So I defined my srcset/sizes thusly:

<txp:images limit="1">
   <img src="<txp:image_url />" 
      srcset="<txp:smd_thumbnail type="Landscape" display="url" /> 300w, <txp:image_url /> 800w" 
      sizes="(max-width: 466px) 100vw, 35vw"
      alt="<txp:image_info />" class="articlethumbfront" />
</txp:images>

The srcset defines both the landscape thumbnail width at 300px and the “full size” (an image that has been resized prior to upload) at 800px. I could do with higher density versions but don’t have access to the original images at the moment.

The problem (umm, I think) is that the browser is serving the Landscape image on mobile and tablet, but because it’s only 300px wide, it looks terrible scaled up to almost twice that to meet the 100% viewport width requirement. As soon as we snap above that, the 800px image downloads and it looks crisp, but we probably don’t need all that resolution and the Landscape version would do because we’re only using 35% of the display width, with the body capped at about 976px anyway.

This is kind of ‘backwards’ logic to serve the higher res image on mobile/tablet and low res on desktop. PageSpeed is saying I need to optimize things in the image department. I don’t really want to serve the full size here because tablet is the only size that’s really affected. Once you go down to mobile widths, the Landscape image at 300px isn’t too bad. Maybe I should make that size 320 or even 400px instead, because 300 is a bit tiny.

Do I need to introduce an intermediate ‘Landscape’ size and serve that between, say, 400px and 768px? Still doesn’t solve the issue that I want to serve a lower res version at higher viewports but maybe I can flip the sizes attribute around to fix that? I’m cheating right now and using this:

sizes="(max-width: 466px) 35vw, 100vw"

Which pretty much means it’s serving the full size image everywhere (does it? Argh!)

Jason Grigsby talks about performance budgets but that’s a bit over my head. Maybe I need to figure that out somehow so I can choose the optimum image widths for various breakpoints.

I’m clearly missing something obvious here so any pointers gratefully appreciated.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#2 2020-09-22 11:47:31

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,578
Website

Re: srcset/sizes head scratcher

Yeah, getting sizes right makes my head hurt too … but haven’t you got your directive round the wrong way?

You want full-width at mobile sizes and 35vw at larger viewports, so I would have thought it should be:

sizes="(max-width: 466px) 100vw, 35vw"

given that it stops once the first media query criteria has been met.

(Alternatively, use your code with min-width)

Two more things:

  • 466px is probably a portrait mobile size but not a portrait tablet size. That’s more likely to be 768px or perhaps something else if you want to get various galaxy device portrait sizes working with it.
  • Given that most phones and tablets are hidpi, they’re likely to grab the larger image anyway.

The fuzziness may be because your hidpi device is showing a regular pixel size a bit blurry, or because you’ve been telling it that at small widths, that image is only shown at 35vw, i.e. 0.35 x 466 = 163px (or smaller) and maybe the 300px image is being used. Your css is then showing it at 100% width causing the upsizing.

You might, in this case, be able to get away with just specifying the image at 1x and 2x sizes without media queries. That way you’d get the 1xdpi at large widths and the 2xdpi at narrow widths on hidpi devices.

An aside: you’ll find that upsized images that look fairly crappy in photoshop or similar will look much better when shown downsized on a hidpi device, often better than a regular (1x) dpi image. You can often get away with really crap jpg quality – 40 or 50% – if those images are only ever going to be shown in hidpi mode.


TXP Builders – finely-crafted code, design and txp

Offline

#3 2020-09-22 11:49:54

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,058
Website

Re: srcset/sizes head scratcher

I am not sure I follow your code fully, but in this case in most (all ?) cases I would expect your 800px image would be needed – small screens because most if not all have a high density screen (2x is becoming a rarity), tablets for the same reasons. Larger screens ? 35vw of my iMac screen at full-width is 672px; it is a retina screen, (2x). On my MBA, full screen it is 504px; again, retina screen.

(mind you my browser window is smaller: ~1350px in both cases).


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#4 2020-09-22 12:10:22

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: srcset/sizes head scratcher

jakob wrote #326009:

Yeah, getting sizes right makes my head hurt too …

Glad it’s not just me :)

but haven’t you got your directive round the wrong way?

If I put it that way round, then I get the blurry stuff. So I’ve just switched the widths in the sizes attribute for now so it at least renders the full-width version and leaves the code relatively unscathed so I can tinker with it in the inspector to debug it. It’s a live site and I’m not using dev themes at the mo, and leaving stuff commented out is pain.

466px is probably a portrait mobile size but not a portrait tablet size.

Yeah, maybe I need an intermediate step/size/query. But given the full size image itself is only 800px wide and my media query for tablet is around 768px, I might as well just serve the fullsize pic for anything other than mobile. That’s what I’m trying to achieve.

The pics aren’t that big anyway, but PageSpeed et al are complaining about mobile page weight (probably because there are about 60 images on the front page) so I thought I’d best do it properly. Hence I dipped my toe into the srcset pool again… and promptly fell in.

Given that most phones and tablets are hidpi, they’re likely to grab the larger image anyway.

Maybe. It looks okay on my (non-hidpi) phone but I can’t tell at that resolution which one it’s downloaded. It might have grabbed the big one for all I know. It’d be nice to find out for sure: relying on Device Mode in the inspector is all well and good, but it doesn’t equate to the behaviour of the real thing in many cases.

The fuzziness may be… because you’ve been telling it that at small widths, that image is only shown at 35vw, i.e. 0.35 x 466 = 163px (or smaller) and maybe the 300px image is being used. Your css is then showing it at 100% width causing the upsizing.

That’s entirely possible. As it stands:

  • sizes="(max-width: 466px) 35vw, 100vw" shows clear images on all devices/desktops; but
  • sizes="(max-width: 466px) 100vw, 35vw" (which is – I think – what I want) shows fuzzy images on mobile/tablet and clear images on desktop. That’s what is doing my head in.

My goal, unless anyone can see faulty logic:

  1. Render “Landscape” (small size) smd_thumbnail jpgs on mobile devices under about 466px or thereabouts, at full width of viewport.
  2. Render “Full size” article image on tablet devices under about 768px or thereabouts at full width of viewport.
  3. Render “Full size” article image (or maybe the smaller smd_thumbnail size is good enough resolution?) on anything greater than 768px or thereabouts, but at 35vw with text wrapped around the image.

Is that possible?


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#5 2020-09-22 12:18:18

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: srcset/sizes head scratcher

phiw13 wrote #326010:

in most (all ?) cases I would expect your 800px image would be needed

I’m fine with doing this. It’s a lot simpler! I’m just trying to track down if there’s any mileage in using smaller images to appease the whining Webmaster tools report, and PageSpeed when they complain there are too many images and they need to be served in more suitable sizes.

I think I need to introduce another size anyway because on one particular page is a sea of thumbnails – like, 48 of them – and they never display wider than about 160px. That requires a new ‘images’ form though, so I’ll need to split the code and use it, instead of being lazy and using the same form for all images.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#6 2020-09-22 12:51:03

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,578
Website

Re: srcset/sizes head scratcher

Not sure why the max-width: / min-width isn’t working as expected*. What does sizes="(min-width: 466px) 35vw, 100vw" – e.g. if wider than 465px the image shows at 35vw, otherwise full-width – give you? Any better?

PageSpeed et al are complaining about mobile page weight … probably because there are about 60 images on the front page

How about lazyload if they don’t all appear at once?

It might have grabbed the big one for all I know. It’d be nice to find out for sure

The network tab in the inspector should tell you which image src it’s using. The obvious way to test it is to prep two different images with some kind of visual identifier (a coloured square or img-size in the corner) for a test case and upload the thumbnails individually. Then you can see which one is loading.

*you’ve got caching switched off in the inspector? It may also depend on whether you start large and resize from large to small or reload anew from the mobile size.


TXP Builders – finely-crafted code, design and txp

Offline

#7 2020-09-22 12:56:37

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,058
Website

Re: srcset/sizes head scratcher

One trick to test which image is being requested: create a dummy image at your estimated Large size, give it a green background; create a second image at your smaller thumb size (300px here I think), give it an orange background – or any color you deem usable, as long as all your various thumbs have really distinct colours. Upload them manually (replace… in smd_thumbnail) now you can hopefully see at a glance which of the various images is being used. And if you test by resizing the browser window, reload each time, browsers won’t necessarily fetch a new one otherwise.

Also, consider adding the width and height attribute to your image tag, example here from the TXP website; works great.

oh and yeah, don’t try to make a shortcode for all possible use cases; in a few weeks you’ll go crazy trying to figure out the madness of if/else logic.


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#8 2020-09-22 13:25:56

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: srcset/sizes head scratcher

jakob wrote #326014:

What does sizes="(min-width: 466px) 35vw, 100vw" … give you?

The same, sadly. But, curiously:

sizes="(min-width: 466px) 100vw, 35vw"

Seems to work. It only loads the low-res image on mobile, and the hi-res one on anything greater than 466px, even though I’m telling it (incorrectly) that anything higher than (?) 466px is displayed at 35vw. That media query only kicks in at 768px. But if I alter the rule to:

sizes="(min-width: 768px) 100vw, 35vw"

Then I’m back to blurr-o-vision on anything up to 768px. *scratches head* My brain hurts.

How about lazyload if they don’t all appear at once?

Excellent idea! I’ll do that, thank you.

The network tab in the inspector should tell you which image src it’s using.

Yes. On desktop. Not on my phone, which doesn’t have an inspector. I’m just curious to know which version it’s actually using in the native Android environment.

phiw13 wrote #326016:

One trick to test which image is being requested: create a dummy image at your estimated Large size, give it a green background; create a second image at your smaller thumb size, give it an orange background

Yes, good trick. Or use placeholder.com/ I guess. If it wasn’t for the fact the guy and his customers would notice if I started mucking around with his images, I’d do this.

I should be doing these changes on a staging server really, but it’s a faff because he changes stuff (content and templates) almost daily so resyncing is a pain. And dev/live won’t help me here, since if I muck around with images they affect both live and dev themes. Just gotta tread carefully as I progressively enhance the site while it’s live!

Also, consider adding the width and height attribute to your image tag

Will do.

oh and yeah, don’t try to make a shortcode for all possible use cases

Sage advice :)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#9 2020-09-22 13:52:01

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,578
Website

Re: srcset/sizes head scratcher

Bloke wrote #326021:

Yes, good trick. Or use placeholder.com/ I guess. If it wasn’t for the fact the guy and his customers would notice if I started mucking around with his images, I’d do this.

One possible way. Add an image of your own to test with on the live site but hide it with a class from general view online so that no-one’s the wiser while you’re testing.

Then use cascadea (safari only) or sprinkles (mac only) or one of the usercss add-ons for firefox or chrome to set that class to be visible as a local css override so you can experiment from your own machine.


TXP Builders – finely-crafted code, design and txp

Offline

#10 2020-09-22 14:06:46

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: srcset/sizes head scratcher

jakob wrote #326023:

sprinkles

Oooh I like that.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#11 2020-09-22 14:12:54

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,578
Website

Re: srcset/sizes head scratcher

Bloke wrote #326024:

Oooh I like that.

Thought you might :-) I think you could probably use the dev tools to do local overrides too (e.g. https://www.afasterweb.com/2018/04/19/using-local-overrides-in-devtools/ and I think firefox/safari might do it too) at least for as long as you have one session going.


TXP Builders – finely-crafted code, design and txp

Offline

#12 2020-09-22 16:35:20

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

Re: srcset/sizes head scratcher

I find it easier to min-width the media query as it’s easier to get your head around. For example with the below you are saying ‘at screen sizes over 466 pixels use an image that would sit comfortably in a maximum area of 800 CSS pixels, otherwise, at screen sizes under 466 CSS pixels, let the browser decide which of my two stated images (300w or 800w) is best to use based on the measured screen width and screen density.

sizes="(min-width: 466px) 800px, 100vw"

It’s important to remember though that 800px and 800w are not the same. The 800px simply tells the browser that the maximum theoretical (CSS measured) container area is going to be 800 CSS pixels, not accounting for screen density. However, the 800w image is chosen based on the browsers calculations including screen density.

TLDR; I’d provide a range of images from 600w, 800w, 1200w and 1600w and let the browser decide what is the best image to use.

As others have stated, there is not much point having a 300w image since small screen devices tend to have high screen densities anyway – I doubt it would ever get used apart from maybe on some desktops just after the breakpoint kicks in.

Offline

Board footer

Powered by FluxBB