Smush core images
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
| Issue tags: | Performance |
Running Google Page Speed or YSlow on Drupal sites recommends using a compressed version of files in /misc. It's only small bytes of difference, but the compressed product is visually identical. Using these smaller versions will save a lot of messages for people when they're trying to optimize their sites and won't want to be bothered with messages about 20-30 bytes here and there on images they didn't create.
In #511114: Use smaller feed.png image, we decided Yahoo's Smush.it service has the best compression algorithm, so these attached images were processed through that service alone.
Byte savings summary:
- menu-collapsed-rtl.png 22 bytes 16.92%
- menu-leaf.png 57 bytes 29.38%
- arrow-desc.png 1 byte 0.84%
- draggable.png 87 bytes 24.93%
- druplicon.png 58 bytes 1.42%
- forum-closed.png 5 bytes 0.45%
- forum-hot-new.png 4 bytes 0.30%
- forum-new.png 6 bytes 0.53%
- grippie.png 54 bytes 33.33%
- tree-bottom.png 40 bytes 4.10%
- tree.png 40 bytes 4.09%
- watchdog-error.png 19 bytes 2.38%
- watchdog-ok.png 2.74 KB 87.22%
- watchdog-warning.png 19 bytes 5.60%
- powered-black-135x42.png 19 bytes 0.67%
- powered-black-80x15.png 12 bytes 0.82%
- powered-black-88x31.png 19 bytes 0.90%
- powered-blue-135x42.png 18 bytes 0.59%
- powered-blue-80x15.png 17 bytes 1.68%
- powered-blue-88x31.png 16 bytes 0.76%
- powered-gray-135x42.png 19 bytes 0.70%
- powered-gray-80x15.png 17 bytes 2.24%
- powered-gray-88x31.png 19 bytes 0.92%
- marker.png 149 bytes 22.85%
- mask.png 19 bytes 0.94%
- wheel.png 19 bytes 0.16%
I intentionally left the ui directory alone because I assume editing those images would make it slightly harder to sync with updates from jquery ui official releases.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| menu-collapsed-rtl.png | 108 bytes | Ignored | None | None |
| menu-leaf.png | 137 bytes | Ignored | None | None |
| arrow-desc.png | 118 bytes | Ignored | None | None |
| draggable.png | 262 bytes | Ignored | None | None |
| druplicon.png | 3.92 KB | Ignored | None | None |
| forum-closed.png | 1.07 KB | Ignored | None | None |
| forum-hot-new.png | 1.29 KB | Ignored | None | None |
| forum-new.png | 1.11 KB | Ignored | None | None |
| grippie.png | 108 bytes | Ignored | None | None |
| tree-bottom.png | 936 bytes | Ignored | None | None |
| tree.png | 939 bytes | Ignored | None | None |
| watchdog-error.png | 780 bytes | Ignored | None | None |
| watchdog-ok.png | 411 bytes | Ignored | None | None |
| watchdog-warning.png | 320 bytes | Ignored | None | None |
| powered-black-135x42.png | 2.73 KB | Ignored | None | None |
| powered-black-80x15.png | 1.42 KB | Ignored | None | None |
| powered-black-88x31.png | 2.06 KB | Ignored | None | None |
| powered-blue-135x42.png | 2.94 KB | Ignored | None | None |
| powered-blue-80x15.png | 994 bytes | Ignored | None | None |
| powered-blue-88x31.png | 2.05 KB | Ignored | None | None |
| powered-gray-135x42.png | 2.64 KB | Ignored | None | None |
| powered-gray-80x15.png | 741 bytes | Ignored | None | None |
| powered-gray-88x31.png | 2 KB | Ignored | None | None |
| marker.png | 503 bytes | Ignored | None | None |
| mask.png | 1.95 KB | Ignored | None | None |
| wheel.png | 11.44 KB | Ignored | None | None |
#1
Of course as soon as I submitted that I discovered ImageOptim which uses a combination of OptiPNG, PNGCrush, AdvPNG, and PNGOUT to maximize the shrink. I'm running it all over again because it found even more savings over Smush.it.
#2
After some research, Smush.it claims to use PNGCrush for optimizing. Yahoo's Exceptional Performance group also recommended using pngout, optipng, and pngrewrite to find lossless savings. Google recommends OptiPNG or PNGOUT. ImageOptim has them all except pngrewrite, but has AdvPNG instead.
Only the following images were better through Smush.it: druplicon.png, mask.png, watchdog-ok.png, so I'm attaching those again to make it easier to discuss a group. Otherwise, these attachments are all new.
ImageOptim even found some savings over #511114: Use smaller feed.png image for feed.png, so here's the big list. Note ImageOptim has an Again button to do it all over again for additional savings. The algorithms can improve on themselves it seems.
Fun fact: ImageOptim on one run found 21.6% savings on the second and third screenshots taken and saved with Skitch.
First run
Second run
Third run
#3
The sum of the changes takes the size of all misc PNGs from 152k to 144k.
#5
I have already created an issue regarding this #543888: use compressed images in drupal core but this seems to have better description so let me mark that as duplicate.
#6
Tagging. If we don't lose anything visually, seems no reason not to do this.
#7
I can't really be bothered to compare every single image. Would be nice if would have supplied an comparison chart. But yhea, as catch said - if there is no visual difference, its good to go
#9
Wouldn't expect there to be any loss resulting from PNG optimization programs like those, so I'm for it. Subscribe.
#10
Here are some screenshots for comparison.
#11
Has my vote. Anybody else so we can RTBC?
#12
I am doubtful whether this will make a noticeable difference, even for sites with pages that are heavily reliant on the icon set. We should instead bank on a CSS sprites approach and optimise the icon set there. Time is spent in HTTP requests instead of actual transfer for files this size. Someone with a different theme and icon set will have to redo this optimisation. Even so, it doesn't harm to have this in.
#13
The goal here is not really performance as catch tagged it. We're really only talking about a couple of bytes per image. It's not hugely significant there.
My reason for going through this issue is because every time someone runs YSlow or Google Page Speed to optimize their site, they're going to get notified that their site could be faster if they had used compressed or optimized images, then it will list these images and their compressed options.
When I start thinking about having to swap out core files on my production site to make error messages go away and get a nice clean report, things start leaking out my ears. That's my reasoning. If people think it's also a performance issue, that's fine as well, but even I'll loudly proclaim that's not a great argument on its own.
Google and Yahoo are investing a lot of money in their performance teams, so I expect Page Speed and YSlow have enough users to make this worthwhile in just making Drupal look good that it passes their tests. Latest stat: 1,309,372 downloads of YSlow - note Smush.it is plugged repeatedly on the add-ons page.
#14
Exactly. RTBC.
#15
Just quickly, deekayen can you confirm that said warnings from Google Page Speed go away once you put the images this patch? I only saw a "before" screenshot, not an "after".
And thanks a lot for taking the time to lay out before/after images!
#16
Additionally, let's make sure we have this procedure documented somewhere so whenever a new image is added to core we can make sure this tool has been run on it. It's useful for contributed modules as well.
#17
More screenshots. I uploaded all the proposed in #2 to http://deekayen.net/misc if anyone wants to try it themselves. The DA icon is cached on Coral, so it'll take some time to update. Smush.it is being slow, so I got impatient and took screenshots before it finished processing all of the images, but it shows the feed.png result.
#18
@figaro CSS sprites are a good idea, but we'd need something which generates them - adding a sprite to core is a maintenance nightmare. I don't think this'll make any measurable performance difference either, but it's good to have clean reports from those tools, so that when something shows up which is an actual problem, it's not obscured by the noise.
#19
Sprites are good when you display many of its images on one page. In this case, a lot of the images are displayed on different pages, which could make sprites sub-optimal. Imagine you only want to use a single image of the sprint ...
#20
Thats not 100% true Dries - remember that images are cached, so you would download it once and that would save http requests on other subsequent pages, assuming that the user actually visit multiple pages. Anyway, I think it wouldn't be a good idea to implement anyway - for logistic issues. We could always adopt an automated sprite generator to fix the logistic issue, though.
#21
Fair enough, good point. Most websites have bounce rates of 50% and more so it could still be sub-optimal. ;-)
I'm happy to commit this "patch" but it is a bit time consuming to have to download all of these images. Happy to do so after code freeze though.
Packing them as a single zip file would help a bit.
#22
The last attachment on #2 is "misc.tgz of all the images".
#23
Just to keep the focus on what this issue is about:
1- Avoiding a repeat alert on a tool that is maintained outside drupal (#18)
2- Having a process in place that ensures that this issue does not regress (#16)
I am happy to propose some text to our documentation team, if someone is willing to point out which page(s) this concerns. At the same time, it would help to have similar guidelines for the Drupal theming guide and I would like to propose the best practices guide (http://drupal.org/node/37156). Despite #21, no change in status.
#24
Committed to CVS HEAD. Thanks!
#25
Automatically closed -- issue fixed for 2 weeks with no activity.
#26
Closed it may be, I have yet added the Smush suggestion to the following page: http://drupal.org/node/37156
Please review.
#27
What you had looked fine, even though I tacked on a few more links. It's a little weird to be on the HTML and CSS page. Is there a better place?
#28
#29
I think this works for now. Thanks!
#30
Simple, yet great change :)
For the people who end up reading this issue and are interested in optimizing *all* the images on their site *automatically* (and optionally syncing them to a CDN): use the CDN integration module in combination with the File Conveyor daemon.
#31
Automatically closed -- issue fixed for 2 weeks with no activity.