“Since image uploading is very rare compared to image serving, the extra effort to compress and store images should be worth it.” “However resources to serve an image will be lowered,” Silverstein said. Six weeks ago, in response to one complaint that the “resources for conversion would be tremendous,” Google-sponsored core committer Adam Silverstein confirmed that resources for generating the images on upload would “increase dramatically.” On the other hand, if the WEBP file sizes are actually larger than the JPEGs, that would probably mean that better tools are needed, and this patch is premature. There is no point of clogging the web servers storage with all these useless files.
If JPEGs are indeed needed, these can be generated on-the-fly as needed. IMHO a better approach would be to just make all image sub-sizes WEBP. Why would there be twice as many image files taking up a lot of extra space when half of them will never ever be used anywhere? Like and others I think this approach is perhaps lacking. Last week, WordPress lead developer Andrew Ozz weighed in on the ticket with new objections: Several contributors reported issues with the feature and suggested that it should start by being opt-in, an idea that was summarily dismissed before the main work was committed. While the Google-sponsored contributors driving the project have made some revisions after an initial round of significant critical feedback, other contributors have continued to voice concerns that they said were not being considered.
The proposal to generate WebP images by default for new JPEG image uploads has been controversial from the beginning.
#Webp converter for media server configuration error pdf#
This includes smaller related items like the shim for non-supporting browsers and adding PDF support, which are being handled in separate tickets. Last week Performance team contributors were working on refining their follow-up patches for the multi-mime/WebP feature, after the main work for it was merged into core for 6.1 at the end of July.
0 kommentar(er)
