5

The answer to this question has been clear to me ever since I read/learned about CSSOM, until today. I can't seem to be able to find the initial article, but it explained quite clear, with examples, that JavaScript execution is deferred until CSSOM is built from all <style> and <link> tags in <head> (except those not applying, based on @media queries).
Or at least that's what I made of it at the time and I had no reason to doubt it until today.

This seems to be backed up by the bold-ed statement in this sub-chapter of Web Fundamentals / Performance, from Google:

... the browser delays script execution and DOM construction until it has finished downloading and constructing the CSSOM.

However, this statement was seriously challenged by a friendly chat on the subject with another SO user under this answer I provided, in which he proposed the following to prove the opposite:

<head>
  <script>document.write("<!--");</script>
  <style> body { background-color: red; } </style>
  -->
</head>

Ok, so let's make sure. Let's replace the <style> with 

<link rel="stylesheet" type="text/css" href="test.php" />

... and make test.php hang for a few seconds:

<?php
sleep(10);
header('Content-Type: text/css');
?>

/* adding styles here would be futile */

If I am right (and js execution is deferred until CSSOM is built), the page hangs blank for 10 seconds, before building CSSOM and before executing the <script> that would comment the <link /> out and would allow the page to render.

If he is right, the js is ran as it's met and the <link /> request never leaves, because it's a comment by now.

Surprise:

  • the page renders right away. He's right!
  • but the <link /> request leaves and the browser tab shows a loading icon for 10 seconds. I'm right, too! Or am I? I'm confused, that's what I am...

Could anyone shed some light into this? What is going on?
Does it have to do with document.write?
Does it have to do with loading a .php file instead of a .css?

If it makes any difference, I tested in Chrome, on Ubuntu.

I kindly ask linking a credible (re)source or providing an eloquent example/test to back-up any answer you might consider providing.

BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
tao
  • 82,996
  • 16
  • 114
  • 150
  • 1
    I don't feel qualified to answer this. I did find this article https://developers.google.com/web/fundamentals/performance/critical-rendering-path/analyzing-crp#adding_javascript_and_css_into_the_mix and in that section it states this: "Even if the script is inlined directly into the page, the browser can't execute it until the CSSOM is constructed. In short, inlined JavaScript is also parser blocking." – gforce301 Jun 05 '17 at 19:18
  • @gforce301 I know. You'll find this statement in several places in that documentation (which is otherwise pretty solid and a very good read), but it conflicts with what's happening in the browser, methinks. In ***their*** browser, even. Something doesn't add up. – tao Jun 05 '17 at 19:46
  • Out of curiosity, if you place a dependency on the CSSOM in your script prior to document.write, does it change the outcome? For example, `console.log(document.documentElement.style.width);` – Travis J Jun 05 '17 at 19:53
  • @TravisJ `console.log(document.documentElement.style.width);` outputs nothing (an empty line). However, console.log('nothing') outputs what you'd expect: `nothing`. And it happens right away. – tao Jun 05 '17 at 20:01
  • Yeah, I know it outputs nothing (there are no computed styles yet), however I was just curious if accessing the style would cause a dependency on the CSSOM or not. – Travis J Jun 05 '17 at 20:03
  • I was also curious! Ilya, the author, actually mentioned this exception in his Udacity course video: "Inline scripts will always block on CSS Object Model. Well, with one exception. If you put your JavaScript above your CSS, then it will execute without blocking on CSS." I wonder if it's spec'ed, but it makes some sense to me. That is, when a browser parses the document and encounters a script, it doesn't know if there will be CSS after the script. It can choose to just execute the JS. https://youtu.be/AKkzB7A2C58?t=94 – 322896 Dec 22 '18 at 18:59

1 Answers1

3

This quote is true, but it means that if you place your style sheet first, and a script after it, the script will not execute until the style sheet is downloaded and parsed. See this example:

test.php:

<?php
sleep(5);
header('Content-Type: text/css');
echo 'body {background-color: red;}';

index.html:

<link rel="stylesheet" href="test.php">
<script>console.log('done');</script>

The console.log call won't be executed until background color changes to red.

This leads to the conclusion that building CSSOM isn't done once for all style sheets, but it's a gradual process – when browser encounters a style sheet, it downloads it, parses, and moves next. Also probably browser first makes a list of all CSS resources and adds them to the download queue, even before executing any scripts. That would explain why the request is made even though the link tag is commented by a script.

Michał Perłakowski
  • 88,409
  • 26
  • 156
  • 177
  • 1
    This basically leads us to the conclusion that `` parsing is, in fact, single-threaded. And that building of CSSOM is gradual, done in stages, as each ` – tao Jun 05 '17 at 20:33
  • @AndreiGheorghiu In your example the request being made looks like a browser bug, because if you inspect the DOM tree in console, you'll see that the `link` tag is commented. – Michał Perłakowski Jun 05 '17 at 20:36
  • I'd say the browser reads the list of all CSS resources first and loads it in a separate process, because it's a list that has to be loaded (in 99.99% of cases - the above being the exception). Doing it in a separate thread makes the process faster, as it's not prone to blocking from main thread. I'd say it's a feature, not a bug. Thank you for taking the time to answer. – tao Jun 05 '17 at 20:41
  • @AndreiGheorghiu But at least it should abort the request when the tag is commented. – Michał Perłakowski Jun 05 '17 at 20:42
  • I totally agree. – tao Jun 05 '17 at 20:43
  • 2
    @MichałPerłakowski I did some testing and it would indeed "appear" to be a browser bug. Both Firefox and Chrome put calls in to load the resources that will become commented out **before** the inline script that starts the html comment executes. They both then load the files even though they never parse or execute them. You can see this happen in the Network tabs of their Developer tools. Oddly enough IE 11 doesn't do this (IMHO the only correct behavior). It completely ignores the tags "that will become commented out". – gforce301 Jun 05 '17 at 20:45