<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I'm still fiddling with the scripts on <a href="http://muddledramblings.com/">muddledramblings.com</a> 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 <a href="http://www.muddledramblings.com/">www.muddledramblings.com</a> and <a href="http://cookieless.muddledramblings.com/">cookieless.muddledramblings.com</a>, but you're making me do things a different way to support one Web browser.)</div><div><br></div><div>(On a side note, <a href="http://muddledramblings.com/">muddledramblings.com</a>'s biggest performance problem right now is the host. Don't use iPage. </rant>)</div><div><br></div><div>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 <i>must</i> 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.</div><div><br></div><div>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 <i>really</i> 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>Jerry Seeger</div><div><br></div><div><div>On Feb 8, 2011, at 9:24 AM, Silvio Ventres wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Do you have any example of scripts or css that are externally sourced,<br>and where developer cares to reasonably optimize the web page?<br>The main use case of such external scripts currently is ads and<br>statistics gatherers for analysis. This, arguably, is not critical<br>content that the user is interested in.<br><br>If your argument is indeed "Web developer should have control", then,<br>when you have no choice but including external scripts (ads, f.e.),<br>you would probably hate those to break the latency of your website.<br>If you are talking about the <a href="http://muddledramblings.com/">http://muddledramblings.com/</a> website, for<br>example, you can clearly see that most scripts there are<br>domain-internal.<br>Do you deem your user experience more or less important than Google<br>Analytics capability ? If Google Analytics hangs, for example, for 4<br>seconds, would you like the user to wait, or start reading while it<br>loads?<br><br>A change to HTML standard might be a good idea, though the problem<br>here is that there are millions of pages on the 'net already, and the<br>developers won't suddenly start changing them.<br><br>This heuristic will allow the users to view 90% of the current Web<br>more interactively.<br>Keep in mind that at least 38% of all statistics is taken out of thin<br>air :), but, really, please, show at least two pages which this<br>heuristic will NOT work on.<br><br>--<br> silvio<br><br>On Tue, Feb 8, 2011 at 6:52 PM, Jerry Seeger <<a href="mailto:vikingjs@mac.com">vikingjs@mac.com</a>> wrote:<br><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Jerry<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Feb 8, 2011, at 2:23 AM, Silvio Ventres wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">This argument - "web developer is to blame for choosing a slow<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">ad/tracking/etc server" - is incorrect.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Web developers in general do not have any control over the ad provider<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">or, frankly, any other type of external functionality provider.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Google Analytics being a good point in case, you would not want most<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">of the world's web pages to suddenly hang if something happens inside<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Google.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The web browser should clearly prioritize developer-controllable<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">resources over ones that are beyond web developer's control.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Also, as an application run by the user and not by the developer, the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">browser should arguably prioritize actual content against<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">pseudo-content which purpose is functionality that is not visibile to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the actual user, such as ad/tracker scripts. This actual content has<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">higher probability to be important when sourced from the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">domain/subdomain of the webpage itself, based on current trends.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Domain check is a reasonable approximation that fits both purposes.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">--<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">silvio<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On Tue, Feb 8, 2011 at 5:13 AM, Jerry Seeger <<a href="mailto:vikingjs@mac.com">vikingjs@mac.com</a>> wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Jerry Seeger<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Feb 7, 2011, at 5:47 PM, Silvio Ventres wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">IE/Opera are delaying only for 4 seconds, same as Mobile Safari<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The reason looks to be the url for the script/css.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">If the url is the same twice, Chrome/Firefox serializes the requests,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">while IE/Opera/MobileSafari launches both requests simultaneously.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Of course, requesting simultaneously doesn't fix anything, as you can<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">see by trying a link-stuffed version at<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="http://solid.eqoppa.com/testlag2.html">http://solid.eqoppa.com/testlag2.html</a><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">This one has 45 css and 38 javascript links. It hangs all browsers nicely.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The main point here is that it might be acceptable if it's coming from<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the webpage domain itself.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">But the links are coming from a completely different place.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">This is exactly what makes browsing pages with any third-party<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">analytics, tracking or ad addons so slow and frustrating.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Fixing priorities in subresource download should make experience<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">considerably more interactive and fun.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">--<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">silvio<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote>_______________________________________________<br>webkit-dev mailing list<br><a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev<br></div></blockquote></div><br></body></html>