- From: Yoav Weiss <yoav@yoav.ws>
- Date: Sat, 25 May 2013 22:25:24 +0200
- To: David Bruant <bruant.d@gmail.com>
- Cc: WHATWG <whatwg@whatwg.org>
> > How bad is the current situation with JS-based loaders? I would expect a > JS-based loader and the couple of feature-detection tests to be rather > small as well as heavily cachable, so not that awful for performance. > JS based loaders have several drawbacks: * JS files are not discovered by the preloader, which means the browsers can't prioirtize their download appropriately. * They require JS inlining, which will become significantly harder with CSP (JS nonces make it possible, but it'd require server side logic) * Arguably, attributes make authoring easier, which may mean authors are more likely to avoid useless JS downloads. > I'm not sure I understand your point about preloading scripts parsing. Do > you want them to be preparsed (which costs in battery as you mention) or > not preparsed (which will result in longer time when actually needing the > script)? I was referring to HTML parsing (so the discvery of JS resources in HTML), not the parsing/execution of the JS resources themselves. How much time can be expected to be gained from such a feature given the > state-of-the-art JS loaders? > > Overall, what is the expected gain between a JS-based loader and a > declarative media-aware loader? 1ms? 100ms? > > While the expected gain may vary per site, I'd estimate that it's probably in the area of hundreds of ms for most sites. A recent study by Google (addressing this specific issue) showed that the PreloadScanner gives ~20% improvement https://plus.google.com/+PaulIrish/posts/WcsqfSFZAfR
Received on Saturday, 25 May 2013 20:26:06 UTC