Sorry - the WordPress plugin is W3 Total Cache, not W3 Super Cache. I always 
get those names scrambled.


On Feb 8, 2011, at 10:40 AM, Jerry Seeger wrote:

> I'm still fiddling with the scripts on after a redesign, 
> but I intend to move static resources to a cookieless domain to improve 
> performance. This is a petty common tactic - sort of a poor man's CDN. The 
> key is that I can decide to do this. (Yes, I could rearrange my site and use 
> and, but you're 
> making me do things a different way to support one Web browser.)
> (On a side note,'s biggest performance problem right now 
> is the host. Don't use iPage. </rant>)
> Keep in mind that scripts not executing when expected can totally break a 
> site, not just make it less pleasant. A script that generates content must be 
> executed in a predictable fashion no matter where it came from. Long ago I 
> had a moon phase widget that generated content, and raised hell on browsers 
> that did not block correctly when the script loaded. (I once had a widget 
> with a script that generated a script. The results were... inconsistent.) 
> These days all browsers block correctly and the Web is a better place for it.
> I can't see telling Web designers, "If your script uses document.write, it 
> must come from the same domain or a known whitelist." (And let's hope the 
> latency of the whitelist server is really low.) I can't see telling Joe 
> Blogger why the visitor counter in his sidebar now writes the number at the 
> bottom of the page.
> The WordPress plugin W3 Super Cache includes features to automate moving 
> static content (including scripts) to a separate, cookieless domain. A lot of 
> people use the plugin, but I can't speak to how many use the pseudo-cdn 
> feature. My guess is not that many, but the ones who do will expect their 
> scripts to execute where encountered, before the rest of the page loads, as 
> mandated by the standards.
> The Web designer can already cause javascripts to load after the rest of the 
> page (the above plugin automates this as well). Were I to run ads, you can 
> bet that those scripts would not be loaded in the header (well, if I weren't 
> lazy you could bet it). If I'm not already loading Google analytics late, 
> it's because I haven't finished getting my script strategy finalized.
> While I would certainly like to see an automated mechanism for setting 
> external resource priority, allowing me to continue in my lazy ways and not 
> pay a performance price, (and make the Web more responsive in general, since 
> most of us are lazy), simple domain check is not adequate when it comes to 
> scripts. I wish I could think of an automated way to augment using the 
> domain, but all my ideas require knowing what's in the script ahead of time 
> (scripts that only define event handlers, for instance).
> Jerry Seeger
> On Feb 8, 2011, at 9:24 AM, Silvio Ventres wrote:
>> Do you have any example of scripts or css that are externally sourced,
>> and where developer cares to reasonably optimize the web page?
>> The main use case of such external scripts currently is ads and
>> statistics gatherers for analysis. This, arguably, is not critical
>> content that the user is interested in.
>> If your argument is indeed "Web developer should have control", then,
>> when you have no choice but including external scripts (ads, f.e.),
>> you would probably hate those to break the latency of your website.
>> If you are talking about the website, for
>> example, you can clearly see that most scripts there are
>> domain-internal.
>> Do you deem your user experience more or less important than Google
>> Analytics capability ? If Google Analytics hangs, for example, for 4
>> seconds, would you like the user to wait, or start reading while it
>> loads?
>> A change to HTML standard might be a good idea, though the problem
>> here is that there are millions of pages on the 'net already, and the
>> developers won't suddenly start changing them.
>> This heuristic will allow the users to view 90% of the current Web
>> more interactively.
>> Keep in mind that at least 38% of all statistics is taken out of thin
>> air :), but, really, please, show at least two pages which this
>> heuristic will NOT work on.
>> --
>> silvio
>> On Tue, Feb 8, 2011 at 6:52 PM, Jerry Seeger <> wrote:
>>> My argument is less "it's the Web developer's fault" than it is "the Web 
>>> developer should have control." I am hardly a sophisticated Web developer 
>>> but I have javascript from a different  domain that must be loaded first 
>>> and I have Google analytics, which I should load after the rest of the page 
>>> (though to be honest I'm not sure I do after my redesign... hm). While I 
>>> would love it if there were standardized rules for which scripts would be 
>>> loaded synchronously and which wouldn't, I would hate it if one browser 
>>> required me to move my scripts to a different domain.
>>> Having said all that, I hate it when I have to wait for a resource out 
>>> outside of my control, so I'd love to see a solution to this. If there were 
>>> a more reliable way than simple domain checking to prioritize content, that 
>>> would be fantastic. I think ideally this is something for the standards 
>>> board - perhaps an extension of the script and link tags to specify a 
>>> priority, or something like that.
>>> Jerry
>>> On Feb 8, 2011, at 2:23 AM, Silvio Ventres wrote:
>>>> This argument - "web developer is to blame for choosing a slow
>>>> ad/tracking/etc server" - is incorrect.
>>>> Web developers in general do not have any control over the ad provider
>>>> or, frankly, any other type of external functionality provider.
>>>> Google Analytics being a good point in case, you would not want most
>>>> of the world's web pages to suddenly hang if something happens inside
>>>> Google.
>>>> The web browser should clearly prioritize developer-controllable
>>>> resources over ones that are beyond web developer's control.
>>>> Also, as an application run by the user and not by the developer, the
>>>> browser should arguably prioritize actual content against
>>>> pseudo-content which purpose is functionality that is not visibile to
>>>> the actual user, such as ad/tracker scripts. This actual content has
>>>> higher probability to be important when sourced from the
>>>> domain/subdomain of the webpage itself, based on current trends.
>>>> Domain check is a reasonable approximation that fits both purposes.
>>>> --
>>>> silvio
>>>> On Tue, Feb 8, 2011 at 5:13 AM, Jerry Seeger <> wrote:
>>>>> I'm reasonably sure that javascript in the header must be loaded 
>>>>> synchronously, as it might affect the rest of the load. This is why tools 
>>>>> like YSlow advise Web designers to move javascript loads that are not 
>>>>> needed for rendering until after the rest of the page loads.
>>>>> Blocking on loading the css is less clear-cut, as in some cases it could 
>>>>> mean several seconds of ugly page. I don't know if it's right or wrong, 
>>>>> but a lot of pages out there rely on the CSS being loaded before the page 
>>>>> starts to render to avoid terrible layout and the appearance of items 
>>>>> meant to be hidden for the seconds it takes the css to load.
>>>>> In general, while things could certainly be improved, it's up to the 
>>>>> owner of the page to not rely on a a slow ad server, or build the page so 
>>>>> the ads load after the primary content.
>>>>> Jerry Seeger
>>>>> On Feb 7, 2011, at 5:47 PM, Silvio Ventres wrote:
>>>>>> IE/Opera are delaying only for 4 seconds, same as Mobile Safari
>>>>>> The reason looks to be the url for the script/css.
>>>>>> If the url is the same twice, Chrome/Firefox serializes the requests,
>>>>>> while IE/Opera/MobileSafari launches both requests simultaneously.
>>>>>> Of course, requesting simultaneously doesn't fix anything, as you can
>>>>>> see by trying a link-stuffed version at
>>>>>> This one has 45 css and 38 javascript links. It hangs all browsers 
>>>>>> nicely.
>>>>>> The main point here is that it might be acceptable if it's coming from
>>>>>> the webpage domain itself.
>>>>>> But the links are coming from a completely different place.
>>>>>> This is exactly what makes browsing pages with any third-party
>>>>>> analytics, tracking or ad addons so slow and frustrating.
>>>>>> Fixing priorities in subresource download should make experience
>>>>>> considerably more interactive and fun.
>>>>>> --
>>>>>> silvio
>> _______________________________________________
>> webkit-dev mailing list
> _______________________________________________
> webkit-dev mailing list

webkit-dev mailing list

Reply via email to