WordPress v.5.3 introduced three new large resized image sizes to generate more suitable srcset attributes for large images. The new image sizes proportionally resize the original images to 1536*, 2048* and 2560* maximum width or height and greatly increase the storage use by creating three new large WordPress image sizes per uploaded image.
WordPress v. 5.3 improved large image support for uploading non-optimized, high-resolution pictures taken from your smartphone or other high-quality cameras. Combined with larger default WordPress image sizes, pictures always look their best.
– Block Editor Improvements, WordPress v. 5.3 ChangeLog, November 12, 2019.
The new ‘1536×1536‘ and ‘2048×2048‘ proportionally resized WordPress image sizes are meant to enhance the way WordPress displays images at the front-end on larger, high-density devices. The two intermediate sizes are initiated in /wp-includes/media.php and designed as 2X retina versions for default ‘medium_large‘ [768*0] and ‘large‘ [1024*1024] image sizes.
function _wp_add_additional_image_sizes() {
// 2x medium_large size
add_image_size( '1536x1536', 1536, 1536 );
// 2x large size
add_image_size( '2048x2048', 2048, 2048 );
}The front-end ‘big_image’ 2560*2560px maximum
An additional 2560*2560px ‘big_image’ image size was also introduced as a front-end maximum image size for the originally uploaded large images. This eliminates the need for common add_image_size(‘full’, 2560, 2560, false); call for many WordPress themes.
It is important to know, that starting WordPress v.5.3 the default WordPress image tag output will not include a link to the original full-size image for images larger than 5 megapixel even when a ‘Full Size’ Image Size is selected in the right-side image settings.
A src link to the original full-size uncompressed image is replaced with the ‘big_image’ 2560*2560 intermediate image.
Until now, it was possible to use the originally uploaded images on the front-end even when they were not “web ready”. In WordPress v.5.3 when a large image is uploaded it is stored in the upload’s directory but is not used on the website.
– Updates to Image Processing in WordPress 5.3, WordPress.org, October 11, 2019.
A new scaled down image is created and used as the largest available size. This scaled down image is usually much more suitable for web use, the file size is up to ten times smaller than the original.
Large image study case example
Below is the 10 megapixel [4608*2176] image that I took at Yavirnyk-Gorgan in Carpathian Mountains of Ukraine.
The default WordPress v.5.3 themes embeds the ‘Full Size’ image with the following code:
<img src="https://wpo+/wp-content/uploads/Example-scaled.jpg"
srcset="
https://wpo+/wp-content/uploads/Example-scaled.jpg 2560w,
https://wpo+/wp-content/uploads/Example-300x142.jpg 300w,
https://wpo+/wp-content/uploads/Example-768x363.jpg 768w,
https://wpo+/wp-content/uploads/Example-1024x484.jpg 1024w,
https://wpo+/wp-content/uploads/Example-1536x725.jpg 1536w,
https://wpo+/wp-content/uploads/Example-2048x967.jpg 2048w,
sizes="(max-width: 2560px) 100vw, 2560px"
alt="Large Image Example">The initial src attribute link to the original uncompressed full-size image Example.jpg [4608*2176] is replaced with the compressed Example-scaled.jpg image size [2560*1209]. Such an approach might affect the image-indexing and image-ranking for many photo-bloggers and other media professionals WordPress websites.
Will Google still index the original WordPress images?
The Google Images is the #2 most popular Internet Search Service. It ranks the website images by various factors, with image-quality and maximum image-dimension being two most important.
The logic is simple: the larger the website’s image, the bigger chances the image is the original source of the alike resized images around the web. It is important therefore to ‘feed’ search crawlers with the best image size available. The above is true for Yandex, Bing, TinEye and similar image search services as well.
The largest images are displayed first in the Google ‘Reverse Image Search‘ results:
With the introduction of the Google Lighthouse Stack Packs, it is clear that Google’s AI algorithms are capable to recognize the WordPress’s ‘finger-prints’ by its code output. Image filename’s postfixes [like ‘Example_scaled.jpg’] are one of such recognition patterns.
The Google crawlers, no doubt, are capable to obtain the original ‘Example.jpg’ image filename from ‘Example_scaled.jpg’ image size filename, but are they available enough to walk the ‘extra mile’?
The WPO+ Best Practices
1. Process WordPress image sizes with 100% quality
Starting from WordPress v.4.5 all WordPress image sizes are resized or cropped with the default 82% compression quality by a server-side utilities such as ImageMagick. Unlike third-party lossless compression services, like ShortPixel, the default server-side compression often creates images with noticeable compression artifacts.
WordPress image-processing uses “lossy” compression, meaning that when resized the image file size gets smaller and some of the image data is lost.
– Updates to Image Processing in WordPress 5.3, Andrew Ozz, October 23, 2019.
Luckily the image-processing quality can be easily switched to 100% with the following functions.php filter code:
add_filter('jpeg_quality', function($arg){return 100;});2. Manually resize/crop compression-free image sizes
To guaranty the best user experience we use the WordPress plugin like WP SmartCrop or YoImages to manually resize/crop the images around the best focal point.
3. Post-optimize the images
The resized/cropped high-quality intermediate images are optimized with the ShortPixel’s best-class lossless compression.
Since the compressed ‘2560*2560’ front-end image sizes do not replace the original compression-free images, the original images are used to generate new intermediate images. The wp_get_original_image_path( int $attachment_id ) function can be used to retrieve the path of an uploaded original compression-free image file since WordPress v. 5.3.
The way this works in WordPress seems not good at all.
Example:
I upload images that are 1920×1080 (“the original”), the largest image size I need, well-prepared in Photoshop. In Settings I have defined “Large” to be 1080 (which will then be 1080×608).
WordPress then also creates a “smaller big image” that is 1536×864, with the intention that the very big image (1920×1080) should not be served to a client if a smaller one (e.g. 1536×864) is sufficient.
A good idea but it does not work.
The 1920×1080 images that I upload are around 210 kB in size (it varies very much, so take it as an example).
The “smaller” 1536×864 images created by WP are ALWAYS bigger in size, typically 40% bigger, e.g. ~300kB compared to the original of 210 kB.
So by trying to be “clever” and creating the 1536×864 images WordPress is actually WASTING bandwidth and making the pages heavier, since the file size is much bigger than the original.
But not only that, the “large” size, defined as 1080 (1080×608) created by WordPress are somewhat smaller than the original, but not very much (about 20% smaller in kB). Questionable if that is worth-while.
It seems to me that WordPress is really, really poor in handling image sizes.
True. WordPress relies on various server image libraries and PHP image compression settings here.
That is why the resized image is often heavier than a bigger compressed original.
It important therefore to ‘feed’ search crawlers with the best image size available.