Theme Directory: listing thumbnails download at full 1200x900 because w=post-thumbnail is not a numeric Photon width

[softglaze]

Theme listing pages request every thumbnail through Photon like this:

https://i0.wp.com/themes.svn.wordpress.org/<slug>/<version>/screenshot.png?w=post-thumbnail&strip=all

post-thumbnail is a WordPress image size name. Photon expects a number in w. It appears to discard the non-numeric value and serve the image at its full size instead.

Evidence that the parameter is discarded

For three themes the response is byte identical whether you pass w=post-thumbnail, pass no w at all, or explicitly ask for the source width. Passing a real number changes the response as expected.

Theme	w=post-thumbnail	no w param	w=1200	w=351
warqa/1.1.0	216,214	216,214	216,214	27,436
adwa/1.0.2	101,512	101,512	101,512	33,856
vora/1.1.3	296,654	296,654	296,654	38,030

Byte counts. The first three columns match exactly in every row.

Effect on a listing page

Measured on the grid at /themes/browse/new/:

• All 12 thumbnails decode at naturalWidth 1200 by naturalHeight 900
• The cards render them at 351 CSS pixels
• There is no srcset, no sizes and no loading="lazy", so all 12 full size images are requested immediately on load

Total thumbnail payload for the page: 2,237,766 bytes, about 2.13 MB.

At w=351 the three themes sampled above averaged roughly 33 KB each, which would put a comparable page nearer 0.4 MB. That figure is an estimate from three samples, not a full page re-measure.

Suggested fix

Pass a numeric width in place of the size name. Adding srcset and sizes would let higher density displays get a sharper image without every visitor paying for 1200 pixels, and loading="lazy" would stop the whole grid being requested at once, but the numeric width alone accounts for most of the difference.

Environment

Browser:  Chrome 151.0.0.0
OS:       Windows 11 Pro N (26200)
Edge:     Singapore Photon edge (x-nc "sin")
Date:     17 August 2026

How this was found

While testing #8315. It is a separate issue: it concerns payload size rather than images failing to render, and it is not offered as an explanation for that ticket.