![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 4 weeks ago
Last modified 4 weeks ago
#65473 new enhancement
Feature: Add libvips-based Image Editor to WP Core
| Reported by: | nickchomey | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Awaiting Review |
| Component: | Media | Version: | trunk |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: | performance, sustainability |
Description
WP 7.1 is taking a big step forward with regards to Media processing with the client-side media processing effort. I see this as an opportunity make significant improvements to server-side media processing at the same time.
Problem: WordPress Media Processing requires excessive server resources
It is common for users to report issues and failures with uploading images (e.g. #23127, #22869, #48522, #55289), and these largely come down to running out of RAM.
@kirasong confirmed to me recently in slack that:
image processing has been the highest user of RAM for any individual operation in WordPress for as long as I've been working on the project
Reducing the memory requirements of image processing would improve reliability on resource-constrained hosting environments and allow available memory to be used for serving requests rather than generating image subsizes.
Finally, datacenter CO2 emissions are becoming an increasingly pressing concern. So, WordPress - representing over 40% of the web - needs to endeavour to reduce its server footprint as much as possible.
Proposal: Add WP Core support for using libvips to process images on the server
Published libvips benchmarks show memory usage and processing times that are often 10–20x lower than ImageMagick and GD. My own testing of libvips for WordPress media uploads has shown improvements in the 5x range for CPU (measuring memory usage seems tricky for Imagick and VIPS, so I don't have figures on hand).
Using libvips in WP Core would result in faster and more reliable uploads, fewer user errors and support/trac tickets, lower memory requirements, reduced hosting costs, lower CO2 emissions, and more.
We should introduce a new WP_Image_Editor_Vips implementation in wp/wp-includes/class-wp-image-editor-vips.php, which would use php-vips to talk to libvips via the php FFI extension. This would be the preferred Image Editor, falling back gracefully to Imagick when libvips is unavailable on the server.
There is already a very capable plugin that adds such support, but it is largely unknown. Moreover, even if it were to be made a Canonical Plugin, most hosts do not (and won't) support libvips until WP itself supports and educates about it. The core functionality from this plugin could be reviewed, tested and added to WP Core.
Benchmark
See attached SPX profile flamegraphs for uploading the attached large image (on a powerful desktop - 8.6s vs 1.5s. Conversely, the client-side media wasm-vips seems to take around 6 seconds to do the same - and you have to wait on the page while that happens.
Responses to potential objections:
- "WP 7.1 will have so server-side media processing is no longer a concern"
This is a fantastic and highly welcome innovation. But it only works on Chromium browsers and in the Gutenberg editor - not the Media Upload tool, nor via plugins from the frontend. So, plenty of media uploads will still fall through to the backend.
This effort is complementary to the client-side media effort (which also uses libvips via wasm-vips!).
Also, some sites will surely want to disable the client-side processing, for any number of valid reasons (e.g. battery life, not having to wait for processing to happen before leaving the page)
- "Very few hosts have libvips installed. So this wouldn't meet the WP Philosophy threshold of core features need to benefit 80% of users"
There's plenty of historical (and current!) precedent for introducing important features that do not meet this threshold.
- The client side media project estimated that only a maximum 40% of users would benefit from it.
- AVIF support was added despite only 30% of hosts supporting itat the time.
- And surely many other features and APIs have low initial adoption.
Hosts' support for libvips is likely to be lower than these precedents, but this is is an opportunity for outreach and education amongst hosts and users - supporting vips is as simple as something like sudo apt install libvips42 php8.x-ffi.
And, again, this would be a progressive enhancement - if your host doesn't support it, WP falls back to Imagick or GD.
But there is no good reason why this couldn't eventually benefit 100% of WordPress users.
- "There would be a maintenance burden associated with it"
WordPress already maintains multiple WP_Image_Editor implementations. A Vips implementation would reuse the existing editor abstraction and would likely share much of its behavior with existing editors. The maintenance surface area appears relatively small relative to the potential performance benefits.
Additionally, there's only been a couple of commits per year to the imagick editor.
I and others will surely be willing to help with maintaining this editor.
- "There are potential security concerns with FFI"
php-vips previously worked via a .so extension, but that was deprecated in favour of the FFI approach.
Some hosts disable FFI, but that is a deployment concern rather than a WordPress compatibility concern. For hosts with security concerns, tools such as Snuffleupagus can be used to selectively permit FFI access for libvips while maintaining broader restrictions on FFI usage.
Again, hosts that choose not to enable FFI would continue using Imagick or GD without any change in behavior.
Attachments (3)
Change History (11)
#2
follow-up:
↓ 4
@
4 weeks ago
WordPress is already falling back on GD in case ImageMagick is not found. I see very little wrong with making php-vips the primary option, with ImageMagick becoming the fallback.
It's actually about time as I've been using vips for a while already.
#3
in reply to: ↑ 1
@
4 weeks ago
Replying to swissspidy:
Hosts' support for libvips is likely to be lower than these precedents
I'd recommend adding some detection for it to the update API so that we have some usage stats.
If hosts first need to install libvips, there's no reason why they wouldn't just install that libvips plugin for their customers.
I'm sure many hosts install plugins for users, but I am certain that many site owners absolutely don't want their host meddling with their plugins. This is something that should be built into core and that users don't have to think or even know about. This would also result in better maintenance of the feature.
#4
in reply to: ↑ 2
@
4 weeks ago
Replying to aldavigdis:
WordPress is already falling back on GD in case ImageMagick is not found. I see very little wrong with making
php-vipsthe primary option, with ImageMagick becoming the fallback.
It's actually about time as I've been using vips for a while already.
In what way are you using vips? Via the above-mentioned or another plugin? Some custom code of your own?
#5
@
4 weeks ago
@notglossy fyi, I've proposed merging your plugin into WP Core. Is this something you'd be interested in helping with?
This ticket was mentioned in Slack in #hosting by nickchomey. View the logs.
4 weeks ago
#7
in reply to: ↑ 1
@
4 weeks ago
Replying to swissspidy:
Hosts' support for libvips is likely to be lower than these precedents
I'd recommend adding some detection for it to the update API so that we have some usage stats.
@swissspidy we may already be able to detect this with the presence of the libvips php package - if not I agree it would be good to add; I have inquired with systems.
#8
@
4 weeks ago
To clarify, php-vips just installs with composer and uses the FFI php extension to call the libvips binary directly. We'd probably bundle/vendor it.
I assume that the update api detects the FFI php extension, but would be surprised if it looks for libvips/all binaries in $PATH. It wouldn't be all that hard to add support for though.
I'd recommend adding some detection for it to the update API so that we have some usage stats.
If hosts first need to install libvips, there's no reason why they wouldn't just install that libvips plugin for their customers.