Thread:Requests for comment/Partial page caching/A few notes


 * if I recall correctly, gzipping may need to be pushed until after the ESI processing runs; this means the gzip output buffer options in MediaWiki would need to be disabled and replaced with either a transform in or in front of the caching proxies, if we don't already do this. (Plus side: reduces cache fragmentation between gzipped and non-gzipped pages? Minus side: may inflate cache sizes significantly.) Artur Bergman should have hints about this sort of thing from his Wikia days.
 * most HTML5-style enhancements should either be used unconditionally (thus enhancing when supported!) or triggered from JavaScript based on client-side support; server-side sniffing will rarely be useful or desired there.
 * inline SVGs are a possibility based on Accept headers... but doing this well may require some fancy footwork. See my 2009 SVG-Open talk; my analysis then showed that a lot of SVGs are much larger in source form than their renderings; large maps and such also may render slowly. Efficient inline SVG thumbs would be fantastic especially for mobile (think high-density displays like the iPhone 4), printing, people zooming in on their screens, etc... but may require tools to make large SVG images less heavyweight, or to conditionally fall through to rasterization for certain uses.
 * location stuff should probably be limited to announcements/banners; today we do those sorts of things via JavaScript which is mostly nice, but subideal when a banner may or may not be present, or have unknown height (the current discussions, as always, about pages 'jumping' when the banner shows)
 * I'm not sure how much we can really handle for logged-in users (other than just using ESI to inject banners and things). Current skins aren't really designed for this, and lots of options may affect both the full HTML skin and some contents of the page stuff. Worth considering though -- ideally in the future we'll have a system that is friendlier to that! (Athena?)