WordPress libvips Image Editor: 18x Faster Than Imagick

Image processing is one of those quiet costs nobody puts on the dashboard. I have spent twenty years sizing servers for WordPress and WooCommerce builds, and I can tell you that on any media-heavy site — a magazine archive, a product catalog with thousands of variations, a portfolio with hero crops — the Imagick worker that resizes uploads is usually the loudest process in the room. It is also the one nobody touches, because the alternative is GD, and GD is not a serious alternative for anything sharper than a thumbnail.

So when a Core Trac proposal lands suggesting we replace, or at least complement, that 25-year-old plumbing with libvips, I pay attention. libvips is not new — it has been quietly running image processing for Mastodon, Wikimedia, imgproxy, Rails’ Active Storage, and Node’s sharp library for years. The news is that someone is finally going to ask WordPress Core to ship it.

This is a small announcement with very large second-order effects. Here is what is actually on the table, and what I would do about it on a real production site.

What is actually new

In the Performance Chat summary from June 16, 2026, contributor @nickchomey announced he is opening a Core Trac ticket proposing libvips integration into WordPress. The stated reason is direct: libvips offers significant CPU and memory advantages over Imagick. Weston Ruter acknowledged the proposal and added the realistic caveat — Core support would likely be necessary before hosting providers prioritize adoption, and even then adoption would be gradual.

To put numbers on “significant”, the published libvips benchmarks show the C variant completing a standard load-shrink-sharpen-save test in roughly 0.57 seconds versus 10.53 seconds for PHP’s Imagick on the same hardware. That is an 18-fold speedup. Peak memory in the same test was 94 MB for libvips against about 1,500 MB for ImageMagick — roughly sixteen times less. The benchmark caveat is honest: that particular test is IO-heavy and flatters libvips. The real-world advantage in pure processing scenarios is usually three to five times faster and somewhere between five and ten times lighter on memory. Either way, it is not a margin you argue with.

libvips itself is a demand-driven, horizontally threaded image processing library written in C, licensed LGPL-2.1-or-later, with mature PHP bindings. It handles every format WordPress cares about — JPEG, PNG, WebP, AVIF, HEIC, TIFF, GIF — plus PDF and SVG. It is already in production at Mastodon, MediaWiki, Rails Active Storage, sharp, and imgproxy. This is not a research project.

The same Performance Chat surfaced the other two high-priority items the team wants to land in WordPress 7.1: graduating View Transitions on the frontend from feature plugin to Core, and shipping Enhanced Responsive Images. Both already exist as feature plugins under the Performance Lab umbrella; both need another round of iteration before a Core merge proposal lands. None of that is unrelated to libvips: View Transitions and responsive image variants both multiply the number of image operations a typical request triggers.

For context on what libvips would be replacing or complementing, WordPress Core ships two image editor backends today: WP_Image_Editor_Imagick (PHP’s bindings to ImageMagick) and WP_Image_Editor_GD (PHP’s bindings to GD). The architecture is already pluggable — third-party image editors can register via the wp_image_editors filter. A libvips backend would slot into the same pattern. The proposal is not “rip out Imagick”; it is “add a third, faster option and let hosts and users pick”.

Why it matters for WordPress and WooCommerce people

It matters because image processing is one of the few WordPress costs that scales linearly with content and quadratically with formats. Every time you add a new size in add_image_size(), every time WooCommerce regenerates a product variation gallery, every time someone runs Regenerate Thumbnails after a theme switch — that work is paid for in CPU seconds and RSS memory on the application server. Multiply by AVIF and WebP alongside JPEG, multiply again by responsive srcsets, and the bill is real.

Three concrete consequences if libvips lands in Core, even as an opt-in backend.

One. Hosting economics change. Managed WordPress hosts run Imagick at scale and they feel every memory peak. A backend that needs an order of magnitude less RAM per image operation lets the same machine serve more concurrent uploads, faster regenerations, and more aggressive responsive variant generation. That is a margin every WP Engine, Kinsta, Pressable, Hostinger, and self-hosted ops team will quietly notice on their next billing cycle.

Two. WooCommerce catalogs become tractable again. If you run a Woo store with thousands of products, several variation galleries each, and the new variation image galleries landing in WooCommerce 10.9, the cost of a full thumbnail regeneration today is measured in hours and migraines. With libvips that becomes minutes. The same applies to bulk imports and CSV-driven catalog migrations.

Three. Modern formats stop being a luxury. AVIF and HEIC are expensive to encode in Imagick. They are not in libvips. If Core ships a fast backend, generating AVIF variants alongside WebP and JPEG stops being a “we’ll do that on the CDN” conversation and starts being a default. That is good for Core Web Vitals, and it is good for everyone on a slow mobile connection.

What I would do (or not do) about it

Right now, today, nothing in production. The proposal is a proposal. There is no Core Trac ticket merged, no patch, no timeline. View Transitions and Enhanced Responsive Images are ahead in the queue for WordPress 7.1, and even those are still in feature-plugin iteration. Treat libvips in Core as a 2026-Q4-or-later expectation, not a Q3 plan.

What I would do is start measuring. On your three loudest sites, log the wall-clock time and peak memory of your current image pipeline. wp media regenerate with --dry-run on staging is a fine first measurement. Capture Imagick’s peak RSS during a full regeneration. Save those numbers. When libvips lands as an opt-in backend, you will want a clean before/after to justify the switch to whoever signs off on production changes.

What I would not do is install one of the third-party libvips image editor plugins on a production site this quarter on the strength of this news. Some exist on GitHub. They are perfectly reasonable for experimentation on staging. They are not battle-tested at WordPress.org-distribution scale, and the abstraction will almost certainly change once a Core implementation lands. Wait for the Trac ticket. Read the patch. Then evaluate.

What I would do, if I ran a managed host, is start the procurement conversation about getting libvips and the PHP vips extension into the base image. It is a system dependency, not a Composer package. Hosting providers can be slow on system-level changes, and the worst outcome is Core shipping a libvips backend in 2027 and nobody being able to enable it because php-vips is not installed anywhere.

The honest read of this week’s Performance Chat is that WordPress Core is finally taking image processing seriously as a performance surface, not just a correctness surface. That is overdue, and it is welcome. We will know it is real when the first Trac ticket appears with a patch attached.