[wp-trac] [WordPress Trac] #57459: Reexamine the usefulness of file size meta for images

[WordPress Trac]

#57459: Reexamine the usefulness of file size meta for images
-------------------------+-----------------------------
 Reporter:  azaozz       |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  Media        |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+-----------------------------

Comment (by azaozz):

 Replying to [comment:2 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 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.007ms. If the meta was not loaded, retrieving it
 was considerably slower. The chance that image file size could be missing
 in the meta made it pretty much impractical.

 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57459#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform