The default prioritization is found here: http://trac.webkit.org/browser/trunk/Source/WebCore/loader/cache/CachedResource.cpp#L51. There are cases where we override this (e.g., I'm pretty sure we load favicons at a lower priority than other images)
On Mon, Feb 7, 2011 at 11:44 AM, Adam Barth <aba...@webkit.org> wrote: > There is already some amount of code that's involved with prioritizing > subresource loads. See > > http://trac.webkit.org/browser/trunk/Source/WebCore/loader/ResourceLoadScheduler.h > and > http://trac.webkit.org/browser/trunk/Source/WebCore/loader/cache/CachedResourceLoader.h > . > > I suspect the prioritization algorithm could be improved. A good > first step is to create a benchmark illustrating the performance > issues and then write patches that optimize the benchmark. Please > consider putting your performance test in > http://trac.webkit.org/browser/trunk/PerformanceTests/ so that it's > easy for others to work on as well. > > Adam > > > On Mon, Feb 7, 2011 at 11:23 AM, Silvio Ventres > <silvio.vent...@gmail.com> wrote: > > Hello. > > > > Can someone point where in the source code is the implementation of > > the subresources loading and some documentation regarding its > > implementation - as a queue or just child-threads or async functions? > > > > The reason is that the current subresource loading seems to lack any > > prioritization and it often occurs that some external "1x1 pixel > > tracker" or other similarly unimportant page resources block the > > rendering of the page completely, and the user is left starting at > > "contacting ads.doubleclick.com" with a blank page. This is very > > frustrating as the page render as a whole then depends on the slowest > > part and cannot be possibly done faster by any optimizations in > > hardware or software on the part of the page owner. > > > > Thus, the proposition is this: > > 1. Render should only wait for the main HTML/CSS to load from the main > > page domain (a page in tumblr.com domain should wait for html/css > > files from *.tumblr.com, but not from *.doubleclick.com). > > 2. Other content load except HTML/CSS should be prioritized as > > follows, with placeholders shown until the load is complete - possibly > > adding one or more extra render passes, but increasing interactivity. > > > > So, basic priorities: > > > > 10 = Highest: HTML/CSS from main domain ( > sites.tumblr.com/some_site.html) > > 9: JS/XHR from main domain > > 8: HTML/CSS/JS from subdomains in the same domain ( > ads.tumblr.com/ad_serve.js) > > > > 7. <Reserved for future use> > > > > 6. IMG/media from main domain (sites.tubmlr.com/header.png) > > 5. IMG/media from subdomains in the same domain ( > ads.tubmlr.com/banner1.png) > > > > 4. <Optional*> HTML/CSS/JS (text) from CDNs > > 3. <Optional*> IMG/media from CDNs > > > > 2. HTML/CSS/JS from other domains > > (*.doubleclick.com/link_210986cv3.php?refer=2323424) > > 1=Lowest. IMG from other domains (*.doublclick.com/images/track_1x1.gif) > > > > *4 and 3 are optional and would need some kind of a whitelist of > > well-known CDN domains. > > > > This prioritization will reduce the latency between the page load > > start and a usable render, so even if some external-domain subresource > > is nonresponsive, interactivity will not suffer. > > Maybe the priorities should be moved to a user-controllable setting, > > where more fine-grained rules can be defined. Otherwise, maybe HTML > > standard can be extended to provide hints to the browser regarding the > > preferred subresource loading order, which should of course be > > user-overridable. > > > > Thank you for reading. > > This might be a big undertaking but the benefit for the user will be > > seen instantly. > > > > -- > > silvio > > _______________________________________________ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
