[webkit-dev] Question regarding priorities of subresource content retrieval
silvio.ventres at gmail.com
Mon Feb 7 12:18:44 PST 2011
The function doesn't seem to get any information regarding domain the
resource is hosted at.
Calling some kind of setResourceDomainType() to set DOMAIN_TYPE to
enum(0=main domain, 1=subdomain within same domain, 2=CDN, 3=external
domain) and then providing that as an additional parameter to
defaultPriorityForResourceType() seems logical. Trying to see where
this domain-sensing function can be called at earliest.
Regarding the performance test, since it depends on multiple resources
with highly differing latency, it would depend on an external
resource. Does the PerformanceTest framework have some kind of latency
Thanks for swift replies, btw!
On 2/7/11, Nate Chapin <japhet at google.com> wrote:
> The default prioritization is found here:
> 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
>> 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.
>> 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 (
>> > 9: JS/XHR from main domain
>> > 8: HTML/CSS/JS from subdomains in the same domain (
>> > 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 (
>> > 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
More information about the webkit-dev