Top 10 WPO Disasters: Don't Let This Happen To You

Joshua Marantz (Google)
Web Performance, Mission City Ballroom B1
Average rating: ****.
(4.00, 15 ratings)

What can go wrong with automated web performance optimization? Some of the problems are particular to the architecture of the WPO solution. Others potential problems are fundamental to the current state of the art of the field, which is roughly where C compiler optimizers were in 1988: they could make improvements that would be ridicuously onerous for human programmers, but had to be used consciously; not as a default setting to be turned on and ignored.

WPO solutions (such as mod_pagespeed) which run at origin without an explicit setup phase create extra load on the server(s) optimizing resources on the fly. The benefit is that it’s very easy to deploy and will automatically track site evolution in its server-side cache. The drawback is that the cache may need to be tuned, and sites that employ cache-busting hacks may effectively defeat all optimizations while still adding load to their servers. We’ll show what happens when this goes all wrong.

WPO solutions that simply optimize images when serving them cannot exploit contextual information (width/height tags) to deliver the optimal image, nor can they safely increase the cache lifetime of resources. The benefit is that they be used “transparently” without every breaking sites.

On the other hand, WPO solutions that change change DOM structure or tweak URLs in HTML, CSS, or even JavaScript have a much richer set of optimizations at their disposal, but open themselves up to breaking site functionality if the exact syntax of those URLs is critical to their function. We’ll what happens when this goes wrong & how to address it.

Operations such as domain-sharding, inlining small resources, and combining multiple resources into one are generally a win, but can in some cases have surprisingly negative effect on performance. We’ll look at some of these corner cases & what we’ve learned from them.

We’ll look at the impact of some other transformations, such as image-spriting, SPDY, web-fonts, and SSL to see what happens when these technologies are deployed.

Photo of Joshua Marantz

Joshua Marantz

Google

Joshua Marantz is a software engineer at Google, where he is tech-lead of mod_pagespeed, a project to build an open-source Apache module for automatically improving website latency and reducing bandwidth consumption by rewriting HTML, CSS, Javascript, and Images. At Google he has also worked on latency improvements in web caching infrastructure and scalable social networking. Prior to Google, Josh spent 20 years in the Electronic Design Automation industry, much of it working on accelerated functional simulation. He holds BS and MS degrees from MIT, in Computer Science and Engineering, and Electrical Engineering and Computer Science.

Sponsors

Sponsorship Opportunities

For information on exhibition and sponsorship opportunities at the conference, contact Gloria Lombardo at (203) 381-9245 or glombardo@oreilly.com

Media Partner Opportunities

For media partnerships, contact mediapartners@ oreilly.com

Press and Media

For media-related inquiries, contact Maureen Jennings at maureen@oreilly.com

Contact Us

View a complete list of Velocity contacts