Make WordPress Core

Opened 16 months ago

Last modified 15 months ago

#57459 new enhancement

Reexamine the usefulness of file size meta for images

Reported by: azaozz's profile azaozz Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Media Keywords:
Focuses: Cc:

Description

Storing of the file size for images was added in #49412 without it being used in core and with pretty marginal use case(s) expectations:

Storing file size means, developers will not have to resort to doing filesize function calls, that can be time consuming on assets on offloaded to services like Amazon’s S3.

#49412 also mentions some serious drawbacks:

  • Image filesize meta is missing for all previously uploaded images.
  • It is unreliable as seemingly many hosting companies optimize images directly on the disc, without running WP, hence the cached file size becomes outdated/wrong soon after images are uploaded.
  • Many sites replace JPEGs with WebPs on the fly, making the stored file size unusable.

In that terms the cached image file size seems too unreliable to even fulfill the expected use in plugins. Furthermore not being useful in core, and the additional overhead when uploading images seems to make it a poor addition.

Change History (3)

#1 @azaozz
16 months ago

Thinking that moving most of the functionality that was added in #49412 to a (canonical) plugin would be best. Perhaps wp_filesize() can remain (not be deprecated) as it may be useful in other cases. But the "caching" of image file size in image meta would be better as a plugin, and will need a good documentation of how unreliable it is.

#2 in reply to: ↑ description ; follow-up: @kirasong
15 months ago

@azaozz Thank you for the ticket! I've been a fan of starting to store this so that WordPress can make better/faster decisions about what to do with images. But of course also open to change!

I agree that WordPress should use it in core -- if it's not currently being used to load the locations where image sizes are being used, it'd be good to do that.

Was it being used by alternate mime / WebP support before it was removed? That's one of the areas I can see it being particularly useful.

It's possible I'm missing some of this from the previous ticket, and if so, apologies!

A few questions:

Replying to azaozz:
<snip>

#49412 also mentions some serious drawbacks:

  • Image filesize meta is missing for all previously uploaded images.

This is true! But will gradually be less of the case as new images have the information.

  • It is unreliable as seemingly many hosting companies optimize images directly on the disc, without running WP, hence the cached file size becomes outdated/wrong soon after images are uploaded.

Oh! I didn't know that any hosts changed stored files on disk.
Do you know who does this, and with what methods?

  • Many sites replace JPEGs with WebPs on the fly, making the stored file size unusable.

Yes, some sites have CDNs that do type replacement. I thought that was part of the idea of the filter, though -- to make it so some of these services have additional information, or can store it.

I think this is still useful for WordPress efforts to improve what is served, too.

Do you know what that percentage of sites that use other services/plugins looks like? This might help for any use cases for doing that sort of thing in core, too.

In that terms the cached image file size seems too unreliable to even fulfill the expected use in plugins.

Is this feedback you've received from plugin authors?

Furthermore not being useful in core, and the additional overhead when uploading images seems to make it a poor addition.

How much is the additional overhead for images? Is that causing issues for users?

#3 in reply to: ↑ 2 @azaozz
15 months ago

Replying to mikeschroder:

I've been a fan of starting to store this so that WordPress can make better/faster decisions about what to do with images.

Yep, I liked the idea at first too. There's been about a year since image file size data was added and it's still not used in core. Not sure how many plugins use it, hard to search for them. My guess is probably only a few given the shortcomings.

I agree that WordPress should use it in core -- if it's not currently being used to load the locations where image sizes are being used, it'd be good to do that.

How do you see that implemented? As far as I see it might be useful only once when deciding if a different format image may be a better choice. I.e. when JPEGs are uploaded and if core gets functionality to replace them with WebPs, it may want to compare whether the WebP replacements are actually better and with smaller file size. Even then the implementation would probably be better to get a "fresh" file size as the cached size may be incorrect.

Do you see any other use cases in core? Lets discuss them, make test plugins, reexamine, etc. :)

It is unreliable as seemingly many hosting companies optimize images directly on the disc, without running WP, hence the cached file size becomes outdated/wrong soon after images are uploaded.

Oh! I didn't know that any hosts changed stored files on disk.
Do you know who does this, and with what methods?

Think this was pretty common some years ago. To save bandwidth and space some hosting companies would use cli "image squishers" like jpegoptim from cron. Not sure how common is this now but I've seen it on couple of the sites I had access to. Btw the savings were pretty impressive in some cases, over 20%. Wondering if core should be looking at something like that, perhaps (canonical) plugin?

In that terms the cached image file size seems too unreliable to even fulfill the expected use in plugins.

Is this feedback you've received from plugin authors?

No. I tried to make a plugin that uses it and didn't like the results. Ended up with a function that gets the file size (with wp_filesize()) when the meta value is missing. Then tested the "savings" per image (all sub-sizes). Getting sizes with wp_filesize() when the image meta was already available was slower by 0.07ms. If the meta was not loaded, retrieving it was considerably slower. The chance that image file size could be missing made it pretty much impractical to retrieve the image meta.

Add to that the chance that the cached value in the meta may be wrong/outdated, and it seems not a good idea to use it.

How much is the additional overhead for images?

It seems quite small, but overhead is overhead. And post-processing images is a "problem area" for timeouts and running out of memory.

Last edited 15 months ago by azaozz (previous) (diff)
Note: See TracTickets for help on using tickets.