I'm also thinking that more testing/consideration is needed on whether to create large sub-sizes for PNGs at all. So this ticket is to (temporarily?) turn off replacing the "full" size image with a scaled down version, and use the originally uploaded image as before. However it seems that in some cases PHP (GD and ImageMagick) do not handle resizing/scaling of very large PNG images well. There is a filter to control what the "too big" threshold is. This ensures that original images are never used when they are "too big" for web use. Inside WordPress the largest size is also set as the "full" size.
This was done to support more devices with larger screens and/or high-density displays. Generally the change was to add up to three larger image sub-sizes. The changes in WP 5.3 expand and enhance WordPress' ability to serve images better. With that already baked in WordPress original images never get served. Images are mostly already served in a way that doesn't hurt the reader, for example with responsive images.
Overall it is more expensive that "disk storage". We run a large managed hosting platform for publishers with 60+ editors working daily with press and stock photo's and saw our average CPU load increase by 9 percent.Ĭould you provide some more info about this, if possible? In particular, was that increase seen only when post-processing uploaded images or was it an overall increase after updating to WP 5.3?īandwidth is cheap, CPU and inodes are not.īandwidth may be "cheap" in some cases, but may also be "quite expensive". Yep, I agree, opened this ticket for that. The handling of PNG images needs more checking.
0 kommentar(er)
