About page 7.1: Optimize images served from CDN

[peterwilsoncc]

The images served from s.w.org for the WordPress 7.1 about page are transferring 1.52MB compared to 125 kB for the WordPress 7.0 about page.

Even on a high speed domestic connection, this is causing a noticeable flash as the images are loaded.

I think these images can be optimized to require significantly less data:

• the four header images on each of the about sub pages
• the feature images on the main about page.

[iamchitti]

I had a look for anything on the core side that could handle this and couldn't find any image optimization step - core only holds the URLs, and the files themselves were removed from src/wp-admin/images/ in [63182]. So the fix will need to happen on the s.w.org side.

On the cause: the 7.1 images are lossless WebP, where the 7.0 ones were lossy. Dimensions are unchanged (features 900x900, headers 2000x600), so it's purely the encoding mode - the RIFF chunks read VP8L in 7.1 vs VP8 in 7.0. The 7.1 files also carry an embedded ICC profile, which suggests they went up straight from a design-tool export rather than through a compression pass.

Once replacements are in place, the core-side change is just a ?ver= bump — four URLs in wp-admin/about.php and ten in wp-admin/css/about.css. Happy to put that patch afterwards.

[markoserb]

Hi there,

lossy optimization simply doesn't work. We have gradient elements that don't do well when optimized. It looks like low res photo once 'lossy' or even 'losssless' optimization is done. No matter if it's from a source that is png, jpg, or done from webp itself — the optimization is bad.

I also think 7.0 images don't look too great due optimization. They are better because solid colors are used instead of gradients, but still their optimization is seen on bigger screens easily. I don't think this is good.

Nevertheless. Can you help me understand what difference these images (sizes) make in contrast to the ones that are optimized in load time on the 'worst' case-scenarios? Or is it something else? I am really naive here, but if I can learn well, we could be better prepared the next time. Maybe we don't use gradients in release's identity, solely for this reason, etc. But to repeat, the images don't do well if optimized. See attachment in my next comment.

[markoserb]

Testing. Potential solution is:
Instead of x2 the size (current images), we can export them x1 size/no optimization. All files will be 40-50% less the size. And they look well for all screens until 16". But everything from 16" and above will be not clear enough.

[markoserb]

Another quirky thing here, sorry for lot's of messages. Is it possible that a flash happens not because image size but something else? I am a designer so I don't understand. But I did just test (on a slower internet) and I do see a flash here, but I don't see it on several sites where image is even bigger. Same internet connection. Is it something else that may be adding to this, or it is simply just the image size?

[wildworks]

The container width for the About page is 1000px, and the maximum rendering size for the four feature images on the About page should be 468px. Would reducing the image size itself from 900px to 468px be effective? Are there any issues with Retina displays?

[wildworks]

The size at which the feature images are rendered in the browser

[joedolson]

One thing that would make a significant difference would be to move the header images back to local files, rather than fetching them from the CDN.

[markoserb]

I did some hacks to optimize things from 4.4 to 2.7mb (total images). I am still not happy about the outcome. On the first look they seem ok, but on certain places the issues are seen, like text Mono over the bottom image in feature 01 can be seen as blurry a bit. And so on. However, if we 100% need them to be lighter, this does that. But we need to figure out this for next time of why this loads slow, as it shouldn't load so slow even with current image size. Attaching.

[wildworks]

At the very least, the file sizes of these four feature images are clearly larger than previous ones.

version	URL	size
7.1	​https://s.w.org/images/core/7.1/about-feature-01.webp	476.1 KB
7.1	​https://s.w.org/images/core/7.1/about-feature-02.webp	281.0 KB
7.1	​https://s.w.org/images/core/7.1/about-feature-03.webp	135.5 KB
7.1	​https://s.w.org/images/core/7.1/about-feature-04.webp	286.9 KB
7.0	​https://s.w.org/images/core/7.0/about-feature-01.webp	27.6 KB
7.0	​https://s.w.org/images/core/7.0/about-feature-02.webp	26.7 KB
7.0	​https://s.w.org/images/core/7.0/about-feature-03.webp	37.4 KB
7.0	​https://s.w.org/images/core/7.0/about-feature-04.webp	28.6 KB
6.9	​https://s.w.org/images/core/6.9/01-notes.webp	22.4 KB
6.9	​https://s.w.org/images/core/6.9/02-visual-drag-drop.webp	118.1 KB
6.9	​https://s.w.org/images/core/6.9/03-command-palette-everywhere.webp	13.6 KB
6.9	​https://s.w.org/images/core/6.9/04-fit-text.webp	69.4 KB
6.8	​https://s.w.org/images/core/6.8/feature-01.webp	10.8 KB
6.8	​https://s.w.org/images/core/6.8/feature-02.png	5.2 KB
6.8	​https://s.w.org/images/core/6.8/feature-03.webp	17.7 KB
6.8	​https://s.w.org/images/core/6.8/feature-04.png	4.0 KB

Regarding the header images, we might be able to write it inline with CSS, similar to how it was done in 6.9.

​https://github.com/WordPress/wordpress-develop/blob/6.9/src/wp-admin/css/about.css#L582

[markoserb]

Images are heavier because the content of the images is spread gradient. Automatically is heavier than a solid color background image. Then on features. If an image has 1-2 elements it is simply less pixel dense and is less in size. And our images in previous releases, as well as in this one aren't great quality for retina, nor bigger screens. We should change that moving forward. I have ideas that I can share for future.

Your call on above, either optimized either ones that are now live.

[wildworks]

Images are heavier because the content of the images is spread gradient.

I'm referring to the feature images, not the header images. The backgrounds of these images do not appear to be gradients.

​https://s.w.org/images/core/7.1/about-feature-01.webp
​https://s.w.org/images/core/7.1/about-feature-02.webp
​https://s.w.org/images/core/7.1/about-feature-03.webp
​https://s.w.org/images/core/7.1/about-feature-04.webp

[markoserb]

Yes, because they weren't optimized. As you can see in my latest zip I sent the features are: 28, 43, 147, and 149 kb. That fully aligns to what was done before and what you were comparing. While headers cannot achieve that amount of kb if we want to have them gradients.

But, their quality (depending on how many elements are on the feature image, is it just text, is it image + text + colors, or color contrast is low) deteriorates with optimization. Each graphical symbol is differently optimized (text/image/solids-shapes). I also want to say that what we did with that optimization in the past isn't good. If you look those images you can notice weird pixel cuts.

And as I mentioned: I am fine with whatever you all want to go with. There is a zip above with optimized images, but in an ideal world we do fix this, as these (nor past releases) are good on retina or bigger screens.

Hope this helps explain things in greater detail.

Replaces the about page images with optimized versions.

[!CAUTION]
For testing purposes, I've deployed the SVGs to my server. These will be deleted so do not commit until these have been deployed on to the WordPress.org CDN

Trac ticket: Core-65854

## Use of AI Tools

Nope.

[peterwilsoncc]

I've created ​PR#13025 using the images in 7-1-about-page-images-optimized.zip​.

• Header backgrounds converted to SVGs and passed through the default settings on ​SVGOMG
• About feature images exported from ​Figma designs at 2x pngs and optimized via ​Squoosh: WebP, Effort 6, Quality 80.
• DO NOT MERGE THE PULL REQUEST until images are hosted on s.w.org as I've pushed them to my own site for the purposes of testing.

When viewing the webp images at full size you will notice some degradation but the images will only be viewed at 50% of their size in the dashboard. Even on a retina screen when viewing at this size, I did not notice much, if any, degradation in quality.

Image Name	Previous size	New size	Optimizer
about-feature-01.webp	488 kB	26 kB	squoosh
about-feature-02.webp	288 kB	61 kB	squoosh
about-feature-03.webp	139 kB	11 kB	squoosh
about-feature-04.webp	294 kB	15 kB	squoosh
about-header-credits-rtl	308 kB	1.2 kB	webp -> SVG, SVGO
about-header-credits	375 kB	1.2 kB	webp -> SVG, SVGO
about-header-default-rtl	308 kB	1.6 kB	webp -> SVG, SVGO
about-header-default	308 kB	1.57 kB	webp -> SVG, SVGO
about-header-freedoms-rtl	308 kB	1.1 kB	webp -> SVG, SVGO
about-header-freedoms	386 kB	1.1 kB	webp -> SVG, SVGO
about-header-get-involved-rtl	308 kB	1.0 kB	webp -> SVG, SVGO
about-header-get-involved	162 kB	1.0 kB	webp -> SVG, SVGO
about-header-privacy-rtl	358 Kb	1.0 kB	webp -> SVG, SVGO
about-header-privacy	356 kB	1.0 kB	webp -> SVG, SVGO
about-release-badge	3.65 kB	2.38 kB	webp -> SVG, SVGO

@peterwilsoncc Since the majority of the images are downloaded from the s.w.org server rather than the local WordPress installation, it's better to use an optimized version so they load faster.

I think it would be better to land the optimized version.

[peterwilsoncc]

I've updated the ​linked pull request:

• The SVG header images are now included in the WP distribution
• I've added loading=lazy attributes to the feature images two through four (admin bar, cropping, inline notes).
• optimizations, etc unchanged from the details provided above.

The four about-feature images are updated.

​https://wordpress.slack.com/archives/C0BBK6LTBB8/p1786717289706949?thread_ts=1786712200.317349&cid=C0BBK6LTBB8

As far as I can tell from replacing the images locally, lazy loading is working and the delivered images are also compressed.

​https://github.com/user-attachments/assets/09ef1c7d-8fcd-4ed3-a36d-6715eb721315

@peterwilsoncc, could you apply the suggested changes to your repository, as I'm unable to push to it?

@t-hamano I've applied your changes in ​https://github.com/WordPress/wordpress-develop/pull/13025/commits/969ee2ace6f18a964cf75c2bdc0112f6712952be. I noticed in your suggestions you removed the lazy loading attribute, was that intentional?

I've applied your changes in ​https://github.com/WordPress/wordpress-develop/commit/969ee2ace6f18a964cf75c2bdc0112f6712952be. I noticed in your suggestions you removed the lazy loading attribute, was that intentional?

Oh, that was not intentional and was simply caused by a copy-paste.

[peterwilsoncc]

​PR#13025 is in it's final form pending a final approval from @wildworks. The images have been updated on the CDN, see this ​Slack thread.

[wildworks]

In 63304:

Help/About: Optimize the About page images.

The header backgrounds now ship with WordPress as SVG files instead of being fetched from the CDN, the feature images have been recompressed, and those below the fold are lazy loaded.

Follow-up to [63182].
Props iamchitti, joedolson, markoserb, mukesh27, peterwilsoncc, wildworks.
Fixes #65854.

[wildworks]

Reopening #65854 to request backporting [63304] to 7.1 branch

[wildworks]

@sabernhardt Thank you for reopening this! I sometimes forget about it.

[joedolson]

Approved for backport to 7.1.

[joedolson]

In 63305:

Help/About: Optimize the About page images.

The header backgrounds now ship with WordPress as SVG files instead of being fetched from the CDN, the feature images have been recompressed, and those below the fold are lazy loaded.

Follow-up to [63182].

Reviewed by joedolson.
Merges [63304] to the 7.1 branch.

Props iamchitti, joedolson, markoserb, mukesh27, peterwilsoncc, wildworks.
Fixes #65854.