All geek questions in one place

Rails 3.1 http streaming - js in head or bottom of body?

Rails 3.1 has the option to enable HTTP streaming so that your page can be knocked down in pieces. In Railscast on this feature, Ryan recommended that it would be nice to enable this so that your CSS and JavaScript can be torn while the rest of your page is still displayed.

I have always followed the instructions that scripts should be at the bottom of the page after loading the page content to reduce loading time, but it will not take advantage of HTTP streaming video.

What do you think is best now?

+6
source share
3 answers

I think this is a great question; one for which I felt indebted to Google for the answer.

The argument for placing the script resources at the bottom of the page was to prevent the rendering of the browser from blocking, which could otherwise draw pixels on the screen so that the user remains busy while the rest of the loaded page functions load. With HTTP streaming, we are talking about being able to do something about the server being a bottleneck. While we are waiting for the completion of all these expensive database queries and server service calls, we can load JS / CSS assets.

It seems to me that there is a turning point around which you must <head> your assets or not <head> your assets. This is just net profit if your JS / CSS assets can be loaded before your server leaves a ready-made answer.

<head> page assets are not worth it if:

  • You are serving the page from the cache on the server side
  • The response time to the server is faster than the loading time of the actual JS / CSS resource (when calculating the loading time, carefully examine whether these assets can already be cached on the client side or not).

Make <head> page assets if:

  • The server needs more time to respond than it takes to load all your JS / CSS assets while waiting.

Does this sound right?

+2
source

In the general case, I think, unfortunately, they will go to the bottom anyway. The reason is that Safari for Mac supports 1024 bytes before it starts issuing asset requests (and Safari for iPhone and iPad - 512 bytes).

Since the head of the document is generally smaller, Safari users will still get the usual bad experience.

Firefox, Opera, and IE8 do not buffer, and Chrome buffers 252 bytes, according to some test that I did with Hunley Lai.

I am still doing research on this, but this is my conclusion.

+2
source

The subjective answer to the subjective question:

  • Libraries (and definitions of functions in the head), they are all represented as static assets, so they can be cached.
  • "triggers" for callbacks, etc. at the bottom of the page in script blocks.
+1
source

Source: https://habr.com/ru/post/888954/

More articles:


All Articles