Re: [Mediawiki-l] vector skin repeated images?

We (Roan and I) performed careful analysis very early on of the effects of data-uri embedding and found clear evidence that even in cases where relatively large images were repeated the resulting CSS with embedded images was significantly smaller than the raw data of the CSS and image files when gzip compression was utilized. Part of this has to do with gzip making a dictionary of the PNG headers and common palette colors, making a virtual sprite of sorts. Without gzip the size was slightly larger, specifically because base64 bloats the image data a little bit and as you noticed some images are repeated. The repeated images are very small however so that really only adds a negligible amount of data in a non-gzip situation. The added bonus here is that all the images and the CSS code are available in a *single request*. That results in ridiculous time (queuing/HTTP slow start) and data transfer (overhead) savings that *simply can not be understated*. That said, since Vector was not designed with this in mind, I think it's probably possible to make adjustments to Vector's HTML and CSS to reduce the number of repeated data-uris, such as using a class for a background image and another for the specific placement and repeat properties. But to be honest, this gets down to micro-optimization and perhaps even pre-optimization since we're not so sure this is really going to be a visible problem in production. In fact, the front-end performance changes that this and other optimization techniques that ResourceLoader gives us are so significant that it's a much better use of our time to just do whatever we can to get ResourceLoader into production as soon as possible and worry about the micro-optimizations later. Also consider that obfuscation may be a result of further optimizing Vector. I think there must be some cases where Vector can be further optimized without obfuscation, but I think that will be the minority of cases. We should find those cases and get at them, but let's approach the problem with respect to avoiding making a mess in the name of performance. - Trevor On 12/7/10 5:21 AM, jidanni(a)jidanni.org wrote: