If you run a small business in New Zealand and have ever tried to put your own photograph on your own website, you will recognise the moment. You take the picture on your phone, find it again on the laptop, drag it into the website, and after a long pause the screen says there was an error. It does not say why. You crop it smaller, try again, get the same result, and eventually email the file to whoever built the site.
That failure has a dull technical cause, and it has just been fixed. On 19 August, WordPress released version 7.1, code-named Mary Lou after the jazz pianist and composer Mary Lou Williams. Most of the coverage went to the new styling controls and the two new blocks. Further down the release announcement sits a change to the way the software handles pictures, and for a business that does not employ a web team it is the most practically useful thing WordPress has shipped in years.
Here is what used to happen. When you uploaded a photo, the file travelled to your web server and the server did the heavy lifting. It shrank the image, rotated it if your phone had recorded the picture sideways, converted the format, and generated the six or eight smaller copies a modern website needs so it can send a phone a phone-sized picture rather than something built for a billboard. All of that ran in PHP, using whichever image library your host happened to have installed. On the cheap shared hosting where most New Zealand small business sites live, PHP is allotted a modest amount of memory, and a photograph straight off a recent phone can exhaust it. The upload then dies, and WordPress tells you almost nothing about why.
WordPress 7.1 moves that work off the server and into the browser sitting in front of you. Compression, resizing, rotation and thumbnail generation now run on your own computer, using a WebAssembly build of libvips, a fast image library usually found inside large publishing platforms. The finished pictures, thumbnails and all, are then sent to the server, which simply stores them. The core team’s developer note on the change puts the consequence in six words. “No more PHP memory limit failures.”
The second consequence matters more to your customers than to you. libvips compresses better than the older libraries most hosts run, and the same note puts the improvement at roughly 15 per cent smaller JPEGs. Fifteen per cent sounds modest until you consider what it is fifteen per cent of. The Web Almanac, HTTP Archive’s annual survey of millions of real websites, found the median home page loaded on a phone weighed 2,559 kilobytes, of which 911 kilobytes were images. Pictures are the largest single category of what a website makes people download, ahead of JavaScript and well ahead of fonts. Trimming the biggest item on that list, automatically, for every image uploaded from now on, is the kind of improvement that never appears in a sales pitch and shows up in the numbers anyway.
That has a commercial edge here. Online spending in New Zealand in the first half of 2026 ran 12 per cent ahead of the same period last year, according to NZ Post’s Business IQ, and a growing share of it happens on a phone, on a mobile connection, often while someone is standing in a shop comparing prices. Every extra second of loading is paid for by the retailer.
Two smaller changes will save more tempers than the compression will. Photos taken on an iPhone are stored in a format called HEIC, which most web servers have never been able to read. WordPress can now decode those files in the browser and convert them to a standard web image before upload, keeping the original alongside. The developer note describes the result in four words. “iPhone photos just work.” The other change concerns bad connections. Each thumbnail is now uploaded as its own request rather than one large batch, failed requests retry automatically, and an upload pauses if you drop offline and resumes when you return. Anyone who has tried to load a gallery of photos from a rural connection or a motel wifi will understand why that matters.
There is a real caveat, and I would rather state it plainly than let anyone find it out later. The full browser-based pipeline needs a capability only Chromium browsers currently expose, which means Chrome, Edge and Brave. The developer note is explicit about what happens elsewhere. “Browsers that don’t support the required features automatically fall back to server-side processing with no user-facing change.” Nothing breaks in Safari or Firefox, then, but the benefit is not universal. It depends on the browser the person uploading happens to use. Statcounter puts Chrome at about 56 per cent of New Zealand browsing in July 2026 and Safari at about 25 per cent, so a fair number of Mac owners will see exactly what they saw before. If your photos are being uploaded from a Mac in Safari and they keep failing, switching browser for that one task is now a legitimate fix.
The wider point is more interesting than the feature. For twenty years the direction of travel has been to move work onto the server and away from the visitor, because servers were reliable and the devices people carried were not. That assumption has quietly expired. The phone in your pocket is a more capable computer than the shared hosting most New Zealand small businesses rent, and WordPress has started handing work back to it. Expect more of this. It weakens the old argument that the answer to a slow website is a bigger server. Often the real answer is that the site was asking the server to do something it should never have been asked to do.
None of which means you should update on a Friday afternoon. Version 7.1 also completes a long-running change that puts the post editor inside a frame of its own for every theme, and the field guide warns that plugins reaching across that boundary need reviewing. Block stylesheets are now loaded conditionally, and the bundled jQuery UI has moved. If your site runs an older custom theme, a page builder, or plugins nobody has audited since it was built, test on a staging copy first. Ask whoever maintains your site to do that, and to tell you what they found.
Do keep current, though. A week before 7.1 arrived, WordPress issued version 7.0.4 to close a flaw that let a logged-in user run code on the server through a malicious file upload, on sites using the Imagick and Ghostscript image tools. It was reported responsibly and patched quickly, and it only protects the sites that apply the update. The irony is not lost on me that the flaw sat in image handling, on the server, in the month WordPress began moving image handling somewhere else.
WordPress runs about 40 per cent of all websites, according to W3Techs, and a large share of New Zealand’s small business sites. A change that makes photographs upload without failing, and arrive smaller when they do, will not make anyone’s newsletter. It will make thousands of ordinary websites faster and much less annoying to run, which over a year is worth more.
Roger McSaveney is General Manager of Forge Creative, an Auckland web design and development agency.
Have you given up trying to load a photo onto your own website? Tell us what happened in the comments below.
This article was written by AI, briefed to report the facts, hopefully without some of the bias people bring to the job 🙂
Leave a Reply