The only concern I want to raise is the fact that users won't be able to download an image by right clicking on it.

• because they will be background-image
• and because even advanced users who know how to open the browser developer tools will only be able to save that big image grouping them all.

That's why CSS sprites are usually used for icons and images on the page that only decorate the page.

If this is a matter, we don't have to put all 17 images into 1. We can have:

• one image for the globe logo (if we care that people can right and click?)
• one image for the search icon + the bookshelves (we don't care if people can right and click!)
• one image for the 12 projects (if we care that people can right and click?)
• one image for the WMF logo (if we care that people can right and click?)

This will already drop the 17 requests down to 4 requests.

The question is to decide, for each image, whether saving this image is a "feature" we want to support - in despite of load performance.

First I'd like to address the issue of right-clicking. All of our logos are open-source CC licence, and can be downloaded
from Wikipedia, at any resolution, and even vector SVG https://en.wikipedia.org/wiki/File:Wikipedia-logo-v2-en.svg
So I think we can safely remove the 'save image' feature when someone right-clicks.

I think the real distinction we can make is whether an image is considered 'content' or not.
I'm willing to entertain the idea that the wikipedia wordmark and globe logo could be considered content.
However, looking around the web, yahoo, amazon, bing, even http://alistapart.com/ (semantic web champions)
use a background image for their logos. Google seems to be the only one who uses an img tag for their logo.

(Our globe logo currently is a background image.)

I think the bookshelves might have to be a separate background image, because they repeat,
and repeating the sprite wouldn't work if the width of the sprite is wider than the bookshelf image. We might be
able to group the search icon and bookshelves, if the bookshelves are wider than the search icon, which I think they are.

I think the sister projects can be a sprite as well, since they are just icons and they have the text beside them.
The mediawiki foundation logo at the very bottom can also be grouped in with these logos, as long as we
provide fallback screeen-reader text beside it too.

Now, I would like to mention something interesting :P

CSS Background images load last. Currently, because our globe logo is a background image, it loads last.
It loads after those sister project logos which nobody sees until they scroll down.
I think this load order is important, because it can make the page feel slower than it really is.

So I propose we do this:

• Keep the wordmark as an <img> so it loads first.
• Change the globe logo to an <img> so it loads after the wordmark.
• Sprite the bookshelves + search icon.
• Sprite the sister project logos + wikimedia logo.
• add screen-reader text to the wikimedia logo.

This amounts to the same number of requests, 4, as @JGirault suggested, just in a slightly different grouping and for a slightly different reason.

Change 267289 had a related patch set uploaded (by Jdrewniak):
Replacing some images with CSS sprites on wikipedia.org portal.

https://gerrit.wikimedia.org/r/267289

I like the proposal, @Jdrewniak!

Change 267289 merged by jenkins-bot:
Replacing some images with CSS sprites on wikipedia.org portal.

https://gerrit.wikimedia.org/r/267289