6

In Rails 3.1 there's the option to enable HTTP streaming so that your page can be brought down in chunks. In the Railscast on this feature, Ryan recommended that it would be a good idea to enable this so that your CSS and JavaScript can be pulled down while the rest of your page is still being rendered.

I've always followed the guideline that scripts should be at the bottom of the page after all the page content is loaded so that it would reduce perceived loading time, but by doing this it won't be taking advantage of the HTTP streaming.

What do you think is the best practice now?

Paul
  • 4,422
  • 5
  • 29
  • 55

3 Answers3

2

I think this is an excellent question; one for which I felt compelled to Google for an answer.

The argument for putting script assets at the bottom of the page was to prevent blocking a browser's renderer that could otherwise be painting pixels on the screen to keep the user busy while the rest of the page's functionality loaded. With HTTP streaming, we're talking about being able to do something about the server being the bottleneck. While we wait for all those expensive database queries and backend service calls to finish, we can load JS/CSS assets.

It seems to me that there's a tipping point around which you should <head> your assets or not <head> your assets. This is only a net performance gain if your JS/CSS assets can be downloaded before your server has the rest of the response ready.

Don't <head> a page's assets if:

  • You're serving the page out of a server-side cache
  • Your server's response time is faster than your JS/CSS' actual asset load time (when calculating load time, consider carefully whether those assets are likely to have already been cached on the client side or not)

Do <head> a page's assets if:

  • Your server's takes longer to respond than it would take to load all of your JS/CSS assets while waiting

Does that sound about right?

steveluscher
  • 4,144
  • 24
  • 42
2

For the general case, I think unfortunately they are still going to go to the bottom. Reason is Safari for Mac buffers 1024 bytes before it starts to issue requests for assets (and Safari for iPhone and iPad buffer 512 bytes).

Since the head of a document is typically smaller, Safari users would still get the ordinary bad experience.

Firefox, Opera, and IE8 do not buffer, and Chrome buffers 252 bytes, according to some test I've done together with Hongli Lai.

I am still doing research about this, but as of this writing this is my conclusion.

Xavier Noria
  • 21
  • 1
1

Subjective answer to a subjective question:

  • Libraries (and function definitions in head), all provided as static assets so they can be cached.
  • 'triggers' to callbacks, etc. at bottom of page in script blocks.
colinross
  • 2,075
  • 13
  • 10