Show the actual filesize of the selected image size slug, if known

[kadamwhite]

When a user selects a particular size of image, e.g. "large" in the editor, this PR makes a remote HEAD request to the actual image source_url to get the measured byte size of the remote file rather than trusting media_details.filesize. This still may not be 100% accurate given that the responsive markup might display a smaller image than selected, but it provides the easiest-to-compute upper bound for in-content image sizes.

Still TODO: Handling featured images, handling (and detecting) offloaded videos.

Also switches the per-image size display to kb if it's less than 1mb, and adds thumbnails for easier identification!

[kadamwhite]

Just pushed one more commit to display:none the image JSON details tag, it's still there for debugging but we're getting closer to not needing it.

[kadamwhite]

Marking this for review despite the elements of WIP / unaddressed items, to validate the overall approach.

[goldenapples]

I like how it's coming together!

A couple of thoughts I had:

• Instead of fetching the image in JS to get the image size, it might be more efficient to do that calculation in PHP, store the filesizes as post meta on the attachment, and return it with the REST resource for the attachment.

• I'd like to figure out a way to accurately replicate the logic of responsive images for calculating filesize. I think we'd probably have to run the whole get_intermediate_sizes logic and return the first size that's larger than either the content width or featured image width. Is that feasible to get to in an MVP or should that be a future enhancement?

[kadamwhite]

I'd like to figure out a way to accurately replicate the logic of responsive images for calculating filesize. I think we'd probably have to run the whole get_intermediate_sizes logic and return the first size that's larger than either the content width or featured image width. Is that feasible to get to in an MVP or should that be a future enhancement?

I spent a while going back and forth on this, and I've determined to argue that it's not worth it. I argue it is so much more efficient to directionally trust the image will be displayed at the scale it has been requested, than to be worth replicating the logic and get the value precisely accurate — doing so is difficult, would be entirely template-dependent on some sites, and would be less legible for editors. Even for featured image, I've resolved to allow filtering the slug of the size you are planning to use as a featured image in your templates rather than to do any dynamic computation; doing so added a lot of code without resulting in a significantly different final number.

[goldenapples]

I like the cleanup of the display here too.

[goldenapples]

I spent a while going back and forth on this, and I've determined to argue that it's not worth it. I argue it is so much more efficient to directionally trust the image will be displayed at the scale it has been requested, than to be worth replicating the logic and get the value precisely accurate — doing so is difficult, would be entirely template-dependent on some sites, and would be less legible for editors.

This makes sense. This is a tool for editors and not intended to match exactly the media total on the front end. The figures we get here should be proportional to the total served on the front end at any given viewport, so site owners can just set the max weight accordingly.