1

I hear a lot that you should put your scripts at the end of your markup because the page needs to download the script and then execute it before moving forward to render/execute the rest of the page. How is this different than stylesheets? How come the page can keep going with stylesheets and isn't slowed down by them. Don't stylesheets also need to be downloaded and executed before the page continues to be executed by the browser?

stackjlei
  • 9,485
  • 18
  • 65
  • 113
  • More to the point, JavaScript needs the page to have loaded in order to access it. This is largely avoided with frameworks like jQuery (`$(function() {...})`) but on the whole it's still good advice. Stylesheets can be loaded at any time to work just fine, since they're updated dynamically. – Niet the Dark Absol Apr 29 '17 at 19:28
  • Another point is that you're almost never going to deal with a case where the user tries to click a button so fast that the script hasn't loaded yet, so it's okay to run the script at the end of the page. But if the user has to wait more than a fraction of a second for the page to be visible, that's a problem. – Niet the Dark Absol Apr 29 '17 at 19:29
  • 1
    "download the script and then execute it before moving forward to render/execute the rest" - not "render/execute" but "parse". The JS must be executed before parsing continues because the JS might be `document.write(" – Alohci Apr 29 '17 at 20:01
  • @Alohci what's the difference between executed and parsing? – stackjlei Apr 29 '17 at 23:24
  • @NiettheDarkAbsol What does it mean for stylesheets to be updated dynamically? Why is it that scripts need to be run after the page has been loaded but not stylesheets? What's actually going on under the hood? – stackjlei Apr 29 '17 at 23:26
  • @stackjlei - HTML isn't "executed". It's a static description of a data structure, not set of operations to be run. "Parsing" in a HTML context means the conversion of a character stream of markup, into the user-agent's internal object model. It is this conversion that is affected by the JS and therefore means that the browser must wait for it. CSS does not affect the conversion so while it blocks rendering, it doesn't block parsing. See also [Parser blocking vs render blocking](http://stackoverflow.com/questions/37759321/parser-blocking-vs-render-blocking/37759508) – Alohci Apr 30 '17 at 00:00
  • @Alohci would I be correct in saying that "executing" is used for dynamic code from your js files that can change html and css whereas "parsing" is used for static code such as the markup and css that is served from your html/css files? – stackjlei Apr 30 '17 at 00:06
  • 1
    @stackjlei - More or less, yes. Parsing is that specific conversion process that happens once when the HTML and CSS is fetched and loaded by the browser, while JS is executed to affect the DOM both during loading and subsequently, in response to user action. This object model is re-rendered repeatedly as necessary using the CSS rules to layout and style the content on the screen. – Alohci Apr 30 '17 at 00:14
  • @Alohci so essentially parsing can happen asynchronously always because it's static and won't change whereas execution has to defaults to synchronous runtime because it can dynamically change other things – stackjlei Apr 30 '17 at 01:09

3 Answers3

1

CSS and JavaScript are two different contexts.

CSS is just a set of rules while JavaScript: Needs to be executed in a thread meaning it's going to be busy doing its own stuff not to mention that if you're going to use any I/O it will take even longer, so just put it at the footer so all your CSS and HTML load correctly and fast, then you can load your JavaScript script.

You could also do an async script but it depends on the functionality of this script as well.

James
  • 679
  • 1
  • 8
  • 22
  • Why does CSS not need to be executed? What does it mean to be a set of rules? Doesn't it still take time to load those set of rules? – stackjlei Apr 29 '17 at 23:27
  • What I meant by set of rules is that the process is quite simple, you have selectors and properties, all embed in the core of your browser whilst JavaScript uses the real thread, the code is parsed and then interpreted if there was no syntax or runtime error. If your script uses any I/O devices it'll take longer because client has to wait for them devices to answer your script, hence taking longer to process. That's just an instance of what could be happening. Another thing is that some scrips don't use domready event so it'll execute as soon as it is loaded… – James May 01 '17 at 11:51
0

Request at <link rel="stylesheet" href="/path/to/style.css"> is blocking.

guest271314
  • 1
  • 15
  • 104
  • 177
  • @User which cast "downvote" and whom fails to attach description of reason for "downvote", see [Render Blocking CSS](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css) _"This creates an important performance implication: both HTML and CSS are render blocking resources."_ Feel free to contribute rational reason for "downvote" at comment. – guest271314 Apr 29 '17 at 19:54
0

Styles are loaded asynchronously. In fact, you do not need to put script at the end of page. You can put script in the header. But at the same time set the attributes async or defer.

    <script async src="/yourpath/file.js"></script>
// or
     <script defer src="/yourpath/file.js"></script>
Smiranin
  • 738
  • 1
  • 5
  • 14
  • _"Styles are loaded asynchronously."_ ? Where `stylesheet` is requested at `` element? – guest271314 Apr 29 '17 at 19:38
  • @guest271314 As far as I know, yes. The browser processes stylesheet in several stages. Stylesheet does not block the page. – Smiranin Apr 29 '17 at 19:43
  • _"Stylesheet does not block the page."_ Where did you find that information? Link to documentation and specification? See [Render Blocking CSS](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css) _"This creates an important performance implication: both HTML and CSS are render blocking resources."_ – guest271314 Apr 29 '17 at 19:45
  • Where is description of `` not blocking rendering at link? – guest271314 Apr 29 '17 at 19:51
  • @guest271314 Read the last paragraph of your article. "the browser has to hold the initial rendering of the page on that resource", but not downloading files, all css files are loaded asynchronously. In my link pay attention to examples of diagramma, how the render takes place. – Smiranin Apr 29 '17 at 20:05
  • @guest271314 I created 3 files of css and 3 files of js. Every file has size 2.7mb. For example code in Html: ` ` Results in Chrome: css = 0.1s; js = 1.5s; – Smiranin Apr 29 '17 at 21:18
  • @guest271314 *Link to code:* https://ide.c9.io/smiranin/stackoverflow *Link to preview CSS:* https://preview.c9users.io/smiranin/stackoverflow/perfomanceCSS.html?_c9_id=livepreview2&_c9_host=https://ide.c9.io *Link to preview JS:* https://preview.c9users.io/smiranin/stackoverflow/perfomanceJS.html?_c9_id=livepreview1&_c9_host=https://ide.c9.io – Smiranin Apr 29 '17 at 21:19
  • The first link requires login. Not sure how the second and third link are related? – guest271314 Apr 29 '17 at 21:22
  • @guest271314 Plunker saves the created files to local storage, large files it can not save. Because I used the cloud ide. If you can not understand ide, testing my information locally. And you will see that the information is correct. – Smiranin Apr 29 '17 at 21:40
  • Yes. The comparison at plnkr was for `.css` files having different `Content-Length`. If `` element is not blocking files there should not be a difference between the resulting load times. – guest271314 Apr 29 '17 at 21:54