Reduce Excessive Bandwidth usage on plugin and theme pages

Hi @j09,

As a solution, you can upload the images by reducing the size using some image tools or website.

Also, you can use the https://developer.www.ads-software.com/reference/functions/add_image_size/ to cut the image and reduce the size and load.

Thanks

I would not advice messing with codes if you are not a developer.
The problem you are having can easily be solved using a plugin called imsanity

This free plugin does everything you are asking for and better still it automates the tasks.

Here is a snippet of the plugin description: Imsanity automatically resizes huge image uploads down to a size that is
more reasonable for display in browser, yet still more than large enough for typical website use.
The plugin is configurable with a max width, height and quality. When a contributor uploads an
image that is larger than the configured size, Imsanity will automatically scale it down to the
configured size and replace the original image.

The good news is you can use it on your already uploaded images too.
Check out the plugin at the wordpress repository

@ketuchetan
@lawrenceagles

Thank you both for your replies, but that is not what I mean.

The images I’m referring to are fetched from w.org They are not my images.

I have no control over those images. the images need to be fixed by the WordPress team.

I understand what you mean.

The images are uploaded by the theme or plugin authors. They choose the sizes. They choose the format (we allow either PNG or JPG, both work).

For the specific case you’re talking about (theme screenshots), we recommend 1200 pixel wide images. While you are correct that the display space for the image maxs out at 387 pixels wide, you also need to consider Hi-DPI displays.

I have a Hi-DPI screen. So do a lot of Mac users with retina displays, as do mobile users which those super hi density mobile screens. The pixel space as described by the browser is therefore not the same as the actual pixels on the screen. My 15 inch wide screen has a native resolution of 3840×2160. Which is obviously ludicrously dense. So a 387 pixel wide image, in native resolution, is about the actual size of a postage stamp. Not very useful.

So browsers define the resolution of the “page” differently than the native resolution. And that 387 wide space gets scaled up. But, as you know, scaling up images sucks. Makes them look blurry and awful. But browsers are smart, so it will scale up the image using a larger image and then display that as close to native resolution as it can. So now, that 1200 wide image, which on my screen is about 5 inches across, looks pretty good in the space provided for it.

Size is indeed a factor, and we do recommend optimizing images for size. Sometimes JPG is better, if you have a very photographic screenshot. But sometimes PNG is better, because you have large areas of generated graphics. Depends on the screenshot, and more importantly, the author of the theme/plugin has the choice and can do what they think best there. We don’t force a method on them.

It sounds like the images are large in size, for the benefit of those with big screens, at the expense of bandwidth and time for all those with smaller screens.

Something to consider dreaming of (and it might then begin to happen);

Responsive systems that do for PCs (and TVs) with large screens compared to older/normal screen PCs, what responsive systems do for tablets and smartphones.
We just add a 4th setting for responsive themed sites, for the step up to the bigger pixel count screens.

Just a thought, but it would keep a lot more people happy, and possibly save bandwidth.
At the same time, the 4th step would allow websites (that use WordPress) to really improve their appearance on huge screens, without making the site impractical for the viewers on older equipment.

We’ve considered responsive images for that area, for plugins and themes. I’m still considering it. It’s not off the table at this point.

Hi Samuel Wood (Otto) (@otto42),

It’s good news to hear this is not off the table yet.
I am not sure how close to the edge, or within elbow range it is,
but sometimes what seems outlandish or overkill today, becomes outstanding and disruptive the next.

On our website, we get visitors that view on mobile devices at about 300 pixels wide, through to tablets, and PCS, and what are probably large screen TVs at over 4000 pixels wide.
That is a very large range (more than magnitude 10).

The importances of image resolution, and use of space, and page height considerations are vastly different between the extremes, and vary through the device screen sizes.
For a site to give a good experience for users on each device type, the above factors must be at least suitable, and should be optimized for best experience.
Presently there are compromises.

Users’ behavior and duration on a site is closely related to their experience on arriving (and continuing to stay) on it.
The demographic of the visitor is (loosely) correlated with the device they are viewing the site with.
For some sites, it is almost imperative that these visitors be catered for in order to maximize conversion.

It is doubtful that nobody is interested in overcoming this impediment.
But what is needed to overcome it, is a group of people that want to work on it.
It would be a great way for theme developers to show their versatility.
The WordPress team could enable a convention for handling the extra breakpoint (or what ever it is called), so all the main core systems and other plugins can continue to work as they do presently.
I am not suggesting that the WordPress Core Team become burdened with yet another task, but do encourage the enabling of this expansion of capability, so those that are interested of keen can start working with each other (see some more thoughts for future below).

If it ends up going nowhere, then that will be because of lack of interest. But if it does eventuate in to something exciting, then it’s probably good that it didn’t go to, or start at, somewhere else.

A spinoff from this, is that it might be possible to allow the user to set as many “breakpoints” as they wish, and what those points are (they just need to have more space to store files particularly when caching).

Another spinoff thought
If “break points” can be treated arbitrarily, based on device detection, then
…
in the future (maybe keep this on the table),
the same system will be able to detect a 3d viewer, or holographic device, and display the website content in best appearance for such device.

One thing for sure though is,
The WordPress site is a major opportunity for show casing the latest advances in wordpress’s capabilities (especially while maintaining backwards compatibility for those that do not yet have the latest great stuff).

This may not (presently) be the main course, nor the salt and pepper,
but sometimes some fun can be had by playing Ketchup.

Thank you for your input. WordPress itself already has full support for responsive images, and so that is not in question in any way. This is a question purely about our systems and how we treat them in combination with the SVN.

But again, thank you for your input.