Klix Image DimSum

Run your page, check the HTML source. Do a find/search for the string '.dimsum.' in the HTML source.
Turn on Debug in the DimSum options (Not WP_DEBUG in the wp-config.php file). A verbose output will follow in each page footer. Warning: And please note that this debug mode is public and it lists information such as directory names.

DimSum needs the PHP library, GD for image processing. It does a check for GD during installation. See http://www.php.net/manual/en/book.image.php. GD may need to be added to your site.
DimSum leans heavily on the Perl Compatible Regular Expression (PCRE) functions for parsing HTML text. That is usually included in installs.
DimSum needs Themes that use the 'width' and 'height' attribute in the image tag. It is rendered useless, without those two attributes. Make sure to include it when designing your theme.
ie. <img src="image.jpg" width="200" height="150">

How much faster are DimSum pages
Results will vary. We made the plugin for our site, and it decreased the home page size from 450KB to about 220KB under our favorite theme. -- with no visible difference at all. That move shaved off around 3 seconds of delivery time to the user. Add a caching plugin, and it got even better. We started at 7 seconds, dropped to under 4 seconds with DimSum and then dropped to under 2.7 seconds with a caching plugin.
DimSum savings are greatest with a large disparity between underlying image width/height and HTML width and height attributes.
Themes that use the original or largest image will see big savings, those that use thumbnail images will see less significant speed savings. Images on pages will vary, depending on the use of the 90%, 80%, 70% image scale in posts. I hope you know the interface im speaking of.
What about the trade-offs
DimSum conducts regular expression on an HTML page, searching for 'img' tags along with 'width=xx', 'height=yy', plucks those values out and spanks them. That lengthy process is followed by a string replace. All add up to an expensive operation.
Despite all that work, a significant time savings can be had when the disparity between original and optimized is great. Why is that. Because performance to user is different than server performance. More content means slower delivery. Remember the elephants.

But we strongly suggest using DimSum along with a caching plugin of some sort for optimal performance. Page caching will avoid that expensive regular expression operation per user.
Will DimSum work with caching plugins?
Yes, but not always. It is compatible with various components of a caching plugin, but not all. WP is getting complex after all.

That's why we added a huge Debug log and we have added a 'Run level' option to help you find compatibility with your caching plugin. A low number runs early and the high number runs after other plugins.
Those two features help you find compatibility with your caching plugin.
Note: DimSum should run after most other plugins, but before caching plugins.

WP Cache: It seems to be fully compatible.
WP Total Cache: Incompatibilities appeared when using the extended disk paging. Basic paging seems compatible.
WP Super Cache: Incompatibilities appeared but page caching was fine because of its use of WP Cache under the hood.

We suggest disabling caching, play around with DimSum, check out the different debug outputs, and get it stable. And then enable caching again.

Our site succesfully uses the following combination: DimSum, WP Cache and Keep-Alive and Max-Age for browser caching. We also 'prime' our site using a simple combo of wget and crontab.
Will DimSum work with Google's mod_pagespeed. It seems redundant with the'rewrite_images' function?
Yes, its works perfectly with mod_pagespeed. Most importantly, DimSum was designed for those users without no or incomplete control over server configurations. DimSum gives you better control over your shared server situation.