- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 15 Feb 2013 14:29:13 -0800
- To: "Eric J. Bowman" <eric@bisonsystems.net>
- Cc: Anne van Kesteren <annevk@annevk.nl>, Michael Smith <mike@w3.org> (tm), public-html WG <public-html@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>
On Feb 15, 2013, at 8:27 AM, Eric J. Bowman <eric@bisonsystems.net> wrote: > Anne van Kesteren wrote: > >> >>> Also, given that my desktop CPU is twice as fast as that on my >>> server, putting the XSLT on the client reduces transformation >>> latency, not just CPU cycles on the server, in the event of a cache >>> miss. Better user- perceived performance is the result for most >>> consumer CPUs. >> >> You realize on mobile this is not at all the case right? >> > > You realize this is not at all the case *yet*, right? Besides, the > tradeoff on mobile where there is more transform latency, is less > bandwidth utilization -- guess I'm not seeing the problem. Client-side XSLT would prevent starting the loads of any auxiliary resources (images, stylesheets, scripts) until the main resource load is complete so that the XSLT transformation can be performed. Modern mobile networks are often high-bandwidth/high-latency so delaying the start of these extra loads is extremely bad for page load performance.In fact many modern browser engines go out of their way to load these auxiliary resources as early as possible, even doing speculative parsing, and XSLT completely defeats this. This is so even if you can reduce the total bytes used for the main resource, because it's the latency that kills you, not the bandwidth. For anyone looking to make high-performance mobile sites, I would strongly recommend using text/html and strongly recommend against client-side XSLT. Regards, Maciej
Received on Friday, 15 February 2013 22:30:05 UTC