evhead: "Wow, the Blogger posting form sends down 30 Javascript files to your browser and 17 .gifs. Curious why they don't turn those 47 http requests into two or three. It would make a huge difference in responsiveness. Pete?"
Really? 47? I ran LiveHttpHeaders while loading the posting form, and here’s what I saw:
GET /post-create.g?blogID=16425656 HTTP/1.1
Host: www.blogger.com
GET /__utm.gif?utmwv=1&utmn=602865791&… HTTP/1.1
Host: www.google-analytics.com
How is it that Ev got 47 and I got 2? If you use curl on Blogger’s image and JavaScript files, you’ll notice that they’re sent back with rather generous cache headers. So, chances are the files are already in your browser:
> GET /img/gl.video.gif HTTP/1.1
Host: www.blogger.com
< HTTP/1.1 200 OK
< Cache-control: public
< Expires: Thu, 08 Nov 2007 02:14:31 GMT
Obviously, if the files are not in your cache, Blogger’s post editor will load more slowly, because it does have 47 or so files to download. If Blogger had the same code in fewer files, the initial loading would likely be somewhat snappier in non-cache situations. So it would have some effect, but, in practice, not always a “huge difference.”
Monday, October 8
Subscribe to:
Post Comments (Atom)
Since JS files are mostly non-presentational, would they significantly influence page render, or only if users were attempting those actions?
ReplyDeleteMore simply, does the page render slower or does spell-check.js just not work for a few seconds?
The page will take longer to become operational, since Blogger's post editor is initialized in an onload handler. More files == longer until onload is fired.
ReplyDeleteIn practice, JavaScript is executed serially and will hold up the page rendering until it's loaded. (IE supports a "deferred" attribute to mitigate this somewhat.) This is because the script may call document.write to modify the HTML.
One could structure things to put the script tags for "optional" features at the very bottom of the page, and write those files to "turn on" the feature once they load. This would work fine as long as you weren't hanging anything off of onload.
Of course, what may be the best structure is to have all common, necessary JavaScript in a single file that gets downloaded first (and cached for a long time). To keep this file small, less frequently-used features (like your spellcheck example) could load their JS only when you first click on the button.
I understand that they're often cached -- esp for regular users. I should have stated it would make a huge difference in some cases.
ReplyDeleteI noticed this, though, because of clicking on New Post form the Dashboard and seeing lots and lots of requests in the status bar while waiting for the page, indicating they're not in the cache. This happens pretty regularly for me.
Not sure about your average user.
Thanks for the response!