[webkit-dev] Question regarding priorities of subresource content retrieval

[Nate Chapin]

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 <abarth at 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.ventres at 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 at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110207/4ab3508a/attachment.html>